カスタム版 strftime 関数 - Tociyuki::Diary
glibc の strftime(3) は、日本ロケールになっていると、%E で年号を、%O で漢数字で日付時刻を表す機能があります。Perl からも、strftime(3)を POSIX モジュールや Time::Piece モジュールから使うとデフォルトで現在のロケールを setlocale してますので、これらの表示をさせることができます。 $ perl -e 'use Time::Piece; say localtime->strftime("%%Ec = %Ec\n (略)")' %Ec = 平成23年08月02日 00時38分48秒 %EC = 平成 %Ex = 平成23年08月02日 %EX = 00時38分48秒 %Ey = 23 %EY = 平成23年 %Od = 二 %Oe = 二 %OH = 〇 %OI = 十二 %Om = 八 %OM = 三十八 %OS = 四十八
東京電力でんき予報を Perl 向けデータにする Net-Tepco-Forecast-0.003 β版 - Tociyuki::Diary
東京電力でんき予報の CSV ファイルが 2011年7月1日よりリニューアルしていたので、Perl で扱いやすいデータに加工するモジュールをお試しで書いてみました。ソースは GIST に置いています。 ⇒ https://gist.github.com/99f1c5571662af5abd70 (Net/Tepco/Forecast.pm) 2011年7月2日バグ修正: 0.003 epoch の計算に timelocal ではなく timegm を使い、JST のタイムゾーン・オフセットの補正をおこなうようにしました。これにより JST 以外のタイムゾーンに設定してあるマシンであっても、正しい epoch が得られます。 2011年7月2日バグ修正: 0.002 tomorrow_capacity と tomorrow_estimate の period と period_to が当日の
CGI-Hatchet-0.004 - Tociyuki::Diary
玄箱等の非力な CGI 環境向けの PSGI アプリケーション・フレームワークで使う目的で作っている PSGI レスポンス・コンテナ兼フォームデコーダ関数モジュールです。依存モジュールを削り込んでいます。まだ書いている途中ですけど、バックアップを兼ねて github へリポジトリをおくことにしました。CPAN モジュールにする気は今のところありません。 ⇒ http://github.com/tociyuki/libcgi-hatchet-perl インスタンスはリクエストのデコード時に参照したいパラメータと PSGI レスポンスを格納することを前提にしています。リクエストのフォームデータとクッキーのデコード結果は、関数の戻り値に返すだけです。デコード結果は Hash::MultiValue の初期化に都合が良いようにペアリストにしてあります。CGI::Hatchet インスタンスにも格納
MENTA::Template に対抗して Tepl なるものを作ってみる - Tociyuki::Diary
⇒ https://github.com/tociyuki/libtext-tepl-perl 関連 ⇒ Tepl のランタイム用に汎用 filter を作る - Tociyuki::Diary 軽量なウェブ・アプリケーション・フレームワーク MENTA は、軽量化の仕掛けに学ぶべき点がいくつもあって、興味深くソースコードを読んでいます。が、Mojo::Template をポートした MENTA::Template に、どうしても馴染めません。例えば、pager.mt から抜粋した、これ: ⇒ release-0.09/app/controller/pager.mt ? my $pager = shift ? my $action = shift ? my $page_n = $pager->{page} ? if ($pager->{page} == 1) { 前 ? } else {
単純データのシリアライズ速度比較 - Tociyuki::Diary
最近の CPAN モジュールで Storable を当たり前のように使っているのをみかけるのですが、入れ子になっていないフラットなハッシュ程度の単純なデータをシリアライズするには重いのではないかとベンチマークをとってみました。ついでに、以前から比較してみたかった pack/unpack の固定長と可変長の比較もやってみました。ベンチマークをとるのは、ハッシュのシリアライズでありがちな要素数の少ない文字列リストと、配列のシリアライズでありがちな要素数が多い整数リストの 2 つにしました。 結論 要素数が少ないハッシュのシリアライズには split/join が速いようです。 要素数が多い整数のリストのシリアライズには整数 unpack/pack が速いようです。 可変長文字列 unpack/pack は split/join よりも遅いようです。 単純なデータ構造では Storable のメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
