はてなスターのユーザー名をCSSだけで強引に表示

なんとなくブログの見た目を少しいじった(テスト前になると部屋を片付けたくなるアレ)。
シングルカラムだと横に間延びするのは前から気になってたので、max-widthを1000pxで設定して、あとフッターをシンプルに。

で、はてなスターってデフォルトだとマウスを乗せるまで誰のだかわからないのが気になってて、自分ではGreasemokey Scriptでユーザーのアイコンに置き換えてるんですが(hatena big profile star)、そういうことをしてない多くの人はが並んでいるだけで、わかりにくいなーと。
ってことで、装飾してやろうと思ったけど、CSSだけだとやはり厳しい。まあ、IEを考えなければ(IEだと普通の表示のまま)ってことで、afterとか使って強引にIDを表示してみた。
CSSはこんな感じ(ネガティブなtext-indentとoverflow:hiddenというよくあるバッドノウハウ)。

span.hatena-star-star-container a[href^="http://d.hatena.ne.jp/"]:after{
  font-size:11px;
  color:#666;
  content:attr(href);
  display:inline-block;
  overflow:hidden;
  text-indent:-11.5em;
  font-family: "Consolas", "Inconsolata", "Menlo", monospace;
}

追記:リンク先がはてなダイアリー以外だと残念なコトになるのにも対策した
で、こんな感じに。

おっと、グリモンが効いてた。

IEも8-9で標準モードを強制すればちゃんと見える。Operaはちょっと変…。
しかし、有料オプションでもいいからDOCTYPEの選択ができるようになってほしいな。

2011年のJavaScriptとかなんとか

昨年に続いて、新春特別企画：2011年のJavaScript ─ウェブアプリ全盛の時代へ｜gihyo.jp … 技術評論社を書きました。
去年、当たったら(自分が)面白いよねくらいな気持ちで書いた「拡張」とか「サーバーサイドJavaScript」が見事に的中してて驚きました。特にNode.jsブームはすごいですね。
ってわけで今年は、Node.jsのどこが注目されているのかを書きました。あと、それに呼応してBigPipeにも言及。BigPipeはid:brazilが東京に来たときの飲み会で@kzysに教えてもらった。確かにかとーさんはいつも良いネタ持ってる印象があるなあ。

そういえば、今年の後半は色々忙しくてブログにあんまり書いてなかったけど、DeNA Technology Seminar #3 : ATNDでJavaScriptの未来みたいな話をしました。この時も@kzysが来ていた。@h_kishiのHTML5@iPhoneゲーム開発でCanvasは遅いとされていた件について、

@os0x: canvasが遅いのではなく(速くはないけど)、iPhoneのCSS AnimationはGPU使って速くしてるから差が出るって話だった気がする。canvasでもGPU使われるようになればその差はなくなるはず。 #denatech

2010-11-15 19:59:41 via web

と発言したんですが、これについて懇親会で@kzysからCanvasのGPUってほんとに効果あるんですかと的確なツッコミが…。去年IEのPlatform PreviewでCanvasにGPUを効かせることで高速化したってデモが公開されたことで、CanvasもGPUで高速化するって印象がありますが、実際のところCanvasでGPUの恩恵を得られるのはdrawImageを呼ぶところくらいしかない(IEのデモはでっかい画像をdrawImageしまくるという露骨なデモ)ので、GPU入っても大抵のCanvasは全然変わらないというか、むしろ遅くなりかねないくらいです。。なので、上の発言は確かに誤解があるかなと…。
まあ、Canvas+CSS Animationで頑張っているところを、CSS Animationの代わりにGPUパワーのdrawImageにしてCanvasで統一するくらいはできそうですよってことです。

あと先月はHTML5とか勉強会でFile API話をしました。File System API周りについてのプレゼンは、日本初どころか世界初との言を b:id:vantguarde より頂きました。

連載：これでできる！ クロスブラウザJavaScript入門｜gihyo.jp … 技術評論社のほうも順調(?)に回を重ねています。しばらくUIの実装を色々書いてみようと思います。

MacをJavaScriptの開発環境にするメモ

以前は自宅も仕事もWindowsメインな環境だったんですが、仕事の方がでMac+英語キーボードな環境になり、ついでなので自宅もそれに合わせることにしました。
環境はMac miniの最新型で一番安いの(6月くらいに購入)とMacbook Airのやっぱり一番安いの(11月に購入)です。両方合わせて15万くらい。お手頃…なのか？どうでもいいけど、mac miniは1.3kgしかなくて、Macbook Airの13インチとほぼ同じ重さだっりします。miniデスネー。
ついでにWindowsのほうは2年半前に買ったCore2duo(Windows7アップグレード済み)で、当時そこそこハイエンドだったやつです(ちょうどMac miniと同じくらいのスペックだけどこいつは一体何kgあるんだろう…)。
以下、Macの開発環境をなるべく最近の流行りを取り入れてレポートします。

ブラウザ

さて、マシンのセットアップで最初にすることといえば、もちろんブラウザのインストールですよね！ とりあえずスタンダードにChrome、Opera、Firefoxを入れておきます。
ChromeはChrome Release Channels - The Chromium Projectsからdev、beta、stableの各バージョンがそれぞれダウンロードできます。ダウンロードしたファイルを実行するとGoogle Chrome.appが出てきます。通常はこれをアプリケーションフォルダに放りこめば良いのですが、JavaScripterとしてはそれぞれのバージョンを同時に使いたいので、一工夫します。まず、アプリケーションフォルダに適当にディレクトリを作ります(Chromesとする)。その中にさらにdev、beta、stableとさらにサブディレクトリを作ります。で、それぞれのディレクトリにGoogle Chrome.appを保存します。これで一応各バージョンを起動することはできますが、プロファイルが共有されているの同時起動できませんし、バージョン違いでプロファイルを共有すると色々と問題がでます(というか、起動できないこともある)。というわけで、プロファイルを分けましょう。Chromeのプロファイルを分けるには、起動オプションの--user-data-dirでプロファイルの場所を指定してあげればOKです。ただ、Macは起動オプションを指定するのが少々面倒で、こういうときにAppleScriptが活躍します。アプリケーションの中のユーティリティの中にAppleScriptエディタがあるはずなのでそれを起動し、以下のコードをコピペしてください。

do shell script "/Applications/Chromes/beta/Google\\ Chrome.app/Contents/MacOS/Google\\ Chrome --user-data-dir=/Users/$USER/Library/Application\\ Support/Google/ChromeBeta > /dev/null 2>&1 &"

パスは適宜調整してください。これを実行すると、beta版のChromeが立ち上がると思います。動くのを確認したら.appとして保存しましょう。保存場所はアプリケーションの中などにして、ファイルフォーマットをアプリケーションにしましょう。これで.appファイルとして保存されます(ただ、この方法で起動したChromeをDockに追加すると、追加されるのはChrome自体であってAppleScriptではないのでご注意を)。
Firefoxもバージョン違いを共存させる方法は大体同じで、Firefoxの場合は起動オプションの-p(profile)と同時起動のための--no-remoteをやはりAppleScriptにしておくとよいでしょう。

システム環境設定

(だいぶ脱線しましたが、)つづいてシステム環境設定まわりを見ていきます。まあ、好みが大きいところなので、大事なところだけ触れます。
まず、「言語とテキスト」で入力ソースを開き、「入力ソースのオプション」を「書類ごとに異なるものを使用」にしましょう。これでブラウザはIME ON、コンソールではOFFと使い分けできるようになります。これがないと死にます(これに1ヶ月くらい気がつかなかった…)。
あと、「キーボード」の「キーボード」の右下にある「修飾キー」で、Caps Lockの割り当てをControlなどにしておくのがオススメです。また「キーボードショートカット」のほうで「フルキーボードアクセス」を「すべてのコントロール」にしておくとタブキーでボタンにもフォーカスできるようになるので、これもオススメです(OSの設定ですが、多くのブラウザもそれに従います)。
あとは、アカウントでまず左下の鍵アイコンをクリックして鍵を解除し、自分のアカウント名のところでControl+クリック(もしくは右クリック)して詳細オプションを開きます。ここでターミナルのログインシェルを変更できます(私はzshに)。

裏:システム環境設定

Secretsの PrefPane( Secrets_[バージョン].zip)をダウンロードしてSecrets.prefPaneを実行するとシステム環境設定のその他の項目にSecretsが追加されます。このSecretsはいろんなアプリケーションの隠しオプションを設定できるツールで、画面キャプチャ時のファイルフォーマットをPNGなどに変更できたり、Finderで非表示属性のファイルを表示するようにできたりします。他にもいろいろありますが、自己責任なのでご注意を。

基本ツール

Finder

Finderの環境設定の「詳細」で、「すべてのファイル名拡張子を表示」にチェックを入れておきましょう。

Google IME

ATOKユーザーでないならGoogle 日本語入力を入れておくと良いです。設定は特に弄らなくても大丈夫だと思います。

KeyRemap4MacBook

英語キーボードだとIMEのON/OFFが面倒です。そこでKeyRemap4MacBookで左⌘を単独で押したときは半角英数モードに、右⌘を単独で押したときは日本語入力モードに切り替えるように設定します。設定方法はキーボード操作をもっと便利に! KeyRemap4MacBook オススメ設定からどうぞ。

エディタ

ベーシックなエディタとしてはCotEditorがオススメです。文章を書くときはCotを使っています。vimなひとはMacVimを入れておくとコンソールからも使えて便利です。他の候補はTextWranglerとかでしょうか。あと、JavaScripterとして、も気になるところですね。FirefoxなひとはXULで出来てるKomodo Editとかが気になるところでしょうか。

Windowsとの連携

Windowsも同時に使いたいので、以下にしてスムーズにMacとWindowsを使い分けるかが重要な課題です。

Synergy

まずは定番のSynergyです。私の場合、モニタを2個並べて右をWindows、左をMac miniにしていて、Windows側でマウスを画面左に持って行くとそのままモニタを抜けてマウスポインタがMac側に移動するようになっています。
設定方法などは複数の PC を手元で操作 「Synergy」を使おう! -Win&Mac 混合対応版- - livedoor ディレクターブログが参考になります。
ただ、キーボード周りが今一つで、私の環境だとシングルクオートとダブルクオートの入力がおかしくなるという問題があります。というかMacとWindowsのキーは結構違うので仕方ないところも大きいんですが…。

リモートデスクトップ

もうひとつの選択肢はMacからWindowsへのリモートデスクトップです。MicrosoftからRemote Desktop Connection Client 2というアプリが出ていて、これがかなり高性能です。特にKeyRemap4MacBookで設定したキーも認識してくれるのがポイントで、前述のIMEの切り替えがWindowsでも効きます。その他も色々とよきに計らってくれる感じで、かなり快適です。今のところMacbook Airからリモートデスクトップで使うことが多いですが、Mac miniもリモートデスクトップにしようかと検討中です。

コンソール

さて、いよいよ開発環境らしくCUI周りを見ていきます。なお、前述のとおり私は今までWindowsをメインでやっていたので、CUI環境にはかなり疎いです。突込みどころと思ったら是非突っ込んで頂けると助かります。
MacのデフォルトコンソールはTerminal.appですが、256color modeをサポートしてなかったりと機能的に物足りないので、MacのコンソールといえばiTermが定番のようです。特に最近はiTerm2がいい感じみたいです(ただ、iTerm2は自動アップデートの通知の度にフリーズするという現象が起きているので、自動アップデートには注意)。

パッケージマネージャ

MacのパッケージマネージャといえばMacPortsが定番ですが、最近はhomebrewが人気…なんですが、あえてMacPortsを選びました。
homebrewが人気な理由は、MacPortsはデフォルトで入っているパッケージを使わずにすべて自前でコンパイルするから重い、それに対してhomebrewはデフォルトをそのまま使うので軽いというのが主な理由(あと、homebrewのほうが新しいので各パッケージのバージョンも最新に近いのもメリット)みたいなんですが、MacPortsも昔はデフォルトのパッケージを使っていたけどMacのバージョンが変わったときに問題が出るから自前でコンパイルするように切り替えたという経緯があるそうです。というわけで、homebrewも同じ道を歩む可能性が高そうです。ただ、結局MacPortsもOSのバージョンが上がったときに問題が出ることがあるみたいで、環境の再構築に時間が短くて済むhomebrewのほうが良いかもしれません。どっちに転ぶかとりあえず様子見ということで、今回はMacPortsを選びました。
MacPortsのインストールはThe MacPorts Project -- Download & InstallationからSnow Leopard用のdmgを落としてインストールするだけです。

2011/10/20追記：その後、homebrewに切り替えました。homebrewのほうが使い勝手が断然良いので、もはやMacPortsに戻れない感じです。Lionへのアップデートもhomebrew自体は全く問題ないですね。

screen

今時はtmuxかtscreenらしく、MacPortsからインストールできるのはtmuxなので、tmuxにするという安直な判断に…。

sudo port install tmux

して、

cp /opt/local/share/doc/tmux/screen-keys.conf .tmux.conf

でscreen互換なキーバインドになります。ただ、zshのC-aはよく使うので、やはりC-tが無難だと思います。まあ具体的な設定はtmux.confでググって色々参考にしてみるのが良いと思います。

coreutils

折角iTerm2にtmuxなので、カラフルにしたいよねってことで

ls --color=auto

とかしてみるとそんなオプション対応してないと怒られます。代わりに-Gで色は着くのですが、配色がしっくりこないんですよ。というわけでcoreutilsをいれます。coreutilsはBSD系のOSでLinux系の基本コマンドを使えるようにするユーティリティ集です。ls以外にもLinuxとの互換性があがって、同じドットファイルを使いやすくなるのでオススメです。

sudo port install coreutils

ただ、coreutilsで入るコマンドにはprefixでgが付いています。なので、aliasで

alias ls='gls -v --color=auto'

のようにしています。aliasの一覧など詳しくはMint's log: Macportsのcoreutilsコマンド群はなんでも「g」から始まるをどうぞ。

vim

Mac OSXでのvim環境整理。.vimrcやらオヌヌメPlug inやらまとめ。 - ( ꒪⌓꒪) ゆるよろ日記を参考に、MacVimを使うようにします。

export EDITOR=/Applications/MacVim.app/Contents/MacOS/Vim
alias vi='/Applications/MacVim.app/Contents/MacOS/Vim "$@"'
alias vim='/Applications/MacVim.app/Contents/MacOS/Vim "$@"'

iterm，tmuxのおかげで256色で使うのに特に設定は必要ありません。あとはいい感じのcolorschemeを頂いてくればOKです。ただ、colorschemeはカラースキーマ — 名無しのvim使いとかにいっぱいあるけど、どれがいい感じかわからなくてどうしたものかと思ってたんですが、idのバリエーションが豊かな方がおすすめしていたir_blackに決めました。ir_blackはいろいろ凝ってて面白いですね。ただ、ちょっと凝り過ぎな感じもするので、様子見て h2u_black.vim に落ち着くかも。
ちなみに、その他のdotfileは主にid:cho45のdotfileを参考にさせていただいています。まだよくわかってないところが多いので自分のは公開してません。

git

sudo port install git-core

でインストールできる…はずですが、(おそらく)XCodeインストールしてない状態だとJavaがなんとかと言われてエラーで止まります。そのメッセージにURLが書いてあるとおり、Java Developer Package for Mac OS XというやつをAppleのサイト(要ログイン)からダウンロードしてインストールするとgitが入るようになると思います。

SpiderMonkey

sudo port install spidermonkey

でとりあえず入るけど、versionは1.7でFirefox2相当。古い…。まあ、jslint走らせるくらいなら困らないかな…。homebrewなら1.8.5(js -vの結果はJavaScript-C 1.8.0 pre-release 1 2007-10-03でした。Firefox3.5相当かな?)が入ります。ウラヤマシイ。

node.js

sudo port install nodejs

で(2011年1月1日時点で)v0.2.5が入ります(homebrewだとv0.2.6)。ただ、node.jsはバージョン管理したいので、naveを使うほうが良いです。

git clone git://github.com/isaacs/nave.git ~/.nave
./.nave/nave.sh install 0.2.6

インストールはこんな感じで。インストールしただけではパスが通ってなくて、

./.nave/nave.sh use 0.2.6

を呼ぶ必要があります。
これを毎回呼ぶのは面倒なので、上記を.profileとかに書く…でもいいけど、アプリごとにバージョンを管理するのがベターなので少し工夫してみます。
まず適当にnaveコマンド作ります。

ln -s ~/.nave/nave.sh bin/nave

.zshrcに次のように記述します。chpwd_functionsはcdしたときに実行する関数を入れておく配列です(めも - Zshでディレクトリを移動したときに色々やるを参考にしました)。

typeset -ga chpwd_functions

function _naverc_check() {
if [[ -f '.naverc' ]] ; then
  source '.naverc'
fi
}
chpwd_functions+=_naverc_check

これで、cdしたときにそのディレクトリに.navercというファイルがあったらsource で読み込むようになるので、プロジェクトの中に

nave use 0.2.6

とだけ書いた.navercファイルを置いておけば、そのプロジェクトにcdすると適切なnodeがセットされるという塩梅になります。
これはRVMの仕組みと全く同じです。naveもそのうち同じような仕組みになってくれるかも。

RVM

ついでに RVM(Ruby Version Manager)もインストールしましょう。

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

でインストールは完了です。

rvm install ruby-1.9.2
rvm install ruby-1.8.7
rvm install jruby

といった感じで色んなバージョンのRubyを簡単にインストールでき、手軽に切り替えできます。前述の通り、.rvmrcファイルを用意すればプロジェクトごとに自動でバージョンを切り替えることもできます。

終わりに

だいぶ長くなってしまいましたが、いまのところこんな感じです。そういえば、あんまりJavaScriptしてないですね…。第2弾に期待ということで。。とにかくMacもUnixもほぼ素人なので、知らないことばかりなので調べ甲斐があって楽しいです。

「Google API Expert が解説する Closure Library プログラミングガイド」

日本初の Closure Library 本「Google API Expert が解説する Closure Library プログラミングガイド」発売です！ - WebOS Goodies

Google API Expertが解説する Closure Libraryプログラミングガイド

献本頂きました！
WebOS GoodiesのIto ChihiroさんによるClosure Libraryの解説本です。HTML5ガイドブック - 0xFFのシリーズ本になります。
Closure LibraryはGoogleが開発・提供しているクロスブラウザなJavaScriptライブラリです。jQueryなどに比べると実際に利用されているケースは少ないですが、なんといってもGoogleのプロダクトで実際に使われている点がポイントです。
JavaScriptのライブラリというとjQueryが強固な地位を築いていますが、jQueryはどちらかというと個人での開発に最適化されたライブラリであって、複数人での開発には自由過ぎてやりにくい面があります(例えばセレクタで対象の要素がないときにエラーにならないなど。自分が書くときは便利ですが、バグの温床になりがちです)。
最近はウェブアプリの開発が活発になりつつありますが、その流れで今後は複数人での大規模な開発が増えてくるはずです。そういったケースでは、Closure Libraryという選択肢は十分に現実的です。
さて、Closure Library プログラミングガイドですが、まさにウェブアプリの開発を目的にした解説書です。HTML5とかなんとか騒がれていますが結局のところウェブアプリを構成するのは地味なHTML/CSS/JavaScriptであり、Closure Libraryでその面倒な部分を解決する方法を教えてくれます。サーバーとの連携方法についても解説されているところも素敵です。
あと、なんといっても個人的に嬉しかったのはClosure Compilerの解説です。ちょうどClosure Compilerについて調べようと思っていたところだったのですごく参考になりました。
というわけで、Closure Library プログラミングガイドを(ついでにHTML5ガイドブックも)よろしくお願いします。

JavaScriptのデバッグTips

JavaScript Advent Calendar 2010 8日目担当のid:os0xです。
JavaScriptネタは案外範囲が広くて色んなネタがあるので、毎回が楽しみですね。
さて、私はデバッグをネタにしたいと思います。テストではなくデバッグです。誰かが書いたコードをメンテナンスしなきゃー、とか。jQueryプラグイン導入しようとしたけど、なんかうまく動かないーみたいなケースのおはなしです。
JavaScriptのデバッグは大変なので、多くの方が日々苦労されていると思います。なぜJavaScriptのデバッグが大変なのか少し整理してみましょう。

1. ブラウザ依存
   まず、なんといってもJavaScriptはウェブブラウザ上で実行されるので、環境が一定ではありません。特定の環境だけを対象にJavaScriptを書くことは滅多にありません。PC向けではIE、Firefox、Chrome、Safari、Operaなど、スマートフォンはほぼWebKitでFirefox、Operaが少々ですが、WebKitの中でのバージョン違いはPC以上に複雑で環境を揃えにくい分むしろ厄介です。
2. 積極的にはエラーを出さない
   変数を宣言なしに使えて、しかもそれがグローバル変数になるなど、JavaScriptは思わぬところにバグが潜みやすい言語といえます。読み取り専用のプロパティに代入してもエラーにならない(代入がスルーされるだけ)ほどです。なんとなく動いてしまったコードが後々にバグとなって帰ってきます。

また、デバッグの難しさとは少し違いますが、テストを自動化し難いため、バグが再発しやすい問題もあります。

さて、今回は実際にバグが発生したコードにどう立ち向かうと良いか、という点にスポットを当てていきたいと思います。
まずはバグを大雑把に分けしてみましょう。

シンタックスエラー

JavaScriptの解釈時にエラーとなる、比較的分かりやすいエラーです。最新のブラウザならそれなりに親切なエラーメッセージで、どの行にシンタックスエラーがあるのか教えてくれるはずです。
ただし、IEのみで起きるシンタックスエラーには注意が必要です。IEの行番号は当てにならないことが多い上に、外部ファイルが複数あるときなど、どのファイルでのエラーになっているのかをIEは教えてくれません。大抵はオブジェクトリテラル( {hoge: 2, fuga: 0,} など)に余計なカンマが付いていることが原因です(IE以外のブラウザは余計なカンマを許容してしまいます)。まずカンマをチェックして、1ファイルずつ読み込んでエラーになるファイルを探し出し、さらにコメントアウトの範囲を変えてエラーになっている箇所を特定するなど、根気のいる作業が必要となります。
ただ、これらはJSLintなどのチェックツールで検出することも可能です。他にも幾つかチェック方法はあり、コマンドラインから JavaScript のシンタックスチェックを行う方法 - #生存戦略 、それは - subtechを参考にどうぞ。

実行時の例外

どのブラウザでも動いていない場合

まずはFirebugを入れたFirefoxか、Google ChromeのDevtools(WebInspector)、SafariのWebInspector、OperaのDragonfly*1などでデバッグしてみましょう。特にWebInspectorには例外が起きたところでbreakするオプションがあるので、まずはこれでbreakしてみましょう。

breakするとこのようにその時のコールスタック、ローカル変数が確認できます(左下の この状態がエラーのたびにbreakする状態です。もう一度クリックするとcatchされてない例外のみでbreakするモードに、さらにもう一度クリックするとbreakしないデフォルト状態に戻ります)。
このbreakした状態で、さらにコンソールを開くとその状態のままJavaScriptを実行することもできます。ちなみに、arguments.callee.toString()を実行すると、自分自身の関数を文字列として取得できます。arguments.callee.caller.toString() と、callerで呼び出し元を遡っていくこともできて、複雑に入れ子になった処理や、圧縮されたコードを読むときなどに重宝します。

ある程度バグに目星をつけたら、該当する箇所にデバッグ用のconsole.logなどのコードを埋め込んだり、debuggerキーワードなどを埋め込んでみましょう。ソースコードを直接編集するより、条件付きブレークなどを活用するとよりスマートにデバッグできるはずです(Firebugで元のJavaScriptのコードに手を入れずにdebug用のconsole出力を入れる方法 - 文殊堂)。
さて、これらのツールを活用すれば、Firefox、Chrome、Safari、Operaで正常に動作するようにすることはそれほど難しくないと思います(もちろん内容によりますが、そこまで複雑なことを実装することは多くないかなと)。

IE対策

さて、ある意味本題のIEでのデバッグです。これはどうしても経験に頼るしかないところかもしれません。
まず、前述のシンタックスエラーは無くなっているものとすると、IEでもJavaScriptは実行されているはずです。つまり、適当にalertを入れていけば、どこまで実行されているのか調べることができます。適当にalertを散らばらせて、問題の範囲を絞っていけば問題の箇所を見つけることができます。alertは処理が止まるので、(ループなどに注意すれば)案外デバッグしやすいと思います。
ちなみに、出力をコピーしたいときはalertではなくconfirmを使ったり、処理を止めずに手軽に値を確認するにはlocation.hashに値を入れるなどのテクニックがあります。もちろん、Firebug Liteを使うのも良いでしょう。
さて、問題の箇所を見つけたとして、それをどのように修正するかは内容によりけりです。ただ、IE対応のノウハウはウェブ上で積極的に共有されているので、(適切なキーワードがわかれば)調べれば解決策が見つかると思います。
また、IEもIE8から開発者ツールが付属しており、特にIE9の開発者ツールはかなり強力になっています。 特に有用なのがconsole.dirです。console.dirは渡したオブジェクトのプロパティとその値をすべて表示してくれます。

windowのほかにも、documentやdocument.bodyなど、console.dirで解析すればすべてのプロパティ・メソッドを一覧できます。この情報は非常に有用で、初めて見るようなメソッドが色々見つかると思います。それらが解決の糸口になるかもしれません。

まとめ

要するに、FirebugやWebInspectorなどのデバッグツールを使いこなせばJavaScriptのデバッグはすっごく楽になりますよ、というお話です。手前で恐縮ですが、http://gihyo.jp/dev/feature/01/devtoolsやこれでできる！ クロスブラウザJavaScript入門：第2回　完全版：ブラウザとデバッグ環境｜gihyo.jp … 技術評論社も参照頂ければと思います。
それでは、引き続き JavaScript Advent Calendar をお楽しみください。
Happy Xmas!

*1:[https://dragonfly.opera.com/app/cutting-edge:title=最新のOpera]でかなり良くなってます

AutoPatchWork更新とSITEINFOのあれこれ

まだChrome版だけですが、AutoPatchWorkを更新しました(AutoPagerizeのセキュリティアップデートとは関係ありません)。
Chrome Web Store - AutoPatchWork
ローカライズして(一部を日本語で表示されるようにしただけですが)、かなり前に作りかけていたSITEINFOの管理機能を載せました(あと、NAVERまとめとTumblrの専用対策)。
こんな感じです。

主な機能は

• 検索
• ソート
• 特定のSITEINFOの無効化
• SITEINFOの編集

"number of successful"はURLがマッチして実際に使われた回数、"number of failed"はURLがマッチしたけどXPathでマッチしなかった回数です。自分がよく使うSITEINFO、まったく使ってないSITEINFOが確認できます。
統計を取り始めたのは今年の2月くらいのアップデートのときなので、人によっては半年以上のデータが溜まっているはずです。
私は何度かリセットしたりしているので、おそらくこの数ヶ月くらいの期間で1回以上使っていたSITEINFOは134件でした。2010年10月時点で、wedataのSITEINFOは2600件以上あるので、実際に使っているのは5%程度といった感じです。
今後は、SITEINFOを追加したりできるようにする予定です。あと、管理機能を切り離しできるようにしてwedata使ってる拡張の共通ライブラリみたいにしても良いかも(AutoPagerizeでも使えるように)。

リアルタイムWebハッカソンに参加してきた

node.jsでWebSocket動かして遊ぼうという素敵なイベント、リアルタイムWebハッカソン : ATNDに参加してきました。
まず、なんといってもめそさんが準備した資料が素晴らしく、大変勉強になりました。資料はリアルタイムWebハッカソンでハンズオンしてきました - 自分の感受性くらいから。node.jsの環境構築から具体的なサンプルの作り方までわかりやすくまとまっています。

で、タイトルのとおりハッカソンなので、上記資料にざっくり目を通してから@yoshikawa_tさんとなにか作ってみようかという話になりました。
ただ、いいアイディアが思い浮かばず、「ゲームとか」と考えたところでという、こちらもnode.js+WebSocket(Socket.IO)で動いているデモアプリを思い出しました。このSwarmationは、右側でお題が与えられて、そのお題の形になるようにマス目を塗り潰すというゲームです。一人一つしか持ちコマがないので、参加者の動きを予想して動かなければいけないというところがポイントです。かなり完成度が高くて、Socket.IOなのでIEでも動くようになっています。
で、これの影響をモロに受けて、マス目を取り合うゲームを考えました。
まず適当なマス目を用意して、クリックすると自分の色に反転させる。反転した状態が1列並ぶと自分が反転させていたマスの数だけポイントが入るという形を考えました。そこに複数人でリアルタイムに反転させあうという要素によって、相手の妨害をするといった戦略がでてきます。さらに自分が反転して置ける数に制限を設ければ、妨害だけでなく上手く協力もしないといけなくなってそこそこゲーム性が出てくるだろうと考えました。

で、できたのがこちら(クライアント側のコード)です。
os0x's
gist: 636371 — Gist

サーバー側はごくシンプルで、クライアントが送った位置情報を他のユーザーにそのまま通知するだけです。あとはそのデータで、クライアント側で現在の反転状況(自分のマス、他人のマス)を把握して、1列揃ったら消してポイント計算という処理を行っているだけです。
黙々と書いた甲斐あって、なんとか時間内にゲームとして成立させることができました。
あ、ちなみになるべくIEでも動くようにそれっぽく書いてあります(改めてみたらaddEventListener使ってたけど、onclickで良いケースだし)。折角のSocket.IOなので、IE6でも動かしたいですから。

反省

• 私はいつも通りクライアントサイドのJSを書いてただけで、node.jsにあんまり触れなかった…
• 同じテーブルの方とかともっと協力できればよかった

まあ、今回は3時間もなかったので仕方ないところも。ハッカソンならやはり半日はほしいかなと。

その後はLTがあってなかなか面白そうな話題が出てましたが、コードにコメントつけたりしてていまひとつ集中できず、LTのあたりは リアルタイムWebハッカソン ハンズオン編 - サイト更新停滞ちうっなどに。

全体としてはなかなかまとまった情報を得られなかった node.js についての理解が深められた良いイベントでした。ありがとうございました。