スタートアップ企業のLovely ChartsがFlexアプリケーション構築の見識を語る

Webスタートアップ企業のLovely Charts (サイト・英語)は制限付きのベータリリースを先日発表した。同社のサイトはAdobe Flexを使って作られている。InfoQはLovely Chartsの設立者で首席アーキテクトのJerome Cordiez氏と話し、FlexベースのLovely Chartsのサイトがどのように構築されたかについて見識を得た。

Cordiez氏はまず、Lovely Chartsの簡単な紹介から始めた。

Lovely ChartsはFlexで構築したオンラインのダイアグラム作成アプリケーションで、フローチャートやサイトマップ、組織図、ネットワーク図、ワイヤフレームなど、あらゆる種類のダイアグラムをプロ並みに作成します。料金はかかりません。

したがって、Lovely ChartsはMicrosoft Visioに匹敵するオフィス向けオンライン生産性ツールである。では、この新製品は何が動機となっているのか。Cordiezの答えはこうだ。

基本的に、元々の動機は私自身のニーズとフラストレーションでした。ほとんどの人と同じく、私もいくつもダイアグラムを描くというわけではありませんが、時折は描きます…。ですから、その手助けをしてくれるツールを探していましたが、私のニーズにぴったり合うツールが実は見つからなかったので、自分で取り組むことに決め、既存のソリューションで満足しなかった理由と私が探していたものが何かを調べることにしたのです。その過程から、このプロジェクトの裏にある中心的な決定要因と呼ぶもののリストを作り上げ、とにかく最初の概念実証プロトタイプに取り掛かったのです。

サイト作成プロセスについてもっと教えてもらうために、InfoQは主な設計目標を訊ねた。Cordiez氏は3つの目標を教えてくれた。1番目は以下のとおりである。

簡単に使えること。描いていることを意識せずに、「どうやって」描くのではなく、「何」を描こうとしているのかだけに集中できるほど、簡単に使えるツールを目指しました。

次にCordiez氏は簡単使用の適用範囲について、考えを聞かせてくれた。

ここで言っているのは単に有用性と使いやすさではなく、すばらしい外観の代物を作成することも含まれており、それには奮闘する必要も、デザインの予備知識も必要ないのです。なぜなら、このアプリケーションはそのためにあるのですから。

そのため、2番目の設計目標は以下のとおり。

魅力的なこと。重要視しない人もいるかもしれませんが、不可欠であると私は確信しています。私たちは楽しむためにダイアグラムを描くわけではないのです。他の人々とコミュニケーションをとる必要があるから、ダイアグラムを描くのです。顧客やパートナー、同僚、教師に強い印象を与え、魅了して、納得させる必要があるのです…。基本的にダイアグラムを描くということは、コミュニケーションに尽きます。そして、コミュニケーションを支援する適切な視覚的資料があれば、コミュニケーションがより簡単に、いっそう効果的になると確信しています。

最後の１つは次のとおりである。

非侵入的。これに関しては、37 Signals (source) を引用するだけにします。「皆に好かれるのは、仕事が済むよう手伝って、仕事が終わったら邪魔にならないような、そんな単純なツールです」 

Lovely Charts構築の技術面について、Cordiez氏は次のようにまとめている。

全体がFlexで、ライブラリのコンパイルにはFlashを使っています。LC のようなものは、Ajaxでの構築はまったく目にしません。中間に位置するのがFlex（Actionscript3およびMXML）、 PHP／MySQL、AMFPHPです。クライアントサイド・アーキテクチャのかなりの部分がCairngormフレームワークに依存しています。 

AMFPHP（PHPのリモートソリューション）がバックエンド—フロントエンド間のコミュニケーションを処理します。これにより、保守の簡単な洗練されたOOアーキテクチャが可能になり、このアーキテクチャはかなりトランスペアレントで、フロントエンドとバックエンド間をシームレスに実数型オブジェクトが行き来します。

アーキテクチャの観点からすると、もっと良くできた点、違う風にできた点はあるのか。Cordiez氏は後悔している点を隠さず教えてくれた。

唯一後悔しているのは、PHP階層とデータベースの間にActiveRecordのようなある種のフレームワークを実装しなかったことです。PHP用としてこうした種類のものに取り組んでいる人達が存在することは知っていますが、私が調査した時点では、まだ利用段階にきていないか、私のニーズにマッチせず、私自身のソリューションを導入する時間もなかったのです。 

RIAシステムに関して言えば、Lovely Chartsがなぜ過渡期にあるWebアプリケーションと違っているのか、また、このアーキテクチャはどのように進化するのか。Cordiez氏が意向を教えてくれた。

Lovely Chartsは現在持っている特徴により、ほぼ「クライアントのみ」のアプリケーションになっています…。つまり、現在のところアプリケーションロジックの90%がクライアント側にあり、バックエンドでは基本的にCRUDのようなオペレーションを行っているだけということであり、ですから、実際には現時点の論点ではないのですが、より一層共同するアプリケーションを目指して進化させる計画では、バックエンドの重要性は確かに増大するでしょうし、新しい機能を入れるためには、アーキテクチャを修正する必要が必ずでてきます。 

Lovely Charts開発時に直面した技術的難題を訊ねたところ、Cordiez氏は大きな問題が1つあったことを思い出した。

現在のところ、キーボードショートカットの適切な処理が最大の難題です。初期テスターのフィードバックから明らかなのは、Ctrl-ZやCtrl-Cなどの標準ショートカットの実装を皆が期待していることで、その期待は当然だと思います。でも、当初の印象よりは、ずっと些細なことであることは確かです。

Cordiez氏はさらに問題の説明を続けた。

第一に、たとえActionScript言語が典型的なDOMキーボードイベントを処理するメカニズムを提供するとしても、キーストローク処理システムの保守と実装がアプリケーション全体に渡って簡単に行える標準フレームワークは、現在のところ存在しません。それはアプリケーション開発者の仕事の一部ですから、それはそれで問題ではなく、興味深い課題でもあるのです。

Flex RIAアプリケーション開発の難しさと能力が試される側面について、Cordiez氏は続けた。

けれども、スタンドアロンのコンフィギュレーションでうまく動作する基本的なフレームワークがひとたび出来上がると、FlexアプリケーションはまだWebやブラウザ埋め込み型ですから、ブラウザの互換性問題に直面するようになり、高レベルの大要に目を向けずに、それぞれ個別の問題を解決するためにハックを組み入れていくことにより、アーキテクチャが壊れやすくなっていき、その結果、以前は動作していたものを壊す、などといったことが起こるのです。この種の難題への取り組みを評価する人々がいるとは知っていても、私の考えるところ、これはとてつもなく苛立たしいプロセスです:)... Webサイトの構築時なら、ブラウザ間の互換ハックは容認できますが、複雑なアプリケーションになると絶対に使いたくありません。

こうした難題に直面し、対処しながらも、Cordiez氏は将来については依然、楽観的である。

さて、こうしたことはRIAの典型的な課題であり、他の人たち（例えばbuzzword）がこの課題に直面し、私の見る限り、どちらかと言うと満足できる方法でほとんどの問題を解決していることは明らかで、Lovely Chartsのキーボードショートカットもそのうち標準になり、正しく動作するであろうことを確信していますが、今のところはまだ課題として残っています…。Adobeが将来この問題をどう処理しようと計画しているのか私には見当がつかず、なぜなら、Adobeのセキュリティに関する懸念が現実問題かつ真に妥当なものであるとしても、もしFlash PlatformをRIAデプロイメント向けの無類のリファレンスとして主張したいのであれば、対処の必要がある問題であるということは確実だからです。

Cordiez氏はこの後、Flash／Flexプラットフォーム上での開発経験を語った。

このほかには、これといった技術的な難題はなく、最大の問題はダイアグラム作成において満足のいく新規アプローチを提供する上で役立つ、インタラクションの原則とメカニズムを考え出すことでした…。その上で声を大にして言わなくてはならないことは、Flashプラットフォームがこの点では間違いなく素晴らしいということです。なぜなら、やっかいなコンセプトをすぐにハックして、プロトタイプ作成プロセス全体をとてもアジャイルにすると同時に、「実際に」何かを実装するとひとたび決断すれば、非常にクリーンで堅牢なものを設計できるのですから。この柔軟性を、FlexフレームワークとFlexが提供するすべての機能と組み合わせれば、RIAにおいてより豊かでより良いユーザーエクスペリエンスを構想し、実装するための実に効率的なプラットフォームになります。

最後にCordiez氏は、Lovely Chartsの将来に向けての計画について話してくれた。

2008年第1四半期中には、V1か、少なくともオープンパブリックベータ版をリリースしたいと思って（希望して）います。まだ詳細を話すには早すぎるとは思いますが、例えばAdobeのBlazeDSなどは必ず検討したいと思っています。

V2とその先についてCordiez氏は次のように明かした。

V2では、コラボレーション機能（おそらくリアルタイム）と「ユーザー生成コンテンツ」オプションの追加に特に焦点を当てる予定で、上級ユーザーになるとカスタムライブラリを作成して、それをシェアする、などといったことができるようになります。

V2のもう1つの大きな決定要因は、プレミアム提供機能の改善です。リアルタイムのコラボレーションがその一側面となる可能性は非常に高いのですが、強化バージョンのデプロイメントプラットフォームとしてAIRをとても前向きに検討しており、デスクトップ統合やオフライン同期・ストレージなどを利用しながら、それと同時に、Webベースのソリューションが提供するフットプリントの小ささと「マルチプラットフォーム主義」という利点を維持できるのです。

もう1つ検討中のオプションは、専門家や専門業種向けの専門・上級オプションパッケージへの取り組みですが、現状では優先リストの上位にあるわけではなく、ユーザーのフィードバックや要求によって決めたいと思っています。