2004-09-04
_ 効果出てきた。
本家のアドレスへやたらと来る worm, spam に業を煮やしてアドレスの書き換えを敢行したが、少しずつ効果が出てきた。まだまだ本家のアドレスにばかすか来るけど、どんどん減ってほしいです。えぇ、ほんとに。
_ IPAフォントを OS X で試してみた
どうも12, 14ポイントで通常のアプリ（iText でテスト）で正しく表示できなくなる。具体的にはカーニングが狂って文字が重なって表示されてしまう。NeoOffice/J では問題なく使えたけど、ちょーっと難しいフォントだな。何が問題なんだろ？
ちなみにライセンスによると、
- このフォントだけでの再配布は不可。Grass とともに配布すること。
- このフォントを他のアプリと組み合わせて利用するのは問題ない。
そうです。
参考
テスト状況
| アプリ | platform | 結果 |
| NeoOffice/J 0.8.4 | Panther | OK |
| iText 3.1.3 | Panther | NG(12,14ptでカーニングが狂う) |
| mi 2.1.5 | Panther | NG(12,14ptでカーニングが狂う) |
| ターミナル | Panther | OK |
| Firefox 0.9.1 | Mac | OK |
| mEdit 0.98 | Mac | OK |
| Safari 1.2.3 | OK | |
| iText 3.1.5 | Win2k | OK(11, 13 ptがアンチエイリアスなしでもきれい) |
| Word 2002 | Win2k | OK |
| Illustrator 10 | Win2k | OK |
| メモ帳 | Win2k | OK |
| サクラエディタ | Win2k | NG(等幅のはずのIPAフォントを認識せず) |
| cko | cygwin | OK |
| xyzzy | Win | NG(認識せず) |
12ポイント問題って特殊な事例なのかな？ あ。ターミナルはフォントのパネルで文字幅が設定できるな。OS X 標準パネルを使うアプリはひょっとして大丈夫か？
cko で試したところ、Windows では 12, 14，16 でドットフォントでも「見れる」状態になる。アンチエイリアスで使うのが基本だとは思うが、そうならない環境でもこの辺のサイズを選べばイケる。iText だと(日本語)と書いてあるフォントにしないと表示できない。11, 13ptがきれい。この辺、なぜ食い違うのかはよく分からない。
_ CSS の修正
なんとか Netscape 4 で問題が目立たないくらいには CSS の修正ができたと思う。あー面倒くさかった。
2005-09-04
_ ユニットテスト始めました
今までもテストコードは書いていたんだけど、使い捨てだったのでこれはいかんなぁと思っていたのと、確認は人間の目で行っていて、成否をいちいち人間が判断するという効率の悪さが気になっていたので、テストツールを使うことにした。
とりあえず Ruby の Test::Unit から始めた。うーん最初はやはりかなり邪魔くさい。あと、assert にはテストしたいメソッドの結果が直接返ってこないとダメなのかと思いこんでいたけど、たぶんそうじゃないんだな。確認用のメソッドを作ってそっちを呼んでも、とりあえず問題はないと判断。*1
ユニットテストの自動化のメリットとして
テストしやすい書き方をするから書き方のバラつきが少なくなる
てな記述を見かけるんだけど、これはほんとかもしれないと思った。こういう自動化ツールは中途半端に使っても嬉しくなく、徹底的に依存しちゃう方が効果は大きい。そうすると、確かにテストしやすいコードに自然と直ってくる。ような気がする。まだコードそのものが変わっちゃうほど使い込んでいないけど、このなんかこう、居心地の悪さは、慣れないことをやっているとき特有のもので、慣れると気持ちよくなりそうなそんな期待を感じることのできる気持ち悪さだ。cvs なんかを使い始めるときもこんな感じかな。最初のうちは面倒なだけで必要性を感じられないんだけど、慣れると使ってないと気持ち悪くなるところが。
ただ、テストコードを書きにくいものはどうしても残りそうだし、とりあえず Web 上を見て回ってもそれに対する有効な回答は見つけられなかった。なんか、そのうちうまく書けるようになる、みたいなちょっと騙されたような感じ。（まぁよほど経験を積んだうえでないと具体的にテストしにくいものはこうする、なんてことは書けないもんな。）
テストコードはどこに置いておくのがいいんだろう？ 別ディレクトリに分けてリポジトリにつっこんでおくのがいいのかな？ コンパイラ言語なら中に書いちゃって ifdef で切り分け、なんてのも ok なんだろうけど、LL の場合はそうはいかないもんな。
これしかし、自分で書いたものを自分でチェックしてるだけなんだけど、プログラムが自動で成否を判断してオッケーって言ってくれてるような感じが嬉しくて面白い。錯覚なんだけども、面白いと感じることができる要素があれば続けられそう。
*1 この辺、assert の書き方のパターンがどこかにいっぱいあると嬉しいかな。
2006-09-04
_ viewset という考え方
別段新しい考え方でもなんでもない気がするんだけど、思いついたのでメモ。
Rails を引き合いに出すまでもなく MVC という単語だけはずいぶん浸透している。でまぁ、この V に当たる部分をロジックから分離する方法の一つとして*1テンプレートの活用というのがあるわけなんだけど、
このテンプレートって配置に困りませんか？
プログラマが、あるいはアプリのワクが分かっているデザイナがテンプレートを書いているなら困らないかもしれないけれど、そういうことが分からない人がデザインを担当している場合、
テンプレートとそれ以外のパーツが泣き別れになると作業しにくい
と思うわけ。テンプレートはテンプレート用のフォルダに、画像や CSS などのパーツは Web ブラウザから直接見える場所に置いてください、というのはやはり不親切ではないかと。だからと言ってテンプレートをブラウザから見える場所に、具体的にはアプリケーションと同じ階層に置くと今度はお互いに管理しにくいし危ない。
そこでブラウザから見えない場所に viewset の置き場所を作って、そこにまとめて置いてもらうっていうのはどうだろう。具体的には以下のような構成になるんじゃないかと思う。
|-- app ← ブラウザがアクセスするところ
`-- viewset ← テンプレートおよびデザインパーツ置き場
|-- VIEWNAME
| |-- css
| | |-- base.css
| | `-- flavour.css
| |-- img
| | |-- dummy1.img
| | `-- dummy2.img
| `-- template.htm とか template.erb とか
`-- VIEWNAME2
で、アプリの側からは VIEWNAME を指定するだけで、いい具合に CSS や画像も呼び出せるようになるという寸法。デザインリニューアルの際にはこの VIEWNAME を切り替えるだけでガラっと印象を変えることができる。また画像や CSS を直接上書きしなくて済むのでリニューアルというほど大掛かりではないが、定期的にデザインが変わるような場合も更新作業が楽になるのではないかと思う。
ファイルの管理上も都合がよい。デザインする人はデザイン過程と同じ要領でテンプレートも画像も CSS もひと固まりで管理しておけるし、アプリケーションとは別な領域に置いておけるので開発する人もデザインする人もお互いに安心。おまけに VIEWNAME が時系列で並ぶようにすれば簡単な履歴管理にもなる。
どうだろ。
実現方法をなんにも書いてないけど、それはまだ何も考えてないからです。
*1 メリットはそれだけじゃないけど
2007-09-04
_ Cperl-mode 重すぎと思ったら Emacs の問題だったか？
試し始めた Cperl-mode だけど、Debian etch(4.0) の Emacs（emacs-snapshot） との組み合わせが悪いのか、なんかプロセッサパワーを食いつぶしちゃう。これはさすがにおかしいなぁということで使用を諦めることにしようかと思ったけど、Fink で入れた Emacs 22.1 (OSX PPC) 上で使う分にはたぶん大丈夫な感じなので、testing の 22.1 を入れたらいいのかもしんないな。もしかすっと。
と思って改めて見てみると backports に Emacs 22.1 が来てた。おぉ。ということで emacs-snapshot を apt-get remove して emacs22-nox をインストール。
……。
んー。まだ跳ね上がるときがあるなぁ。ずっと上がりっぱなしではなくなったけれども。メモリじゃなくてプロセッサパワーっつーところがいったい何しとんじゃいという感じ。こんなにクソ重ければそれなりに話題になっていそうなもんなのに、そういう話は見ないもんなぁ。
