再び設計思想を再考

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のような思想で走るのならば参照関係の記述方法をエンドユーザに記述可能な形に落とし込む必要がある。
また、設計したモデルからビューを作成するような場合に対しても作成できる環境が欲しい。
そのためには、まず利用者のモデルを技術レベルに応じて何段階かに分けたほうがいいかもしれない。分けた上で利用イメージをがっちり固めて、一気に作ったほうが目的がぶれないだろうと考えられる。