書籍：実践テスト駆動開発 - haru01のめも
実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型本購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る 実は、ちょっと不満がある。だた、この不満は、オブジェクト指向設計／テスティング活動ついての、きわめて個人的な信条／大切に考える価値判断に由来している。個人的な不満。 この本は、オブジェクト指向設計、テスティングが主題なのだが、どうしてドメインエキスパートとの対話をあまり描かず、OOやテスティングを説明したのだろうかと（対象を明瞭に記述しようとするこだわり／気配りを凄く感じるのに）。DDDが、がんばって対話について説明しようとしたように、もう少し触れてほしかった。 Fitががんばって説明したように
RSpec shared_examples - haru01のめも
shared_examples あまり使ったことがなかったが、 学習教材作成用に記述していると, 初めて shared_examplesを 使いたくなったので使ってみた。 shared_examples "期待通りレンダリングされる" do let(:expected) { <<-HTML <dt>name</dt><dd>myname</dd> <dt>email</dt><dd>myname@example.com</dd> <dt>age</dt><dd>33</dd> <dt>address</dt><dd>myaddress</dd> HTML } it { should include("<dt>name</dt><dd>myname</dd>") } it { should include("<dt>email</dt><dd>myname@example.com</dd>"
RSpecの難しさ - haru01のめも
RSpecの文法に触れる機会が多いのであれこれこねくり回している。 def hoge(key) {a: "AAA", b: "BBB", c: "CCC"}[key] end のテストをどう書く？ 一つのit にまとめて should describe "#hoge" do it "hoge がなんか返す" do hoge(:a).should == "AAA" hoge(:b).should == "BBB" hoge(:c).should == "CCC" hoge(:d).should be_nil end end it を分割 describe "#hoge" do it "keyが :aの場合は AAAを返す" do hoge(:a).should == "AAA" end it "keyが :bの場合は BBBを返す" do hoge(:b).should == "BBB" e
DDDを新人向けに 1時間 読書会を開いた - haru01のめも
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る 3部を、新人向けと考えて、厳選してやったつもり。 難しいところは難しかったようだ。 下記は、読書会で選んだ項目。 意図の明白なインターフェースを 太字中心に読む 副作用のない関数 表明 独立したクラス 閉じた操作 ストラテジー（簡単に解説するだけ） リファクタリングのレベル (P191付近を読む) しなやかな設計 (P248付近を読む) 「リファクタリングのレベル」 は、読み忘れたな。 よく知られているファウラーのリファクタリングと異なること語っており、 この本の特徴の
人とシステムのジレンマ - haru01のめも
やっと文字にできそう。 自己啓発系の座視は、要因を自分の心に配置するのを好む。 一方、デミング等のシステム系の座視は、人ではなくシステム全体に配置するのを好む（安易に問題の要因を人に帰属させるのではなく、システムエラーとして扱い、根本要因を徹底的に見つけ出し、そこを修復する）。 一方の座視では、盲点となりやすい自分の心に要因を求めるのが良いとされることが、 他方の座視では、必ずしもよしとされない。自分の心に要因を求める行為が盲点となる。 逆に一方の座視では、システム側に要因を求めるとよいとされることが、 他方の座視では、必ずしもよしとされない。それが盲点となる。 よく迷う。
Wikiのテンプレート - haru01のめも
Wikiでパタンを意識して文書を書くテンプレート。色々試したが、私のお気に入りは次。 Name：XXXと名前を書く。Implementation Patternのように小さな要素も候補にできないか検討． What：XXXとは？の要約を書く Why：XXXの嬉しさを書く When：XXXをいつ使うか（使わないか）を書く How：XXXの詳細手順などハウツーを書く See Also：リンク元、関連リンク、外部参考ページを書く テンプレート要素がとても覚え易い。それでいて、それぞれの要素は強力。Whenは、xUnit Patterns等の「When to Use It」のように。全部のテンプレート要素を無理して埋めなくて, NameとWhatとSee Alsoだけとかも融通が利く。変種で最後にThreadを追加して、私的な意見を書けるコメントスペースを追加するとか．Exampleのスペースがない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fat model になってしまったコード。本来は何処に配置すべきか？ - haru01のめも
達成不可な計画ができる理由 - haru01のめも
２つの「メンタルモデル」の言葉の使用 - haru01のめも
KPT - haru01のめも
TOCとボトルネックとタイムボックス - haru01のめも
ソースコードの濁り具合と開発者の心の濁り具合 - haru01のめも
”パ タ ン ラ ン ゲ ー ジ か ら プ ロ ジ ェ ク トラ ン ゲ ー ジへ” に目を通した - haru01のめも
英語のPodcast - haru01のめも
DevLove で発表したよ - haru01のめも
Project Wiki - haru01のめも
ペアプロのナビゲータ - haru01のめも
ペアプロのタイミング - haru01のめも
Wikiの簡単なテクニック - haru01のめも
知的資産を企業内に閉じて所有しない時代が既にやってきている． - haru01のめも