Developers Summit 2013に参加してきました。

Meetup

目黒雅叙園で2月14と15日に開催されたDevelopers Summit 2013（通称デブサミ）に行ってきました。発表者、参加者、スポンサー、スタッフの皆さま、おつかれさまでした。

聞いたセッションは以下の9つ。内容未定の時点で申し込んだとかも含まれてますが、概ね私的に関心の高いセッションになってます。

講演資料一覧はCodeZineにてまとまっています。

今年がはじめての参加でしたが、ためになるセッションが多く、充実した2日間になったかと思います。すぐに家に帰ったら調べて/試してみようと思わせるものもありました。ソフトウェア開発ってエンプラかWebかに関わらず、本来は楽しい作業である（苦痛な作業は自動化やツールやチームのちからで解決することができる）と改めて考えさせられました。

15日の中で特に気になったセッションの感想を書いておきます。14日の感想は、メモが手元にないので、週明けにでものんびりと追記していきます。2/23 追記しました。

HTML5で高速なウェブアプリ、そして3Dゲームの開発も可能?!

  • 会社で許可をもらって行ってますが、最初のセッションから完全に個人的趣味で聴講。
  • OperaがWebKitを採用することになったのも最近のニュースとしてありますが、実装は異なるので注意。
  • 3D描画技術が色々と紹介されていて、参考になりました。
  • ブラウザの表現力をゲーム機に例えた例が秀逸。

チケット駆動開発の本質

  • サーヴァントリーダシップ・マクロマネージメント・ぬれぞうきんはしぼらない
  • チケットの粒度、肥満児チケット、放置すぎるチケットなどのありがちなポイントについて言及されていて、色々考えさせられました。
  • イテレーションをリリースバージョンとしてRedmineを運用するのは、自分達のプロジェクトでも実施中。とはいえ、イテレーション前にチケットにバージョンをきちんと割り当てる、といったルールはあんまり守れていないです…。
  • Velocityの測定は有効そう。あまり進捗管理としてRedmineを使えてないなと考えさせられました。

Opsから挑むDevOps

インフラエンジニアの方が90%で構成される会社の方の発表らしく、DevOpsの概念や、Chef, Puppet, MCollective, Capistranoといった各種ツールに関して、うまくポイントをつかむことができる発表でした。

Chefは本当に色んな所で耳にするようになったし、使いたい気持ちはありつつも、Cookbook, Recipe, Resource, Template等々、概念が多くて、（Rubyでシンプルに書けるとしても）とっつきにくそうな印象があったんですが、少し敷居が下がりました。また、MCollectiveを知れたのは大きな収穫でした。全然知らなかったので。情報の収集源がほぼ継続的デリバリー本だけの身としては、どうしても穴が出てきちゃうので、うまく補完できてよかったです。

後半は先日提供開始されたばかりのクラウドサービスの話。普段の自分だったら会社の製品の宣伝をされるとちょっと萎えてしまうところですけど、とても興味の惹かれる内容でした。聞いた発表内容から、すごくピンと来て、面白そうなアーキテクチャだったなと。詳しく書いていいのか微妙なところなので書かないでおきますが。

セッション終了後は、会社でブースも出してたので立ち寄ってみました。もうちょっと時間があればデモとか見たかったけど、とりあえず名刺交換だけして次のセッションへ。残念。名刺を渡すともらえるノベリティのモルスキン（伝説的ノートブック）が地味にメモを取るのに活躍しましたｗ

SQLアンチパターン─開発者を待ち受ける25の落とし穴

読んでない人がこのプレゼンを聞いたらこの本を買わずにはいられないようなプレゼンでしたｗ

非Railsアプリでもとにかくテーブルにとりあえずidとか、木構造を表現するのに親IDカラム作っちゃうとか、割と我流の論理設計をしてきた身としてはドキッとする点がちらほら。そういった共有できる問題について、同じ失敗を繰り返さないために、名前や対策付きでアンチパターンとしてまとまったのは本当に素晴らしいと思います。

あとは、こうして体系化して整理されたアンチパターンと、実体験が結びつくと、より自分のスキルが広げられるんじゃないかと思います。ナイーブツリーを使ったプロジェクトに携わった後に、Redmineのソースコードを追っていて、「なんだ、この lftとrgtって？」と思い、ググって入れ子区間モデル・入れ子集合モデルを知った時は、衝撃を受けてテンションが上がった記憶があります。

ワンクリックデプロイ〜いつまで手でデプロイしてるんですか〜

このブログでも何回か書いたことがあるけど、継続的デリバリーは関心の強いテーマです。自分のプロジェクトでも、（いわゆる野良継続的デリバリーかもしれないけど）、デプロイパイプラインとか色々試行錯誤してきた立場としては、非常に価値のあるプレゼンでした。内容は復習的な意味合いが強かったかな。

ちなみに、発表者である吉羽さんの公開スライドは、社内で継続的デリバリーに関するプレゼンをする機会があった時に、大変参考にさせていただきました。こっそりここでお礼を言わせていただきます。

継続的デリバリーは実践しようとすると色々と課題が見えてきて、今のプロジェクトで抱えている課題は下のようなものがあります。少しずつ改善していきたい。

  • すべてのテストが通るのを確認してからコミットする習慣がない（紹介されていたアンチパターンの一つ）。
    • （原因1）テスト実行はワンコマンドでできるけど、終わるのに1分かかるだけでも面倒と感じてしまい、やらなくなっている。
    • （原因2）テストの実行はCI(Jenkins)側にまかせてしまえばいいかと思っている（開発が少人数ってのも影響しているかも）
  • Jenkinsの届かないスタンドアロン環境へのインストールを行うのに、作成したパッケージをWinSCPで転送→展開→実行という手順が必要。
  • 受け入れテストが自動化されていない。
  • 静的解析、単体はコミットの度に行うけど、結合テストだけは（自動化しているものの50分くらいかかるので）1日1回だけにしている。

JavaプロジェクトのマイグレーションもRailsのマイグレーションを使っている人が結構いるんですね。今は自製のマイグレーションツール(SQLベースで、upはできるけどdownはできない）なんですが、Flywayに乗り換えようかなと思ってたりします。

アジャイルサムライって当たり前になるのかな？

若いエンジニアの方々のエネルギッシュな話を聞けて、とても刺激になりました。

苦労話も聞けましたが、自分の経験をふりかえると、アジャイル開発が浸透するかはプロジェクトによりけりだったように思います。最近だと、ふりかえり、カンバン、イテレーション開発などは、率先して薦めてくれる先輩がいる状態だったりしたので、恵まれているなぁと思います。

いいプラクティス、すべったプラクティスの話で、自分がすべったプラクティスは工数を時間でなくポイントで見積もって評価するやつ（プランニングポーカー？）かな。ちょうどアジャイルサムライを読んだ直後に本格的に始まるようなプロジェクトだったので、使ってみようと思ったけど、最終的にメンバーの開発範囲も完全に分業化してしまったり、メンバーも抜けていったりで、機能しなかった経験があります。

ペアプロはどうなんでしょうね？最近、テストコードを書くのにペアプロしてみたけど、テストコードの均質化（書き方そのものやケースの洗い出し方）に結構有効だったんじゃないかなぁと。TwitterのTLを見ると色々な意見があったけど、一度ちゃんとしたペアプロのHowtoを学んでみようかなと思いました。