yo_waka's blog

418 I'm a teapot

出戻ったワイワイ

Github Pagesで書いてたけど思い立ってはてなブログに戻した。 インポートスクリプト書いたものの、記事数多くないしMarkdownだし手でコピった方が早かったんじゃという気がしてきた。

ReactiveCocoa Tokyo

ios

先週になりますが、「ReactiveCocoa Tokyoというイベントがあり、そこでfreee社での導入の経緯やMVVMでのReactiveCocoaの使い方について話してきました。

ReactiveCocoaは役割上ロックインされがちで、そこをなるべくゆるやかに導入していくにはというのが ninjinkunさんの発表に対して、ロックインされると各レイヤに統一感出ていいよと、対比ぽい感じができたのでよかったです。

ReactiveCocoaの魅力は、MVVMのコンポーネント間のインターフェースを統一できること、またアプリ固有の非同期処理や入力処理を統一的なインターフェースでラップできるフレームワークとして使えることです。 自分が知る限りでは上記のことをやるならReactiveCocoaが一番よくできていてまた開発も活発だと思います。

@ikesyoさんに懇親会で聞いた限りだと、Swiftブランチは実運用にはもうちょっと時間がかかりそうだなという印象です。でも粛々と開発は進んでいるようなので期待。

終わった後、同日開催のiOS/Swift勉強会@ヤフーをピザとビール片手にみんなで眺めたというのもちょっと新鮮で楽しかった。 会場の迷惑にならないので思う存分ワイワイできるw

freee社で50人規模の勉強会を開催するのは初めてだったのですが、当日欠席する人も思ったより少なくてよかった。これをきっかけにReactiveCocoaの導入事例が増えるといいなあ。

大阪から駆けつけてくれた @ikesyoさん、主催の @ninjinkunさん、社内でいろいろ調整してくれた @yonekawaさん、トップバッターで話してくれた @tinpayさん、LT発表者の皆様ありがとうございました!

f:id:yo_waka:20141112031225j:plain

f:id:yo_waka:20141112031242j:plain

@ymrl 写真拝借しました。当日はありがとうございました。

volley(サブプロジェクト)のbuildToolsVersionをafterEvaluateで上書く

Android StudioがBetaになったので、0.8.2に上げようとしたらモジュールのビルドでハマった。

Android Studioのバージョンを上げるときは、build.gradleを弄る時でもある。 Betaに上げるからには最新版のGradleプラグインAndroid SDKコンパイル&ビルドできるようにしたい。

// project/gradle/gradle-wrapper.properties
distributionUrl=http\://services.gradle.org/distributions/gradle-1.12-all.zip

// project/build.gradle
buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:0.12.+'
  }
}

// project/app/build.gradle
android {
  compileSdkVersion 20
  buildToolsVersion '20.0.0'
}

しかしビルドエラー。
ルートプロジェクトのGradleプラグインのバージョンを0.12に上げると、buildToolsVersionが"19.1"以上でないとビルドできない。
僕の環境ではvolleyをモジュール(submodule)として組み込んでいて、compileSdkVersionとbuildToolsVersionがこのように指定されている。

// modules/volley/build.gradle
android {
  compileSdkVersion 19
  buildToolsVersion = 19
}

volleyのソースを見る限りbuildToolsVersionを20に上げても特に問題なさそうなので、何とかしてビルドが実行される前にandroid()の中身を上書きしたい。
と思って、Gradle User Guideを眺めていたら、Project.afterEvaluate()というものを見つけた。 Project.afterEvaluate()は、そのプロジェクトのビルドスクリプトが評価された後に実行されるらしい。まさにやりたいことと一致!

Gradleで分からないことがあれば、Gradle User Guideを見るのがオススメ。 Gradleのバージョンごとに用意されているので、使っているものに合わせて見るとよさげ(ちょくちょく変わったりするので)。

subprojects { subproject ->
  afterEvaluate {
    if (subproject.plugins.hasPlugin('android-library')) {
      android {
        compileSdkVersion 20
        buildToolsVersion '20.0.0'
      }
    }
  }
}

これで、モジュールとして組み込んでいるライブラリプロジェクト全てのcompileSdkVersionとbuildToolsVersionをアプリのそれと合わせることができる。
もし特定のプロジェクトだけどうしても"19.1"でビルドしたければ、プロジェクトごとに指定すればおk。

project(':modules:volley') {
  afterEvaluate {
    android {
      compileSdkVersion 20
      buildToolsVersion '19.1'
    }
  }
}

Android meets RxJava

少し、いやかなり前に渋谷Javaで「Android meets RxJava」というタイトルでLTしてきました。 スライド上げるのが遅くなってすいません。。。

freeeのAndroidアプリの開発前にチーム内で考えていたのが、テストの書きやすさを考慮するとどうしてもFragmentとAPIのやりとり含むビジネスロジックを切り分けたいというところで、 ViewController/ViewModel/Modelを上手く疎に分けられる仕組みが必要でした。

先行して開発していたiPhone版では、ReactiveCocoaを導入して上手くいったこともあり、FRPが出来るJavaのいいライブラリはないか探していたところ、上手くマッチしそうだったのがRxJavaでした。
RxJavaのObservable、Subscriber、Func/Actionを使うことで、API呼び出し/モデルへの変換/画面への表示を上手く切り分けることが可能になります。 また、ViewModelのプロパティをFragmentからバインディングすることにより、データの状態をFragment側で管理する必要がなくなります。

Fragment側でデータの状態を持ってしまうと、いざそのテストを書く際にUIが必要になるので非常にめんどくさい。ViewModelまでで完結できればユニットテストだけでOK。 とはいえ、スライドにも書いてますが、ビジネスロジックがそこまで複雑でなければEventBusなどでやり取りするのもアリだと思います。

こういうFRPなライブラリをクライアントアプリで使うと、コアな部分で使うためどうしてもロックインを防げないのがデメリットです。 Reactive Streamsによる標準化に期待。

Hubotを導入したらレビューの敷居が下がった話

dev

ウチの会社ではHipchatとGitHubを開発のコミュニケーションの中心にしている。
だんだん人も増えてくると、以前よりプルリクの数がそれだけ増えて、レビューで1日終わってしまう人がでてきた。

昔から仕様を知っている人にレビューが投げられがちで集中しやすいとかは他の会社でもよくある話しだと思う。
レビューは自分のタスクと同様に大事だけど、それで自分のタスクが全くできなくなったり、新しく入ってきた人がレビューする機会を失うのはあまりよくない。

というのもあって、Hubotを立ててみてプルリクのレビュアーをランダムで振れるようにしてみた。
Hubotというのはご存知Hipchatのbotとして動くプログラムで、botにコマンドを指定してリモート実行させたり、特定の文字列に反応させたりということがHipchat上でできる。
CoffeeScriptスクリプト書けるのでとてもお手軽。

sushiという名前のHubotを立てて、GitHubのプルリクのURLをbotに投げるとランダムでレビューお願いします!とメンションを飛ばすようにしてみた。

xxx   | @sushi https://github.com/AAA/BBB/pull/999
sushi | @yyy オナシャス! https://github.com/AAA/BBB/pull/999

GitHubから流れてくるログから自動でメンションを飛ばさないのは、大きな機能追加などは特定の人にレビューしてもらいたいことがあるので、そこは自分で打つ。assignまで自動でできる美しいんだけどそこまではまだ出来てない。
誰にレビューしてもらおうかなと考える必要もないし、レビューの偏りも結構解消されていい感じになった。
スタートアップはどんどん人が増えるので、新しく入った人にもレビューが振られることで早くプロジェクトになじめるとかそういうのは大きいと思う。

何より、みんなが楽しんでレビューを振れるようになったのがよかった。
pushされたブランチを見て、「俺に来るな、来るなよー・・来たーマジかorz・・」とか振られる側もドキドキできて楽しい。

ランダムレビュー以外にも、みんなの名前打ったりするとその人のおもしろ発言が流れたり楽しい感じになってる。

これまで自分のローカルで動かしてたのでw ちょっと旅行に行ったときは動いてなくて寂しかったと言ってもらえたのは嬉しかった。
普段の開発フローに定着できたので、ちゃんと運用していこうと思う。

方針を決めて守ったり対面のミーティングでなんとかしていけることもあるけど、動く仕組みを作ることで一段上の解決ができることもあるよなーと1つ勉強になりました。