デブサミ2012 1日目 (2012/02/16)のまとめ その1 #devsumi
参加セッション
- 【16-A-1】見る前に翔べ 〜ギークの工夫で社会を変えよう〜 及川 卓也 氏
- 【16-C-2】大規模化するピグライフを支えるインフラ 〜MongoDBとChefについて #devsumiC
- 【16-B-3】教科書と現場のあいだ 〜学びを活かすために〜#devsumiB
- 【16-A-4】Effective Smartphone UX at GREE #devsumiA
- 【16-E-5】デザインの最前線 #devsumiE
- 【16-C-6】kintoneの表と裏〜大規模JavaScript開発と非構造データベース #devsumiC
- 【16-B-7】デブサミオフィシャルコミュニティから選出のLT大会2012
まずは3セッション分のまとめ
【16-A-1】見る前に翔べ 〜ギークの工夫で社会を変えよう〜 及川 卓也 氏
見る前に跳べ 〜ギークの工夫で社会を変えよう〜
View more presentations from takoratta
プロフェッショナル仕事の流儀
-
- 会場視聴率 80%
- 挑まなければ、得られない
- Nothing ventured, nothing gained. が元ネタ
- あの及川とこの及川は別の人
- 事実を元にしたフィクションと思って
2ch vs Twitter Facebook Google+
- 友人からは「2chは読むな」と
- 読まなければよかった orz
- ここまでこき下ろすか
- これはサイバーカスケード現象
- 同じ方向に傾いている人が集まっている、その方向に流れてしまう
言葉
- "当たり前を"を、否定せよ
- 痛みから逃げるな
ソフトウェ開発の変遷
2011 ベストスピーカー賞 クラウド時代のソフトウェア開発
の内容をおさらいし、今どのように社会に貢献できるかを伝える
- Launch & Iterate
- Launchはリリースと置き換えてもらってもよい
- 完璧を目指すよりまず終わらせろ
- パッケージ
- リリースが重要
- リリース前に注力する
- 昔 リコールは絶対に出してはならないものだった
- 例
- 翻訳ミスがないか
- メッセージがはみ出ることがないか
- 膨大なチェック
- アップデートをどうやってユーザにとどけるか
- それでも、当てるかどうかはユーザー次第
- 大きなサイクル
- Plane
- Design
- implementation
- Stabiilzation
- Release
- クラウド
- 「リリース後」が重要
- デプロイ、配布コストが低い
- すぐに直せ、反映できる
- リリース後に十分にパフォーマンスがでているか
- 落ちることがないか
- 常にモニタしている
- 小さいサイクルを繰り返す
- 毎日のように
- うまくいってなかったとりはずす
- 日々進化
Theme
- なんのためのプロジェクトなのか
- 大量のドキュメントなんて読まない
- チーム全員が覚えられるで、〜3行で収まる範囲で
- 例 JW-1o/Rupo 日本語ワープロ
- 森健一
- プロジェクトのコンセプトを3行で表現
- 1)誰でも手書きより早く入力できる
- 2)持ち運びできる
- 3)どこからでもアクセスできる
- いろんな機能を追加をテーマに沿って考えることができる
- いろんな機能を落とすときにもテーマに沿って考えることができる
- テーマがあればプロジェクトが佳境にはいったとき、立ち止まったときにふりかえることができる
- シンプルなもの覚えてられる範囲で
プロダクトアウト、マーケットイン
- プロダクトアウト
- 開発者の想い
- 唯我独尊になってしまう危険性
- マーケットイン
- ユーザの声を聞く
- ユーザー自分の声で話すとき、それが本当の声とは限らない
- リサーチ会社だとインセンティブがある
- ユーザビリティラボ で 視線を追うテストだとしたら
- なんか貢献しないとという気持ちになってしまう
- 普段見たこともないポータルサイトでこうすればいいのにと
- だが、これを反映したからといっても、ポータルを変えてくれるとはかぎらない
- ローンチ
- 開発者の想いとユーザーの声
-
- アクティブユーザがすぐに分かる
- 繰り返し訪れるか
- クリックしたか
- プロダクトアウトで問うて、ユーザの声を聞くことができる
- 実際に使わているかどうかのデータを見ることが出来る
- マーケットを作ろうという時にマケットリサーチは意味がない
- SONY
- 人のことをやらないことをやる
-
- 「いい会社"だった”」と去年いってしまった
- 本当にいい会社です
- ウォークマン
- 企画書を提出して、試作を行ってという通常の手順を踏んでいたら、この商品は生まれなかったかもしれない
- なんだかわからないものをリサーチしても意味ない。プロトタイプを作って、銀座でぶら下げてもらえ
- ユーザー
- ユーザーって誰？
- 今日のユーザー(今使用しているユーザー)
- 明日のユーザー(新しいマーケット)のために製品を作る
- ユーザーって誰？
- イノベーションのジレンマ
- プログラミング言語
- 新しい市場
- 新しいユーザー
- 改良が繰り返されている
- クラウドWebだとJavascript
- これでいいのだろうか？とい疑問でGoogleならDart
- プログラミング言語
- 常に新しい市場を作ろうとしている、明日のユーザー
- 今だけではなく、次を考える
┌──→ 仮設 ───┐ │ │ └─── 実証 ←──┘
間違ったら、パラメータを変えて繰り返す
現在の日本
-
- 逆V字の状態
- 予測ってのははずれることが多い
- 人口予測だけははずれない
- 人口推移の折れ線グラフ
- 人口ピラミッドの年代ごとの移り変わりのアニメーション
- ビジュアライゼーションって大事
- しかし、世界は人口爆発
- バブル1980年代後半
- 「本当にいい思いをさせておもらった」
-
- はじけたときには、ちょっとだけと言ってたが、5年、10年、20数年たっている
- いいものと思ってるものだとしても、何がいいのかを考えていかないと継続できない
市場競合
- 従来考えられている市場とは違うのではないか
- 京都のおしゃれなカプセルホテル
- カプセルホテルの競合は？
- ビジネスホテル、ネットカフェ
- 実はタクシーでは？
-
- 良質な睡眠 vs コストでどちらを選ぶか
- 自分の競合は狭い世界にいるのではなくて、まったく思いつかないところにいるのではないか？
- アメリカの航空業界
- 競合は、電話会社
- 移動しなくてもいいようになったとき、テレフォンコミュニケーションが主流になったときが本当の危機だ
Hack The World
- 仕様書：やれと言われてる感じがするのでそう呼ばない
- デザインドキュメントと呼んでいる
- ここが変だよ日本企業
- というネタでブログを書きたいと思ってかけていない
-
- 遅すぎる
- 会議/ミーティング
- 終わりが決まっていない
- 早く終わってもついでだからと別の内容で話はじめる
- 何も発言しない人もいる
- 定例ミーティングなんていらないんじゃないか
- 次の定例ミーティングで話しましょうになってしまう
- 別の定例ミーティングがあるので、次の日、必要な日にできない
- ノーミティングDay
- ノーミティングWekk(2週間)
- ゼロベースの思考
- ホントにいるかを試してみる
- 会議/Meeting→議論/Discussion
- 会議だとでてるだけで満足してしまう
- 名前を変えてみる
不連続への挑戦
- 先頭奏者
- 出る杭は打たれる
- これ事例はありますか？
- 世界初で日経の一面飾りましょう
- 事例がないと社内の稟議がとおらない
- 出る杭は打たれる
- みんなはきた道ばかり気にする。本当は行き先の方が大事なんだ。
- ジョン・ディリンジャー
思考実験
- アナログをデジタルに変える
- 今なんでこうなんだろう
- 何人かは反論してくる
- あえてそういう思考実験をしてる
- そこで化学反応が起きる
- 異端児がこういうことがいると苦痛、不快に思う人もいる
制約条件
-
- もし、----------までに
- 年→月
- 月→週
- 週→日
-
- 部下にしてみればこれは非常に苦しいかもしれない
- creativity loves constraints
- 制約が多い
- 小さい工夫でクリアーしていく
- 手段と目的を混在しないように
- How vs What
Avoid Note
- バッハの音楽
- ちょっとずつ旋律が変わっていく
- ジャズ
- ある音が入ったら、不快に感じる音
- あえて材料としてつかってみよう
- JACO PASTORIUS
get out of comfortable zone
- 不快はこのまない、快適なゾーンに留まりたい
- 本当は、引っ込み思案、でもあえてでていく必要がある
- 見る前に飛べ
- W.H.Auden
- 見ないで飛ぶのは怖いが見過ぎると飛べないことも多い
【16-C-2】大規模化するピグライフを支えるインフラ 〜MongoDBとChefについて〜桑野 章弘 氏 / 並河 祐貴 氏
開発スピードのための構造
- 例:最終ログインタイムを追加したい場合
- lastLoginTime1つオブジェクトを追加できる
- ない場合の処理を書いておけばいい
- すぐに追加できる
スケーラビリティ
- データをChunkで分割
- アプリケーション側はmongosにアクセスする
- 実際にはmongocのレプリカにアクセスル
- mongodbの機能でできる
冗長性
- 相互死活監視 & 投票により冗長製を保つ
- 最小単位は3台
- 生きてるサーバで投票でプリマリサーバが決まる
実際の運用は？運用の課題
- 現在の台数140 ここまでは稀と自負
- mongos
- スケーラビリティはなし
- アプリサーバに同居
- サーバへの負荷はすくない
- mongoc
- スケーラビリティなし
- 常時は負荷が駆らないが潤沢なリソースが必要
- 冗長性は同期書き込み2フェーズコミット
- mongod
- メモリに書き込み
- 定期的にDiskに書き込む
- ioDriveの性能を有効につかえる
- ioDriveに書き込む処理でレプリケーション側のアクセスが遅くなる
- CPU
グローバルロックあり
複数コアは効率的に使えない
-
- メモリ
- Indexがメモリをあふれる場合があれると性能が落ちる
- Index
- 2.0系でIndexをはっている
- Btree
- Indexをはると、レスポンスが100倍に
- 7ミリsecになった
- よく検索されるデータにはインデックスをはる
- バックアップ
- fsyncコマンドでれぷりか 停止してdump
- シェアードごとにやって、あとでつけると完全なデータをつくる
- グローバルロック
- 逃げるすべ
- 別のクラスタに分けて局所化
- 例
- ConneftionBに集中するとA,Bのアクセスが滞る
- Bだけノードを分けている
- 今後コネクションロックが採用されるはずなのでこういった対応は不要になるはず
- Chunkの偏り
- データ量、オブジェクト数による分割
- データアクセス頻度ではない
-
- データアクセス頻度によるShared分割をしたい場合には、手動Chunを移動する必要があり、
- 再起動する必要がある
- 2.0でロードバランスの機能がよくなっている
- バグとの戦い
- mongodumpをmongos経由で実行すると落ちる
- →2.0で修正済み
- mongodumpをmongos経由で実行すると落ちる
- mongos->mongocのセう段が起こった倍の再接続でmongocが負荷が上がる
-
- →2.0で修正済み
-
- mongod replicasetsのPRIMARYが切り替わっった時にmongosがダウン
-
- →次のバージョンで修正されるはず
-
- Shaarding replicaSetsと柔軟なデータ構造があり、
- サービス開発(ゲーム、ソーシャルゲーム)をつくるには最適
サーバ増設、管理に関する話で登壇者交代
- インフラ
- アメーバピグ
- ピグライフ
よくある光景
-
- ○○のサーバの負荷が高いので30台増設したい
- 右肩上がりに成長
- 想定を超えるスピード
- それ、クラウドを使ったらでｋ(ry
ミドルウェアの設定管理やプロセスの状態管理も含めてChefの紹介
- 手作業→時間がかかる
- 数十台数百台になると、サーバごとの差異が発生したりしてしまう
- リードタイムが長くなってしまう
- 作業漏れ、1台だけ設定が違う
- サーバにばらつき
- あとで一気に変更する際にミスが発生してしまう
- Chefを使えば設定に間違がっても自動化で一斉変更できる
- プラットフォームの差異吸収
- ディストリによるコマンドの差異
- yum、apt
- OSSでなりたっている
- httpとJSONでなりたっている
理解するために
- Node
ノード/サーバ
- Role
管理したいグループ
- Cookbbok
- どういうことをしたいかのレシピ集
- nginx
- Passenger
- ruby
- git
- などなど
- どういうことをしたいかのレシピ集
- アプリケーションサーバとしてのRoleとして、Cookbookを結びつけたり
- nodeから直接cookbookを紐付け付けることができる
- template：サーバへ配置する設定フィル eRuby
http://wiki.opscode.com/display/chef/Templates
##Groovy,Gradleでできないだろうか？
- Chefで利用できるResource
- Cron
- Git
- etc・・・
いけてないところ
- サーバのセットアップが面倒
- パッケージの用意はされている
- dry-runができあないので、テスト環境が必要
Chefを活用したサーバ増設
- postスクリプトが若干肥大化
- 今はオンプレミスな物理環境を想定
- クラウド環境でも応用可能
- AMIを作成して、user-nodeにノード名を設定で
- 各Role
- ScriptResourceは使わないようにしている
- コマンドレベルで書ける
- →何度も実行される
- 何度実行しても問題ないものにだけ使うもの
- tomahawk：複数のサーバで同じコマンドを実行
- Node のAttributeお登録
- JSONファイルを自動生成して登録
- アンインストール・削除等の処理も忘れず
- Enviromento(0.10〜)の活用
Chef
-
- そのサーバがどうあるべきかを記述数r事で設定を自動化できる
- Rubyそのものも使えるので、柔軟に対応できる
今後
クラウドとうの連携して、実際にサーバを準備することを完全に自動化したい。(
【16-B-3】教科書と現場のあいだ 〜学びを活かすために〜和智 右桂 氏
教科書と現場のあいだ
View more presentations from Yukei Wachi
仕事はアーキテクト
-
- 方式設計、要求定義、開発もちょろっと
- DDD 1/5
- 文系大学院出身
- ドイツ文学
- 抽象概念の操作が仕事
- これがオブジェクト指向の原点
- 中規模プロジェクトのリーダー
- 現場に導入しようとして苦労してる人→半分
- 本を読んでみよう、勉強会に参加したいみたい人→半分
- アジャイル→ 1/5 残りWF
- 今回は学びと現場のギャップに対する回答
- 仕事はSI
- 休み
- 翻訳やブログ
- セミナーに参加
- 登壇
- 仕事は比較的トラディショナル
おしゃれ
スクラム | DDD
プロセス ---------------------+----------------------------- アーキテクチャ
ウォーターフォール | トランザクションスクリプト
どろくさい
プログラマでの成功体験
失敗体験
-
- 振る舞い駆動開発
- スケジュールが完全に崩壊
- ちなみにBDD 知ってる人? → 1/5
- TDDの発展形
- ユーザーストーリに基づいて、give、then、whereで記述する
- BDDは素晴らしい
- が、周りとの調整ができていなかった
- とあるシステムの機能追加
- どこまでつくるのか
- つくったものをどうやって引き継いでいくのか
- 1ヶ月後
- 大変なことになってることに気づいた
- ごめんなさい
- リカバリパターン
なぜだろう？
- プラクティスの優劣ではない
- 閉じた世界 開いた世界の違い
- デザインパターンを読んだときの状態
- リーダーがある程度アーキテクト設計、スケジュールができていて
- 戦力として和智さんが投入された状態
- うまくいったのは、私なのかリーダーなのか
- BDDの状態
- そういう囲い込みもできてない状態でボールを渡された
- 限られた領域の中で問題を解決するをするエンジニアも必要だが、そういう問題を解決するために囲い込みをする人も必要
- 解決するために囲い込みをするをやるには怖い
要件
設計
実装
テスト
リリース
- これってなんですか？
- 基本的にソフトウェアを作る本質的な違いAgileでもWFでもはない
- 動く形になってお客様にとどけられる→バリューストリーム
- これは、抽象的なものを具体化する流れ
- ユーザーがやりたいこと、機能など、頭の中にしかないものをドキュメントに落とす。
- 仕事としてやるからには、みんなの嫌いな 予算と期限 が入ってるくる
- ある程度の抽象的なものをより具体的にしていくこと
- はっきりしないもの 課題として管理
- プロセス
- 進捗管理
- 課題管理
- 変更管理
- バリューストリームの流れにのってスムーズに流れてくればいいがこれはあとでと変更管理をしないとならない
- コックピットのようにいろいろなものを見ないとならない
- アーキテクチャデザイン
- 分割していって、再統合したときに動くこように考えるのがアーキテクト
- プロセスデザイン
- そのために週1日集まる。週2回集まりしょう。そういうことを決めるのがプロセス
原則(プリンシプル)と実践(プラクティス)
- それでもで朝会ができない場合もある
- お客さんと打ち合わせ
- 朝弱い人
- 来ない人
- 各自が自分のタスクをやっているだけなので作業上京を共有する意味がない
- 朝顔を合わせるだけの意味しかない
- リーダーへの報告ではない
-
- 自分はここまでやった
- 自分は大丈夫だけど、他の人は大丈夫だろうか
- 自分がまずいから、誰か助けてもらえないだろうか
- なんでそれをやらなければならいのかという原則がある
- それをはじめて理解して、なぜそれをやっているのかという意味がある
- それがないと型をなぞっているだけになってしまう
- 原則をたどっていくと最終的には、方法論上の区別には意味がない
- 作業のチャンクを小さく
- ふかえり改善案 PDCAサイクル
- 痛い思いは早めにしておこう
- 後でやってうわぁってなるよりも先にやってしまう プロとタイミング
- 原則を理解すると、実践に幅が生まれる
- 意味を理解して柔軟にコンテキストに乗せていく方がいいじゃないか
- アジャイルサムライ読んだ人？→ 6割
- インセプションデッキ
- どんなパッケージにすればいいかやってみようぜ
- 職場でクレヨンもって書ける？
- プランニングポーカーでカードをおでこにあててくださいと言える？
- 原則を理解した上でやると組織の上で実践するにはどうしたらいいんだろうとう「言葉」を手に入れられる
- パッケージ 何を作るかを1つにするために
- プラニングポーカー 俺は決まった 平等で自分で見積もったことを突き合わせるため
- 自分が価値だと信じるものを相手に伝える能力は本当に大切
- 問題を解決する能力≠それを伝える能力
- 相手が分かる言葉で伝えていく能力が大切
- バリューストリームとしての成熟とは実際にアイディアが生まれてから、具体的に商品にする、抽象的な概念に落としていく
受託開発
- 常に新しいコンテキストがまっている
- 今でのやりかたで、ここが問題だったから、改善しようとできたのが、新しいお客さんで崩れる
- 保守フェーズって一番アジャイルやりやすいフェーズ
- 前のお客さんでやったバリューストリームは、新しいお客さんには通じない
- 新しいお客さんと1から気づいていく必要がある
- すぐれたPMはここからプロセスとしてもってる
- アイディアから形にするだけでなく、それとともに創り上げるためにはどうしたらいいかを持っている
- プラクティスに意味がないわけではない
- 閉じた世界で問題解決をしてくれるエンジニアはお客さん、リーダーにとても役に立つ
- HTML5など要素技術も必要
- 原則は1段階抽象レベルが高い
- 地図を作ろう
- 求められるものはなに？
- 俯瞰できる地図を作ったほうがいいのでは？
- 勉強会で、人がやっていること、なんでそれをやっていかなければならいのかということを話し合うことも意味がある
- コツ
- 最初に原則が書いてある
- ふわっと理解できる
- セミナー
- 著者に会える機会を大切に
- 英語の問題で躊躇するともったいない
- 本は体系的に書いてあるので、ごく一部
- 彼らも悩んでいる
- 偉そうに見えるけど、かれらにも悩みがある
- 学びの中でそういう機会を大事にすべき
- そして、いつも、地に足をつけよう
- 決められた期限、予算の中で価値あるソフトウェアを届ける
- Q.モデルはアーキテクチャデザイン、プロセスデザインの2つに含まれるか？
- A.モデリングということは切り分け
- 難しいところとそうでもないを切り分けるのがアーキテクチャデザイン
- 閉じた世界に落ちたらプロセスデザイン
- Q.守破離というのはどう理解しているか？
- 守：型 武道は実践からはいる、先生とまったく同じ動作を覚えていく
- 破：筋肉のつきかたが違うから、うまくいかないことがでてくる 守らないことがいいことがでてくる
- 離：自分の型ができる 破れの集合体として成り立っていくこと
