JoshuaTreeの位置づけ 第三回

第三回　JoshuaTreeが向かおうとするところ。

とはいえ、Torusは担当がUIであるので、利用形態とかそんな感じの話であるのですが。
機能についてはあまり深く立ち入っていないです。

JoshuaTreeはクライアントサイドで動作するマッシュアップアプリ開発環境である。
マッシュアップアプリ、という点が重要で、Yahoo! Pipesとは少し違います。
要はアプリを作成するものである、ということです。

アプリを作成する、ということで重要になるのが、Viewを作る必要があり、
マッシュアップの設定をするフェーズと、
マッシュアップからの情報の表示方法を設定するフェーズが必要になると思われる。

ここで重要になるのは、どちらに重点を置くのかということです。
第二回で書き散らしたように、アプリを作成するための開発環境ということで、
Yahoo!Pipesとの違いを鮮明にすることは、差別化の一つの道筋だと思います。

しかしながら、他にもマッシュアップフレームワークは多数存在するわけで。
マッシュアップを作成するフェーズでも、Viewを設定するフェーズでもその差異を
求める必要があるのかな、と思います。

迷いの森に入り込んだ気がしますが。次回は他のフレームワークについて少しアタ
ッチしてみようかと思います。

Joshua Treeの位置づけ 第二回

少し時間があったので更新しようかと。

第二回　Yahoo!Pipesとの差別化

えっと、やっぱり少し見え張ってるみたいに見えますがそんなことはないです。
Yahoo!Pipesはとてもよくできたマッシュアップ用のWebアプリケーションであると思います。その点ではTorusはただただ脱帽するばかりです。
しかしながら、Yahoo!Pipesはマッシュアップを作成するためのWebアプリケーションという位置づけなんです。ここが肝です。つまり、マッシュアップを作成することが目的なのであって、アプリケーションを作成しようということではないんです。利用したことがある人は分かるかと思いますが、Yahoo!Pipesには表示に関する設定をすることがほとんどできません。

Yahoo!Pipesはそのコンセプトとして、作成したものは全て自社のサーバにホスティングされ、新たなWebサービスとして呼び出して利用することを提示しているように思います。だからサーバーサイドスクリプトなんだよ!という論理が成り立つわけで。

つまり、アプリケーションとして必要な部分はYahoo!Pipesからは抜け落ちているように思うんです。それは通信量の削減であったり、ユーザ操作に対するインタラクティブな挙動であったりとか。
そういった意味でYahoo!Pipesと我々の作成するフレームワークとの差異は其処にあるような気がしてならないんです。今のところ。

長々と駄文を書き散らしましたが、とにかくそんな感じです。といってもここでの差はまだ、Torusの担当する範囲ではないのであまりえらそうなこともいえませんが。

次回はJoshua Treeの目指す方向性なんていうものをつらつらと記述していこうかな、と思っています。駄文で申し訳ありませんが。

Joshua Treeの位置づけ 第一回

これはなに？という問いかけに何も答えていなかったと思われるので、今日はこの"Joshua Tree"の話を含めてMotivationの部分を複数回に分けて説明して行こうかな、と思います。

第一回　Joshua Tree作成の背景

タイトルはかなり威圧的ですが内容は薄っぺらいです。

マッシュアップについての説明はこちらを参照。イメージの掴みにくい場合は、旅行サイトとかにに組み込まれている地図とかを想像してもらってもかまいません。あれもマッシュアップの一部ですから。

元々、マッシュアップを作成する場合はJavaScriptとかPHPとかPythonとか、PerlにRubyにFlex、HTMLにXML、Java等のプログラミング言語を理解していないといけませんでした。まぁ、プログラムですから当然ですね。

昨今こういった状況に対して、プログラマでなくても簡単にマッシュアップを行えるツール、フレームワークというものが提供されています。代表例がYahoo!のYahoo!Pipesですかね。

"Joshua Tree"も平たく言えばYahoo!Pipesなどと同じ、マッシュアップをプログラムを書かずにできるフレームワークということになります。平たく一言で分類すれば、の話ですが。

そんな、今あるものを作っても仕方ないじゃない？と思われると思います。しかしながら、私のスタンスとYahoo!Pipesのスタンスは少し違います。対象としているものが少し違うわけですね。そういうわけで、今回の"Joshua Tree"を開発に相成りました。

スタンスの違い、については次回に回します。今日はこの辺で。

再び設計思想を再考

Mash Makerとどのように差別化を図るのだろうか。
Mash Makerはマッシュアップの最小単位であるWidgetを編集することはプログラミング知識のない人間に対しては難しいことがある。
我々のフレームワークでは誰でも簡単にデータ構造をいじることができ、その内部のデータにアクセスできる構造にしようと考えている。そうするとView（Widget）内でのモデルの表現をどうすればいいのかな、と考える。
extractList一つに対してGridを宛がう、くらいの設計でもいいのかもしれない。そう考えるようにもなってきてはいる。しかしながら、Grid程度ならいいが、現状ではMapの表現をどうするのか、ということは議論されていない。また、Model側でもJoin演算などの問題がある。
どうしたものだろうか。

閑話休題

これだけ優れたインフラがあるので、このインフラを如何に使いこなせる環境に持っていくのかということが大事だと思う。
その上で、今まであまり考えていなかった、Webサービスを簡単に作り出せるようなインターフェースを作り出す必要があるのかもしれない。現状ではあまりにもカードが少なすぎて、インフラの能力を生かしきれていないと思われる。
エクセルのデータを放り込めばそのままWebサービスになるような環境を作成すれば、もっとアプリケーション領域が広がっていく気がするのだが…。

とかく、少しいじってみようかな？PHPやPythonとか。

記述方式の思想

記述方式の思想をどうするか。
Yahoo!Pipes、Afrous、MashMakerなどのたくさんの、いわいるマッシュアップ作成環境では、作成したものに対しての思想が少し違う。
Yahoo!PipesやAfrousは、作成したデータモデルをWebサービスとして提供するという思想をしている。我々の思想では作ったデータモデルはそのデータ構造のまま部品化をするスタンスを取っているので、この方式はあまり良いものではない。
MashMakerは部品をViewとして保存、ブラウザの部品として利用可能。こちらの方法が我々の思想にあってはいると思われる。
今後、MashMakerのような思想で走るのならば参照関係の記述方法をエンドユーザに記述可能な形に落とし込む必要がある。
また、設計したモデルからビューを作成するような場合に対しても作成できる環境が欲しい。
そのためには、まず利用者のモデルを技術レベルに応じて何段階かに分けたほうがいいかもしれない。分けた上で利用イメージをがっちり固めて、一気に作ったほうが目的がぶれないだろうと考えられる。