ruby1.8.Xから1.9.xへの更新

macでMacPortsを使ってrubyをインストールする際
$ sudo port install ruby19 
しかし、これだと$ ruby -vをすると1.8.X系が現在のバージョンだと言われる。
代わりに$ ruby1.9 -vとすると1.9.X系が出てくる。


通常使われるrubyのバージョンを上げるには
$ sudo port install ruby19 +nosuffix
が正解。
以下のサイトを参考。ありがとうございます。
http://d.hatena.ne.jp/deeeki/20101030/mac_ruby19_rails3

email_fieldは便利だが

ユーザー情報の１つにE-mailがある。
Railsはemail入力ヘルパーemail_fieldがあり、

railsのview::<%= f.email_field :MAIL %>

出力結果::<input id="muser_MAIL" name="muser[MAIL]" size="30" type="email" />

と、HTML5の機能を用いてsubmit時にバリデーションを有効にさせることができる。
が、望む機能はフォーカスアウトした際に有効になる仕組み。どうすればいいのだろう。調査調査。

Time.nowの実装

生年月日のセレクトボックスを作る際以下の実装をする。

<%= f.date_select :BIRTHDAY, :use_month_numbers => true, :start_year => Time.now.year - 80,:end_year => Time.now.year %>

Time.now.yearと実装すると、”2011”と返してくれる。

生年が1930-2011まで指定されている(絵では表現できていませんが)。

このTime.nowだが、今回はレコードの更新日付に使おうと思い

def createメソッドに以下の実装を施した。

　@usr = Muser.new(params[:muser])

　#新規登録時間を登録

　@usr.INS_DATE = Time.now

　@usr.save

すると想定通り、INS_DATEには現在日付が入っている。結果は以下の通り。

2011-10-27 13:12:44

ん？何故昼時間が登録...あ！これ米国時間だ（この間数秒）。

なのでTimeZoneをTokyoにして再度実行。

application.rbに以下の行を追記

#TimeZone変更のため

config.time_zone = 'Tokyo'

config.active_record.default_timezone = :local

３回目のチャレンジでうまくいきました。今は夜。

Railsは自らの開発環境との戦いが大きなリスク

いきなりrakeコマンドが打てなくなったのですね。
こまったな、ともう一回プロジェクトを作成
$rails new photo575 -d mysql
このへんで気づいたのですが、railのバージョンが3.0系から3.1系に上がってたようです。
railsのバージョンが3.1になるとrailsのmysql2の設定も異なるようです。

ActiveRecord 3.0系 最新:3.0.10 mysql2 最新:0.2.13
ActiveRecord 3.1系 最新:3.1.0.rc6 mysql2 最新:0.3.7

知らずにmysql2:0.2.13を使っていると、サーバ起動時に以下のエラー

WARNING: This version of mysql2 (0.2.13) isn't compatible with Rails 3.1 as the ActiveRecord adapter was pulled into Rails itself.
WARNING: Please use the 0.3.x (or greater) releases if you plan on using it in Rails >= 3.1.x


サーバは上がれど、検索ができない状態になるのです。はい。
rails3.1はいささか勝手が異なり難しいです。悪戦苦途中...

エンティティに存在しない「受諾」カラムを追加。

今日は「利用規約に同意する」の機能を追加。

new.html.erb  

<div class="field">

    <b>利用規約に同意する</b>（同意する場合チェック）。<br>

    <%= f.check_box :agreement %>

</div>

modelクラス

  validates :agreement,

    :acceptance =>true

実装完了。さてチェックをせずに登録ボタンを押す。

・01.Agreementがカラム名そのまんま

・02.受諾してください、とは強制しているようでイケてない。

 まずは02の方を訂正

ja.yml

  errors:

    format: "%{attribute}%{message}"

    messages: &errors_messages

      inclusion: "は一覧にありません。"

      exclusion: "は予約されています。"

      invalid: "は不正な値です。"

      confirmation: "が一致しません。"

      accepted: "を受諾してください"

      accepted: "を同意するにチェックがありません。"

しかしこの受諾検証のメッセージを変えてしまった事は、他の受諾検証もこれに倣う事になる。後々後悔しそうだが、ひとまずこれで。

さて試してみる。

メッセージが変化。あと一息。 

ja.yml

  activerecord:

    attributes:

     muser:

      USER_ID: "ユーザID"

      DISP_NAME: "表示名"

      agreement: "利用規約"

これは一瞬迷った。muserエンティティには存在しないカラムを、muserのカラム名定義部に入れていいのか、ということについてだが、他に方法も思いつかないのでコレで行く。

完成。意外とすんなり行った。

情報源は以下の書籍。

バリデーションによる入力規制02 ローカライズ（日本語化

なんとか日本語化に成功。今回は調査から動作確認まで3hの工数を消費。

何が難しいといえば、railsのバージョンによって推奨される方法が異なる事で、どの情報をもってローカライズすればよいのか非常に迷った事、必要とする情報だけをフィルタリング出来なかった事が反映。あれもこれも、では駄目。

今回調査したrailsのローカライズの推移は

1.エラーを扱うクラスをオーバーライドしたり、ActiveHeartでゴリゴリ書く「力技」

2.ruby-gettextを使う。

3.i18nを使う。

私が一番最初に「これはいける」と思ったのは1.のゴリゴリ型。最初はいいと思ったが、工数がかかって仕方がない。また日本語が、各modelに散ってしまうのもメンテナンス性が悪い。

結果、2はやらず、3のi18nに到達。参考にした資料は
http://www.st.rim.or.jp/~sakisan/rails3_ja.html（Rails3 エラーメッセージ日本語化のメモ）
上記リンク先にも書いてあるとおり。ステップは以下の通り

イ.ja.ymlをネット上からダウンロードし、config/localesに配置

ロ.config/locales/ja.yml に以下の行を追加（サンプルは私の環境に最適化。
activerecord:

 attributes:

   muser:#エンティティ名

    USER_ID: "ユーザID"#カラム名

    DISP_NAME: "表示名"#カラム名

helpers:

 label:

  muser:

   USER_ID: "ユーザID"

   DISP_NAME: "表示名"#カラム名

ハ.config/application.rbのどこかに以下を追記

config.i18n.default_locale = :ja

二.webサーバ再起動

これで終了。簡単。但し、i18nを最初から使うという結論に最初から辿りつけていればの話。でも目標が達成できてよかった。

バリデーションによる入力規制01 事始め

Railsのバリデーションは非常に簡単。modelクラスに以下のように実装する。

  validates :USER_ID,#入力制限を加えたいカラム

    :presence => true,#Not Null制約

    :uniqueness => true,#一意性制約

    :length => { :minimum => 3, :maximum =>30 }#桁数範囲制約

viewに以下を実装する。

<% if @usr.errors.any? %>

　<div is ="error_explanation">

　　<h2><%= pluralize(@usr.errors.count, "個") %> のエラーが存在します。</h2>

　　<ul>

　　　<% @usr.errors.full_messages.each do |msg| %>

　　　　<li><%= msg %></li>

　　　<% end %>

　　</ul>

　</div>

<% end %>

以上で上の絵のようなチェックを走らせる事が出来る。簡単。

但し以下の問題点がある。

1.エラーメッセージが英語

2.カラム付近へエラーが出ていない。

3.エラーのカラムが分かりにくい（カラム周囲が色が変われば良い）

4.規約に同意、などといった新規のみチェック等が制御できていない。

明日からは、上記の問題を解決していこうと思う。

いきなりrailsが消えた??

朝から本職の会社で「伸び悩むゴルファー練習会」が開かれたり、午後は家族サービス＋夕飯のポークシチューの準備で忙しく、疲れ果て集中力も切れたので近所のマックで気分転換も兼ねて出向く。

さすがマック、土曜の夜21時を超えているのに混んでいる。
勉強する高校生やら、13インチのmacbook proで作業する方やら、vaio pの小さな画面で何やら一生懸命に文字入力している方とか...うん、疲れているけど頑張らねば、という気分になる。いい場所。

というわけでホットコーヒーを片手に席につき、今日もrails sとWEBrickを動かそうとすると

$ rails s
Rails is not currently installed on this system. To get the latest version, simply type:

    $ sudo gem install rails

You can then rerun your "rails" command.

「あんたのMacからRailsは逃げ出しました(異訳)」と書いてある青天の霹靂的なエラー。え、おかしい、一昨日まで動いていたrailsがトンズラするとは。なんか変なさよならコマンドでも打ったかな...

と迷っても仕方がない、再インストールするしかないな、とさっさと諦め帰宅、情けないことにモバイル回線は無契約。トホホ。でもやる気をもらったから無収穫ではなかった。また来よう。

確認画面の必要性

アプリを開発する上で、ユーザが何らかの登録アクションを行う際に必要になる「確認画面」。

Webアプリを使用していると、この確認画面にまでたどり着くまでに様々なチェックに引っかかり四苦八苦した事は１度はあると思われる。

開発者からすると、どうしても入れてもらいたいnot null制約がある項目については厳しくチェックしたいところはわかるが、ユーザからすれば、こんなん要らないだろ、という項目もある。しっかりと設計して、必要最低限の入力項目にするのが目指すべきところ。

その確認画面をこれからrails上で機能として開発しようと思う。confirmが鍵のようだ。

"完成したら出す"位で良い、「個人開発のスケジュール」

システムを開発する人間は、皆エンジニアである。自動車を作る人は、どの工程にいる方でもエンジニアであるように、システムを開発する方も最上流のコンサルさんを除けば、皆エンジニアである。横文字にするから分かりにくいのであれば、自動車を作る方もシステムを作る方も皆「技術者」である、といえば分かりいいかもしれない。

エンジニアとして、他のメンバーと共同で1つの作業をする為に、進捗を確認するための「スケジュール」は不可欠である。これがなければ、メンバーはいつ迄に何を作らなければならないか分からない、都度リーダーに質問する。リーダーはクリティカルパスが遅れているのかどうか把握出来ない。チームとしての進捗を把握するためのツールとして重要。私も本業の現場では、スケジュール線を引く任にある。

ただ、こうして個人で、それも既婚子持ちの人間が、少ないプライベートの時間を削って開発していると、すぐに気づくことがある。スケジュールは守れない、というか作ってられない。裕福な親元にいる学生さんなら時間を潤沢に使えるだろうが、こちらは本業も多少の責任を持つポジションであるので、少し残業してしまえば開発の時間なんぞ消し飛んでしまう。

スケジュールを作れない、という訳ではないが、スケジュールを守れないという事は、リカバリプラ員を考えることになる。本業でスケジュールが遅延するのであれば、スケジュールに余裕があれば負荷崩しをしたり、余剰リソースを探したりして対応を考える思考になるが、プライベートは１人であり、余剰時間も限られている。つまり簡単に自分というステークホルダーに対する納期遅延が発生する。この納期遅延はやる気ダウンに直結する。

プライベートの開発は納期死守のためのリカバリは睡眠時間や家族とのコミュニケーションを犠牲とする事になる。これはNGである。身が持たない。

「私は個人で趣味の開発をしていて、スケジュールもばっちり日単位で引いてオンスケですわガハハ」という人に出会えば尊敬してしまう。よっぽど意志の強いタフネスな方なのだろう。私は三下の為、これをすれば本業も家庭も疎かになる。だからどうせ守れないスケジュールなんぞ要らないだろという結論に達している。

但し誤解して欲しくないのは、全くのノースケジュールノープランが良い、と言っているわけではない。私は一次リリースを来年４月１日に定めている。これは目標である。

そのリリース目標に向けて月単位で、何をすればよいかのグランドスケジュールぐらいは引いている。それぐらいでいいと思っている。お客様から急なゴルフやツーリングのお誘いが来れば週末が吹っ飛ぶわけだから、週に落としこむのも危険だと思っている。

ということで、言いたいことは、私の好きなゲーム、米Blizzard社の「Diablo」の責任者の言葉を流用する。「完成したら出す」と。

これぐらいの気分で肩の力抜いた方が、継続すると思う。