2.2.0に変更すると半分程度の月の日記データ(YYYYMM.td2)が消えた。残ってる月も表示されるのは一、二件程度。原因を調べると、もちろん原因は自分にあったんだけど、2.2.0の更新された tdiary/wiki_style.rbに、DIFF差分をもとに過去に自分が加えた変更をもう一度加えたときに行頭の - を一カ所取り除き忘れたのが原因だった。
if /\A(?:http|https|ftp|mailto)\z/ =~ scheme
を、
if /\A(?:http|https|ftp|mailto|javascript)\z/ =~ scheme
こう(↑)すべきところ、
- if /\A(?:http|https|ftp|mailto|javascript)\z/ =~ scheme
こう(↑)してしまったのが原因。
Rubyでは ifといえども値を返すので、Stringに単項マイナスのメソッドは存在しないというエラーになっていたんだけど、そのエラーは tdiary/defaultio.rbの restore()で rescue NameErrorされて捨てられていました。
スクリプトのエラー(原因は自分だけど)で日記データが消えるのはウレシクナイ。スクリプトの間違いは起こりやすく修正も容易だけど、消えた日記データは復活しないのだから。バックアップをとっていてさえ直前のバックアップより新しいものは元に戻しようがない。
エラーで表示できない日記データでも TDiary::WikiDiaryなどのかわりに TDiary::BadDiary などとして保持しておいてほしいな(そしてデータファイルを更新するときには正常なデータと一緒に書き込む)、と思いつきだけで書く。
(怖くなってサーバーの tDiaryがまだアップデートできてません)
セクションごとに表示されるようになったのはもちろんのこと、飛び先が同一ページ内になったことが嬉しい。プライベートな変更(→20040228p02, →20050401p01)は維持するのが面倒くさいし、アップデートの失敗例が直上にあるので。
Productize and officially support the group_concat() SQL function.
試してみる。
>sqlite3 SQLite version 3.5.4 Enter ".help" for instructions sqlite> create table t1(c1); sqlite> insert into t1 values(1); sqlite> insert into t1 values(2); sqlite> insert into t1 values(3); sqlite> select * from t1; 1 2 3 sqlite> select group_concat(c1) from t1; 1,2,3 sqlite> select group_concat(c1+1) from t1; 2,3,4 sqlite> select group_concat(c1||0) from t1; 10,20,30 sqlite> select group_concat(c1, "-") from t1; 1-2-3 sqlite> select group_concat(c1, c1) from t1; 12233
期待通り。
もう create_function()で自作して Segmentation faultに困らされたりすることもなくなるね。(sqlite3-rubyの話)
もっとも sqlite3-rubyは一年以上のブランクを経て今年の二月に新バージョンが出てるので Segmentation faultは出なくなってると思う。下の変更点が多分そう。
2007-01-13 11:42 jamis
* Fix for use of callbacks (busy_handler, set_authorize and trace) (thanks Sylvain Joyeux, closes #2955)http://rubyforge.org/frs/shownotes.php?group_id=254&release_id=9438
数日前からこちら(SmallStyle - category プラグインを利用した タグクラウド 表示プラグイン)から入手したタグクラウド表示プラグインを手直ししたものを使っている。
直した理由は、日記を書かなくても毎日キャッシュが更新されるとか(<それ日記じゃない)、すぐに組み立てられる URLをキャッシュに含めなくてもいいじゃないかとか、addとか print_htmlというメソッドにプラグインの名前空間を汚されたくないとか、プラグインファイルの地の部分で returnするとどこへ戻るんだろう無事に戻れるんだろうかとか、そういうこと。いじった結果、ファイルサイズが増加し、キャッシュサイズもたぶん増加し、計算量が増加して、機能はほとんど変わらず、なので変更点は(この人目につかない日記にも)書けない。
本題。変更の過程でフォントサイズの指定をクラスからインラインスタイルに変更し、style="font-size: xxx%" というのを HTMLタグに埋め込むことにした。そして、フォントサイズのパーセンテージの決定方法を以前自分が書いたものから流用した。(ここが問題)。
以前書いたものはタグの出現数の分布を、最小フォントサイズ(100%)から最大フォントサイズ(200%)の間にそのままマップするものだった。これだと一つだけ突出したタグがあると他がみんなどんぐりの背比べになってしまう。では出現数の二乗根を使うとどうなるか、実験してみた。
[1, 2, 3, 10, 20, 50] # タグの出現数のリスト => [100, 102, 104, 118, 138, 200] # 出現数をそのまま使って font-size(100%-200%)を求めた => [100, 106, 112, 135, 157, 200] # √出現数 => [100, 117, 128, 158, 176, 200] # log(e)(出現数)
ここの日記のように一部のタグだけが突出していて、その他のほとんどのタグの出現数が 10以下のような場合は、出現数の自然対数を使うと出現数のわずかな増加にフォントサイズが敏感に反応する。というわけで、Rubyでは sqrtと logの時間コストがほとんど同じであることだし、タイトルを無視して logを使ってフォントサイズを決めることにした。
単純に出現数を使った場合、上で書いたように一つを除いて豆粒サイズになる問題があったが、logを使った場合は一部を除いほとんどが最大に近いサイズになってしまう問題が発覚した。あいだをとってルート。
http://www.machu.jp/diary/20070719.html#p02
はてブ指数というものに使われているという。定義は「N以上の数がN個以上含まれる場合の最大のN」
これなら一部のカテゴリがどれだけ突出していていようとも、「N以上である」としか評価されないわけだ。たとえば求めた H指数が 100だったとき、値が100の要素も10000の要素も「100以上である」とだけ評価されているわけで、重みは等しい。なるほど。でも H指数をフォントサイズの決定にどのように使おう。