Developers Summit 2012(2日目) - shinodoggのテキトーなブログ

昨日に引き続き、今日もデブサミ行って来ました。にしても、目黒雅叙園は素敵な会場でございます↓ 　 ■【17-B-1】Continuous DeliveryとJenkinsアブストラクト川口耕介氏 　 Jenkinsの裏にある哲学っていうか。川口さんの話はロジカルでいて且つとても刺激的でした。日本語でこんな話聞けるなんてラッキーだなぁと。　　 **労働集約型から計算機集約型へ -計算機は安くなってる。性能も向上してる。 -人間の能力はそんなに変わらない。 -聖徳太子も7台まで

**Netflix -全部EC2。 -バランサでちょっとずつ切り替えていく。

**小さなスケールで並列化を奨励 -1時間とかで並列化してもコスト的にOK -今まで1ヶ月単位とかだった。(リース)

**とにかく横に並べればいい -21世紀の富豪的プログラミング

**あらゆる階層でテストの並列実行 -複数スレッド -複数プロセスで -複数マシンで

**自動化へ拍車 -EC2->RightScale -Chef, Puppet -Visual Studio -> MSBuild -今や対話モードonlyなど考えられない

**SourceOndemand/deviceAnywhere/Jenkins as a Service -プロビジョニング -分単位とか

**Jenkinsは分散ビルドに対応して5年 -100+の計算機とその利用状況を把握する基盤

**コミットの検証済みマージ -ローカルの仕事がサーバに移った？ --コミットしないとJenkinsにテストしてもらえないけどコミットがダメだと… --サーバでテストする前にローカルで -大規模プロジェクト --開発者が問題のあるコミットをする確率が一定だと人数が増えれば触れるほど‥ -Jenkinsは --開発者はブランチにコミット --Jenkinsがブランチをテスト --JenkinsはブランチのテストがOKだったらTrunkに --利点 ---間違いしてもOK。気軽にコミット ---テストはサーバで。環境依存とか大量データとか。 ---運用とかに効果的。いちいちローカルにテスト環境作りたくない ---テストは非同期に走る。頭の中からテストの待ち時間をなくす -やり方の詳細はWeb+DBプレスで。

**デプロイメントの自動化 -ビルドができたらどこかで動かそう --開発者だけでなく、QAやビジネスの人も動くものが見える -ビルドパイプライン --徐々に大掛かりなテスト。失敗したらそこでストップ。無駄なテストをしない -Promoted Buildsプラグイン --プロセスフローではなく状態遷移を考える --条件をいろいろ入れられる。人間のオーソライズや何時間継続して動いた、とか。 -昇進モデルの利点 --とにかく非同期に。ウォーターフォール的に考えるとシリアルになりがち --パイプラインを途中からリラン出来るように --状態をチーム間で引き継ぐ。 ---チームとチームを横断した自動化 --トリガになるイベントはなんでもOK

**Tracability. 追跡を可能にする -ビルドやオペレーションに問題にあったのであればどうして？というのを細かく --Dev:コミットID、QA:バグID、QA:テスト実行記録、、 --Jenkinsはみんなを一つに繋ぐ -どのビルドがどのテストで失敗してるのか

**バイナリインテグレーション -バイナリをリビルドしない --時間を節約するだけでなく、環境による差異の排除

**分散バイナリリポジトリ -コミットと共有の分離。分散VCS。 -同じことがバイナリについても言える

まとめ -あらゆる局面で自動化が進んでいる -自動化の島がつながる。複雑な自動化を簡単に。 --開発者と開発者。開発者と検証者。 -すなわち継続的デリバリ -今までの三種の神器 --ビルドスクリプト、バージョン管理、自動化されたテスト -これからの三種の神器 --デプロイスクリプト、XaaS、クラウド -計算機能力は湯水のように。とにかく横に。 -計算機能力の新しい活用の仕方　　 ■【17-A-2】仕事のバトン、渡っていますか？プロジェクト管理におけるコミュニケーション基盤作り　鈴木雄介氏 　 JIRAの話や現場の生々しい話が聞けるのかと意気揚々としてたのですが、教科書的な内容が多くて刺激は少なめでした。　　グロースエクスパートナーズ -SIer, Atlassianの代理店

**明確な事と曖昧な事が混ざり合う -全部決まってるわけじゃないけど、全部決まってないわけじゃない。

**Excel最強 -自由にカスタマイズ、フィルタ、ピボットなど -実質デファクト。現場でExcelが入ってないって言われる事はあまりない

**仕事は1人じゃ完結しない -成果物を分解してタスクにしてプロセスとして並べていく -テスターがバグを発見、エンジニアが修正、deploy屋が修正版をリリースする -エンジニア的にはもう治ってる、テスト的にはいつ直ったの？deploy屋はどれを？？ -仕事のバトンがちゃんと渡ってない -Excelだけでは足りない --ファイルを配ってーっていう形なので非同期にやるには難しい。マージが大変。

**JIRA. 課題管理実践 -適用への道のり --テスト、バグ発見、修正、デプロイ、再テスト --JIRAにはバージョンっていう考え方が既に入ってる --JIRAにはリリースというステータスがある --バージョンとかコンポーネントをうまい事使えていない場合が多い -テスト以外での適用 --顧客とのQA管理、オフショア先やチーム間など。

**事例 -実装管理要のJIRA、QA管理用のJIRAを分けている --秘密を担保するため。契約関係とかあったり。 --今日出来てるけど、明日って言おう、、とか。 --全て開示ということであれば一個で良いかと。

**管理のコツ -起票のルール --気遣い重要。事実を書く。 --あくまでコミュニケーションツール -プロセスを決める -気軽にチケットを切り過ぎるとか、粒度とか、チェッカーを置く。 --誰がクローズするのかが重要

**JIRAの良いとこ -セキュリティとかマルチプロジェクトとか権限管理とかが容易

**注意点 -チケット駆動開発はレベルが高い。難しい。 --時間軸のバランス関係が見えづらくなってくる。 --確定していることに無理に使う必要はない。Excelで十分。 -プロセスやアーキテクチャが安定しているとハマる --運用フェーズとかにイイんじゃない？ --問い合わせベースとかだと。

**アンチパターン -計画的なものはExcelやMS-projectには勝てない -基本的にはデフォルトの設定でイイはず -タスクの階層化はやり過ぎない --相当明確じゃなければ使わないこと -メールや電話での内容もJIRAに登録する --ステークホルダーの啓蒙 --JIRAだけじゃ問題は解決しない

課題管理より時間管理が重要 -WBSなき課題管理ツールは失敗する　　 ■【17-A-3】スマートフォンにおけるHTML5実装の最先端紀平拓男氏 　短い時間の中で中身はとても濃い感じで、非常にためになりました。特にJavaScriptのメモリ周りの話は、そこでもやっぱりそうなのね的な。。　　紀平さんはシリアルアントレプレナー -HTML5によるFlashPlayerのExGameを制作。 -ガラケーのFlashをそのままHTML5で使える -DeNAに評価してもらえたのでJoin

**今回はスマホのみ -HTML5はとにかく広い -PCの話はなし

**HTML5=HTML+JavaScript -豊富なAPI --ドット単位の描画。Canvas --ベクターグラフィックスを扱えるSVG --アニメーションなど豊富な表現力のあるCSS3

**描画能力の向上 -曲線のある図形を描画できる -アニメーション能力も高い -HTML5でFlash並みのが出来る

**ExGameのデモ -FlashとHTML5の比較 -怪盗ロワイヤルのデモ動画。見え方ほとんと変わらない

ApplicationCache機能 -一度アクセスすれば二度目からは機内モードとかでも動く localStorage -スマホ端末の中にアプリケーション特有のデータを保存

**アプリにかなわないところ -3D,音楽,速度 --3DはOpenGLが使えない。WebGLってのがあるけどまだ。MSがWebGLは採用しないって言ってる --音のタイミング調整が非常にシビア ---iPhoneは画面がタッチされたタイミングのみで音楽の再生が可能 ---WindowsPhoneとiPhoneは同時に2つの音を鳴らせない -速度 --描画が遅い。JSの実行速度が遅い

**描画 -Canvas:ラスターグラフィックス -SVG:ベクターグラフィックス --Android2系ではサポート外 --Canvasで代用可能 -CSS3:変形やアニメーション

**Canvas -常にiPhoneの方がAndroidより遅い -iOS4 --drawimageが遅い。小さいタイルを沢山やるようなヤツは死亡 --オンメモリキャンバスを使ってdrawimageを減らす --Canvasの上にDOM構造のオブジェクトを載せるとメモリから合成してもっかい貼り付けるような動きをするので重い -iOS5からGPUサポート -使いこなせれば早いけど、そこまで行くのが結構大変 -互換性はよい。PS Vitaでも動く

**CSS3 -悪女のような存在。とっつきやすいがいきなり裏切る。 -GPUサポート -同時に動く物体すが増えると急激に重くなる -Androidでブラウザやバージョンに互換性が無いのが多い -一枚もののアニメーションとか同時に動くものが少ない時は良い -葉っぱが落ちてくるようなのは全体を1つのオブジェクトにするような形で

**JavaScriptが重い -JITが重い --本来重いはずないんだけど。。 --eval, ループの中でclosureの生成とか -GCが重い --AndroidにおいてFullGCが走ることがあって、シャレにならないほど止まる。2〜3秒とか --格闘ゲームだと60フレーム。やられ放題。 --V8は世代別GCを利用しているので、なるべく早いうちに参照を切る --iOSはメモリが足りなくなると落ちる ---以下に回避するかが大事 -何度も使うのは最初にメモリにロードしておく -上限の決まっているオブジェクトは初期化時に上限まで確保 --オブジェクト生成の回数を減らす --敵の数が100以上になることはあまりない。数十とか決めておけば。

**メモリ -なんとか実機上でのメモリ利用量を確認する -iPhoneSimulatorは信用出来ない。。 -UIWebViewも信用できない。。 --この中で動くJSはJIT コンパイラじゃない -JailBreakして確認 --リスキーだけど。。 --topコマンドでメモリ使用量を取得とか。 --非常に役に立つ。 --100MBくらいにメモリの使用量を抑えるようにすること

**ExGameなどでは自作プロファイルを仕様 -関数単位でcount,total,selfを取得 -どの関数のプロファイルを取るか指定。ビルトインAPIも -プロファイルのタイミングを設定できる(取りたいところで取れる） -結果をサーバに送信

**実機でのデバッグ -JsConsole --実機上でJSのコンソール -console.log --iPhoneでも設定を操作すれば参照可能 --console.errorをデバッグ用に使う。赤文字で出てくるからトレースしやすいｗ

**ngCore -HTML5の上で。 -NinjaLoyal --本邦初公開

**インストールの時代は終わる -歴史は繰り返す --ネイティブやアプリからのパラダイムシフト -Gmailとかで世の中変わってきた

長いスパンで自分なりに考えて行動する -10年前のJS --ひどいもので、誰もあれでOS作ろうとか思わなかった　　 ■Open Jam 日本Springユーザー会 　小じんまりした会場でSpringの今昔的な話。 Springユーザー会は3週連続で初心者向け勉強会とかやっててすぐに定員オーバーになったりしてる。会場にいた人も濃そうだったし、まだこれからあるんじゃないかなぁとか思ったりも。。　　マイコミジャーナルに寄稿したのが確か2年前 -雑誌とかなくなっちゃったし -Springってオワコン？ -いや、そんな事はない

**All in One -SpringFramework --DI&AOP --シンプルなPOJOで扱おうっていう思想

**SpringSource -2009年8月にVMwareに買収される -Build, Run, Manage

**Build -SpringFramework,Groovy/Grails,STS,WaveMaker(Ajaxアプリを作れるIDE)

**Run -VMwareは仮想化とクラウドの会社 -vFablic --Apache,Tomcat,RabbitMQ,GemFire(インメモリデータキャッシュ)

**Manage -Hyperic --Javaのプロセスの中でメモリがどう使われているか？

**Spring3.1 -目玉はCache -SpringCache --Cacheable/CachePut/CacheEvict

**これからの話 -クラウド -スマホ普及が著しい -Spring以外 --Seasar2 --JavaEE6(アノテーションベースでOK。シェア高い。サクサクな感じ) --play!(コマンドベースで) -Spring --SpringRoo,SpringSurf

3週連続Spring入門ってのをやってる！ --第一回 2月13日 --第二回 2月20日 --第三回 2月27日　　 ■【17-B-5】アジャイルマニフェストディケイド　角谷信太郎氏 　相変わらずいい意味でいっちゃってる感じの講演でした。俺もエイヤーーーー！(でしたっけ？ｗ)ってヤツ作りたいです。。　　永和さんはRuby屋募集中

**角谷さんはRuby エバンジェリスト

**アジャイルサムライを会社のみんなで訳した -アジャイルサムライトレーニングをやる

**2001.2アジャイルマニフェスト -不正義->eXtreme Programming --KentBeckが建築家のアレグザンダーの〜

**アレグザンダー -少しずつ -人間の閑静に -繰り返し

**アジャイルマニフェスト/デブサミ -ディケイド -10周年 -仮面ライダーも10周年 --カードに合わせて誰にでも変装出来る

**Nature of Software -人とソフトウエアあいだに価値がある --動いてるだけじゃだめ。人から使われてないと。 -システム全体を構成 --ソースコードだけじゃだめ --ハード、文書、運用 -変更に対応出来ることが求められている --だからソフトウエア --育てる、技術的負債 -ソフトウエアが目に見えない --使ってみないと。

**変更に対応できること -Programming as theory building --スキルを備えた人の営み --文字列を並べるだけの簡単な仕事じゃない -コードはドキュメント

**自然なソフトウエア -Free/OpenSource -BazaarStyle -Hackers

**アジャイル -You can't do Agile --名詞じゃなく、形容詞。 --角谷さんは5年前から言ってた -Agility is degree -いろんなフレーバーがある(XP,Scrum,,,) -Gemba Ride -スクラム --軽量、理解が容易、習得は非常に困難 -似たケースはあるけど1つとして同じ現場ない --現場の中で考えなければならない -アジャイル宣言の背後にある原則

**アジャイル開発をやれない理由

**Github -永和さんは組織的なランキイングで88位とか。Zyngaに負けてるけど。

**内側の質 -全部しがらみとっぱらったらスゲーアプリ作れるの？

**ユニットテスト -変更を容易に受け入れられるようにするため -ただ書けばイイってものではない

次の10年に向けて -みんなAgile知ってるし、セッションや本もたくさん　　 ■【17-B-6】Building scalable web apps Christopher Stolt 氏 　早口な英語だったのと、Heroku使ってる人は知ってるよー的な感じだったですかねぇ。。ログはファイルじゃなくてストリームとかってら辺は自分には興味深かったです。　 ChrisさんはHerokuのサポートマネージャー

**Heroku -PaaSですよん〜

**Building Modern Web Apps -Codebase --Stored in an SEC(git). Configは含めちゃだめ -Dependencies --3rd party libraries, declared in a manifest, -Config --Connection Strings, Stored in Env Vars -BackingServices --Databases,Caching,Queue -Build/Release/Run -Processes -Logs --Logはファイルじゃなくてストリーム --Logging as a Service

**The Heroku Way -Heroku Platformがあれば、アプリケーションの開発だけにフォーカスすればイイ -git push heroku master --bundleなんちゃらで依存性解決してー -DEMO --gemの中身とか -アプリが無いところから --git initi --git addして --最初のcommit --heroku create して。アプリの名前はdevsumi2012-demo --heroku config:push ---.envがwritten されましたよ、と。 --pushしたあと、scale worker=1とか。 --実際に動かしてみるとデブサミのTwitterのつぶやきが取得できます、と。

コミュニティのメンバー募集中　　 ■【17-D-7】実践Android Developer Testing 吉澤毅氏 / 持田真哉氏 / 長谷川孝二氏 / 松木晋祐氏 　サンフランシスコでAndroidアプリ作ってた時にまともなテストが出来てなかったので、勉強させてもらいに行きました。非常に参考になる話の数々。ありがとうございました。　 Androidテスト部の紹介 -Androidのテスト全般について -テスト祭りとかやってる -400人以上のメンバーがいる -Googleで"テスト部"で検索すると一番上

**体制 -ソースかつチーム --レイヤ低め -ハッピーターン --レイヤ高め -Androidのバージョンの名前がお菓子なのにちなんで。。

**環境 -スポンサー(OpenStream) -クラウド環境(KDDI)

**DeveloperTesting -V字も出るで言うところの単体テストと結合テスト

**テスト自動化ツール -DEMO --Robotium ---Seleniumみたいなヤツ --Monkeyrunner ---外から操作する ---普通のゲームとかも自動操作できるので(ryｗ -いろんなフレームワーク --NaitiveDriverはGoogle製。 ---ちょっと面倒 --FoneMonkey ---Gorilla Logicって会社

**テスト自動化が不利なところ -テストの記述のコスト -UIの変更が多く再利用できない --ちょっとUI変わっただけで全部書き直しはちょっと、、

**上層のテストは無理なく計画的に -下層のテストをより厚く！

**下層。ユニットテスト -Activityだけで出来ているレガシーコードアプリにテストを付与 -ActivityのonCreate --レイアウトのレンダリング --メッセージ処理C --データ処理 M --Viewの表示 V --リスナーの割り当て V/C -モデルが分離できていないActivityコード --ロジック処理、永続化層へのアクセス -Androidの永続化層 --SQLite3, Network(Twitter,Facebook),加速度センサー,GPS -DBの状態に依存するテストコード --setUpメソッドでデータベースを初期化しよう --ActivityInstrumentationTestCase2 ---onCreateとonResumeまで実行されてしまう ---異なるものを比較。 ---instrumation.xxxonCreateで強引に呼んでみる ---スレッドが違うって起こられる ---Activityと同じスレッドでonCreateを呼び出す -ModelのテストをやりたいのにThreadやライフサイクルとか考えるの面倒 -ActivityからModelを分離しる

**Modelの分離の詳細 -SQLiteまわり --setUpメソッドでSQL文を記述 -Fixtureライブラリ --DBUnit,ActiveRecord,Test::Fixture::DBI,,, --Androidは？->無かったので作った -SQLiteFixtureLibrary --テストデータをファイルから。テスト専用DBを作成 --テスト専用データベースの自動作成、テストコード読み易く --公開APIからテストプロジェクトへのリソースにアクセス出来ないので --リフレクションで無理やり。。。 -Migration --スキーマ更新のDDL流すのを実機でやろうと思うと、、 --古いのインストールしてから、新しいの入れてーってやらないといけない --サーバ側だったら運用側でメンテナンスとか出来るけど --クライアントはいつマイグレーションが走るかってのを保障出来ない --Aさんは毎回更新版を入れてくれる、Bさんは3回くらいすっ飛ばして更新する -AndroidEmulatorPlugin --自動ビルド、自動テスト、エラー通知、APK生成 --Android フラグメンテーション問題 ---解像度、OSバージョン