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 のテスティングに対する考えなど、技術的な教訓についても触れる。
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 - アジャイル対リーン
http://martinfowler.com/bliki/AgileVersusLean.html 2008/6/26 アジャイル対リーン 「アジャイルソフトウェア開発をしようと思っています。 ですが、アジャイルの代わりにリーンソフトウェア開発をしたほうがいいんでしょうか？」 最近、こういう質問を何回か受けた。安易に答えるわけにはいかない―― そもそも、アジャイルとリーンの関係について誤解があるのだ。 そこで、まず歴史をひもといて、その関係について説明しよう。 「リーン」は、もともとは工業生産の世界で1950年代にトヨタが開発した手法を指す。 当時日本は第二次世界大戦の打撃から立ち直りつつあった。 リーン手法は、トヨタ生産方式と呼ばれることも多いが、 主に大野耐一の功績とされている。 もっとも、大野は西洋の多くの思想の影響を受けている。 特にデミングの影響が強い。 トヨタ生産方式が日本以
Martin Fowler's Bliki in Japanese - 構文ノイズ
http://www.martinfowler.com/bliki/SyntacticNoise.html 2008/6/9 ドメイン特化言語について話していると（DSLに限らずあらゆるコンピュータ言語でそうなんだけど）、構文にノイズがあるって話をよく聞く。 RubyはJavaよりもノイズが少ないとか、外部DSLは内部DSLよりノイズが少ないとか。 構文ノイズっていうのは、言語としての記述には必要だけど、プログラマがやりたいことには関係のない文字のことだ。 ノイズ文字はプログラムの意図をぼかしてしまうため、 プログラムの動作を読み解かなければならなくなってしまう。 「構文ノイズ」という言葉も意味があいまいで主観的な言葉なので、ちょっと使いにくかったりする。ちょっと前にGilhad BrahaがJAOOで構文ノイズについて説明しようとしていたが、私も同じようにやってみたいと思う。DSL本のイ
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/ParserFear.html 2008/5/20 最近はドメイン特化言語についてみんなと話すことが多いのだが、外部DSLのことになると、だいたい決まって「パーサーを書くのは難しいよ」とか言われる。 外部DSLの構文としてXMLがよく使われるのは、「パーサーが無料で手に入るから」だったりする。 でも、パーサーを書くのは思ったよりも簡単なことなのだよ。いやマジで。 XMLのパースができれば簡単なことだよ。 証拠だってあるのだ……つっても、私の話だけど。 でもでも、十分に証拠となるものだから引き合いに出そうと思う。 現在執筆中の書籍に入門的な例を書いたんだけど、 簡単なステートマシンを作るのに外部DSLを2つ作ったのだ。 1つは（ゲートウェイドラッグ*1として）XMLを使ったもので、もう1つはカスタム構文をAntlrを使ってパースした
Martin Fowler's Bliki in Japanese - 進化的設計
Bill Venners: 「設計の終焉?」の中で計画的設計について述べられていますよね。計画的設計とはどういったものでしょうか？ Martin Fowler: 私は計画的設計と進化的設計とを区別しています。計画的設計とは、ソフトウェアを作る際にまず設計を行い、それからコーディングするようなことを指します。計画的設計はUMLダイアグラムの形をとることがあります。システムをサブシステムに分解し、サブシステム間のインターフェイスを定義するものだといえるかもしれません。計画的設計を用いれば、設計とコーディングとの間に明確な「スイッチ」が存在することになります。それぞれのタスクは普通、別々の人間が行います。設計者が設計を行い、開発者がコーディングを行うのです。必ずしも完全に確定したものではないにせよ、設計はほぼ確定したものとして扱われます。設計が優れていれば、コーディング時の変更が少なくなると言っ
Martin Fowler's Bliki in Japanese - 生産性は計測不能
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
Martin Fowler's Bliki in Japanese - 優れたほうが安い説
http://martinfowler.com/bliki/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる
テストダブル - Martin Fowler's Bliki in Japanese - TestDouble
http://martinfowler.com/bliki/TestDouble.html Gerard Meszarosが、様々なXunitフレームワークを使用したパターンを集めた書籍を執筆中である。 彼は、ある厄介なことに出くわしている。 システムの一部分をテストするためにスタブ化することがあるが、 その名前というのが、スタブ、モック、フェイク、ダミーなど、色々とあるのだ。 そのため彼は、自身の用語集を作成した。 この用語集は広く普及すべきものだろう。 彼が一般的な用語として使っているのは、「Test Double（テスト代役）」という言葉だ（スタントの代役(double)を想像してほしい）。 Test Doubleは、テスト用にオブジェクトを入れ替えるときに一般的に用いられる言葉である。 Gerardが作成したリストには、様々なDoubleが載っている。 ダミーオブジェクトは、受け渡
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 - Evansの分類
http://martinfowler.com/bliki/EvansClassification.html Eric Evansのエクセレントな著書『Domain Driven Design』では、 我々がしばしば目にする様々なドメインオブジェクトが以下のように分類されている。 エンティティ：アイデンティティを持ち、時間経過によって形を変えるオブジェクト。「リファレンスオブジェクト」とも呼ばれることがある。 バリューオブジェクト：属性の組み合わせに意味があるオブジェクト。同じ値（バリュー）を持つ2つのバリューオブジェクトは、どちらもすべての属性が等しいと見なされる。バリューオブジェクトについては、私もP of EAAで触れている。 サービス：ドメインにおける独立したオペレーション。サービスオブジェクトは1つ以上のサービスを持つ。実行文脈におけるサービスオブジェクト型のインスタンスは、通常
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://martinfowler.com/bliki/OneLanguage.html 開発努力において言語は１つだけにすべきか？ エンタープライズ・ソフトウェア界の流行はここ10年の間ずっと、ソフトウェア開発努力のための1つの標準言語に集中することだった。 多くの開発組織が、すべての作業をJava(とかC#/VB)でこなそうとしている。 これの理論的根拠は、開発者が1つより多くの言語に熟練するのは困難だということだ。単一の言語にこだわり続ければ学習の負荷は下がる。とりわけ新人を採用するときに効果がある。 まあ真実もちょっとはあるけど、大抵は大外しだ。プログラミング環境ってのは一部は言語だけれど、でも複数の言語やフレームワークについてでもある。大規模フレームワーク、HibernateやStrutsやADOなんかは、単一のホスト言語でプログラミングしていたとしたって、今や1つの言語を学
Martin Fowler's Bliki in Japanese - コードの臭い
http://www.martinfowler.com/bliki/CodeSmell.html コードの臭いとは表層の兆候で、だいたいにおいてシステムの根深い問題に関係している。この単語はKent Beckが私のリファクタリング本を手伝っているときにはじめて考え出したものだ。 上記の簡単な定義では伝わりにくい点が2、3ある。第1に、臭いとは定義上、すぐに見つけられる――私の最近の表現だと嗅ぎつけられる――ものだ。長いメソッドはこれのいい例だ――十数行以上のJavaコードを見かけたら、コードを眺めただけで鼻がヒクヒクしてしまう。 第2に、臭いが常に問題の兆候というわけではない。長いメソッド方法でも問題ないものはある。そこに問題が隠れているのかを知るには、より深く眺めないといけない――臭い自体が根本的に悪いわけではない――それ自体が問題というよりは、問題の指標となっていることが多いということ
Martin Fowler's Bliki in Japanese - InMemoryDatabase
Generated by Hiki 0.8.7 (2007-06-24). Powered by Ruby 1.8.6 (2007-09-24). Founded by kdmsnr.
Martin Fowler's Bliki in Japanese - ポストイットタイムライン
http://martinfowler.com/bliki/StickyTimeline.html プロジェクト回顧時にプロジェクトタイムラインを作成すると、 非常に役に立ちます。 プロジェクト中にどんなイベントが起きたのか、 そしてそれらのイベントがプロジェクトにどのような影響を与えたのか、 タイムラインを見て、それらが分かるようにしなければいけません。 XP day において、 Tim Mackinnon が、素早く効果的にタイムラインを作る方法を紹介していました。 まず、壁にスペースを作ります。 そして、てきとーに時間軸を取ります（ホワイトボードや壁に貼った紙を使います）。 それから、チームメンバ各自がポストイットを壁に貼り付けます。そのポストイットがイベントを表すのです。 イベントは色分けされています。 緑色:良いイベント オレンジ色:問題のあるイベント 黄色:どちらともいえないイ
Martin Fowler's Bliki in Japanese - CodeOwnership
http://martinfowler.com/bliki/CodeOwnership.html コードの所有には、私が今まで見てきたものだけでも、いくつかの形がある。 ここでは大きく3つのカテゴリに分けてみた。 強いコードの所有では、コードはモジュール（クラス、関数、ファイル）などに分かれており、それぞれが一人の開発者に割り当てられている。開発者は自分のモジュールだけを変更することができる。他の開発者のモジュールを変更したい場合は、モジュールの所有者に頼んで変更してもらうことになる。または、パッチを書いて送りつける方法もある。 弱いコードの所有では、上記と同様、モジュールが各開発者に割り当てられているが、他の人のモジュールも変更してもよいという点で異なる。モジュールの所有者は割り当てられたモジュールに責任を持ち、他の人によって変更が加えられることに気を配る必要がある。他の人のモジュールに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler's Bliki in Japanese - ボールとソケット