スクールアイドルです

冷やし中華はじめました

近況報告（誕生日）

本人に自覚はまったくないが、先月誕生日を迎えてめでたく三十路に突入した。

一般的に言う IT エンジニアの定年まで５年を切ったが、業界歴が浅いので本人はまだ若手と認識しており、まだ伸びる余地があるかなと思う。

一方でコスプレはあと２年が限度かなと思う。２年というのはある種の目処で、肉体的な経年劣化がごまかせなくなった時がやめどきなのだろうなと考えている。

ところでこのようなほしいものリストがございますので是非御一考願います。

Docker で Android のテストを爆速にする話をした（Docker 実践 LT で話した） #dockerlt

タイトルは釣り。

speakerdeck.com

connpass.com

github.com

https://hub.docker.com/r/misumirize/android-remote-client/

電源ケーブル忘れて行ったのでひたすら焦ってた。

DigitalOcean に Android x86 エミュレータを飼う - スクールアイドルです が完全にこの ADB remote client in Docker のための布石で、実証ができたのでスライドにまとめて喋ってきた。

Docker がテーマなので Serverspec とか Infrataster でインフラ CI しよう的な話とか、K8s あたりでクラスタ組んだ話とか、そういうのがなかったのは意外だった。Swarm はあったけど。

多少強引にでも（今回は HAProxy 使った）ロールごとにコンテナ分割をしておくと、どれかをオンプレにするとか他所に移すとかいったときに移行がしやすくて快適ですねという感じの話だった。

あと Docker 自体がコンテナ技術の抽象レイヤー（libcontainer より前は違ったけど）なので、この抽象レイヤーを共通言語にしたほうが、どこで動かすにせよ頭に負担がかからないで楽できますねというという話でもあった。

皆様お疲れ様でした。

また近いうちにどこかで何か発表できればと。

実を言うとPHPはもうだめです。（PHPカンファレンス2015行った）

（タイトルは釣りです）
突然こんなこと言ってごめんね。 でも本当です。

２、３ヶ月後にものすごく新しい PHP のリリースがあります。それが終わりの合図です。
程なく大きめのレガシー PHP 案件が来るので気をつけて。
それがやんだら、少しだけ間をおいて PHP 5.5 サポートの終わりがきます。

当日の動向

日本語セッションがほとんど初学者向け、フレームワークの紹介、CMS の紹介だったので食指が伸びず、英語セッションにいるか、作りかけの Device Farm ラッパーアプリを書いていた。あと Rasmus は見た。

PHP の各種ツールには他言語でも同様のものがあるが（Composer に対する Bundler, Carton, npm とか）、他のカンファレンスではその使い方を毎年説明したりしないし、フレームワークとか CMS でレッツ Hello, world! とかサービス使ってハウツー CI みたいな枠も他のカンファレンスにはないので、そういうのを除外したら何を見に行くかで特に迷うこともなかった。

所感

PHP 周辺ツールチェインの進歩が停滞しているために、言語そのものはダサくない方向に激しく進歩しようとしている（これも去年からだけれど）のに、今年は停滞感をぬぐいきれていないという印象を受けた。フロントエンド系のセッションがあったりすれば、多少風通しがよくなったのかもしれない。ツールチェインが枯れて一般化すると、チームビルディングとかカイゼンでどう差を作るかみたいな話に行きがちなのかなと思った。個人的には PHP そのものの開発の話を聞きたかった。

あと、PHP 7.0 対応は今からでも取りかかれますと去年から言われていた割に、今回いよいよ RC が出てリリースが秒読みになってさも突然 PHP 7.0 対応がタスクとして湧いたかのような、えーというオーラが放たれていたのが印象的だった。

停滞感とブレイクスルーの話

今の PHP（あるいは PHP コミュニティ）にある種の停滞感を感じるのは、PHP エンジニアにとって今までのパラダイムをひっくり返すようなプロダクトが出現していないことに起因するように思われる。

確かに Laravel も Phalcon もすごいフレームワークなのだが、それによって PHP エンジニアのマインドマップが一気に書き換わるほどのインパクトを持っていない。そのような立場になるポテンシャルを持っているとしたら今のところ ReactPHP （フレームワークですらない）かなと思うが、実際のプロダクトとしてどのようなアウトプットができるかにかかっている。

イベントの規模と想定参加者層の話

内容如何を置くと、PiO を全館借りてなおかつ参加無料というスタッフさんの手腕は間違いなくすばらしい。

そしてその観点から言えば、PiO 全館を借りるに値する参加者を集めるためには非プログラマも想定参加者層とする必要性があり、そのために初学者向けの導入が多くなってしまうことはやむを得ないことなのだろう。もっとも大きいパイは未経験者と初学者なのだから。

そういう意味では PHP 7.0 の ZVAL API の変更が知りたい（主に自分）みたいな層などは比率でいえば高が知れているし、そういうのは地域 PHP コミュニティでやるか自分で調べるかした方が良いのだろうと思った。

それはさておき

スタッフの皆様お疲れ様でした。2016 年の開催も楽しみにしております。

AWS Device Farm で androidTest(Espresso, etc.) が実行できる

動機

現在各種 CI サービスが Android のテストに対応するようになり、CI サービス上で androidTest を実行する方法も共有されている。しかし、ARM エミュレータ（Android SDK がデフォルトで立ち上げるあのもっさりしたエミュレータ）なので Espresso で Activity の挙動についてテストした場合、実機や Genymotion と比べてタイムアウトが発生しやすいという問題がある。

前回の DigitalOcean に Android x86 Atom エミュレータを飼うと ADB の接続をプロキシする方法で、CI が実行する Activity のテストをタイムアウトさせないようにすることを考えた。だがここで一旦原点に立ち返り、実機を従量課金でテストターゲットとして利用できるサービスを CI に組み込めないか検討する。

AWS Device Farm とは

紹介記事は適当にググってほしい。平たく言えば実機を従量課金で借りられるサービス。

標準提供の Fuzz テスト（所謂モンキーテスト）を試してみた系やスクリーンショットを撮ってみた系の記事は多いが、注目するべきは Instrumentation Test(androidTest) が実行できることである。

つまりすでに Espresso などを使って Activity のテストを書いていた場合、Device Farm の利用を今までの Android アプリ開発フローに組み込めるということである。さらに言えば AWS 提供サービスなので他のサービスと同様に API が提供されており、aws-cli による操作も可能である。

このような視点に基けば、端末の種類の少なさは特に問題でもなく、Instrumentation Test を自動で、かつ確実に実行できる基盤として有用であると言える。リファレンス機の Nexus 5 が提供されているので、端末はこれだけでも良いかもしれない。Appium や DSL での E2E テストを各種端末で実行できるという類似サービスもあるが、それらとはカバー範囲が異なるというのが私見である。

もちろん Android 端末細分化や端末ごとの特殊な状況という問題は残るが、今回解決する問題とはレイヤーが異なるのでここでは置いておく。

AWS Device Farm の各リソースのざっくりとした説明

  • Project: 文字通り Project である。全く違うアプリをテストしても、テスト履歴が混ざってしまう程度の問題にしかならない。
  • Upload: テスト対象のアプリ、テストコードの入ったアーカイブ、テスト用データの入ったアーカイブなどのファイル情報。そのファイルがどういったものかはこちらで指定する必要が有る。
  • Device Pool: テストを実行する端末の集合。
  • Run: 実際のテスト実行。Upload されたアプリのうちどれを対象に、Upload されたテストコードの入ったアーカイブのうちどれで、どの Device Pool 上でテストするかを指定することで、テストが実行される。

作業

画面の詳細は他の AWS サービスほど複雑ではないので省略。まずはテスト対象となる Android アプリとテストコードを作る。

github.com

サンプルというほどのものでもないが、HackerNews の上位 30 件をリストで出すアプリと、初回読み込みの結果がちゃんと 30 個の View として存在するかを確認するテストを作った。

$ ./gradlew assembleAndroidTest

コマンドを実行すると、通常 Android Studio から端末やエミュレータにインストールされる .apk ファイルと、テスト実行時にインストールされる .apk ファイルが生成される。

$ tree app/build/outputs/apk
app/build/outputs/apk
├── app-debug-androidTest-unaligned.apk
├── app-debug-unaligned.apk
├── app-debug.apk
└── app-release-unsigned.apk

このうち、テスト対象として app-debug.apk を、app-debug-androidTest-unaligned.apk をテストコードとして AWS Device Farm にアップロードする。

注意するべきは Configure Test のステップで Instrumentation を選択しておくこと。これはドキュメントを読めばすぐにわかる。

また、一度作った Project は削除できないという大変男らしい仕様になっているので、この点も要注意である（サポートに問い合わせれば削除してもらえるらしい）。

さらに注意点があり、テストコードは仮に JUnit4, Espresso を使う構成（AndroidInstrumentationTest2 を継承しない、@Test アノテーションを使う）にしていても、テストクラス名を Test で終わるようにして、テストメソッド名が test からはじまるように（JUnit3 方式）しないと、Device Farm 側でテストとして認識してくれない（しかし TestCase を継承する必要はない）。Device Farm 側のテストランナーが独自なのかもしれないが、この情報はフォーラムにしか書かれていなかったので難儀した。

あとはどの Device Pool を使うか、端末ごとの環境設定を済ませると、テストが実行される。単純に androidTest を実行するだけであれば、特に細かい設定を変更するようなことはない。

所感

これまで Android の UI テスト（結合テスト）を CI することは、種々の制約による障壁が存在した。

  • 実機を USB 接続するなら Jenkins の面倒を見る必要がある
  • 実機の場合、テスト毎にクリーンな環境を作らなければならない
  • 何より実機を購入するためのコストがかかる
  • CI サービスのエミュレータではタイムアウトが発生する

特に CI のために実機を用意することは個人開発者レベルではコスト的に難しかったので、比較的少額でテストを自動実行できるサービスが出現したということはありがたい。

ただ現時点では、テスト実行をスケジュールしてから完了まで一時間程度待つことがあったり、テストの完了を通知する仕組みがなかったり、まだ粗削りなサービスだと感じられた。

また、すでに稼働していて、テストの資産がある程度存在するプロジェクトに CI 要素として組み込んだとき、予期しないタイムアウトが発生しないか、テスト実行時間が現実的かなど、他にも考慮する点はある。

DigitalOcean に Android x86 エミュレータを飼う

VPS で KVM を動かす場合のサービスの選び方（2015 年 8 月版）の続き。

動機

エミュレータの中ではそこそこ実行速度がある Android x86 エミュレータをインターネット上に展開し、CI 基盤として用いたい。

オープンソース向け CI サービスの中には Android のテストに対応していると記載されているものも存在するが、以下の問題が存在する。

  • androidTestを実行する場合には ARM エミュレータの起動が必須になるので、テストの実行速度が非常に低速
  • 画面なしでのエミュレータ実行が求められるので、UI メインのandroidTestを書く場合に実行状況を確認しにくい
  • 複数バージョンのエミュレータを展開してのテストができない
  • CI サービスの YAML 地獄辛い

なお、実行環境として、仮想化支援機構の存在する時間課金型 VPS である DigitalOcean を利用したい。

実装

github.com

software.intel.com

上記をベースに Ubuntu 14.04 LTS 上にエミュレーション環境を構築した。Itamae でプロビジョニングするのでbundle installしてnode.jsonを用意してから、下記コマンドを叩けば動く。

$ bundle exec itamae ssh -h host -u user -j node.json recipes.rb

f:id:MisumiRize:20150915001748p:plain

x11vnc でDISPLAYにアタッチできるので vnc 接続もできる。

プロビジョンが終わってからインスタンスをシャットダウンしてイメージにしておくと、次回以降の立ち上げが高速化する。

雑感

  • 日本国内リージョンがなく最寄りが多分シンガポールなので vnc が結構遅い
  • それを抜いても Genymotion の実行速度には勝てない
  • 最初は Genymotion を並べまくるという構想もあった
  • 適当に立てたインスタンスで Genymotion をアクティベートしまくったら個人開発者ライセンスの上限に達したので挫折した
  • まともに動かそうと思ったらメモリ 4G 以上のインスタンス推奨
  • つまり常時起動すると月額 4,000 円からかかるので時間課金推奨

VPS で KVM を動かす場合のサービスの選び方（2015 年 8 月版）

結論

仮想化支援機能がサポートされているインスタンスを立ち上げることができるのは、現在 DigitalOcean だけになってしまったので、 VPS サービスで KVM を動かしたい場合おとなしく DigitalOcean を使いましょう。

動機

  • 短時間だけクラウドコンピューティングリソースを使用して計算を行いたい。なお、それ以外の時間は全く使用しない。
  • 利用技術は KVM なので、そのコンピューティングリソースは仮想化支援機能をサポートしていなければならない。

調査対象

分単位での課金が可能な VPS サービス、なおかつ API によるインスタンスの立ち上げ、削除が可能なものを対象とした。

他、厳密には VPS サービスと違うが以下も調査対象とした。

リンクは省略する。

調査方法

Linux インスタンス（ほとんどは Ubuntu 14.04 LTS）を立ち上げ、 cat /proc/cpuinfo した結果から vmx, svm を探した。

調査結果

上記サービスは全て Intel Xeon プロセッサを採用していたが、そのうち 2015 年 8 月時点で Intel VT-x をサポートしていることを意味する vmx フラグが確認できたのは、 DigitalOcean のみだった。

個人の技術ブログなどでは ConoHa で立ち上がるインスタンスに vmx フラグが存在するという記述が見られたが、数回インスタンスガチャを実施してもそのようなインスタンスは立ち上がらなかった。 OpenStack のコンピュートノード側で Nested Virtualization が無効に変更されたものと思われる。

なお、 AWS のこのドキュメント では C4 インスタンスが Intel VT-x をサポートしているように一見見えるが、あくまでも E5-2666 v3 プロセッサが Intel-VTx をサポートしているだけで、実際に立ち上がるインスタンスに vmx フラグはない。