ニフニフ動画を見てみました。ニコニコ動画の劣化コピーです。ニフティがやるんだからもうちょっとましなものが出て来るんだと思っていましたが。

切込隊長BLOG（ブログ）: ニフニフ動画がネット諸氏に送る絶望より

何この脱力感。営業数字が上がらない営業マンを大声でドヤしつける管理職のそれではなく、数ヵ月後の資金繰りに思い悩む経営者が頭を抱えるタイプのダウナー系のインパクトを見る者に与えることにかけては、やはりニフティには一日の長がある。

あまりに秀逸なコメントに脱帽。そう、ニフニフ動画を語るにはこの脱力感が一番適当だと思います。画面を見た瞬間、「うわ、やる気ねぇ」って感じさせるのは、なかなか凄いことですよね。多分、急ごしらえのシステムで作りこみをしている時間が無かったんでしょうけど。

2007/6/14 2:36 時点でランキング一位が「すごいぜカスラック」（JASRAC をこき下ろした動画）というのもニフニフ動画を象徴している気がします。サイトコンセプトから何から何までパクリで構成されているという意味では、ニコニコの無法っぽさのさらに斜め上を行っています。この点において、むしろ褒めるべきなのかもしれません。

わずかにニフティのやる気（＝押す気満々の自爆スイッチ）を感じさせるのはこちらのページか。

いやいや、しばらくニフニフから目が離せませんねぇ。

追記（2007/6/14 3:18）。

でも、成功する可能性がゼロなわけではありませんよ。ニコニコは有料化で失速するかもしれません（※）し、ニフティなら最初からある程度集客できるかもしれません。Rimo と違ってニコニコとガチンコになるのは、かえって良いのかも。

※ 負荷を抑えるため、ニコニコでは、初期に登録したユーザー以外はアクセス制限がかかっていて、かなり不便らしいです。有料ユーザーになればいいのですが、お金を払いますかねぇ？

ようやく・・・というか、Kodougu の概要が未踏の公募結果のページに載りました。所属が前の会社のままだったり、書いてあることがちょっと胡散臭かったりしますが・・・。(^^;

ITPro の記事によると、Safari 3 のベータ晩が公開されていますが、Windows にも対応しているそうです。日本語など問題もあるようですが、Kodougu の英語版のみテスト対象に加えても面白いかもしれません。つーか、テスト対象に加えます。
# dojo.gfx とかまず動かなさそうですけど。

日本 Ruby 会議 2007 の Dave Thomas のスピーチが載っていました。すばらしい内容。こんなことをしゃべれる人間になりたいものです。こんなことなら行けばよかったな～。。。

さて、変なところに反応してみます。

日本 Ruby 会議 2007 の Dave Thomas のスピーチのログより

でも、あるプログラマに着目すれば、そのプログラマが時間あたりに書けるコードの行数は、プログラミング言語によらず決まっている、たとえば一日に50,000行なのだそうだ。

先生！　私は一日に 500 行も書けません！！
（Kodougu なんて 5000 行くらいで出来ています。）

えー、なんと言うかあれです。プログラマの生産性は少なくとも 100 倍は格差がある・・・と。私は自分が最底辺でないことを願っていますが（苦笑）。しかし驚くに値しないことです。私はピアノが趣味（20 年以上やってる）ですが、ピアノの初心者が 1 曲弾けるようになる間に、同程度の曲を同程度の品質で 10 ～ 50 曲くらいは習得できるでしょう。才能のある人なら、その数倍 ～ 数十倍になってもまったくおかしくありません。

要はそういうこと・・・なんでしょうねぇ。はぁぁ・・・。

■ 追記（2007/6/13 23:39）
一日に 50000 行ではなく、一年に・・・だそうです。ミスプリかな。ま、この手の数字は話のネタなので、そんなにまじめに考える必要は無いですよ。

でも、Ruby や Lisp で 50000 行も書いたら、世界征服できるんじゃないかって考えるのは私だけですかねー。（大袈裟）

2006 年度下期未踏ソフトウェア創造事業で開発している Web 上で動作するモデリングツール Kodougu の近況を書いてみます。

最新の Kodougu。IE/FireFox で動作。


(1) IE に対応
動作がかなり重い、まだバグバグであるという問題はありますが、これまでは FireFox 1.5/2.0 のみだった動作環境に IE6/7 が追加されました。未踏開発期間中（2006/11 ～ 2007/8 末まで）では、Opera 9.2 への対応を考えていますが、IE/FireFox が基本的なプラットフォームとなります。

(2) 操作性の改善
図上で要素を選択して Delete キーを押すと要素を削除できますが、これまでは、キーを押しても動作したりし無かったりという問題がありました。現在は解決されています。また、Shift キーを押して要素を選択すると複数個の要素が選択できます。

(3) サーバのパフォーマンス改善
図のページを開く際、サーバサイドでは、秒間 2 リクエストも処理できなかった（つまり、一つのサーバで秒間 2 枚図を開けなかった）のですが、秒間 5 ～ 6 枚はいけるようになりました。

(4) デモサイトの作成
現在作成中です。以下からアクセスできますが、現在は英語のみ、いつデータが消されるかわからない、かなりバグバグという問題があるので注意してください。

Kodougu.net（現在、英語のみ）
http://www.kodougu.net/

FireFox で、以下のような DOM ノードを含むドキュメント（下記は SVG）が存在するとします。

JavaScript で以下のように記述するとします。

alert(node_397);

すると、上記の g ノードが 表示されてしまうようです。FireFox からは、標準どおり document.getElementById でアクセスしてくれと怒られます。node_397 はローカル変数として別の場所で定義した（つもりだった※）のですが・・・。

※ これが原因で、Kodougu で、要素を作成した後関係線が作れなくなるというバグが発生していたようです。orz 後で修正バージョンを上げます。

日々世相に疎くなっているような気がしますが・・・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 なんて生き残っていけるのかなぁ・・・。

Apache のログを眺めていたら、AB（ApacheBench）のアクセスは HTTP 1.0 クライアントとして認識されているようです。このため、AB では、コンテンツ圧縮など HTTP 1.1 を前提にした処理は実行されない可能性があるため、正確には速度を計測できないかも・・・。（少なくとも、AB からのアクセスでは、mod_deflate は走っていませんでした。）

これ・・・私の勘違いですかね？？？

Kodougu のサーバは回線がしょぼい（10Mbps を数台で共有している）ので、結構重要な気がしているのですが・・・。

私は Kodougu について語るとき、いつも「重い、遅い」と言っているのですが、ベンチマークをとったことはなかったので、手始めに AB（Apache に付属するベンチマークソフト）を使って速度を計測してみることにしました。

実行したコマンド

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 倍くらいは改善しないと使い物になりませんね。

機能拡張が落ち着いたら、パフォーマンス改善をしないとなー・・・。

左側のメニューの下のほうに日本地図があると思います。これは、なかのひとというブログパーツです。アクセス解析ツールの一つなのです。特徴としては、「どんな組織の人がアクセスしてきたのか」に特化していることです。

仕組みとしては、whois 情報を元に、経度緯度に変換、地図上に表示とのことです。

よく、この業界では「××のなかのひと」という表現をしますが、まさにこのツールはどこのなかのひとがアクセスしてきたか調べるためのものというわけです。一日で開発出来てしまいそうなツールですが、アイディアが面白いのでしばらく使ってみます。

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(); で指定した名前を記述してください。

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 Dir}}/release/dojo/dojo.js が生成されます。このファイルに、全ての JavaScript が含まれます。

dojo のリファレンスの「Including Non-Dojo Resources」を参照すれば、自作の JavaScript をビルドに含める方法もわかります。（dojo.provide() してやる必要がありますが・・・。）

以上、dojo のビルド手順でした。