options_form_collection_for_selectの初期選択が効かない
アプリケーションでは，データベース内に格納された各種マスタの一覧から１つ選択する，という行為が良く行われる。Webアプリケーションにおいて，マスタの内容を一覧表示する際は，selectタグとoptionタグの組み合わせが多く使われる。Ruby on Railsのactionpackに含まれるaction_viewヘルパーには，あるモデルの集合からoptionタグのセットを生成してくれる便利な機能が提供されている。それが，options_from_collection_for_selectメソッドである。 options_from_collection_for_selectメソッド(やたらと長い)の基本的な使い方として，例えばnameとuser_idという両方とも文字列の属性を持つUserクラスのインスタンスの集合@usersがあったとき， とすることで，name属性を表示文字列に，user
天使やカイザーと呼ばれて: Ruby on Railsのテスト環境が気持ちいい
Javaな世界に10年以上どっぷりと浸かってきたが，Ruby on Rails(RoR)をやっていると「良く考えられているなぁ」と感心してしまう箇所が随所に見られる。とかくScaffoldやActiveRecordに関するコーディングに目が行ってしまいがちだが，僕個人的にはテストに関する環境が最も「おぉ」と感じている。 言うなれば，「JUnit + DbUnit + Cactus」な環境が標準で整備されている，ということだ。 JUnitについては，もちろんTest::Unitがそれに相当する。Test::Unit::TestCaseクラスを継承し，”test_“で始まる名前のメソッドを定義していくというのは，xUnitの流儀とほぼ一致している。JUnitで単体テストを行ったことがある開発者は，違和感なくTest::Unitでテストケースクラスを書いていけることだろう。 Web+DBアプリケ
DIコンテナの設定ファイル書くの？書かないの？
DIコンテナの設定情報，つまり「オブジェクトの依存関係」や「オブジェクトの設定内容」について，規約重視で暗黙のものとするか，ファイルに記述することで形式のものとするかは，個々人によって主張が異なるようである。何が何でも設定ファイルを書かない，あるいは，何が何でも設定ファイルを書く，といった「原理主義者」も多く，多くの場合は彼らの説明に「コンテキスト」が含まれない。よって，主張を聞いても，実際に何らかのDIコンテナを使う際をイメージした場合，その主張に沿う部分と沿わない部分が僕個人の中で発生し，完全に主張を受け入れられないことがよくある。 結局のところ「DIコンテナをどう使うか」（＝上記で言ったコンテキスト）によって，暗黙知とするか形式知とするかを判断しなければならないと思っている。 DIコンテナの適用パターンとして代表的なものは，「View，Business Logic，Dao」といった3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
