Object.observeに関して(あと bind-unit とか)
先日
血迷って どうしてもObject.observeを使いたい場合 - Write and Run なんて記事を書きましたが、再びよくソースを呼んでみたら、setTimeout で polling してました。全然クールじゃない。まぁ、そんなもんだろうとは思っていたけれど。(もちろん、ネイティブ実装ではアクセスフックしてるので高速です。早く標準になれ)
そういえば先日、KOBA789/bind-unit · GitHub なんてものを作りました。こいつはプロパティの new, delete イベントこそ補足できませんが、update ならちゃんと補足できます。ついでに Array を監視する機能も追加予定なので、Object.observe の研究よりそっちを先にやろうかなーと思ってます。というか、今思えば EventEmitter のインターフェース実装する必要なかった気がする。(おかげでいろいろ面倒になってる)
日本科学未来館へ行ってきた
こんばんは。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年の抱負
「鼻くそほじりながらアプリケーションをデプロイする」という夢を実現すべくあらゆる努力をしていきます。
とにかく、進学とか就職とか、受験勉強とか研究とか開発とかまぁいろいろ選択しやら進路やらありますが、俺のモットーは「極力怠けて死なない」ことなので、今年もそのとおりに生きようと思います。