この記事では、QCon San Francisco（2008年11月）の印象とその体験がどのようなものであったかを感じ取っていただけるように、QConについて(リンク)ブログを書いた(リンク)多く の参加者の視点と見解を紹介します。最初のチュートリアルから最後のセッションまで、彼ら自身のブログでQConの多くの局面について議論しています。ま た、FlickrではQConの参加者が撮影した多数の写真(リンク)を見ることができ、TwitterではQConに関して投稿された数百に及ぶ「さえずり」(リンク)を見 ることができます。
このQConは、InfoQの4回目のカンファレンスであり、サンフランシスコでは2度目の開催でした。このイベントは、デンマークのJAOOカンファレ ンス主催者であるTriforkと共同で開催されました。登録参加者は460人を超え、参加者のうち60%がチームリーダー、アーキテクト、およびそれ以 上の役職者でした。80%が北米から、20%がヨーロッパ、アジア、南米から参加していました。Kent Beck氏、Martin Fowler氏、Tim Bray氏を含め、100人以上の講演者がQCon San Franciscoで講演しました。QConは毎年11月頃アメリカにて開催され続ける予定であり、また、2009年3月11日～13日には、QCon London(リンク)が開催される予定です。
目次
チュートリアル
* 実践的なErlangプログラミング
* Certified Scrum Master
* JRubyおよびJRuby on Railsを始める
* ドメイン固有言語
* アジャイル管理の禅
基調
* Martin Fowler氏とRebecca Parsons氏: アジャイリストとアーキテクト -- 味方は敵対者ではない
* Kent Beck氏: 今に分かる
* Tim Bray氏: シフトするストレージ領域におけるアプリケーション設計
インタビュー
実際に使えるRESTFul Web統合
* HTTPステータスレポート
* RESTfulエンタープライズ開発
* ErlangおよびYawsを使ったRESTful Webサービスの構築
* 現実世界のRESTの導入
* RESTを使ったエンタープライズITシステムの設計
ソリューショントラック
* アーキテクチャ管理の黄金律
* オープン標準の開発: チャンスか制約か?
パフォーマンスとスケーラビリティ
* パフォーマンスとスケーラビリティについての設計: パネルディスカッション
アジャイルになること
* チームワークは個人のスキルである: 時を選ばずチームを作る方法
* アジリティ: 個人レベルでの可能性
* 反応のよい設計
* 超越およびゲートの通過
エンタープライズ向けRuby
* MERB: 柔軟性とパフォーマンスが重要になるとき
* エンタープライズ向けのRailsのスケーリング
クラウドコンピューティング: プラットフォームとしてのWeb
* プラットフォームとしてのWeb: 市況
* Google App EngineおよびGoogle Data API
* "組み合わせる" - 結合、メッセージング、会話
機能的および並行プログラミング言語の適用
* Haskellと芸術
* 強く型付けされたドメイン固有埋め込み言語
* Buy a Feature: 不変性とActorの冒険
* 原理主義の関数型プログラマ
効果的な設計およびクリーンコード
* ビヘイビア駆動開発 - 効果的な設計およびクリーンコードへの道
* コードを改善する10の方法
* 多言語およびマルチパラダイムプログラミングによるRadical Simplification（超単純化）
現実世界でのRIA: クライアントの進化
* Hard Rock: Silverlight 2を使用した音楽の裏側
* 溝の中の柔軟性と空気: 現実世界のエンタープライズ体験の6ヶ月間
* 現実世界のGWT: LombardiがGWTを使ってBlueprintを構築した理由とあなたが次のRIAにそれを使用すべきである理由
ドメイン駆動設計
* C#による.NETドメイン駆動設計: フレームワークの内部で作業しながらドメインモデルをクリーンに保つ方法
* DDDを使ったguardian.co.ukの再構築
* ドメインの枷をはずす
* 戦略的設計
実際に使えるDSL
* Erlangでのドメイン固有言語
常日頃から疑問に思っているアーキテクチャ
* Digg.comソフトウェアアーキテクチャ
* Facebook: サイエンスとソーシャルグラフ
* マシンに釣りを教える: eBayが自ら向上する方法
.NET空間における選択肢: オープンソース、フレームワークおよび言語
* 寿命の長いコードベースの喜びと痛み
* F#入門
* DbC世界におけるTDD
* Volta: どこでも分散.NET
データストレージの再考: ドキュメント指向分散データベース
* 10,000ftからのCouchDB
Javaの新生テクノロジー
* コンカレントからパラレルへ
* パネル: Javaにおけるオープンソースの傾向は設計と開発プロセスにどのように影響するか?
* Hibernateのスケーリング
アジリティのスケーリング
* Fossaの解放: 野心的な文化におけるアジャイルのスケーリング
ソーシャルイベント
QCon自体に関する意見
QConをきっかけとする考え
結び
チュートリアル(リンク)
実践的なErlangプログラミング
Ola Bini氏(リンク)は、このチュートリアルを楽しみました。
私は、自身のチュートリアルを公表する前である午前中に、Erlangチュートリアルに参加して過ごしました。このチュートリアルは面白かったです。Francesco氏は非常に良い先生であり、私たちは多数の教材を利用しました。
Certified Scrum Master(リンク)
Srini Penchikala氏(リンク)は、このクラスを楽しみました。
私は、Object Mentor(リンク)プロジェクト管理チームのMartine Devos氏(リンク)が主催したCertified Scrum Master（CSM）(リンク)に参加しました。Martine氏は素晴らしいCSMトレーナです。このチュートリアルクラスは、技術管理部に所属しアジャイルプ ロジェクトマネージャを目指す人々にとって、とても勉強になり為になるものでした。このクラスは対話式であり、受講者はいくつかの現実世界のプロジェクト 管理シナリオにおいて他のグループと互いに議論することができるものでした。
JRubyおよびJRuby on Railsを始める(リンク)
Bjorn Rochel氏(リンク)は、このチュートリアルに参加し、次のように述べています。
この話の中で特に面白かったことは、JRubyとJavaに適用されるもののほとんどがIronRubyと.NETにも適用される（適用されることになる）という事実です。
- 既存のITインフラストラクチャの再利用。そう遠くない将来、Railsは.NETおよびIIS上で実行できるようになるでしょう。稼働させるために、既 存のRubyインフラストラクチャは不要です。新しいサーバー/インフラストラクチャのどのようなノウハウも、.NET環境でRailsを実行するために 必要にはなりません。
- 静的に型付けされたプラットフォームとRuby間の両方向における統合。C#は動的に型付けされたコード（動的なC#キーワード）を統合できるようになり、純粋なRubyアプリケーションは.NET上で実行可能になります。その上、IronRubyは、.NETフレームワークライブラリのファンタスティックな統合を得て、Ruby概念で.NET世界に関する視野を広げることができるでしょう（それはモンキーパッチと呼ばれると思います）。IronRubyからの.NET型の開始と拡張、および.NET Frameworkに組み込まれた型のメンバーのスネークケーシングのサポートは、良い特徴の一部です。
ドメイン固有言語(リンク)
Ola Bini氏(リンク)は、このセッションに参加しました。
このチュートリアルには何度か参加していますが、どんどん良くなっています。特に、構文解析に関するRebecca氏の部分は、今回とても洗練されたものになったことが分かりました。もちろん、彼らは皆素晴らしいプレゼンターです。
Chris Patterson氏(リンク)は、次のように述べています。
私が気に入った要点は、内部DSL用に示されたスタイルでした（fluent interface（流れるようなインターフェース）とも呼ばれます）。内部DSLは、新しい文法を作成するのではなく言語自体を使用して構築されます。 fluent interfaceの優れた例は、FluentNHibernate(リンク)プロジェクトやStructureMap(リンク)のレジストリDSLなど、多数あります。内部DSLの即値は、このインターフェースのスタイルを使用して記述されたコードを読み取って把握したものです。
アジャイル管理の禅(リンク)
Razvan Peteanu氏(リンク)は、次のように、このチュートリアルの詳細な概要をまとめました。
丸一日行われるクラスのテーマは単純です。悪い管理は他の何よりもソフトウェア開発をダメにするということです。事実、十分な区別と知識なしで決定を行うと、ソフトウェア開発だけではなく、すべてをダメにしてしまうということは、分かりきったことです。
強調する点は、「他の何よりも」というところです。完全ではありませんが、分別よく実行されたアジャイルアプローチは、開発者自身にもはや厄介な問題は存 在しないほど十分に機能しています。開発の管理法を確定すべきときです。そして、人間性を考えると、プログラミング方法論への対処は簡単な部分でした。
基調
Martin Fowler氏とRebecca Parsons氏: アジャイリストとアーキテクト -- 味方は敵対者ではない(リンク)
多くの人がこの基調について書いています。Denis Bregeon氏(リンク)もその1人です。
私はこの話について最も強い1つの考えを持ち続けるでしょう。エンタープライズアーキテクチャは多数のステークホルダーの中でアプリケーションのステーク ホルダーであるということです。そして2つ目に強い考えは、エンタープライズアーキテクトは会社の技術的なポートフォリオの横方向の視点を示すのに役立つ ということです。
Ola Bini氏(リンク):
Martin氏とRebecca氏による水曜日の基調は、アーキテクチャについてと、アジャイルがいかにしてアーキテクチャグループの問題に役立ち、大規 模な組織に存在することの多い開発者とアーキテクトの間のギャップを埋めることができるかに関するものでした。とても良い出来でした。
Chris Patterson氏(リンク):
QConのメインカンファレンスは水曜日に開始され、ThoughtworksのMartin Fowler氏とRebecca Parsons氏による基調で始まりました。トピックは、「アーキテクトとアジャイリスト - 味方は敵対者ではない」でした。そのタイトルから推測できるように、この話は、象牙の塔に住むアーキテクトとソフトウェアデリバリーを担当するチームとの 間に協力的な関係を築くことに焦点が当てられました。映画「マトリックス」のネオがアーキテクトに会うシーンが背景として使われ、2つの職務間の主な断絶 を浮き彫りにした後に多数のソリューションが提示されました。私は、コーディングしないアーキテクト（NCA）は実際にコードを記述する人の問題を理解し ている人と比べるとまったく能力がないと固く信じてきました。
Jeremy Miller氏(リンク):
彼らは、アーキテクトを支援するためにアジャイルが提供できる透過性と付加的なデリバリーメカニズムについて非常にうまく説明したと思います。しかし、提 案を機能させるためには、大企業はソフトウェアを構築する人々に対する態度を劇的に変える必要があると思います。多くの企業は現在よりもはるかに多くの点 で実践のスキルとアプリケーションアーキテクチャのスキルを保持する必要があります。
Eric Smith氏(リンク):
アーキテクチャに関する問題の一部は、定義しにくいという点です。より重要に聞こえるように言いたいときは、単に設計と言えるかもしれません。私は以前よ く一緒に働いた、アーキテクチャがすべてという男を覚えています。「あなたがこの2つのクラスのアーキテクチャについて考える場合...」Martin氏 は、困難なことについて特定の組織に起こることは何でも考える人としてRalph Johnson氏のアーキテクトの定義を気に入りました。
別の問題は、アーキテクトは役割の成功を定義することに苦労し、それを実現することにもっと苦労するということです。時にそれは、アーキテクトはコードを 記述しないと主張する会社のような、組織的な機能不全のせいです。またある時には、まだ証明されていない必要性を予想してフレームワークを考案するよう な、お粗末な実践によるものです。
Erik Rozendaal氏(リンク):
QCon San Francisco 2008カンファレンス(リンク)は、Rebecca Parsons氏(リンク)とMartin Fowler氏(リンク)による面白い基調で開始されました。彼らは話の中で、伝統的なアーキテクトとアジャイル開発の間のギクシャクしがちな関係と、アジャイル開 発チームとアーキテクト両方の利益のためにこの関係を改善する方法について扱いました。これらの利益には、プロジェクト間および部門間での知識交換、アー キテクトと開発者との何年もの経験の共有、および実際に必要なアーキテクチャのみへの取り組みが含まれます。
Omar Khan氏(リンク):
私は2pathsでポリシーについて考えさせられました。皆が、ある程度コーディングを行います。私自身アーキテクトとして、大量のコードをコーディング しないかもしれませんが、コードを開発します。このため、設計の決定を行う際に私の意見が関係します。皮肉にも、状況を修正するための提案はまさに次のこ とでした。アーキテクトは、devチームの一部でなくてはならず、毎日または毎週、理想的なケースコードで、開発/登録されたコードを調べる必要がありま す。
Razvan Peteanu氏(リンク):
講演者によって指摘された別のより微妙な問題は、時間が経過してあなたが40代でまだ開発において開発中であるなら（管理と対比）、あなたがほとんど失敗 しているという暗黙の推定により、経験豊富なプラクティショナーを追放してしまうことです。多年にわたるスキルの成長は社会的に受け入れられますが、期待 は昇進することに移行し、コーディングを「若者のもの」として残していきます。
しかし事態はそれほど単純ではありません。多くの環境において、EAは彼らの肩書きがかかわるアーキテクチャを良く把握しています。彼らは、幅的にも時間 的にも、より広いビジョンがあります。低いレベルの目標を支持してそのような知識を無視するのは、誤りでしょう。問題は多くの場合、EAがいかに開発チー ムと協働するかにあります。アドバイスや図表なしで判断を下す愚か者は、信用も、機能するアーキテクチャも作らないはずです。信用がなければ、アジリティ はありません。
The Register(リンク)も、この基調について取り上げました。
「たまにこの話をすると、人々は私がアーキテクトに厳し過ぎると言います」と、Parsons氏は述べました。「しかし私は、アーキテクトは非常にやりが いのある仕事についていると理解しています... アーキテクトは非常に難しい立場に置かれており、一般に組織は彼らに害を与えています。」
「これについて自覚すべき重要なことは、問題が組織的なものであるということです。」と、Fowler氏は言い足しました。「それは組織がどのように設定 されているかについてであり、そのシステムの中に閉じ込められた個人の失敗についてではありません。あなたのスタッフがどんなに優れているとしても、あな たはいつでも悪いプロセスで彼らを台無しにすることができます。」
Kent Beck氏: 今に分かる(リンク)
Eric Smith氏(リンク)は、この基調について次のように書いています。
彼の話は、傾向を見て、進む可能性のある所や予期せぬ結果を想像するという、素人の未来思想家としてのものでした。たとえば、もしあなたがより頻繁にソフ トウェアリリースの傾向を広げたら、何が起こりますか? キーストロークごとにソフトウェアをリリースするでしょうか? OK、ライブWebサイトの編集はほとんどそれでしょう（編集者が継続的に保存した場合）。
彼が予測するその他の傾向の一部として、Web上の「無料の」ものの終了、人々が技術をより深く理解し始めてプログラミングがそれほど不可思議ではなく思 えることによるプログラマの地位の低下があります。その後者の点が真実だと分かっても、我々はまだ、何を構築しそれをどのように構築するかで世界に影響を 与えることができると、彼は言います。
Razvan Peteanu氏(リンク)は、次のように書いています。
Beck氏は再び夕方の基調で話をしました。コンピューティングの傾向と、今日の展望の主要部分のいくつかは過去数十年にわたり楽しんだ長期に及ぶ「全盛 期」から下落しないのかどうかについてです。1つの例は、薄っぺらのアプローチについてますます不評になりつつあるリレーショナルデータベースです。しか し、こうした例は主にGoogleとAmazonの世界からのものであり、MapReduce(リンク)によるデータ処理ではなく、ユーザートランザクションが標準である典型的なOLTPシステム（およびデータベーススキーマの「レガシー」警告ラベル）を対象としていません。
Tim Bray氏: シフトするストレージ領域におけるアプリケーション設計(リンク)
何人かの人が、この基調について論じました。Martin Fowler氏(リンク)もその1人です。
先週QCon(リンク)で、この仮定を問題として取り上げた脈絡のある話がありました。確かに、私の心を打ったものはTim Bray氏(リンク)の基調でした。その基調はデータ管理のいくつかの側面にわたる行程(リンク)でした。その際に、彼は多くの面白いプロジェクトを紹介しました。
- Drizzle(リンク)は、リレーショナルデータベースの一種ですが、現代のリレーショナル製品の機構の多くを避けているものです。私はそれを、リレーショナル機能セットの必要最小限しかサポートしない、RISC RDBMSと見なしています。
- Couch DB(リンク)は、分散したキーと値のペアモデルへの多数の進出の1つです。鋭くシンプルなデータモデル（実際にハッシュマップにすぎない）ですが、この種のアプローチは大容量のWebサイトでかなり人気となりました。
- Gemstone(リンク)はオブジェクトデータベース系の1つでした。私はGemstoneとSmalltalkの組み合わせが非常に強力な開発環境である（大半 の後継物よりも優れている）ことに気付きました。Gemstoneは、ニッチ市場の参入者としてまだ活躍していますが、Maglev(参考記事) - そのアプローチ（本質的にはデータベースと仮想マシンの融合）をRubyの世界にもたらすプロジェクトによって、さらに勢いを増す可能性があります。
Brendan Quinn氏(リンク):
しかし、Tim氏を本当に興奮させたものは、いかに高速にソリッドステートが適切なファイルシステム上に存在できるかに関する印象的な統計(リンク)（少しばかり、 彼の雇用主であるSunがリリースした新しいサーバーの宣伝でした）、SSDにその一面としてムーアの法則があるという事実もありました。 「spinning rust」と対照的に、SSDはすべてシリコンであるため、時間がたつにつれて価格/性能が向上するだけでしょう。
Tim氏が言うように、「皆さん、あなた方は将来を見据えています。」
Eric Smith氏(リンク):
彼はO/RマッピングレイヤとSQLエンジンに主に焦点を合わせました。そこでの技術は、Tim氏の言葉を引用すると、「最低（sucks）」です。 O/Rマッピングは本当に困難で、オブジェクトデータベースが商業的成功をまったく得なかったほどひどいものです（最前列のMartin Fowler氏は同調してうなずきます）。SQLエンジンは、memcachedのような分散ハッシュテーブルへ導くことや、データベースエンジンを完全 にスキップしてファイルシステムに進むことさえも、遅過ぎます。また、SQLエンジンは複雑で、決して使用されない機能を積んでいます。これは、スリム化 を試みてMySQLから派生したデータベースであるDrizzleのようなプロジェクトを引き起こしています。
また、Tim氏は、HTTPでのみアクセス可能なドキュメント指向データベースであるCouchDBについての良い面を言っていました。私はこのプロジェ クトに関して何も知りませんが、Tim氏の正確な言葉は「私はこれに夢中になっている」と「驚くほど洗練されている」でした。
Jnan Dash氏(リンク):
- アプリケーションコードとディスク/キャッシュ間で、伝統的なレイヤは次のとおりです - オブジェクト/リレーショナルマッピング、SQLエンジン、OS &ファイルシステム。レイヤ間における移動は次のとおりです - アプリケーションコードからO/Rマッピングへ、次にSQLからSQLエンジンへ、次にタプル（tuple）からOS &ファイルシステムへ、そして最終的にバイトからキャッシュ/ディスクへ、オブジェクトが移動します。
- これらのレイヤはレイテンシーとオーバーヘッドを加えるため、何百万人ものユーザーに応じるWebアプリケーションにとって大きなボトルネックになりま す。したがって、あるアプリケーションコードがキー/値ペアのハッシュテーブルを直接操作しています。このアプローチでRDBMSよりも100倍速くなる と主張しています。
- アプリケーションコードはO/Rレイヤ（これは困難）を迂回してRDBMSに直接マッピングできます。PHPもそれを行いますが、恐ろしく醜いです。
- アプリケーションコードがデータベースレイヤ全体を迂回して、OSやファイルシステムに直接進むことについてどう思いますか? XML、JSON、プレーンテキスト、およびメディアファイルを使用します。
Omar Khan氏(リンク):
その日はTim Bray氏の話から始まりました。それは、データベースとデータアクセスおよびデータベースの進化とそれらを使用するシステムを設計する際に留意すべきこ とについての話でした。彼は、データベースから検索されたデータの分散キャッシュとして、有名なあらゆるWebアプリケーションで採用されている MemCacheDの使用などのテクニックを紹介しました。彼は、データベースサーバーや最終的にGoogles BigTableの ようなカラム指向データベースの動作を低下させる、主要なデータベースで誰も使用しないすべてのものを取り除いた、軽量のデータベースDrizzleにつ いて話しました。概して、彼は、さらなる調査に値するデータベースレイヤの技術について深い洞察力を与えてくれました。
Denis Bregeon氏(リンク):
私にとって、それは解放的な話でした。まず、私は、慣れ親しんだRDBMSタイプに戻るという反射的行為により、ストレージについて十分に考えない癖がつ いていました。そしてこれは、私の現在のプロジェクトに多大な時間と労力をかけています。Tim Bray氏は、ストレージ階層の各ポイントで利用可能なストレージの選択肢を提示することによって、その考えを何とか15分で打ち破りました。
たとえば、オブジェクトを永続化する必要がある場合、一体なぜオブジェクトリレーショナルマッピングとRDBMSに進むのでしょうか? なぜ直接ファイルシステムを使用しないのでしょうか? 余談ですが、私の現在のプロジェクトでは、システム管理者がファイルシステムの複製を機能させることができなかったため、RDBMSに戻る必要がありまし た!
The Register(リンク)も、この基調を取り上げました。
圧力のかかったスタックの将来はどうなるでしょうか? 「すべては動く標的です。」と、Bray氏は言います。「しかし、それは、このビジネスに携わるチャンスを意味します。あなたは現金を支払う人々に対し、 重大でnon-trivialなWebアプリケーションを構築する場合に、Java EEまたは.NET、およびすぐに使えるORや、Oracle、種々様々のものを使用する必要がありました。最近は、そうしたことをする必要がなく、あな たを変わり者のような目で見る人はいないでしょう。それは良いことです。」
インタビュー(リンク)
Razvan Peteanu氏(リンク)は、インタビューの1つに参加しました。
Yoder氏は、より一般的なモデルを作ることによってビジネスルールを変えるための設計方法について話していました。最後にインタビュアーが突然振り 返って私に何か質問がないか尋ねました。そこで私は、2分間有名になりました。（Andy Warholの言葉「誰でも人生で15分間は有名になれる」ので、）残りは13分です...
実際に使えるRESTFul Web統合(リンク)
Steve Vinoski氏(リンク)はこのトラックを楽しみました。
Jim Webber氏(リンク)は、RESTトラックをまとめ上げて展開しました。それは私が今までに参加した中で最も良いトラックの1つでした。Mark Nottingham氏(リンク)はRESTとHTTPの分野において非常に知識が豊富であるため、彼はHTTPおよびHTTPbisグループ(リンク)の取り組みに関する非 常に有益な話をしてくれました。Ian Robinson氏(リンク)とStu Charlton氏(リンク)は共に、企業におけるRESTの使用（否が応でもやって来る）(リンク)について話しました。Leonard Richardson氏(リンク)は、RESTfulサービスの品質を判断する方法について話しましたが、私は彼の話の大部分を逃してしまいました。脚を崩しに外へ 出た後、部屋が満員で戻ることができなかったからです! 私はREST、Erlang、およびYaws(リンク)を使った仕事について話しました。QConのサイトからこのトラックのスライドセット(リンク)をすべて入手できます。
Jim Webber氏(リンク)も同様に楽しみました。
QCon RESTトラックは、多くの講演者や参加者がブログに書いているとおり、とても素晴らしかったです。役に立たない話は1つもありませんでした。
HTTPステータスレポート
Brendan Quinn氏(リンク)は、このプレゼンテーションについて、次の内容を含む詳細なメモを取っています。
HTTP/1.1は基本的に0.9と1.0の「ダメージを含む」ようにしか記述されませんでした（vhosting、永続化、キャッシング）。Mark氏 はWS-*スタックに関与したのですが、彼は部屋の皆に自身の罪について丁重に謝りました。SOAPなどに関する面白いコメントは、「プロトコルにおいて 大きな拡張を可能にすることは、社会的に無責任です - プロトコルは取り決めがすべてです」というもので、あなたは有用なものにするために線を描く必要があります。彼が基本的に言っていたことは、WS-*は、 あなたに好きなようにさせ、極端なケースを可能にするためだけに正常なケースを難しくし、やり過ぎることをあなたに許可するということです。（そのような 感じで、彼が自ら説明するブログ投稿があれば、私は彼の言葉を言い換えずに喜んでそれにリンクを張るでしょう。）
Mark氏は、RESTful APIが「プロトコル構築ツールキットとしてHTTPを使用する」という素晴らしい言い方を心得ていました。それらはHTTPの上に構築されず、HTTPの一部として構築されます(ある意味では)。
Jim Webber氏(リンク)も同様に、次のようなメモを取っています。
- URIの長さ制限 - 一部のクライアントは256文字ほどと短い。大半のクライアントは非常に長いURIを許可している。仲介機関は様々である - 通常4～8Kbである
- 人々は、キャッシュ可能性を犠牲にして、POST（entity bodyサイズに制限がない）でクエリを送信することになる - 問題にはならないかもしれない
- 一部のフレームワークはこのアンチパターンを具現化している
- HTTPbisは8KbのURIを推奨
- ヘッダーにはある程度の長さ制限がある（Squid: 合計20Kb）
- ヘッダー行の連続は支持されるものではない - HTTPbisはそれらを制限する
Eric Smith氏(リンク)も、この話に参加しました。
私は、有名なman boobs専門家のJim Webber氏が進行役を務めるRESTトラックに少し参加しました。このセッションの講演者は、HTTPbisワーキンググループの議長であるMark Nottingham氏でした。彼らは、基本的にはHTTP 1.1仕様を書き直しますが、新機能を加えようとしません。なぜわざわざそんなことをするのでしょうか? Mark氏は、既存の仕様が不明瞭で、あまりよくまとめられておらず、あまり分かりやすいものではなく、時には理解するために作成者との相談が必要になる ことがある、と説明しました。その結果、皆は主要部分をきちんとほぼ理解していますが、実装間であまり相互運用性がないその他多くのものがあります。およ そ6ヶ月の完成を目標とするHTTPbisは、うまくいけば、不適合を十分に排除した仕様を明確にするでしょう。
また、Mark氏は、スタンダードセットのような適合性テスト、より良い認証、TCPではなくSCTPによる伝送など、HTTPの将来に期待できることについて簡単に話しました。
RESTfulエンタープライズ開発(リンク)
Jim Webber氏(リンク)は、この話から、次の内容を含む詳細なメモを取っています。
InfoQの「Restbucks」/「How to get a cup of coffee」の記事は、Gregor氏の記事を再構成したバージョンで、よりREST様式なものに構成されている。 非常に多くのバックオフィス機能が関与: オーダー管理（注文の調達を監督する）、インベントリ（店内に在庫を保持する）、プロダクト管理、地域配送（様々な場所に配送する）、など。 「Terrorist Cell Services」 - サービスデプロイメントに吹き込まれる3層のアーキテクチャとは対照的に、必要とするすべての仕事を行う自己完結的なもの。 サービスが自己の仕事を行うために、誰が何を知る必要があるか? オーダー管理は、仕事を行うプロダクトを把握する必要がある... 多くのもの（分散アプリケーションさえも）がこれらのサービスの1つの内部を構成するかもしれないが、この議論はサービスの境界相互作用に関するものである。
ErlangおよびYawsを使ったRESTfulの構築(リンク)
im Webber氏(リンク)は、この話から、次の内容を含む詳細なメモを取っています。
- YAWS - Yet Another Web Server - 動的なコンテンツの提供に役立つ; 埋め込み可能、またはスタンドアロン
- 動的コンテンツ - .yawsファイルにHTMLでタグを埋め込むOut関数 - アプリケーションをWebサーバーにつなぐ - argレコードは接続の詳細をアプリケーションに与える - 大きなタプル
-
- Ehtmlは、乱雑になるタグを埋め込むのを避けて、代わりにErlang構文でHTMLを記述する - タプルのタプル空間必須のEmacs rant
-
Appmods - アプリケーションモジュールは関数をエクスポートする。設定ファイルで1つまたは複数のURIに結合されている。Yawsは、URIに登録されたすべてのappmodsについてOut関数を呼び出す -
現実世界のRESTの導入(リンク)
Jim Webber氏(リンク)は、この話から、次の内容を含む詳細なメモを取っています。
- どこまでスタックを上がるかを確認することによって、大まかにサービスを判断できる: URI->HTTP->HTML（ハイパーメディア）
- レベル0 - 1つのURI、1つのHTTPメソッド - SOAPなど
- レベル1 - 多数のURI、1つのHTTPメソッド - （人々はURIを気に入っているため、まだ気に入られていない）大半のRESTfulサービスなど
- レベル2 - 多数のURI、それぞれ複数のHTTPメソッドを持つ - Amazon S3など
- レベル3 - リソースは独自の機能と相互接続を説明する - AtomPubなど
- Webは多数のURIを介して複雑性の分解を可能にし、HTTPは読み取り操作（GET）と書き取り操作（その他すべて）をパーティション化することで複雑性を分割する。これらを構成すると、高性能システムがもたらされる
- GETは制約されるため重要であり、そのためあなたは最適化することができる（レベル1サービスはこれらの制約を無視する）
- HTMLはGETとPOSTについてしか知らない - より特定の拘束と最適化機会との間の緊張関係、クライアントは拡大したボキャブラリを理解していない
RESTを使ったエンタープライズITシステムの設計(リンク)
Jim Webber氏(リンク)は、この話から、次の内容を含む詳細なメモを取っています。
- 課題はRESTを企業に適用することである - 企業は、特にMOM/Component/SOAP空間にいるため、まだそれを考えていない - 大きな頭痛の種はハイパーメディアである
- ハイパーメディアは単にシステム間の異種の抽象化であり、メッセージパッシングの上のレイヤである
- RESTはファイル転送ではない - CRUDを上回り、汎用システム用のソリューションである
-エンタープライズアーキテクチャは階層化されている（データ、ビジネスサービス、プレゼンテーション）
- Webアーキテクチャはこれらのサイロをあいまいにするが、すべての問題を解決するというわけではなく、いくらかの矛盾がある
- Webアーキテクチャには、典型的な企業制約にマッピングされる可視性、トランザクション、シンジケーションがある
- 典型的なサービスのインターフェースにはプロデューサー志向の考え方があり、インターフェースはコンウェイの法則のような考え方に類似している
- 代わりに消費者中心の契約に移行する - 聴衆のIan Robinson氏が同意している
ソリューショントラック(リンク)
アーキテクチャ管理の黄金律(リンク)
Kelvin Meeks氏(リンク)は、このプレゼンテーションの要約を書いており、それには次の内容が含まれています。
アーキテクチャの衰退 - 基本法は?
アーキテクチャの衰退は既知の問題を引き合いに出します。
- システムの知識とスキルが均等に広がっていない
- 複雑性がサイズよりも速いペースで増している
- 不要な依存性が気付かれることなく作られている
- 結合と複雑性が急速に増えている
衰退しているアーキテクチャの典型的な兆候は、高度の結合と多くの周期的な依存性です
- 変更はますます困難になる
- テストとコードの理解がより困難になる
- あらゆる種類の配備の問題
オープン標準の開発: チャンスか制約か?(リンク)
このパネルディスカッションは、様々なサイトで取り上げられました。以下は、InfoQ(参考記事)からの引用です。
聴衆から2、3人が、スペックリードは外へ出てコミュニティを推進する必要があると言及した後、InfoQのチーフエディターであるFloyd Marinescu氏は、JCP委員会は決定に関するより「民主的なアプローチ」のために世論調査を主催することを考えているかどうかについて尋ねまし た。Patrick Curran氏はそれを考えていないと返答しましたが、JCPサイトの次のバージョン用に開発された新しいコラボレーションツールを使えば、いろいろな参 加方法があるという意見を述べました。
聴衆のうちかなり多くの人々がOSGi(リンク)上のJava Modularity(リンク)の選択とそれがいかに混乱を引き起こすかについて否定的な意見を述べました。Patrick Curran氏は、自分はその分野のエキスパートではないがこの決定につながったいくつかの技術的な理由があると言って、Java Modularityの選択を擁護しました。
The Register(リンク):
1時間のディスカッションはJCPの開放性と初心者レベルの参加の障壁に関する懸念が争点となりました。Janssen氏は、ユーザーグループにとって JCPに参加することは費用が高いため難しいと不満を言いました。Van Riper氏は、参加費を分散させるためにJUG USA統括組織の創設を提案しました。また、彼は、JSRに関わっていなければJCPにおいて真のコミュニティ感情は得られないと不満を言いました。 Ashley氏は、JCPには公への開放性が欠けていると指摘しました。Horstmann氏は、その懸念に同調し、標準化プロセスにおける透明性の重要 性について強調しました。
議論が標準化に変わると、Venners氏は、言語の標準化は複数の実装がある場合にのみ価値を高めると主張しました。多くの場合、言語適合キットは十分 です。Rosenthal氏は、標準化組織を働かせる鍵となるのは、基本的なチームワークの原則であると主張しました。Reid氏は、ドキュメントを障害 のあるコンピュータユーザーが利用しやすいものにする、自身の組織の仕事について話しました。
InfoWorld(リンク):
JCPの他の部分で、Curran氏はJava Platform、Standard Edition 7におけるすべての作業がオープンソース手法でJava Development Kitコミュニティによって行われると述べました。
JCPにも、Java標準開発プロセスにおけるより良いコミュニケーションのためのコラボレーションツールが用意されています。「私たちは、専門家グルー プが内輪で、そして一般会員との間でもう少し容易にコミュニケーションを図ることができるように、jcp.org上でフォーラムなどを提供するつもりで す。」と、Curran氏は述べました。
専門家グループは密室で活動しているということが懸念されていると、Curran氏は言いました。さらに、ツールは現在テスト段階にあり、2ヶ月ほどで入庫される予定である、と言いました。
パフォーマンスとスケーラビリティ(リンク)
パフォーマンスとスケーラビリティについての設計: パネルディスカッション(リンク)
Omar Khan氏(リンク)は、このパネルディスカッションに参加しました。
次は、スケーラビリティに関するパネルディスカッションでした。あなたが設計しているシステムのアップデート要件を理解する必要性について強調するものでした。彼らは、次の2種類の設計があるということを提案しました。私は選択肢#2に 取り組むかどうか分かりませんが、彼らは、何人のアーキテクトが防弾の要件がないときに防弾になるものを設計するかについて説得力のある主張をしました。 私はその原則に完全に同意します。彼らは、妥協点を持つことについて非常に良い決定を行ったflickrなどのいくつかのWebサイトについて触れまし た。
- 前もってスケーラビリティを考慮して設計する
- 単純さを考慮して設計し、ボトルネックが出現したときにそれらに対処する
Razvan Peteanu氏(リンク)も参加しました。
ほとんどの参加者はベンダーのCTOで（TerracotaのAri Zilka氏は話の上手な人である）、Brian Goetz氏はほんの数分前にやって来ました。パネルディスカッションは、Bruce Eckel氏がBrian氏に質問を投げ掛けて始まりました。その後、スケーリングを可能にするデータのパーティション化について、良い会話がありまし た。パネルディスカッションの時間がもっと長ければよいのにと思います。1時間では短過ぎて、興味深い多くの会話を展開させるチャンスが得られません。非 常に高度なスケーリングとスケーラビリティには、聴衆の興味をそそる何かがあります。おそらく、技術的な制限を推し進めるとコンピュータサイエンスがあま り魅力的でないビジネスソフトウェアに戻ってしまうからでしょう。
アジャイルになること(リンク)
チームワークは個人のスキルである: 時を選ばずチームを作る方法(リンク)
Martin van Vliet氏(リンク)は、このプレゼンテーションを楽しみました。
QCon初日に私が最も良いと思ったセッションの1つは、Christopher Avery氏(リンク)による「チームワークは個人のスキルである」という話でした。この話は、私たちが有能なチームメンバーになるために学ぶことができるスキルと 習慣について焦点が当てられました。私たちの大半は、直接影響を与えることのない人々によって私たちの成功と失敗が判断されるような立場にあるため、これ はますます重要になっています。ソフトウェア開発チームはこの好例です。
アジリティ: 個人レベルでの可能性(リンク)
Daniel Cukier氏は、Linda Rising氏のプレゼンテーションにおける、クモの巣への種々の薬（カフェインなど）の効果を示した画像の1つ(リンク)に興味を持ちました。
反応のよい設計(リンク)
Denis Bregeon氏(リンク)は、この話について次のように書いています。
前の取り組みを踏まえ、彼は設計の定義と価値の影響（設計の質をどのように評価するか）およびパターンの使用と設計に関する原則（ある程度の価値の運用効果）から始めました。
そして、話の中心は設計の戦略になりました。Kent Beck氏は自身の経験から4つの設計戦略を特定しました。それらは本当に設計を進化させる戦略です。
- 1つ目はleap（ジャンプ）です。ある設計から別の設計に一気にジャンプします。
- 2つ目はParallel（並列）です。古い設計と新しい設計がしばらくの間共存します。
- 3つ目はstepping stone（足掛かり）です。新しい設計に到達するまでの一連の中間段階が定義および実施されます。
- 4つ目はsimplification（単純化）です。設計は問題の単純化されたバージョン用に作られ、その後複雑性を再導入することによって強化されます。
Razvan Peteanu氏(リンク):
満員となったKent Beck氏のプレゼンテーションでは、設計方法を捉えるために彼が行った積極的な取り組みの成果について共有しました（命令しようとすることなく、皆がそ れをどのようにすべきか、というものです）。設計が困難であったというBeck氏の最初の言葉に対し、予想通り是認するざわめきがありました（初心者と専 門家の両方が設計は困難であると言う場合、プラクティショナーのスキルレベルに予測される難易度をグラフに表したら面白いでしょう。「この程度のことは朝 飯前」というレベルに達するのはいつでしょうか?）。設計について言えば、それについて彼が最近作った定義は「有益に関連する要素 （Beneficially Relating Elements）」です。ここに少し言語的遊戯があります: あなたは、設計を名詞（有益に関連付けられた要素で作られている）または動詞（設計することは有益な方法で要素を関連付けること）として読むことができま す。
Jeremy Miller氏(リンク):
私は、QConでKent Beck氏の話の1つに参加させていただきました。それは正直なところ革新的でも情報を提供するものでもありませんでしたが、私が見たものは、名匠の1人 が設計の決定をどのように行ったかに関して熟考するものでした。私は、それを倣うべき良い模範であると思います。
Bruce Eckel氏(リンク):
Kent Beck氏は、設計時に使用した手法の探求について話しました。彼はそれを「有益に関連する要素（Beneficially Relating Elements）」と定義しました。
- Leap（ジャンプ） （効果のある小さい（安全な）措置を取る）
- Parallel（並列） （しばらくの間2つの設計を並列で進める）
- Stepping Stone（足掛かり） (もし...があったら、それをすることができるだろう）
- Simplification（単純化） （最も単純なケースから始めて、動作したらすぐにそれを強化する）。単純化のための機能を取り除くタイミングと、それらを再追加するタイミングを知る方法。
超越およびゲートの通過(リンク)
Denis Bregeon氏(リンク)は、このプレゼンテーションに参加しました。
これはとても興味深い話でした。少なくとも、何が私たちをソフトウェア開発に駆り立てるのかについて興味を持っている者には、そうでした。余談として、こ れについてはKent Beck氏の基調後の質問時に数回話題に上りましたが、答えはほとんどお金や人間の利益についてであってあまり興味深くありませんでした。このプレゼン テーションは、哲学的なタイプのAgile開発者についてこの1年間むさぼってきた多数のアイデアと同じ考えを作ります。また、私は日本に強い関心を抱い ています。
Dave氏の話は短期集中コースであり、印象派であり、禅の哲学の教育であり、悟りの度合いから完全に悟った能力に至る芸術であり、弟子が求めているもの でした。私は、この話の要点が何であるか確信を持っていませんが、ソフトウェア開発におけるアジャイルが1日のレシピであるはずがないということの警告で あったのだと思います。それは、生き方、（禅の意味における）悟りへの道、言い換えれば、コンスタントな改善によって完全性を追究することです。とはい え、ソフトウェア開発者になることは僧侶や戦士や刀職人になることほど崇高ではありませんが。
エンタープライズ向けRuby(リンク)
MERB: 柔軟性とパフォーマンスが重要になるとき(リンク)
Chris Patterson氏は、MERBに感銘を受けました(リンク)
MERBは、高性能でスケーラブルな、RubyのMVCフレームワークです。Railsと同じ空間にありますがパフォーマンスを向上させるための多くの最適化が伴います。また、機能をシンプルなgemとして追加できるよう、スライスをサポートしています。MERBは、今後もその成長に注目すべきものです。
Kelvin Meeks氏(リンク)も、このプレゼンテーションから、次の内容を含むいくつかのポイントに注目しています。
今朝のRubyプレゼンテーションにおいて、1つの興味深い主張がありました。それは、Rubyの歴史的なひどいパフォーマンスの評判は、いくつかのパフォーマンス改善を考えると（たとえば、生のPHPと比較したMerb、主要なPHPフレームワーク、Django、Rails、Code Igniterなど）、現在は通用しないかもしれない、ということです。
InfoWorld(リンク)もこのプレゼンテーションについて取り上げました。
彼は、Merbは「エンタープライズに非常に適しています。そして[エンタープライズ]だけに限りません」と言いました。Merbは「現在私たちが持っているもので最速のRubyフレームワークです」と、Aimonetti氏は言いました。
技術はMerb「スライス」の概念を提供し、そのスライスは他のアプリケーションの内部に搭載可能なスタンドアロンのミニチュアアプリケーションとして機能します、と彼は言いました。Merbはモジュラリティと柔軟性を提供するとAimonetti氏は言いました。
エンタープライズ向けのRailsのスケーリング(リンク)
InfoWorld(リンク)は、このプレゼンテーションについて取り上げました。
Railsアプリケーションはmemcachedアプリケーションなどの手法によってスケーリングできる、とPollack氏は自身のプレゼンテーション後のインタビューで言いました。「実際、Railsをスケーリングする方法は他のWebアプリケーションをスケーリングするのと同じ要領です」と、彼は言いました。
RubyはWeb以上の域に達するとPollack氏は言いました。Rubyは、グラフィックおよびデスクトップクライアント用だけでなく、音楽の生成、およびLinuxボックスの維持に使われていると彼は言いました。
クラウドコンピューティング: プラットフォームとしてのWeb(リンク)
プラットフォームとしてのWeb: 市況(リンク)
Eric Smith氏(リンク)は、この話に参加しました。
John氏は、インターネット上で利用可能な様々なAPIのカタログサイトの一種であるProgrammableweb.com(リンク)の創始者です。John氏はプレゼンテーションで、Web APIの動向について話しました。一部の動向は、REST対SOAPの使用上昇など技術的なものです（ただしRESTは標準というよりはむしろ哲学であるため、REST風とは対照的に何かをRESTとして分類することは難しいことがあります）。その他の動向は、APIの普遍性を中心としたものです -- Web上に便利な機能性を置く場合、それはユーザーインターフェースだけでなく、APIを利用するということが予想されています。The New York Times(リンク)やNPR(リンク)などのメディアプロデューサーさえもAPIを利用しています。
良いWeb APIの条件とは何でしょうか? 何よりもまず、基本となるサービスが価値あるものでなければなりません。そのほかに、APIはプロバイダのビジネスモデルをサポートする必要があります（eBayはリスト追加の最適化を望んでいます。それが彼らのお金を稼ぐ方法だからです）。また、提供される開発者サポートと開放性の両方において、アクセスしやすくなくてはなりません。
Google App EngineおよびGoogle Data API(リンク)
Chris Patterson氏(リンク)は、このプレゼンテーションについて次のように書いています。
私の次の目的は、GoogleのAppEngineについてと、それがスケーラビリティとパフォーマンスにどのように対処するかを学ぶことでした。AppEngineは現在無料であり、開発者はPythonとBigtableを使用してアプリケーションを構築しクラウドへ配備することができます。AppEngineは、完全に透過的なスケーリングインフラストラクチャを備えた面白いエンジンです。あなたは自身のアプリケーションについて心配し、システムは残りの部分に対処します。大規模なアプリケーションが構築されていますが、Googleは標準的な割り当てを超えるスケーリングを無料で許可しています。最終的な価格設定についてはまだ議論されていませんが、かなり安く設定されると思われます。また、来年早々に新しい言語サポートの計画的導入がありますが、追加される正確な言語ランタイムは秘密にされていました。
"組み合わせる" - 結合、メッセージング、会話(リンク)
Chris Patterson氏(リンク)は、このセッションについて次のような考えを述べています。
私がMassTransit(リンク)に取り組み始めてから、Gregor Hohpe氏の『Enterprise Integration Patterns』(リンク)という本を、分散型のメッセージベースシステムを構築するための参考マニュアルとして使用しました。このセッションの話の中で、Gregor氏はある基盤を築き、この本の続編（『Conversation Patterns』というタイトルになる）の準備を整えました。しかし最初に、メッセージベースシステムの課題が示されました。あらゆるレベルのエラーがかなり関係しており、これには、リクエストの損失、応答の損失、遅い応答、再試行の重複などが含まれます。こうした多くがオンラインで取り上げられているため、題材のほとんどが私にとってはレビューでした。ACIDの新しい頭字語も宣言されました: Associative、Commutative、Idempotent、そしてDistributedです。
一貫性が即座の性質というよりも結果として生じる性質を帯びている大規模な分散システムでは、予測可能かつ正確なことよりも将来に柔軟かつ冗長性があるかどうかを認識することが重要です。耐久性があり補償をサポートする分散トランザクションを構築することは、成功したスケーラブルなアプリケーションを持つために不可欠です。
Omar Khan氏(リンク)も、次のように書き留めています。
Gregor Hohpe氏は、「クラウド」アーキテクチャを使用するアプリケーション作成の基礎となる原則について、素晴らしいディスカッションを展開しました。クラウドコンピューティングは基本的に他の組織/企業が提供するサービスをあなたのアプリケーション内で使用することです。この例は、GoogleマップやAmazonのEC2を使用するアプリケーションを持つことです。彼の話から学んだ主な点は次のことです。
- 不確実性を受け入れることを学ぶ
あなたは、使用しているサービスを自身で制御するのではないため、ダウンしている/利用できないコンポーネントを考慮して設計する必要があります。なぜなら顧客はカバーの下であなたがどんなサービスを使用しているかを気に掛けないからです。- 物事を単純かつ小規模に保つ
- 非同期性を考慮して正しく設計することを学ぶ
- 新しいプログラミングモデルを取り入れる
- 従来のパターンの適用に抵抗する
機能的および並行プログラミング言語の適用(リンク)
Arjan Blokzijl氏(リンク)は、このトラックを楽しみました。
QCon San Franciscoに参加している間、特に満足だったのは、私が非常に関心を持っているトピックである関数型プログラミングの分野をテーマにしたトラック全体に参加したことでした。そのトラックをたどった後、私は以前よりも関数型プログラミングは学問の世界に閉ざされていないということを確信しています。それは、私たちの心的な物事の見方と、今後数年で解決する問題とプログラミングについての考え方に深い影響を与えると思います。
Haskellと芸術(リンク)
Arjan Blokzijl氏(リンク)は、このプレゼンテーションに参加しました。
彼は、現在エール大学にて主要な研究分野となっている、Functional Reactive Programming（FRP）(リンク)の概念について話しました。FRPは、各関数が、時間的に変化する量（たとえば、入力サウンド、ビデオ、ユーザーアクション）をキャプチャできるプログラミングスタイルです。このスタイルのプログラミングは、Robotics、並列プログラミング、オーディオ処理に適用されます。新しい入力値が関数に渡されると、再評価されて新しい出力が返されます。彼は話の中で、音楽とサウンドの合成用に開発されたドメイン固有言語であるHasCoreとHasSoundについて特に紹介しました。Paul氏は、関数型言語は、宣言的である（「どのように」なされるべきかではなく、「何が」なされるべきかを言う）ため、コンピュータミュージックに特に適していると述べました。Haskell抽象化メカニズムは、遅延評価、高階関数、代数的なデータ型および型クラスのメカニズムを使用して、エレガントで正確かつ強力な音楽プログラムを可能にします。Haskellでの音楽モデリングの基本例は、こちら(リンク)でご覧になれます。
強く型付けされたドメイン固有埋め込み言語(リンク)
Arjan Blokzijl氏(リンク)は、この話について次のような考えを述べています。
Lennart氏は、彼自身がHaskellでDSLを実装することで開発したいくつかの例を挙げました。私にとって最も印象的だったのは、彼がExcel（すなわち、テキストベースのcsvファイルではなく、本当のExcelシート）を生成するためにDSLを実装したケースでした。彼が言うには、Excelには、コピーと過去の再使用のみで構成される、やや初歩的な抽象化メカニズムがあります。しかしそれは、ビジネスマンに広く使用されていて、馴染み深いUIです。したがって、ソリューションはExcelシートを生成することです。Lennart氏はコンパイル時のエラーを防ぐための強力な型検査の提唱者です。彼は、Haskell型クラスをどのように使用したかについてと、Excel DSLにおけるPhantom型(リンク)としてのより不明瞭な概念を紹介しました。結果は、Excelでの2つのセルの追加（1つのセルに整数が含まれ、もう一方のセルに文字列が含まれている）など、Excel自体が防ぐことのない、操作時の型エラーを許すことなくExcelを生成できるDSLとなりました。Haskell型システム機能のフルパワーを紹介したり、Haskellといって直接思い浮かばないであろう分野におけるその使用について説明したりと、本当に興味深くて面白いセッションでした。
Buy a Feature: 不変性とActorの冒険(リンク)
Arjan Blokzijl氏(リンク)は、このセッションについて次のように書いています。
おそらく私たち大抵の者にとってより馴染み深い概念は、David Pollak氏によるセッションで説明されました。彼は、最近開発したWebアプリケーションBuy a feature(リンク)について話しました。すぐに興味を湧かせるようなテーマではありませんが、David氏はScala(リンク)とScalaのLift (リンク)Webフレームワーク（後者は彼自身が作成）を使用しました。彼は、マルチユーザー、Webベース、リアルタイムの、シリアスなゲームを実装するために、同時並行性に対処するScalaのActorライブラリなど、関数型プログラミングパラダイムを使用し続けていました。彼によると、チームは当初Javaの命令型プログラミングスタイルを使用していました。しかし、しばらくして（コーチングの後）、彼らは徐々に、Scalaも提供する宣言的な関数型プログラミングスタイルの使用に移行しました。さらに注目すべき主張は、アプリケーションに見つかったバグはどれも並行性関連ではなく、ScalaのActorライブラリを使用した、イベント駆動のメッセージパッシングプログラミングスタイルは、彼に明らかに良い結果をもたらしたということです。
Steve Vinoski氏(リンク)は、次のように書いています。
私は面白いことを発見しました。それは、彼はScalaで、私はErlangで記述しているにもかかわらず、私がYawsの仕事で使用しているリクエストディスパッチ手法といくつか同じものを、彼はLiftで使用しているということです。Functional languages rule。
原理主義の関数型プログラマ
Arjan Blokzijl氏は、このディスカッションを楽しみました。
関数型プログラミングの支持者にとって、その日の終わりはあまり良いものではなかったかもしれません。
Eric Meijer氏自身が、「原理主義の関数型プログラミング」というタイトルの楽しい話で最後を締めくくりました。彼の示唆に富む主張は、私たちはプログラミング方法においてここ数十年間も誤った方向に進み続けている、というものです。このブログのタイトルが示しているように、純粋で、基本的な関数型プログラミングに方向転換しましょう。
これがなぜ良いのでしょうか? すべての「純粋な」関数型コードには副作用がなく、そのため状態を変更しません。変更される状態がなくなると、ステートメントが実行される順序も、プログラムが実行される回数も問題ではなくなります。これにより、プログラムはより理解可能なものになり、エラーを起こしにくいものになります。関数に潜在する副作用がいかに不快であるかを、Eric氏はC#言語の例を用いて示しました。このブログでは詳細を説明すると長くなりすぎてしまうので、興味のある読者の方は、彼のブログ(リンク)をご覧ください。
効果的な設計およびクリーンコード(リンク)
ビヘイビア駆動開発 - 効果的な設計およびクリーンコードへの道(リンク)
SD Times(リンク)は、このプレゼンテーションについて取り上げました。
「同じことを意味するように皆同じ単語を使用してみましょう」とNorth氏は言いました。「私は、クレジットデリバティブと呼ばれるものを取り扱う場所で専門家に相談していました。そこでは、価格設定の概念を用います。それは大きなグリッドを必要とします。この価格設定アルゴリズムに苦しんでいる1組の開発者が[いました]。ビジネスアナリストが通り、彼らは会話をしました。私はそれを見ていました。ビジネスアナリストは彼らがコードについて話していると気付くことがまったくなかったので、その会話は見事でした。彼は価格設定について話していました。彼らは流動的な会話をしていました。この男は、彼がオブジェクトについて話していることに気付きませんでした。
「これは考えるエクササイズというだけではありません。共通の言語を持ち始めましょう。ユビキタス言語とは、あなたがそれをソフトウェア成果物に入れる時です。クラスはそれらがドメインで名前付けされたものに名前付けされます。あなたは、何かをモデル化するときに、仕事を成し遂げるということが分かると思います。」
コードを改善する10の方法(リンク)
Joey deVilla氏(リンク)は、このプレゼンテーションで目にした映像の1つを楽しみました。それは、YAGNI開発アシスタントを紹介するものでした。
YAGNI(リンク)は、「You Aren't Gonna Need It（今必要のあることだけをやれ）」の略で、現時点で必要ないが将来必要になるかもしれない機能や機能性をアプリケーションに追加すべきではないということをプログラマに示唆する開発原則です。YAGNIにはDRY（「Don't Repeat Yourself」）原則(リンク)といういとこがあり、その先祖の中には、Occam's Razor（オッカムの剃刀）(リンク)やKISS原則(リンク)（「Keep It Simple, Stupid」で、「I Wanna Rock and Roll All Night and Party Every Day」ではない）があります。
Eric Smith氏(リンク)も、このプレゼンテーションに参加しました。
Neの10のポイントは、TDD、静的解析の使用、YAGNIなど、ほとんど私が知っている（かつ時々成功している）ものでした。多言語プログラミングについて興味深いポイントがありました。彼は、多言語プログラミングは概念的に複数のプラットフォームを意味せず、単一プラットフォーム上の複数の言語を意味する、と言いました。Javaと.NETはどちらも多言語プラットフォームであるため、それを利用して、一般的なランタイム環境の利益を保ちつつ当面の問題に対し最適な言語を使用します。
合間に、Neal氏は10の悪臭について話しました。その中での私のお気に入りは、「弁護士が、我々はいかなるオープンソースソフトウェアも使用できないと言っている」というものでした。それは、Neal氏がCruiseControl（Neal氏の雇用主、ThoughtWorksによって書かれたもの）をクライアントで使用できるようにその「ライセンス」を購入しなくてはならないことにつながります。
Kelvin Meeks氏(リンク)もこのプレゼンテーションに参加し、次の内容を含む詳細なメモを取っています。
企業のコードのスメル、トップ10
10 - 我々は既存のフレームワークでは不十分なため、独自のWeb/永続化/メッセージング/キャッシングフレームワークを発明しました。
9 - 個々のツールを購入するよりも安かったので、我々はツールスイート全体を購入しました（そのうち10%ほどしか必要でないにもかかわらず）。
8 - 我々はWebSphereを使用しています。なぜなら...（私はいつもこの時点で聞くのをやめます）
7 - 我々はいかなるオープンソースコードも使用できません。弁護士がそう言っているからです。
多言語およびマルチパラダイムプログラミングによるRadical Simplification（超単純化）(リンク)
Ola Bini氏(リンク)は、この話について次のように書いています。
その日の最後に、私は、Dean Wampler氏が多言語プログラミングについての漠然とした考えをすべて混ぜ合わせて、結束した全体をアプローチすることで話をしているのを目にしました（私が一度もできたためしがないことです）。良くできたプレゼンテーションでした。
Kelvin Meeks氏(リンク)も、次のような多くのことを取り上げています。
PPPPの欠点
- Nツールチェーン、言語、ライブラリ、「エコシステム」
- ツール間のインピーダンス不整合
PPPの利点
- 特定のジョブについて最高のツールを使用する
- 必要なコード量を最小限に抑えることができる
- コードをドメインに置いておくことができる
- アーキテクチャについて考えるように促す
現実世界でのRIA: クライアントの進化(リンク)
Hard Rock: Silverlight 2を使用した音楽の裏側(リンク)
Eric Smith氏(リンク)は、このプレゼンテーションについて次のように書いています。
Scott氏は、Microsoftパートナーオブザイヤー2008に指名されたコンサルティング会社であるVertigo(リンク)のCEOです。カンファレンスは今までのところJavaサイドに厳しいようなので、Microsoftの技術的な表現があって嬉しかったです。Scott氏は、市場調査会社であるDuncan/Channonとの協働によるHard Rock Memorabilia(リンク)サイトの構築について話しました。Duncan/Channonは当初Flashを使用してそのサイトを構築するつもりでしたが、Deep Zoomが、Silverlightを明確な選択肢にした目玉機能であると判明しました。
Scott氏は、Silverlightの独立したグラフィックデザインとプログラミングのストーリーは完全に宣伝どおりに展開していると言いました。彼は、VertigoプログラマのMichael Moser氏がすぐにコードアップし、その後グラフィックアーティストによって美しく一皮剥かれたEtch-A-Sketchアプリケーションの小さいデモを紹介しました。
溝の中の柔軟性と空気: 現実世界のエンタープライズ体験の6ヶ月間(リンク)
Eric Smith氏(リンク)は、この話について次のような考えを述べています。
Scott Delap氏は、ビデオゲームLeague of Legends(リンク)のいくつかのオンラインコンポーネントを構築するためのAdobeツールの使用についてプレゼンテーションしました。彼の考え方は、Flash/Flexと、SwingでJava UI開発を行うこととの比較でした。彼は、プラットフォームと開発ツールにかなり満足しているようでしたが、いわばJava year 2000のようなものと思っていました。つまり、最先端というわけではありません。しかしながら、彼は宣言的なUI仕様への転向者です。私が知っているJavaのUI開発者と同様に、彼は、Swingのビジュアルデザイナーを本気では信用していませんでした。しかし、Flashでのデザイナー経験が大きいとも言っていました。
Scott氏は、様々なもの（依存性の注入、リモーティング、単体テスト、機能テストなど）の多くのフレームワークの評価について話しました。これはオープンソース開発スタックの標準的なエクササイズです。
現実世界のGWT: LombardiがGWTを使ってBlueprintを構築した理由とあなたが次のRIAにそれを使用すべきである理由(リンク)
Eric Smith氏(リンク)は、このセッションに参加しました。
手短に言うと、Alex氏と彼のチームはGWTが大好きです。そして私は、動作しているBlueprint(リンク)を見て、かなり素晴らしかったと言わざるをえません。それはデスクトップアプリケーションに非常に似ていましたが、HTMLとJavascriptを使って完全に実行していました。GWTはそのすべての背後にある魔法です。これは、JavaをJavascriptにコンパイルするためのGoogleのツールキットです。
あなたがJavaショップで働いているなら、すべて馴染み深いツールを使用し、Javaコードを記述し、素晴らしいWebアプリケーションを手に入れるという、すばらしい開発ストーリーのように思えます。
ドメイン駆動設計(リンク)
C#による.NETドメイン駆動設計: フレームワークの内部で作業しながらドメインモデルをクリーンに保つ方法(リンク)
Eric Smith氏(リンク)は、この話に注目しました。
Tim氏は彼の話で次のような興味深い質問を投げ掛けました: フレームワークで作業するとき、あなたはどのようにドメインコードをクリーンに保ちますか? フレームワークに関して、Tim氏はASP.NETのような広いフレームワークと、SharePointのようなより狭いアプリケーションフレームワークのことを意味しました。課題は、フレームワーク、および特にMicrosoftが提唱するもののコード化に対するウィザード/デザイナーのアプローチでは、永続性や、特定のAPIなどと不適切に結合されやすくなることです。
DDDを使ったguardian.co.ukの再構築(リンク)
Eric Smith氏(リンク)は、このプレゼンテーションに参加しました。
Phil氏は、彼らがこれまでに学んだいくつかのことを共有しました。1つは、いたる所で問題ドメインの言語を使用することの重要性でした。それにより、チームの非技術系の人々さえも予期せぬ方法で貢献できました。この一例は、オブジェクト合成の大きな進歩でした。Phil氏は、オリジナルのオブジェクト階層と、はるかにクリーンなオブジェクト階層を示しました。彼は、もちろん大きな進歩はいつも後から考えると明白で些細に思えるが、それを思い付いたのは非技術者だと言いました。彼が引用した別の例は、ユーザーの1人が機能デモのため開発者のマシンにやって来た時のことでした。開発者が準備をしている間、ユーザーはコードを覗き込んで、「これは、私が実行すると思っていることを実行しますか? そうだとすれば、それは正しくはありません。」とコメントしました。コードはオブジェクト名とメソッドにドメイン言語を使用したため、彼はバグを見つけることができるくらい十分に理解できたのです。
Phil氏と彼のチームが学んだ別のことは、データベーススキーマはモデルではないということです。時に人々は、データベース内にないものであれば、それはモデルではないという誤った感覚を得ますが、モデルはコードです。
ドメインの枷をはずす(リンク)
Erik Rozendaal氏(リンク)は、このプレゼンテーションを楽しみました。
Greg Young氏(リンク)による「ドメインの枷をはずす」(リンク)の話は、私にとってのQCon(リンク)のハイライトでした。アーキテクチャのアプローチは、比較的理解しやすく、信じられないほどスケーラブルで、リッチドメインモデルをサポートします。
プレゼンテーションで、Greg氏は、JEE(リンク)などの従来のエンタープライズアプリケーションアーキテクチャに関する問題のいくつかを指摘しました。このアーキテクチャの構成は通常、手続き的サービス層の内部でカプセル化され、リレーショナルデータベースに永続化され、UI層によってデータ入力画面でフラットにされ、何らかのレポートツールによって管理レポートにかみ砕かれた「オブジェクト指向」のドメインモデルから成ります。マスターが非常に多いため、ドメインモデルが貧血症（anemic）(リンク)になり、アプリケーションがスケーリングしにくいというのも不思議ではありません。
戦略的設計(リンク)
Eric Smith氏(リンク)は、この話について次のように書いています。
彼のこの話の仮定は次のとおりです:
大規模システムのすべてが優れた設計なのではありません。
私たちは、そうでないことを願っていますが、それが厳しい現実であるように思えます。彼は、開発チームによくありがちな状況について話しました。私たちはこのレガシーシステムを使用しています。レガシーシステムにはデザインの悪さ、古いテクノロジー、予想外の複雑性など、私たちに不満を抱かせるような典型的な、あらゆる問題があります。では、どうすればよいのでしょうか?
Bruce Eckel氏(リンク)も、この話について次のように書いています。
プログラミングの「ヒーロー」とは、コアドメインで働くことでビジネス価値を提供する人々です。残念ながら、そのような「ヒーロー」は多くの場合、自分たちを適所に置くことができるくらい優秀な悪いプログラマです。良いプログラマはたいてい彼らの後始末をする必要があります。
3年目にビジネス価値を提供し始めるためにシステム全体を再構築しようとするのではなく（2年間は会社にお金を失わせて目に見えるビジネス価値を提供しないため、これは決して起こらない）、自分自身をコアドメインに置くべきです。基調となる（悪い）アーキテクチャにファサードを作成し、ビジネス価値を追加し始めてください。時間がたつにつれて、利益が明確になったとき、あなたは基調となるアーキテクチャの側面を変更できます。
実際に使えるDSL(リンク)
Erlangでのドメイン固有言語(リンク)
Ola Bini氏(リンク)は、この話に感銘を受けました。
Dennis は、ErlangでのDSLに関する非常にクールな話をしました。とても信じられないような、実行できることがあります。この日最高の話でした。もしかしたらこのウィークで最高の話かもしれません。
常日頃から疑問に思っているアーキテクチャ(リンク)
Digg.comソフトウェアアーキテクチャ(リンク)
Omar Khan氏(リンク)は、このプレゼンテーションについて次のように書いています。
次に登場したのはDigg.com(リンク)のJoe Stump氏でしたが、彼のセッションは素晴らしかったです。Joe氏は、彼らが遭遇したいくつかの問題に加えて、来年早々展開予定のものに結び付けた点からのアーキテクチャの進化について話しました。MySQLのスケーラビリティには重大な問題があったため、彼らはIDDBに移行し、MemcacheDとBerkley DBを融合したMemcacheDBを使用することを検討しています。Joe氏は、digg images(リンク)の画像の管理にMogileFS(リンク)を使用することを指摘しました。私は現在のプロジェクトのために、それに注目するでしょう。
Facebook: サイエンスとソーシャルグラフ(リンク)
Omar Khan氏(リンク)は、この話に参加しました。
facebookのAditya Agarwal氏は素晴らしかったです。彼は、facebookの様々な側面と、アーキテクチャの基調となるPHP/MySQLの使用と、その方法について話しました。彼らは、key-valueストアとプロフィールコンテンツが数千ものサーバーにランダムに存在するため単純にMySQLを使用する傾向があります。彼らは、大部分についてLAMPを使用していますが、アプリケーション内で他の言語で書かれたサービスを使用可能にするフレームワークを作成しました。
Eric Smith氏(リンク)も、この話に参加しました。
Aditya氏は、Facebookの技術部長です。彼のプレゼンテーションを聞いた後、私は次の2つの結論に達しました。FacebookがLAMPスタック上に構築されますが、ほとんどのコンポーネントが、特定用途のためにカスタマイズおよび最適化されました。また、memcachedを使用しており、Aditya氏が言うには、それはサイトのパフォーマンスにおける大きな要素だったとのことです。これは先日のTim Bray氏の話に出てきた、データベースはこの種のスケーラビリティに関して遅過ぎるということと見事に一致していました。Aditya氏は、memcache分散ハッシュテーブルはRAMの25テラバイトを消費すると言いました。
- 私は今まで、とてもここまではスケーラビリティについて心配する必要がなかった。
- それについて少し嬉しく思う。
マシンに釣りを教える: eBayが自ら向上する方法(リンク)
Razvan Peteanu氏(リンク)は、このセッションについて次のように書いています。
その後、eBayの優れたアーキテクトであるRandy Shoup氏は数字を印象付けるプレゼンテーションを行いました。自動化された検索および推奨エンジンは日々50PBを処理しており、毎日50TBが追加されているということです（タイプミスではありません）。そのインベントリ（一覧）のうち10%は毎日流動的であり、その変化率はユーザーが正確な検索結果を必要とするときに課題を課します。プレゼンターはこう言いました。「ユーザーは検索結果の最新ページに進み、数が元々示されたものと1つ異なると不平を言います。」一方Googleでは、「Java」の検索総数はおよそ4億1400万件ですが、1000件以上の検索結果を見ることはできません(リンク)。
.NET空間における選択肢: オープンソース、フレームワークおよび言語(リンク)
寿命の長いコードベースの喜びと痛み(リンク)
Eric Smith氏(リンク)は、この話について次のような考えを述べています。
これらは私が学んだ教訓の一部です。また、私は、質問に答える際に彼が言った次のコメントを有り難く思いました。テストを記述するときにはIoCコンテナを使用しないでください、ということです。私はこれまでにそれをしている人々を目にしてきました。彼らは、コンストラクタで注入された依存性セットを使い、モックを注入するためコンテナを再構成しようとします。単にコンストラクタでモックを渡してください!
- クラスレベルでの優れた設計は極めて重要である。
- 質の悪いテストは、コードを変更しやすくするどころか、難しくする。
- TDD（BDDとも呼ばれる）(リンク)は最高である（私はこれについてもっと学習する必要がある）。
- 抽象化が正確になると、コードが改善されるだけでなく、新しい可能性が切り開かれる。
- DRY – ほんの少しの重複も悪である。
F#入門(リンク)
Eric Smith氏(リンク)は、次のように書き留めています。
私はF#について小耳に挟んだことはありますが、それを理解しようとすることにあまり時間をかけたことはありませんでした。設計者に教えてもらうほど良い機会を得られることはないと思いませんか? もちろん、言語について学ぶ最善の方法は、プレゼンテーションを聞くことではなく、コードを記述することです。それでも、ハイレベルな概要をつかみ、いくつかの例を見ることは面白かったです。Don氏のお気に入りの1つは、C#とF#の機能的に同等なビット間のコード行の違いを示すことでした。非同期I/Oの例では、3ページのC#コードに対し十数行のF#という違いがありました。
Don氏は、F#はデータ転送を扱う問題に適しているが、ユーザーインターフェースの構築には（すべての.NET UIライブラリにF#からアクセスできるとしても）それほど適していないと言いました。
DbC世界におけるTDD(リンク)
Eric Smith氏(リンク)は、このプレゼンテーションについて次のように書いています。
私は、過去に契約による設計（Design by Contract）について投稿したことがあり（パート1(リンク)、パート2(リンク)）、単体テストとDbCについていつか話すつもりでしたが、その暇がありませんでした。そのため、私はGreg氏が言わずにいられなかったことを聞きたいと思いました。彼の話の最初の部分は、DbCの概要でした。spec#コードを示して概念を説明し、コードベリファイアーに問題を検出させました。私はMicrosoftがPDCで契約ライブラリを発表したことに気付いたため、spec#の探索動作は言語拡張としてではなくフレームワークに組み込まれることになるでしょう。
Greg氏のプレゼンテーションの要点は、テストと契約が相補的であるということです。契約は制約に焦点を合わせ、一方テストはビヘイビア(BDDへのその他の参照)に焦点を合わせる必要があります。契約を結ぶということは、記述すべきテストが少ないことを意味します。なぜなら、パラメータxがnullのときに引数の例外が投げられるのをチェックするすべての馬鹿なテストを記述する必要がないからです。実際、そうしたテストを記述する必要がないだけでなく、仮に試してみても、コードベリファイアーはエラーを出すでしょう。そのため、あなたはそうしたテストをほとんど記述できないので、契約はコードの意味のあるビヘイビアをテストするように推し進めます。
Matthew Podwysocki氏(リンク)は、ブログ投稿で、このプレゼンテーションからいくつかのアイデアを発展させました。
最近、私は.NET 4.0の新機能であるCode Contracts（コード契約）(リンク)について話しています(リンク)。これは、Design by Contract（DbC）のイディオムを、ベースクラスライブラリの一部としてすべての.NET言語にもたらすことです。先週、私はQConに参加しました。そこで、CodeBetter仲間の1人であるGreg Young氏が、「DbC世界におけるTDD」(リンク)というタイトルのプレゼンテーションを行いました。彼は、それらは衝突せずにテスト第一の考え方に対し相補的であるということについて話しました。どちらも、もう一方の使用を改善します。
質問の1つは、私のブログ投稿時およびQConにおいても、そのことについて取り上げられました。何度も、DbCはTDDと衝突すると判断され、その上DbCの使用を支持する多くの人々がTDDを実行していないため、私はそれが必ずしも正しいとは思いません。それぞれが一般的な状況に当てはまるところについて見てみましょう。
Volta: どこでも分散.NET(リンク)
Eric Smith氏(リンク)は、この話を楽しみました。
私は再び講演者の方々の能力に感心します。中でも、LINQを設計したEric Meijer氏です。現在、彼はVoltaに取り組んでいます。これは単刀直入に言えば、.NETのGWTです。Voltaは、.NETコードを記述するクライアントアプリケーションを構築できるよう、MSILからJavascriptへの変換を可能にします。また、クライアントに偶然Silverlightがある場合、Javascriptに進むのではなく、それをランタイム環境のターゲットにすることができます。
また、単一層の.NETアプリケーションを記述し、単にコードに注釈を付ける（どのビットがサーバー上で、どれがクライアント上で実行すべきかを示す）ことで、それをクライアント層とサーバー層に分けるという開発ワークフローもあります。前のプレゼンテーションのGreg Young氏はすぐに分散コンピューティングの8つの誤り(リンク)を挙げて反発しました。Erik氏は、8つの誤りを示しているスライドまで少し先までスキップして、現在もプログラマは痛みを避けるのに十分な主導権を持っているということを聴衆に断言しました。
データストレージの再考: ドキュメント指向分散データベース(リンク)
10,000ftからのCouchDB(リンク)
Omar Khan氏(リンク)は、CouchDBに感銘を受けました。
この日の発見は、CouchDB(リンク)でした。Diggセッションのとき、リード開発者/設計者の1人が私と同じテーブルに座っていました。Tim Bray氏は2日目の基調でこの技術についてかなり興奮しながら話していました。私は、高いレベルからCouchDBについて取り上げられた2つのセッションの1つに参加しました。過去にLotus Notesに取り組んだ人のうちの1人が作成したことを考えると、これにはLotus Notesデータベース設計にルーツがあります。CouchDBには、いくつかの非常に素晴らしい機能があります。
- RESTful。そのためコネクタを必要としない
- JSONにすべてのコンテンツを格納する
- データベースのクエリは、map reduceのような機能を実行するjavascript関数を介して行われる
- 非常に効率的で、分散時にバージョニングと同期化を実行する
Javaの新生テクノロジー(リンク)
コンカレントからパラレルへ(リンク)
Omar Khan氏(リンク)は、この話について次のように書いています。
Omar Khan氏は、この話について次のように書いています。
次の話は、Java 7並列ライブラリと、プロセッサは高速化していないがマルチコアに移行しているという事実を踏まえて並列にすることの必要性についてでした。そのため、私たち開発者は、アプリケーションがすべてをパラレル（コンカレント）で実行させるように保証することを確実にする必要があります。Webサイトを実行する場合、すべてのリクエストが異なるスレッドによって扱われるため自分の仕事は完了していると感じる人がいるかもしれません。しかし、私たちのうち何人が、すべてのコアをフル稼働させるほどのリクエストを24時間365日受信しているでしょうか?したがって、私たちは、最大のCPU使用率と応答時間の短縮を実現してユーザー体験の向上を確保するために並列して実行できるすべてのものを並列で実行する程度までアプリケーションが分割されるようにする必要があります。
Razvan Peteanu氏(リンク)は、次のように書いています。
直後、Brian Goetz氏は、JDK7に計画されているfork-join並列フレームワークに熱烈になりました。その理由は地平線の彼方で待っています: 多数のプロセッサを備えたマルチコアです。IntelのCPU速度は2003年以降向上しておらず、ムーアの法則を有効にするものは、コアの増設です。それはまだ穏やかな段階にあり（私たちは4と8ウェイマシンを楽しんでいます）、それらの数がアプリケーションサーバーのスレッドプールのサイズを下回らない限り、そのレベルで負荷を分散することはまだ申し分ありません。2010年までにIntelによって作られるとうわさされている256コアのCPUで、ゲームは変化します。
こうしたプロセッサの使用を効率的にするには、単一のリクエストの処理内における、より粒度の細かい並列化が必要となります。Goetz氏はこう言いました。「多くのプログラマがおそらくしぶしぶ並列プログラマになるでしょう」。数百または何千ものプロセッサを搭載したマシンは長年にわたって存在しており、ただ、それが主流になるということです。
パネル: Javaにおけるオープンソースの傾向は設計と開発プロセスにどのように影響するか?(リンク)
Omar Khan氏は、このパネルディスカッションについて次のように論じています(リンク)。
興味深い最後のセッションは、オープンソース傾向が持つ影響とjavaについてのパネルディスカッションでした。それは、オープンソースが平凡さとJ2EEからjavaを救い、死の淵から救ったというコンセンサスでした。議論の焦点は現在の経済状態の中でのオープンソースに移りました。パネルでは、大半の企業における予算削減によってオープンソースは繁栄でき、少なくとも安定したものになるだろうと感じられました。興味深い最後のポイントは、何をオープンソースにし、何を有料にするかに関して企業内でどのように決定を行うかについてでした。GoogleのBob Lee氏は、低レベルのツールとフレームワークをオープンソースにして、その上に構築するものについては有料にする、と言いました。その他、MuleSourceの人やSpring SourceのRod Johnson氏などは、人々がすでに他のベンダーの製品/サービスに料金を支払っていそうなときに有料にすると言いました。たとえば、この夜の名言は、Rod Johnson氏による次のような発言でした。
あなたは、アプリケーションスタックとしてMySql、tomcat、およびApacheを使用する場合、無料でspringを使用できます。それは素晴らしいことです。しかし、データベースにOracle Rackを、アプリケーションサーバーにBEA Weblogicを使用している場合は、私たちがOracle RACKコネクタへのSpringについて料金を請求することに、あなたは不平を言う権利はありません。
ポイントは、あなたがすでにお金を使っている場合に、私たちはなぜ、私たちが提供するものについて料金を請求してはいけないのかということです。
Hibernateのスケーリング(リンク)
Razvan Peteanu氏(リンク)は、このプレゼンテーションについて次のように書いています。
始めは、（セキュリティ分割の有無にかかわらず）データベース全体でデータをパーティション化するための戦略について取り上げられました。Max Ross氏がHibernate Shardsの裏の主要人物であるため、話の一部はHibernate Shardsについてと、先に宣言される前にこれから実装すべきものについてでした。
もう1つの主な...内容は、%LIKE%による古典的なSQLクエリよりも優れた無料のテキスト検索を実装する方法としてHibernate Searchを紹介するものでした。過去に似たようなソリューションを扱ったため（すなわち、永続層+Lucene）、Hibernateとの統合が見られて嬉しいです。主な利点: Luceneは単語変化に対処でき、関連ランキングが内蔵されています。それがスケーラビリティのプレゼンテーションに含まれる理由は、これを使用するとデータベースからアプリケーションサーバーまでテキスト一致の負荷が取り除かれ、よりスケーリングしやすいからです。いくつかのスライドで、Luceneインデックスへの同期vs非同期のアップデートについて取り上げられました。また、Emmanuel氏は、Lucene/Hibernate Searchはいくつかのデータベースの全文検索機能よりも柔軟で安価であるという観衆からの質問に答えました。そして再び、重要なポイントは、この仕事からデータベースサーバーを解放することです。
アジリティのスケーリング(リンク)
Fossaの解放: 野心的な文化におけるアジャイルのスケーリング(リンク)
Brendan Quinn氏(リンク)は、この話から、次の内容を含む詳細なメモを取っています。
salesforce.comからの数人が、彼らがどのようにして700人を超える50チームを、一気にScrumへ移行したかについて話しました。その原理は、「もう一方の岸までボートを漕いだ後にそのボートを燃やすようなこと」であり、いくつかのチームが移行し、他のチームが移行しなかったら、それは非難、依存的締め切りの遅れ、および逆襲の原因となってしまうということでした。全員が同じコードベースに取り組む（!!）という事実とあいまって、これはいくらか筋が通っています。
いくつかの名言:
- （有名なアジャイルコーチが、上層部にアジャイルを売り込む方法について尋ねられたときのことです:）「私は2年半の間（非常に大きな組織のための）大規模なアジャイルプロジェクトを実行しました。その間ずっと上司は、それをウォーターフォールプロジェクトだと思っていました」
- 「アジャイルは他のものと同様、ゲームになり得ます」
- 「もしあなたがいくつのタスクを完了したかで速度を測定するならば、皆は簡単だが役に立たないすべてのタスクを完了するでしょう。私たちは、タスク速度を測定すべきではなく、ビジネス価値の速度を測定するべきです... [VCプロフェッサーのTerry氏が私たちに教え込んだマントラ（信念）: 構造は行動を駆り立てる]によって、皆は、測定されるものを実行します。
- 「私たちは、ある定説[ウォーターフォール]から別の定説[スクラムとXP]に進みました -- 私は、肝心なことは私たちがアジャイルであるべきだということだと思いました。考えに何が起きたのでしょうか?」
ソーシャルイベント(リンク)
Chris Patterson氏(リンク)は、水曜日の夜に開かれたパーティーを楽しみました。
その晩、近くのビリヤード場で参加者パーティーがありました。軽食と簡単なビリヤードゲームの後に、Dru氏と私はGregor氏と席を共にし、メッセージング概念について話しました。日本語の簡単なやりとりの後、私たちはテーブルの席を得て、自分たちの仕事の中で特定した様々な会話パターンについて話し始めました。私は、私たちが同じように考えていたことと、私たちが使用したメッセージパターンのいくつかが本で取り上げられる予定であったことに驚きました。また、私たちはGoogle Protocol Buffers(リンク)（効率的なバイナリストリームでデータをシリアライズする、プラットフォームと言語から独立した形式）について少し話しました。数週間前に私たちは、MassTransitを使用する際のJavaと.NET間にさらなるシステム相互運用性を構築する方法としてGPBについて詳しく調べ始めました。これまでのプロセスに基づくと、GPBは最終的に今後のリリースのMTになりそうです。
QCon自体に関する意見
Razvan Peteanu氏(リンク)は、このカンファレンスを楽しみました。
カンファレンスは、アーキテクチャと高いスケーラビリティに焦点を当て、全体的にかなり素晴らしいものです。この上なく絶大なスケールです。プレゼンテーションや通路に創意工夫が見られます。そこから良いものが生まれるはずです。
アジャイルトラックはどうゆうわけか他のカンファレンスと重なりますが、それは、ソフトウェアの開発法がソフトウェア自体と切り離すことができないことの表れです。QConはまだ歴史の浅いカンファレンスですが、展望あるカンファレンスです。人数について知りたければ、ランチルームにあったテーブルの数に基づく私の概算では、300～350人の間だと思います。InfoQからのメイン主催者は毎日来ていて、彼らとおしゃべりすることが可能でした - このイベントは「素晴らしい（メガ）」というほどの感じではありません。
Omar Khan氏(リンク):
結論として、QConは素晴らしい経験でした。ホストは、物事ができるだけ技術重視になるようにベストを尽くしました。講演者が聴衆を満足させるプレゼンテーションを行い、かつプレゼンテーションの本題にとどまるようにする必要があります。低迷する経済はカンファレンスに影響を与え、登録済みだった200人以上の人が参加しませんでした（登録デスクで未収集のバッジのすべてを見ることができました）。経済が向上すれば、来年はさらに良くなると思います。これは本当に開発者による開発者のためのカンファレンスであり、私は心から楽しみました。お気に入りの技術本の著者の何人かに会うことができて大変光栄でした。
Kelvin Meeks氏(リンク):
私はメッカ...聖地を見つけました。
頻繁に私はカンファレンスにお金を払って参加していました。そして、一般的に一日中/1週間ずっと続くセッションに「有益な部分」があると思っていました。しかし、旅行して会議に出席するために犠牲にした、わずかとはいえない時間と費用に関して、払ったお金に見合うだけのものを得たと感じることはめったにありませんでした。
今日は違います。私が今日参加したセッションはすべて、私がエンタープライズアーキテクトとして抱いている特別の関心に的を射ていました。
その他の引用:
- Matt Aimonetti氏(リンク) - Qconは素晴らしいイベントでした。そこで私は多数のとても興味深い面々に会い、「エンタープライズ」コミュニティにおけるMerbの関心を測ることができました。
- David Kinney氏(リンク)- 全体的に、QConは素晴らしいと思いました。講演者の質は、私が参加したセッションでいくらか変わりましたが、大半のカンファレンスより優先する他のセッションを調べることに時間を費やしたほうがよいと感じることはありませんでした（私はvoting with my feet(リンク)（行動で意思表示する）の大ファンです）。QConは、私が来年出席するカンファレンスのリストに確実に入ります。
- Age Mooy氏(リンク)- 全体として、今年サンフランシスコに来た価値は十分にありました。できれば、私は来年、さらにインスピレーションを得るためにここへ戻ってくるでしょう。
- Alex Moffat氏(リンク)- 私はカンファレンスをたいへん楽しみました。Google I/OやJavaOneよりも（明らかに）小規模であるため、JavaOneを行き来が苦痛なものにし得るような混雑に悩まされることはありませんでした。それでも、幾度も、確実に興味深い内容があったため同時に参加したいと思ったプレゼンテーションが1つ以上ありました。
- Ola Bini氏(リンク)- いつもどおり、素晴らしい人々と非常に興味深いプレゼンテーションがスケジュールされた素晴らしいイベントであると判明しました。
- Nick Sieger氏(リンク)- QConは全体的に見て、面白くうまく構成されたイベントです。参加者は「エンタープライズ」の最先端を行く人たちであるという印象を受けました。それはまさに私たちがRuby導入の増加をもたらすために関与する必要がある人々です。したがって、私はもう一段レベルアップして次回Rubyのあっせんに成功できることを願っています。多分、そこで皆さんとお目にかかれるでしょう!
- Steve Vinoski氏(リンク)- QCon San Franciscoから空路帰国する準備をしているところです。当然ながら、それは素晴らしいカンファレンスでした。主催者は私に、出席者が昨年よりおよそ30%増加したと言っていました。うまく構成され、うまく実行されたカンファレンスであったため、多数の素晴らしい講演者がその効果を得る傾向にありました。
- Chris Patterson氏(リンク)-私が到着した日以降、それはずっと素晴らしいです。知識の深さは本当に驚くべきものであり、私は素晴らしい会話を楽しんでいます。出席者の構成は、（私の推定に基づくと）50%がJava開発者、30%が.NET開発者と、20%がRubyやPythonなどのその他の言語です。セッションの多くがプラットフォーム中立であり、ツールよりもパターンやプラクティスにより焦点を合わせているため、カンファレンスの様々な性質は興味深いものです。
- Jeremy Miller氏(リンク)-週の大半を私はQCon San Franciscoで過ごしました。内容面で、それは私が今までに参加した中で最高の「目が釘付けになる」カンファレンスであると言えます。私は、自身の話を終えて、その出来に比較的満足しています。
- Brendan Quinn氏(リンク)- ロジスティクスはいつものように素晴らしかったです。ワイヤレスは次々と来ましたし、食べ物はかなり良かったです -- 皆、血糖値を高く維持するために配られた昼下がりのアイスクリームを好きになりました!
- Dan Diephouse氏(リンク)- 私はサンフランシスコで開催されたQConから帰ってきたところです。QConは、（私見ですが）最も良いカンファレンスの1つです。講演者は素晴らしく、内容の質も素晴らしいもので、通路での会話は思考力を大いに刺激されます。もっと参加できたらいいのに!
QConをきっかけとする考え
カンファレンス自体について話すことに加え、何人かの人はQConでのディスカッションやプレゼンテーションの結果として生じた考えについて書いています。Matthew Podwysocki氏(リンク)もその1人です。
過去に、私はF#でのオブジェクト指向プログラミングについて少し取り上げました。しかし、いまだこのトピックに関して取り上げていないことが多くあるため、そのシリーズに戻りたいと思います。先週、私はQConでErik Meijer氏と話しました。彼と私は、ある意味でF#は、言語の柔軟性を与えるという点で、C#よりも優れたオブジェクト指向言語であるということに同感でした。
Ola Bini氏(リンク)は、QConでインタビューを受けました。
先週QCon SFで、Fabio Akitaによるインタビューを受けさせていただきました。結局、マニアックな話題に触れて、およそ2時間という長いインタビューになり、Iokeに関するかなり詳細な内容になりました。これに興味があり、プログラミング言語の負荷に関する私の意見を聞くエネルギーがある方は、以下でご覧ください: http://www.akitaonrails.com/2008/11/22/rails-podcast-brasil-qcon-special-ola-bini-jruby-ioke
Nick Sieger氏(リンク)は、エンタープライズにRubyをさらに根付かせる方法について思いを巡らしました。
今年のQCon San Franciscoカンファレンスに、私は初めての参加でした。それは、いくつかの理由で私にとって目を開かせるような経験でした。
[...]
最後の項目は、Rubyがまだエンタープライズソフトウェア開発において価値あるツールとして考えられていないという私の認識にかかわるものです。カンファレンス自体ではRubyの提案法よりも業界の状態について考えるものでしたが、私には心配の種が残っています。
Rubyにおいて「エンタープライズに対する準備ができている」とは何を意味するのでしょうか? それはJRubyを示唆するものでしょうか? JVMやJavaアプリケーションサーバー、または.NET上でも動作するでしょうか? 大量のXML? JMS、Spring/Hibernateなどの専門用語の存在? 適応能力または影響力のあるレガシーコード? これらすべて?
Erik Rozendaal氏(リンク)は、Javaへの関心が弱くなっているのではないかと考えました。
2日間のQConの後、皆、誰もJavaについて話していないと感じています。C#、Erlang、F#、Groovy、Ruby、およびScalaが引き継いだように思えます。Javaについて話される唯一の新しいことは、ライブラリ、アプリケーションサーバー、または単にIDEの改善についてです。誰もJava言語について話していません。
振り返って考えると、Java言語の最後の大きな変化は2004年のJava 5のリリースにおいてでした。Java 7は変化をもたらすものになりますが、遅れています。利点は安定性ですが、支払うべき代償は、業界の非常に聡明な心がJavaを置き去りにし始めているということです。
Omar Khan氏(リンク)は、今後も注目すべきソフトウェアのリストを特定しました。
QConに参加する目的のひとつは、技術者コミュニティと、彼らが経験して使用法を見つけたテクノロジーについて同調することでした。以下は、私がカンファレンスから得た興味あるテクノロジー/フレームワーク/などのリストです。 私は、ここ数ヶ月中にこれらの各テクノロジーについて、適用できる時期と場所でそれを利用するという希望を抱いて、調査する時間をとるつもりです。
Bjorn Rochel氏(リンク)は、Greg Young氏と話をしながら、問題の解決法を発見しました。
これはあなたにとって聞き覚えがあることですか? 時々、あなたがずっと気になっている疑問に、誰かが答えを提供します。あなたは自分で答えを見つけられず、話をした相手の大半がそれを気に掛けていないか、あなたにとって満足のいく答えを持っていませんでした。最終的に自分が求めていた答えを聞くと、あなたは . . .今日、私は、運良くGregory Young氏と、概して（分散）ドメイン駆動設計について、具体的にはドメインオブジェクトからDataTransferObjectへの双方向マッピングと、メッセージングやイベンティングとDDDの統合法に関する質問について、話すことができました。これは私がその議論から得たものです. . .
- 実際の解決法はなんて単純なのかとあぜんとする
- なぜ自分でそれを解決できなかったのかと考える
- それでも、パズルの紛失したピースを最終的に見つけて嬉しくありがたく思う
Ari Zilka氏(リンク)は、様々な種類のクラスタリングの使用すべきときについて説明する表を作ろうという気になりました。
スケーリングのための設計に関する昨日のパネルで、私は観衆に聞き取り調査をしました。
1. 何が「最終的に正しいか[または一貫しているか]」知っている人は何人か – 3人
2. EHCache vs. Sleepycatの使用すべきときを知っている人は何人か – 同じく3人
3. EHCache非同期複製 vs. JMSの利点を知っている人は何人か - 3人中2人
4. memcacheをトランザクションな感じにする方法を知っている人は何人か – いない
5. 日常的にアプリケーションで非同期のイベント駆動設計を活用している人は何人か – 1人
部屋には約60人いました。
これは、解決法を市場に任せて開発者にエンジンの使用場所を考えさせているという大きな危険があることを私に教えてくれました。
結び
QCon San Franciscoは大成功を収め、私たちはこのようなカンファレンスを提供できたことを非常に誇りに思っています。QConはロンドンとサンフランシスコの両方で年に一度のイベントとして今後も開催され続けるでしょう。次回のQConは来年の同じくらいの時期に各場所で開催される予定です。また、私たちは、InfoQがサービス提供している、中国や日本などの他の地域でQConが開催されるようになることを心待ちにしています。ご参加いただいた皆様に感謝するとともに、来年お会いできることを楽しみにしています!!!!
第3回QCon Londonカンファレンス(リンク)にあなたを招待したいと思います。このイベントは2009年3月11日～13日に開催されます。3日間のカンファレンス(リンク)の登録は、1月15日まで£1,105です! 今すぐ登録して、£195を節約してください。カンファレンスは、昨年と同じくThe Queen Elizabeth II Conference Centre(リンク)で開催されます。