Netdocs の頃の時代と現代の技術者の働く「場」

 Life is beautiful に関する投稿が続くが、今回は「マイクロソフトがついにオンライン版の Windows と Office を作ると発表」に取り上げられていた、MSの過去のプロジェクトNetdocs「Secret project may be Microsoft's next big deal」の話。

 このNetdocsの記事は、2000年の12月だが、この頃私はあるソフトウェアをウェブアプリケーション化するために、IISやらASPやらを触っていた。その取り組みは振り返ってみれば画期的なことだった。普通のWindowsアプリケーションではあるが、ウェブアプリケーションのUIも提供しようというものだ。当時の上司には私にまかせてくれたことに感謝したい。

 それ自体は1998年頃からかやっていたのだが、その頃はActiveXで強引にウェブアプリケーションっぽくするか(ブラウザに張り付いているだけです)、ASPで現代のウェブアプリケーションらしく作りこむかという選択肢があった。当時VBScriptを使ったが、最初は概念を理解できず、サーバーサイドスクリプトでメッセージボックス表示処理を書いたりして、わけわからないことをしていたことを覚えている。ActiveXで強引にというアイデアも、当時としては画期的ではあった。そんなことを、MSDNを読みながら、数少ないASPの本を読みながらやっていたと思う。

 当時の会社ではNetdocsの件のような組織上の対立も無く、ローカルアプリケーション用のエンジンを上手く使いつつ、ウェブ用のインタフェースを作りこんだものだ。

 現在は猫も杓子もウェブアプリケーションにし、アプリケーションをパッケージではなくサービスとして提供することが始まっている。現時点でそれがビジネスとして成功するために必要なキーが何かはまだわからないが、Netdocsのような先進的な試みが途中で消えたことは非常に残念でならない。

 もし、MS-Officeがウェブアプリケーション化されていたら、IEのシェアがFireFoxにこれほど奪われることも無かったかもしれない。それだけでなく、現在販売されているウェブベースの文書管理ツールやナレッジマネジメントツールがとてつもなく使いやすいものになっていたのでは無かろうか?

 さて、話は飛ぶが日本にいる多くのエンジニアの中で、数年後の未来を信じて新しい製品開発に取り組んでいる人材はいったい何人いるのだろうか?顧客の口から湧き出る目先の対処療法的なカスタマイズやバグ取りではなく、数年先を見た仕組の開発、そういう開発ができる「場」を提供することこそが経営者として必要ではなかろうか。

 20人即戦力を採用するとブログで宣言した、とある会社の社長が、20人即戦力のエンジニアをパフォーマンスチューニングやちょっとした機能追加に使わないことを願っている。

技術者諸君これを使い給え。その名はUIEngineだ。

 「クロスプラットフォーム」この言葉に何人の人間が踊らされたことだろうか?Write Once Run Anywhere、このメッセージはどこに行ったのか?以下に続く本文とあまり関係無いが、私の疑問である。

 中島氏が語るヴィジョン、例えばこれらの記事

アルファギークはLonghornの夢を見るか?

Google OS を妄想すると未来が見えてくる!?

パーベイシブ・アプリケーションという世界観

ここから何を読み取るか?AJAXで使い勝手の良いWEBアプリができてうれしいとか、Googleががんばっててすごいとか、そんなことではない。変化は身近におこりつつある。

従来型のOSは、たった一つのコンピューターが提供できるシステム・サービスの集合体でしかなかったのに、Google の提供するサービスは、Google が持つ何百台・何千台のサーバー郡どころか、その先にある、インターネットに繋がった地球上の全てのサーバー、センサー、カメラ、各種デバイス、何億人も のユーザー、により実現されるサービスの集合体なのだ。言い換えれば、この地球上にあるネットに繋がった全てのものを一つの巨大なシステムとみなし、それ らの提供する各種サービスをユーザーやプログラムからアクセス可能にするのが Google の役割なのである。

中島氏はこのように書いている。注目は下線部分。身近にあるあらゆるセンサーやらカメラやらデバイスがつながると言っておられる。いつ頃とは書いていないが、Googleという固有名詞を出す以上数年以内と踏んでいることは間違いない。(数年以内でなければ将来は、、、ぐらいにして濁すだろう。)

 中島氏がGoogleの名前を出しているので、UIE社とGoogle社との直接的な提携はまだ無いのだろうが、UIEngineの特徴も考えれば、センサーやらカメラ、各種デバイスにUIEngineを載せてしまえと動いているに違いないのだ。

 技術者諸君、身近にあるデバイスがシームレスにつながったときどんなサービスが提供できるのか?もう考えてもいいころだ。数年前までは妄想でしかなかったことが、実現可能なレンジに入っているのだ。時代は変わりつつある。

 新しい変化の前兆、その中にいて何をすべきか、自分がどんな役割を果たすべきか。一兵卒で終わるのか、それとも違うのか。変化は続いている。

 Win95,IE3,IE4とつくり続けた人間が、それらの完成を見た後、その次に見たものが何だったのか?最高傑作をうんだ瞬間に「次」が見えてしまう、それはものづくりに携わる人間にとっての宿命である。仮に中島氏がこの時代にうまれた天才だったとしたら、彼が見た「次」を覗いてみても良いではなかろうか?

 中島氏のブログを古いものから読みたい方は2004年1月からのアーカイブをごらんください。

UIEngineとUIEPlayer テクニカルタームの使い方

 最近UIEngineのことを人に話す機会が増えてきたが、UIEngineとUIEPlayerの用語の使い分けに苦慮することが多かった。日本にはUIEngineのことを知らない人の方がどうやら多いので、そういう人たちに向けてUIEngineについて話すときのアドヴァイスをひとつ。

「UIEPlayerという言葉を口にしない。」

 話し手はUIEngineとUIEPlayerの差を理解しているが、聞き手は最初は理解し得ない、と思ったほうが良い。話し手としてUIEPlayerと言うべきところもUIEngineと言った方が良い。聞き手が「技術的にどうなっているのか?」と興味を見せたとき初めて出せば良いだろう。

スクエニがついに発表 UIEngineでFFだ、おそらく。

 ファイナル・ファンタジーの新作は「ファイナルファンタジーXIII」。こちらは、プラットフォームごとに、異なる世界観やストーリーが楽しめる 「FABULA NOVA CRYSTALLIS」(ファブラ ノヴァ クリスタリス)プロジェクトとして展開される。中心になるのは、PS3向けの2タイトル「ファイナルファンタジーXIII」と「ファイナルファンタジー ヴェルサスXIII」だ。さらに携帯電話向けの「ファイナルファンタジー アギトXIII」も明らかにされた。

ということだ。クロスプラットフォームならUIEngine使うことは間違い無い。具体的な話はこのニュースでは確認できなかったがいよいよ本格展開ということではなかろうか?

ニュースソース

 実際のXIIIの形は不明だが、UIEvolution CEOの中島氏のCnet上のブログにおいて

  以前から、UIEngineを使ってファイナルファンタジーのゲームを作りませんか、というようなアプローチをしていました。

という話もあったことを書いている。予想の域は出ないが、何らかの発表があるかもしれない。

_link() cook

 この投稿はUJMLが分かる人のみ理解できるでしょう。

 これまで別<partition>で定義した処理を _link() 関数で呼び出していた。共有は必ず親→子の関係でなされるので、親は子の<function><variable>を使えないと思い込んでいた。_link() 同士は同期的に実行されるので、実行時遅延が生じやすい。浅はかだった。

 親側で子の関数を呼び出すためのステート変数を export しておけば、ステート変数を変化させることで子で実装されている関数を実行させることができる。これなら _link() による実行遅延も生じない。なるほど。サンプルソースは次回以降に。

JavaApplet版のPlayerで_getIntProperty( &_VALUE_INT_ONSELECT_X_REL; )がいつもゼロなバグは直ったのか?

 実はJavaApplet版のPlayerにバグがあって

_getIntProperty( &_VALUE_INT_ONSELECT_X_REL; )
_getIntProperty( &_VALUE_INT_ONSELECT_Y_REL; )

という、マウスクリックされたポイントのX,Y座標を取得する処理で常にゼロが戻っていた。これは果たして修正されたのだろうか?PCはマウス前提でアプリを組みたいものだ。PCならマウス、携帯はマウス無しを前提にインタフェースを作成できたらこれは楽しい。

 「PCでもマウス使えないようにしたら?」と結論しても良いが、携帯上でPC上で動作するアプリが、デバイスの良いところを取ってユーザーインタフェースを提供する、そういう考え方をするのが新しい挑戦かもしれない。

_discard("/*")は期待通り動作しました

 以前_discard("/*")が期待通り動作しない旨報告したが、使用していたUIEPlayerの問題だった。現在リリースされているPlayerでは期待通り動作する。

「UIEngine的やってはならない」をそろそろまとめよう

 UIEngineベースのアプリ開発にはUJMLという言語を使うが若干癖がある。そのうち「UIEngine的やってはならない」をまとめようとは思うが、既にUJML2.0もベータ版が出、現在UJML1.5をメインに開発している私としてはそれが必要かどうかよくわからない。

 基本的には「平」でソースコードを書いていけば問題が無い可能性が高いことはわかった。ごりごり書いて2000行近いもので色々やっても平気だった。問題はリファクタリングを試みたり、コンポーネント化して再利用性を高めようとするときに起こる。もちろん私が仕様を100%理解していないことも原因なのではあるが、インサイドUIEngine的なドキュメントがそろそろ必要だ。

トラックバックステーションはちゃんと動いているのか?

Trackbackstation_3 UIEジャパンさんが、UIEngineに関するトラックバックを受け付けるトラックバックステーションを運用中だが、私の投稿の何件かがトラックバックされていないようだけれども、しっかり動いているのだろうか?

UIEngineのRPGツクールってGameTellerとは違うのか?

Gameteller 「UIEngineでAJAXなRPGゲーム」という投稿で

---
 ちなみに、このRPGゲームを共同開発する際に、うちのエンジニアが最初に作ったのは、UIEngine上にRPGゲームを作るためのツール。これを使 えば、プログラマーでなくともRPGゲームが作れてしまうのだ。そのうちウェブ・ベースのものでも公開したいと考えているので、少々お待ちいただきたい。
---

と、あるが、これはUIEvolution GameTellerとは違うのだろうか?

教材としてのUIEngine

Binary_atodeyomitai UIEngineは小さい。言語仕様も小さい。ujbcバイナリコードもシンプル。だから、大学の情報系の教材としてうってつけではないか?(恐らく半年ぐらいで終わる)と、ujbc バイナリコードを見ながらそう思った。

 ujbc のバイナリ仕様とVMであるUIEPlayerの仕様が公開されれば実現できるがどうだろうか?草の根活動である。UIE社の誰かが大学の講師になれば良い。仕様公開は難しいかもしれないが、いずれにせよ情報系の学生にVMの概念を教えるのには調度良いサイズだと感じたのである。

UIE社が本気になった?UIEngine開発者フォーラムでバグトラックを開始。

Forum2 私の働きかけのせいかどうかは知らないが、UIEngine開発者フォーラムでのバグ報告に対してトラック用のIDをつけてもらえるようになった。恐らくUIE社内でのバグレポートシステムと同じIDにしているのだろうが、こういう感じの対応は好感できる。

 まぁ、私がぽこぽこ致命的なバグを送った結果だと信じたいが、最初からそうしなかったのはこちらに置いておいて、変われるということは素晴らしいことである。このように地道に進化するフォーラムに参加することをおすすめする。

トラックバックステーションの左のタイトル一覧は、マウスオーバーしたら全タイトル読めるようにして欲しい

Bellx

トラックバックステーション、活用中。できれば、トラックバックステーションの左カラム内にあるタイトル一覧はマウスオーバーしたら全文読めるように工夫すると良いと感じた。

UIEngineが扱うStringの長さは最高いくつ?

 実行時には 65535 バイト、つまり、2バイト数分確保できるらしい。デバイスのメモリ制約によってそれが期待通り処理されるかどうかはわからないが、、という話。

 また、UJMLのソースコード上ではUTF-8変換してバイトコードにするため、3バイト必要な文字のみの文字列の場合には21,845文字が最長となる。これは、コンパイルされた ujbc をバイナリエディタ等で見るとよくわかる。コンパイル時にUJMLの""文字列は定数としてconstant-poolエリアにバイトコード化される。最初の2バイトで文字列長を、それに続いて文字列が格納されているのだ。文字列の長さは2バイト分しか確保しない仕様になっているのでということですな。

multi-label の改行ロジックにバグ

 以前に書いたmulti-labelエレメントの改行ロジックのバグだが、やはりバグだったようだ。UIEngine開発者フォーラムにて、2,3週間で修正するという回答をもらった。対処方法としては、半角スペースが悪さするので、半角スペースはすべて全角スペースに置換すれば問題は起きない。※逆に英文表示はかっこわるくなるが仕方が無い。

トラックバックステーションができたものの、全部記事トラックバックすべきか悩む

Trackbackstation_1 UIEジャパンが「トラックバックステーション」を開設した。本ブログはUIEngineに関することしか書いていない。全記事トラックバックしても良いのだろうか?とりあえず全記事トラックバック方針で進めよう。

_discard("/*")は期待通り動作するのか?

 _discard()という関数がある。_link()実行時にデバイスにキャッシュされたものを強制削除するための関数だ。_discard()関数の引数にはURLを渡すが、"/*"を渡すと全て削除できるらしい。が、期待通り動作しない現象が発生しているのでUIEngine開発者フォーラムにて問い合わせ中。

UJML2.0のLanguage Referenceが出ましたよ

UJML2.0のリファレンスが出た。ざっと見ただけでも _castInterface(), _createInstance(), _instanceOf() 等の関数が追加されていて、あぁ、OO化したのかなという感想。

UIEngineが多くのデバイスに簡単に対応できるのはなぜ?

 UIEngineは小さくて良い。小さいから多様なデバイスに載せることや、各種ランタイム(Flash等)に載せることも容易だ。ソースコードが小さく済むので可読性も高いプログラムとなり、移植性も増す。

 小さいだけでなく恐らく、設計にもその肝があるだろう。UIEPlayerはイベントのハンドリングをする部分Bと、各種処理を実行する部分A、描画処理をするXにモジュール分けされている気がする、ujbc を解釈して各種処理を実行する部分Aはデバイスによらず共通化できるのが強い。

-----こんな感じ
[描画処理]X
[各種処理]A
[event handle]B
-----

 デバイスによっては、不思議なマンマシンインタフェースがあり予想外のイベントを発生させることもあろうが、それとはB部分に影響し、A、X部分には影響しない。いくらなんでも四則演算できないデバイスにUIEngineを載せることは考えにくいので、A部分を変える必要は殆どないわけだ。A部分は、どんな言語でもできることや書き方は似ているので移植も容易だ。(変数Xに値1を代入するときに、X=1と書くのが普通ということ。)

 残った、Xの描画処理はデバイスが備えているAPIを叩けば良いのでスマートに移植できるはずだ。角の丸い四角を無理に描画しようとしないところにUIEngineの移植性の高さを垣間見る。無理はしないのだ。

 これらがUIEngineの持つ特長の一つであるデバイスポーティングの容易性の肝なのだろう。

_link()はたとえキャッシュされていようとも、シーケンシャルに実行されます。という話。

Forum  UIEngineには開発者フォーラムというものがある。ここで一日一質問することを目標にしているが、なかなか難しい。できるだけ他の人もつまづくだろうと思うものを質問した方がその質問の価値は相対的に高くなる、という考えに基づいてこちらも選ばなければならないからである。

 そんな中で最近した質問は、_link()はシーケンシャルにしか実行できないのは何故?というものだ。_link()は実行命令が出された順に同期的に処理される。つまり、次の_link()は今処理中の_link()が終わるまで実行されないということだ。

--- main.ujml (UJML1.5)
<script>
_link("hoge1","http://hoge/hoge1.php");
_link("hoge2","http://hoge/hoge2.php");
...
---

 例えばこのような場合は、hoge1のリンク処理が終了するまではhoge2の処理は開始されない。

 何故、私がこの質問をしたのかというと、hoge1の_link()がサーバー側の都合で処理に時間がかかっているとき、hoge2の_link()にキャッシュが残っていたら*先にそれを使ったらいいのでは、と思ったからだ。UIE側からの回答は、「_link()の目的を考えると、処理順序をUIEPlayerが判断して行うのはアプリケーション開発者にとっては管理しにくくなる。そんな仕組はバグを産むので不採用だ。」ということだが、まさにその通り。

 そして、「より重要なものを先に_link()すべし。」という回答だった。

 まぁ、こんな感じの通信遅延で困るのは、そもそもUI設計が「おもいやらないUI」になっているからであり、「おもいやりUI」で設計していたらこんなことも無いのだが。

*:UIEngineは_link()したものを明示的に_discard()されるまでメモリ中にキャッシュする。次回同じURLで_link()したときはキャッシュを優先的に使う仕様になっている。

UIEngine on Wikipedia 無いなら書いてしまえという話

Wikipedia WikipediaにUIEngineが無いと書いたが、せっかくなので書いてみた。ほんのさわりだけだが、続きは太郎日記'79Jさんにバトンタッチだ。

そういえばWikipediaにUIEngineを載せてもそろそろ良いのでは?

Bellx Wikipediaという便利な百科事典サービスがあるが、UIEngineは登録されていないようだ。

非同期通信が売りなのに、同期的に作ってしまう輩が多いなんてことはありませんか?

Sync  UIEngineは非同期通信が特長のひとつだ。しかし、うっかり私はUIに対し同期的に通信する仕組みでアプリケーションを開発している。それは慣れていないからなのだが、UIEさんには非同期通信はこんな感じで実装すると良いというサンプルを次々発表して欲しいものだ。

 つまり、「Zipcode converter app」として公開したものも、「F2 to get city/state」などとボタンがあってはだめなのである。インクリメンタルサーチ等、非同期通信の特長を活かしたものだけ公開して欲しい。いや、まぁ、これはスクリプト版のコンパイラーが出たよという告知なので、という話もあるのだろうが。

 さて、UI開発における非同期通信の肝の一つは「先読み」することではないだろうか。ユーザーの次の行動を予測して、その行動の結果を先読みし、遅延を感じさせずに結果を表示させるのだ。最近はカーソルがリンクに近づいたらリンク先のページキャッシュを開始するといったブラウザも出つつあるようだが、そもそも日本人の思考と行動はこの考え方に近い。

 察して知る。ツーカー。以心伝心。

 表情やらしぐさ、言葉遣いまで全神経を投入して相手の考え、次に何をしたいのか、何を言わんとしているのか、それを感じる訓練を続けてきたはずだ。つまり、脳内はそのようにチューンされているはずだ。仮に、ここで取り上げた先読みするUIを「おもいやりUI」と呼ぶとすると、「おもいやりUI」はそういう以心伝心文化を持った人間が作った方が良いかもしれない。

 ここまでくると、「とはいっても、所詮、機械に入力されるインプットは限られてますから。」と反論されそうだが、つまり、インプットが限られているからそんな複雑怪奇な文化は無くても予想できる、ということなのだが、何が正しいのかはさておいて、日本人の技術者の方には脳内をフル稼働させ「おもいやりUI」の開発に励んで欲しいものである。

 私は残念なことに、ことプログラムにおいては同期を前提とした「おもいやらないUI」の開発に慣れ親しんでしまったため再出発の必要がある。まだ何にも染まっていない新しい若い力が「おもいやりUI」として新たな革新をおこすのではないかと思っているがどうだろうか。

PC用のUIEngineはJavaAppletでいいんですか?UIEPlayerを逆コンパイルしてもいいですか?

 UIEPlayerのJavaApplet版はJava1.4以上のJREが必要だが、それが入っているPCは少ないのでは?と感じる。友人のPCにも入っていなかった。いっそ、Flash等の大半のブラウザに入っているテクノロジーを使って欲しい。あるいは、JavaScriptで実装してはどうか?

 アプリを作っても、PCでも動かない、携帯でもDOCOMOだけ、、、うーむ、せっかくの軽量UIEngineがJAVAのインストーラーで魅力半減、ナンバーポータビリティが始まったらDOCOMOユーザーが減ってなんてことにならなければ良いが。

 では作ってみようか?UIEPlayerのJavaApplet版、逆コンパイルしてもいいですか?と聞いてみる。JavaScriptに移植したいんですが。

ブログの力とUIEngineが就職活動をも変えるのか?

 「UIengineの世界」という記事を書いたブロガーいる。履歴を見ると就職活動をし、最近ブログを始めた学生のようだ。数えてみると、十数番目の記事でUIEngineを取り上げている。その他は就職活動の日記がメインだ。技術系の記事は2つありそのうちの1つだ。もう一方はMacというメジャーなものである。2つのうちひとつがマイナーなUIEngineだ。

 このブログの作者はUIEngineを知り人生が変わるのかもしれない。UIEJapanに就職した他のブロガーがそうであったように。このブログ作者もUIEngineに就職するかもしれない。

 UIEJapanさんには、トラックバックステーションの公開を望む。もちろんUIEngineでも実装を願っていることを忘れないでおこう。必要があればAPI公開してもらえれば私が作りますということも付言する。テレサテンが歌う「夢芝居」を聞きながら書いた、今日最後の投稿である。

「UIEJapanよ聞いてくれ」にシールが増えたんだって?

Saiyou_1 トラックバックステーションの話に対して新しいシールが付いた。「UIEJ的、採用っぽい何か」というシールだ。

 できればシールは、「採用」をまるで囲んだ判子のようなものがインパクトがあってうれしい。よく、ドラマの面接で「不採用」、ぼんっと履歴書に押されるような、あれ。もちろん決定ではないので「?」が付くが、 こんなのか?

そういえばUJML2.0でドキュメントをWikiで提供する話はどうなったのだろうか?

 確か、UJML2.0はドキュメントをWikiで提供するという話があったと思うのだが、どんな感じなのだろうか?太郎日記79Jさんがドキュメントが古いと指摘していたがWikiにすれば一発解決だ。太郎日記79Jさんのような問題意識の高い方が積極的に更新するに違い無いのだ。それが、Web2.0だ(ほんとか?)。

 もしWikiで公開されたら、今まで公開したUJMLサンプルのソースコードは「the Creative Commons 帰属 2.1 Japan License」で提供しようと考えている。

タイミング良く、UIEJapanの代表の今野さんの書き込みがあったので、、

Osozaki  UIEJapan社長の今野さんのブログ「遅咲きブログ少年@はてな」に次のような投稿があった。

---歓迎会にておもふ

最近毎日書き始めるものの途中で様々な思いがうごめいて、大人の判断なのか単なる臆病者なのか、途中でボツにしてします。

大体にして今回のような歓迎会はネタの絶好の機会にもかかわらず、写真をとらない自分自身が情けない。。。ブログを持つものとして意識低すぎですね。うむー
---

「もっとブログを更新せい」と社員にとがめられたようだ。

 実は面白いもので、UIEJに合流した強者達は皆ブロガーであり、ブログを通じてメンバー募集→採用という流れを取ったのだが、UIEJが本格稼動したら、どうも、更新頻度が落ちているなぁと感じていたところだ。唯一、UIEのCEOの「Life is beautiful」の中島さんだけは毎日更新している。

 そんな中、私は「がんばれ」の意味もこめて、今日一日10個投稿し、「こんなくだらんことでもOKですよ、もっと発信してくださーい」と、例の「UIEJapanよ聞いてくれ」を使って投稿しようとしていたのが今日で、そんなことをやっている中であったのが今野さんのこの投稿「歓迎会にておもふ」だった。

 周りの人が思っていることは、やはり本人が一番よくわかっているが、気づかせてくれるのはやはり周囲の人間だということなのかなぁ、としみじみ感じた本日の10番目の投稿であった。

 それはそうと、いっそのこと「日報<<<<ブログ」という価値観の職場にしてはどうか?日報を書く前に必ずブログを一投稿する、そういうルールを最初に日本に作った会社にしてはどうか?そして、人事評価項目に「ブログ」を入れ、トラックバック数や他ブログでの言及数、コメント数等で評価し来年の給与に反映させるのだ。

 私が今度つくる会社はそうしよう。

Bellx

UIEvolution! Listen to me?

 ドキュメントが古いことを「俺的”美しい生活”のためにUIEngineを試そう。(8):ドキュメントが古い」でも怒られてしまったUIEngine。確かにドキュメントは古い、そして充実していない、だから本ブログのような平民ブロガーのホームページにアクセスが集まるのであり、そういう欲求の集合がインターネットに価値の高いネットワークを作っているのだろう。

 確かにドキュメントは古い。そう、確かに古い。そして、間違いもある。

 しかし「それが仕様です。」とならない限り明日はあるのだ。

 ところで、ドキュメントが古いこともそうだが、SDKに入っているdemoプログラムがそのまま動作しないこと等も大きな問題だと考えている。プログラマはソースコードで全てを語れるはずだ。「今日から来月まで残業時間++かもしれん。」などと、ソースコードで全てを語るのだ。そのソースコードに手を抜いたらいかんよ。魂の無いソースコードを書いたらいかんよ。魂が無くなると「それが仕様です。」と言いたくなるのだろう。

ついにスクリプト版(PHP,Perl等)のUJMLコンパイラー登場:フルコンパイラーは出るか?

Zipcodesamples 知らぬ間に、スクリプト版のコンパイラーがリリースされていた。「Zipcode converter app」でサンプルの閲覧とソースのダウンロードが可能だ。こういう便利なものを地味にリリースするので、「開発者フォーラム」はよく注意してみていなければならない。

 このサンプルはサーバーサイドで郵便番号(zipcode)から町の名前を検索して、クライアントサイドに渡している。果たして簡単にこれを使ったアプリをすぐ用意できるのかどうか、早速レビューしてみよう。

_discard()の使いすぎは良くないか?更新チェックは考えなければならない課題だ

 現在「あとで読みタイ」は_discard()を使い、キャッシュしていない。キャッシュを頼らないとどんなものかと実験しているのだが、やはり使えないな。

携帯電話の実機にならないと検証できない、そういうこともあるのかもしれない。

0_hatena_3  UIEngineはプラットフォーム間の差を吸収してくれるので、開発効率を決定的に向上させることができる。はずなのだが、テストは実機で行わなければならないという話。

 UIESDKのデバッガー上で動作する、Docomo提供のEmulator上でも動作する、だが、実機では期待通りに動作しない。そういうことが実際に起きた。

 それは_link()等で外部資源にアクセスするときに起きた。携帯電話は高いセキュリティを意識して作られている。そのため、Docomoのiアプリはiアプリが配置されていたサーバーとしか通信できないようになっている。このセキュリティがいたずらすることがあるようだ。

期待通り動作しない例:
_link("hoge","http://hoge.com/hoge.php?u=http://foo.com")

 私の手元のD902iではこの_link()が期待通り動作しなかった。他の機種では期待通り動作するのかもしれない。おそらく、http://foo.com を解釈して通信を拒否しているのだろう。結局、URLを_urlEncode()して期待通り動作するようにした。

携帯電話の通信の遅さを体感できないから、とんでもないものができることもある。

 携帯電話からサーバーと通信して、データを取り出して表示する、云々のアプリを開発しているが、PC上で携帯電話の通信速度を体感できないので、気が付くと使い勝手の悪いものが出来上がる。

 実際にできてしまった。

 作ったものを携帯電話で走らせると「なんじゃこりゃぁ」である。昔のファミコンゲームで敵が出すぎて、動きがのろくなった、そんなシューティングゲームを思い出す。

 さて、リファクタリングだ。先読み機能を持たせ対処するが、パケット代が気になるユーザーもいるだろう。早くパケット代定額&格安になることを願うのみ。そのあたりの政治的なことに全然キャッチアップできていないので勉強開始だ。

multi-labelの自動改行ロジックが何だかおかしくないですか?と言ってみても仕方が無いので、

Damanakaigyou  先日の投稿で「multi-labelの自動改行ロジックが何だかおかしくないですか?」と書いたものの、UIEPlayerの問題であろうから、そんなに早く修正されるはずもなく、いくつか対処方法を考えた。

対処方法1.<label>を組み合わせて自前で実装する。

対処方法2.半角スペースを全角スペースに置換する。

前者は実装に時間がかかるのでやめ、後者をやってみたら、まぁ、おかしくない程度だろうから、こちらを採用。置換処理はサーバー側で実装、UIEngine側は例によって表示するのみ。

 後者で期待以上の成果が出たので、前者はUIE社が修正するのを待つことに。

「私はあなたに受け入れてもらえますか?」という ujbc の相性の話:importとexport

 まだ、本ブログでは本格的に取り上げていないが _link() 関数を使うことで外部の ujbc を動的にロードしてアプリケーションの一機能として使うことができる。その際、呼び出し側が関数や変数を export し、リンクされる側がそれらを import することが多い。

 さて、リンクされる側はもちろん既に export された関数や変数でなければ import できずランタイムエラーが発生し動作しない。十分な動作検証が行われた閉じたアプリケーションならそんなエラーが発生することは無いのだろうが、もっとオープンなアプリケーションを考えると若干これは都合が悪い。

 リンクされる側が「あなたはわたしを受け入れてくれますか?」と聞くか何かする機構が必要になる。

 その役割を誰が果たすのかについては熟考が必要だが、まずはサーバー側で実現するかと考えた今日この頃である。

※実は現行の仕組みではサーバーに配置されるは ujbc が前提ゆえ、若干パースが面倒だ。幸いにして変数名はそのままバイトコード内に残っており、変数宣言箇所も特定しやすいので良いが、UJMLがサーバーに配置される前提ならもっと楽になるなぁ。

multi-labelの自動改行ロジックが何だかおかしくないですか?

Atodeyomitai001 ←写真は現在開発中の「RSSリーダー」と「あとで読む」をくっつけて携帯上で動作するツールだ。どうやら、UIEngineの複数行を表示できる<multi-label>なるエレメントの自動改行ロジックが日本語表示に適していないようだ。

 こんな感じのシンプルロジックにしているらしい。

・連続した文字はどんな文字でも1単語と認識される。
・上の1単語が同じ行内に入らなかったら直前で改行する。
・1単語が長すぎたら仕方が無いので、めいっぱい1行に入れて、右端で改行する。

あぁ、これだとスペースのある日本語が読みにくくなって仕方が無い。改善を望む。

UIEジャパンさん「UIEJapanよ聞いてくれ」って結構運用が大変じゃありませんか?

Bellx UIEジャパンさんはアイデアベースで面白いサービスをリリースしている。試みとユーザーフィードバックから得られるサービスの最適化へチャレンジしているのかもしれない。

 ところで、現在リリース中の「UIEJapanよ聞いてくれ」は使う側(ブロガー)も使われる側(UIEジャパンさんの人 萌えさん?)も結構しんどい気がする。

使う側のしんどさ:張った以上は読まれたかどうか気になる。しばらく読んでもらえないとブログアーカイブに埋もれるため確認するのが面倒だ。そして、さらにしばらくすると忘れてしまう。

使われる側のしんどさ:急速に普及してしまうと、自分の仕事時間が圧迫されてしまう。何だかかわいそう。

 前者の使う側のしんどさについては、もう少し「疎」な告知方法が向いているなと感じるがどうだろうか?例えば、ブログの該当記事にトラックバックすることで読んだことを通知するのはどうか?人によってはトラックバックを自分のメールに通知するようにしているかもしれない。あるいは、最新のトラックバックをサイドバーに張っているかもしれない。

 メールのような「疎」なメッセージツールを活用するのが良いだろう。直でメール通知は、メールアドレス登録が必要になり面倒なので、やはりトラックバックが妥当か?

 いずれにせよ、使われる側のしんどさの克服は難しい、とにかく「読まなければならない」ことをサービスとして課しているのでここはがんばってもらうしかない。シールが張られたブログをRSS化して、自分のRSSリーダーで閲覧を効率化する等の手はあるのだろうが。

 あるいは、サービスの趣旨を若干変更したらどうだろうか?「UIEJapanよ聞いてくれ」ステーションを作り、そこにみなの意見を集約して表示する。後は誰が読んだかわからないが、読んだ回数をカウントアップしてシール表示するようにするのだ。もし、本当に言いたいことがあれば直接言うだろうし、シールで遠まわしにするということは、他の誰かにも見て欲しいという気持ちもあるに違い無い。そういう意味では、UIEJapanが聞いたかどうかもそうだが、何人ぐらいが見たかもいいかもしれない。また、他の人が何を言いたいのかもステーション上で簡単に見ることができるようになる。

 UIEJの人が見たらシールがキラキラに変化、他の誰かが見たら閲覧数をカウンター表示、という具合が良いのでは?と思ったがどうだろうか?

Docomo携帯でujbcをキャッシュさせないためにはどうしたらよいか?

 UIEngineは、例えばDocomo携帯の場合、Doja仕様にのっとったUIEPlayerというものが実行される。

 このUIEPlayerはつまりiアプリだ。

 UIEPlayerは指定された、ujbc を読み込み実行する。ujbc はUJMLで書かれたプログラムがコンパイルされたものだ。

 さて、実際にDocomo携帯に作成したアプリをインストールしたとき、配信側としてつまづきやすいのが、古いアプリの更新を逐次行えないことだ。ちょっとしたバグの修正があったら、サーバー側のujbc ファイルを修正して良しとしたいが、デフォルトではそのようなことができない。携帯端末にキャッシュされた ujbc が使われる。

 もちろん、キャッシュせず毎回新しい ujbc を取りに行くように設定することも可能だ。それが、今回紹介する内容だが、やや前置きが長すぎた。

 設定方法は極めて単純で、Dojaの場合、サーバー側にjamファイルを設置するが、その中のAppParamの値を次のようにすると良い。これは、foo.ujbcがメインアプリファイルの場合。

AppParam = app/foo.ujbc?_nocache=1
AppParam = app/_nocache/foo.ujbc
AppParam = app_nocache/foo.ujbc
AppParam = app/foo_nocache.ujbc

つまり、"_nochache"なる文字列がURL内に含まれるようにすれば良いのだ。これで、UIEPlayerは起動時に毎回サーバーのujbcをとりに行くだろう。

UIEジャパンさん?やっぱりUIEngineのライセンスは日本語で告知した方がいいみたいですよ!

Bellx

 本ブログを訪問いただき、ありがとうございます。

 最近はUIEngineが多くのメディアで取り上げられ、また、UIEngineを採用したサービスもサービスインしつつあるので、UIEngineの注目度が増加中。

 そんな中、このブログに「UIEngine ライセンス」というキーワードで検索エンジンから訪れる方も増えてきた。そこで、UIEジャパンさんにお願い。

そろそろUIEngineのライセンス体系を日本語で公にした方がいいと思いますよ。

UIEngineの特性を活かしたアプリケーション作りを目指したいが、どうしたらいいの?

Bigsize_application これまで、多くのUJMLを紹介してきたが、いずれも部品レベルで、一つのアプリケーションを構成するほどのサイズには至っていない。では、「UIEngineの特性を活かしたアプリケーション作りをしたい。」と思ってしまったら、どうしたらよいのか?役立つサンプルは無いのか?

 もちろんある。

 

 SDKインストールしたフォルダをたどると、どこかに「demo」というフォルダが存在する。その中の demo.ujml をSDK上で実行して見ると良い。画像は実行したときにロードされるコンポーネントだが、include と _link() を駆使して、良くできている。

 UIEngineの特性を活かしたアプリケーションを作るには、この demo.ujml が動作する仕組を理解するのが手っ取り早いだろう。import,export,_link(),include、、等で頭がややこしくなるが、ノートか何かに図で整理しながら、何が何を_link()して、何が何をincludeしているのか明確にするとわかることがある。

 初心者の方がいきなり demo.ujml を見ると、全く意味不明なので、初心者の方は「初心者向けまとめページ」から無難に簡単なサンプルを見て行って欲しい。

※この demo.ujml を実行するには、同じフォルダ内にある config.ujml 内に指定されているフォルダパスを正しく指定しなおす必要がある。

UIEジャパンさん?どんなわがままも聞いてもらえますか?

Bellx

UIEジャパンさんが面白いサービスをやっているので、はまりつつある。この投稿を読んでくれたか分かるのだ。UIEジャパンさんに意見があるときは今後はこれを使う。

 さて、UIEジャパンさんは言いたいことを聞いてくれると言うのだが、最近、UIEngineに対する興味が増加中(検索トラフィックより)で、UIEngineに言及するブログも増え、UIESDKをDLしてUIEngineを体験する方も増えてきているようだ。

 おそらく、これから順調に増えていけば、UJML、UIEngineに関する疑問や要望を持つ人も増えるだろう。これらの疑問・要望に対してUIEジャパンさんとしてどこまで対応できるのか(現時点で)、そろそろ表明しておいた方が良いのではないかと感じる。言語仕様に関する疑問にこたえられるのか、SDKの改善案についてはどうか、などなど、「開発者フォーラムへ」ということであれば、そのように明確にしてもらえると、将来のUJML開発者にとっても皆ありがたいだろう。一元化されるのが望ましい。

集合知が重要になるプラットフォームには素敵なインタフェースを入れるべき

Realcom_1 巷ではWEB2.0が云々と盛り上がっているが、その中で「集合知」の価値が大きく取り上げられている。企業の中で「集合知」と言えば、ナレッジマネジメントシステムを思い浮かべる方も多いと思うが、今回はそのナレッジマネジメントシステムについて少し書いてみる。

 左の写真はナレッジマネジメント専業ベンダーとして急成長中の「リアルコム株式会社」のホームページだ。何故、ここまで伸びてきたのか、導入事例を見るとベンチャーにしては立派な企業で採用されている、これは正直驚きだ。ナレッジマネジメントソフトはマイクロソフトやオラクル等のベンダーのみならず、IT系のコンサルティングファームも強力なプラットフォームを持ち展開している。

 その中でこれだけの採用実績を誇るのは、営業力もさることながら、システムの整合性が取れていることだろう。

 ナレッジマネジメントソフトは主に、「みんなが投稿した情報をみんなで閲覧する」という単純な流れでできているが、「投稿する」行動自体が曲者だ。投稿するのは閲覧するよりもはるかに労力もかかり、直接的に得られるメリットも少ない。その中でいかに投稿を促す仕組を取り入れるか?が重要になる。

 リアルコム社のナレッジマーケット(R)は開発当初からその課題に取り組み、直感的なユーザーインタフェースを徹底的に追求していた。つまり、投稿者の負担を極限まで減らし、かつ、投稿による直接的メリットをうみだす仕組をシステムに組み込んできたのだ。

 これが、リアルコム社の成功の要因の最も重要な1つであると考えている。

 今後、WEB2.0ブームにより集合知を扱うサイトが次々と起ちあがるだろうが、その中でリアルコム社が取ったような、ユーザーインタフェースの追求こそが生き残りに重要になるに違い無い。

萌えたUIEJapanはどこにいくのか?

0083  UIEJapanが一風変わったエイプリルフール企画をしていた。会社が萌えていた。社長も萌えていた。これからは「萌え2.0」が会社成長のキーワードになるらしい。ドラッカーもさすがに気づかなかった経営の真理かもしれない。

 UIEJapanのホームページはこちら

UIEngineの方向性を誰が正しいと言えるのか?それは正しいと信じる人間にしか証明できないだろう。

 CNET Japanのブログにある『「ソフトウェアの肥大化」と「ムーアの法則」』には非常に興味深いことが書いてある。これだけ読めばUIEngineが何を目指すのかわかるぐらいだ。

---引用
 Microsoft、Sun Microsystems、Macromediaといったソフトウェア・プラットフォームを提供する企業が、互換性を犠牲にしながらも、Windows CE、J2ME、Flash liteという「組み込みデバイス向けの別個のプラットフォーム」を出さざるをえないのが、その方向性に根本的な問題があることの証拠である。
---引用ここまで

 彼らはレッドオーシャンで戦っている。ここにあげられなかった、オペラプラットフォームやオープンウェーブ社のMIDAS、携帯電話向けブラウザを開発する会社も同類だ。

 携帯電話も「ムーアの法則」の恩恵を受け、ここ数年で見事なまでにそのパワーを増した。今では4GBのハードディスクを搭載するものまで現れたり、MSオフィスやPDFのドキュメントを閲覧できるものまで登場している。

 そのリッチになったリソースを、「いざ使い切らん」とばかりに闘っているのがここで名前をあげられた会社なり技術である。「俺の技術の方がすごいんだ」と言っているが、どうもどんぐりの背比べとしか思えない。組み込みデバイス向けのプラットフォームとしては、同じ戦略マップ(ブルーオーシャン戦略より)で闘っているのだろう。

 何故その呪縛から逃れられないのか?

 その理由はわからないが、UIEngineが全く異なる戦略マップで闘っていることは間違い無い。

---

UIEngine、UJMLに興味があって初めていらっしゃった方へ

ご訪問ありがとうございます。まず、本ブログ右上の「UJML初心者向け」という枠の中から「初心者向けまとめページ」をお読みいただくのが良いと思います。

携帯電話にMS-Office用ヴューワーを載せたあの端末は何を目指したのか?

Sh902i_red 写真は携帯電話でMSオフィスのファイル500KB程度を読むことができる携帯だ。SH902iである。

 この端末は、オフィスドキュメントがパソコンでしか閲覧できないことに不便を感じていたユーザーのニーズを捉えた良い商品だと思える。

 しかし、消費者はオフィスドキュメントを携帯で見たかったらこの端末を買わなければならない。他にも対応端末はあるのかもしれないが、少なくとも私が持っている902iではオフィスのドキュメントは閲覧できない。

 また、ファイルサイズ500KBの制約がある。これはいかがなものか?ドキュメント作成者はそもそも500KBにファイルサイズを抑えようとは思わない。つまり、この端末を持っていたとしても、たまたま500KB以下で作成されたファイルしか閲覧できないのだ。

 この様な例はCNETのブログに書かれている『「ソフトウェアの肥大化」と「ムーアの法則」』の、ムーアの法則にのっとってデバイスリソースを限界まで利用するために作られたソフトウェアの典型だろう。

何故機種が制限されなければならないのか?

何故閲覧可能なファイルサイズが制限されなければならないのか?

答えは一つだろう。

「作り手がそう作りたいと思っている」

から。

ユーザーはそれを望んでいないのに。これが、現在のソフトウェア開発のアプローチだ。

---

UIEngine、UJMLに興味があって初めていらっしゃった方へ

ご訪問ありがとうございます。まず、本ブログ右上の「UJML初心者向け」という枠の中から「初心者向けまとめページ」をお読みいただくのが良いと思います。

UJMLをコンパイルしたバイトコード ujbc に何故変数名が含まれているのか?

Binary_a_1 以前、無理矢理、文字列をアプリケーションに動的に受け渡せるように、UJMLをコンパイルしたバイトコード ujbc をバイナリエディタで開いたことがある。それが左の画像。

 そのとき、変数名がバイトコード中に残されていることに気づき、漠然と「何故だろう?」と思っていたが、_link() のためだと最近気づいた。

 _link()でリンクされる ujbc とは、例えばステート変数やただの変数を共有することができる。export、import といった指定を変数宣言時に行う。

 異なる ujbc 間で、変数を共有するためには互いが理解できる識別子を使っていなければならず、疎結合を実現する _link() では、その識別子も UJML 中の変数名をそのまま使うのが正しい。そういうわけで、変数名はできるだけ短い方が ujbc のサイズが小さくなるということがわかる。

 とはいっても、開発後のメンテナンス性を著しく損なう変数名のつけ方はいただけないので、開発者の変数名の名付けセンスが問われている、のかもしれない。

ヴィジョンが技術により具現化され、具現化された技術によりヴィジョンに誘導される私

Pervasive  当ブログも気が付けば200ポストを超え、開始から2ヶ月経とうとしている。

 偶然UIEngineという技術と出会い、探求してきたが、最近UIEngineを使い実現したいことをまとめていたら、あることに気が付いた。

 前回の投稿にも書いたがUIEvolution社CEOの中島氏のブログに「パーベイシブ・アプリケーションの世界」という投稿がある。この投稿には、中島氏のヴィジョンが書かれている。

 今まで、じっくりこの投稿を読んだことは無かったが、気が付けば、私がまとめた実現したいことが、この中島氏のヴィジョンそっくりになってしまったのだ。中島氏の掲げたヴィジョンを詳しく知らない状態で、中島氏が自分のヴィジョンを元に具現化したUIEngineという技術に触れながら、私が勝手に積み上げたやりたいことが、中島氏のヴィジョンそっくりになった。

 そうなるのはあたりまえのことだと感じるかもしれない

 しかし、私はそうなった本質的な理由は1つだと思う。

 それは、「UIEngineが極めてコンパクトにまとまった技術だ」ということにつきる。

 UIEngineはあれもできるこれもできるというものでは無い。

 つまり、自己のヴィジョンの本質を捉え、不要なものを削ぎ落とし、具現化したUIEngineだからこそそうなるのではないか。

 私がまとめた実現したいことの絵と中島氏の投稿を見比べ、「誘導されたのか?」と、どこか気持ちの悪い妙な気分になったのだが、面白い発見もあったので良しとしよう。

アプリを簡単にサーバー上に公開できるのは便利だが、それで満足して良いのか?

Build_multiple 無償で公開されているUIEngineのSDKには、作成したアプリケーションをサーバーにアップロードし公開できるツールが、これもまた無償でついている。UIEvolution社はアップロード用サーバーも無償で貸している。よくよく考えてみると、このようなSDKは世界初ではないかと思う。すばらしい。

 このツールの便利さには以前も何度か触れているが、最近、「?」と感じたことがある。

 例えば、一度に同じアプリケーションを異なる二種類以上のデバイスに対し公開したい場合がある。「JavaApplet」と「Docomo携帯」といった具合だ。

 SDK上ではこの二種類のデバイスを同時に選択し、ビルド&アップロードを行うことができるが、サーバーにアクセスするためのURLは2つ自動生成される。もし、三種類のデバイスを選択すれば、3つ自動生成されるだろう。100種類のデバイスを選択すれば、100個のURLが生成されるはずだ(実際はそんなに選択できないが)。

 勘のよい方はお気づきだと思うが、この仕組は極めて不便だ。アプリケーションを公開する側が、各端末ユーザー別に、「このURLにアクセスしてください」と送らなければならない。あるいは、振り分け用のサーバースクリプトを1つ自前で用意し、デバイスを適宜判断し、適当なURLにリダイレクトする仕組を用意するのだろう。

 この仕組は間違っている。

 簡単に言えば「1つのURLで複数個のデバイスに対応できるように、サーバー側を賢くすべし。」ということだ。

 UIEvolution社のCEOである中島氏は「パーベイシブなアプリケーション」の実現をビジョンとして掲げていらっしゃるが、「パーベイシブ」にするためにはアプリケーションの配布元を一点に集約すべきであり、サーバー側を賢くすべきだろう。

 ということで、改善要望を出してみた。

携帯用にデプロイしたものをパソコン上でエミュレートするには?

Dojaemu UIESDK1.5等を使うことでDocomo携帯電話用のアプリを簡単にデプロイすることができるが、デプロイしたものを携帯電話でわざわざ確認するのも面倒なので、PCで確認できるようにしたい。そう思っていた。

 そこで使うのが、PC用のDojaエミュレーター(Docomo提供)。こちらのサイトからDoja2.0プロファイルのものをダウンロードし、インストールする。ちなみにDoja4.1では期待通りにできなかったので敢えて偶然成功したDoja2.0を推奨する。

 インストール後、doja.exeというファイルがインストールフォルダのbinフォルダの中にあるが、このエミュレーターを使用して例えば、20x20daの場合はこんな感じでコマンドプロンプトから実行する。

%> \doja2\bin\doja.exe -i 20x20da.jam -u http://pts.app.uievolution.com/pubserv/vfs/2350/20x20da.jam

ちなみに、jamファイルはSDK上でビルドしたときにUJMLソースファイルの所在地に作成されるフォルダの奥底にある。jamファイルの

AppParam

の値だけは、例えば

http://pts.app.uievolution.com/pubserv/vfs/2350/20x20da.ujbc

のような形に変更しなければならないと思う。

UJML2.0の特長は?Lorenzoさんが紹介していたので、それを紹介する。

 UJML2.0をまだ使いこなせていないのだが、UJML2.0で私が最も衝撃的だったのは開発環境がEclipseベースになりインストーラーが100MB近くなったということだ(笑)。他の仕様上の追加等はあらかじめ分かっていた部分もあり、あまり驚いていない。

 そんな中、UJML2.0の特長を紹介しているブログがあった。Lorenzoさんの英語を日本語にして私の見解をマッシュアップして紹介する。

特長1.
2.0はEclipseベースになったから、開発も超簡単っ!エディタもデバッガーも統合されたよ!今まではデバッガーだけだったからね、これはすごいことなんだ!SDKの自動更新機能があるから、機能追加等も楽にできるよ!

特長2.
オブジェクト指向っぽくなったよ!これで、JAVAとかのOOに慣れた開発者も文句言わせないよ!

特長3.
可変長配列も使えるようになったよ!これは便利だよね!だって、今までは固定長だったから「とりあえず1024取っとけばいいかぁ!」なんてこと考えてた。そんなことも無くなるよ。

SDK2.0で明らかになる、UIEngine及びUIEPlayerのライセンスについて

License  UIESDK2.0をインストールするとライセンスに関するドキュメントもインストールされる。SDK1.5のライセンスから変更された個所がかなりあるが、第三者的開発者には極めてうれしい内容だ。

 非商用利用ならUIEPlayerを無償で利用できるのだ。普通に開発言語UJMLを使って普通にアプリケーションを作り、無償で公開するだけのひとにとってはうれしい内容だろう。ただし、UIEPlayer をハックするひとは、しっかり読んでおいた方が良い内容でもある。

 いずれにせよ、このサイトにおいても以下のようにライセンスについてはまとめて表示する。
---
Your use of the UIE Player software is subject to the relevant restrictions and limitations set forth in the Software License Agreement for Non Commercial Use of UIEvolution Platform Software, a copy of which can be viewed at
http://developer.uievolution.com/licensing.html
or
http://developer.uievolution.com/licensing.wml).

「AJAXの本質」+「UIEngine用アプリ」=データバインディングの最初の一回はサーバーで

Ajaxの本質という非常に興味深い記事がある。UIEngine用アプリケーションを開発する過程で、今日、たまたまこの記事をじっくり読んでみた。この記事にはAjaxの本質を5点に、極めてわかりやすい形でまとめている。

---引用ここから
(1)アプリケーションの明示的なインストールが必要ない。
(2)サーバーとの通信を非同期に実行することにより、通信遅延によりUIをブロックしない。
(3)サーバーとのやり取りは、RPCではなく、メッセージで行う。
(4)データ・バインディングはサーバー側ではなく、クライアント側で行う。
(5)UIにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。

---引用ここまで

UIEngine用のアプリケーションを開発する上で、この5点はまさに抑えるべき事柄だ。

ただ、携帯電話等の小型かつ通信速度も遅いデバイスの場合には

(4)データ・バインディングはサーバー側ではなく、クライアント側で行う。

については、「少なくとも最初の一回はサーバー側でデータ・バインディング行った方が良いかもしれない」と直感的に思ったものの、これもまた作りながらケース毎に検証していこう。

UIESDK2.0がようやくリリースされた Eclipseベースの開発環境、その使い心地はどうか?

Uiesdk2 まだベータ版だが、開発環境としてはまだまだ改修の余地ありだ。

ダウンロードはこちら

 もともとSDK1.5ではデバッグ環境のみあった。2.0でもその思想を受け継ぎ、デバッグ環境としては機能が充実している。コンパイルエラーの場所にすぐにジャンプできるところはありがたい。

 2.0で新たに追加されたエディター機能はお世辞にも良くできているとは言いがたい。ただのエディターだ。

 また、PushToPublishの機能(ワンクリックでサーバーにアプリケーションをデプロイできる機能)も若干使いにくくなった感がある。

 インストーラー自体が100MB以上あることや、メモリー使用量が多いこと等、UIEngineの思想の真逆を行くこのSDKが何とも憎めないが、開発環境としてはもう少し洗練する余地があるだろう。

 デバッガー自体にも若干バグがあるようだが、SDK1.5での開発環境のように

・デバッガー+PushToPublish機能→SDKで
・エディター→お気に入りのエディタで

という組み合わせが開発環境としてはベターだろう。

 ところで、Eclipse標準の設定にはエディターとして外部エディターを指定できたはずだが、どこでやるのだろうか?その設定があるだけでだいぶ変わるのだが。

 それから、PushToPublish先のサーバーに自分のサーバーを指定できるようにして欲しい。

 これらの提案は開発者フォーラムに投げておこう。

UIEvolutionの動きが活性化している、それは胎動なのかもしれない

Uievolution  UIEvolution(R)社は、先週UJML2.0のベータ版をリリースした。さらに、サーバー上でPHP等のスクリプトで動作するコンパイラーを出すようだ。動きが激しい。詳しくは http://satoshi.blogs.com

 UJML2.0の評価結果は追々投稿するが、サーバー上のコンパイラーをリリースすることにUIEvolution(R)社が何かを動かそうとする強い意志を感じる。

 UIEvolution(R)社の日本法人UIEJapanがこの3月より営業開始した。まだ半月だが打って出てきた。UIEJapanにいったいどんな優秀な人材が集まったのか、極めて興味深い。ブログを中心に採用をかけたため、集まった人材もブロガーが中心のようだが、ブログをたどるとどんな人が参画したのか見えてくる。なかなか濃い人材のようだ。

 今後は何かとんでもないサービスを打ち出してくるに違い無い。UIEngineの特徴を活かし、サービスの対象ユーザーは携帯電話利用者であることは間違いがない。2006年3月に産まれたばかりの会社が、「優秀な人材」という何物にも変えがたい強みを得、とんでもない化け物になっていく、どこかで聞いたことあるような話だが、この話が日本で今まさに起きようとしているのだから、こんな面白いことは無い。

 そして、当ブログ http://uiengineda.blogs.com も2006年中に何らかのサービスをUIEngineベースでリリースすることになりつつある(現在、資金調達を含め回転中)。競合し市場をつぶすようなことをするつもりは全くないが、内と外、面白い競争関係が産まれることを信じている。こちらは、サービス予定の内容をブログで公開し、ソースコードはスパゲッティでも公開する方針のため少し分が悪い。(本当は、はてな社が会議音声を公開しているように、音声で企画を公開しようと思ったが、それはただの独り言で色気が無い。)

 いずれにせよ、この書き込みは、一技術者として、UIEJapanの中の人達への宣戦布告なのかもしれない(と語尾を濁してみる)。

#日本で初めて?ブログで宣戦布告しました。

UJMLがコンパイルされ ujbc というバイナリである有意味性、それってなくなるんじゃないのかい?

 電車に揺られながら考えた。頭の中では、UIEngine上で動作するライブラリ(コンポーネント?何て呼んだらいいのか?)がWEB上に散在し、それが有機的に絡み合って一つのアプリケーションを形成している。

 はて、UIEngineの仕組みでは、UIEPlayer上で ujbc という中間コードが動作する、ということだが、WEB上に散在しているライブラリは ujbc というバイナリになっている必要はあるのだろうか?

 UJMLはXML形式で書かれたテキストで、誰でも読み、理解することが可能だ。中間コードである ujbc は、UIEPlayerでしか読めない。もし、UJMLから ujbc にコンパイルすることがユーザーに意識されない程の速度でできるのなら、UJML形式でWEB上に散在していた方が都合が良いのではないか。

 最初の話に戻り、有機的に絡み合い一つのアプリケーションになるには、そのUJMLが何なのか?というメタ情報があった方が都合が良い。見つけやすいから。

 とにかく、有機的に絡み合うにはUJMLのままのほうが都合が良いのではないか?と直感的に思うが、うまく説明できない。だから、コンパイル用のサーバーをどかんと立てて、それが本当に便利かどうかやってみたらいいのだ。有機的に絡み合い一つのアプリケーションになるために何が必要か、見えてくるはずだ。

OperaPlatformって何? - AJAX、携帯へ進出:Opera Platform により携帯電話で AJAX アプリケーションが利用可能に

Opera_platformオペラプラットフォームに関する記事を見つけた。

とりあえずSDKを入れて体感してみようと思ったら、SDKダウンロードできず。

例によって「画像に表示された文字を入力してください」ということだが画像表示されず。

試みは失敗に終わった。

UIEngine アプリボックス構想を勝手に考える その2

2以前、「UIEngine アプリボックス構想を勝手に考える」という投稿で、UIEngine上で動作するライブラリを共有する仕組みがあると良い、といったことを書いた。

その中で、アプリやライブラリを皆でアップロードして1箇所のサーバーに集約させる案を書いた。

色々考える中で、ライブラリ側は動的に生成されることが多いのではないかと気づいた。そうすると、一箇所のサーバーに集約させるのはどうしても都合が悪い。作り手がそのサーバーのスペックによる制約を受けるためだ。phpは使えるけど、perlは使えない、例えば簡単な例ではそういったことだ。

いまどき、一箇所のサーバーに物を集約するということ自体が古い考えでもある。中央のアプリボックス(仮称)サーバーにWEBインタフェースを持たせ、外部に存在するライブラリが配置されたサーバーと通信できれば良い。

終端端末のデバイス(携帯電話 等)は、ライブラリがどのサーバーにあるのか気にする必要がある。が、それは表面上の話で、実体が全く別のサーバーにあっても問題は無い。終端端末に対し通信中のサーバーに存在するかのごとく振舞えば良いのだから。(プロキシと同じ話)

図の右上にある、「勝手ライブラリ」と中央のアプリボックスサーバーの通信方法させ規定すれば、後は勝手ライブラリが動的にどんな言語で生成されようが(C言語、C++、Java、PHP、Perl等)関係無いのだ。作り手はやりたいように作ることができる。

これこそが、現代のダイナミックリンクライブラリなのではないか?と思った。携帯上で動作するアプリのライブラリをWEB上のどこからでも取り出すことができるのだ。各々ライブラリの作り手はタグか何かのメタ情報をライブラリに持たせることで、使う側のアプリがそのライブラリを発見しやすくすることも可能だ。

そんなことを考えたらUIEngine及びUJMLはRSSに変わる新しい情報配信フォーマットとなりうるのではないか?と、妄想する。RSSでは「文字」しか配信できないが、新たに「見せ方」も配信できるのだ。配信側にとってこれほどのメリットは無い。後1年以内に携帯向けの広告配信技術がUIEngineになるかもしれない。

世界が変わる気がする。

大手ポータルへの展開がUJMLの普及を加速させるのか?

Calendarservice例えば今日、たまたまこのような記事を読んだ。

前回、エンタープライズWEBアプリケーション市場の話も書いたが、大手ポータルにも採用してもらえる可能性が十分ある。

現在ではカレンダー機能携帯アプリバージョンを作ろうとすると、Docomo,AU,Vodafoneそれぞれ用にアプリを作成しなければならない。UIEngineの技術を使えばそれもなくなる。Docomoバージョンはあるけど、AUとVodafoneはちょっと待て、ということも無くなるだろう。

これは開発者・提供者側にとっても大きなメリットに違いない。さらに、ユーザーは使いやすくなるのだから言うこと無しだ。やはり、プロトタイプと携帯電話3つ持って営業すべき先であろう。

AJAXは100倍!

何回か前の投稿で、
---
現在、UJMLの認知度はまだまだ低い。最近流行りのAJAXとは50倍以上差があるようだ。(※Googleアドワーズ統計より)
---
と書いたが、100倍以上と訂正する。(※Googleアドワーズ統計より)

エンタープライズ市場への展開がUJMLの普及を加速させるか?

Realcom現在、UJMLの認知度はまだまだ低い。最近流行りのAJAXとは50倍以上差があるようだ。(※Googleアドワーズ統計より)

さて、最近ではエンタープライズ向けウェブアプリケーション市場でも積極的にAJAXを採用し、ユーザーインタフェースを差別化要因として打ち出そうとしている傾向がある。グループウェアを開発するネオジャパンもそのような発表をここ数日で行った。

エンタープライズ向けウェブアプリケーションといえば「グループウェア(スケジュール管理、情報共有等)」「ナレッジマネジメント」「文書管理」等、明確な区切りをつけて列挙しても意味が無いがいろいろある。それぞれが多くの場合携帯電話向けのインタフェースを提供している。

写真のリアルコム社のナレッジマーケット(R)に携帯電話向けインタフェースが提供されているかどうかは知らないが、この会社は独立系でナレッジマネジメントソフトウェアを提供する会社としては業界1位だったと記憶している。事例を読むとわかるが、昔からユーザーインタフェースに極めて力を入れてきたようだ。

是非、このようなユーザーインタフェースを思いやるベンチャー企業で、かつ一気呵成に市場での展開を考えている企業にUJMLを採用して欲しい。UJMLには

・開発の生産性を向上する(iアプリ、EZアプリ、云々と別々に開発しなくて良い)
・ユーザーに快適なインタフェースを提供する

という二大特長がある。人的資源に限りがあり、かつ、イノベーティブな思考が根付いているベンチャー企業にこそUJMLが採用されるべきだろう。※ちなみにリアルコム社のナレッジマーケット(R)はJAVAベースのシステムだ。現在ある、ServletのUJMLコンパイラーがそのまま活用可能だ。

もし仮に、私がUIEJapanの営業マンなら、このようなベンチャー企業にプロトタイプとそれが動作する3つの携帯電話(DOCOMO,AU,VODAFONE)を持って飛び込み営業するに違いない。

実はもう一つあった壁 その壁の名は「Life is Beautiful」

Wall_2もう一つ、これはUIEJapanにとっての壁だが大きな壁があるのではないか?と今日気づいた。

それは「Life is Beautiful」という大きな壁だ。このブログはUIEJapanのマーケティングチャネルとして有力だといわざるを得ない。

このような強力な資産を、「当初から使える状態」、これこそが大きな壁となる可能性が十分ある。現在、比較的、人目を引くサービス、例えば「はてな」「Google」、もともと何か有力なチャネルを持っていただろうか?私は、MBAフォルダーでも何でもないが、見えない大きな壁がそこにあるのではないかと直感的に感じた。

私も、UIEngineの普及を願う一人だ。「Life is Beautiful」のチャネルを使ったらどんなに楽だろうか?と考えなかったと言ったら嘘になる。「楽」がどんな結果をもたらすのか?

また、前回書いた「壁その2.完璧主義」と似た状況に陥る可能性が高い。「こんなサービスでは恥ずかしい。」そう思うことが余計に無いだろうか?

この状態がどちらに転ぶかは、数年後の事実が証明するだろうが、それまで、この記事はここに埋もれているはずだ。

UJML普及に立ちはだかる2つの壁:「頭の良さ」そして「完璧主義」 その2

Wall_1 前回は「壁その1.頭のよさ」を書いたが、今日はその2を書く。

壁その2は「完璧主義」だ。

◆壁その2.完璧主義

この完璧主義は開発者側が自分の考える「完璧」にこだわるがゆえに、リリースが遅れ、本来リリースすべきだった時期を逃してしまう、ということだ。

特に、UIEngineという名前を冠しているがゆえに、開発者はその「User Interface」にこだわっているのではないか?と想像できる。例えばSDKを開発するときも、SDK実装上のUser Interface を必要以上にこだわる、といったことだ。

現在のSDK(Ver1.5)のインタフェースは不親切だ。どちらかと言えば。今後リリースされるUJML2.0のSDKは見てみないとわからない。私が予想するに、比較的凝ったインタフェースでSDKが提供されるのではないか?ということだ。もし、そのような傾向が見られたら、その後は壁にぶちあたるに違いないと勝手に予想する。彼らは、「自分たちはUIに最適なものを提供するためにUIEngineを作っている、その自分たちが提供するSDKのインタフェースがしょぼかったらどうする?」という思考にならざるをえない。

これが、リリースを遅らせ、最良の時期を逃すのではないか?という私の予想である。

UJMLにはただならぬ可能性を感じている。しかし、競合技術はゼロではない。そして技術者の数も限りある。いつ技術者のハートを捕らえるものを絶妙のタイミングで提供するかが、UJML普及の分岐点となるだろう。

ちなみにAJAXという技術(概念?といった方が正しいか)は、UIEngineを使えば、例えば携帯電話等の小型デバイス上で実装可能だ。そのことに多くのアルファギーグ層に気づかせるタイミングを間違ってはならないだろう。

今後のUIEJapanの戦略的マーケティングがどうなるか、みものだ。

「はてブタグホッパー」のRSS読み込み部分の見込みが立ったので公開

Hack_rss一応、はてブの注目記事をRSSから取得し、UIEngineに渡すところまでできた。

動作サンプルはこちら

※Enterキーで次のブックマークを取得

お願い:半角スペースが"+"となるが、気にしないで欲しい。他にもありそう。

ソースコード等
サーバーサイドのPHP→Download rss_read.php
↑で使われる ujbc の頭部分→Download XXX_String01.ujbc
同じく尻部分→Download XXX_String02.ujbc

クライアントのUJML→Download hack_rss.ujml
↑をコンパイルしたujbc→Download hack_rss.ujbc

アプレットのHTML→Download hack_rss.html

配置方法:全部同じディレクトリに配置

JavaApplet版のUIEPlayerとデバッガ-上のUIEPlayerの仕様が異なることについて

Okda 先日の投稿に「JavaAppletだと_link()が正しく動作しないのか、それとも私の設定が悪いのか」というものがある。

phpで作成した ujbc を吐き出すスクリプトを使ったサーバーとの通信プログラムがデバッガー上では動作するが、JavaApplet化すると動作しないことを書いた。

JavaAppletに関しては素人のため、JavaAppletの設定が悪いのか?と疑っていろいろ調べた結果、結局、タイトルに書いたように「デバッガーのUIEPlayerとJavaScriptのUIEPlayerの仕様が異なる」らしい、ということがわかった。

結論、どうしたらうまくいったのか?

「ヘッダーのContent-Lengthをセットする」

だ。↓

header("Content-Length: ".(108+$len+1));

こんな感じで php で書いたサーバーサイドのスクリプトで、ヘッダーContent-Lengthをセットするようにしたら期待通り動作するようになった。その間、サーバーのログを調べたり、問題の切り分けに頭を使ったりと、色々勉強になった。

これで無事 _link() を使ってサーバーと通信できるようになったので、ちょくちょく作っていこう。

UJML普及に立ちはだかる2つの壁:「頭の良さ」そして「完璧主義」

Wall約1ヶ月半ほど、UIEngine、そしてUJMLを体感(体験?)した。その中でふと考えたことを「UJML普及に立ちはだかる2つの壁」としてまとめてみた。今回はその1の「頭の良さ」について。

壁その1.頭の良さ

壁その2.完璧主義

※言及の中でUJMLの仕様に触れるが、仕様を100%理解していないので、間違いがあったら指摘していただけると幸いだ。
※また、私はUJMLが普及したらうれしいと感じており、揚げ足を取るつもりはない。

◆壁その1.頭の良さ

その1は、「UJMLを考えた人はとても頭の良いひとなんだろう」、という前提で話を進める。そう考えた理由は、「幅や高さの指定に%が使えないのはどうしてか?」にも書いたが、ヴィジュアルエレメント(箱とかラベル等のこと)を配置するときに開発者が座標計算をする前提でUJMLが作られているからだ。私もたびたび足の裏からむずむずしてくるような不快な思いをしている。

簡単なアプリケーションを作成するなら、厳密な座標の位置やヴィジュアルエレメントのサイズは気にせずに作れた方がいいのではないか?と思う。

ホームページ作成に使われるHTMLは何でもありにしたこと - 例えば、入れ子とか閉じタグ無しもOKでブラウザががんばって表示してくれる - により、老若男女世代を問わず普及に成功したのだと思う。(まぁ、それが、情報洪水を引き起こし、Googleの躍進を助けたのだが)

これに比べ、UJMLはヴィジュアルエレメントを座標指定せずぽんぽんと配置しようとすると、全て座標が初期値X=0,Y=0になりみんな画面左上に重なって表示されることになる。サンプルを作っていると「表示を確認したいだけなのに、何で座標まで指定しなければならないのか、、、」とむずむずしてくる。

そんなわけで、今のUJMLは座標計算等を苦に感じない人向けであり、「老若男女世代を問わず」というものではない。直接座標指定することは極めて凝ったUIを設計するためには必要だが、UJMLの入り口に立つ人にはちょっとやらしい仕様だ。

これは、UJMLを開発した人が頭の良い人で、そんな計算は朝飯前で頭の中で自動処理できるような座標変換のみを司るサブプロセッサを脳内に配置している人なんじゃないか?と考えてみた。

というわけで、「壁その1.頭の良さ」は、UJMLの仕様がむずむずする人の気持ちをくまないため、痒いところに手が届かない仕様になり、とっつきにくいと感じるだろう、ということがいいたいのだ。

今流行りのWEB2.0は、インターネットを介し、様々なサービスとの連携、マッシュアップ?によりユーザーに新しい体験を引き起こすことで、多くのユーザーを巻き込み、また、巻き込まれたユーザーが提供する側になることで良い循環が巻き起こっているのだと感じる。

この「連携」と「マッシュアップ」は、まず、「連携できるか?」が重要であり、ユーザーインタフェースはその次ではなかろうか?ゆえ、ある程度ユーザーインタフェースを適当に作れる余地があった方が良いと思うのだ。

例えば、

GoogleMapのAPIが公開されたとき、とりあえず、どこかに描をうち、「こんなことできるよ」的な紹介が多かった。連携できることを見せ、新しい体験と感動があったのだ。

その後、表示方法を工夫したり、描をオリジナルにしたり、と、インタフェースを改良し、優れたサービスとして提供されるものも出てきた、という流れがあったと思う。

UJMLには、まずWEBサービス等と連携する部分以外は、いい意味での適当さを持たせることが普及には必要だと感じている。UJML2.0に期待するのだ。

JavaAppletだと_link()が正しく動作しないのか、それとも私の設定が悪いのか

Hatena_komatta_1  サーバー側のスクリプトで簡単なujbcを動的に作り出すことができ、とんとん拍子で進むかと思ったら思わぬ落とし穴。JavaApplet版だと期待通りに動作しない。JavaAppletを初めて扱ったので勘所がわからない。開発者フォーラムに質問を出したが、すぐ答えが戻ってくるだろうか?

今は、左の絵のような状態だ。

さて、今回の試みでサーバー側から任意のスクリプトを使って文字列をクライアントに動的に渡せることがわかった。かなりシンプルな仕組みだ。現在 PHP がやっている、 ujbc 化するための前後につけるバイナリの処理を隠蔽すれば、誰でもクライアントに文字列を渡せる仕組みができあがる。

実は、SDKの中にはサーバーサイドでUJMLをujbcに動的にコンパイルするCompilerサーブレットがある。本来ならこれを使うのがUJMLの提供側が意図したことかもしれない。

しかし、サーバーサイドがJAVAというのは敷居が高い。流行のAjaxを試している人もPHP、Perl等のスクリプト系言語が主ではないだろうか?それには、JAVAが使える安価なレンタルサーバーが少ないことも影響しているのだろうが、こんなときは気軽なスクリプト系が良い。

結局何が言いたいのかと言うと、スクリプト系の言語で ujbc を動的に生成できる「なにか」を用意したらいいんじゃないだろうか?ということだ。

--------------

ここから話は変わって、これからどんなものができていくのかという話。

YahooWidgetsのギャラリーを見るとニュースフィード系の物が多いことは以前書いた。このカテゴリの中を見ると「ワシントンポストニュースフィード」「お天気ニュースフィード」等のコンテンツそのものもあれば、ただの「RSSリーダー」で何を読むのか自分で設定できるものもある。

これは、つまり、

中身はRSSリーダーだけど、ユーザーが選べる「スキン」がたくさんあるということ。

なのかと感じた。デパートにある携帯電話の塗装屋が思い浮かぶ。

技術的なところでは「RSSリーダー」だが、デスクトップ上での「見た目」とか「サイズ」をこだわって色々作りたくなる人もまたたくさんいるということなのではないだろうか?

UIEngineもXMLの親和性の高さと通信可能な特色を活かし、小型デバイス上のアプリケーションのスキンをおしゃれに着せ替えさせられる、そんなフレームワークを提供したら面白いのかもしれないと感じた。スキンをギフトでプレゼントなんてことも将来あるのかもしれない。

RSS→ujbc化してUIEngineで表示させられるようになった。

Hatebu_rssok前回の「RSSリーダーはOKだ。あとは、つなげるだけ。そうすれば、「はてブタグホッパー」の記事取得部分はほぼ完成だ。」の続き。

前回までにRSSをサーバー(PHP)で読むことに成功していたので、読み込んだ記事のタイトルをUIEngineに渡す仕組みを作った。

【サーバーがやっていること】PHP
1.RSSの記事のタイトル読み込み
2.適宜文字コードを変換
3.ujbcの仕様に準拠したバイナリを作成

たったこれだけで、UIEngineのクライアントにRSSから読み込んだタイトルを渡すことができた。(一部、urlEncodeしたときのスペース→"+"の変換をしっかり処理していないが)

phpのコードを載せておく。

phpが作成するujbcは表示したい文字列以外をあらかじめ用意したujbcのバイナリの頭の部分と尻の部分をファイルから読み込んでいる。ujbcの仕様は知らないのでこの方法を取った。

Download rss_read.php

UIEngine アプリボックス構想を勝手に考える

Uiengine_aplibox作業用PCのハードディスクが壊れ、UJMLサンプルの作成を休憩しているので、UIEngineまわりで何があったらいいかぼーっと考えたものを絵にした。

これは、「ライブラリとアプリが入る箱」だ。これが欲しい。誰もが使えるライブラリとアプリ(UIEngineで動くもの)が入る箱だ。インターネット上に公開されている箱だ。

これを考えた理由は、「携帯電話の制約:アプリをダウンロードしたサーバーとした通信できない」があったからだが、結構無理やり考えたものだ。この箱には誰かが作ったアプリとかライブラリが保存されている。

こうすることで、携帯アプリでもAさんが作ったライブラリをBさんのアプリが利用できるようになる。

最初のうちは、作って公開する人も少ないので、箱の提供側が「がんばって面白いものをつくり」載せるのだろう(黄色の部分)。そのうち、面白さに気づいた人が、作って投稿してくれるかもしれない(「勝手ライブラリとアプリ」)。そして割合もだんだん「勝手」のものが大きくなるだろう。

アルファギーグと呼ばれる層に「面白さに気づかせる何か」を最初に箱に入れて提供するうことが極めて重要なのだが、ちょうど良いベンチマークがあることに気づいた。

それは、Yahoo Widgets

ギャラリーにはWidgetsが掲載されている。カテゴリ分けされ、だいたいどんなもが作られやすいのかがわかるかもしれない。ニュースフィード系、ゲーム系が多いようだ。このあたりを箱の提供側が惜しみなく出し(もちろんオープンソースで)、ただで使わせるのが良いだろう。各種WEBサービスと連携するためのWEB-APIライブラリは必須だ。

これが完成すれば、このブログで出した案のいくつかも比較的容易に実現できるに違いない。

ロジックをユーザーが参加して作るということ
何を作るか?プレゼンテーションViewer。その2
[prototype]はてブタグホッパー、クライアントサイドのみ作りこみ
ブログパーツとして貼り付けられる何か?指名手配犯?

そして、完成後は大々的にキャンペーンを張る。CMも打つ。採用するタレントは「YOU」と「飯島」がいいだろう。CMはこんな感じだ。エンジンが剥き出しになった車(クラシックカーみたいなの)で、YOUと飯島愛がマッドマックス的な道路をバリバリ走りさるだけだ。

途中のセリフ

飯島:「ねぇ、YOU(ゆう)」

YOU:「なぁに、愛(あい)」

飯島:「エンジン、最高だね」

YOU:「まぁ、私が作ったんだからね、、、、」

といった感じで、最後にちょっとした落ちを入れるだけだ。最初にYOUと飯島が二人でエンジンを作って、車で出かけるという設定も良いかもしれない。第二段は携帯電話を作る話だろうか、最初が携帯電話を作る方がいいだろうか。

RSSリーダーはOKだ。あとは、つなげるだけ。そうすれば、「はてブタグホッパー」の記事取得部分はほぼ完成だ。

Hatebu_list ↓のようにRSSReaderは完了。
http://www.uiengineda.com/rss.php

こちらの、 「MagpieRSS - PHP で使える RSS パーサー。」を参考にさせてもらいました。

あとはつなげるだけ。

完成が見えてきたらおなかがすいたこともあり、モチベーションが下がってきた。今日はここまでで終了。

UIEngineの文字処理よりもphpの文字処理に手間取った

Mb_convert_encode 無事日本語をサーバーから受け取って表示できることを確認した。

よかった。後は、サーバー側にはてブを読み出すリーダーをつけるだけだ。

・PHPでWSSE認証
・HTTP_Requestを使ってはてなフォトライフへ画像を投稿

このあたりを参考に。進めよう。

追記:と思ったら、注目記事はAtomAPIではなく、RSSで提供されているのだった。そちらで充分、AtomAPIはまた今度の話だ。RSSReaderはこちらを参考に。

コンパイルされると文字コードはurlEncodeされた状態で保存される

Binary_a 「あ」なら E3 81 82 といった具合。php上で

「日本語」→「urlEncodeされた16進数のバイト配列」

という変換をする必要がある。どうすればいいんだろう?

コンパイルしてujbc化すると日本語はどうなるのか調べておく

Stopwatch 先の投稿で書いたが、動的にujbcを作成することに成功した。

これなら、はてブの注目の記事を取ってくることも可能だ。

その前に、日本語はどうなるのか調べておく必要がある、調査開始。そのまま、はてブの注目の記事リストの取得までこもる。

※はてブ注目記事リストの取得完成の報告前に、他の種類の投稿があったら、途中で挫折したということだ。

よーいどん。(自己実況開始)

無理矢理ウェブサーバーと通信して、WEB2.0の世界を体感する足がかりを作る

Server_trans2 先日「無理矢理ウェブサーバーとの通信を実現するには?」で書いたが、サーバー側でPHPか何か適当なものでujbcというUJMLがコンパイルされた中間コードを生成すれば通信できるはずだった。今日、実験してみたので結果を書く。



成功した(画像参照)


以上

Yahoo Widgetsを見ながら、UJMLの未来を考える。

Yahoo_widgets詳しいことは今日知ったのだが、Yahoo Widgetは、Windowsやマッキントッシュで小さなアプリケーションを使う仕組みだ。計算機、RSSリーダー、天気予報とか、そんなに大きなサイズがいらないアプリケーションを実行できる。アプリケーションは無償で1,000以上公開されているらしい。

チュートリアルを見ながら、思うことは、こちらの開発言語もXMLベースなので、UJMLと似ているということだ。どちらもXMLということは簡単に変換にできる。ただ、見た感じではYahoo Widgetの方が仕様が大きいので、

UJML→Yahoo Widget : 簡単
Yahoo Widget→UJML : ちょっと?

となるだろう。

UIEngineは「一回作れば、どこでも期待通り動作する」ことが売りなので、Yahoo Widgetに変換できれば、PC用のUIEngineを新たに開発する必要は無い。その辺の敷居を下げるxmlベースの開発言語は素敵チックだ。

早速、さわってみて、Yahoo Widgetへの変換をできるようにしたら面白いかもしれない。

Yahoo Widgetをインストールしてみよう。

UJML2.0の進化を読み解こう-DTDを眺めれば何かが見える?

UJML2.0のリリースが数週間後という話もあるが、アルファバージョンを使わせてほしいという私の要望も放置されたまま、仕様だけでも知りたいという欲求が、5分ほど前、あるヒントを与えてくれた。

「DTDから探れ!」

というものだ。UJMLはxmlベースの開発言語ゆえvalidationするためにDTDが存在する。UJML1.5用には1.5用のDTDが、UJML2.0には2.0用のDTDがあるわけだ。

というわけで、ここにあった。

http://www.uievolution.com/dtd/ujml-2.0.dtd

中を見れば、新しい仕様が見えてくる。Diffで1.5のDTDと比較するともっと見えてくる。

このDTDが完成版なのか否かは定かではない。ただ、比較してわかったのはやっぱりオブジェクト指向チックな言語になりそうだ(Interfaceとかそのあたり)ということだった。

テレビのリモコンと携帯電話とキーボード

J0289581_1 テレビのリモコン、携帯電話、キーボード、この3つの道具には番号のボタンがあるという意味で共通するが、一人だけ仲間はずれがいる。

キーボードだ。

キーの配置がキーボードだけ違う。

テレビのリモコンと携帯電話は
123
456
789
と並ぶが、キーボードは
789
456
123
と並ぶ。

だからJavaApplet版と携帯電話版のアプリを作るとき悩んでしまう。デバイスのキーの配置がキーボードタイプなのか、電話タイプなのか知る方法は今のところ無いようだ。

というわけで、UJMLは確かifdefができたので、JavaAppletでコンパイルするとき用にキーの配置を意識してアプリを開発する必要があるだろう。

このキー配置を誰が決めたのか知らないが、世の中全て統一すべきときがきたのかもしれない。ちなみにそばにあったCANONのコピー機は携帯電話と同じキー配列だった。FAXとの複合機だからあたりまえか。

今後UIEngineは様々なデバイス上で動作するように展開されるかもしれない。そうなると数字の配置が妙なものもあるだろう。横一直線に1234567890と並ぶものもあるかもしれない。これにどう対処するのか?UIEngine側で何とかするのか、UJML開発者及びディストリビュータが何とかするのか?

はっきりしていることはただ一つ。

UIEngineが対応しなければ、開発者が何とかするのだ!するしかない。

ということだ。

幅や高さの指定に%が使えないのはどうしてか?

UJMLではヴィジュアルエレメント(箱とかラベル等)を表示するときに、その表示位置やサイズを具体的に指定することができる。

<box>
<x>10</x>
<y>10</y>
<width>100</width>
<height>100</height>
</box>

こういう感じだ。個人的には幅width,高さheight共に、スクリーンのサイズ、または親の要素に対する%指定ができた方がうれしいと感じている。

UJMLはデバイスの環境、例えばスクリーンのサイズ、を取得し、1回作成したものが多くのデバイスで期待通りに動作するように作りこむことを推奨している。ここ1ヶ月ほどサンプルを作りつづけてきたが、サイズの%指定はあるとうれしいと感じた。これは、ブラウザのサイズが人によって異なるホームページ作りの話に似ているかもしれない。見やすいページを作るには「幅を固定しないこと」とどこかに書いてあった。HTMLではそういうときに%指定を重宝する。

UJMLにも必要ではなかろうか?

「%指定したいなら、%の値をかけて100で割ればいいんだよ。」

と作った人が言っているのが聞こえてきそうだ。いつでもさっとそういうことができる人がUJMLの仕様を決めているに違いない。

小型デバイスを持ち歩く必然性、携帯に勝るものは何か?

多くの人が日常携行するもので、インテリジェントな小型デバイスといえば「携帯電話」に勝るものは無いだろう。最近は(昔からそうだが)、iPodを始めとする携帯音楽再生機を携行する人も多いが携帯電話には及ばない。

かなりインテリジェントさでは劣るが、ICチップつきカードが、日常携行する小型デバイスとしては、所有数が携帯電話を超える勢いで増えているのではないかと思う。

これらの小型デバイスを持ち歩く必然性を考えると、ICチップつきカードが携帯電話を超えていると感じる。現在では、間違いなくほとんどの場合ICチップは「お金」に関係しているからだ。そして、財布の中に入っている。

携帯電話を忘れてもそのままのことはあるが、財布はがんばって取りに帰る。これが、「持ち歩く必然性」だ。

さて、最近は携帯電話が財布化しつつあり、携帯電話と財布の境界があいまいになりつつある。これは、携帯電話の「小型デバイスを持ち歩く必然性」を極めて高めるものであり、そうなるべく手を打ってきた携帯電話のキャリアには頭が下がる。

例えば、ちょっと買い物に出るときに、「財布は持つが、携帯は置いていく。」という行動が現在はあるが、それが無くなるのだ。

今後、携帯電話が財布に近づけば近づくほど、携帯電話とユーザーの接点・接触度が増える。

小型デバイス上での質の高いユーザーインタフェースがより一層求められ、ユーザーインタフェースも進化していくのだろう。

先人の知恵とUJMLの進化

YubinukiUJMLは他の言語がそうであるように進化を続けている。数週間のうちにUJML2.0がリリースされるはずだ。(1月からそう言っているが、少し遅れている感もある。ちなみに現在はバージョン1.5。がんばれPete!)

わかっている情報から推察すると、UJMLの進化は現在のWebを取り巻く世界で起きている進化(例えばWeb2.0の話)を捕らえたものにるだろう。余談だが、Web2.0の柱となるいくつかの要素は、UJMLが産まれた当初の思想自体に入っており、「UJML設計者に先見の明あり」と言えるかもしれない。

さて、UJML2.0ではサーバーとの通信ができるようになり、言語自体もオブジェクト指向チックになる。前者はGoogle、Yahoo等を始めとするWeb関連企業が提供開始したAPIとの接続を容易にし、UJMLで作られるアプリケーションの可能性を極めて大きくするものだ。後者は開発の生産性を向上させ、UIEngine及びUJMLの普及を爆発的に進める可能性がある。設計思想に優れた開発言語はその言語の「グル」を誕生させ、その使いやすさがWEB上でアピールされやすい。例えば、5分で作るWebアプリケーションといったものだ。

この投稿のタイトルは「先人の知恵とUJMLの進化」だが、UJML2.0での進化も既知のものであり(他の言語でできるのにどうしてUJMLだとできないの?といったもの)、先人の知恵を拝借している。UJMLが産まれた当初も、同じように先人の知恵を拝借したのだが、

「余分なものを切り捨て、エッセンスのみを実装した」

という点がにくらしい。UJML2.0での進化もこうであることを期待する。

「先人の知恵」と言えば、裁縫道具のひとつに「ゆびぬき」というものがある。手縫いという作業は

針と糸で布と布とを縫い合わせる(布とボタン、その他のものの組み合わせもあるが)

という極めてシンプルなものだ。「ゆびぬき」はその作業の中で、やってみなければわからない作業上の障害を取り除き、見事に手縫い作業に貢献している。そして、裁縫道具箱の中に必ず納まるという現在の地位を得たのである。

全く関係の無い「UJML」と「裁縫」だが、UJMLもインターネットの進化、小型デバイスの進化に合わせ、「余分なものを切り捨て、エッセンスのみを実装」することを続けられたら、確固たる地位を得られるようになるに違い無い。

無理矢理ウェブサーバーとの通信を実現するには?

Hack以前、UJML2.0にならないとWEBサーバーとの通信はできないということは書いたが、1.5でもどうしてもやりたくなることもある。後2,3週間待てばでるはずなのでそう焦ることもないのだが。

そこで、今回触りだけ考えてみることにしたので紹介する。

UIEngineの仕組には、UIEPlayerと呼ばれるものがある。このUIEPlayerがUJMLからコンパイルされて生成される中間コードujbcを実行する。この中間コードujbcとは_link()という関数を使ってリンクすることができることはリファレンスマニュアルに書いてある(_link()はまだ本ブログでは説明していないが。)。

ということは、

クライアント→中間コード生成+WEBインタフェース→WEB API(Google、amazon、はてな)

ができれば、UJMLで作成したクライアントから仮想的にWEB APIを利用することができる。そこで、中間コードを生成するにはどうしたら良いか?と考えるわけだが、所詮はバイトコードの集合であり、UIEPlayerが読み取れる特定の仕様に則っているはずなので、「バイナリエディター」というもので覗いてみることにした。

まぁ、難しいことは無さそうである。(文字列の中身が暗号化なり、特異なEncode処理されていたらどうしようかと思ったが、そんなことは無かった。)

WEB APIとのやり取りも基本は「テキスト」なので、特定のテキストを持った中間コードが生成できればやりたいことは実現できる。

サーバー上での中間コードの生成はどんな言語(php,perl,java等)を使ってもバイト配列の書き出しなので対したことは無いことは想像がつく。

UJML2.0が出る前に時間のあるときに少し触ってみよう。

UJMLのエクステンションって何?

ExtentionUJMLの言語リファレンスをながめていると「エクステンション」という機能があることに気づく。

この機能、SDKに含まれているサンプルでも使用例として提供されていないのだが、いったい何ができるのだろうか?

と、読み進めると、どうやら、UJMLで提供されていない関数や機能を、もしデバイスが実装していたらそれを使えるようにするためのもの、らしい。

例えば仮に、ある携帯電話がアプリから電話帳へのアクセスを許していたら(ありえないか。。。)、それはUJML標準では提供されていないので、電話帳へのアクセスするための関数やらを使えるようにする仕組、ということだ。

UJMLの言語としての進化のスピードと携帯電話等のデバイスの進化のスピードを考えたとき、こういう仕組が入っていることはとてもありがたい。携帯電話の機種といった、デバイスに依存するアプリになる可能性が高いがユーザーに新しい感動や体験をさせられるならそれもありかな、と思う。

"Make One Run Anywhere"の制約から逃れるための方法として活用したいものだ。

。。。使い方はわからないが。。。

何を作るか?UJMLのCMをUJMLで作る その6

今回で6回目の更新ですが、UJMLに関する説明を文字で表示するようにしました。

←のデモをご覧ください。

今まで紹介したUJMLサンプルのステートマシンを活用しています。

便利なステートマシン(コンポーネントのこと、Javaで言うところのクラス)のライブラリを持っていれば、組み合わせで色んなものが作成できるというのは他の言語と同じです。

未発表情報?今度のInside UJMLはWikiか?

Insideujml_wikiここ数週間の内にUJML2.0が出るようだ。

そして、UJML2.0のリリースと同時にInsideUJMLも公開されるが、そのInside UJMLがなんと「Wiki」になるという情報を得た。「Wiki」になるということは、基本的には誰でも更新が可能になる。そういうドキュメントを実現する試み。画像は作り途中のWikiだ。リンクはこちら

今まで「Inside 何とか」というドキュメントは多く見てきたが、これはもしかしたら業界初の取り組みなんじゃないかと思う。

「テクニカルドキュメントをユーザーに書いてもらう」という何ともユーザー本位な試みだと感じた。

テクニカルドキュメントは大概、何だかわかりにくく、しまいには読み手を無視して、解説を割愛し、最後はサンプルコードのオンパレード、「全てはソースコードにある」、とでも言わんばかりのものが多かった。それがあたり前だったと思う。

そこにメスを入れる、全く新しい取り組み。結果がどうなるかわからないが、この挑戦は興味深い。

良い結果を期待しつつ見守りたい。

と、今までなら書いているが、書き直す。

良い結果を期待しつつ積極的にこの試みに貢献したい。

UJMLを書くときの生産性

Ujml_on_emeditorUJML2.0はEclipseベースのRADツールと一緒にSDKとして提供されるらしい。気が付けばUJMLを毎日書いているが、遅くて仕方が無い。

タグの自動挿入等、Editorにやって欲しいと思うことが山ほどある。

私はEmeditorというEditorを使っているが、UJML2.0が出るなら、EmEditorプラグインを作るまでも無く、しかし、UJML2.0がいつ出るのかはっきりせず、いつになるのか?それだけでも、早く知りたいものだ。

何を作るか?UJMLのCMをUJMLで作る その5

UJMLは「非同期ゆえの面白さ。」があると感じる。

非同期ゆえにうまいことタイミングをずらしてエフェクトをかけると予期せぬ効果が得られることがある。偶然の産物だが、その辺をイメージできるようになるとユニークなものが作れるようになりそうな、そんな予感はする。

forは使えるのか?

Control_flow最近インサイドUJMLの解説を書いていないが、「Control Flow」の中でifとwhileはサポートされているが、forとswitchはサポートされていないと書いてある。

ところが、forは使えるようだ。

うーん、ドキュメントに書いていない実装がいろいろありそうである。

何を作るか?UJMLのCMをUJMLで作る その4

Ujml_cm_3 動作サンプル

入場とジャンプが終わった後、ENTERキーを押すと、UJMLの文字がランダムに移動する。本当はクリックした位置に移動するようにしたかったがJAVA Applet化するとうまくいかない。PDAのスタイラス対応のXY座標の取得がJAVA Appletでは期待どおりに動作しないようだ。

↓これら
_getIntProperty( &_VALUE_INT_ONSELECT_X_REL; );
_getIntProperty( &_VALUE_INT_ONSELECT_Y_REL; );

何を作るか?UJMLのCMをUJMLで作る その3

Ujml_cm_2 のんびりと改良しながら進める。

動作サンプル

 

スタートボタンが押された後、スタートボタンが小さくなって消えるようになった。後は、クリックすると何回でもジャンプするように変更。

文字<text>つきの<label>は文字を消してから小さくした方が良いということがわかった。文字サイズを<label>サイズに合わせて勝手に変えるようにすることはできないのだ。デバイスにインストールされているフォントシステムに依存するのだろうけど、今のところ携帯電話にそこまで期待すべきでは無いのかもしれない。

開発者フォーラムデザイン変更中?

UIEvolution開発者フォーラムのデザインが微妙に変わった。アイコンの種類が変更されたようだ。

ここ24時間中の投稿が無い。質問したいことは結構あるが、英語にするのがやっかいだ。

英語と言えば、Googleはページを翻訳してくれるが、投稿フォーム内を翻訳する機能も誰かに実現して欲しい。

何を作るか?UJMLのCMをUJMLで作る その2

Ujml_cm_1 前回から改良、UJMLの文字がばらばらとジャンプするのが気に入っている。

動作サンプル

 

ところで、「前回SDKのバグ」だと書いたが、私のミスだった。申し訳無い。SDKに謝りたい。これから、日々精進だ。

ソースコードはまだ見せられない。恥ずかしながら、関係無いコードもたくさん入っているのだ。何しろ、今までのUJMLサンプルの組み合わせゆえ。

ところで、作るにしたがって、もっと「UJML」の特徴を打ち出したいと思うようになる。そうなると、よりクリエイティブな領域に足を踏み入れることになるのだが、いかんせん、慣れていないので骨が折れる。

「あっ、だから、広告代理店がいるんだ!」と正直納得した。

今日たまたま友人にUIEngineについて話すことがあった。そういう機会があると自問自答する。何故UIEngine、UJMLでなければならないのか?Flashでいいじゃん、と。

苦しい。

何か、他人を「あ、なるほどね」と言わせる、そんな表現が、言葉にならない。

だから、UJMLのCMを作ろうと思ったのかもしれない。

しかし思う。単純なアニメーション作るにはUJMLは向いていないんじゃないだろうか?と。

UIengineは「非同期」を前提に作ってあるだけに、ステート変数がやっかいだ。手続き型でプログラムを作ってきた私には、頭がこんがらがる。手続き型でプログラムを作ってきた人にとっては新しいチャレンジの要素があると感じた。というのは、「非同期」前提で、スマートなプログラムを書くのは結構楽しそうなのだ。

そして、UJMLは実装がシンプルなだけに工夫するのが楽しいのだ。SDKに含まれているサンプルでもMVCモデルに沿って作成されたサンプルがあるが、開発を効率化するための工夫を考えるとまた知らぬ間に時間がたっていくのである。

何を作るか?UJMLのCMをUJMLで作る

Ujml_cm とりあえず作ってみる。

動作サンプル これは今まで作ったものの張り合わせのプロトタイプタイプだ。(※動作サンプルの実行にはJAVAが必要です。)

UJMLのJとMとLが重なるのは望んでいないが、JavaAppletに変換するときのSDKのバグだと思う。SDK上では期待通り動作するのだ。

実は頭の中に絵コンテはある。それを実現するためのスピードが足りない。日々精進だ。

ロジックをユーザーが参加して作るということ

Mario私はマリオブラザーズという任天堂から出ているゲームが好きだ。
・画面一杯を使って動き回ることができる自由度
・右端に行くと左端に出るという発想の奇抜さ
何をとっても秀逸だと思う。

なにより、敵キャラが良い。カメ、ハエ等極めてシンプルだが、動きに特徴をもたせることで、移動ロジックを統一(例えば、いきなり理由も無く方向転換しない)しつつ、バラエティに富んだ面を演出している。

UJMLに限らず、どんな技術を使ってもそうだが、例えば、このマリオブラザーズの敵キャラの動作をユーザーがインプリメントして、それを別の誰かがプレイすることも今後は可能になる。

一時期、IBMが戦車のバトルゲームのインタフェースを公開し、JAVAができるひとが、戦車に独自の戦闘アルゴリズムを搭載し戦わせるイベントをやっていた(名前は忘れたが)。これと同じようなこともすぐ実現可能だ。UJMLはJAVA程難しくない。HTMLができるひと、ノンプログラマーまでが参加できるようになる。そういうことも何だかわくわくする。

※なお、この記事は技術的に今すぐ実現できるかどうか確認せぬまま書いたものである。期待も含めて書いた部分もある。

UJMLはどこに行くのか?

Box_fl8pro_112x112この前書いた「何を作るか?プレゼンテーションViewer。その2」で、FlashがXMLになっているのかどうかという疑問があったが、こちらを見る限り、半年以上前にXML化が進んでいたようである。私は結構、遅れている。

こちらの記事とUIEngineの概念を読むと、UIEngineとFlashの目指すところが極めて似ていることに気づく。

この2つはどうなっていくのだろうか?WEBアプリケーションを作成する言語がC,Java,Perl,PHP,等色々あるように、UIEngineとFlashも色々あるうちのひとつになると感じる。

もちろん、あるデバイスはどちらかしか対応していない場合もあるだろうが、仕様がXMLベースなのでその変換も簡単である。変換するためのミドルウェアをどこかの企業が製品化して売り出すかもしれない。しかし、変換用のミドルウェアは家電連合が一緒に作り、組み込み家電普及のために仕組を無償で提供してくれるとありがたい。

UJML2.0は何ができるのか?

もうじきUJML2.0が公開されるらしいが、どんなものが追加されるのか?期待に胸を膨らませているのは、私だけかもしれないが、UIEngineに大きな可能性を感じているだけにそれは仕方が無い。

実は開発者フォーラムで質問する中で、なんとなく私が欲しいものが追加されることがわかった。例えば、UJML1.5(現在のバージョン)は画像ファイルとサウンドファイルは極めて簡単に外部リソースを利用できる。インターネット上にある画像や音を簡単に使えるのだ。

しかしながら、テキストデータを取得して使うのは結構面倒だ。意外である。サーバーサイドにphp等でプログラムを作りこみ、クライアントにデータを渡すようにしたくても、想像以上に面倒なことがわかる。

1.5ではそういう使い方を想定していなかったのだろうが、UJML2.0ではそれが可能になるらしい。

早くUJML2.0を使いたいものだ。

何を作るか?プレゼンテーションViewer。その2

1_1_intro_a_1先日「何を作るか?プレゼンテーションViewer。」という投稿で、マイクロソフトオフィスがXMLをサポートすると書いたが、次期バージョンOffice12の発表でやはりそう言っている。

-----
 Office “12”では、Wordは「.docx」、Excelは「.xlsx」、PowerPointは「.pptx」の拡張子が付く。これらのフォーマットは圧縮ファイルフォーマットの「Zip」をコンテナとして利用している。

 文書フォーマットがXMLベースになることで、Officeとほかアプリケーションとの連携が容易になる。1度作成した文書の再利用も簡単になる。
-----

エンタープライズのナレッジマネジメントシステム等でファイル共有する仕組がよくある。しかし、共有するだけでシステム上からダイレクトにファイルにコメントを書き込んだり、そういうことができなかった。私は、PowerPointで資料を作成するとき、メモ欄を重宝するが、そこに誰かが意見を直接書き込んでくれるととてもうれしいなぁといつも思っていた。Office12以降ではそういう実装も容易になるだろう。極めてうれしい。

そうなると、移動中にプレゼン資料を見ながらコメントを書き込むことも容易になる。携帯上でOfficeが動くまでもない。

Office12、早く出ろ!

それから、もうひとつ、プレゼン資料の切り貼りも携帯からできるようにしたい。いくつものPowerPoint資料から必要部分をアセンブルして新しいプレゼン資料を作ることはよくあることだ。また、ほんのちょっと修正(提案先名変更等)して作ることもある。XML形式になれば、その辺のバージョン管理ツールの作成も楽だし、オブジェクト指向的なプレゼン資料のオーサリングツールの開発も簡単にできるだろう。

Office12、早く出ろ!

でも、価格は下げてくれ!
(事業に占めるMSN等の広告収入比率をあげ、Officeに頼らない体質になったら価格はさがるのだろうか?)

次期バージョンのOffice文書がXMLをサポートするが、その他の文書はどうなのだろうか?例えばFlash,PDFだ。もうそうなっているかもしれないがいずれ全ての文書がXMLになるだろう。そうなると、良く言うところのセマンティックウェブで期待されている、世の中に存在する情報が整理された状態に極めて近づくことになる。

そうなると、フロントのUIがとっても重要な役割を果たすのだ。つまり、Office文書、Flash文書、PDF文書等何でも構わず、一種類のユーザーインタフェースで編集可能なツールが作りやすくなる。なんか、すごいことだ、わくわくする。誰がその状態に対して先鞭を打つような、画期的な「何か」を出してくるのだろうか?

やっぱりGoogleか?

そうでないことを願う。

立て、日本のベンチャー企業達!

今がチャンスだ。

頼むからベンチャーキャピタルはもっと財布の紐を緩めてくれ。

UIE™ SDK 1.5.2 Beta 1 はどうか?

Sdk_152_1SDK1.5.2のBeta1が公開されている。インストールしてみる。

 日本語のUJML言語リファレンスとDoja対応が新しいようだ。

exeファイルをダウンロードして、インストール開始だ。インストール開始時に出るグラフィック(思わずキャプチャーし忘れたので、次回インストール時にはキャプチャしよう)、なかなか良いと思う。

ユーザーは一度ぐらいしか見ないだろうが、こういうところに凝っているのはさすがだなと感じる。しかし、それに比べてSDKのデバッガー起動時には飾り気もない。これは起動の快適さを取ったということだろうか。

Beta1ということだが問題なく動いている。

何を作るか?プレゼンテーションViewer。

1_1_intro_aUJMLサンプルで色々なものが作れることはご理解頂けると思うが、さて、何を作ろうか?

ゲームだろうか?何かのツールだろうか?

ふと思ったのが、プレゼンテーションコンテンツのViewerはどうだろうか?仕事でよく使われるPowerPoint(R)というマイクロソフトのプレゼンテーションソフトがある。確か次期バージョンのオフィス製品(Word,Excel)はXMLの保存形式になったような気がする。サポートするだけだったか?詳細はわすれたがいずれにせよXML形式でファイルを保存できるという話だったと思う。

そうなると、PowerPointXML→UJMLがスタイルシート変換で一発、何てこともできそうだ。

移動中に携帯電話で会議用の資料を確認する。ということもあるかもしれない。

ところでOfficeのファイルがそのまま開ける携帯電話がどこかにあったような。

あと、FlashやPDFはXMLで保存できるのだろうか?

UJMLはべき乗の計算はできるのか?

できないようだ。演算子のリファレンスにはべき乗を演算するためのものは載っていない。UJMLでは楕円を描くことができる。<x-oval>というタグを使うのだが、楕円が描けるのならべき乗も計算できるはずだ。私ができないと勘違いしているだけだろうか。そうかもしれない。

SDKはWEB上に持ってこれるか?

UIEngine用のアプリケーション開発はUIEvolutionから提供されている開発環境を使っている。「UIEvolution SDK」だ。このSDKはJAVA1.5が必要で、手元のローカルで動いている。

ところで、できあがったアプリケーションは基本的にはWEBのどこかに配置する(ことが多いと思う。)。なら、何故ローカルで開発しているのだろうか?

日頃、JavaServlet+JSP等でWEBアプリケーションを開発することが多いが、開発環境は大部分WEBベースだ。アプリケーションモデルの基本となるスケルトンはWEB上から作りこめるようにしている。HTMLフォームの入力を元に、内部的にXMLを生成、XMLからJAVAソースコードを生成、といった具合だ。

こんなことを日常的にやっているにも関わらずたった今まで気が付かなかった。UJMLをWEBベースで開発するのもそんなに難しいことでは無い。今ある開発環境をいじれば良い。さしずめ「UJMLWebDeveloper」といった名前だろうか。

どうでもいいが、私はRelaxが好きだ。こんなときにも役立ってくれるRelaxにありがとう。

UIE開発者フォーラムは英語で投稿しよう!

 先日「Developer Forum だ」で、日本語で投稿しても良いだろうか?書いた。

 フォーラムで日本語はどうか?と現地で聞いたところ、「できれば英語で」という回答。フォーラムでの質問と回答はフォーラム参加者でシェアされるべき「価値あるもの」ゆえ、フォーラム参加者全員の共通語でやり取りされるのが望ましい。

 さらに付け加えると、「もしどうしてもなら、日本語でも良いですよ」というとても温かみのある回答も同時に頂いている。感謝感激だ。とても懐の広いフォーラムではないか?

 こんなことがあり、Googleのような会社が多言語一括翻訳を代理するようになったら世の中の知識の移転はいっそう加速化するだろうな、などと一人納得した。

UIEngineはどこでもあるべき

 時間があったらFirefox用プラグイン版UIEngineを作ろうかと考えた。

 ただの思い付きだ。

 そういえば一昔前、IE4が出たぐらいだったか、OSとIEがくっついてActiveDesktopが云々とかそんな話があった頃、「もうこれからはブラウザの時代」みたいな話をしていたことをふと思い出した。もちろんその頃はAJAXとかブログとかは知らなかったのだが、インターネットとブラウザが何でもやってくれるドラえもんの四次元ポケットに違い無いと思っていたかもしれない。

 結局その後、思っていたほどの進化もブラウザには無かったのだけど、どのパソコンにもブラウザが入っている、しまいには携帯電話にも入っている、家庭用ゲーム機にも、、という現実が目の前にある。

 それと言うのはHTMLをもっともらしく解釈して、表示してくれる仕組みがどこにでも入ったってことで、UIEngineもそうなってくれるとうれしい。それは、例えば、UJMLで作った「何か」を、始めて出会った鈴木さんでも高橋さんにもプレゼントできるということになる。そうなると、創作意欲倍増だ。なんか、うれしい。何を作ってもプラスのフィードバックを得られる無敵な気分だ。

 できあがりのイメージは、FireFoxのツールバー上に「小さい小窓を引っ張り出す取っ手」みたいなインタフェースがあって、そこを引っ張ると使いたいUJMLで作った何かが使える、ただそれだけだ。

 「それならIE用に作った方がいいんじゃない?」と100人いたら99人が言うだろうけど、UJMLを楽しんでるし、Firefoxのプラグイン作りたいと思ってたけどネタを探していた、というどうしょもない理由で、自分の時間を使ってみたいと思うのが、きっかけで、「UIEngineがどこでもあるべき」というのは後付けの理由だった。

Developer Forum だ

UIEngineの開発者用フォーラムができている。
http://developer.uievolution.com/forum/

まだ数えるほどしか投稿が無いが、これからどんどん増えることだろう。

思えば、2,3日前に初めてブログを書いてみようと思い立った、その理由はUIEngineが面白かったからで、日本語のドキュメントとかTipsも無いので作っておこうと思ったのがきっかけだ。しかし、始めてからたった3日にして開発元がフォーラムをオープンした。

このブログは、もうやめようかな。真の三日坊主だ。それもひとのせいにしようとしている(笑)

ところで、このフォーラム、日本語で投稿しても良いのだろうか?

JavaAppletPTSによる配布

作成したサンプルをJavaAppletPTSという仕組みでWEB上にJavaAppletで公開配布できる。それもSDKのツールを使って、それこそ「ワンクリック」だ。COOLだ。

ただ、ルパン三世ティッカーもそうなのだが、公開配布したはずのAppletが期待通りに動作しない。画面に何も表示されない。

「俺」すら表示されない。

何故だ?誰か教えてくれ。

そっけないエラーメッセージは次期バージョンで修正されるか?

20060125error_1UIEngineというプラットフォームではUJMLというXMLベースの開発言語でアプリ開発をする。そのためのSDKがUIEvolution社から公開されている。

ところで、前回「デバッガーのコンパイルエラーメッセージがそっけないけど」と書いたが、何がそっけないのか書いていなかったので、具体例を1つ。

ERROR at line 271 ( org.apache.crimson.parser/V-036 box width )

これは、271行目にエラーがある。BOXエレメントのWidthエレメントがおかしいとのことだ。でも何が悪いのかまでは指摘されない。まぁ、今では「ああ、またやったか」と自分を責めるのだが、初心者にはかなりきつい、と私は思った。バージョン2ではこの辺も修正されるのだろうか?

修正して欲しいと強く願う。

修正を期待しつつも、こんなエラーも慣れればかわいいもので、初心者の方もちょいちょいっと直せるから安心して欲しい。要は「Syntax Error」みたいなものだ。

UJMLはXMLベースの言語だから、HTMLわかっていればちょっとしたプログラムも作れる。もしも、Javascriptもわかっていたらそれはすごいことだ何でもできそう。もちろん、難しいことにチャレンジするには、それだけ勉強が必要だが、それは他の言語と同じだ。日々学習あるのみ。初心者向けのまとめも作っていこうと思う。このブログでも比較的規模の小さいUJMLサンプルを公開するので参考にして欲しい。

ところで、ネット上を徘徊していたらUIEngineの初心者向けリファレンスを作っている方が既にいらっしゃったので、少し引用、

----
 プログラムというよりは、HTMLに近いので、結構、直感的じゃね?
 labelというタグを付けると、文字が書ける
 textというタグで文字の内容を決める
 HTMLが書ければできそう?
----

まさにその通り。(http://revilog.com/program/2006/01/006788.html