先日、Stylusのコードをいじってたらグローバルリークがあったので、修正してPullリクエストしました。（TJが即マージしてリリース済みだよ！）

リークを見つけたのは、StylusのテストコードにGlobalオブジェクト汚染を検出するテストがあってそれをたまたま走らせただけなのですが、このテストがシンプルかつ効果的でいいなと思いました。

https://github.com/LearnBoost/stylus/blob/master/test/run.js

// Testの初期化時にデフォルトのグローバルオブジェクトのキーを保存。
var globals = Object.keys(global);
...

// Testが終わったらグローバルオブジェクトの差分をチェック
function done() {
  Object.keys(global).forEach(function(name){
    if (!~globals.indexOf(name)) {
      console.error('  \033[31mglobal leak:\033[0m %s', name);
      ++failures;
    }
  });
  ...

JavaScriptってvarとかnewとか忘れただけでグローバルリークしちゃうので（CoffeeScriptなら以下略）、これテストフレームワークに入れて全メソッドでチェックしたらいんじゃない？と思って、Stylusの作者TJが作ってるテストフレームワークmochaを見てみたら、やっぱりGlobal leakをチェックする機能が入ってました。デフォルトでチェックしてくれるみたいです（"―ignore-leaks"で抑制可能）。

使っているテストフレームワークにこの機能がなくても、単純なテストなので、setup()やteardown()に仕込んどくのがいいんじゃないでしょうか。

ちなみに、グローバルリークってだいたいnewかvarの付け忘れだと思うんですが、今回の"lineno"プロパティはいろんなクラスに継承されるNodeというベースクラスのコンストラクタでセットされるプロパティなので、newが漏れてる箇所を単純なgrepでは見つけにくいところでした。なので、

var Node = module.exports = function Node(){
  if (this === global) debugger; // newを忘れてたらここでbreakされる
  this.lineno = nodes.lineno;
  Object.defineProperty(this, 'filename', { writable: true, value: nodes.filename });
};

みたいに条件付きdebuggerを仕込んでテストをdebugで動かしたら一発で見つかりました。

$ node debug test/run.js
< debugger listening on port 5858
connecting... ok
debug> c

<     arithmetic.color
<   ✔ arithmetic.color
<     arithmetic
<   ✔ arithmetic
<     arithmetic.unary
break in lib/nodes/node.js:23
 21 
 22 var Node = module.exports = function Node(){
 23   if (this === global) debugger;
 24   this.lineno = nodes.lineno;
 25   Object.defineProperty(this, 'filename', { writable: true, value: nodes.filename });
debug> bt
#0 node.js:23:23
#1 boolean.js:23:8
#2 Boolean.negate boolean.js:78:10
#3 Evaluator.visitUnaryOp evaluator.js:428:31
#4 Visitor.visit index.js:28:39
#5 Evaluator.visit evaluator.js:74:18
#6 Evaluator.visitExpression evaluator.js:451:26
#7 Visitor.visit index.js:28:39
#8 Evaluator.visit evaluator.js:74:18
#9 Evaluator.visitProperty evaluator.js:489:22
debug> o
break in lib/nodes/boolean.js:24
 22 var Boolean = module.exports = function Boolean(val){
 23   Node.call(this);
 24   if (this.nodeName) {
 25     this.val = !!val;
 26   } else {
debug> o
break in lib/nodes/boolean.js:79
  77 Boolean.prototype.negate = function(){
  78   return Boolean(!this.val);   // newが抜けてる！！！
  79 };
  80 
  81 /**
debug> 

gdbライクなNode.jsのDebugger、覚えてるとちょっとしたときに便利ですね。

node-canvasをインストールするために、依存するcairoをbrewで入れようとしたらなんかエラー。

$ brew install cairo
...
ld: lto: could not merge in .libs/cairo-analysis-surface.o because Unknown instruction for architecture x86_64
collect2: ld returned 1 exit status
make[3]: *** [libcairo.la] Error 1
make[2]: *** [install] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install] Error 2
==> Exit Status: 2
http://github.com/mxcl/homebrew/blob/master/Library/Formula/cairo.rb#L20
==> Environment
HOMEBREW_VERSION: 0.8
HEAD: 2cd086421ee5b01e3684a938795d4d8c12979db7
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
HOMEBREW_REPOSITORY: /usr/local
HOMEBREW_LIBRARY_PATH: /usr/local/Library/Homebrew
Hardware: quad-core 64-bit sandybridge
OS X: 10.7.2
Kernel Architecture: x86_64
Ruby: 1.8.7-249
/usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
Xcode: 4.2.1
GCC-4.0: build 5494
GCC-4.2: build 5666
LLVM: build 2336
Clang: 3.0-211.1
MacPorts or Fink? false
X11 installed? true
==> Build Flags
CC: /usr/bin/llvm-gcc => /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
CXX: /usr/bin/llvm-g++ => /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
LD: /usr/bin/llvm-gcc => /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
CFLAGS: -O3 -march=core2 -w -pipe
CXXFLAGS: -O3 -march=core2 -w -pipe
MAKEFLAGS: -j4

Error: Failed executing: make install 
These existing issues may help you:
    https://github.com/mxcl/homebrew/issues/7658
    https://github.com/mxcl/homebrew/issues/8144
    https://github.com/mxcl/homebrew/issues/9180
Otherwise, please report the bug:
    https://github.com/mxcl/homebrew/wiki/checklist-before-filing-a-new-issue

提示されたURLはどうも的外れっぽい。

なんかLLVMが怪しいので、gccでコンパイルしたらあっさり通りました。

$ brew install cairo --use-gcc

もう、ソースからビルドしろよって感じですね。

node-canvasのビルドマニュアルが超親切です。

みんな気になってしょうがないPathのアレを、Sass, Compass, CSS3 Animationsのお勉強をかねて作ってみました。Chrome, Safari, Firefox, IE10で動きます。

• Demo: http://teppeis.github.com/menu-like-path/
• Source: https://github.com/teppeis/menu-like-path

「CSSでPath風メニュー」っていうのは国内外ですでにたくさんあるので、気になったところなどSass&Compass寄りでいくつか書きます。

SCSSの記述量はCSSの約5分の1

今回作ったもので、SCSSで約300行（後述の自作ライブラリ含む）、コンパイル後はCSSで約1550行になりました。

大きいのは、繰り返しで@forループできたところと、ベンダープレフィックスですね。border-radiusやanimation, box-shadowなどを多用する場合はこのぐらいに成ると思います。Sass形式で書くとブレースがない分、まだ若干減りますね。

transition-propertyでtransformを指定する方法

前述のとおり、Compassの最大の利点はベンダープレフィックスをよろしく付けてくれるmixinが用意されてることです。SCSSをこう書くと、

/* SCSS */
@include border-radius(50%);

コンパイル後にこうなります。

/* CSS */
-moz-border-radius: 50%; 
-webkit-border-radius: 50%; 
-o-border-radius: 50%; 
-ms-border-radius: 50%; 
-khtml-border-radius: 50%; 
border-radius: 50%; 

ところが、transition-propertyのように値に対象のプロパティ名を指定するケースでは、値の方にベンダープレフィックスをつけてくれません。これが、

/* SCSS */
@include transition-property(transform);

こうなってしまいます。

/* CSS */
-moz-transition-property: transform;
-webkit-transition-property: transform;
-o-transition-property: transform;
transition-property: transform;

本当はこうなってほしいのです。

/* CSS */
-moz-transition-property: -moz-transform;
-webkit-transition-property: -webkit-transform;
-o-transition-property: -o-transform;
transition-property: transform;

なので、プロパティ名と値の両方にプレフィックスを付けるmixinを作ってtransition-propertyに使ってみました。

• https://github.com/teppeis/menu-like-path/blob/master/sass/_shared.scss
• https://github.com/teppeis/menu-like-path/blob/master/sass/_transition.scss

transitionとtransformでベンダープレフィックスサポートが異なる場合もあるので、実はあんまりいけてないmixinですけど。。

Compassのベンダープレフィックスサポートはわりとテキトー？

IE10からCSS3 Transitionに対応していますが、上の出力例で分かるようにCompassはtransition-propertyに-msを出力しません。IE10でもTransitionしたいのに！一方、CSS3 Flexible Layout関連には-msが出力されます。Issuesの議論を見ると、入れるかどうかの判断基準は割とゆるそうです。

座標計算をするにはCompassがほぼ必須

Pathのメニューは円形なので、座標計算のためにはsin(), cos(), piなどが必要になります。そういうのがSassには用意されてるものだと思ったのですが、Sassの組み込み数値計算関数は四則演算と丸め関数ぐらいしかありません。

• Module: Sass::Script::Functions

そこでCompassのリファレンスを見てみるとsin, cos含めていくつかのヘルパー関数が用意されていました。

• Compass Helpers | Compass Documentation

Compassって、-moz-transitionみたいなベンダープレフィックスの便利帳みたいな印象だったのですが、こういう組み込み関数も充実してるんですね。もうSassはCompassとワンセットだと思った方が良さそうです。

@keyframesが鬼門すぎる

CSS3 AnimationsをSass&Compassでうまいことクロスブラウザ対応するのは非常に苦労しました。結論としては以下の2つでなんとかなりました。

• Sass-3.2.0（alpha版）から導入される@contentを使う
• SCSS形式をあきらめて一部をSass形式にする (Partial Sass)

やりたいこと

CSS3 Animationsの基本構文は以下のようになります。

/* CSS */
@-webkit-keyframes anim-1 {
  0% {
    width: 0px;
  }
  100% {
    width: 100px;
  }
}
.hoge {
  -webkit-animation-name: anim-1;
  -webkit-animation-duration: 1s;
}

やりたいことは2点

1. @keyframesのベンダープレフィックスを自動生成したい
2. 複数要素に対してを繰り返しで@keyframesを生成したい（メニューの周りのちっちゃい丸用）

@keyframesのベンダープレフィックスを自動生成したい

これはmixinとかいろいろ試したのですが、根本的に@keyframesがCSSとしては例外的にネストしている構文なせいで、コンパイルエラーになるか、コンパイル後におかしなCSSになってしまってだめでした。

で、SassのIssuesを漁っていると、@contentというのが次期バージョンから追加されることが分かりました。これは、mixinを呼び出した側のブロックの中身を呼び出されたmixin側が@contentで参照できるもの。まさに@keyframesや@media用に作られたっぽいです。こんな感じ。

/* SCSS */
@mixin keyframes {
  @-moz-keyframes anim-1 {
    @content
  }
  @-webkit-keyframes anim-1 {
    @content
  }
  @-ms-keyframes anim-1 {
    @content
  }
  @keyframes anim-1 {
    @content
  }
}
/* 使い方。この中身が全ての@contentに代入される。 */
@include keyframes {
  0% {
    width: 0px;
  }
  100% {
    width: 100px;
  }
}

開発版のSassのGemはこんな感じでインストールできます。（rvmを使うと複数のGemのバージョンを管理できるのでオススメです）

$ gem install sass -v 3.2.0.alpha.35

複数要素に対してを繰り返しで@keyframesを生成したい

ほんとはこんな感じで複数の要素に異なるkeyframesを割り当てたいのです。

/* SCSS */
@mixin keyframes($name) {
  @-moz-keyframes #{$name} {  /* ここでコンパイルエラー！ */
    @content
  }
  ...
  @keyframes #{$name} {
    @content
  }
}
/* 3つの要素に繰り返しkeyframesを生成して設定 */
@for $i from 1 through 3 {
  @include keyframes(anim-#{$i}) {
    0% {
      width: 0px;
    }
    100% {
      width: 10px * $i;
    }
  }
  li:nth-of-type(#{$i}) {
    @include animation-name: anim-#{$i};
  }
}

ところが、keyframesの$nameを設定するところでコンパイルエラーになってしまいます。

Line 1: Invalid CSS after "($name) ": expected expression (e.g. 1px, bold), was "{"

https://github.com/nex3/sass/issues/207 に書いてあるように'#{$name}'のように引用符で囲むとコンパイルは通りますが、CSSとしては引用符で囲むのはInvalidなので、Firefoxでは動きません。。

諦めてsedで置換しようと思ったのですがw、どうもSCSSのパーサーが怪しい気がしたので、Sass形式で試してみるとうまく動きました！

/* Sass */
@mixin keyframes($name)
  @-moz-keyframes #{$name}
    @content
  @-webkit-keyframes #{$name}
    @content
  @-ms-keyframes #{$name}
    @content
  @keyframes #{$name}
    @content

Sassにはアンダースコアで始まるSassファイルを@importで読めるPartialsという機能がありますが、これはSCSS形式でもSass形式でも区別なく読めます。読み出し側と呼ばれる側の形式が異なっても問題なし。なので、普段はSCSS形式で書いていて、keyframesのmixinだけ_keyframes.sassとしてSassファイルで保存すれば、SCSSファイルから、

/* SCSS */
@import "keyframes";

として呼び出せます。Partial Sassとでも言いましょうか。素晴らしい！

CompassではAnimations関連のmixinが定義されていない（このkeyframes問題のせいかな？）ので、まるっと定義しました。ほとんどTransitionsのコピペですが。

• https://github.com/teppeis/menu-like-path/blob/master/sass/_animation.scss
• https://github.com/teppeis/menu-like-path/blob/master/sass/_keyframes.sass

まとめ

以前は、HTMLで構造を、CSSで見た目を、JavaScriptで振る舞いを、と言われていましたが、CSSで「動きの見た目」まで定義した方が、JSにはロジックだけ書けてすっきりするし、CSSを適切に書ければ自然とProgressive Enhancementになるので良いかなと思います。ただし、素のCSSは「動き」を記述するにはあまりに貧弱なので、Sass的なものが必須になってきます。

SassもCompassもまだ発展途上でいろいろ問題がありますが、現在進行形で発展しているのでおもしろいです。ガリガリ書き始めると、Sass/SCSSは@includeなど記述の冗長性が気になりますが、デザイナーさんと協業しているところは必要経費かもしれません。

個人的には、より自然で簡易な記述が出来るStylusが気になってます。Rubyで書かれたSassよりもJSのStylusの方が個人的に読みやすいのでｗ

昔HomebrewでNode.jsをインストールしたけどnaveに移行したよという話。作業ついでに調べたことのメモ。

こんな生Node.jsはいやだ！（Homebrewとかのパッケージ管理やソースから入れたときの問題点）

• Node.jsのバージョンがもりもり上がる（これはソースから入れたときの問題）
• 0.4系(stable)と0.5系(dev)を気軽に切り替えて試せない
• Node.js本体とnpmの権限が違ったりして、sudoするとかしないとか面倒

Node.js本体を管理するユーティリティとしてnvmとnaveっていう2つがあって機能はだいたい一緒。ただし、nvmはzshとの相性が悪いようでパッチを当てなきゃならんらしく、zsh厨としてはとりあえずnaveを選択。naveはnpmと作者が同じなので相性もいいはず（という願い）。

今回は、個人の開発環境用に全部ユーザーのホームディレクトリ以下にインストールする形にする。

1. 古いNode.jsのアンインストール

まずはHomebrewで入れた古いNode.jsのアンインストール、の前に、先にnpmのアンインストールをしておく。（npmをあとから消すのはパスの設定とかめんどくさかった）

$ sudo npm uninstall npm -g

上のコマンドだとnpmでインストール済みのモジュール群は削除されない。削除したい人は、npm lsの結果をnpm rmするか、以下のコマンドで削除できるよって公式READMEに書いてあった（怖いから試してない）。

$ npm explore npm -g -- sh scripts/clean-old.sh

次いでNode.js本体のアンインストール。

$ sudo brew uninstall node.js

あとNODE_PATHとかの環境変数を.profileとかに書いてたら消しとく。

2. naveとNode.jsのインストール

実際にはnave.shさえあればいいのだけど、手っ取り早くcloneする。

$ git clone https://github.com/isaacs/nave.git ~/.nave

nave.shにパスを通す。ここではパスの通ったディレクトリにリンクしてるけど、aliasにしてもいい。

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

次にnaveコマンドでNode.js本体をインストール

$ nave use stable
$ node -v
v0.4.12

"stable"だと安定板0.4系の最新バージョン、"latest"だと0.5系の最新バージョンをインストールした上で、もろもろの環境変数を設定してくれる。もちろん"nave use 0.4.12"とか直接バージョンを指定してもいい。

実際にインストールしてから分かったのだけど、このnaveというのは各種環境変数を設定したshellを起動するシェルスクリプト。なので何回もnave useすると何層もシェルをラップするような感じになってしまう。ちょっといやな感じ。どうやらnvmの方はシェル起動ではなく現在のシェルの上で環境変数をよろしくするタイプらしいのだけど、うーん。どっちもどっちか。

ということなので、常時Node.jsを有効にするためには、nave use stableを.profileに書いておくか、.bashrc系なら以下のように書くとnave useするたびに多重起動しちゃうのを防げる。

if [ ${NAVELVL-0} -lt 1 ]; then
    nave use stable
fi

$NAVELVLはnave useを呼んだ回数、現在何層目かを記憶しているトーテム*1のようなものなので、これで判定するのが良いでしょう。

3. npmのインストール

npmは普通にインストール。

$ curl http://npmjs.org/install.sh | sh

試しにexpressをインストール。

$ npm install express -g

-gオプションを付けると、現在useしているバージョンのNode.js全体で使えるようにインストールしてくれる。逆に付けないとカレントディレクトリのnode_modulesにインストールしちゃうので、アプリ単位で必要なときに使う。

4. ディレクトリ構成の確認

そうするとだいたいこんな感じになる。

.nave/
├── installed
│   ├── 0.4.12
│   │   ├── bin
│   │   │   ├── express -> ../lib/node_modules/express/bin/express
│   │   │   ├── node
│   │   │   ├── node-waf
│   │   │   ├── node_g
│   │   │   ├── npm -> ../lib/node_modules/npm/bin/npm.js
│   │   │   ├── npm-g -> ../lib/node_modules/npm/bin/npm.js
│   │   │   └── npm_g -> ../lib/node_modules/npm/bin/npm.js
│   │   ├── include
│   │   ├── lib
│   │   │   ├── node
│   │   │   ├── node_modules
│   │   │   │   ├── express
│   │   │   │   ├── npm
│   │   │   │   └── socket.io
│   │   │   └── pkgconfig
│   │   └── share
│   └── 0.5.7
└── src
    ├── 0.4.12
    └── 0.5.7

Node.js本体もnpmでインストールされたモジュールも、全部ユーザーのホームに作った.naveに入ってて、かつ本体のバージョンごとに分かれていることが分かる。

個人の開発環境としてはかなり開発しやすくなったと思います。お疲れさまでした！

先日、MacBookでデュアルディスプレイでフルスクリーンにするとフリーズすると書いたのですが、実際にはフルスクリーンにする前に外部ディスプレーを接続した時点でCPU暴走が始まっていてハングしているようでした。

Mac OS X 10.7.1もリリースされたところでもう一度情報収集していると、Appleのフォーラムで解答を見つけました。

Gentlemen! Removing InsomniaT solved it for me. It seems to work just fine now, and the error messages, the high CPU load and the freezes are gone.

https://discussions.apple.com/message/15752716

InsomniaTのこのバグが原因だったようです。

Bug #804321 in InsomniaT: “OSX 10.7 with external display causes CPU spike”

以前に使っていたInsomniaXがLionでは使えなかったので、ちょうどInsomniaXに乗り換えたところでした。該当のバグは3.0.2で修正済みとのことで、バージョンアップしたら無事に外部ディスプレーが使えました。古いバージョンの方はアップデートをおすすめします。

もう信用ならん！という人は、最新版のアーカイブにアンインストーラーが入っています。手動で削除したい人はこちらを参考に。