この投稿では、Flexコミュニティのロックスターで、Flex for Dummies(サイト)の著者であるDoug McCune氏(ブログ)が、Flexの現状を説明し、Flexでのカスタム・コンポーネントの構築に関する洞察を語る。さらには、Flex 4の新機能、コミュニティが過去数年でどのように変わったかについて話す。
最初に、InfoQは、McCune氏の最近の様子について尋ねた：
私は、Universal Mind(サイト)で、SpatialKey (spatialkey.com)という名前の製品の開発で忙しくしています。SpatialKeyは、地理空間的な分析とビジネス・インテリジェンス用のFlexアプリケーションです。スプレッドシートにしまい込んだデータをすべて取り出して広げ、より深い分析を行おうとしています。たとえば、Excelファイルに売買取引に関する5万件のデータ・ポイントが詰まっているとします。そのファイルをアップロードしてSpatialKeyを使うと、地図上にそのデータが表示されます。去年1年間を時間の流れで分類し、さらには、1日の時刻ごとにグループ化して、昼と夜で状況を比較することもできます。
仕事の他に、いくつかのオープンソース・プロジェクトを楽しんでいます。5月にインディアナポリスの360|Flexでする話の準備をしようと思っています。私の話は"Cool Shit"というタイトルで、FlexやActionScriptの楽しく実験的な側面を再発見させてくれた実験を紹介しようと考えています。最近は、顔認識やリアルタイムの顔追跡で多くの仕事をしています。また、Flashを使った拡張現実の多くの仕事に注目しています。私も、とてもクールな拡張現実の実験を考え出したいと思っています。
McCune氏は、SpatialKeyなど、クールなユーザー・インターフェイス機能とアプリケーションの構築で有名である。InfoQはMcCune氏に、通常のビジネス・アプリケーションでFlexのクールな側面を活用するチャンスがあると考えているかを尋ねた。
エンタープライズ・ソフトウェアは、ほとんど100%ひどいですが、そうでなければならない理由はありません。RIAのデザインでは「UX革命」が起こっています。それに、「ユーザー体験」を取り巻く無意味な専門用語に関係なく、RIAが提供する体験の全体的品質については、何かが起こっています。コンシューマーRIAでは、本当に優れた革新的な仕事が出てきていて、インターフェイスは簡単で直観的な方向へ向かっています。しかし、エンタープライズ・ソフトウェアでは、この傾向はやっと始まったばかりで、まだまだ複雑です。私は、エンタープライズ・アプリケーションがコンシューマー・アプリケーションと同様に扱われることを望んでいます。ユーザー体験に同じように注目し、すべてを単純化し直観的にしようとする一貫した意欲が必要です。システムが複雑だからといって、それを利用するソフトウェアをわかりにくくする必要はありません。しかし、簡単でエレガントなソリューションを考え出すのには、より多くの作業が必要です。良い簡単なソフトウェアを作るより、悪い複雑なソフトウェアを作る方が、はるかに安く速くできます。
また、直観的なソフトウェアのこういった同じ概念を特にビジネス・インテリジェンスの分野へ持ち込むブレークスルーが始まっていると、私は考えています。ビジネス・インテリジェンスとは、何かの方法で生データから価値を抽出することを難しく言った表現です。通常、これは、チャートやゲージなど、今では標準の、普通のダッシュボードUI要素に限定されています。しかし、私は、フレッシュな観点からBIの問題について考えています。エンタープライズ分野の外にいる誰かの視点から、新しいビジュアル化の方法が発明されるのではないかと思うのです。たぶん、販売実績をばかばかしいスピードメーターに表示するのが、最も良い方法ではないでしょう。たぶん、エンタープライズ・サーバーに蓄えられた生データの山から、より多くの価値を抽出する直観的な方法があるでしょう。しかし、私は、エンタープライズ開発者が、新しい概念を喜んで自分から実験するとは思いません。発明を始める必要があるのです。
次に、Flexでのカスタム・コンポーネントの構築を他の言語/フレームワークと比較してもらった：
実は、私は、ActionScript以外の言語でカスタム・コンポーネントを開発した経験が多くはありません。私は、FlashとHTML開発を少しかじって、Web開発の仕事を始めました。しかし、これは、一般的なJavaScriptフレームワークが広がる少し前のことで、カスタムのAJAXコンポーネントを書くには、ゼロから書く必要があったのです。それ以来、AJAX開発の苦痛の多くを減らそうとするJavaScriptフレームワークがいくつか登場しました。しかし、私がUIコンポーネント開発を学び始め、AJAXかFlashのいずれかを選択しようとしていたとき、JavaScriptでコンポーネントを開発するのは、現実的な選択肢であるようには思えませんでした。特にIDEのオプションや様々なコンポーネント・ライブラリについては、この数年間のJavaScriptコミュニティでの開発の情報を得たいと思っています。
Flex SDKが公式にオープンソース化されたので、Flexフレームワークは、カスタムUIコンポーネント開発を始める最も手軽な方法の1つになると、私は考えています。AdobeとMacromediaが、（公式にオープンソース化される前でさえ）Flexフレームワークの完全なソースコードをずっと発表してきたという事実は、製品や開発者コミュニティに大きなプラスの影響を及ぼしていると思います。Flexフレームワークのサイズにひるむ人もいると思います。確かにコードは多いのですが、思ったほど手ごわくありません。信じられないほど十分に文書化され、よく考え抜かれています。
InfoQが次に尋ねたのは、高品質のカスタム・コンポーネントを構築する方法を学びたいとき、開発者は、Flexフレームワークのどの部分の学習に集中すべきか、という点である。
Flexフレームワークの「比較的小さな」コンポーネントならどれでも、優れた学習教材になります。私が「比較的小さな」とカッコに入れたのは、コンポーネントはすべてUIComponentクラスに基づき、そのクラスだけでも、Flexフレームワークで最大のクラスの1つだからです。そのクラスが、無効化・有効化プロセス全体を担当します。しかし、Flexフレームワークでいちばん良いのは、それがすべてオープンソースであるという点です。だから、Adobeの技術者が何かを作成するのにどういう方法を使ったか、知りたいと思えば、コードへ直接にジャンプして確認できます（Flex Builderで、Controlキーを押したままクラスをクリックするだけです）。Buttonクラスを調べるのが、コンポーネントの基本を理解し始める良い方法です。次に、Buttonを拡張したComboBoxやCheckBoxに何が追加されているかを確かめることは、本当に貴重です。すると、なぜクラスを拡張するか、既存のコンポーネントの上にどのような種類の機能を構築できるかが、わかり始めます。
Flexが最初に発表されたとき、自分でカスタム・コンポーネント開発を行う方法に関するリソースは、それほど多くありませんでした。付属の少量のドキュメントを読み、次に、Flexソースコードに直接飛び込んで、自分で理解する必要がありました。しかし今では、コンポーネント開発に関する大量のリソースがあり、素晴らしいプレゼンテーションもいくつかあります。カスタムFlexコンポーネント開発に関するプレゼンテーションを見るたびに、わかりやすく簡潔になったと思います。Deepa Subramaniamは、Flex 3のコンポーネントのライフサイクルとFlex 4の新しいコンポーネントのアーキテクチャに関する素晴らしいプレゼンテーションをMAXでやりました（そのビデオはオンラインで見ることができます(サイト)）。
McCune氏は、カスタム・コンポーネント開発に対する、よく見かける間違ったアプローチについて語った：
コンポーネントのライフサイクルについて十分に理解していないのが、たぶん最大の問題でしょう。これは、マスターするのに時間がかかる上に、Flexやその基礎になるFlash Playerの動作に特有の内容です。Flexカンファレンスで話をして、自分が無効化ルーチンのいくつかの正しい使用法を知らなかったことに気づかされたほどですから（これは本当です）。これを本当に理解するには、脳に少しドリルで穴を開けて、非常に多くのサンプルコードを読む必要があります。特に、invalidatePropertiesメソッドとcommitPropertiesメソッドの使い方でつまずく場合が多いようです（私もそこでつまずきました）。
カスタム・コンポーネントの作成を学ぼうとしているときに、私が見かける別の大きな問題点は、基本クラスの働きを本当に理解するために、基礎となるソースコードをしっかり読む時間をかけていないという点です。たとえば、Listクラスを拡張している場合、構築の基盤となるListクラスの振る舞いに精通していることが絶対に必要です（また、これが非常に複雑な場合があります）。Flexフレームワークの各行を裏の裏まで熟知している必要はありません。しかし、問題を見つけるためにAdobeのコードへ気楽に飛び込める必要があります。問題をデバッグするため、ソースコードへ気楽に飛び込むことができなければ、次々に壁にぶち当たります。
IInfoQは、Flex 4の最もエキサイティングな点についても尋ねた：
多くのカスタム・コンポーネントを開発してきた多くのFlex開発者と同様に、Flex 4コンポーネントのアーキテクチャの計画が最初に発表されたとき、私は、大きなため息をついて「この方がいいぞ」と言いました。現在のFlex 3のコードベースは非常に強力ですが、多くのカスタム開発を行うと、何度も同じ領域で問題が起こることがわかり始めます。Flex 4のコードベースは、Flex 2と3で何がうまく行き、何がうまく行かなかったかがわかった後に作成されています。それで、コンポーネントを開発するときの考え方の違いにいちばん興奮しています。
Flex開発者、特にコンポーネント開発を専門としている人間は、かたずをのんで、Flex 4の進展具合といつ使えるようになるかを見守っていたように思います。Adobeは、驚いたことに、作業中にもかかわらず、コミュニティに開発の最先端までアクセスさせてくれます。私は、Adobeのソース管理リポジトリからFlex 4 SDKの最新ビルドをチェックし、最新のコードを入手できます。これは、Adobe内部の技術者がアクセスできるのと同じ最新版です。これは驚くべきことです。しかし、Flex 4のリリースはまだ先で、コードは大きく変わるでしょうから、Flex開発者にはつらいことでもあると思います。6か月後には、Flex 4が成熟して、Flex開発者は（私自身を含めて）、新しいコンポーネント・セットをいじり始めることができればと期待しています。
Flex 4の新機能で最も関心を持っている点についてMcCune氏に尋ねてみた：
たぶん、Flash Catalystとそのツールが生成するコードについて最も関心を持っています。Catalystは、設計者が美しいアートワークをドラッグ＆ドロップして、コードを書かずにFlexアプリケーションを動かすことができるようにするのが目的です。それは、私にとっては脅威です。優れたプログラマーが手でコードを書く以外に、何者かが良いコードを生成するのは、一度も見たことがありません。コード・ジェネレーターやWSYWIGエディターは、恐ろしいコードを生成し、その扱いを知っているプログラマーが修正しなければなりません。一方で、私はコンサルティング会社で働いていますが、ひどい生成コードはビジネスになります（もっとも、私たちがやりたいタイプのビジネスではありませんが）。CatalystからFlex Builder（そしてその逆）のワークフローが、デザイナー兼開発者の調和した至福の場であることを心から望みますが、本当のところ私は皮肉屋です。しかし、公平な評価を与えるため、さらに進んだビルドが登場するまでは、黙っていることにします。私は、驚嘆するかもしれません。
また、Flex開発とそのコミュニティがこの2年でどのように変わったかを尋ねた：
この数年間は、激動の時でした。2年か3年ほど前は、Flexコミュニティは開拓時代の西部のようでした。誰もが同時に学習し、誰もが見せびらかしたくてうずうずしていました。私は、信じられないほどに幸運で、ぴったりのタイミングで非常に刺激的な波をとらえました。全体に（また、私自身にとってもそうですが）、Flexの採用が増え、実際にフルタイムの仕事としてFlex開発に忙しくなって、少し落ち着いてきました。また、コミュニティ自身のサイズも非常に変わりました。かつては、flexcodersメーリング・リストの全員が、互いのファースト・ネームを知っていました。今では、Flexを学ぶ人は非常に増えているので、新しく参加した人の数について行くのは不可能です。Flexがはるかに多くの人たちに使われていることを意味するので、これは素晴らしいことです。しかし、昔が少し懐かしくなるときもあります。
最後に、他のFlex開発者へのアドバイスを求めた：
クールでくだらないものを作ること。実験してみること。あっと驚くもの、うらやましくなるようなもの、競争したいと思わせるようなものを見たいと思います。他のすべての開発者が、同じ位すごいものを作りたくて夜も眠れないような、クールなものを作ってください。
McCune氏の詳細は彼のブログで：http://dougmccune.com
原文はこちらですhttp://www.infoq.com/news/2009/03/doug-mccune-flex-development