「Developers Summit 2014」に行ってきました。【１日目】

日本最大級のソフトウェア開発者の集い「Developers Summit 2014」に行ってきました。

Developers Summit 2014：開発者のためのITカンファレンス

開催概要

• 2014/02/13(木)、14（金） 10:00-18:00
• 目黒雅叙園
• 参加者数 約1000人/日
• 発表資料はこちら。

デブサミ2014、講演関連資料まとめ：CodeZine

会場雰囲気

セッションメモと雑記

サーバプロビジョニングのこれまでとこれから

• 以下の本をざっくり説明した内容。

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

• たまたま今読んでいる本だったので、理解が進みました。
• Orchestration
  • 複数のサーバを管理するレベル。各サーバが自律協調する。今、サーバが簡単に増減できる時代になったから必要になった要件。
• Configuration
  • 単体のサーバを管理するレベル。Chefなどはこちらを対象としている。←自社はこちらのレベル。
• Infrastructure as Code
  • サーバ構築のワークフローに変革をもたらすもの。※もうもたらしている？
  • 以前は秘伝の手順書に沿ってコマンドでサーバ構築する時代だったが、これからはその構築をコードをして蓄積し、構成管理の対象とする時代。
• Immutable Infrastructureという運用が流行っているらしい。※AWSなどでサーバ構築・管理のコストが減ったため。
  • 動いているサーバには手を加えない。
  • 変更したい場合は新規で作る。その後、ロードバランサで切り替え。
  • 新しい環境が正常に動いているなら、古いモノは破棄する。
• Container Base Infrastructure
  • 「Container」とは、ざっくり言うと軽量化VM。サーバ部品のコンポーネント化。個別差し替えして運用する。
• インフラ構築もコードベースでできるなら、テスト駆動で作業しなければいけない。
• 以下はあとで調べる。
  • Test Kitchen：Chefのテストツール
  • serverspec：ChefでもPuppetでもテストできるツール
  • Docker：最近日記でよくみる。食べ物？
  • Serf：サーバが新規追加されたら、上流のロードバランサに存在を通知する仕組み。自律協調の実現ツール。
• 所感
  • 「ウェブオペレーション」をたまたま今読んでいたので、理解が進みました。
  • AWSのようなものの誕生（2002～）で仮想サーバ構築が低コストになった昨今、構築・運用に大きなパラダイムシフトが起きているようだった。日進月歩。
  • 「インフラ構築もコードベースでできるなら、テスト駆動で作業しなければいけない。」の言葉はなるほどだと思いました。ツールもいろいろ出てきているようなので、触ってみたいです。
  • 「Chef」のテストツール「Test Kitchen」のネーミングセンスに脱帽。

グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～

• GREEの中にヒトの発表
• GREEはChef Soloを使っている。
  • Chef Serverを選択しなかった理由
    • 単一障害点になる。（※無償版の場合）
    • 既存のサーバ管理があったので。情報管理が重複するから。
    • Chef Serverは運用のために多くのソフトウェアを必要とされるから。Erlang使える人がいない。
• Chef Soloを使う上での工夫。
  • 既存でサーバ管理のサーバがあって、Chefの設定共存しないといけなかったので、「Chef Bridge」を内製した。
  • 「Chef Bridge」:サーバ管理サーバ内の情報を取得できるAPIを提供する。
• 「世間的にChefは知名度があるが、Chefを仕事で使っているヒトは少ないし、使えるヒトは少ない。」※そうなんですね。
  • GREEでChefを使うヒトはまず以下を読んで勉強する。

    • 入門Chef Solo - Infrastructure as Code

    • [和訳] 初心者Chefアンチパターン by Julian Dunn #opschef_ja « CREATIONLINE, INC.
• この発表でも、「Test Kitchen」「serverspec」が出てきた。
• サーバ構築の際に打っているコマンド・実行ログを保存したいとき。
  • 昔はscriptコマンドを使っていた。今はChefのReport Handlerを使って、MongoDBに自動で入れるようにしている。
• 以下はあとで調べる。
  • Chefのロールの概念
  • chefspec
  • foodcritic：Chefの記法チェックツール。※また食べ物っぽいツール

テスト自動化を見直そう！自動化への投資が開発チームをクリエイティブにする

• 障害対応時、担当者を決めないだけで、対策期間が30パーセント伸びる。
• 優先度の指標として、新しく追加されたコードをテスト/障害対応を行うとよいという傾向がある。
• テストの自動化は4回実行するとペイできる。
• 以下はあとで調べる。
  • Coverity Scan

社内システムの構造と設計、実装のはなし

• 発表はLINEのヒト。
• 社内向けシステムの構築で気をつけるべきこと。
• 社内システムであっても、モジュール化、API提供をちゃんと考えるべき。
• フォーマットはJSONを選んだ。「長期運用できる」が一番大切な要件。
  • 自分の目で確認できるから。
  • データ更新が用意にできるから。
• プロトコルはHTTPを選んだ。
  • テストの容易にできるから。※curlとか？
• とりあえず動くことを目指せ。
• 使われない機能はリリースするな。使われているのかを調べること自体がコスト。
• 機能の優先度をちゃんと管理しろ。「優先度ハック」。
• 機能は細かく1つ1つで動くもので定義すべき。そうすれば、単機能になり疎結合にできる。
• 今いらない機能は後で作ればよい。だって、それはいつでもリリースできるから。
• 「積極的にサボる」
• 社内システムほど試しやすいものはない。顧客は自分。

事例から学ぶDevOps実現のためのプラクティス

• DevOpsには「顧客」「事業部門」も含める必要がある。
• uTestの事例：uTest――世界中の技術者がバグ探し、欠陥なければタダ - ITmedia エンタープライズ
• 「顧客の声」は健在的な情報。
• 「クラッシュ情報」は潜在的情報。
• Googleで採用しかけたランク方式「センチメント分析」（採用はしていない）。悪い言葉が多いと、悪い検索結果を下げる。

フロントエンド開発者になるための切掛と行動

• 「仕事＝保守的な技術」と「趣味＝最先端の技術」のギャップ。
• コミュニティに参加し、一皮向けた。「同じ意識をもって、議論すること」が大切。
  • 以前は自分で情熱的に勉強していたが、それは「独りよがり」なやり方だった。
  • ReadOnlyな勉強だった。ただ読んでいただけだった。知識を借りているだけだった。
  • 噛み砕いで人に説明できないといけない。
• 「仕事」に最先端の技術を入れるためには。
  • 実績と実用性を出し続ける。
  • 他のヒトにやらせてみる。
  • 継続的な活動を通して、いつか手札として見せる。「何が欲しいの？」「何ができるの？」という会話の時に出す。
• 「楽」：”らく”から”たのしい”へ
• 所感
  • 自分はヒトより本を読んでいることを自負していますが、それが「知識を借りている」だけになっていることははっきり言われました。。。
  • 知識をちゃんと噛んで、手を動かす、脳を動かして、自分のモノにしてアウトプットとしていきたいと思います。

ソフトウェア開発を勉強し始めて3年間でやったこと～After～

• bleis-tiftさんへのあこがれ。ブログ：ぐるぐる～
• わかったこと、わかんないことを、ちょっとでもいいから書き出す。
• 「考えないこと」はダメだし、「考えたことを表現しない」こともダメ。
• 思いがあれば実現できる。

快適さはWebサービスの生命線！Webアプリのパフォーマンスを最高にするために心がけること

• 「ザ・スポンサーセッション」って感じで、後半聴く気ほぼなかった。
• アカマイ製品の説明
• 画面描画が早いと、サイトからの離脱率が低下する。
• 最近はモバイルユーザでも画面遷移時間を待ってくれない時代。
• 現在多くのサービスはクライアントにデータを全て送っている（～1.3MB）。しかし、クライアントは画面描画に200KBぐらいしか使っていない。
• 画面遷移を高速にするための工夫。
  • クライアントを識別し、接続回線情報を識別し、最適なデータサイズで返却することが大切。
  • 高速化のために見える部分だけ、先に送る。描画にいらない情報は送らない。

何故クックパッドのサービス開発は日々進化しているのか

• 一番面白い発表でした。
• この会場にクックパッドの開発者は居ない。クックパッドはバレンタインが一番忙しいから。
• クックパッドの他の資料も参照。発表資料 | クックパッド開発者ブログ
• クックパッドの組織
  • インフラ部：インフラやるヒト。
  • サービス開発部：サービス開発するヒト。
  • 技術部：足回りをやるヒト。ミッション「全てのCIビルドを10分以内にする」など。
• 開発ツール「chanko」：cookpad/chanko · GitHub
  • 概要：一部のユーザだけ機能を見せる。その機能についてエラーが発生したら、デフォルトを見せる。「絶対にユーザに迷惑はかけない」というポリシー。
• 徹底的なGitHub駆動開発。
  • マージは本人がする。チーム内のレビューは必ず必要。HTML内の用語変更などはレビューなしでも可、自己判断。
  • 設計行為もGitHubのissuesで行う。
  • デザインさんもGitHubを使っている。デザイン変更の際、デザインさんがPull Requestを出してくる。
  • サポート区もGitHubを使っている。
    • サポートは依頼を投げたら心配する。開発区は進捗を見せるべき。
• LGTM=“looks good to me.（私はいいと思うよ）”
• デプロイ時間できる時間は決めたほうがいい。定時ギリギリや休日前にコミットさせない。クックパッドは月～木の9:30～17:00まで。
• インフラが権威的にならない。
• 「hipchat」を使っている。
• クックパッドの文化
  • 正しいと思ったら行動。自分で文化を作る。
  • 社員一人一人にユーザがいることを意識すべき。
    • サービス開発部、インフラ部→お客さん
    • 技術部→サービス開発部、インフラ部
    • バックオフィス系→サービス開発部、インフラ部、技術部
  • 社員は社外の開発者へ貢献すべき（それが社内の評価項目にもなっている）。
  • 会社で作成したライブラリを個人名で出すなど。会社の経営陣はその行為を「許可」しているのではなく、「推奨」している。
  • なるべくルールを作らない。ルールにしない。
  • 許可を取るより謝罪せよ。ユーザのことを思ってとった行動なら、誰も責めない。
  • 文化を共有、信頼し実行する。
• 所感
  • クックパッドってこれまで「開発一筋で進めー！！」といった感じで人間の体温が感じなかったが、この発表でそれが勘違いであったことが分かった。
  • GitHubで全てが回っており、デザイン・サポートさんに使っていることが驚いた。「うちの会社の関連区は使えないなあ～」と思っていたら、発表者がすぐに「彼らには使えないと思うのは失礼ですよ。30分教えればちゃんと使えるようになりましたよ。」と言われた。すいません。
  • 社外への発信能力も高く、社外の開発者にとって魅力的に見えるんだろうなと思いました。また、その発信が開発者のモチベーションも高めていると思います。

所感と雑記

• 去年もデブサミに来ましたが去年聞かなかったツールの名前が今年は聞こえてきて、改めて進歩が早い業界だと感じました。
• デブサミはこういった情報が得られる場としてありがたいです。
• また他社の雰囲気も感じることができ、それを通して自社と比較が出来ました。※自社はやっぱり決まったことはちゃんとできるが、それが変化のない保守的な会社だと感じました(；´Д｀)←正に自分のこと。