得るものの多いカンファレンスでした。
スタッフの方、講演者の方、参加者の方、おつかれさまでした。
会場で取ったメモを置いておきます。
正確性はまったくあてになりませんので、そのあたりご承知のうえ、だまされたつもりでご利用いただければ。
あとプレゼン資料のメモが多く、著作権的にフェアユースの範疇なのかちょっとよくわかりません。ご指摘あれば対応させていただこうかと考えています。
- 一日目: オープニング
- QCon / InfoQ の説明と、午後のマルチトラックセッションの紹介
- Rubyトラックは角谷さん
- QCon / InfoQ の説明と、午後のマルチトラックセッションの紹介
- 一日目: 午前1: ドメイン固有言語 −その役割− / Martin Fowler
- DSLについての本をもう２年くらい書いている
- 年内いっぱいはかかりそう
- DSLs are everywhere
- Secret Panel: 部屋にはいって、電気をつけ、引き出しをあける
- External DSL (言語外DSL) と Internal DSL (言語内DSL)
- Command-Query API と Fluent API (流れるようなAPI)
- DSLとは
- 言語
- コンピュータプログラミング
- limited expressiveness (限定的な表現力) <= general purpose ではない
- focused on particular domain (特定領域に集中)
- write より read
- [感想] 最後の話(ノンプログラマが読めるDSL)は、すごく価値があることだと思います。いまはExcelで書いた表で会話しているかもしれませんが、そのまま動作すればその方が齟齬がない訳で。「Word/Excelからwiki/cucumberへ。」って感じ？
- DSLについての本をもう２年くらい書いている
- 一日目: 午前2: ビューティフルコード / まつもと ゆきひろ
- コードは設計である
- 職人芸、一品もの、善し悪しがある
- コードを書くための作業全体が設計なのに、その一部の作業を取り出して「設計」というのはどうよ。
- コードは実用品である
- 実用に供してなんぼ。用の美
- コードは読み物である
- コードは人を感動させる
- パワーの美
- 効率の美
- 簡潔さは力なり 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であれば実行できる
- 長期的な展望
- [感想] Dojo使ってみよう。DojoXに使ってみたい機能がいくつかあった。
- Apps wants (アプリケーションに要求されるもの)
- 一日目: 午後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
- Elastic MapReduce
- 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?
- 生産性は?
- Railsでかなり強引な主張があった
- ThoughtWorks: 向上した 28 / そうでない 3
- どのくらい？: 2倍というプロジェクトが多かった。1.5倍-5倍という人が75%以上
- Rubyを使っているときに聞くと「まぁまぁ」C#に戻ったあとに聞いたら、「Rubyの方が2倍」という人もいた
- Scott Conley: スコープを考えるアナリストが多く必要 = 開発チームの生産性は高い。
- Is Ruby Slow?
- Testing with Active Record
- オブジェクトとデータベースが一対一に。でも粗結合でなくなる。=> 理解するのが簡単になる。利点の方が多い。
- テストに問題がある。DBアクセスは実行コストが高いので、テストが低速になる => スタブでDBをスタブアウトする。テストと戦う。
- 80%はActiveRecordで対応可能だが、20%はSQLを書かないとできない場合(リーク)がある
- ORマッパは万能ではない。特にパフォーマンス。
- SQLを知らなくてはいけない
- [感想] すごいチームが実際にRubyを使って生産性をあげている、という報告は、すごいと思う。「いまはすごくない」チームがやるときも、絶対に指針になるとおもう。
- 41個のプロジェクトをやった。
- Ruby on Railsで変わるエンタープライズ開発の現場 / 大場寧子
一日目はここまでです。二日目はエントリ分けます。
