Curlソフトウェア開発という難題に立ち向かう

その他

IBM developerWorksの記事です。


Ajax と REST、第 2 回
http://www-06.ibm.com/jp/developerworks/web/library/wa-ajaxarch2.shtml


Ajaxなアプリケーションの開発に取り組もうとする組織に対して警告や助言をしています。
それらの多くは、curlについてもそっくり同じように当てはまりそうです。


記事は、いきなり本格的なAjaxアプリケーションの開発に着手するのではなく、部分的なAjaxの採用から開始することを勧めています。Netflixというのは、そういった部分的なAjaxの採用をうまく行った組織として、記事の中で名前が挙げられている企業です。

純粋な Ajax/REST は歴史の浅いアーキテクチャー・スタイルです。JSP (JavaServer™ Pages) 技術や PHP などの確立された Web アプリケーション・スタイルに比べると、その実装はまだ困難です。次世代 Web のユーザー・エクスペリエンスを提供することが第一の要件であり、そして世界的な Web 開発チームが控えているのでない限り、初めは Google のような「大規模な Ajax」ではなく、Netflix のような「局所的 Ajax」を採用するほうが組織にとっては有利に事が運びます。

curlもまだまだ歴史が浅いです（リッチクライアント技術の中では最も古株ですが）。また、リッチなユーザーインターフェースというのは、素人でも（もしくは素人であればあるほど）いろいろと想像力を働かせることができてしまうため、得てして身の丈に合わないアプリケーションを志向してしまいがち、といったところでしょうか。

新しいものに下手に手を出して派手に失敗するプロジェクトほど、有益な新興技術を急速に衰えさせるものはありません。通常、スキルが十分にないのに多くのことを時期尚早にやろうとすると、このような結果になります。けれども今の時点では、非凡な Ajax 開発の経験を持つ開発者を見つけるのは困難です。この技術はとにかく新しすぎるからです。

過去 10 年間に渡って PHP、Java、あるいは .NET のサーバー・サイド Web アプリケーションを提供してきた Web 開発者のチームなら、専門的な Ajax 開発者に転向するのもわけないと考えがちですが、そう簡単にはいきません。同じ Web 開発の世界であっても、Ajax アーキテクチャー・スタイルとそれをサポートする技術では、いずれも、開発者が古い概念を捨て、新しい様式とパターンを学ぶ必要があります。つまり、転向は可能ですが、時間がかかります。

「大規模な Ajax」では、開発チームがなおさら重要になってきます。実証されたアーキテクチャーを新しい技術で拡張するだけでなく、新しいアーキテクチャーに着手しようとしているからです。チームは、Ajax の経験がほとんどない状態で、主要な設計を決定しなければなりません。決定によっては、恐ろしく間違った方向に進む可能性もあります。

これらもAjaxの部分をcurlと置き換えて読みたくなる部分でした。
Ajaxは単なる既存技術の組み合わせですが、それで実現するものが新しいアーキテクチャスタイルであるという点が開発を難しくするということだと思います。しかし、新しいアーキテクチャが大きなインパクトを持つということは、多くの開発現場でまだ合意された事実ではありません。既存アーキテクチャの単なる拡張ではない、大きな変更に挑むということは、ほとんどの開発者にとって頻繁に遭遇する事態ではないためでしょうか。

Ajax アプリケーションの開発には、2 つの異なる作業が伴います。1 つは、HTML/JavaScript/CSS/DOM による UI とアプリケーション・ロジックの実装、そしてもう 1 つは PHP、J2EE、.NET などの確立したサーバー・サイド・プラットフォームによるサービス・ロジックの実装です。

少し脱線しますが、curlでもクライアントサイドのUI、アプリケーションロジックの実装に、既存技術であるPHPやJavaなどを用いたサーバーサイドのサービスロジックの開発が伴うという点は同様です。確認まで。


以下は記事のまとめにある文章です。

Ajax 技術を採用する際の最大のリスクは、業界での実際的経験が乏しいということです。そのため私が推奨しているのは、小規模なものから始めて、プロジェクトに大きなリスクを与えることなく開発チームが経験と自信を培うようにできるようにするということです。現時点で Ajax のみでの開発に飛び込むならば、現実的に成功する見込みが低いという理解のもとで行ってください。世界有数の Web 開発チーム、そして繰り返しを重ねる開発と実験をサポートするような開発組織がなければ、失敗は目に見えています。

これほど脚光を浴びているAjaxであってもこのような忠告がなされています。しかも、Ajaxの個々の要素技術自体は既存のよく知られたものばかりです。いわんやcurlは・・・と痛感。より一層の努力が必要ということでしょうか。誰でも簡単に開発ができるような画期的なツールやAPI、フレームワークの出現を信じて待つだけでなく。


ちなみに記事の最後は以下のように締めくくられています。

やがてより多くの実践者が経験を積み、フレームワーク、ツール、そしてベスト・プラクティスが現れるにつれ、難易度もリスクも低くなっていくはずです。Ajax はエキサイティングとは言えないまでも、一層安全でより日常的になることでしょう。