あかさたの最近の仕事

• ゲームを作れるウェブサービス - Rmake
• ブラウザ上で動作するモデリングツール Kodougu
  
• 作品間の関係を追跡するシステム - コピトレ（ブログはこちら）

2008-04-03 11:27 : クライアント（ブラウザ）もサーバも同一言語で書ける haXe を使ってみる

---

八角研究所にて、クライアント（Flash, JavaScript）とサーバ（NekoVM）で動作するコードを出力するオブジェクト指向プログラミング言語 haXe を紹介する記事を書きました。

続きを読む

---

2008-01-27 01:22 : JavaScript 使っている人なら、AIR に関する記事ならお勧めがあるよ

---

いまさら聞けないAdobe AIR「超」入門（1/4）- ＠IT は「AIR とは何か」を知るには良い記事なっているようです。ただ、JavaScript を使っている身としては、Flex Builder を使えば・・・という開発環境はちょっと面倒です。

JS 使いなら、クジラ飛行机さんが書かれている AIR に関する連載「八角研究所 : JavaScript使いのためのAIR入門(1)」の方が身近に感じられるかもしれません。オフラインアプリや jQuery との連携など JS 使いにとって実践的な内容が紹介されています。

などと、勝手に宣伝してしまっていいのだろうか。
ToDo：「後で了解を取る」

---

2007-12-18 14:04 : dojo 1.0 が出たから Cometd のインストール方法の整理と使い方へのポインタを書いた

---

cometd を使ってみたという記事で、dojo 0.4.2 + cometd のセットアップ方法を記述しました。dojo 1.0 が出て、多少状況が変化したようなので、Kodougu で行った作業をもとに cometd のセットアップ方法を整理して掲載します。

続きを読む

---

2007-12-10 17:15 : Kodougu の dojo を 0.4.3 から 1.0.1 にアップグレードした作業をまとめてみた

---

Kodougu で使っていた dojo を 0.4.3 から 1.0.1 に上げました。0.4.x から 0.9 の段階でドラスティックに変わっていたので、Kodougu の JavaScript は 3000 行に満たないのですが、移行にかなり手こずってしまいました。

まだ、運用環境にはアップロードしていないのですが、大半の機能は動くようになったので、作業ログと感想を載せておきます。

作業環境：Firefox で移行作業を完了させてから、 IE での確認。

■ 疑問と感想
(1) イベント系について
イベント系が dojo._base に組み込まれたのはなぜでしょうか。個人的には従来の名前空間（dojo.event.browser）でもいいかなと感じました。それとも、よく使うものだから dojo 本体に入れ込んだのかな・・・？

(2) dojo.io.bind について
敢えて specific な構造（従来は dojo.io.bind という抽象的なメソッドだったのが、dojo 1.0 では、iframe や XMLHTTPRequest などのプロトコルごとにメソッドが準備されている）に変更されたのは・・・まぁ、なんとなく理由はわかりますが、従来の「とりあえず bind」でもよかったかなという気もします。

(3) dojo.io.FormBind が無くなった
また、dojo.io.FormBind がなくなったのが痛かったです。dojo.io.FormBind は、既存の Form の Submit ボタンが押されたイベントを拾って、Ajax 方式でリクエストをサーバに送信してくれるクラスです。

対策としては、Dojo の Form には、Form の Submit ボタンを押すと実行される OnExecute というイベントがあります。Form.execute というメソッドをオーバーライドして、ここで、xhrPost（Ajax）を送信するようにしました。このため、Rails の Form といまいち相性が良くありません（※）。もしかすると、Form 系は Rails を使わずにすべて dojo でやってしまうのも手かもしれません。Kodougu では、Rails で Form の外枠だけ作って、あとから dojo の Form 系 Widget を生成しています。

※ dojo 使っている時点で、Rails の Ajax 系ヘルパーをそのまま使うことはあきらめるしかないのですが。そのうちだれかが何とかしてくれるでしょうけどね。

(4) 感想
0.4.3 から 1.0.1 と、かなり隔たりのある更新作業だったので、正直大変でした。それでも、感覚としては、「ドラスティックな変更の割には、今のところ互換性による影響はそれほど出てない」と思います。（一番困るのは、「××が廃止されたから○○はできません」みたいなことが起こることですが、それはありませんでした。）dojo もいろいろな意味で品質が上がってきたのかもしれません。

dojo.collections -> dojox.collections のような変更が続くなら、バッドノウハウであるコンストラクタをラッピングするだけの Factory を作りたくなりました。ま、作らないと思いますけど。

続きを読む

---

2007-12-05 15:40 : DojoX に含まれる Dojo Strage は Google Gears をラッピングしているらしい

---

今、Kodougu の dojo を 0.4.3 から 1.0.1 に上げる作業をしています。その過程で見つかったちょいネタです。DojoX に含まれる Dojo Strage は Google Gears をラッピングしているそうです。夢が広がるなぁ・・・。

例：

dojox.storage.put("someKey", "someValue");

SQL 直打ちも可能：

var results = dojox.sql("SELECT * FROM DOCUMENTS");

情報元は The Book of Dojo です。
http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojo-offline/storing-offline-data

■ 追記（2007/12/5 15:48）
以下から読み始める方が、理解が深まります。
http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojo-offline

---

2007-11-28 16:46 : Dojo UML なんてあるんだな

---

via Dojo/JavaScript Toolkitのメモ

Dojo UML（リンク先は結構重いので注意） というものがあるみたいです。Kodougu と同じく Dojo Toolkit を使っているそうです。Web 上でベクターグラフィックスなんて結構楽勝な時代になったってことか。

---

2007-11-10 13:56 : dojo.gfx(dojo 0.4.3) が IE で遅い件について改善にトライした

---

ここしばらく、Kodougu の IE における高速化を行っていました。これまで、Kodougu の IE 対応は機能カバー率こそ 100% であるものの、速度は Firefox の 1/10 以下という非常に舐めた状態でした。機能カバー率は 50% 程度であるものの Opera 対応の方が実用性が高いかもしれません。

私が IE というものを分かっていないせいだろうと思っていたのですが、どうも調べれば調べるほど、dojo 0.4.3 の dojo.gfx が怪しいということになってきました。（dojo 1.0 が出た時点でやたら古いものを使うなって話ですが。）そこで、 dojo のどこが遅いのか調査してみることにしました。

続きを読む

---

2007-08-09 15:47 : そんなこと言っちゃったら Web 系なんてねぇ・・・

---

私は、マークアップエンジニアという言葉は知りませんでしたし、ぶっちゃけ CSS で盛り上がる世界が存在しているということも理解できませんでしたが、以下のエントリの言わんとしていることは賛成です。

ただ、一つ違和感がありました。

IT戦記 - マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開）より

(X)HTML + CSS しか出来ない人はそれなりに危機感を感じたほうがいいと思った今日の昼ご飯でした。

JavaScript をごりごり書いている私が言うのもなんですけど、そんなこと言っちゃったら、Web 系エンジニア全体が微妙な気が・・・。CSS がバッドノウハウの塊で、極めるほどの本質的な奥行きがないなら、JavaScript もある意味同じ気がします。ぶっちゃけ「ブラウザ上なのにこんなことできて凄い凄い！」という世界ですからね。(--;　VC なら凄くねぇ！

# デモ、VC ノホウガムツカシイあるヨ。

つまり、私が感じている違和感は、本質と表層の捉え方なんだと思います。

http://twitter.com/amachang/statuses/191263472 より

「CSS 道」は道が短すぎるんだ。マーケティングの為に長く見せてるけど、実際覚えることは少ない。「デザイン」か「JavaScript」を職業に出来るくらいにしとかないとヤバいと思う。

私としてはデザインと JavaScript を同列においているのが少し気に食わないわけです。本質的な奥行きを持つデザインと、表層的な奥行きしかない JavaScript で比較するなんて。JavaScript のノウハウの少なくない部分は、言語が改善されれば（あるいはフレームワークやライブラリによって）消えゆく「べき」ものです。CSS ハックの大半がブラウザ（主に IE）の改善とともに消えゆくように。本質的な奥行き感で言えば、デザインと UI プログラミングくらいなら、結論として納得感があるんですけど。

# 絵のセンスがない私にとっては、絵描きさんやデザイナさんは尊敬の対象です。

UI に関係するプログラミング言語の変化はめまぐるしいです。つい最近まで主流だった VB も Delphi も Java + Swing も生き残っているとは言いがたいです。変化の激しいこの世の中で、JavaScript だって長く生き残るかどうかはわからないわけですよ。Ajax や Comet だって、本質的な部分には非常に奥行きがあるわけですが、表層に限って言えばあまり言うことはないわけです。近頃は Ajax.Request とか dojo.bind とか書けば Ajax してくれますから。

でも、UI に関係するプログラミングは実に奥が深いです。下手な書き方をするとすぐにメンテ不能やテスト不能（VB や Delphi のフォームみたいに）に陥ります。また、ユーザが直接触る部分ですから、工夫の余地は無数にあります。これらは、言語によらない本質的な難しさであり、価値です。

もちろん、今使っているプログラミング言語に精通することは大切です。でも、IT の世界は歴史が浅く道具の変化が激しいので、本質的なスキルは何か見極めていかないといけないんじゃないかなと思います。CSS の後に JavaScript では・・・あまりにも短期的な視点で食っていくためというのがアリアリ。そりゃ、食わにゃ死にますが、長期的かつ本質的なスキル開発を促しても良いんじゃないかな？、と思いました。

あ、でも、本エントリの言わんとしていることには賛成です。第二の何かは、Rails している人も、PHP やっている人も、JavaScript をやっている人にも、等しく必要なんだってことです。Java している人にもね！

以下、余談。

○ 余談１

とはいえ・・・C/C++ 言語の世界は変化が少ない・・・というか、変化はしているのだろうけど、プログラミングそのものが奥行きを持っている気がします。対象領域の違いから来るものでしょう。C/C++ だってアプリの世界なら同じ問題を抱えていると思います。

○ 余談２

スタンドアロン（Delphi + VCL でも Java + Swing でも VB でもいいけど）の世界を知っていると、HTML + CSS + JavaScript（＋LAMP）が、意外と理にかなっていて面白い世界なのが良くわかります。Web 系技術が凄くないと連呼する人はいるけど、また、私もそう思うけど、これまでのやり方よりは優れているんです。個別に見ると新しい技術はなくても、組み合わせて使うと新しいみたいな感じです。
実際、Kodougu（Ruby on Rails + JavaScript で実装されたブラウザ上で動作するモデリングツール）は、Java + Swing や C# + Windows.Forms で実装された同系統のソフトよりもはるかに短いコード（＝メンテしやすい）で実装できています。やはり、Web 2.0 のときに技術的にも何かが起こったんだなって感じます。「気づき」のあるなしとか些細なことなんですけど。

---

2007-07-26 13:15 : JavaScript で波○拳を繰り出すことはできるか？（「お知らせ:「コナミコマンド」を実装しました」を読んで）

---

「お知らせ:「コナミコマンド」を実装しました」によると、コナ○コマンドはできるらしいです。コードを見てもらうとわかりますが、if 文で普通に分岐しています。これはこれでお手軽な実装ですが、こういうものを見ると一般化してみたくなります。

上記サイトより抜粋：

var konmaiFlag = 0;
function konmaiCommand(konmaiKey){
	if (konmaiKey == 38 & konmaiFlag == 0){//上
		konmaiFlag = 1;
	}else if (konmaiKey == 38 & konmaiFlag == 1){//上
		konmaiFlag = 2;
	}else if (konmaiKey == 40 & konmaiFlag == 2){//下
		konmaiFlag = 3;

キーの配列を受け取ったら実行してくれるクラスがあると便利ですよね。特に以下のような書き方ができたら楽しいですね。

// 上、上、下、下、左、右、左、右、b、a
var keys = [38,38,40,40,37,39,37,39,66,65];
var processor = new KeyCommandProcessor(keys, onSuccess, onError);

作成してみました。以下にサンプルページ＋全ソースコードがあります。
キー入力サンプルページ（IE/Firefox）

でも、上記の実装だと、波○拳を繰り出すことはできません。なぜなら、複数のキーの同時押しができないからです。この手の実装はゲーム開発者にとっては当たり前のものだと思いますが、馴染みがないとなかなか難しいです。ス○２の波○拳の場合、下、下右、右、パンチです。私の記憶が正しければ。ここでは、↓、↓→、→、A を実現するようにします。とりあえず以下のような書き方をしたいものです。

// 下、下右、右、a
var keys = [40,[40,39],39,65];
var processor = new KeyCommandProcessor(keys, onSuccess, onError);

作成してみました。以下にサンプルページ＋全ソースコードがあります。ポイントは入力したキーを複数個持つことです。prototype.js とか使って配列を操作する機能を強化すれば、半分くらいのコードで書けると思います。でもまぁ、ここまで来るとあまり、手軽なものにはなりませんね。
キー入力サンプルページ（IE/Firefox）

実は現時点でも結構手抜き実装（格闘ものならもっとキー操作は厳密にする方が良いです。）ですが、ずいぶん進歩した気がしますね。上記のコードは全てパブリックドメインです。かなりバグがあると思いますが、適当に料理してやってください。

---

2007-07-24 21:09 : Kodougu で Kodougu の設計を書いてみた

---

Kodougu の機能をアップロードしたので、Kodougu を使って Kodougu の設計を書いてみました。モデリングツールのデータモデル（いわゆるメタモデル）ではなく、メタメタモデルの部分です。関連が折れ曲がっていますが、線を折る機能はまだ実装していません。以下の図では裏技で実現しています。本機能の実装をお待ちください。

多重度はテキストで表現しています。近いうちにメタモデルを整備して関連で実現できるようにします。

Kodougu に以下の機能を追加しました。
(1) 図の凍結機能（図を編集不能にする機能）
詳しくはマニュアルをご参照ください。

図を凍結したKodougu


Metaelement のインスタンスは、UML でいうところの Class, Usecase などです。Metaattribute は値型の属性（整数や文字列）、Metareference は参照型の属性を表します。Metaattribute の例は Class 名です。Metareference は、Package が複数の Class を持つような場合を表現するために利用します。

Metanode はそのモデルの表記を表現します。多重度が複数になっているのは、一つの Metaelement が複数の表記を持っている場合があるからです。たとえば、UML のインタフェースには、ロリポップと分類子表記（矩形表記）があります。

うーん、まだまだ表現能力不足です。

---