BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
- Java,
作者 Sadek Drobi, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年4月11日 午前12時47分
良いドメイン特化言語 (DSL) とは、プログラマ以外でも読むことができる英語のようなものだと広く言われている。Dave Thomas氏は、DSLは自然言語にできる限り近づくものではない(source)と主張し、そのような考え方に反対する。 さらに、これをDSL設計の指針とすることがむしろ有害であると主張する。また、彼が信じていることがDSL設計では重要であることを強調し、必ずしも英語らしくなくてもうまくいくDSLの例を紹介している。
Dave氏によると、DSLは英語や他の自然言語に近づく必要はない。なぜなら、それは実際に自然言語を話さないドメイン専門家など、かなり特別なカテゴリやユーザを対象にするからだ。
ドメイン専門家 [中略] は業界内の専門用語を話します。それは、彼らが仲間同士で効率的にコミュニケーションするための簡単な表現として発明した特別な言葉です。専門用語は英語を使うかもしれません。しかし、英単語にまったく異なる意味をつけて使っているのです。その意味はある分野の経験を通してのみ学ぶことができます。
このように、DSLは専門用語を反映し、簡潔な方法でドメイン専門家の専門知識を表現すべきである。依存関係を管理するMake、コードでデータを表現するGroovy builder、Rubyでデータモデリングを行うActive record の記述などは、ドメイン専門家にとってDSLが必ずしも英語らしくある必要がないことを示す数少ない成功例である。例えば、has_many や belongs_to のように、Active record の記述でいくつかの命令文が英語のようであっても、実際はそうではない。それらは「モデルの世界の専門用語」であり、「コンテキストに特別な意味を持つ」ものである。
Dave氏の意見によると、もうひとつの重要な点は、「ドメイン専門家」はビジネスユーザとしてではなく、むしろ仕様書を書いている人として考えるべきだ。 彼らはプログラマである。本当は英語のような言語など必要ではない。Dave氏は、実際に流暢なインターフェースの概念は誤解されることが多いと考える。「ここで言う流暢さはプログラマの流暢さであって、英語の流暢さではありません。簡潔で表現に富むコードを書くことです。」
Dave Thomas氏は、自然言語に近づこうとすることは必要ないばかりでなく、有害でもあると主張する。自然言語は正確ではない。 これは現実世界では力を持つが、プログラミングに当てはめることはできない。だから、「自然言語のように見えるDSLを作ろうとすると、いつも期待通りにならない」のだ。どんなに頑張っても、シンタックスは「まったく英語らしくなく」なりがちである。そして、このギャップがかなり分かりにくいのだ。
ここに認知的不協和があります。まず、自然言語で表現されたアイデアを持ち (問題) 、 それを人工的な言語 (AppleScriptプログラミングモデル) に当てはめ、偽の自然言語のようなものを書かなければなりません。
問題になる点を示すため、Dave氏は、test/specフレームワークを使って書かれたテストからコードを抜き出して例を示し、1つの式を分析している。
@result.should.be.a.kind.of String
これは英語のように読めます。しかし、実際はそうではありません。最後の2つの単語がスペースで分けられている以外、単語はピリオドで分けられています。プログラマとして、私はなぜだか知っています。しかし、ユーザとしてはそれが気になります。最初の例で、@result.should.be.a.kind_of と書きます。なぜ kind.of ではないのでしょうか。もし、浮動少数がおおよそ等しいというテストが必要ならば、@result.should.be.close value と書いたでしょう。なぜ、close.to value ではないのでしょうか?
これは取るに足りない詳細なことですが、それでも英語の知識を使ってただテストを書くことはできないということを示しています。よく調べなければならないのです。そして、もしそうしなければならないならば、なぜ仕様やテストのドメインにより近い言語やAPIを使わないのでしょうか?
英語のようなDSLの方が読みやすいというのは本当だが、Dave氏は「DSLの自然言語的な感覚を作り出そうとすることで、抽象的なことが扱えなくなる。」と指摘する。コードが読みやすくなるかもしれないが、「書きやすさがなくなり」、「不確かさとあいまいさが増える」のだ。
二番目に、このように書いていることに気づきます。def a
self
end「a」をコネクタとして使うことができます。
add.a.diary.entry.for("Lunch").for(August.10.at(3.pm))
一線を越えたことがわかるでしょう。これは、もはやDSLではありません。片言英語です。
Dave氏のブログのコメントで、Has氏もまた、プログラマ以外の人に読めるような言語にしようとすると、「読み込み専用言語」になる危険性があるとの考えを示した。彼はAppleScriptの例を挙げている。AppleScriptは、読みやすくするために「言語のセマンティクスを記述するお決まりの記号的なものをほとんど」削除する必要があった。結果として、「構文は、言語のセマンティクスを明確にするのではなく、事実上混乱させる」ことになる。「AppleScriptを読んで、_what_ が何をするか理解するのはとても簡単だとしても、_how_ が何をするか正確に理解するのはかなり難しい」のだ。
Has氏は英語のようなDSLを使うことから起こりうる別の問題点を指摘する。:ユーザは、「英語のように見える(_looks_)から、英語のように振舞う(_behave_)。」と思うかもしれない。そして、「英語のようであることに強く関連付けて結論を出してしまう。しかし、実際はそれで終わりではない」のだ。 このように、Has氏によると英語のよう見えることは「意図せずにユーザに非現実的な仮定を促す」ことになる。
もし、DSLの読みやすさと表現力に興味があるならば、Dave氏のブログ(source)でもっと他の例やコメントを見つけよう。
原文はこちらです:http://www.infoq.com/news/2008/03/dsls-are-not-natural-languages
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
ウィルス対策ソフトや情報漏えい防止用のソフトは、いわば影の存在です。ユーザの操作性やGUIを工夫する以上に、いかに目立たない存在となるかにその技術を注ぎ込んでいます。ここでは日立ソフトが開発した「秘文」の事例を紹介します。
Google Chartは、チャートを作成するためのWebサービスです。本稿では、Google Chartのインターフェースと、Rubyコードから簡単にチャートを生成することができるgchartrbライブラリの説明をします。
全二回からなるこの記事では、ダイナミックビジネスアプリケーション(Dynamic Business Applications:DBAs)の開発についての全体的な眺望を、アーキテクチャと方法論の観点から見ていくことになります。我々のゴールは、「ビジネスの変化や、その他に必要とされる変更に対して、いかにして容易に適応できるアプリケーションを構築していくか」を導きだすことです。
本稿では、Adrien Louis氏がESBベースのSOAに対する2つの接続形態についての賛否について説明しています。その2つとは、会社での単一のESB対「部門毎」に相互接続するESBによるシステムです。
誕生から2年を経てCometは「何が出来るのか」という議論から、「いかに実現するか」という議論に関心が移ってきたように見えます。そこで本稿では同じくJavaOneで数多く取り上げられたNetBeans 6.1とGlassFish v3を使いながら、サンプルを交えてCometを解説していく事にします。
この記事では、WSS3とMOSS 2007に難しい設定など一切せず、すぐに利用可能なWebサービスと、Javaと.NETからそのWebサービスを消費する方法に目を向けます。
この記事の始まりは、知的で思慮深い人たちの魅力的なグループが食事会を終えて話をしているところです。話はレトロスペクティブ(振り返り)プロセスの要であるプライムディレクティブ(最初の指示)に及んでいます。
No comments
返信