easy_fabricator とか作ってみた。

あるいは。

Ruby で動的に class を定義したかった。

twitter 上で何人かにそんなんできるよって言われたんだけど、どうにも伝わらなかった部分。

class を生成したいんじゃなくて、class 構文を使わずに class を定義したい。

なんでかというと

Fabricator は Model 相当の class の名前を Symbol で与えて使うから

ゴニョゴニョしてできたものはこれ。

具体的に困ったこと、解決したことは何か

  • Object.const_set( NAME, classobj ) で好きなタイミングで class 定義できる
    • Klass = な書き方はメソッドの中では不可能
  • fabrication の DSL はちょっと注意が必要

例えば open や catch とかって attribute を用意してしまうと困る。

Fabricator( :model ) do
  open  { ... }
  catch { ... }
end

って書き方になるんだけど、これは通常のメソッド呼び出しになるので定義できない。

回避方法あるのかなぁ。あったら嬉しいんだけど。ダミーデータ用のツールのために元の名前に制限があったらちょっと本末転倒だよね。

PukiWiki 中身消えちゃったように見える問題再現

うちのサーバでも 4.4.2 に上げたら再現したorz 4.4.2 + 1.4.4 はアウトってことね。

そうかい分かったよ、とりあえず PukiWiki 1.4.6 のカスタマイズするよ。常時使ってるものに影響が出ちまったらさすがにやるしかあるまい。

やっぱやめた。どうもファイルの存在が分かってないみたいだなぁとは思っていたのでちょっと眺めてみたら、ページ名からファイル名を取得する encode() に使ってる unpack() で返ってくる値が変わってしまっていた。

CVS Repository - log - SourceForge: pukiwiki/pukiwiki/lib/func.php

を参考に、func.php を

246c246
<       return ($key == '') ? '' : strtoupper(join('', unpack('H*0', $key)));
---
>       return ($key == '') ? '' : strtoupper(bin2hex($key));
252c252
<       return ($key == '') ? '' : substr(pack('H*', '20202020' . $key), 4);
---
>        return ($key == '') ? '' : pack('H*', (string)$key );

にすれば ok っぽい。

ircd-hybrid の 7.2.0 と X-Chat が相性悪い

ircd-hybrid を何の気なしに上げたら

Server load is temporarily too heavy.

ってメッセージがじゃんじゃか出てくるようになった。最初は裏でコンパイルとかしてるから重たいのか?とか呑気なことを考えてたんだけど、調べてみると X-Chat が定期的に /WHO を投げてるのがよくないとかなんとか。snapshot ではもう直ってるから数日から数週間で 7.2.1 が出れば解決じゃないかみたいな話が出てたのが昨年末。まだ 7.2.1 は出ない。

irc クライアント変えれば問題ないのは確認したけど、気持ちよくない(というか新しいソフトいろいろ調べるの面倒でやだ)ので portdowngrade した。すげー便利だな、これ。

初バリウム

健康診断を受けてきた。

噂のバリウムに初挑戦。うわーと思ったがなんてことなかった。炭酸ガスを発生する薬(?)を飲んでバリウムを飲むんだけど、ビール飲んだあとにおいしくもないシェイクを飲むようなもので、期待していたようなつらい体験ではなかった。確かに腹は張るけどまったくどーってことない。

むしろ台に乗せられて身体をぐるんぐるん回すのがびっくりした。なんか右向いてって言われたりあお向けになってって言われたりするんだけど、どっちが何だが混乱して悩んでしまう。別にひっくり返っても右は右なのにね。

Ruby のドキュメント、Python のドキュメント、PHP のドキュメント

Pythonのマニュアルは、Rubyのリファレンスマニュアルより、ずっと良い

Python のマニュアルは量が多いのは分かっているけど真面目に見たことないのでなんとも言えない。ただ、Ruby のリファレンスマニュアルがなんだか微妙だという印象は強い。まつもとさんはまぁまぁだと思っているみたいだけど、個人的には「リファレンスマニュアル

  • 逆引き Ruby」でまぁまぁかなと思っている。

とにかくリファレンスマニュアルは記述が質素すぎて自分のほしい情報への取っ掛かりにしにくく、Namazu で検索してもタイトルでは意味がまったく分からないことが多いような気がする。ページをもう少し細かく分けた方がいいのかもしれない。1PHP のマニュアルのようにものすごく大量なのもそれはそれで確かに扱いにくいんだけど、検索に関して言えば PHP の方はほぼ目的のものが一発で見つかるので助かる。

あと凡例のページを用意してほしいかな。ソースコード内で意味を持ちそうな記号を説明用の記号として使っているので、どこからが説明でどこまでコードなのか判別しにくい。あるいはソースコードをハイライトする RWiki のプラグインのようなものがあればよいのかもしれないけど。よくサンプルコードを見て首をひねってしまう。

Ruby に慣れていれば「こんな記号に意味はない」と一発で分かるんだろうけど、そういう人はそんなにリファレンス見ないと思うんだな。その辺の書き手と読み手の意識のずれが Ruby 関係のドキュメントをよりよくしようとする際のカギなのかもしれない。

  1. その後、2005-02 に 1.8.2 の HTML マニュアルがダウンロードできるようになり、以前より検索精度が高くなったように感じる。HTML ソースなどを詳細に眺めたわけではないが、少なくともページタイトルを見ても意味がよく分からないということは減ったと思う。 

About

例によって個人のなんちゃらです