たくさん出るRails本
どうやらRails本のラッシュらしく少なくとも三冊は出版される模様。
- ライド・オン・Rails (ξ*゜ー゜)ξ { 遅レス。)
- はじめよう Ruby on Rails (ふぇみにん日記)
- 優しいRailsの育て方 (ヽ( ・∀・)ノくまくまー)
RailsによるアジャイルWebアプリケーション開発
実はまだ1章までしか読めていない
Rails本なのだけど、そのわずか数ページでもぐっと興味をひきつけられる本だ。手を動かしてみようという気になる。良い本だとは方々で聞いていたが、まさにその通りなのだろうと思える。評判通り、技術的な話題に移る本編でもきっとこの調子なのだろう。本筋以外のことを考えずに読める日本語版を待ってて良かった。
と、いいつつも読み進められないのは、まさに手を動かしながら読み進めたいという気持ちにさせられたのに、手を動かせる環境にいられる時間をどうにもとれないからで、こう書いていても何だかおかしな状況である(校正やらなんやらでつまっていて、そっちはそっちで手を動かしながらでないとならず、とりあえず今はどうにもならない……)。
後続の書籍も出てくるようなのだが、特に前述したような面でこの本に対抗するのはなかなか大変そうだ。自分でもこういう本を書いてみたいものだなあ。
雑誌拾い読みメモ: 日経ソフトウェア 2006.03号 1
「Railsアプリケーションを日本語化しよう」という記事の「ステップ1」に以下のような記述があった。
まず、RailsでのRubyの動作モードを、データベースに合わせてUTF-8モードに変更します。(略)environment.rb(略)を開き、先頭に以下のコードを追加してください。
$KCODE = 'u'
$KCODEは、Rubyの処理する文字コードを指定する特別な変数で、uはUTF-8を表します。
この設定によりRubyの動作モードがUTF-8モードになります。
[日経ソフトウェア 2006.03号(68ページ)より引用]
以前も同様の説明を読んで、一般的にそういうものなのかなあと疑問に思ったのだった。というのも$KCODEの指定は正規表現のマッチの仕方を変えてしまうので、副作用が大きすぎるのではないかと思えるので。
で、実際にはRailsでどういう対応がなされているのかとざっくり調べてみたところ、直接的にはactionpack/lib/action_view/helpers/text_helper.rbで定義されているtrancateメソッドで文字列の切りつめのためにString#splitに//を渡して文字に分割した後にArray#joinで必要な長さの部分文字列を得るというのをやっている程度に見える。
その他、検索した中では次のようなのが見つかった。
$KCODE = 'n'だと、xsd:base64になっちゃうみたい。
ActionWebServiceというかSOAP4Rかな。前からこうでしたっけ?
[Journal In Time - ActionWebServiceで日本語を扱うには$KCODE = 'u'が必要より引用]
$KCODEを指定することによりRailsのエラー画面で文字化けしなくなったり、正規表現で.がマルチバイト文字にマッチするようになる。
[UTF-8で運用する :: wiki.rails2u.comより引用]
Railsをいったんおいて、Rubyとしてはどうなのかとソースをgrepしてみたところ、正規表現のマッチが変わるのと、String#inspectでの出力の仕方が変わる程度に見える(出力が自動的に変換されるとかはRubyとしては当然ない)。この正規表現のマッチというのは引用にある「.」の動作やtrancateメソッドで用いられている//の動作のこと。標準添付のライブラリの中には$KCODEを参照しているものもあるし、TMailも一部で参照してはいるが……。
Ruby全体としての影響範囲は限定されている一方で正規表現という点ではけっこう大きな変化がみられるわけで、そう考えると$KCODEによって設定されるのは「Rubyの動作モード」といったものではないし、影響の範囲を知らせずに呪文のように「$KCODE = 'u'」と説明してしまうこの記事のような書き方はいまいちなのではないかなと思える(他方、記事の後に引用した二つのテキストでは限定的に説明されている)。
まあ、そういう記述が必要な場面はあるのだろうと思うのだけど(あるいはアプリケーションを開発するにあたって$KCODE = 'u'を前提にするのはアリだとは思うけど)、それにしても「正規表現の動作が変わるよ」などの注釈があれば、というよりもなぜそうするのについての説明があれば、変に誤解されずにすむと思うのだけどなあ。
ActiveRecord-1.13.0でsqliteのdbfileがdatabaseになった 2
Railsを0.13から0.14.3に更新するとActiveRecordが1.13.0になって、sqliteのためのdatabase.ymlの書き方が少し変わった。従来dbfileで指定していたのをdatabaseで指定するようにする。ただしdbfileもエイリアスで使えるのであわてなくても良い。
どこにも問題なさそうなのだが、手元の環境でははまってしまった。
というのも、なんでだか、どこから持ってきたのか、database.ymlでこんな書き方をしていて、おかげでdatabaseに変な値が設定される一方でdbfileは見られなくなり…… ということが起きたのだった:
development: adapter: sqlite3 database: typo_dev dbfile: db/typo_dev
databaseにdb/typo_devを指定するようにして解決(dbfileの行は消した)。カレントディレクトリに空のtypo_devが出来てるのを見て気付いたのだが、ログに何も出なかったこともあって結構時間がかかった。
donrails
期待の日記システムdonrailsが公開された。コードはこのあたり。
すぐにというわけにはいかないけど早めに試してみよっと。


