カテゴリ：プログラミング
2007/06/22: Ruby.NET Compiler について
Ruby.NET Compiler ですが、C# などの言語との相互接続性（interoperability）を確立したようです。つまり、Ruby 上で C# で宣言したクラスのインスタンスを生成したり、C# 上で Ruby で宣言したクラスのインスタンスを生成したりできるようです。継承などがどうなるのかは試していません。
eval、パフォーマンス、日本語はどうなるのかなど、気になる点は多いですが、5 月には VS.NET 上での開発も実現しており、機能的には使えるレベルまできた気がします。
Rails を移植するつもりもあるようです。個人的には全然うれしくないですけど。長期的には意味があるかもしれませんが、向こう数年間では、.NET で Rails が動いてもそれほど意味がない気がします。Mono があるとはいえ動作する OS が制限される、gem は？、数々のプラグインは？、などなど心配事は尽きません。メリットがあるとすれば、ウェブインタフェース（オンライン処理）は Rails、バッチは C# というような使い分けかもしれません。
それに、Ruby はパフォーマンスがあまり良くないのでマシンを並列することも多いと思いますが、有料の OS はマシンごと or CPU ごとに課金することが多いので、そういう意味でも難しいと感じています。
個人的には、クライアントに可能性を求めて欲しいところです。ただ、.NET DLR の Ruby（IronRuby）との位置づけはどうなるのでしょうか。（処理系が増えること自体は、歓迎すべきことでしょう。）
（相反することをいうようですが、個人的には JRuby 上では Rails は動作して欲しいです。Kodougu を移植したいので。EMF とか使いたいものがたくさんあります。）
ま、今後に期待ということで。
eval、パフォーマンス、日本語はどうなるのかなど、気になる点は多いですが、5 月には VS.NET 上での開発も実現しており、機能的には使えるレベルまできた気がします。
Rails を移植するつもりもあるようです。個人的には全然うれしくないですけど。長期的には意味があるかもしれませんが、向こう数年間では、.NET で Rails が動いてもそれほど意味がない気がします。Mono があるとはいえ動作する OS が制限される、gem は？、数々のプラグインは？、などなど心配事は尽きません。メリットがあるとすれば、ウェブインタフェース（オンライン処理）は Rails、バッチは C# というような使い分けかもしれません。
それに、Ruby はパフォーマンスがあまり良くないのでマシンを並列することも多いと思いますが、有料の OS はマシンごと or CPU ごとに課金することが多いので、そういう意味でも難しいと感じています。
個人的には、クライアントに可能性を求めて欲しいところです。ただ、.NET DLR の Ruby（IronRuby）との位置づけはどうなるのでしょうか。（処理系が増えること自体は、歓迎すべきことでしょう。）
（相反することをいうようですが、個人的には JRuby 上では Rails は動作して欲しいです。Kodougu を移植したいので。EMF とか使いたいものがたくさんあります。）
ま、今後に期待ということで。
Posted by あかさた
2007/06/20: いまさら Rails の Scaffold
いまさら、Rails の Scaffold の話です。
コントローラの宣言時に以下のように書くと、アクション（メソッド）にモデル名をサフィックスとして追加してくれます。（edit なら、edit_model_name になります。）
便利ですね・・・。AdminController とか作って、一時的に各種データの出し入れの管理画面を作るときに使用しています。
そもそも、私は Scaffold はコード生成時にしか使っていませんでした。サフィックスをつけられるなんてことも知らずに今まで過ごしていました。なんて損していたんだろうか。(--;
コントローラの宣言時に以下のように書くと、アクション（メソッド）にモデル名をサフィックスとして追加してくれます。（edit なら、edit_model_name になります。）
scaffold :model_name, :suffix => true
便利ですね・・・。AdminController とか作って、一時的に各種データの出し入れの管理画面を作るときに使用しています。
そもそも、私は Scaffold はコード生成時にしか使っていませんでした。サフィックスをつけられるなんてことも知らずに今まで過ごしていました。なんて損していたんだろうか。(--;
Posted by あかさた
2007/06/03: FireFox で DOM ノードにグローバル変数としてアクセスできた
FireFox で、以下のような DOM ノードを含むドキュメント（下記は SVG）が存在するとします。
JavaScript で以下のように記述するとします。
すると、上記の g ノードが 表示されてしまうようです。FireFox からは、標準どおり document.getElementById でアクセスしてくれと怒られます。node_397 はローカル変数として別の場所で定義した（つもりだった※）のですが・・・。
※ これが原因で、Kodougu で、要素を作成した後関係線が作れなくなるというバグが発生していたようです。orz 後で修正バージョンを上げます。
JavaScript で以下のように記述するとします。
alert(node_397);
すると、上記の g ノードが 表示されてしまうようです。FireFox からは、標準どおり document.getElementById でアクセスしてくれと怒られます。node_397 はローカル変数として別の場所で定義した（つもりだった※）のですが・・・。
※ これが原因で、Kodougu で、要素を作成した後関係線が作れなくなるというバグが発生していたようです。orz 後で修正バージョンを上げます。
Posted by あかさた
2007/06/01: Google Gears でオフラインでも Web アプリが動作する
日々世相に疎くなっているような気がしますが・・・Google Gears というものが発表されて、世間の注目を集めているようです。Google Gears をインストールするとブラウザ（IE/Firefox）を拡張して、新しい JavaScript の API を提供してくれます。API には、ローカルにデータとアプリ（html と js）を保存する機能が含まれていることから、オフラインでも Web を使えるようになる技術として注目を集めています。
世の中全てがブラウザで済んでしまう時代が近づいていますね。Kodougu でも使えそうなので、少しわくわくしています。より簡単に対応できるように、Google Gears のプログラミング作法を調査しておきますかね。
とりあえず以下のような記事を見つけました。
【ハウツー】早速プログラミング! Google Gearsを使ったアプリを作ってみよう
(1) Google Gearsで使われている技術 | エンタープライズ | マイコミジャーナル
http://journal.mycom.co.jp/articles/2007/06/01/gears2/index.html
Google Gears・・・何かに似ていると思ったら、CodeGear に語呂が似ているんだ。こんな激動の時代に Delphi なんて生き残っていけるのかなぁ・・・。
世の中全てがブラウザで済んでしまう時代が近づいていますね。Kodougu でも使えそうなので、少しわくわくしています。より簡単に対応できるように、Google Gears のプログラミング作法を調査しておきますかね。
とりあえず以下のような記事を見つけました。
【ハウツー】早速プログラミング! Google Gearsを使ったアプリを作ってみよう
(1) Google Gearsで使われている技術 | エンタープライズ | マイコミジャーナル
http://journal.mycom.co.jp/articles/2007/06/01/gears2/index.html
Google Gears・・・何かに似ていると思ったら、CodeGear に語呂が似ているんだ。こんな激動の時代に Delphi なんて生き残っていけるのかなぁ・・・。
Posted by あかさた
2007/05/31: AB は HTTP1.0 クライアントとして認識される？
Apache のログを眺めていたら、AB（ApacheBench）のアクセスは HTTP 1.0 クライアントとして認識されているようです。このため、AB では、コンテンツ圧縮など HTTP 1.1 を前提にした処理は実行されない可能性があるため、正確には速度を計測できないかも・・・。（少なくとも、AB からのアクセスでは、mod_deflate は走っていませんでした。）
これ・・・私の勘違いですかね？？？
Kodougu のサーバは回線がしょぼい（10Mbps を数台で共有している）ので、結構重要な気がしているのですが・・・。
これ・・・私の勘違いですかね？？？
Kodougu のサーバは回線がしょぼい（10Mbps を数台で共有している）ので、結構重要な気がしているのですが・・・。
Posted by あかさた
2007/05/31: Apache ベンチマークを使って Web アプリケーションの速度を計測してみた
私は Kodougu について語るとき、いつも「重い、遅い」と言っているのですが、ベンチマークをとったことはなかったので、手始めに AB（Apache に付属するベンチマークソフト）を使って速度を計測してみることにしました。
実行したコマンド
計測したのは一番重くなると思われるモデリングツールを表示するページで、10 のコネクションで、合計 100 リクエストを送ることを試してみました。（もっとも、このベンチマークは、あくまでリクエストを送ってレスポンスを返すまでの時間を計測するものなので、たとえば、script タグで関連付けた外部 JavaScript ファイルの DL 時間などは計測できない・・・と思います。今は敢えてその辺を無視しています。）
ベンチマーク結果
サーバは Mongrel となっていますが、間に Apache Proxy が挟まっています。秒間 4.52 リクエストを処理することができるようです。これは、あくまで Web にあげているバージョンで、ローカルで動作させている最新版はさらに重くなっていて、この半分くらいの性能しか出ません。まだ分析していないので、回線、Web アプリ（Rails）、DB（MySQL）のどれがボトルネックになっているのかはわかりません。
まあ、ユーザが少ないうちは、この程度の処理能力でも問題ありません。でも、100 ユーザくらいが同時に使ったら、図を表示するだけで何十秒も待たされることになり、現実的に使えるものではなくなってしまいます。現在は、サーバは一台（CPU:Core2Duo/Mem:1GB）なので、サーバ台数を増やしていくという選択肢もありますが、アプリケーションだけでも 10 倍くらいは改善しないと使い物になりませんね。
機能拡張が落ち着いたら、パフォーマンス改善をしないとなー・・・。
実行したコマンド
ab -n 100 -c 10 http://www.kodougu.net/rendering/diagram/1
計測したのは一番重くなると思われるモデリングツールを表示するページで、10 のコネクションで、合計 100 リクエストを送ることを試してみました。（もっとも、このベンチマークは、あくまでリクエストを送ってレスポンスを返すまでの時間を計測するものなので、たとえば、script タグで関連付けた外部 JavaScript ファイルの DL 時間などは計測できない・・・と思います。今は敢えてその辺を無視しています。）
ベンチマーク結果
Benchmarking www.kodougu.net (be patient).....done
Server Software: Mongrel
Server Hostname: www.kodougu.net
Server Port: 80
Document Path: /rendering/diagram/1
Document Length: 24522 bytes
Concurrency Level: 10
Time taken for tests: 22.140625 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2479000 bytes
HTML transferred: 2452200 bytes
Requests per second: 4.52 [#/sec] (mean)
Time per request: 2214.063 [ms] (mean)
Time per request: 221.406 [ms] (mean, across all concurrent requests)
Transfer rate: 109.30 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 21 8.1 15 46
Processing: 516 2145 2189.3 1390 11765
Waiting: 421 2025 2163.7 1281 11640
Total: 531 2166 2188.7 1421 11796
Percentage of the requests served within a certain time (ms)
50% 1421
66% 2046
75% 2453
80% 2671
90% 5453
95% 7062
98% 10031
99% 11796
100% 11796 (longest request)
サーバは Mongrel となっていますが、間に Apache Proxy が挟まっています。秒間 4.52 リクエストを処理することができるようです。これは、あくまで Web にあげているバージョンで、ローカルで動作させている最新版はさらに重くなっていて、この半分くらいの性能しか出ません。まだ分析していないので、回線、Web アプリ（Rails）、DB（MySQL）のどれがボトルネックになっているのかはわかりません。
まあ、ユーザが少ないうちは、この程度の処理能力でも問題ありません。でも、100 ユーザくらいが同時に使ったら、図を表示するだけで何十秒も待たされることになり、現実的に使えるものではなくなってしまいます。現在は、サーバは一台（CPU:Core2Duo/Mem:1GB）なので、サーバ台数を増やしていくという選択肢もありますが、アプリケーションだけでも 10 倍くらいは改善しないと使い物になりませんね。
機能拡張が落ち着いたら、パフォーマンス改善をしないとなー・・・。
Posted by あかさた
2007/05/14: dojo をビルドしてみた
dojo は複数の JavaScript ファイルを一つにまとめることができます。
dojo は、dojo.require(名前空間名); というような書き方をすると、ダイナミックに JavaScript をロードしてくれます。しかし、個別のファイルをダイナミックにロードすると時間がかかってしまいます。そこで、ビルドしてファイルを一つにすると、Web ページの読み込みを高速化できます。（また、ダイナミックロード時は JavaScript がブラウザにキャッシュされていないようです。）
Kodougu を試された方はお気づきかもしれませんが、Kodougu は起動に数秒かかります。環境によりけりですが、起動時間のうち、JavaScript の DL 時間が 0.5 秒 から 5 秒程度かかっています。時間を計ったわけではありませんが、Kodougu では dojo に関するファイルを一本化するだけで八割方削ることができました。
以下、ビルド手順です。dojo 本家のリファレンスはこちらです。
■ 前提条件
JDK 1.4.2 以降（1.5 以降推奨）
Ant 1.6.5 以降
■ 手順
1. ソースコードのダウンロード
私が調べた限りでは、dojo の HP から DL できる Ajax Edition にはビルドスクリプトが含まれていませんでした。Subversion から チェックアウトしてください。
http://svn.dojotoolkit.org/dojo/tags/release-0.4.2/
（2007/5/14 時点での最新タグ）
2. hoge.profile.js の作成
以下のような Profile を作成します。ビルド時の依存関係を記述するためのファイルです。dependencies には、dojo.require(); で指定した名前を記述してください。
プロファイルは {{Dojo Dir}}/buildscripts/profiles においてください。命名規則（*.profile.js）を守ると作業が楽です。
3. ビルドの実行
{{Dojo Dir}}/buildscripts/ に移動して、以下のようなコマンドを実行してください。
dojo のリファレンスの「Including Non-Dojo Resources」を参照すれば、自作の JavaScript をビルドに含める方法もわかります。（dojo.provide() してやる必要がありますが・・・。）
以上、dojo のビルド手順でした。
dojo は、dojo.require(名前空間名); というような書き方をすると、ダイナミックに JavaScript をロードしてくれます。しかし、個別のファイルをダイナミックにロードすると時間がかかってしまいます。そこで、ビルドしてファイルを一つにすると、Web ページの読み込みを高速化できます。（また、ダイナミックロード時は JavaScript がブラウザにキャッシュされていないようです。）
Kodougu を試された方はお気づきかもしれませんが、Kodougu は起動に数秒かかります。環境によりけりですが、起動時間のうち、JavaScript の DL 時間が 0.5 秒 から 5 秒程度かかっています。時間を計ったわけではありませんが、Kodougu では dojo に関するファイルを一本化するだけで八割方削ることができました。
以下、ビルド手順です。dojo 本家のリファレンスはこちらです。
■ 前提条件
JDK 1.4.2 以降（1.5 以降推奨）
Ant 1.6.5 以降
■ 手順
1. ソースコードのダウンロード
私が調べた限りでは、dojo の HP から DL できる Ajax Edition にはビルドスクリプトが含まれていませんでした。Subversion から チェックアウトしてください。
http://svn.dojotoolkit.org/dojo/tags/release-0.4.2/
（2007/5/14 時点での最新タグ）
2. hoge.profile.js の作成
以下のような Profile を作成します。ビルド時の依存関係を記述するためのファイルです。dependencies には、dojo.require(); で指定した名前を記述してください。
var dependencies = [
"dojo.io.*",
"dojo.event.*",
"dojo.xml.*",
"dojo.graphics.*",
"dojo.io.BrowserIO",
"dojo.widgets.*",
"dojo.widgets.Button"];
load("getDependencyList.js");
プロファイルは {{Dojo Dir}}/buildscripts/profiles においてください。命名規則（*.profile.js）を守ると作業が楽です。
3. ビルドの実行
{{Dojo Dir}}/buildscripts/ に移動して、以下のようなコマンドを実行してください。
ant -Ddocless=true -Dprofile=kodougu clean release intern-strings strip-resource-comments
- Dprofile という引数にプロファイル名（*.profile.js の * の部分）を指定してください。
dojo のリファレンスの「Including Non-Dojo Resources」を参照すれば、自作の JavaScript をビルドに含める方法もわかります。（dojo.provide() してやる必要がありますが・・・。）
以上、dojo のビルド手順でした。
Posted by あかさた
2007/05/09: cometd を使ってみた
Kodougu で comet を実装する必要があるのですが、自分で実装するのもしんどいので、cometd を使ってみることにしました。
■ 注意
本記事は、cometd の trunk のヘッド（2007/5/7 時点）を参照しながら書いています。あなたが読んでいる時点で、本記事の情報が古くなっている可能性があります。
■ 環境
Windows XP SP2
■ 準備（必要なソフトウェアのインストール）
1. Python 2.4.4（インストーラあり、EasyInstall もインストールすべし）
Python Japan User's Group
※ EasyInstall のインストール方法は少し下のほうに記述してあります。
2. Twisted Python 2.4.0（インストーラあり）
http://twistedmatrix.com/trac/
※ 最新の 2.5.0 では、Twisted Web2 との互換性の問題で、正常に動作しません。
3. Twisted Web2 0.2.0 のインストール
http://twistedmatrix.com/trac/wiki/TwistedWeb2
python setup.py install
4. simplejson 1.7.1（EasyInstall でインストール）
http://cheeseshop.python.org/pypi/simplejson
easy_install simplejson
5. path 2.2
http://www.jorendorff.com/articles/python/path/
python setup.py install
6. cometd のインストール
6.1. cometd のチェックアウト
以下のアドレスからチェックアウトしてください。
http://cometd.googlecode.com/svn/trunk/
6.2. cometd-twisted フォルダ内の setup.py を書き換えてください。
data_files という項目を、「/etc/cometd」から「scripts」に書き換えてください。
6.3. setup.py の実行
python setup.py install
6.4. cometd.tac の編集
＜＜Python Install Dir＞＞\scripts\cometd.tac で設定（ポートやログファイルなど）を変更することができます。必要に応じて編集してください。
正直、Python に詳しくないと、きついと思います。私は Python にはまったく詳しくないので、この辺は結構きついです。わかりにくいところは質問してください。
補足：EasyInstall のインストール
x.1. 以下のファイルをDL
http://peak.telecommunity.com/dist/ez_setup.py
x.2. 以下のコマンドを実行
python ez_setup.py
■ cometd の起動
＜＜Python Install Dir＞＞\scripts フォルダ内で以下のコマンドを実行してください。
twistd -noy cometd.tac
補足：原因不明のエラー
私の環境では、＜＜Python Install Dir＞＞\Lib\site-packages\twisted\python\log.py の 228 行目をコメントアウトしないと、正常に動作しませんでした。原因については、現在調査中です。
■ dojo（0.4.2）からの呼び出し
Publisher/Subscriber モデルになっているので、簡単に使うことができます。以下におおよその使い方を書きますが、cometd の exmaples に dojo を使った例が豊富にあるので、参照しながら進めるようにしてください。
1. dojo.io.cometd の読み込み
dojo.require("dojo.io.cometd");
2. dojo.io.cometd の初期化
cometd.init({}, "http://127.0.0.1:8080/cometd")
※ 第一引数は、オプション設定。何が設定できるのかは不明。調査中。
※ 第二引数は、cometd サーバの URI。
3. 購読開始
cometd.subscribe("/channel/name", true, this, "acceptMethod")
※ 第一引数は、購読するチャンネル名。
※ 第二引数は、調査中。false にするとチャンネル名の先頭に "/cometd" が付加されるが何の意味があるのか・・・。
※ 第三引数は、メッセージ受信時のスコープになるオブジェクト（だと思う。。。）。
※ 第四引数は、メッセージ受信時のメソッド名。
4. メッセージの配信
cometd.publish("/channel/name", {name: "hoge"})
※ 第一引数は、配信先のチャンネル名。
※ 第二引数は、配信データ。
補足：IE、Opera で、Syntax Error が出る場合
以下のファイルの 510 行目に「}), }」というような記述がある場合、「})}」というように修正してください。私はこの修正で正常に動作するようになりました。
/dojo/src/io/cometd.js
補足：FireFox を使っている場合の問題
私の環境依存の問題である可能性がありますが、同一 PC 上で、FireFox クライアントを二つ起動以上したとき、publish したメッセージをクライアントで受け取ることができないという現象が発生しました。現在、原因調査中ですが、私は IE と FireFox など異なるブラウザであれば問題は発生していないので、テストはその組み合わせで行っています。
以上、cometd の使い方でした。
■ 注意
本記事は、cometd の trunk のヘッド（2007/5/7 時点）を参照しながら書いています。あなたが読んでいる時点で、本記事の情報が古くなっている可能性があります。
■ 環境
Windows XP SP2
■ 準備（必要なソフトウェアのインストール）
1. Python 2.4.4（インストーラあり、EasyInstall もインストールすべし）
Python Japan User's Group
※ EasyInstall のインストール方法は少し下のほうに記述してあります。
2. Twisted Python 2.4.0（インストーラあり）
http://twistedmatrix.com/trac/
※ 最新の 2.5.0 では、Twisted Web2 との互換性の問題で、正常に動作しません。
3. Twisted Web2 0.2.0 のインストール
http://twistedmatrix.com/trac/wiki/TwistedWeb2
python setup.py install
4. simplejson 1.7.1（EasyInstall でインストール）
http://cheeseshop.python.org/pypi/simplejson
easy_install simplejson
5. path 2.2
http://www.jorendorff.com/articles/python/path/
python setup.py install
6. cometd のインストール
6.1. cometd のチェックアウト
以下のアドレスからチェックアウトしてください。
http://cometd.googlecode.com/svn/trunk/
6.2. cometd-twisted フォルダ内の setup.py を書き換えてください。
data_files という項目を、「/etc/cometd」から「scripts」に書き換えてください。
6.3. setup.py の実行
python setup.py install
6.4. cometd.tac の編集
＜＜Python Install Dir＞＞\scripts\cometd.tac で設定（ポートやログファイルなど）を変更することができます。必要に応じて編集してください。
正直、Python に詳しくないと、きついと思います。私は Python にはまったく詳しくないので、この辺は結構きついです。わかりにくいところは質問してください。
補足：EasyInstall のインストール
x.1. 以下のファイルをDL
http://peak.telecommunity.com/dist/ez_setup.py
x.2. 以下のコマンドを実行
python ez_setup.py
■ cometd の起動
＜＜Python Install Dir＞＞\scripts フォルダ内で以下のコマンドを実行してください。
twistd -noy cometd.tac
補足：原因不明のエラー
私の環境では、＜＜Python Install Dir＞＞\Lib\site-packages\twisted\python\log.py の 228 行目をコメントアウトしないと、正常に動作しませんでした。原因については、現在調査中です。
# err()
■ dojo（0.4.2）からの呼び出し
Publisher/Subscriber モデルになっているので、簡単に使うことができます。以下におおよその使い方を書きますが、cometd の exmaples に dojo を使った例が豊富にあるので、参照しながら進めるようにしてください。
1. dojo.io.cometd の読み込み
dojo.require("dojo.io.cometd");
2. dojo.io.cometd の初期化
cometd.init({}, "http://127.0.0.1:8080/cometd")
※ 第一引数は、オプション設定。何が設定できるのかは不明。調査中。
※ 第二引数は、cometd サーバの URI。
3. 購読開始
cometd.subscribe("/channel/name", true, this, "acceptMethod")
※ 第一引数は、購読するチャンネル名。
※ 第二引数は、調査中。false にするとチャンネル名の先頭に "/cometd" が付加されるが何の意味があるのか・・・。
※ 第三引数は、メッセージ受信時のスコープになるオブジェクト（だと思う。。。）。
※ 第四引数は、メッセージ受信時のメソッド名。
4. メッセージの配信
cometd.publish("/channel/name", {name: "hoge"})
※ 第一引数は、配信先のチャンネル名。
※ 第二引数は、配信データ。
補足：IE、Opera で、Syntax Error が出る場合
以下のファイルの 510 行目に「}), }」というような記述がある場合、「})}」というように修正してください。私はこの修正で正常に動作するようになりました。
/dojo/src/io/cometd.js
補足：FireFox を使っている場合の問題
私の環境依存の問題である可能性がありますが、同一 PC 上で、FireFox クライアントを二つ起動以上したとき、publish したメッセージをクライアントで受け取ることができないという現象が発生しました。現在、原因調査中ですが、私は IE と FireFox など異なるブラウザであれば問題は発生していないので、テストはその組み合わせで行っています。
以上、cometd の使い方でした。
Posted by あかさた
2007/05/05: Web アプリとデスクトップアプリ
ここしばらく Apollo や Silverlight など、クライアントサイドの新技術が登場しています。Rails のブログを見ていたら、Slingshot という製品が紹介されていました。
Slingshot goes public
http://weblog.rubyonrails.com/2007/5/2/slingshot-goes-public
この製品は、Rails で開発したアプリを、オンラインでもオフラインでもシームレスに切り替えて使えるようにするもののようです。ただ、この製品が筋のいい製品かどうかはわかりません。コンセプトは納得できます。ネットがつながっていないと、Web アプリはまったく役に立たなくなるので、オフラインでも使える Web アプリができたら便利ですね。
ここしばらくのクライアント技術の傾向を思いつくままに上げてみます。
・ Web アプリとデスクトップアプリの境目をなくす（共通）
・ Web アプリとデスクトップアプリの技術的な隔たりをなくす（Apollo、Silverlight）
・ クライアント／サーバの技術的な隔たりを（割と）なくす（Silverlight）
・ アプリのインストールを意識する必要が無い
・ マルチプラットフォーム
・ 一応リッチになってきた（？）
究極的には、コードオンデマンドでインストールを意識することはなく、オンラインオフラインを意識することなく、Web / デスクトップを意識することなく、ブラウザの種類も OS の種類もデバイスの種類も意識することなく、アプリケーションというものは使えるようになるということでしょうか。
すばらしい夢の世界・・・といいたくなるところですが、IT エンジニアにとってはしんどい時代になりそうだなぁ。。。
Slingshot goes public
http://weblog.rubyonrails.com/2007/5/2/slingshot-goes-public
この製品は、Rails で開発したアプリを、オンラインでもオフラインでもシームレスに切り替えて使えるようにするもののようです。ただ、この製品が筋のいい製品かどうかはわかりません。コンセプトは納得できます。ネットがつながっていないと、Web アプリはまったく役に立たなくなるので、オフラインでも使える Web アプリができたら便利ですね。
ここしばらくのクライアント技術の傾向を思いつくままに上げてみます。
・ Web アプリとデスクトップアプリの境目をなくす（共通）
・ Web アプリとデスクトップアプリの技術的な隔たりをなくす（Apollo、Silverlight）
・ クライアント／サーバの技術的な隔たりを（割と）なくす（Silverlight）
・ アプリのインストールを意識する必要が無い
・ マルチプラットフォーム
・ 一応リッチになってきた（？）
究極的には、コードオンデマンドでインストールを意識することはなく、オンラインオフラインを意識することなく、Web / デスクトップを意識することなく、ブラウザの種類も OS の種類もデバイスの種類も意識することなく、アプリケーションというものは使えるようになるということでしょうか。
すばらしい夢の世界・・・といいたくなるところですが、IT エンジニアにとってはしんどい時代になりそうだなぁ。。。
Posted by あかさた
2007/05/03: .NET Framework と動的言語
最近、.NET の事情を追っかけていなかったので、今日は少し追っかけていました。最近、Java の世界では JRuby が盛り上がっていますが、.NET の世界でも動的言語の勢いがかなり強いようです。Jython や IronPython の開発者である Jim Hugunin のブログを読んでいたら、.NET における動的言語の取り扱いがなんとなく見えてきました。
Jim Hugunin's Thinking Dynamic
http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx
上記のブログで、私が気になった点を抜き出しておきます。
1. CLR（Common Language Runtime）について
上記のブログでは、CLR の利点を二つ挙げています。一つは、プログラミング言語を簡単に作れるようになったことです。これは、CLR が言語を作るうえで技術的に難しい点（GC だとか JIT だとかセキュリティモデルだとか）をすでに実装しているからだそうです。もう一つの利点は、異なるプログラミング言語をシームレスにつなげるようにもなったこととのことです。
2. CLR と DLR
IronPython で示したとおり、CLR は動的言語をよくサポートしています。さらに、CLR 上で動的言語を作りやすくするために、動的型システムなどを実装した DLR（Dynamic Language Runtime）というものを作るそうです。DLR の上で、Python、JavaScript、VB Script、Ruby を実装するそうです。
3. DLR と Silverlight
DLR は Silverlight にも搭載されるそうです。サーバもクライアントも Ruby で書けるなら、全てを Ruby に・・・と、夢のような世界が！
※ Silverlight とは、MS 版 Flash みたいなものです。
もちろん、DLR だけであれば、Java の世界にも似たような動きはすでにあったのでそれほど驚きはしませんが、Silverlight に乗っかってくるとは知りませんでした。（って、どれだけ世情に疎いんだ私は。orz）Kodougu を書いているときも、Ruby と JavaScript を行ったり来たりして最悪だったのですが、この世界が実現されればそういうことからも解放されそうです。
技術的なコンセプトはすばらしいので、後は政治的な理由から Linux は仲間はずれ（Silverlight は Mac の Safari にも対応するらしい）とかそういう馬鹿馬鹿しい現象がおきなければ良いのですが。。。
Jim Hugunin's Thinking Dynamic
http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx
上記のブログで、私が気になった点を抜き出しておきます。
1. CLR（Common Language Runtime）について
上記のブログでは、CLR の利点を二つ挙げています。一つは、プログラミング言語を簡単に作れるようになったことです。これは、CLR が言語を作るうえで技術的に難しい点（GC だとか JIT だとかセキュリティモデルだとか）をすでに実装しているからだそうです。もう一つの利点は、異なるプログラミング言語をシームレスにつなげるようにもなったこととのことです。
2. CLR と DLR
IronPython で示したとおり、CLR は動的言語をよくサポートしています。さらに、CLR 上で動的言語を作りやすくするために、動的型システムなどを実装した DLR（Dynamic Language Runtime）というものを作るそうです。DLR の上で、Python、JavaScript、VB Script、Ruby を実装するそうです。
3. DLR と Silverlight
DLR は Silverlight にも搭載されるそうです。サーバもクライアントも Ruby で書けるなら、全てを Ruby に・・・と、夢のような世界が！
※ Silverlight とは、MS 版 Flash みたいなものです。
もちろん、DLR だけであれば、Java の世界にも似たような動きはすでにあったのでそれほど驚きはしませんが、Silverlight に乗っかってくるとは知りませんでした。（って、どれだけ世情に疎いんだ私は。orz）Kodougu を書いているときも、Ruby と JavaScript を行ったり来たりして最悪だったのですが、この世界が実現されればそういうことからも解放されそうです。
技術的なコンセプトはすばらしいので、後は政治的な理由から Linux は仲間はずれ（Silverlight は Mac の Safari にも対応するらしい）とかそういう馬鹿馬鹿しい現象がおきなければ良いのですが。。。
Posted by あかさた