2011年04月19日

QCon Tokyo 2011


Qcon(キュウコン)というITセミナーに参加した時のメモ。
http://qcontokyo.com/index.html

様子を知りたい方はこっち↓
Togetter -「#QconTokyo 2011」
 → http://togetter.com/li/123429


キーノート1
メイン駆動設計:複雑な問題群に対する有用なモデル達
Eric Evans(DDD Inventor)


地図と船による荷物の運搬を例にとって
ドメイン駆動設計について説明していた。
ソフトウェアの開発は、ドメインを理解して、
モデリングとデザイン(設計)を行うことでゴールにたどり着くことができる。
 ・この機能は本当に必要か?
 ・バグ収束してからのリリースではなく、許容可能なバグレベルを設定する
 ・次のリリースまで継続する
 ・ユーザエクスペリエンス

ドメインとは「A sphere of knowledge or activity」のこと。
ソフトウェアの複雑性は、ドメインそのものの理解から生じる。
ドメインを明確にしてからモデリングを行う。
モデルとは「A system of abstraction」
 →抽象化の体系。切り捨てる部分と残す部分。

船で荷物を運ぶシステムを考えるときは、
「地点」ではなく「行程」に焦点を当てる。
業務(ドメイン)を正確に理解してシナリオは複数用意する。
役立つモデルは特定のシナリオのみ。
ドメインには複数のモデルが存在する。
ドメインの理解不足から生じる要件のムラや設計の行間が重大な障害となる。
Bounded Context = モデルを適用できる境界を明確にすること。

コードを書き始める前に正しいモデルに到達すること。
DBに格納するカラムを扱うときもビジネス(業務)について考える。


キーノート2
Webアプリケーションエンジニアがみてきたこの10年
伊藤直也(グリー株式会社)


1995年から2011年までのWebアプリケーションの歴史について説明。
この講演はよくまとまっていて大変面白かった。

1995-2000 「ポータル戦争」
 ・Windows95発売
 ・デバイス、メディア、グローバリゼーションとして成長
 ・Webアプリという言葉はまだなく、Webサイト
 ・オンラインゲームの登場
 ・J2EE,Webアプリケーション
 ・98年 Google創業

2000-2005 「Google〜web2.0」
 ・ネットがメディアとして成長
 ・LL(Perl, PHP, Ruby, Python)が人気に
 ・アクセスログがないとメディアビジネスは成り立たない
 ・2004年 Ruby on Rails
 ・ブログブーム、Cheap Revolution
 ・mixi, Twitter, Facebook
 ・2005年 Ajax、Google Maps
 ・Web技術の成熟化

2005-2010 「ソーシャルプラットホーム」
 ・Googleとソーシャル
 ・Googleの抜け道が「人」
 ・コンピュータではGoogleにかなわない
 ・日本のインターネット=ケータイ
 ・GREEはmixiに負けてケータイに移行した
 ・2007年 ソーシャルゲーム元年
 ・クラウドコンピューティング
 ・2008年 Android

2011
 ・これからはAndroidの時代。
 ・Scala →MVCの概念が変わった
 ・リアルタイムWeb
 ・HTML5, JavaScript, node.js
 ・Google Chrome、mongoDB、Scala, Lift


クラウドのデータアーキテクチャ―設計の原則
萩原 正義(日本マイクロソフト株式会社)


クラウド技術の基礎知識の説明。
クラウドはデータの分割とI/Oコスト削減
非正規化 →Map-Group-Reduce
MapReduce →多出力、UNIXにおける2次元のパイプ
SQL →関係代数、Row sotre(行志向)
No SQL →Columnar Database(列志向)
KVSは複雑なクエリは発行できない
Cube →先にJoinして属性値の組を作成


品質検査技術のトレンド –レビューと測定・欠陥工学を中心に-
細川 宣啓(日本アイ・ビー・エム株式会社)


これは一番面白かった。
バグがあると人が死ぬようなクリティカルな
システムの設計書などのレビューを行っている。
工程の後半で一気にレビューを行うのではなく、
開発全体で、15分×8のように細かくレビューした方が
self-governanceが働いて、効果できる。
開発の前半でレビューした方がよい。
レビューはバグを検出するだけ。
これだけでは品質は上がらない。
レビューの投資コストは、アジャイルと同じ。
完全ペアプロは100%レビューと同じ。
レビューを適切に実施しないと、
バージョンアップごとに品質が劣化する。(バグの蓄積)
予測と予防。
魚群探知機などでバグのあたりをつける。
講演者のチームは、バグマスタDBを作ろうとしていて、
このバグDBとプロジェクトの BTSをジョインすることを
将来的に考えている。
病原体のようにバグにカタチを与えてバグを分類することを行っている。
カタチを持ったバグを3次元に並べて、診断して他のバグを探す。


分散クラウド型プラットフォームを考える
山下 克司(日本アイ・ビー・エム株式会社)


これもクラウドの基礎だけの説明だった。
VMWare+Salesforce+Spring+Google Web Tool (HTML5)
業務クラウド
BASE(Basically Available, Softstate Eventual Consisitency)
 →なんとなく動いていて、それなりに連携していて、いつか(データが)一致する
ACID特性ではなくCAP定理
いろいろな分野を経験するといいよ。
隣を知っていると、自分の領域がよくわかる。理解が深まる。


Performance Engineering at Twitter
Evan Weaver(Twitter)


英語が速くてよくわからなかった。
映画「ソーシャルネットワーク」に出てくるような雰囲気の人だった。
Twitterは4つのコンポーネットからなっている。
 →Row Cache, Timeline Pool, Row Strage, Index Strage


形式手法の現在と実開発への適用可能性
今井 宜洋(有限会社 IT プランニング )、小林 健一 (株式会社豆蔵)


コードの正しさを証明によって保証するツールの紹介。
数学的な理論的基盤によって形式的に証明を行う。
主に組み込み系で使うことが多い。
Small Scope Hypothesis
 ・多くのバグは小さい範囲でも見つかる
 ・この「範囲」を科学的に見つける
表面的な説明だけで、続きは懇親会で、という流れだった。
懇親会には参加していないため、詳細は聞けなかった。
定理証明器Coq
 →対象言語(Haskel, OCamlなど)をCoqで実装して、
証明を行い、コードを自動生成する。証明はコンパイルが通ればQED。

※参考
 Coq
 Coqによる証明駆動開発で Merge Sort プログラムをつくってみた
 Proof Driven Developement

命題とプログラムが1対1に対応する(カリー・ハワード同型対応)
というのは内容としては面白いけど、コンパイルが通ることで、
「証明された」とみなすというのは、ちょっとだまされたような気がする。

そもそも関数型言語で開発をしたことがないし、
業務に活かしようがない。

けど、稲葉さんのブログにあるように、
「証明することを意識してコードを書く」という視点は重要だと感じた。
(関数型言語の場合だけど)




posted by 色人 at 00:37| 北海道 ☀| Comment(0) | TrackBack(0) | IT | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]


この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。