ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。 最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。

まじめなことを書くつもりでやっています。 適当なことは 「一角獣は夜に啼く」 に書いています。

トップ > 勉強会

発表資料: Android アプリ開発における Gradle ビルドシステム (京都 Android 勉強会 2014.08)

Android アプリ 開発環境 勉強会

去る 8 月 23 日に株式会社はてな主催で行われた Android アプリ開発の勉強会 「京都 Android 勉強会 2014.08」 にて、Android アプリ開発と Gradle について喋ってきました。

Android Studio ではビルドシステムとして Gradle が採用されていますので、今後 Gradle を使う人は増えていくと思います。 Android Studio でビルドをするだけであればそれほど Gradle に詳しくなくても問題ないわけですが、せっかくなのでいろいろ便利に使っていきましょう、という主旨の発表でした。

発表内容は下のような感じで、Gradle を使ったことがない人にも 「Gradle でこういうことができる」 というのが伝わるように喋ったつもりです。 また、後半の方は Gradle を使って Android アプリのビルドをした人でも触ったことがない人もいると思いますので、Gradle を使っている人にも参考になったかもしれません。

  • Gradle と Android アプリのビルド
  • Gradle や Android Gradle plugin の機能の一部を紹介
    • ここら辺は知らなくても問題なく開発できるはずではあります
  • AAR パッケージについて
  • Gradle プラグインについて

勉強会では、Cookpad の @rejaspotaro さんが 「debug ビルドの時だけデバッグに便利なメニューを表示するようにしている」 とか、「社内でいくつか Gradle プラグインを作って便利に使っている」 という話を先にされていたので、そこら辺とからめて Gradle の話ができたのも良かったところです。

質疑内容

会場で 2 つほど (確か 2 つ) 質問がありましたので、ここにも書いておきます。

Gradle wrapper の更新

Gradle wrapper を使う場合、Gradle のバージョン更新はした方がよいのか、という質問でした。

Android Studio のバージョンアップにともなって必要な Gradle のバージョンも変わってきますので、Android Studio のバージョンアップに合わせてプロジェクト内の Gradle (Gradle wrapper) のバージョンも更新する必要があります。 最近の Android Studio では、Gradle のバージョンが古い場合に警告を出してくれて、GUI 上でぽちぽち操作すると自動的にバージョンが更新されるはずです。

Gradle の欠点

発表資料の中で 「Groovy のことを理解するまでデバッグ等が大変」 と書いていますが、それ以外に不便な点などはあるか、という質問でした。

Gradle 自身の欠点というわけではないですが、Eclipse での Android アプリのビルドと比べて、一部を変更してビルドし直すというのが Android Studio でのビルド (あるいは直接コマンドライン上で Gradle を使った場合のビルド) では時間がかかってしまうというのがあります。 私は今のところあまり細かい変更でビルドし直すということをしないようにすることでなんとかしていますが、UI の変更などでは細かく調整したいということもあってなかなか不便ということでした。

Gradle をオフラインモードにすると速くなるという話もあります。 (ちゃんと試してません。)


関連エントリ

勉強会での他の発表者の発表資料や参加者によるまとめです。 (後で追加します。)

「うらがみが Java まわりの ORM を知りたい会」 に参加してきた

Java 勉強会

Java の O/R マッパーまわりの話を知りたかったので、6/14 に行われた勉強会 「うらがみが Java まわりの ORM を知りたい会」 に参加してきました。 会場は和室でした。

Java まわりの O/R マッパー、あんまり詳しくないのでいろいろ知れて良かったです。 メモを残しておきます。

発表内容

Java の ORM、Doma の話 +α (@backpaper0 さん)

いろんな O/R マッパーについての簡単な紹介と、Doma の紹介。

  • 紹介された O/R マッパーのうち、使うとしたら JPA か Iciql か Doma かなーという気持ちになった。 (個人の感想です。)
    • ちなみに紹介されてる O/R マッパーのうち私がちゃんと知ってるのは JPA だけ。
  • Iciql と H2 Database を組み合わせて Android アプリで使うことができる (実際に製品開発に用いた) とのこと。
    • H2 Database は Android 用のビルド (?) があるらしい。
    • Java DB (Derby) を Android アプリで使おうとして挫折したことがあるので、今度は H2 Database を試してみたい。
Doma について
  • 公式サイト: Welcome to Doma — Doma 2.0 ドキュメント
  • 2 系は Java 8 以降。 1 系は Java 7 までらしい。
  • Doma、なんのライブラリにも依存してないらしい。
  • Pluggable Annotation Processing API を使ってる。
    • その仕組み上他の言語で使えない。
  • 原則としてクエリは SQL ファイルに書かないといけない。 (クエリビルダもあるが使わない方が良いらしい。)
    • SQL には if とか書ける。 ほぼ Java のコードを書けるっぽい。
  • コンパイル時にいろいろ検出。 (対応する SQL ファイルがなかったり中身が空だったり、アノテーションがなかったりすると)
  • DAO の引数や戻り値、エンティティのプロパティ (?) などにドメインクラスを使用できる。 (良い!!!)
  • 自動生成されるのはエンティティの補助クラスと DAO の実装クラスと、ドメインクラスの補助クラス。
議論
  • SQL で書くか Criteria API か?
    • Criteria API の方が IDE の補助があったりするけど、コードが膨らんだりするし、Doma だとコンパイル時に検証してくれたりするし SQL が良いと思ってる。
    • みたいな議論もあった。

F 社乙女チームの ORM (黒) 歴史 (@daiksy さん)

  • Scala でサーバーサイドを書くにあたっての O/R マッパー選択の歴史。
  • Play framework。
  • 今は Slick か ScalikeJDBC が良さそうだけど、昔は悩ましかった。
  • 最初: Squeryl。
    • Implicit conversion を駆使するから IDE の補完が微妙だったりしてしっくりこなかったらしい。
  • 2 個目: ScalaQuery (のちの Slick)。
    • 使いやすいし、後々デファクトスタンダードになるのは理解できる。
    • Scala 2.9 → 2.10 のバージョンアップ時に Slick と名を変えて 2.9 系は切り捨てられた。
    • ScalaQuery を使っていた web アプリケーションはあえなくレガシー化...。
    • Scala はバイナリ互換性がないのがつらいよね。
  • 最後: MapperDao を採用。 (現在も。)
    • Squeryl, Slick, Activate, Circumflex-ORM, MapperDao, SORM, Scala ActiveRecord などを検討して、結果的に MapperDao。
    • DSL が結構良い。 普通の SQL っぽい感じで書ける。
    • ドキュメントの量とかは少ないので、今からなら Slick とか ScalikeJDBC のが良さそうな気がする。

Scala 周りの文化は全然知らないので、そんな感じなのかーと思いながら聞いてた。 Scala 便利だけど互換性とか大変そう。

JOOQ の紹介 (@chipstar_light さん)

  • 使ったことないけど紹介。
  • O/R マッパーというより DB アクセスライブラリ。
  • テーブルから Java コードを生成して、型安全な SQL を Java 上で書ける、て感じ??
  • 既存の O/R マッパーでいい感じのがないけど JDBC をそのまま使うのも微妙、って感じの時に効果的に使えそう。

ORM 初心者が使おうとした (@KYON_MM さん)

3 つの O/R マッパー紹介
  • JOOQ
    • 機能的には使いやすい。 大体揃っているしユーザー数も多そう。
    • QueryDSL を駆逐してやるという勢いを感じる。
  • Iciql
    • とても薄いラッパー。 手軽で良さそう。
  • Slick
    • Play Framework のデフォルトになる予定。
    • 型型しすぎてる雰囲気。
      • Scalaz と同じ雰囲気。
    • ScalikeJDBC の方が好きな人が多いのでは?
議論的な話
  • ロックやリトライのサポートの話。
    • O/R マッパーでいい感じにサポートされているものは少ない。
    • ロックはともかくリトライは O/R マッパーがサポートすべきものではない気がするなーと思ったりした。
  • コネクションプールなどが O/R マッパーの内部で実装されていて不便なことが多い、とか。
    • テスト時にコネクションプールに手を入れられると便利。
    • BoneCP 使いたい、とか。
    • ScalikeJDBC では HikariCP が使えるようになった。 素晴らしい。

MyBatis (@s_kozake さん)

  • 大規模な案件に MyBatis で挑んだ。
  • MyBatis
    • 以前は iBatis という名前。
    • レガシーな環境、非正規化されたデータベース、SQL 文の実行を完全に制御したい場合によい選択肢となる。
    • 自動生成されるソースは?
  • MyBatis のラッパーをこざけさんが頑張って作っていい感じに使えるようになってた。 (すごい。)
  • Proxy クラス というのを初めて知った。
    • めっちゃ便利やん。

GORM めっさゆるい (@kazuhito_m さん)

  • リファレンス: 7 Object Relational Mapping (GORM) 2.4.0
  • Grails 用の O/R マッパー。
    • Grails とは独立させて使おうとすると大変っぽい?
  • GORM、Groovy らしさがあふれてるなーと思った。
  • ゆるい感じで使いたいならいいけど、まじめに大規模開発に使うと死にそう。

android.casual.test #2 に参加しました & LT しました

Android アプリ 勉強会

android.casual.test とは

android.casual.test は、Android のテストについてカジュアルに語るイベントです。 2 回目の開催となる今回は、4 月 3 日に行われました。

私は去年の 5 月ごろから Android アプリ開発の勉強を始めたのですが、なかなか社外の Android アプリ開発者と交流する機会がなく、交流したいなーという気持ちが高まっていたので参加してきました。

関西でもこういう感じのイベント (勉強会) をやりたいですね。

LT: はてなにおける Android アプリのソフトウェアテスト

私は 「はてなにおける Android アプリのソフトウェアテスト」 というタイトルで LT してきました。

はてなでは、最近 (ここ数ヶ月ぐらい) Android アプリのソフトウェアテストを行うようになりました。 どういう環境でテストを動かしているのかや、どういうテストを書くようにしているのかということを紹介し、また、テストを書く中で得られたノウハウなども紹介しました。 上のスライドで紹介しているのは、あくまで Gradle を使う場合の基本 (だと私は思ってます) のテスト手法です。 より実践的には、@rejasupotaro さんが紹介されていた RoboSpock を使うなどの方法もありますが、「まだテストを書いたことがないけどテストを書いた方が良さそう」 と感じている人 (あるいは組織) は、まずは導入として Android 端末 (実機 or エミュレータ) 上で動くオーソドックスなテストを書くところから始めてみると良いのではないでしょうか。

Android アプリのテストについての基本的な部分は、次の書籍も参考になります。

Androidアプリテスト技法

Androidアプリテスト技法

あくまで基本的な部分は、です。 初心者向けの本なのである程度テストを書ける人が読んでも得られるものは少ないでしょう。 次の感想記事も参考にしてください。

各 LT 感想

android.casual.test #2 での各 LT の感想です。

「JUnit テストを 1 日やってみた」

@amyu_san さんの LT。

生まれて 20 年で初めてテストを書いた、ということだったけど、個人開発者で 「テストを書こう」 という意識を持ってるのがすごいなーと思った。

Gradle とかビルドシステム周りのことをあまり知らなくても IntelliJ でテストを書けるっぽく (ちゃんとわかってない) て、新しい発見 (気付き?) だった。 そういえば通常の Java プロジェクトを Eclipse で書くときは、GUI 上でぽちぽち操作してテスト用のクラスを作ったりテスト実行したりしてるので、Android アプリ開発でもできて当然という気はする。

「ノット・ジャバ・テスト」

@rejasupotaro さんによる LT。 「テストを書き続けられる環境を作ろう」 という話や、Robolectric や Spock、RoboSpock などの紹介。

今のうちの会社だと 「自然とテストを書けるような雰囲気 (?)」 みたいなのができていると思うけど、人が変わったり状況が変わったりするとテストを書くのが苦しいような状況にもなり得るので、テストを書くのが難しくない仕組みや環境づくりについてはいつも意識しておく必要があるなーと思った。

あと Spock というものや RoboSpock というものを初めて知った。 また今度使ってみよう。

「もしもの時にも安心な uiautomator の watcher 機能」

id:sumio_tym さんの LT。 uiautomator 自体は知っていたけど使ったことがないので興味深かった。 uiautomator は、他者が作ったアプリの UI テストもできるらしくて、アプリをまたぐような操作シナリオのテストなどに重宝するとのこと。

テスト中に NullPointerException が発生してエラーダイアログが表示された場合、(その挙動がテストシナリオで想定されていないものであれば) 後続のテストが全て失敗する、というようなことが起こるので、UiWatcher を使って監視する、という感じの話。 uiautomator を使うようなテストを書くことってなかなかないけど、今度使うようなことがあれば UiWatcher 周りも検討しようと思う。

｢テストツール導入しようとしている話｣

id:androhi さんの LT。 UI テストを実施するために Robolectric や各種 Gradle プラグインを試したりしたけどうまくいかず、結局 Espresso に落ち着いた、という話。

rejasupotaro さんもブログ記事に書かれてるけど、UI 周りのテストってどこまで自動化するか難しいなー、という気がする。 今のところ、個人的には Espresso を使った単体テスト (?) 程度に留めておくのが吉かなー、と思ってる。 (もちろん条件次第だけど、私が関わってる Android アプリでは、という感じ。)

「テストプラットフォームサービスの舞台裏」

@_touchy_ さんによる LT。 Android 端末の実機上での動作確認やテストをリモートで行うことができるサービスである Scirocco Cloud の舞台裏ということで、実機の運用に特有の苦労話などが紹介された。 実機の運用という全然知らない世界の話だったので、純粋に面白かった。

お疲れ様でした!

LT でも懇親会でもいろいろな話が聞けて有意義でした。 参加者の皆様お疲れ様でした!

関連エントリ

「Typetalk Hack Kyoto」 に参加しました

勉強会 ライブラリ Groovy

「Typetalk Hack Kyoto」 という nulab 主催のイベントに参加しました。

イベントの様子は上の記事にまとめられています。

Typetalk とは

nulab が開発しているチャットツールで、2 月に正式リリースされたもの。 基本はビジネス向けではあるけれど、「いいね！」 を付けられるなど、楽しい要素も盛り込んでいるらしい。

Typetalk Hack Kyoto

内容は @tksmd さんによる Typetalk の話とハッカソン (実際に Typetalk の API を使って何か作る)。

tksmd さんは 『開発現場に伝えたい 10 のこと』 の著者の 1 人。 tksmd さんが書かれた部分は nulab のブログで公開されている。

『早く行きたいなら、一人で行け。遠くに行きたいなら、みんなで行け。』 というアフリカの諺が紹介されていて、なるほどー、という感じ。

Typetalk の API について

Web からもスマートフォンアプリからも、基本的に同じ API を使用するようになっている。 また、製品で使用している API は、基本的にサードパーティに公開しているとのこと。 その理由などは次のエントリで書かれている。

Web 側とスマートフォンアプリ側での違いとしては、認証方式が違うということがある。 あと、一部 API (管理系 API) は web 側でしか使用していなくて、サードパーティへの公開もされていないらしいけれど、将来的には公開する予定とのこと。

開発者が Typetalk API を使う場合は、認証には OAuth 2 が使用できる。 次の 2 つの方式がサポートされている。

  • Client Credentials: 単一ユーザーで使う場合 (バッチ処理とか)
  • Authorization Code: 複数ユーザーに提供する場合

API についての雑感

Typetalk の API を使うのは、(HTTP 通信さえできれば) 結構簡単にできる感じだった。 テスト完了時にテスト結果を通知するボットを作るとか、わりと手軽にできると思う。

OAuth 2 を使ったことは今まであんまりないのだけれど、OAuth 2 は使いやすくて良いなー、と思った。 サービス提供側としても OAuth 2 のことをちゃんと調べておきたい。 nulab ではサーバーサイドの OAuth 2 実装として次の Scala プロジェクトが公開されているので、参考にできそう。

それと、統一された API を提供し、web からもアプリからもそれを使用する、という設計方針について。 サーバーサイドのメンテナンスコストが小さくなるし、こういうツール系の web サービスについては Ajax で (クライアントサイドで) 動的に画面を生成するというのは一つの選択肢として良さそう。 とはいえクライアントサイドが複雑になるので、そこら辺は難しいところだなーと感じた。 *1

書いたもの

自分は Groovy で Typetalk に通知メッセージを送るようなボットを作ろうと思ったけど、Groovy で HTTP 通信するのに慣れてなかったから API を叩く簡単な処理ぐらいしか公開できるものはできなかった。 Gist で公開しているので、Typetalk の API を使う処理を Groovy で書く際の参考にどうぞ。

Groovy での HTTP 通信

せっかくなので少し。

Groovy の HTTP 通信用のライブラリとして、HTTP Builder というものがある。

Apache HttpClient のラッパーなのだけれど、Groovy で使いやすいような API になっていたり、組み込みで XML や JSON の変換処理が行われたりするのが便利。

非同期での HTTP 通信などもやりやすそうな感じ。

*1:個人的にはクライアントサイドの JS のメンテナンスはサーバーサイドのコードのメンテナンスよりも難しいと思ってる (サーバーサイドがどんな感じかによっても違うけど、一般的にはそうかなーと思ってる)。

Kyoto.js #4 で 『Windows ストアアプリのつくりかた (JS + HTML + CSS)』 という発表をしました #kyotojs

Internet Explorer Windows ストアアプリ 勉強会

2013 年 1 月 24 日に開催された JavaScript の勉強会 Kyoto.js #4 で Windows ストアアプリの開発に関して発表を行いました。

発表内容概要

  • Windows ストアアプリ開発環境について
  • Windows ストアアプリを JS で開発する際に用いる WinJS などの雰囲気
  • 最近ソースコードを公開した MeteorLine というアプリの設計と開発の流れ

発表資料

参考資料

Windows ストアアプリ開発に関するドキュメントは MSDN の Windows ストアアプリのページ にまとまっています。

また、発表資料に関係しそうな内容で私が過去に書いたり公開したりしたものを以下に挙げてあります。 あわせて参考にしてください。

ソースコード

開発環境まわり

WinJS まわり

IE 10 まわり