デブサミ2010にいっていきました。
メモ移しておきます。
鈴木雄介 [19-C-1] スライド
パラダイムシフトは起きる。なにかを得るには何かを失うことがある。
いかに長く使ってもらえるものを作るか。
オブジェクト指向、アジャイルなプロセスも優秀な手法だがそれだけでは難しい。
動的平衡にはエネルギーを与え続けることが必要。
これからのアーキテクチャはモジュールとプラットフォーム。
プロセスとアーキテクチャは補完しあう。
何かを得れば、何かを失う。そして何も失わずに次のものを手にいれることはできない− 開高健
-- メモここまで --
遅刻したので最初の方の話は聞けなかったのですが、後半のプロセスとアーキテクチャの補完しあうことに関しては激しく同意で、偏ってはいけない。
また、次のものを得るための自分がなにをしているか、どこに立っているかを問われ、正直どきっとした。少なくてもすでに飛び込んで次を待っている状態ではない。
というか、おそらく傍観している人なんだろう。ぐう。
Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
IBM 玉川憲[19-B-2] （資料）
ストーリー ＝ 柔軟な「要求」の表現
タスク ＝ ストーリーを細かくしたもの
開発プロセスの対比
WF
要求＝スコープ（固定）→リソースと期日が見積もられる
アジャイル
リソースと期日（固定）→要求を見積もる
アジャイルはもともと10人以下のチーム向き
大規模を扱う企業で真剣に考慮されない傾向があった。
そんなことはない。大規模には実際不向きなプラクティスもあるのは事実。
14のプラクティス
- 定義・構築・テストのコンポーネントチーム
- レベル計画づくりと追跡
荒いリリース計画と詳細な反復計画を用いて計画づくりとトラッキングを行う - コンカレントテスト
すべてテストされている - 継続的インテグレーション
- 反復ごとの「ふりかえり」の実施
定期的間隔でチームはより効率を高めるためにどうするかを考察し、やり方を改善する - 意図的なアーキテクチャ
自然出現するアーキテクチャもあるけど - リーン要求開発
素早いコーディングにより形式的な仕様書を避ける
大規模な場合、共通な要求は前倒しで持っておくべき
ビジョン（開発構想書）
ロードマップ - 高度に分散した開発の管理
ツールの使用とより組織的なアプローチが必要
各チームはデイリーミーティング
PMCは週二回のミーティング - アジャイル・リリーストレイン
リリースを固定され遅らせることのできないスケジュールと考える。
時間通りに発射する電車のようにリリースを考える。
リリース・テーマ・品質を守る。
落とすべきは機能・要求 - 顧客とオペレーションへのインパクトへの調整
リリース情報を垂れ流す。 - 組織を変化をさせる。
・ボトムアップアプローチ
それなりの効果はある。
・トップダウンアプローチ
エバンジェリストが必要。
スポンサーが必要。 - ビジネスパフォーマンスを計測する
横串の情報を上位マネージャに提示できる。
-- メモここまで --
あれ、2個足りない・・・
スライドでたら補完する。
いくつかは初めてキーワードだったが違和感なく、楽しく聞くことができた。
RTCの宣伝的な部分が多くあったが、実際にいいPJ管理ツールだと思う。
玉川さんの話を聞くのは2回目なのですが、やっぱり良い講演でした！
RTCの宣伝的な部分が多くあったが、実際にいいPJ管理ツールだと思う。
玉川さんの話を聞くのは2回目なのですが、やっぱり良い講演でした！
● 三周遅れのXP -僕とドワンゴのXP- （資料）
ドワンゴ 庄司嘉織【19-B-3】
XPは今、3周目。
１週目はケントベック。
２週目 角谷信太郎。
３周目は僕ら。（※3週目なら2周遅れだよね）
「車輪の再発明」をしないと心がけるべき。しなきゃダメだという人は老害。知る必要性はない。
僕らは「高速道路の設置」をするべきだ。
４つの価値
コミュニケーション
シンプルさ
フィードバック
勇気 → 「勇気」を出しやすい状況を作ることが大事
おやつ神社
気軽に食べれるところがある→XPのプラクティスにある、みんなが集まって話せる場を作る。
TDDの師匠は「角谷信太郎」「和田卓人」
TDDはTestDrive【Deverpment】つまり開発手法。
TDDはまず動くものを作り、綺麗にしていく。
綺麗なソースを最初から書いてもダメだと思う。
・自分の解決すべき問題を小さく明白に
・すぐにテスト
・開発するためにテストを書く
何度も繰り返しそこで得た知見を即反映 → 宮本武蔵 五輪の書
・不安をテストする
・開発のためのテストであって、品質のためのテストではない。
・WebDBPress Vol35を社内で写経会。
ペアプロ
コードの共有。
コードの指摘を人格批判ではない。
新人にブログを書かせているし、返信もブログでトラバ。
CI
最低でも一日一回
→ 少ない
→ ５分に一回まわした。
→ スローテスト問題発生。
いま３時間かかる。
見積りと計画
アジャイルな見積と計画づくりを嫁。
ユーザーストーリの作成
プランニングポーカー
プランニングポーカー
→ ストーリーポイント計測
→ 繰り返すことにより見積もりができるようになる。
→ 一年間で処理できるストーリーポイントとかがわかる
スマイル動画もBacklogを利用している
ホワイトボードに付箋に貼って進捗状況ごとに移動させる。
Tracにも書いてるけどね
バーンダウンチャート
突発に発生した作業時間も記入、（右上がりで表記）。
正直に書く。FF1３の発売とか。→ 次からDQ、FF発売も見積りに入れる。
現実がXP、アジャイルに対応できないなら、それをどうやったら対応できるかを考えるのもXP、アジャイル的に考える。
Don't repeat yourself
DB→Excel、Excel→DB
Tracから日報
Tracのマイルストーン一括移動
IRCの利用
大きなものを把握できるように小さく分けよう。
XP導入がむずかしいのなら個人で行い、波及させる。
チームにやってもらうようにする。
会社にやってもらう。
XP is about social change. 自分が変わることがXP
-- メモここまで --
空き時間だったので飛び込みで入った割には、今回１〜２番の良い話が聞けた。
いろいろと自分に言い聞かせなくちゃいけない内容であった。
それとともに羨ましく思った。そんな自分がくやしい。
あとやっぱりジョジョを読み返さなくてはならないと思う。
●〇〇◯
つまんなかったので割愛。
● Google 日本語入力を支える情報処理技術
グーグル株式会社 工藤拓 19-C-5
GoogleIMEの内部設計
多くのコンポーネントで構成されていて複雑。
ローマ字変換、キーバインディング、スペルチェック（おんあのこ→おんなのこ）
などなど（※メモれないほどいっぱい）
DLLとしての実装の話
OSの制約、辞書はDLLから共有リソースとされる
・絶対クラッシュしてはならない【大事なことなので3回言う】
・絶対セキュリティホールがあってはならない
発想の転換
クラッシュしても良くしよう。
セキュリティホールがあっても良くしよう。
プロセス間通信（IPC）を利用。
旧のIMと違い、IMDLLはStateless化した。
すべての処理は変換エンジンに渡す。
IMDLLの役割
アプリケーションからきたキーイベントをほぼそのまま変換エンジンに送る。
変換エンジンプロセスが死んでもユーザには影響がでない。
４秒ごとに殺しても平気。
リブート不要の自動アップデートが可能
セキュリティの保護
設計まとめ
クラッシュ、セキュリティは陶然とする
クリティカルな状況でも問題ないようにする
辞書の話
インターネットからクロールして辞書を作成する
ウェブからの特徴的な・高頻度で出現する単語・フレーズを抽出する
データの持ち方
Key-value Storeで実現可能か？ → No
圧縮率が良くない
一般にexact mache ができない。
TRIEでしてる
LOUDS
TRIEのなかでも持っtもスペース効率がよい実装方法
そんなに早くない
ハフマン圧縮を利用
辞書は変換エンジンに埋め込まれていて、ファイルサイズは34MBぐらいに収まってる！
理由
辞書のアップデータの複雑性回避
利点：辞書が壊れない。辞書とエンジンの更新作業がアトミックにに行える。
変換アルゴリズム・圧縮アルゴリズムを日々改善できる。
辞書フォーマットをきにしなくていい
頻繁にアップデートができる
辞書の領域のアロケーションをOSにまかせられる
パフォーマンス低下の要因
相反するフィードバックがあつまった
早い←→遅い
なぜか
エンジンがメモリに乗れば高速に動作
遅い環境ではページフォルトが多発（スワップ）
XP：ページフォワード優先ページング
裏で動くアプリは待避されやすい。
Vista：利用履歴に基づくページング。
XPの解決策
サービスでキャッシュサービスを動かす。
まとめ
IMは複雑なソフトウェア
多くのコンポーネントで構成される
それでいてクラッシュやセキュリティーホールがあってはならない。
機能分離・マルチプロセスアーキテクチャ
Statlessなプロトコル
Playback機能
セキュリティ保護
Googleらしい辞書
Webから辞書作成
ケタ違いの語彙・圧縮率
実行ファイルに辞書を埋込
-- メモここまで --
とにかく圧巻。Googleの技術力を見せつけられた。
特別新しい技術の塊というわけではなく、地道に調査研究して、試行錯誤した結果がこうなりました。という感じ。
個人的に利用していますが、まだ某IMEの方が使ってて気持ちいいと思う。
けど、今回の話しを聞いて期待せざる得ない。
個人的に利用していますが、まだ某IMEの方が使ってて気持ちいいと思う。
けど、今回の話しを聞いて期待せざる得ない。
●次世代Web標準 HTML5 最新動向【19-B-7】
MITSUE-Links 矢倉眞隆 スライド
HTML5全体の話。
HTML5は広義の名称であるが、CSS3や各APIはHTML5と総称して呼ばずに各API名で呼んで欲しい。
過去の互換性を保ちつつ、新しいことを取り込んでいく。
マークアップ
互換性をとりつつ、定型句はシンプルになった。
Form について。
API
一通り全部紹介してました。
白石俊平
未来予想図 − WebMessage
WebWorkersは革命的。UIを邪魔しない。
UI層とBL層をつなぐ役目を担うようになる。
web-messaging-rpc の開発。コミッタ募集。
HTML5を利用したサイトの紹介
小松健作さん
WebSocketsを利用したマッシュアップの披露。
以前作成された食べログのマッシュアップをWebsocketに乗せたやつだと思う。
以前作成された食べログのマッシュアップをWebsocketに乗せたやつだと思う。
たしかにWebSocketを使ったものは世界初なのではないだろうか。
竹迫良範さん
FileAPI
Webアプリだけど、クライアントだけでZipしてくれる。
こりゃいい。わけわからんけど。
FireFoxだけyieldを使える。
上山智士さん
Gyuque
-- メモここまで --
いつもHTML5の勉強会に出させていただいているせいか、特別目新しい情報はなかったのですが、あのような場面で聞くのも感慨深いものがありました。
竹迫さんや上山さんのデモも面白くて新鮮でした。
0 件のコメント:
コメントを投稿