日本科学未来館へ行ってきた
こんばんは。KOBA789 です。今日は「日本科学未来館」へ行って来ました。小学校の遠足で行ったきりなのでだいぶ久しぶりです。
やはり建築の基本に抗って下部が狭く、上部が広くなっている形状の建物は面白くていいですね。内部の展示ももちろんですが、外から眺めていても飽きません。建物自体が1つの展示物のようです。
「インターネット物理モデル」
これ。マジ。
いや、ほんとすごいんですって。メカで(擬似)IP パケットをルーティングするんですよ。しかも、黒と白のボールを用いて 1bit を表す方式で(擬似)IP パケットをまさに手作業で構築して、送信できるんです。ちゃんとコード表も横に置いてあります。そのデータ(白と黒のボール群)はそのままコロコロとレールを転がっていくので、コードを覚えてしまえば流れているパケットを目視で読めます(最後の方は目が慣れてきてだいぶ読めるようになってました)。
また行きたい
合計すると2時間くらいその展示を見ていた気がしますが、まだまだ足らないのでまた行きたいです。日本科学未来館には年間パスポートもあって、1200円(新規・再入会時)と格安です(継続は1000円なので更に安い)。18才以下なら2ヶ月に1度、大人なら半年に一度以上行くと元が取れる計算なので、頻繁にパケットを眺めたい人にはおすすめです。
あと、メカニカルなルーターの構造に関して、光学センサーで先頭 1byte のアドレスを読んでることだけはわかったのですが、上流のルーターに流す部分とかあまりよくわからなかったので、今度行った時にスタッフを質問攻めにしたいところです。
以上、とってもおすすめな日本科学未来館ですので、パケットを眺める趣味がある人もそうでない人も、是非足を運んでみてください。
どうしてもObject.observeを使いたい場合
Object.observe とは
俺がダラダラ書くよりこちらを見たほうが素敵ですし、詳しいです。
次世代JavaScriptでデータバインディング： Object.observe() を試す - ぼちぼち日記
というわけで、使いたい。
上記の記事を読めば、とっても便利そうで、今すぐにでも使いたくなります。でもでも、実装されているのは V8 の ver.3.16.0 以降。最新版の Node.js v0.8.18 でも内蔵の V8 は ver.3.11.10 なので使えません(V8 のソース差し替えれば使えないこともない)。
"EXACTLY the same"なライブラリ
jdarling/Object.observe · GitHub
まさかなぁ、と思って検索したらありました。調べてみるもんですね。"Chromium build is MUCH faster"とのことなので、パフォーマンスを期待するのはお門違いですが、とりあえず処理系にネイティブ実装される前の逃げ道としては十分なんじゃないでしょうか。
ということで、これを使って TCP(というか WebSocket)経由でプロセス間でオブジェクトを共有するという何かをちょろっと書いてみようと思います。
JavaScriptのthis
どれがこれであれがどれだ。なんか JavaScript の this について揉めてるらしいので燃料投下することにした。これで何度目だよチキショー。早いとこ学習しやがれ。
this は4種類もない
this は1つだ。
「this はレシーバを指す」
これだけだ。
レシーバの指し方が複数ある
複数あるのはこっちだ。覚えておけ。
- receiver.method()
- method.call(receiver)
- method.apply(receiver)
- method.bind(receiver)()
- new Constructor()
上4つは見たままだ。一番下は少し特殊だが、新しく生成されたオブジェクトがレシーバになる。以下の様なコードを思い浮かべるとわかりやすい。
function Constructor () {} var receiver = Object.create(Constructor.prototype); receiver.constructor = Constructor; receiver.constructor();
ImageDataはCanvasImageSourceではない(そしてImageBitmapは未実装)
illustea 開発で問題になったことなど。
複数の ImageData を合成したい場合、愚直に for でコピーとかやると極端に遅いので、ネイティブの関数を使って高速化しようということになります。
ちなみに、CanvasRenderingContext2D#putImageData は領域すべてのビットマップを上書きするため、アルファブレンディングは行われず、望んだ結果にはなりません。
希望の結果が得られるのは CanvasRenderingContext2D#drawImage の挙動です。この関数は第1引数に CanvasImageSource 型のデータをとるのですが、ImageData は CanvasImageSource ではなく、直接描画はできません。そこで、CanvasImageSource である ImageBitmap は ImageBitmapSource をソースとして受けられ、ImageData は ImageBitmapSource であることから、ImageData を ImageBitmap に変換してから drawImage で描画することを考えます。
しかし、ImageBitmap は未だ実装されているブラウザがなく、使えません。
次回はこの問題を解決する方法を考えてみます。
illusteaという絵チャの開発をはじめた
環境の変化みたいな感じをきっかけにillusteaという絵チャの開発をスタートしました。
機能概要
当たり前のことですが、大切なこと。その他の機能についても検討中ですが、まだ決定ではないのでここには書いてません。
JavaScriptの実行速度でどこまでのことができるかは不明ですが、やれるところまで粘ろうかと思います。HTML5とかJavaScriptとかNode.jsとか大嫌いなんですけど、それらを使ってやります。マゾです。
開発に際して一番つらいことといえば、ブラウザごとにプリミティブな描画関数の描画結果が違うことで、つまり、getImageData/putImageData を使ってピクセル単位での操作を全て自前で書く必要があるわけで、それが一番つらいです。もちろん、ピクセル単位での合成なんてことまで全部自前でやっていては速度的に全く追いつけないので、表示差が出てもいい場合、またはブラウザ間の差異がない場合にはネイティブの関数で処理をしたり、あるいはその他の手法(DOMによる重ねあわせなど)を駆使する必要があり、この辺の選定にも気を使います。
また、開発に進展があればまとめていこうと思います。
2013年になりました
JSTに生きる方々は時を同じくして2013年を迎えたかと思います。こんな奴ですが今年もよろしくしてやってください。
2012年を振り返って
みんな書いてるみたいですけどめんどいので割愛。なんかいろいろあった気がします。
2013年の抱負
「鼻くそほじりながらアプリケーションをデプロイする」という夢を実現すべくあらゆる努力をしていきます。
とにかく、進学とか就職とか、受験勉強とか研究とか開発とかまぁいろいろ選択しやら進路やらありますが、俺のモットーは「極力怠けて死なない」ことなので、今年もそのとおりに生きようと思います。
CombConfという中高生しか発表しないITカンファレンスを主催してしまった #combconf
あけおめことよろ。人類滅亡にともなってクリスマスなんてものはない。ついでに CombConf2 なんてものもない。
さて、遡ること数日前、具体的には12月23日(日) 13:00-18:00(JST)、人類が滅亡している中、総勢70名ほどの非人類が集まって CombConf が開催されました。真面目な開催報告は公式サイトに掲載するので、ここでは裏話的なことを多めに。
発端
CombConf 自体の発端は去年の夏くらいなのですが、元となる構想については2年ほど前からありました。はじめは id:oidong1 の学校と交流できたらいいなー、なんてことを思ってました。で、そのまま話が流れて去年の夏、CombConf(零)の計画が動きました。参加校は3校。Twitter でお誘いしたら最終的に会場までお貸しくださった開成高校さんと、id:oidong1 の聖光学院さん、そしてうちの東京電機大学高等学校(長い)です。参加者数的には30弱ほど。場所は開成高校の実験室。それはそれで楽しかったのですが、「終わり際に第2回(というか第1回)もやりたいと思ってます!」とか俺が言っちゃって、帰り際に id:oidong1 と「次は一般人も巻き込んで公に参加者を募ろう」とか盛り上がっちゃって。まさかその場のノリの責任をマジで取ることになろうとは。
第1回、本格始動
真面目に第1回の準備が始まったのは9月末、うちの学校の文化祭が終わった直後でした。そのころはスタッフも俺と id:oidong1 の2人だけで、足らない頭を酷使してだいたいの構想を練りました。開催日や会場、名札の案やコンセプトなどはこのタイミングで決まりました。
id:yosida95 の参加
個人的にはこれが一番大きかったんじゃないかなとおもいます。
CombConf の運営スタッフは基本的に適当な場所のルノアール(渋谷、秋葉原、新宿)でミーティングをしていた、というのがまず前提条件。では id:yosida95 参加当日の話を。
まず、俺と id:oidong1 は id:yosida95 の学校である東京工業大学附属科学技術高等学校(こっちも長いな)の文化祭にCombConfの広報として来ていました。そして帰り際に「秋葉原のルノアールにいるから放課後来いよ」と声をかけ、俺と id:oidong1 は秋葉原へ。しばらくして id:yosida95 が現れ、俺が「CombConfってのをやってんだけどさ」「あーでこーでさ」と話をしたら、やれ「そうじゃねぇ」だの「あれはどうなってんだ」などとツッコミを入れてくるので、俺が「じゃあスタッフになっちゃいなよ」と言って Google Apps から id:yosida95 のアドレスを作成。wiki のスタッフ名簿にも追加して参加完了。
地獄のクローラー
さて、参加校を集めるためにはどうすりゃいいかと考えた結果、ブルートフォースしかないんじゃないかという結論に。というかレインボーテーブルだったのですが。
まず、レインボーテーブル(中高一貫校偏差値表)を持ってきて、そこから1校ずつ検索。部活紹介ページに「コンピュータ部」またはそれに準じる部活があるかどうかを確認し、wiki にまとめていきました。
さすがに3桁オーダーの数ですから、1人じゃ間に合いません。ここで @abcsharp (うちの部の副部長)が参加。スタッフが4人に。で、id:yosida95 以外の3人、3スレッドで検索し続けました。
なかなかおもしろい発見としては、女子校のコンピュータ部率が高いことでしょうか。まぁ、結局1校も来ませんでしたけど。
地獄の内職
地獄シリーズ第2弾。上のクローラーで集めた情報を元に、実際にその学校に案内状を郵送しました。この時の送料はなんと id:oidong1 の部活が部費から捻出してくれました(顧問了解済)。マジありがたい。
さて、内職というのはどういうことかというと、クローリングで集まった学校がちょうど100校ほどあるわけですが、それはつまり100枚の案内状を刷って、100枚のそれを折って、100枚の封筒に入れなければいれないということで……自動化できないんだよなーこれ。
宛名の印刷は id:yosida95 がプロプライエタリ・ソフトウェアでよしなにやってくれたので俺が書いた LaTeX -> PDF スクリプトは使われませんでした。やれやれ。
番外: 印刷屋
チーフという偉そうな肩書きを冠している俺ですが、実際の仕事は印刷屋です。
当日皆さんが首から下げていた名札、それに貼っていたタグステッカー、入り口で書いた記帳表、スタッフが配っていた名刺、すべて俺の印刷でした。名刺の印刷はガチでやったのでなかなかだと思います(熱い自画自賛)。
