GitとJenkinsとSTF(仮) at Frontrend Vol.6

/img/photo/2013-11-17.jpg

Frontrend Vol.6に参加してきた。
感想と軽くメモした内容をつらつらと書いておく。

Frontrend/06 @togetter


今回はGit・Jenkins・Androidのテストツールといった内容。

フロントエンドからちょっと外れてる様に見えるかもしれないけど、GitとJenkins(CIツール)はフロントエンドを続けて上でも必要なツールだと思った。

いつやるの?Git入門 @matsukaz

今まで聞いたGitの解説で一番わかりやすかったかも。
pull fetch reset rebase とかのコマンドはきちんと理解できてなかったのもあって勉強になった。

特にrebasemergeはわりと混乱してたのがスッキリした。
ブランチの操作も詳しく丁寧に説明してくれててすごく良かった。
セッションで紹介されてたブランチの操作を学べるサービスも遊び感覚でやってみようと思う。

Learn Git Branching

以下メモ


Gitのメリット

  • commitの対象管理が簡単
  • commitした内容を修正できる
  • pushとfetch以外の操作がローカルで完結してる
    • 最新の状態をローカルに反映しておけばオフラインでも作業できる
  • 効率よくデータを保持
    • 圧縮したり色々

やはりSubversionと比べるとGitのほうが色々捗るなーと感じる。

Gitの3つのデータ領域

  • 作業ディレクトリ(ワークツリー)
  • ステージング・エリア(インデックス)
  • Gitディレクトリ

作業ディレクトリ <-> ステージング <-> Gitディレクトリ の3つの振る舞いを把握すればGitは怖くない。
ファイルを追加・変更したりコミットしたりチェックアウトしたりと、何をしたらどこにどうデータが反映されていくかを理解すれば各コマンドの動きも理解できそう。

mergeとrebase

  • 適材適所でつかう

別のブランチから変更を反映するっていうくくりでは一緒だけど、ワークツリーがどう動くかはちゃんと理解しておくといいのかなと。
発表資料を見ればつかめると思う。

リンク

フロントエンジニアとCIとテスト @st44100

Jenkinsなお話がメイン。フロントエンドでCIツールを使う利点、CIツールを使った上で他のエンジニアとどう絡むかとか「Jenkins使ってみようかな」と思わせる内容だった。
特にJenkinsのビルドの成果物を利用することで”成果物から属人性を排除する”っていう考えは大事だと思った。

Jenkinsになにをやらせるかっていう点で紹介されてた各種ツールも、Jenkinsを使わないとしても覚えて(使って)おいて損は全くなさそう。
Gruntを使ってる人ならそのタスクをJenkinsにやらせるだけなので、無理なく導入できるなと感じたし自動化を一歩先に進められるんじゃないかなと思う。

以下メモ


インストール

  • brew install jenkins

簡単。

成果物の管理

  • 個人の環境の違いでビルドの成功・失敗が変わることがある
  • Jenkinsのビルド結果を成果物にすればその点をクリアできる
    • 属人性の排除

ある特定の人の環境でしかビルドできないとかあったとき、その人がいなくなったら誰もビルドできないといった事態にならないように。

テスト

  • 単体テスト
    • Jasmine
    • PhantomJS
  • 複合テスト
    • CasperJS

ページのSSをとる

  • CasperJSで自動で全ページのSSをとる
    • 修正確認の時とかにブラウザで確認する時間をある程度短縮できる
  • wraithでSSのdiffを取る
    • 修正前と修正後のSSのdiffを取って表示してくれる
      • 遅いのが難点
      • 一定間隔で裏で自動実行させておくとかするといいかも
      • PhantomCSSでモジュール単位で比較すれば早くなるかも

GruntでCasperJSのタスクを設定しておけばJenkinsの成果物としてSSが撮れる。Jenkinsを使わないとしてもCasperJSは導入しておきたい。

リンク

Android端末の動作検証の課題を解決: STF @gunta85 & @sorccu

先日行われたFrontrend x Chrome Tech Talk Night ExtendedのLTで紹介されてたAndroid検証用ツール「STF(仮)」の紹介。

このツールとにかくすごい。いまフロントエンドエンジニアがAndroid向けの開発に対して抱えてる不満や悩みを全部解決しちゃうんじゃないかとまで思う。

OSSで少しずつ機能を公開する予定らしいのでフロントエンドの開発効率が飛躍的に向上する日も近い。ありがたや

以下メモ


Androidについて

  • 国内250種類
  • 世界12000種類…

これにOSのバージョン違いを考えると…いや、もう考えたくないやめた。

バグバグバグ

  • 各メーカーが独自機能と独自バグを盛り込む
    • エミュレータ遅い
    • エミュレータで再現不可能
    • GENYMOTION
      • 実機と違うし

どうする?

  • 物理的に操作
  • ChromeのUSBデバッグ?
    • 2.3がシェア30%~40%ある
    • Chrome入らないしそもそも標準ブラウザと違う
      • だめだ

つらい

  • 充電
    • 気づいたら切れてるし時間かかるしつらい
  • 操作方法
    • 違いすぎてつらい

STF(仮)の出番だ

  • ブラウザから全端末を検証する

  • URLを開く

    • 標準ブラウザ・Chrome・WebViewどれでも指定できる
  • リモート操作
    • レスポンスはやい。3Gでも全然いけてる
  • SS撮れる
    • ページ全体も撮れる
    • SSにURLが発行される
      • 他の人にURLコピペで送れる
  • CPU・GPUの負荷状況が見れる
    • マルチコアでコア数減らして動作してるとかリアルタイムでわかる
  • 転送速度のグラフ表示
    • USBの転送速度。2M~5Mくらい
  • 任意のJavaScriptの実行速度計測
    • 速い順にソートしたりできる
  • ローカルページをリモート端末で表示
    • リバースポートフォワーディングしてlocalhostとかのページをリモートの端末で表示できる
    • 3G回線でもOK。同一ネットワークとか気にしなくてもいい
  • weinreを使ったInspect
    • リモート端末に対してDevToolsみたいにリアルタイムでDOMとかCSSをいじれる
  • ハードウェアボタンの制御
    • 音量の増減とかできる
  • 端末リソースの確保と解放
    • 検証したい端末にチェックするだけ

書ききれない。

デバッグする端末はSTFサーバ?につないでおくことでどっからでも操作できる。それこそ海外でも大丈夫らしい。

会社が保有してる端末を使って開発する場合、誰かが端末を占有したままで、使いたい端末を使えるまでに時間がかかるなんてことはザラにある。
端末が手元に来ても充電が切れててすぐ使えなかったり、充電ケーブルどこいったみたいなこともよくある。

複数のAndroidで画面表示を確認したいだけなのに物理的・ソフトウェア的な色んな要素が邪魔してほんとにめんどくさい。時間の無駄。

STF(仮)は色んな問題を解決してくれると思う。機能的にもすばらしいし、目指してるヴィジョンみたいなものもすごく共感できる。グンタイケメン。

今まで無駄に費やしてた時間を短縮できるようになればリリースのサイクルを早めたり、もっと注力したいところに時間を使えるようになる。

すっごく期待してる。

次回開催を期待して

内容すごく良かった。

GitもCIツールもちゃんと使えるようになっておかないと置いてかれる気がする。

Androidに関しては思うところがいっぱいあるけどSTF(仮)応援してる。

次回開催も(ピザとビール)期待してます。