最終更新: 2009-08-28T23:41+0900
表示方法はこう。
# coding: utf-8
require 'date'
add_section_leave_proc{|date, index|
diary = @diaries[date.strftime('%Y%m%d')]
next unless diary # in case @mode == 'preview'
section, sidx = nil, 0
diary.each_section{|sec| sidx+=1
if sidx == index
section = sec
break
end
}
lm = section.last_modified rescue next
next unless lm
lm = DateTime.new(*(lm.utc.to_a.values_at(5,4,3,2,1,0))).new_offset(Rational(135,360)) # 日本時間
lm.strftime %<<p class="lastmodified">最終更新: %Y-%m-%dT%H:%M%Z</p>> # 色分けテストとして、あえてタグと同じアングルブラケットで囲ってみた。
}
DateTimeのオフセットの単位がわからんかった。ブラウザのブックマークが「Rubyリファレンスマニュアル - 20051129」だからなあ。るりまには載ってるかも。とりあえず「fraction of a day」(date.rb documented by William Webber)とのこと。慣れない Rationalを使ったもんだから Rational(135,360)と書くべき所に Rational(135/360)と書いてしまい、オフセット 0の結果にしばし首をひねった。Rational()の呼び出しより引数の評価の方が先だからやむをえないことだけど、分数を表現するのにはやっぱり / を使いたい(使ってしまった)。Fixnumと Bignumのシームレスな移行のように、 Rationalへも融通無碍に切り替わって欲しい。利用者には Numericだけを利用しているように思わせる、ということ。必要なときに整数化(小数化)メソッドを呼ぶし、変数に整数(や分母を 1に約分できる分数)が入ってることを利用者が知っていれば、そのまま整数を前提としたメソッドを呼んだりできるといい。変わるのは、整数型の演算結果が整数型であることを前提にした(旧来の言語の呪縛に過ぎない)切り捨て除算がなくなる以外にあるだろうか。それも Pythonみたいに // を割り当てれば、無駄な有理数化、再整数化を避けられる。実感に基づいて、既に通った(んじゃなかったっけな？)議論を蒸し返してみました。俺は整数と小数の垣根を取っ払った JavaScriptを、最初は驚いたけど、評価している。JavaScriptのシンプルさが好きだ。セミコロンインサーションも、Cより怠けることを許していながら、Rubyの改行をターミネータにするやり方よりフォーマットが自由で、最高にバランスがいい(はまるのは returnだけだ)。require 'rational'; 10.to_r/2 とか不格好すぎるでしょ。ハードウェアと型から離れて本質に戻りましょう。算数で割り算と分数は同じものだったはずだ。<追記@2009-08-22>require 'mathn' がつまり Fixnumと Bignumと Rational(と Complex)をより親密にするおまじないでした(いまさら何を)。mathnって、読めない(マスエヌ？)のと名前から中身が想像できないのとで意識せず無視してたけど、Rationalとセットで見かけることが多かった気がする。それはそうと、Rationalや Complexの細々した議論に埋もれて全体の方向性が見えない。Ruby 2.0あたりでは require 'mathn' が不要になっているんだろうか……。</追記>
るりまにはスタンドアロンサーバー版と chm版より、スタティック HTML版を用意して欲しいなあ。chmだと閲覧が IEベースになってしまって、文字の大きさやスクロール量、進む戻るが自由にならなくて使いにくい。マニュアルサーバーを起動しておくのは嫌ですよ。view.cgiで CGIしようとしたらリンクがルートからの絶対アドレスなせいで Not Found。Apacheは既に動いてるから、名前ベースのバーチャルホストや待ち受けポートの追加で、るりまに一つのホスト(or ポート)を与えることはできると思うけど……大仰なのでやらない。base_urlのオプションが用意されてるから view.cgiの設定を間違えてるだけの気もするけど……わからない。
組み込みの Timeが UTCと localtimeしか扱わないのがもったいない。任意のオフセットに基づいた日時を出力したいだけだから、DateTimeは牛刀な印象がある。<追記@2009-08-21>よーくかんがえよー(命令形)、・・・・・・・・・ー。なんてことはない。オフセット分だけ未来(過去)の UTC時刻が即ちローカルタイムだよ。当たり前すぎて俺が何を言いたいのかわからないでしょう。先のスクリプト片の最後は DateTimeを使わずにこう書ける、ということです。
lm = section.last_modified rescue next
next unless lm
offset = 9 * 60 * 60 # 秒
lm_local = (lm + offset).utc # UTCと見せかけて lmの地方時。
%<<p class="lastmodified">最終更新: %d-%02d-%02dT%02d:%02d%s%+03d%02d</p>> %
[lm_local.year, lm_local.month, lm_local.day, lm_local.hour, lm_local.min, offset/60/60, offset/60%60]
}
……てなことを、makerss.rbの中の TDiary::RDFSection#time_stringが
g = @time.dup.gmtime l = Time::local( g.year, g.month, g.day, g.hour, g.min, g.sec )
gmtimeに基づく年月日時分秒からローカルタイムを作っている部分を見ていて(遅まきながら)気付いた。gmtimeも localtimeも皮をむけば UNIX epochからの経過秒に過ぎないんだから、どういう意味を持たせるかはこちらの自由だった。まあ、比較はできなくなりますが……(lm.to_i ≠ lm_local.to_i はその意味(同じ瞬間の別表現であること)を考えると望ましくない結果)。</追記>
脱線終了。表示するまでの仕込みがこんな感じ。
主に plugin/makerss.rbからの要請で更新日時を記録したいので、ちょっとした修正では最終更新日時は更新されない。とかいいながら、この日記には変更のあったセクションを見つける別の方法が入っている(20090705p01)ので makerss.rbが最終更新日時を利用するようにはしていない。
最初にポストされた時刻も有用だろうか？ 日記だから最初にポストされた日はほとんど確定してるし、時刻まで知りたいとも思わないけど。
WikiSectionに last_modifiedプロパティをくっつけたけど、WikiSection自体はこれを管理してなくて、外部から操作されるだけだってのがいけてない。やっぱり to_src()と initialize()が DUMP & LOADを担う(last_modifiedや authorその他の情報をフォーマットに含める)か、メソッド群を整備してこちらの望む操作を WikiDiary、WikiSection自身にやってもらう(自分でやるから付帯情報のコピー漏れも発生しない道理)のがいい。
「編集」でセクションを追加したとき、更新日時のコピー処理でのぬるぽを修正。(if old_section and...を追加した)