Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
Martin Fowler's Bliki in Japanese - フィーチャーブランチ
@@ -1,25 +1,29 @@ http://martinfowler.com/bliki/FeatureBranch.html -gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフューチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 +gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
プロダクトバックログの項目は「優先付け」するんじゃなくて「並び替える」 - capsctrldays(2011-08-02)
プロダクトバックログの項目は「優先付け」するんじゃなくて「並び替える」現在、新しい『Scrum Guide』を訳しています（現在レビュー待ち）。今回の変更で気になったのが、プロダクトバックログの項目を「優先付け（Prioritized）」するんじゃなくて、単に「並び替える（Ordered）」という点です。 詳しくは、世界の破壊者 Jim Cope による「Ordered Not Prioritized」に譲りますが、端的に言えば「優先順で並べることが、必ずしもROIや価値を最大化するわけではない」ということです。先の例を借りれば、どんなに優先度が高くてもサンタの画像は冬に表示することに価値があり、どんなに家の屋根が気になっていても最初から屋根を作れるわけはない、ということです。 プロダクトバックログは時間軸を伴う有機的な存在です。全体最適を考えて、柔軟に「並び替える」ことが成功の鍵となりま
Martin Fowler's Bliki in Japanese - ドメイン特化言語
http://martinfowler.com/bliki/DomainSpecificLanguage.html ドメイン特化言語(DSL:Domain Specific Language)とは、 ある特定の種類の問題に特化したコンピュータ言語のことです。 様々な問題に対応できる汎用的な言語のことではありません。 ドメイン特化言語についてはこれまでも議論されてきましたし、 コンピュータが使われてきたのと同じくらい長い間使われてきました。 DSLを頻繁に使用しているコミュニティにUnixコミュニティがあります。 そこでは、DSLは「リトル言語」や「ミニ言語」などと呼ばれています （この伝統について、Eric Raymondが素晴らしい議論を提供してくれています）。 最も一般的なUnixスタイルのやり方は、 言語の文法を定義し、コード生成機能を使ってDSLから汎用的な言語を生成する、 あるい
Martin Fowler's Bliki in Japanese - 言語ワークベンチ
以下の文章は、Martin Fowler による 「Language Workbenches: The Killer-App for Domain Specific Languages?」 の日本語訳である。 ソフトウェア開発における新しい考えの多くは、実は古い考えの新しい組み合わせ方です。この記事では、その新しい組み合わせ方のひとつ、私が「言語ワークベンチ(Language Workbenches)」と呼んでいるツールについて説明します。これは、現在広まりつつある考え方で、たとえば、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどが例として挙げられます。これらのツールは古い開発スタイルを採用しており、私はこれを「言語指向プログラミング(language oriente
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
Martin Fowler's Bliki in Japanese - CollectionClosureMethod
http://martinfowler.com/bliki/CollectionClosureMethod.html (detectとinject部分を明確にするよう更新) Smalltalkでプログラミングを始めたときから、コレクションクラスが好きでした。 よく使う強力なオペレーションを簡単に使うことができました。 Javaが登場したとき、このようなメソッドがなくなって物足りないと感じました――Java（およびC#）のコレクションは、Smalltalkのそれと比べて非常に限定されたものでした。 というのも、JavaにはClosureが実装されていなかったからです。 Smalltalkの強力なコレクションのメソッドは、すべてクロージャに依存しています。 近年、私はRubyで頻繁にプログラミングをするようになりました。 Rubyに引き付けられたのは、Rubyには強力なコレクションメソッドがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
老子いわく - capsctrldays(2011-06-02)
http://capsctrl.que.jp/kdmsnr/diary/20100601.html