Martin Fowler's Bliki in Japanese - 技術的負債の四象限
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html 2009/10/14 ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「 a mess is not a debt」だ。 彼の意見は、こういうことだ。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 技術的負債という言葉はもっと特別な場合を指すものだ。 検討の末に、長期的な持続性のない(けれども短期的には利益を生み出す。たとえばすぐにリリースできるなどの) 設計指針を敢えて選択するといった場合に使う。 要するに、負債を抱えれば早めに価値を生み出せるけれども、いずれ返済しないといけな
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
Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby
以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。 ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える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 - モデル駆動ソフトウェア開発
http://martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html 2008/7/14 モデル駆動ソフトウェア開発（MDSD）は、 伝統的なプログラミング方式の代替であると謳うソフトウェア開発手法のことです。 この手法は、ソフトウェアシステムのモデルの構築に主眼を置いています。 通常、こうしたモデルは、図を用いた設計記法によって表されます――たとえばUMLが選択肢の1つとなります。 これらの図を使い、 捉えたシステムをモデリングツールに描画して、 伝統的なプログラミング言語のコードを生成する というのが、基本的な考えになります。 MDSDの構想は、図を用いた設計記法とCASEツールから生まれました。 これらの技術の提唱者たちは、図を用いた設計記法をプログラミング言語よりも抽象度を高めるための方法であると考えており、開発の生産性
Martin Fowler's Bliki in Japanese - 設計力
http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム
Martin Fowler's Bliki in Japanese - GroovyかJRubyか
http://martinfowler.com/bliki/GroovyOrJRuby.html 2007/11/27 現在、Java仮想マシン（JVM）上で動くスクリプト言語として、GroovyとJRubyはどちらが優勢なのかという議論が巻き起こっている。 この言語戦争の勝者はどちらなのか！？ 知りたいよねー。知りたいでしょ。 みんなは「プロジェクトに使うのはどっちだ？」とか「今から学習するならどっちだ？」とか気になっていると思う。 まず最初に押さえなきゃいけないのは、このレースの出走馬が2頭だけだと考えるのは公平じゃないってことだ。 JVM上のスクリプト言語の歴史は古く、Jython（JavaによるPython実装）なんてずっと昔から存在している。 他にもいろいろありすぎてよく分からない状況なので、ここではあえて列挙することはしない。「XXXがないじゃないか！」と怒られても困るしね。
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
Martin Fowler's Bliki in Japanese - 流れるようなインターフェース
http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース（fluent interface）」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,
Martin Fowler's Bliki in Japanese - ユースケースとストーリー
http://www.martinfowler.com/bliki/UseCasesAndStories.html ユースケースとXPのストーリーとの違いは？ これはよくある質問だが、なかなか答えがまとまらない質問でもある。XPコミュニティの人々は、ストーリーはユースケースを簡単にしたものだと捉えている。私も以前はそう思っていたが、今は別の見方をしている。 ユースケースとストーリーは、どちらも要求をまとめる（organize）方法という意味で一致している。違うのは、まとめる「目的」である。 ユースケースは、ユーザーがシステムにどう携わるか、どう使うか、といったナレーティブ（narrative）を形作るために要求をまとめていく。したがってユースケースは、ユーザーのゴールとシステムとの相互作用がどれだけそのゴールを満たすかに焦点があてられる。 一方、XPストーリー（やよく機能などと呼ばれるもの
Martin Fowler's Bliki in Japanese - オブジェクトマザー
http://martinfowler.com/bliki/ObjectMother.html オブジェクトマザーとは、テストで使用するクラスである。 これはテスト用のサンプルオブジェクトを作るのに役立つものだ。 それなりの規模のシステムでテストを書くとき、 膨大なサンプルデータを用意する必要があるだろう。 たとえば、従業員の疾病手当の計算をテストする場合だと、従業員が必要になる。 これは単なるオブジェクトではなく、配偶者の有無、扶養家族の人数、勤務履歴、給与履歴などのデータが必要である。 もしかすると、オブジェクトを大量に生成しなければならないかもしれない。 こうしたデータは一般に「テストフィクスチャ」と呼ばれる。 まず、フィクスチャをxUnitテストのsetUpメソッドで作成して、 複数のテストで再利用できるようにする。 ここでよく面倒となるのは、同じようなデータが複数のテストクラスで
Martin Fowler\'s Bliki in Japanese - ローラースケート実装
http://martinfowler.com/bliki/RollerSkateImplementation.html 2007/9/9 アジャイル開発の重要な特性として、小さな機能サブセットに分割してシステムを稼動させる方法をあれこれ考える、というものがある。 我々は、ソフトウェアがもたらすビジネス価値のためにソフトウェアを構築するのである。 システムの稼動が早ければ、それだけそのビジネス価値（の少なくとも幾分か）を早く手に入れることができる。 同僚のDave Leigh-Fellowsがこの考えにまつわる話を教えてくれた。 私はこの話が大好きだ。 我々が株式仲買業者の仕事をしていたときのことだ。 彼らは新しい商品を市場に投入したいと思っていた。 このためにソフトウェアが行うべきことは、顧客がWebフォームに入力した情報を使って必要な処理を行い、裏のバックエンドシステムにデータを受け
Martin Fowler's Bliki in Japanese - インタフェースの変更はリファクタリングか？
http://www.martinfowler.com/bliki/IsChangingInterfacesRefactoring.html 2007/9/2 リファクタリングの境界線のひとつ。 部分的なインタフェースの変更はリファクタリングか？ 答えは簡単――インタフェースの変更はリファクタリングだ。 もちろんすべての呼び出し元を変更する必要はある。 このよい例がメソッド名の変更だ。 このインタフェースの変更によるリファクタリングは、 ほとんどすべてのリファクタリングツールでサポートされている。 すべての呼び出し元を変更するというのが、この種のリファクタリングでの肝となる。 インタフェースの宣言を変更しただけでは、システムは壊れてしまうので、 リファクタリングの定義が示すような振る舞いを保った変更にはならない。 インタフェースの変更によるリファクタリングは、あなたがすべての呼び出し元を把
capsctrl - Meadow
前準備 環境変数の設定 set HOME=C:\home\hogehoge set TZ=JST-9 set TMP=C:\tmp インストール http://www.meadowy.org/meadow/dists/ 上記URLよりMeadow 1.15用のsetup.exeをDL。ダブルクリックして身を任せる。インストール先は C:\Meadow 基本設定 C:\Meadow にあるdot.emacs.jaを$HOMEにコピー。.emacsとリネーム。 C-hでBack Space ;; C-h を backspace として使う。 (keyboard-translate ?\C-h ?\C-?) (global-set-key "\C-h" nil) (load-library "term/keyswap") でも可 フォント ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Martin Fowler's Bliki in Japanese - ひとつの言語
http://martinfowler.com/bliki/OneLanguage.html 開発努力において言語は１つだけにすべきか？ エンタープライズ・ソフトウェア界の流行はここ10年の間ずっと、ソフトウェア開発努力のための1つの標準言語に集中することだった。 多くの開発組織が、すべての作業をJava(とかC#/VB)でこなそうとしている。 これの理論的根拠は、開発者が1つより多くの言語に熟練するのは困難だということだ。単一の言語にこだわり続ければ学習の負荷は下がる。とりわけ新人を採用するときに効果がある。 まあ真実もちょっとはあるけど、大抵は大外しだ。プログラミング環境ってのは一部は言語だけれど、でも複数の言語やフレームワークについてでもある。大規模フレームワーク、HibernateやStrutsやADOなんかは、単一のホスト言語でプログラミングしていたとしたって、今や1つの言語を学
Martin Fowler's Bliki in Japanese - RubyMicrosoft
http://martinfowler.com/bliki/RubyMicrosoft.html 2007/6/1 （更新：反応リンク集を末尾に追加） RailsConf2007ではJRubyが大盛況だった。 この小さなチームは瀕死のプロジェクトを引き受け、JVM上で動くファーストクラスのRubyプラットフォームに変えた。彼らが多くの賞賛を得たのは当然だ。 JRubyについてはまさにそんな感じとして、注目すべきはもう一つの共通マネージコード・ランタイム――.NETだ。 Rubyに対するマイクロソフトの意図は今のところすごく不透明だ。 彼らはSilverlightのスクリプティング言語としてRubyを発表した――でも未解決の問題が多く残っている。 Ruby言語をフル実装するのか、それともRuby++みたいなもの――Rubyサブセットの拡張――なのか？ JRubyの目的は2つある。それぞれ明確
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
capsctrldays - Webアプリケーション技術者の見極め方（Java）
Martin Fowler's Bliki in Japanese - 固定価格