この間映画をプロヂュースしたので、ぜひ見てください。
予算の内訳とかあとで書くかもですが、社会人でも合間をぬってコンテンツがつくれるのかなーというトライアルです。
年1くらいでは続けていきたいです
タイトルは肉食女子。
現代社会の縮図とも言える肉食女子のサイエンスドキュメンタリーです。
いいかんじにくだらないので見てやってください。
]]>本日こんな記事を見つけて興奮したので、
http://www.asks.jp/users/hiro/59059.html
つい、やっちゃいました。
どうやら、人間は
390 名前:なまえをいれてください[sage] 投稿日:2009/05/08(金) 00:37:47 ID:Oqxr6eLt
こんちには みさなん おんげき ですか? わしたは げんき です。
この ぶんょしう は いりぎす の ケブンッリジ だがいく の けゅきんう の けっか
にんんげは たごんを にしんき する ときに その さしいょ と さいご の もさじえ あいてっれば
じばんゅん は めくちちゃゃ でも ちんゃと よめる という けゅきんう に もづいとて
わざと もじの じんばゅん を いかれえて あまりす。
どでうす? ちんゃと よゃちめう でしょ?
としても読めてしまうみたいなので、ツールというかプログラムにしました。
いそいで書いたので、そんなにきれいじゃないんですが
ぜひ遊んでみてください。
追記:
ぐは、なんかもうやられてる
http://blog.livedoor.jp/dankogai/archives/51210157.html

こんな面子ほかでは見られません。
しかも満員御礼。当日券まで完売の大盛況でした。みなさま本当にありがとうございました。

場所は、@niftyの運営するお台場のライブハウス、「東京カルチャーカルチャー」。
次代を作り上げるには、フツウの場所でフツウに勉強会している場合じゃないんです。
今回出演していただいた20代のエンジニアは、
例外なくみんな目が悪い。
しかし、平均視力0.1の彼らが見据える先にこそ、
ネットはどこまでも広がっている。平均視力は0.1、WEBエンジニアが見据える世界!「Web2.0 中の人ナイト」ライブレポート(2009.3.29開催)
平均視力よりももっと見てほしいことがある。
それは出演者の平均年齢だ。
出演者はほとんど80's。入社1~2年目のフツウの業界では「右も左もわからないペーペー」と呼ばれている若さだ。彼らみながサービスの第一線で活躍し、うん千万人の日々を支え、そして生活を豊かにし続けている。そう、「WWW」よりも若く、そして学生時代をケータイとともにすごした彼らの見ている地平は、Web2.0といった既存の枠組みを軽くとびこえる。
「webって常に進化して行くものだと思うんです。
だから、個人的には『2.0』も『3.0』も無くて、
webの進化によってみんなの生活が豊かになって行くこと。
これが大事なことなんだと思います」
そしてWebは進化し続ける。
それは、彼らが進化することをやめないからだ。
その他の感想はこちらから
]]>ひさびさの野望の会イベントです。
WWWが生まれて20年ちかくたちますが、このずっと起動しっぱなしだったWebというものを今一度、若い目線で見直してみようという一大イベントを開催します。オレンジや青の大手SNSをはじめ、誰もが知ってる大手ポータルサイトの歴歴の若手たちが一同に終結し、Webの今後を語り合います。そんなイベントを開催するにふさわしい場所が、コミュニティサイトの最長老niftyのお膝元である「Tokyo Culture Culture」というイベントホール。題して「Web2.0中の人ナイト」。
日時は3/29(日)

この浮ついた感もあるチープな名前と適度なサブカル臭が、日本野望の会の真骨頂なのですが、なかなかどうして今回はそうそうたる面々からのWeb業界の事情やライフスタイルなどがかんがみえます。
Web2.0とはなんだったのか。
Webの中、どうなってんの?
そろそろ再考してみてもいい時期かもしれません。
http://tcc.nifty.com/cs/catalog/tcc_schedule/catalog_090225201886_1.htm
チケットはe+から購入または当日券もございますyo
チケット残件わずか!となってしまいました。当日券は期待しないでe+からお買い求めください。
では!
]]>
この本は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アプリケーション設計の際にはこの仕組みが厄介に働くことがあります。
そういったケースでよく使用されるテクニックとしてはwindow unloadイベントへのハンドリングで、このページはすでに終端処理を済ませていますよ、ということを通知することで再度インラインjsや、onload後の処理を行うことができます。
だけではページ遷移後、戻るを押してもloadEventは発火されません。
しかし、
とすることで、「戻る」のあとにもonloadイベントは発火されるようになります。
これである程度の問題は解決するはずが、Safariなどの場合、このunloadを付与した場合のForm要素系のタグ、つまりinput,select,option,textareaなどの動作がおかしくなります。
input追加をクリックするたびに、innerHTMLをつかってinputタグが生成されるというケースを考えて見ましょう。

このときに、inputタグのvalueにユーザ入力によって値を設定します。

削除を押すと、inputタグがinnerHTML=""によってクリアされます。

さらに2つほどinputタグを生成して、再びユーザ入力によって値を設定します。

この後、何らかのリンクをたどって「戻る」という状態にすると、unloadが設定されているので、onloadEventが発火し一番最初の状態に戻ります。なので、Backforwardキャッシュ機構は停止されて、まったく最初と同じ状態になっているはずです。ところが、ふたたびinput追加をクリックしてinput要素を追加すると以下のように、いままでのユーザ入力のデータが保存された状態で現れてしまいます。

ちなみにinputタグはname属性やid属性もふられておらず、ただ同じような位置に存在するということだけでそのvalueがキャッシュされてしまっているようなのです。
これではJemplate/EJS/HTMLTemplate.jsなどのテンプレートモジュールを利用してElementの値を再構築するようなアプリケーションやinput hiddenなどで値をサーバサイドから提供するアプリケーションに深刻な不具合をもたらしてしまいます。
これはappendChildのみですべてのUIを実装するというかなりおそろしいやり方をするというのは、中規模以上のアプリケーションではかなり問題になります。ちなみにcreateContextualFragmentを用いてstringからHTML要素を生成する場合でもどうようにこのようなバグが発生します。
では、その対策にはどのような方法があるでしょうか。
まずぱっと思いつくのはそのノード自体をガベコレの対象とするためにremoveChildするような方法です。
ところが、このおせっかいキャッシュ機構のいやらしいところは、Elementがremoveされたとしてもvalueの汚染が続くということです。なので、Elementのremoveは効果がありません。
さらに、innerHTML=""などでclearされたElementはjavascript領域からは消えてしまうので取得することができないというやっかいさも抱えています。
このバグ(といっても差し支えないだろう)的なキャッシュ機構に対応するためには、そのページで生成されては消えていったすべてのinput系タグを、"戻る"後に生成されるElementとは異なるものであることをレンダリングエンジンに教えてあげなければいけません。
なので
のようにname属性を二度と参照されない値に変更することで、valueを汚染されることを防ぎます。
さらに、そのページで生成されては消えていったすべてのinput系タグを取得する方法として以下のような戦略をとります。
DOM Event Level2のMutation Eventの中でSafariで利用可能なDOMNodeInsertedを利用して、DOMに変化が生じるたびに"まだマークされていない"すべてのinputエレメントを取得し、キャッシュに保存しておきます。
最後にキャッシュされたすべてのエレメントのname属性を変更することで、このようなバグから開放されることとなります。
以下、これらをPrototype.js 1.60をベースに実装したものを晒しておきます。
ただ、これにも一部既知のバグが存在していて、innerHTML+=で発生するバグや途中でidやname属性を動的に変更されたElementなどをフォローすることができないのです。
しかし、いずれもjavascript的にはマナーの悪いこととされているのでコーディングルールなどでこれらのバグを避けるようにすることが得策かもしれません。
この記事の内容ははてなおよびJPCERT/CCに連絡いたします。
今しばらくお待ちください。
こういった危険性などについても
12/6 の講演で詳細を発表いたしますのでぜひおたのしみに。
思いっきり偏ったサンプルで恐縮ですが、、
このデータ構造を、YAML、ついでにJSONで書いてみたいと思います。
インデントだけで記述するスタイルは非常にシンプルですね。
もはや大分アタマがこんがらがってきましたが…
次の機会には各種実装からこれらを使ってみたいと思います。