デブサミ 2014 1日目に行ってきました。
すでにまとめができてるようで関連資料などはそこで公開されそう。
デブサミ2014、講演関連資料まとめ
自分が聞いたセッション（リンクはTogetter）
全体の話
全体の傾向として、インフラ、テスト自動化、開発を通してのプロセスに関わる話が多い印象を受けました。
数年前はフレームワークや最新技術などのセッションが多く、少し前はクラウドの話が多く、これら前の技術・仕組みが当たり前となっている前提で、次のステップへ進んで行く話なのかなと感じました。
クラウドやCIは当たり前で、それをどう組み合わせて自分たちの開発プロセスをスムーズにしていくのかという点が中心な印象。
個々のセッションの話
セッション資料はいまのところすべて公開されているようなので、自分が感じた点を中心に記載しています。
【13-B-1】サーバプロビジョニングのこれまでとこれから
講演資料（speakerdeck）
serverspecなり、Chefなり、dockerなり今インフラレイヤーでトレンド周りを押さえたセッションで一発目としては興味深く聞けました。
会場アンケートで、Puppet、Chefを使用したことがあるかのアンケートだと、
- Puppet -> 数人
- Chef -> 3〜4割手を挙げた
という感じ。
Chefはホントにもう流行ってるようで、まだきちんと取り組めてない自分はちょっと焦る。
ただし、話の中でImmutable（Disposable）なインフラ、作って破棄できる環境というのが出てきてこちらのほうが自分は興味深く聞けた。
既存の動いているサーバに変更を加えるのではなく、全く新しいサーバを構築して、サービスの切替はロードバランサーなどで切り替える。
成功したら元のサーバは破棄（Dispose）、失敗したら元のサーバに向き先を戻す。
-> Blue-Green Deploymentという考え。（AWS EC2などによって容易になってきている）
Chefはかなり気になっているけど、環境を作った後に、差分でどんどんアップデートして行ける（メンテできる）ものかなという懸念があった。
学習コストが高いと聞くし、あまり難しいことまでこだわりすぎるとハマると思っていたので、シンプルに使える構成に持って行くのはたしかになるほどなぁと。
サーバにImmutableであることの制約をいれることによって、同じツールで常に同じ状態を維持するという敷居が下がるのかなという期待が持てる気がした。
後半に出てきた、Dockerは直近で試してみたいものだったので、デブサミという場でも出てきてちゃんと広まってるんだなと思って試してみたい意欲が上がった。
【13-B-2】グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～
講演資料（speakerdeck）
引き続きChefに関連するセッション。
こちらでも会場アンケート
- Chef触ったことある -> 4割くらい
- Chef使ってる -> 1割くらい
という感じ。
こちらでもMutable、Immutableの話が出てきていて、こちらだと、ChefはMutableだと相性がいいとのこと。
複雑で大変そうと思ったら、グリーではChef Soloをベースにラップしたツールを内製して使ってるよう。（Chef ServerはSPOFなり、Erlang人材不足などによりで採用しないことになったとのこと）
セッション聞いてると、Chefでなんでもかんでもやるのは厳しいかなとなんとなく思った。
ある程度、したいこと、やることを限定してやらないと収集つかないような印象を受けた。（それを乗り越えれば幸せになれるのかもしれないが、そこに至るまでが相当ハードル高そう）
前述のImmutable前提のように割り切ることができて、新規からのべき等性を確保するという割り切りができるならよさそう。
【13-B-3】社内システムの構造と設計、実装のはなし
講演資料（slideshare）
社内システムほど、他システム連携を考えようというのがすごくいいなと思った。
連携するのはやっぱりJSONが便利。
社内システムは長期運用が前提になりがち。
欠点や問題点があっても、長い間ほっとかれるものもある。
ドキュメントは、風化していくので、データ自体が人に見やすい形になってるのはとても大事。
たしかによっぽどカリカリなパフォーマンスを求められない限り、わかりやすいもののほうがいい。
触る敷居が低いというのはシステム連携を考えるにあたって無視できない要素だなというのを再認識した。
JSONなどのAPIを提供する際には、view側にも仕組みを持たせすぎるよりも自身のviewからもそのAPIを叩くようにした方が修正が少なくてよい。（クライアントjsでそのAPIを叩く方式等。）
「社内システムほど試しやすい場はない」
まさに。
【13-A-4】新卒エンジニア研修ですべきことできること
講演資料（speakerdeck）
個人的には本日一番、ためになった（ある意味耳が痛い）セッション
「自走できるエンジニア」
これができるエンジニアを育てることはやっぱ難しいと再認識。
出来る人は勝手にできるようになるけど、そうじゃない人を引き上げるというのは、やはりかなり根気や覚悟がいるということ。
理想を先に刷り込むという表現があったけど、いいケースをちゃんと知っておくというのはとても大事だと思った。
実際の現場だと、多くのことがバッドノウハウなどで回避できるけど、それって本来は良くないことなんだという意識をちゃんと持てるか（それが当たり前だと思わないか）というのは成長に必要な要素だなと感じた。
物事に疑問を持てるエンジニアになれるかというのはエンジニアとしてやってくには大事な要素だ。
考えとして、
- 基本的な技術向上、マインド向上
- 問題を問題と感じれるか
- 応用力を身につける
というのは考え自体は自分もなんとなく思ってたけど、それを体現されるまでにもっていったのは素直にすごいと思う。
【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント
講演資料（slideshare）
マネジメント関連のセッション。
マネジメントといっても、よくいうQCDに関わるマネジメントではなくて、マインドのマネジメントのお話だった。
全体的にふむふむと一緒に考えながら聞けた。
期待マネジメント
ここまでやってくれる「はず」が実は自分とチームや、上司が思っていることが違うことが往々にあるので、お互いに表明してすり合わせていかないといけない。
なんとなく周囲に期待されているものはわかるけどはっきりする機会というのはそうそうないのかもしれない。
自分の場合は、これやりたいとか、これやりますと言い切ってから取り組んでるので、そういう意味だと自分の表明はできているかもしれないけど、反対に周りの期待することをちゃんと聞けてないのかなと感じた。
また期待は変わっていくものなので、定期的に確認する必要がある。
モチベーションは何気ない一言で乱高下する。
また人によって鍵穴（きっかけ）は全然違うし、他人がその鍵を持っているわけではないので、周りは手助けはできるが、やるのは自分自身。
良いプレイヤーは不調な時が短い、調子を上げれることも重要。
へこんだときに立ち直れるスイッチを自分で知っておくのは大事。
これは確かにそうだと思う、常にいい状態で入れる人はいないと思うけど、できる人はなんらか自分のリフレッシュ方法やゾーンに入りやすくする方法などを経験的にも持っている気がする。
【13-A-6】Mobageを支えるテストエンジニアリング
講演資料（slideshare）
テストに関する、チーム組織が中心なセッション。
DeNAではSWETと呼ばれる特殊チームがいるようだ。
名前は違えど、Google(SET)やMS(SETD)にも同種のカテゴリはあるらしい。
テストのパターンところで、ブラックボックス、ホワイトボックス、グレーボックスと三種類出てきて、グレーボックスってあまり聞いたことない単語だなと思ってたら、DBやキャッシュなどアプリデータを直接いじってテストするということだった。
条件付きの結合テストに近いのかなと。
前提を置いてデータを積んでテストするということであまり特別な感じは受けなかった。
テストでCalabash(Cucumber)を使ってたみたいで、やっぱりいまいち受けはよくないみたい。
自分はあまりCucumberは肌に合わない（無理矢理感が強くて中途半端になりそう）と思っていて触ったことはないけど、Cucumberを絶賛している資料とかはあまりみたことがない。
Appiumというのがあるそうで、こちらはWebDriverを使っているっぽい。
やっぱりWebDriverベースのツールがいいようだ。
自分もWebDriverはよく使ってます。（よくInternetExploreDriverに泣かされるけど）
【13-B-7】何故クックパッドのサービス開発は日々進化しているのか
講演資料（speakerdeck）
クックパッドの開発フローのセッション。
java-jaの方だったけど、最近はその界隈の人たちはあまりきてないのだろうか。
java-jaのセッションは昔は冷やかしとか爆笑とか結構あったような気がするけど、今回のセッションの雰囲気はそんな感じではなかった。（くすくす笑いはあったけど、昔のような内輪ノリはなかった）
全体を聞いた印象は、クックパッドすごい。
クックパッドは、ほぼすべてでGitHubを活用していて、デザイナーさんだけでなく、サポートデスクの方もGitHubのIssueなどを直接扱っているよう。
GitHubという土台があるからこそだと思うけど、サポートの方までGitHubを活用するというのは目から鱗な感じ。
ここらへんをある程度個人の裁量で決めれる組織風土というのもあるんだろうけど、そういったより良くしていこうというのがいいサイクルで回ってるんだなというのがみてとれた。
少し前は、タスク管理と言えばRedmineやTracなどが活用されていたけど、GitHubベースになると下手に連携とかしないでIssueを活用する流れの方がいいのかな。
