Typemock: その過去・現在・未来
Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。
作者 Steven Robbins, 翻訳者 編集部 投稿日 2008年7月29日 午前6時41分
ODBMS.org(リンク)のRoberto Zicari教授はオブジェクト/リレーショナル・マッピング技術のユーザ数名と面接し、話を聞いた(リンク)。今回の事例では、ドメインモデルにおけるオブジェクト技術とデータモデルにおけるリレーショナル技術の「インピーダンス不整合」が主要ポイントであった。データを持続的に記憶するために使用したデータモデル(ファイルシステムあるいはデータベース管理システムのいずれかは問わず)と、そのデータに対してプログラムを書くために使用したデータモデル(C++、Smalltalk、Visual Basic、Java、C#)が一致しないとき、「インピーダンス不整合」の問題と呼びます。O/Rインピーダンス不整合の定義(リンク)や、その存在に関して(リンク)さえ、議論が盛んに行われており、今回の事例では多数の人々がプロジェクトでインピーダンス不整合を経験したと述べていた。英国Iona社の技術部長John Daviesは、「貴社にはインピーダンス不整合の問題はありますか」という問いに対し、次のように答えている。
この「インピーダンス不整合」は企業においては重大問題であり、オブジェクト・リレーショナル・マッピング(ORM)と通常呼んでいるリレーションの持続性へオブジェクトを無理やり詰め込むのに、開発時間の25~33%以上を浪費しています。こうしたツールの見本では、ORMがいかに簡単であるかを説明していますが、実際はそれよりずっと複雑で、概念全体が崩壊してしまうのです。最良のツールでさえ、信じられないほど非効率的なモデルを作り上げ、結果として重大なパフォーマンス問題が発生するのです。メリルリンチの重役Richard Ahernsも、この問題は現実であるという点で意見が一致する。
我が社には確かにこの問題が存在します。エクイティデリバティブの事業では、アジリティと商品化に要する時間が非常に重要です。新製品を定期的に導入し、業界の急速な変化に順応し、後れを取らないようにするためには、柔軟な技術が必要です。注文と相場の管理という分野で、O/Rマッピング(object-to-relational mapping)を多種多様な製品全体と資産時間にわたって維持することは、開発者の生産性の足を引っ張り、我が社のスケーラビリティに制限を加えるのです。
ドイツのシーメンスAGでソフトウェアアーキテクトを務めるGerd Klevesaatもインピーダンス不整合の問題を認め、その上で、ORMツールが必ずしも開発者の助けにならない理由を説明し、こう述べている。「特殊なクエリ言語でクエリを定義するよう強いられます。クエリ命令文とナビゲーション能力を検査するコンパイル時間を活用するために、プログラミング言語を使えば有益であるでしょう。」Klevesaatの指摘によると、技術やツールがギャップを埋め始めており、具体的に挙げれば「.NETのLINQやdb4oのネイティブクエリ、GroovyのDataSets」がある。
これまでの議論を越えて意見を述べたのがIBM RationalのAgile開発プラクティス・リーダーのScott Amblerである。「インピーダンス不整合」の問題に対するAmblerの見解によると、この問題の技術的側面にはいくつかのソリューションが存在する(たとえば、O/R持続性フレームワーク、オブジェクトデータベース、ORデータベース)。それよりもAmblerが指摘したのは、ほとんどの組織において、データコミュニティと開発者コミュニティの間に、Amblerが言うところの「文化的なインピーダンス不整合」が存在することである。「この2つのコミュニティのIT界の考え方には相違があり、それぞれに長所と短所があり、両コミュニティとも、もう片方と密接に協力することで利益を得ることができるのです。」 AmblerはODBMS.orgのケーススタディの枠を越え、このテーマに関してさらに意見を述べたのである(リンク)。
Zicari教授の調査は概して、リレーショナルデータベース技術を使ったオブジェクト指向システムにまつわる問題を浮き彫りにすることを目的としていた。今回の調査では、問題の組合せが適切な場合、そこにオブジェクトデータベースや他のオブジェクト持続技術を適用すれば、前途有望なエンタープライズ技術となり得る、と考え始めている開発会社や事業組織の数も明らかになっている。
原文はこちらです:http://www.infoq.com/news/2008/07/or-user-studies
この論文では、仮想化やクラウドサービスの複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。
Fiberはユーザに試練を課すことなくこの考えを実装する有益な並行性ツールとして、ライブラリが2つあります。まさにこのためのソリューションとしてあるのがNeverBlockライブラリです。私たちはNeverBlockプロジェクトのMohammad A. Ali氏とRevactorライブラリのTony Arcier氏に話を聞きました。
システムの保守容易性や拡張性を確保するためのベスト・プラクティスに関する記事は数多くありますが、この記事では避けた方がいい、いくつかの悪習慣(ワースト・プラクティス)を強調します。
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
No comments
返信