jQuery Date Pickerを使おうとする

HTMLフォーム上でカレンダーによる日付入力が必要になったので、いまは jQuery をメインにしようと計画していることだし、jQuery Date Picker を使おうとしてみる。

問題1 - 週が月曜からスタートしている

date.js のあとで、

<script type="text/javascript">
Date.firstDayOfWeek = 0;
</script>

とやればいいらしい。

問題2 - いろんな部分が英語

これも date.js で定義しているので、上書きすればいい。

<script type="text/javascript">
Date.dayNames = ['日曜日', '月曜日', '火曜日', '水曜日', '木曜日', '金曜日', '土曜日'];
Date.abbrDayNames = ['日', '月', '火', '水', '木', '金', '土'];
Date.monthNames = ['1月', '2月', '3月', '4月', '5月', '6月', '7月', '8月', '9月', '10月', '11月', '12月'];
Date.abbrMonthNames = ['1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12'];
</script>

問題3 - 月表示部分の順序がおかしい

上のように日本語化しても、順序は "Dec 2007" の英語版と同じなので「12月 2007」のようになる。これは jquery.datePicker.js にハードコーディングなので、「2007年 12月」のようにしたければ直接変更するしかなさそう。

問題4 - 年月日が個別の入力欄の場合の使い方が難しい

正確には、サンプルがない。select要素で選ぶタイプならサンプルにあるのでこれを参考にすればなんとかなるけど、年月日のフィールドのidを固定で与えていて汎用的ではないし「開始日・終了日」みたいに複数つくる場合も面倒。この部分は自分でなんとかする必要がある。

そもそも、最初のサンプルからして謎で、

$(function()
{
  $('.date-pick').datePicker();
});

2つの入力欄のうちどっちに入るかはどうやって指定/判断するのだろう？（DOMツリーでいちばん近いところとか？）。これがわかれば、idを固定にしないように変形できるかもしれないのであとで調べてみる。

Ruby認定試験

合格だそうで。

今まで、周囲に難易度を聞かれたときお茶を濁すような回答をしていたが、これで心置きなく「簡単だった」と言うことができる。落ちておいて言ってもただの馬鹿だしなあ。

若者の献血離れが深刻

若者の献血離れ深刻　１０年前の４割に減

山口県赤十字血液センターの話。で、この話に出てくる「センターのまとめ」た、献血離れを示す資料は？というと、案の定ウェブサイトに載っていないのだった（この手の話が出るときはいつもそう。ちょっと前の酒離れとか）。現状の厳しさを他人に訴えるときに、きちんとした資料を提供しない人が多いのは何故だろう？

http://y-hard.hp.infoseek.co.jp/chosa/cont/data2002b.htm#205
「山口県赤十字血液センタ の一般処遇品です。（中略）2002年 6月 1日（中略）1. 金券 500円分 (図書券) 」

http://www.47news.jp/CN/200211/CN2002112401000152.html
「血液の国内自給や売血禁止を盛り込んだ血液法の施行に伴い、日本赤十字社は今月から図書券など献血者への金券配布を廃止した。」2002年11月の記事。

http://www.ne.jp/asahi/home05/house/dat/kenketsu91.html
「図書券廃止により学生の多い松本ルームなどでは若いドナーが目立って減ってしまったそうです。」

グラフにすると2002～2003年あたりで激減してるから出せないんですなんてことはもちろんないとは信じておりますが。

Struts 2をいじり中

Struts 2 は Struts 1.xよりだいぶ楽になっているんだけど、リンク作るのに2つのタグと一時変数みたいのまで必要なのはなんとも。

<s:url action="blog" method="show" var="url">
  <s:param name="id">1</s:param>
</s:url>
<s:a href="%{url}">BlogAction#showへのリンク</s:a>

試してないけど、伝家の宝刀 jsp:attribute を使えば、形だけは1つにまとめて一時変数的なものも消せるのだろうか……。

<s:a>
  <jsp:attribute name="href"><s:url action="blog" method="show">
    <s:param name="id">1</s:param>
  </s:url></jsp:attribute>
  <jsp:body>BlogAction#showへのリンク</jsp:body>
</s:a>

逆に長くなってしまった。結局、最初の方法しかないのか。

アクセス解析ツール＆サービス

アクセス解析ツール＆サービス13種類徹底比較！ 史上最強の機能比較表

これを参考にしてAdBlockを設定すれば「主要な」トラッキングを弾くことができそうだ的な意味で有用なまとめ。
（shinobi.jp とか良く見かけるんだけど、主要なサービスじゃないのかな。）

データをhiddenで受け渡す（自分用まとめ）

HiddenとWebアプリケーション
Hiddenを使う必要のあるアプリケーション

いくらでも穴がありそうで怖いが、一応個人的な考え。

何個でもブラウザウインドウを開いて同時に処理することを許す（たとえば、入力⇒確認⇒完了がウインドウごとに並行して行えるような）場合、hiddenは有用だと思うし、場合によってはいまでも採用することもあるんじゃないかなぁ、と。（上のサイトが引用しているサイトの例に出てるのは注文の場面なので、複数ウインドウで同時にやるってことはあんまりないってことは置いといて）

そういう場合は各々のウインドウが個別に状態を持つ必要があるので、クライアントのウインドウごとに処理中の状態を保持させる（つまり、hiddenで持ちまわす）のが一番自然な実装に思える。セッションを使っても同じようなことはできるけど、hiddenではクライアントに持たせていた処理中情報をサーバ内に持たなければならず、サーバリソースに制限ができてしまうし、管理も面倒くさい。

hidden方式とセッション方式の違いは、クライアントからの入力が毎回行われる（最初は手動で、あとは自動で）か、最初だけかという点だけで、送られてくるデータの検証を必要なタイミングで行わないと死亡というのは同じであり、それを行っていれば安全性に根本的な違いはないんじゃないだろうか。（ただし、見せたくない内部コードのようなものをミスでhiddenに出してしまう、とかはあるかも）

hiddenの利点は、ステートレスであるためクライアントがウインドウをいくら開いても何の問題もないこと。欠点は、アプリケーションを作るときに処理中データをhiddenに吐き出したりその値が返ってきたとき再度検証したりするのが面倒くさいということと、ユーザ入力から別のデータを作成するような場合に、実装によっては毎回作り直す必要があり処理時間を食うかもしれないということか？

セッションに入れてしまう方法の利点と欠点は全く逆で、アプリケーションは物凄く簡単に作れるけども、状態をサーバ側に保持しなければならないために、同時に処理できる数に一応制限があることだ。簡単というのも何も考えなければの話で、どんどん浪費される「ウインドウごとの処理状態」に使うリソースが無視できないレベルになってくるとちょっと面倒そうだ。

Ruby on Rails 2.0では、セッションデータはデフォルトでCookieに保存するようになったそうだ。ちょっと違う話ではあるけど、これも、出来ればステートレスにしたい、サーバリソースは使いたくないというhidden的な考えに似たものを感じなくもない。

SJISファイルシステムでMercurial

対応する気は無いらしい。
http://selenic.com/pipermail/mercurial-devel/2007-October/003174.html

「ファイル名はファイル内のデータと同じで、（Unicodeに変換することも含む）いかなる変更も加えるべきではない」という原則を、SJISみたいな雲古な文字コードのために崩すつもりは無いって感じみたい。まあ、残念ですが御尤もです。よく見ると「伝説のエロ仙人」とかいう名前の人がさりげなく真面目な投稿をしていたりするのが救いだ。

日本語ファイル名なんて使うのはせいぜいドキュメント類くらいだから、メリットがあればソースコードはMercurial、ドキュメント類はSubversion、というのもあり、かなぁ……。

このへん、Javaでは最初から国際化のことが考られているので（Unicodeマッピングの問題はあったけど……）、シングルバイト圏の人が何も考えずに作ったようなプログラムであっても、文字コードの問題が起こることはほとんどない。

new File("表ソ十.txt").exists()

みたいなプログラムも、その環境のファイルシステムでそういう名前のファイルが存在すればきちんと扱うことができる。

ひょんなところで、改めてJavaの有難味を感じてみたりして。

WindowsでRedmine＋Mercurial を試していろいろ敗退

Redmine でも Mercurial をリポジトリとして使うことが可能らしいと知ったので同時に試してみた。

Redmine のインストールは、SVNでtrunkを引っ張ってきてdoc/INSTALL の通りにやるだけだからまあ簡単。最初、

C:\usr\redmine\trunk> rake db:migrate RAILS_ENV="production"
(in C:/usr/redmine/trunk)
rake aborted!
no such file to load -- initializer
C:/usr/redmine/trunk/rakefile:4

とか謎のエラーが出て困ったものの、よく見たら肝心の rails のインストールがまだだった（SVN版だと vender/rails に無い）。gem install rails --include-dependencies して解決。

Mercurial のインストールも Binary Packages からダウンロードしたインストーラ一発で非常に簡単。とりあえず設定はあとにして

C:\repos> hg init sample

ローカルリポジトリ作成。ここまでは順調。まずはシングルバイト発祥ソフトの泣き所から試してみる。

C:\repos\sample> echo foo > ソ十表.txt
C:\repos\sample> hg add ソ十表.txt
ソ十表.txt: No such file or directory

やっぱりか……。
ソース版をインストールすれば こちら の対応でなんとかなるそうだけどソース版のインストールにはCコンパイラが必要らしい。Cygwinですか。

とりあえずこの問題は無視して、「テスト.txt」というファイルを登録し Redmine で化けずに見られるかどうか試してみた。こっちもダメ。Redmine の /lib/redmine/scm/adapters/abstract_adapter.rb とか mercurial_adapter.rb あたりでSJIS⇒UTF-8変換をかけると表示だけはうまくいくようになるけど、パラメータのエンコーディングの問題かなにかで日本語ファイル名からのリンクはだめ。

とりあえず眠いのであきらめる。Windowsの道は険しい……。

分散型SCM

リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」

から改めて分散型SCMというものを見直す。CVSからSubversionに移行しようとしていた時期に、分散型というものもあってArchとかあるよとは聞いたけど、難しそうだと食わず嫌いしてしまった覚えがある。ちょっと見た限りでは複数拠点開発とかマージトラブルなどのSubversionで面倒くさいところがうまくできている感じ。↓の辺りを見るとMercurialが良さそうなのでMercurial使ってみようかな。
Pythonで分散バージョン管理
Mercurial と Trac のメモ

個人的にはMercurial自体がPythonで出来ていて、Tracプラグインも作られていることがいちばんの決め手だ。

Ruby認定試験受けてきた

東京会場で受けてきた。

解答欄がひとつずつずれていたとかいうことでもなければ合格はできたと思うけど、この程度で Certified Ruby Programmer と呼べるのかどうか……以下感想。

• 普段使いもしないコマンドラインオプションとか環境変数とかirbコマンドを必死こいて覚えていったら全く出題されず。覚えてもしょうがないから問題無しでいいやという判断自体は正しいと思うけど、それなら出題範囲から外せばいいのに……。
• 言語自体の仕様よりも、組み込みクラス（特にArray,Hash,String。あとDir,File,Range,Timeあたりが少し）のメソッドクイズのほうに重点が置かれていた。
• わかりづらい言葉遣いは勘弁してほしい。たとえば、

  いくつかの代入文とか
  
  if true
    puts 何か
  elsif ～
    puts 他の何か
  end

  みたいなプログラムの「結果がどうなるか」とか。「結果」が「最後に返される値」のことなら nil だろうが、「出力」のことなら「何か」になるとか、そういうの。しかも「nil」も「何か」も選択肢に存在するという……。