fixture replacement 決定戦 - ヽ( ・∀・)ノくまくまー(2009-12-22)
めも FGはdefineの仮引数周りが無駄 (blueprintで改善) FGはinstanceをフラットに管理しすぎ FGのsequence(next)はイケてる FGはAR前提 Machinistは定義がイケてるが、名前がダサイ(make_unsaved) Machinistはメソッド名が衝突しそう(makeはアカン) Machinistはinstanceをクラス毎に分類できるが、Shamレベルまで落ちるとフラットになる片手落ち感 Daddyの使えなさは異常 FGの継承はどうやるの？(-> :parent) FG.blueprint は :parent を理解してくれない 試行錯誤 Factory.sequence :login do |i| "login#{i}" end Factory.define(:user) do |user| user.login {Factory.next
DCIが面白い件 - ヽ( ・∀・)ノくまくまー(2010-05-12)
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
draggable と droppable - ヽ( ・∀・)ノくまくまー(2007-10-12)
