本 日 の h o g e

■ [JS][日記] Pyコードシューター を改造

相変わらず chrome でしかまともに動かないと思うけど．

• システムをゲームっぽくした
• 自機や敵を画像にした
• 音を出せるようにした
• 弾幕パターンを増やした

音は最初 Web Audio API を使おうかと思ったのだけれど，どうも反応が遅いのと，ループ時の繋ぎ目に無音時間が長く入ってしまうので HTML5 Audio で出すようにした． HTML5 Audio でも繋ぎ目を知覚できてしまうのだけれど，Web Audio API と比べたら雲泥の差． まあ，やり方が悪いのかも知れないけれど．

それにしても，使わせて貰った素材が良いからか，画像とか音とかがあるとかなりそれっぽくなるね．

ちなみに僕はデフォルトパラメタだとどんだけ運が良くてもスコア 20 万点くらいがせいぜいでした． 自分で作っておきながらムズすぎ... まあ割と運ゲーなので速攻で死ぬ時もあれば粘れる時もあるという感じ．

感想とか意見とかあれば貰えるとこれ幸いです．

■ [Tips] rrd ファイルをアーキテクチャの異なる別ホストに移す

パスフレーズなし鍵認証で ssh 開けてこんな感じのワンライナーでも書けば良いんじゃない．

bash$ find RRD_DIR -type f -name '*.rrd' | while read file; do dir="$(dirname $file)"; rrdtool dump $file | ssh -C -c blowfish SENDTO_HOST "[ -d '$dir' ] || mkdir -p '$dir'; rrdtool restore - $file"; done

dump した xml でかいしファイル数多いと掃除とか色々めんどくさいし．

主に munin とか cacti とか smokeping とか使ってる人用．

■ [日記] あけました

おめでとうございました．

今年も来年から本気出す精神にて邁進して参りますのでどうぞよろしくお願い致します．

■ [戯言] ひとりごと

ハードウェアは陳腐化するのだと人の云ふ．

その通りだけれど，陳腐化するのはハードウェアだけじゃあない． ソフトウェアも，サービスも，理論だって陳腐化する． 極論を言えば，昨日つくられたものは今日陳腐化している．

暗号の 2010 年問題などは良い例だ． 暗号強度はその解を導くためにかかるコストをよりどころにする． しかし計算機の性能向上によってそのコストは年々減っていく， つまり何もしなくても暗号強度は弱くなっていくということになるのだ．

技術は日々進歩しているし，市場ニーズなど環境が変わっていくのに， 変わる前に作られたものが陳腐化しないなんてことがあるはずもない．

「ソフトウェアより上は柔軟にその形を変えられる」 ここに大きな罠がある． 基本設計を逸脱した仕様を取り込むのはなかなかに難しく， 下手にやってしまうと， 優れたものを一瞬にしてダメにしてしまうことがある． これはその規模が大きければ大きいほど起きやすいと思う．

諸々の都合でやらざるを得ないということは往々にしてある． 「めんどくさい」「お金がない」「早く欲しい」などなど． しかし，やるならやるで，それなりの覚悟をもってやらないといけない． その時には分からなかった問題が後から次々に発覚するなんてこともあるだろうし，それが足枷となって拡張不能に陥ったりすることもあるだろう． 「めんどくさい」から既存のものにちょちょいと手を加えるだけで流用したはずが，そのせいで余計に「めんどくさい」ことになることもあるのだ． 基本設計を逸脱するというのは，そういう可能性を孕んでいるということだ．

そんなことが起こらないように努力するのも我々のようなエンジニアの仕事のうちだ． だけど，ある時点での環境，考え方，予測等に基づいた基本設計が，現在の環境，考え方，予測等と合っているだろうか，とまず思わないといけない． そもそも設計段階，いや企画段階から，「これからつくるものは最長でも○年しか使わない」ということを考えておかなきゃいけない． そしてその EOL 時点で別の「その時の環境，考え方，予測等に合ったもの」に乗り換えられるようスケジューリングしなきゃいけない． このサイクルを正常に回せるようにならなきゃいけない． これは決してハードウェアに限った話などではない．

もちろん，少しずつ姿形を変えたりしながら，何年も何十年も使い続けられた，使い続けられてきているものも存在する． これらは基本設計というか思想みたいなところが非常にコンパクトになっていて，変な要件は拡張とかレイヤとかで何とかしろよ，というような形になっている． こういったものを考えつくりだすことがエンジニアにとって目指すべき至高の仕事なのだけれど，まあそう簡単にできたら苦労はない． それにこれらも世界中のエンジニアの血と汗と涙によって支えられて存続できているのだ．

名前は同じでもその時の環境に合わせて基本部分からごっそり変わりもはや別物になった (でメジャーバージョンアップした) というものも多い． 例えばインターネットは IPv4 が考案された当初，アドレス空間は 32bit で充分だったのだろう． しかし環境が変わった (普及しまくった) ため，128bit アドレス空間を持つ IPv6 へ移行しなければならなくなっている．

環境が変わればものも変わる，変わらざるを得ない，変われなければ死ぬ． この当たり前のことを

(省略されました... 続きを読むにはわっふるわっふると書き込んで下さい)

■ [小ネタ] Visualization & Sonification/Auralization

うんこを流す計画その 4．

こないだ Web Audio API をいじって遊んでいたのは，別に MML もどきを作りたくてのことではなくて，巷に溢れている適当なデータを感覚器に訴える何かに変換したかったから．

「可視化」は語るに及ばずだけれど，「可聴化」というのも情報工学的な研究分野として 10 年以上前から存在する． 可視化は Visualization と言うけれど，可聴化は Sonification とか Auralization とか言う． 可視化に比べて可聴化がマイナーなのは，視覚情報よりも聴覚情報のほうが更に曖昧だとか難しいとか効果を測定しづらいとかそういう理由で注目されにくいからかなぁと個人的には思う． 聴覚情報はどちらかというと主に感情に訴える情報のように思えるし．

公開できるような状態にないのでコードやサービスを公開してはいないけれど，実は以前，遊びで ネットワーク可視化を HTML5 canvas の上でやってみた ことがある． これは単純に libpcap でキャプチャしたデータを WebSocket 経由で随時配信し，クライアント (ブラウザ) サイドでリアルタイムにグラフ化していく． こんな感じ にサーバサイドでキャプチャしたデータをクライアントに送りつける形になっていて，サーバがそのまま WebSocket クライアントになることもできるのでツリー型の分散構成を取ることも (ブラウザから直接到達性のないネットワークの可視化も) できる． まあ，要は EtherApe の Web 版，分散版だ．

そんでまあ課題はいくつかあるものの一通り意図通りグリグリ動くところまで出来たのだけれど，だんだんグリグリ動くだけなのに飽きてきたので，今度は音でも鳴らしてやろうかと思ってしまった次第． それが 以前の日記 の元だったわけです．

Sonification/Auralization をまとも (?) に実装したのは初めてで方法論的なものが全く分からないので，とりあえず，

1. IPv4 アドレスをオクテット単位に分割
2. 各オクテットを 6 倍する (つまり 0 〜 1530 になる)
3. プロトコル番号 6 (TCP) であれば音色を弾くような，それ以外なら笛のような音に設定
4. 2. で作った 4 つの数値を周波数に見立て，波を作り，和音として合成
5. IPv4 ヘッダの total_len フィールドを使い，ゲインを log(total_len+1) / 7 に設定 (つまり 0 〜 1.6 くらい，データリンクがイーサなら 1.1 以下になる)

こんな感じで作った波を src → dst で繋げて鳴らしてみた．

結果はというと，音なので直接さっくり伝えることができないのがもどかしいのだけれど，まあ酷いもんで，とにかくうるさくてしょうがない． サーバにログインして top とかしてると 2 秒毎にソナー音． 動画サイトにでも行こうものなら，src/dst が同じパケットが大量に現れるので，なかなかの耳レイプっぷりを発揮する．

その昔 ネットワーク監視を音楽で行う という研究があったようだけれど，この域に達するにはまだまだ考慮が足りないなあという感じ (この研究も実用域なのかどうかは知らんけど) でしたとさ．

というところで，ネットワークを Visualization & Sonification/Auralization して遊ぶのも飽きてきたので，次は別のデータを扱おうと画策している次第． ネタはとりあえずいくつかあるのでまあ何かまとまったらまた何か書くかも．