どうもひろきのだいちです。
水野さん。ありがとう。こんないい本を訳してくれて。そしてくれて。

この本はJavaScriptの世界を一段押し上げるためのものです。きっとJGPとか略されたり、蝶本といわれたりとしてこれからJavaScriptの世界でスタンダードとなる概念を構築するための本になるんだろうなと。その意味では仕事でJavaScriptを読む人間に必携の本となるだろうし、この本を「読む」だけではなくて「理解」することが必須となる本となるだろう。
しかし、これはPerlの世界で言うところ「Perl Best Practices」的な書籍ではないということも理解してほしい。
というのもまだ、JavaScriptの世界はPerlほど成熟していないからだ。
この本は「use strict」「use warnings」のための諸概念を切り出すという段階を担っているものであり、
JSLintはその外部実装といったほうがいいのだろうか。
これが荒唐無稽な著者の挑戦でないことは彼がすでに「JSONの規格化」に成功していることからも伺える。
次の段階を考えてみよう。
良いものと悪いものの線引きはできた。
ではその次は悪いものの使いどころと悪い性質の避け方だ。
Perlには「no strict」「no warnings」が用意されていて、悪い面をライブラリユーザに見せずに清潔なプログラミングを可能にしている。
newの何がわるいの?
newはjavascriptのクラスシステムの根幹を担うところであり、使わないという選択肢はなかなか難しい。
すべての機能をmethod chainの中に隠蔽してしまうという方法論もあるにはあるが、DOMありきのプログラミングモデルならまだしも、それ以上のものを考える場合には必要最低限の機能である。
なにが悪いのかといえば次のようなケースである。
hogeはコンストラクタなのに、new演算子を伴わないで呼び出された場合にfunctionにbindされているthisかあるいはトップレベルオブジェクトに対して汚染をしてしまうケースがある。
これは確かに致命的だ。
ひとつはコーディングルールの中にClass名をHogeのように先頭をcapitalizeするという方法論だ。
もうひとつはコンストラクタ中でチェックルーチンを入れるという方法論。
あるいは、
こういった機能の柔軟性を封じるやり方もできる。
本書に出てくるnewをFunctionオブジェクトのmethodとして実装するやり方もエレガントだけど、
もうすでにnewがあるんだからライブラリ作成者なりが注意しておくか、レビューをしっかりすれば問題ナッシングだと思う。
JavaScriptからは関数のスコープで定義されるActivation Objectに直接アクセスすることができない。
これはここらへんを読んでもらうとして。
たとえば、Globalオブジェクトをできる限り汚染しないようにして、ネームスペース的機能を提供しようとした場合に
これは適切なnamespace機能さえjavascriptに用意されていれば済む話だが、withが強力な機能を提供する場面でのひとつだ。
evalはあらゆる言語で悪者だ。
パフォーマンスを下げてしまうし危険を伴うと紹介されることがおおい。
これに関しておおむね同意した上でもなお、evalを利用することが適切な場面が存在する。
これは皮肉なことにむしろパフォーマンスの分野で。
Webクライアントの技術において、パフォーマンスとはユーザエクスペリエンスのために存在する。つまりユーザがある動作(クリックなど)を行ってから何らかのアクションが発生するまでの時間を最適化したいというニーズが最も多い。
なので、
のようなプログラムがあったときに
のようにしておくことで、DOM構築完了後からimageロードまでの比較的余裕のある時間でスマートな関数を構築しておくことができる。
こういったテクニックは邪道ではあるが、effects.jsなどでも用いられている高速化テクニックの1つであって、JavaScriptというインタラクションのために用いられる言語では重要な要素になりうる。
あくまでもミッションクリティカルな場所でのみ使われるべきではあるが、Templateエンジンなどを実装するためにはevalという邪悪な手段が最適最良のスマートな方法になる。
function文とfunction式の違いは、Activationオブジェクトの生成タイミングを理解しておけば間違えることは少ないだろうが、解釈の違いにより問題が起こることは確かにある。
これらは同値であると説明される場合が多いが以下のようなケースで違いが発生する。
function文は自動的にスコープの先頭に移動して解釈されるが、function式は解釈されない。
これ自体は小さな問題に見えるが、さらにif文内でのfunction文の巻き取りはjsの実装によって異なりポータビリティを損なうというのが本書の指摘するところだ。
たしかにこれらはポータビリティや保守性を下げる場合がおおい。
しかし、function文がデバッグ性にプラスの要素を与える場合が実はある。
function文によって作られた関数は処理系内部において"公式な名前"を得ることができる。
公式な名前がある関数は、それが他の関数ではなくて自分自身であることを証明することができる。
この仕様を正式なものとしてなにかプログラムを書くことを推奨はしないが、
この要素が煩雑なプログラムの中で問題箇所を適切に見つけることのできる一因になることがあるということは覚えておいて損はないだろう。
functionは式であれ、文であれこの"公式な名前"をつけられるという性質を知っていると
プロファイル等で
複数の無名関数の中から、問題の箇所をわずかな変更ですぐに知ることができるかもしれない。
これらはfunction文ではなく、function式であるのでスコープのオブジェクトを汚染することはない。
公式に運用するscript中では無用なものではあるかもしれないが、こういった性質によって見えてくる世界もある。
・JavaScript Good Partsは仕事でJavaScriptを書くすべてのエンジニアが必読の書である。
・読んだ後、汚いもの/悪いものがどのように使われるべきか考えてみよう
・きれいな世界と汚い世界を分けることでJavaScriptはもっと輝きを増す。
2008年の野望会は新年会にはじまり、忘年会に終わる…
野望会おなじみの居酒屋ライトニングトーク、全員自己紹介、
今回もやります。奮ってご参加ください。
参加表明はこちらからお願いします。
http://atnd.org/events/218
パワポです。すこし長いので、はしょりながらやります。
普通に前半のほとんどはフロントエンドの技術を理解している人なら当たり前すぎる内容ですが、
研究会が比較的バックエンドよりなので、こういう話もやってもいいかなと。
あ、
野望イベント近日公開です。
興味のある方はぜひこちらのブログをチェックしてください。
slideshare --
どうもひろきのだいちです。
最近のモダンなブラウザには、Backfowardキャッシュと呼ばれるブラウザの戻るボタンを押した際に利用されるキャッシュ機構が用意されています。この機構は普段ウェブブラウジングを行う際には間違った操作からの復帰が早く非常に重宝するのですが、一部のWebアプリケーション設計の際にはこの仕組みが厄介に働くことがあります。
どうも、ひろきのだいちです。
ソーシャルブックマーク研究会で講演をいたしますので、
ぜひいらしてください。
この記事の内容ははてなおよびJPCERT/CCに連絡いたします。
今しばらくお待ちください。
こういった危険性などについても
12/6 の講演で詳細を発表いたしますのでぜひおたのしみに。
おひさしぶりです。へたれのこみや(pinkmac)です。
YAMLとは何かを今更知ったので、覚え書きしておきます。
折角なので他のデータ形式もいっしょに見直してみることにしました。
思いっきり偏ったサンプルで恐縮ですが、、
このデータ構造を、YAML、ついでにJSONで書いてみたいと思います。
(more...)
こんにちは、ひろきのだいちです。
JavaScriptの再発見からさらに2年がたち、モダンなWeb開発では欠かせない存在となったJavaScript。さまざまなライブラリが乱立し、言語としての基礎を得ないままでもある程度のアプリケーション開発ができるようになった現在。
再入門JavaScriptと題して、中上級者を目指すために入門書を超えてじっくりとJavaScriptを学びなおすことが重要だと考え、ここを中心にまとめていきたいと思います。
ここで掲載するトピックは本当の基礎の基礎は他の媒体にゆだねた上で、「仕事でつかえる」レベルのコードを記述するために重要で比較的高度なものを取り扱うつもりです。
また、ここでいう仕事で使えるとは"多人数で開発を進める"ことを前提とした開発環境を想定しており、他サイトのAPIの使い方やライブラリの使用方法といった枝葉のリファレンスではありません。
また、ここに書かれていることはたいてい僕のメモなので、責任はもちませんw
おこんばんわ。ひろきのだいちです。
今日は、再入門JavaScriptと題して、Perlなどのサーバサイドの言語になれている方に向けて、
JavaScriptにおける大規模開発の勘所として重要な名前空間の実現方法の解説と、
それらを簡単に提供するライブラリJS.Namespaceを作成しましたので、そのドキュメントを織り交ぜてご紹介します。
JavaScriptを仕事で利用される方や、ライブラリのコピペのような書き方から一歩進みたい方に向けて記述しています。
サーバサイドにおいては、フレームワークなどの汎用的に使われるライブラリやプラグイン機構などでしか目にすることが
あまりないモジュールの動的ロードですが、クライアントサイドのようにユーザインタフェースと直結したプログラミング環境においては
動的ローディングは重要な技術です。
Perlにおいてコンパイルフェーズ以外でモジュールのロードを行いたい場合、UNIVERSAL requireを用いることが多いです。
JavaScriptにおいて動的ローディングを行うためには2つの方法があります。
ひとつはDOM操作によってscriptタグを埋め込む方法で
もうひとつはXML.HTTPRequestによって取得したTextをEvalする方法です。
動的ロードの縛りとして、
* 確実に終了と例外を補足できるXHRのみでのダイナミックロードに限定する
* urlでなく完全限定名を引数としてそれをファイルパスに自動変換した場所のファイルを取得する
* 内部でそのモジュールが作成されている
をもうけることで安全な動的ロードを提供する。
Perlの場合、Exporterなどの仕組みを使えば
のように記述するだけで、Current Packageにそれぞれの関数を貼り付けることができます。
あるいは
のように、完全限定名(Full Qualified Name)でアクセスすることでもその名前空間上のメソッドを利用することができます。
jsの場合では完全限定名を利用すれば同じように利用することができます。
一方、Exporterのように現在のスコープに貼り付けるにはwithブロックを使います。
しかし、withの動作をしっかり把握できない場合にwithを多用することはjavascriptのプログラム作法からは
推奨されません。
そのかわりに一時的にその名前空間をテンポラリな変数に別名をつけて利用することもできます。
どちらも、問題なく動作します。
JS.Namespaceライブラリではこれらの利便性を考えて
などの記述を可能にします。
またネームスペース自体に追記がなく、use XXX qw(hoge)のようにただ関数やオブジェクトを利用するだけの場合
このように記述することができます。
jsには予約語としてnamespaceが定義されているけどブラウザじゃ使えませんし、Rhinoなどの一部の処理系を除いて、意味を成さないんですが、var namespace = hogehoge;みたいな記述は避けてください。