QCon Tokyo 2009 に行ってきました。一日目のメモ

qcontokyo

得るものの多いカンファレンスでした。
スタッフの方、講演者の方、参加者の方、おつかれさまでした。

会場で取ったメモを置いておきます。
正確性はまったくあてになりませんので、そのあたりご承知のうえ、だまされたつもりでご利用いただければ。
あとプレゼン資料のメモが多く、著作権的にフェアユースの範疇なのかちょっとよくわかりません。ご指摘あれば対応させていただこうかと考えています。

  • 一日目: オープニング
    • QCon / InfoQ の説明と、午後のマルチトラックセッションの紹介
      • Rubyトラックは角谷さん
  • 一日目: 午前1: ドメイン固有言語 −その役割− / Martin Fowler
    • DSLについての本をもう２年くらい書いている
      • 年内いっぱいはかかりそう
    • DSLs are everywhere
      • RegEx, make, LINQ, rake, ant, css, SQL, graphwiz ...
      • もっと使うべきか？
      • もっとよくできるか？
    • Secret Panel: 部屋にはいって、電気をつけ、引き出しをあける
      • ステートマシン図 / クラス図 => そのままJavaコードを吐き出せるが、可読性が低くなる。新しい設定にするときにはコンパイルが必要になる
      • XMLにすると、もうちょっとクリアになる
      • Rubyの言語内DSL
      • カスタム文法のコード(言語外DSL)
    • External DSL (言語外DSL) と Internal DSL (言語内DSL)
      • 言語内DSLは、親言語の制約を受けるが、言語のための作業がいらない - その辺のトレードオフ
    • Command-Query API と Fluent API (流れるようなAPI)
    • DSLとは
      • 言語
      • コンピュータプログラミング
      • limited expressiveness (限定的な表現力) <= general purpose ではない
      • focused on particular domain (特定領域に集中)
    • write より read
      • DSLを書くことがないビジネスピープル/ノンプログラマも読めるようなDSLは、コミュニケーションを助ける。
    • [感想] 最後の話(ノンプログラマが読めるDSL)は、すごく価値があることだと思います。いまはExcelで書いた表で会話しているかもしれませんが、そのまま動作すればその方が齟齬がない訳で。「Word/Excelからwiki/cucumberへ。」って感じ？
  • 一日目: 午前2: ビューティフルコード / まつもと ゆきひろ
    • コードは設計である
      • 職人芸、一品もの、善し悪しがある
      • コードを書くための作業全体が設計なのに、その一部の作業を取り出して「設計」というのはどうよ。
    • コードは実用品である
      • 実用に供してなんぼ。用の美
    • コードは読み物である
      • 効率よく探し、読めれば、生産性が上がる <= 『CODE READING』
      • 手元にソースがあれば、ドキュメントに記述されていない内容を生で読むことができる。OSSすばらしい。実用OSのソースを学べる。ストールマンやBSDの人たちの活動があってのこと。
    • コードは人を感動させる
    • パワーの美
      • 優れたアルゴリズムは、できないことをできるようにする力
      • Ruby1.9のM17Nも、吉田さんのパッチで実証されるまでは、誰もできると思わなかった
    • 効率の美
      • 簡潔さは力なり Paul Graham
      • 言語の進化の方向は、頭の中のイメージをそのまま書ける方向へ
      • Brooksの生産性不変の法則(アセンブラでもRubyでも同時間で書ける行数は同じ => 実現できることは全然違う)
      • 本質に集中: やってるうちにやってることを忘れちゃうようなものはダメ
      • 実行可能な疑似言語 Ruby
    • DRY: Don't repeat yourself
      • 怠惰のための勤勉
      • 水鳥のごとく: 手抜きは美しくないが、苦労を見せびらかすのは粋じゃない
    • シンプルとはなにか？
      • 現実は複雑。人間が複雑。複雑さは不可避
      • 誰かが複雑さを引き受ければ、人が書くものは単純ですむ。 => 人間のためのソフトウェア
    • プログラマ=アーティスト
      • 歯車ではない。作業員ではない。創造的・自発的。
      • 内面の美: コードに内在。プログラマは関心を持って欲しい
      • 外面の美
      • 自覚が重要: 食べることと、クリエイティブであることとの両立
    • [感想]
      • コードをきれいに書くことの意義。わかる人が増えるといいな、と思う
      • 個人的に、JavaScriptのライブラリ(言語処理系実装じゃなくて使う方)のコードをみんなで読む会をやりたい (きれいに書きたい)
  • 一日目: 午後1: Open Webの進展とその今後 / Dylan Schiemann
    • Apps wants (アプリケーションに要求されるもの)
      • Web delivered (Webで配布できる)
      • useful (有用)
      • ...
    • It Depends (Webアプリがうまくいくケース)
      • Apps with Static Contents (静的コンテンツ)
      • Document-oriented workflow (ドキュメント志向の業務手順)
      • Text based content creation (テキストベースで内容を書く)
    • Dojoなら、アプリを高頻度でリリースできる
    • HTMLで難しいこと
      • â–³ 2D, オフライン/ストレージ, Comet
      • × Audio/Video, 3D, 画像変換
    • [ソースを表示]がなできかったら、Webである意味ないよね
      • テクニックを高速に学ぶことができる
    • DojoはJavaScriptにクラスを提供している
      • jQueryのメソッドチェーンは、HTMLの操作にはいいけど....
    • Browser Suck
      • しかし、競争が状況を改善している
      • IE8以外は進化が早い
      • IEのシェアは75%を割った
    • html, javascript (Open Web)
      • 一番普及したプラットフォーム
      • HTML5, ECMAScript 3.1
      • JavaScriptのエンジンが高速化して、ボトルネックではなくなった
      • CSS3はダメ
      • Flex/Silverlightはいいけど、長期的には独占の罠
      • モバイルのブラウザはHTMLであれば実行できる
    • 長期的な展望
      • IE独占は終わり、FireFox/Safariが増える
    • [感想] Dojo使ってみよう。DojoXに使ってみたい機能がいくつかあった。
      • 中期的にHTMLでほとんどのことができると思われるが、IEがIEがIEが
      • ブラウザもJavaアプレットもWindowsに標準で載ったことで普及したと言っていいと思うけれど、JavaはすでにSunが配布していて、FlashはAdobe。だったら、ブラウザもSafari/Chromeでいいじゃん、という気がする。
  • 一日目: 午後2: Amazon Web Services in Action / Jeff Barr
    • Speaker: Based on Seattle, Washington, USA. "Lifetime Technologist" Startups→Microsoft→スタートアップコンサル→Amazon
    • クラウドコンピューティング
      • over the Internet
      • Flexible / On-Demand / At needed basis / pay-as-you-go
    • クラウドが解決するもの
      • ITの摩擦(friction)を減らす: 契約、帯域、拡張、災害対策、電源/冷房 ...
      • 壊れた経済モデルの修復(Fix broken economic model): 投資からランニングコストに。実需対応、予測性。
      • 減らす: 急いでがんばる(hustule)、 潜在コスト、fear of success(ヒットしすぎて落ちないか不安)、納品待ち、白髪
    • Amazon Services
      • EC2
      • S3
      • SQS: Simple Queue Service - メッセージング
      • CloudFront - コンテンツデリバリ
    • AWS: Amazon Web Service
      • 完全にプログラマブルな"データセンタ"
      • すべての機能がAPI(XML, SOAP, REST/XML)でアクセスでき、セキュアに使える(HTTPS, Public/Private keys, X.500)
    • Elastic MapReduce
      • EC2
      • AWS の管理コンソールから使える
      • Hadoop のビジュアルインタフェース
    • AWSのリージョン
      • US East と EU West がある。Asiaは???
      • 域内に複数のデータセンタがあるようだ。AWSを使うときにどこを使うか選択できる
      • [補足] 距離が長いと通信が遅延するので、サービス相手と近いところでサービスする必要があるのだと思います
    • EC2 Elastic IP Addresses
      • public static IP Address
      • permanent Address
      • Complete control
    • EC2 Block Storage
      • ディスク 1GB から 1TBまで
      • S3へのSnapshot Backup をサポート
    • [感想] EC2/S3以来、Amazonのクラウド機能は進化して、実質的になってきていると感じる。リモートのデータセンターに必要な機能をすべて揃えてきている(揃えようとしている)のではないだろうか。うーん、すごいなぁ。
  • 3.years.of(:ruby) 実世界のRuby - 3年間の経験から/ Martin Fowler
    • 41個のプロジェクトをやった。
      • 2006-8
      • ほとんど20人、12ヶ月以内
      • atlanta project - 40人、2年以上
      • jersey - 20人強、２年半
      • mingle - 20人弱、２年半
      • だんだん大規模のプロジェクト
      • 2006 - 5-6人まで
      • 2007 - 25人のプロジェクト
      • 2008 - 30人超が１つ
    • Rubyは売り上げに貢献しているか？
      • Scott Conley: やり方を変えている。競争優位への触媒。agileで 第一級のプロを持っていることとの相乗効果。rubyはプロの良さを引き出す。ユニットテスト、ダッグタイピング、rake、capistrano。
    • Rubyは開発プラットフォームとしてどのくらい有用か
      • ThoughtWorks: Yes: 36, No: 5
      • Noの理由: no worse fo Ruby (慣れない新しい技術に対応するコストほどには改善がない)
      • Noの理由: .NETアプリケーションとのインテグレーションが難しかった
      • Noの理由: social issues (Rubyに反対している人がいた。IT部門に。)
      • ※他のツールとは比較していない
    • 有効性はどう改善するか
      • Improvement Ravine: 学ぶコストがかかり、いったん効率は落ち込むが、その後、急速回復し、高い効率になる
      • Ravine(è°·é–“)とつきあう: Ravineを予測し、経験を使う
    • 人材確保
    • Rubyの強みはメタプログラミングを行うためのツール
      • メタプログラミンング => 使えるようになると、やりすぎる。やりすぎを予測することが重要。実験場(Sandbox)とメンターが必要。
    • Monkey Patching
      • どのファイルで拡張したのかわからなくなる => moduleを使ってインクルードすれば class#ancesters でたどれるよ
    • Is a Ruby code base difficult to work with?
      • David Rice: クリーンなコード書ける。10人くらいのひとでもコードが共同所有できる。
      • Badri Janakiraman: 比較的に小さなチーム(テストがわかっている人)で始めた。チームを徐々に拡大。15人くらいのチームになった。Javaã‚„.NETよりシンプルなツールで十分。IDEがあればいいのに、という話にはなってない。Rubyのコードベースは管理しづらいということは、ない。40人のAtlantaチームでも
      • 最初は経験の豊富な小さなチームで始めるとよい。Rubyでなくてもそう
    • 生産性は?
      • Railsでかなり強引な主張があった
      • ThoughtWorks: 向上した 28 / そうでない 3
      • どのくらい？: 2倍というプロジェクトが多かった。1.5倍-5倍という人が75%以上
      • Rubyを使っているときに聞くと「まぁまぁ」C#に戻ったあとに聞いたら、「Rubyの方が2倍」という人もいた
      • Scott Conley: スコープを考えるアナリストが多く必要 = 開発チームの生産性は高い。
    • Is Ruby Slow?
      • Yes: JRubyとかで改善しているけど、やっぱり遅い言語
      • but: でも、Rubyがボトルネックになることは、ほとんどない。だいだいDBがボトルネックになる
      • 一部のプロジェクトでプロセッサの性能が問題になることがあった: mingle
      • David Rice: mingleは最新のデータを返す必要があったので、http要求でCPU100%を使い切りたい。その分高いマシンを買った。しかし、チームは年４回もリリースできた。リリースされる機能も多い。技術的な負債に縛られない。顧客はリリースを選択した。Rails2.3/JRuby1.1.7でスレッドセーフと性能改善がみこまれる
    • Testing with Active Record
      • オブジェクトとデータベースが一対一に。でも粗結合でなくなる。=> 理解するのが簡単になる。利点の方が多い。
      • テストに問題がある。DBアクセスは実行コストが高いので、テストが低速になる => スタブでDBをスタブアウトする。テストと戦う。
    • 80%はActiveRecordで対応可能だが、20%はSQLを書かないとできない場合(リーク)がある
      • ORマッパは万能ではない。特にパフォーマンス。
      • SQLを知らなくてはいけない
    • [感想] すごいチームが実際にRubyを使って生産性をあげている、という報告は、すごいと思う。「いまはすごくない」チームがやるときも、絶対に指針になるとおもう。
  • Ruby on Railsで変わるエンタープライズ開発の現場 / 大場寧子
    • 会場調査: 意外と、自社案件や受託開発で既に使っている人がおおかった
    • プログラマの主張: Rubyは楽しい -> 怪しい！(リスクが気になる) -> 楽しかろうが楽しくなかろうが、リスクには関係ないでしょう
    • 経営者がRailsを使う3つの理由
    • (すみません、メモとりすぎて長いので割愛します。たぶん資料がどこかででるのではないかと。)
    • [感想] 経営者視点で、Ruby/Railsの利用の価値やコストについてまとめていて、企業にいる人が社内の説得に使えそうなノウハウが詰まっていた。

一日目はここまでです。二日目はエントリ分けます。