gulp-slim が日本語を含むファイルのコンパイルに失敗する

結論から書くと、私の環境は Windows で gulp-slim は Slim のコンパイルに Ruby 実装を使っていた。 Windows で Ruby を使うときの文字コードの問題で失敗していたようだ。

環境変数 RUBYOPT に -EUTF-8 を設定すれば成功する。
WindowsでEncoding.default_externalをUTF-8にするには - すがブロ

gulp-slim がエラーメッセージを握りつぶしていたことと、 Node.js 上で走る gulp-slim を表面的に使っている限りは Ruby が走っているなど知るところではないので原因の特定に時間がかかった。

Ruby 書くのではなく使う人にこの手の問題を意識させないで欲しいよね。

Stylus ではまった点

CSS プリプロセッサというと Sass と Less の２強という感じですが Stylus もおすすめですよ。

Stylus は文法も覚えやすく１日もあれば使いこなせますが２点だけはまったのでメモ。

割り算をするときはかっこでくくる

margin (500px / 3)

font プロパティや border-radius プロパティなどは CSS でも / を使うプロパティがあるのでそれと区別をつけるためでしょう。

calc() 関数の中の変数は展開されないので % 演算子でフォーマットする

container-margin = 500px
margin 'calc(%s / 3)' % container-margin

Bug when using CSS calc function · Issue #687 · LearnBoost/stylus · GitHub
ここに書いてありました。

CSS3 の calc() 関数はどんなプロパティにでも使えるわけじゃない

calc() 関数を使っていて動かなくても時間を無駄にせぬようメモ。

font-size: calc(36px / 2);

なぜか動きませんでした。

css3 - CSS - calc() on font-size - changing font size based on container size - Stack Overflow
英語は読めないけど駄目だよーって書いてありそう。

クロージャではまったのでメモ

クロージャではまるのは C# に続き CoffeeScript で２度目なのでメモ。

やりたかったこと

４つのクロージャに０、１、２、３のそれぞれを束縛したかった。

間違い

f() for f in ((-> console.log i) for i in [0...4])
# 4
# 4
# 4
# 4

CoffeeScript の性質上仕方のないことで変数のスコープが大変わかりづらいが、すべてのクロージャが同じ変数を束縛している。そのため同じ数が束縛されてしまった。

正解

f() for f in ((do (i) -> -> console.log i) for i in [0...4])
# 0
# 1
# 2
# 3

クロージャを作るときに即時関数を使って変数を新たに宣言し、その変数を束縛している。うまくいった。

まとめ

• クロージャは変数のスコープに注意
• ループでクロージャを作るときは要注意
• CoffeeScript でクロージャを作るときも要注意

グリッドレイアウトを見やすくする小技

グリッドレイアウトやカードレイアウトが流行っていますよね。でも縦と横のマージンを安易に同じにしていませんか？

縦と横のマージンが同じ場合は、まず右に読み進めて下に右に読み進めて下に…なのか、下に読み進めて右に下に読み進めて右に…なのかわかりません。そのためユーザは読み進める方向がわからず無意識にストレスを感じてしまいます。

そこで縦と横のマージンに差をつけ読み進める方向をユーザに暗に示すことによって、ユーザのストレスをなくすことができます。

ユーザに読ませたい方向がある場合はそれに合わせてマージンに差をつけましょう。 もしユーザに読ませたい方向がなくても必ずマージンに差をつけましょう。

Windows 7 と Windows 8 どちらのスクリーンショットがわかりやすい？

先日 Windows 用フリーソフトを公開したのですが、ありがたいことに多数のメディアに取り上げていただきました。そのとき疑問に思ったことについて書きます。

公開した Windows 用フリーソフトです。
Fit Win - ウィンドウの移動・サイズ変更ツール

どのメディアもスクリーンショットを載せていたのですが、そのほとんどが Windows 8 のスクリーンショットでした。公開したとき最新の Windows OS は Windows 8 で、Windows 8 のシェアは 13% 、 Windows 7 のシェアは 50% でした。

もちろんこのとき最新の Windows OS である Windows 8 のスクリーンショットであることに問題はないのですが、ユーザ数が最大の Windows 7 のスクリーンショットがもっとあってもいいのになと思いました。何か理由があるんでしょうか。

ひとつのファイルにひとつのクラスか複数のクラスか？

つい面倒くさがって気がつくとひとつのファイルが長くなっているので自戒の意もこめて。

ひとつのファイルにひとつのクラスのメリット

クラスをまとめてひとつのファイルにするかどうかで迷わなくてすむ

読みやすくなるようクラスをまとめても、クラスが増えたり変更されたりして読みづらくなり迷い損ということもしばしば。

メンバーでの統一がかんたん

ひとつのファイルに大量のクラスといった惨事を防げたり、１００行以下のクラスを３つまでしかひとつのファイルにしてはいけないのような複雑な規約を設定しなくてすむ。また前述のような問題をうけて規約が増えたり変更されない。

ひとつのファイルに複数のクラスのメリット

柔軟

数行の小さなクラスやインターフェースをまとめられたり、結合が強いクラスをひとつのファイルにできる。

まとめ

基本はひとつのファイルにひとつのクラス、小規模な趣味ならご自由に。