オブジェクト指向プログラムのためのパターン言語の使用
以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。 Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースの
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
Martin Fowler's Bliki in Japanese - 事例証拠
http://martinfowler.com/bliki/AnecdotalEvidence.html ソフトウェア開発分野で不満なのは、いくつかある技術やツールの中からひとつを選ぶのが難しいという点である。 この話題になると、その技術やツールが他の選択肢よりも優れているという「確かなデータ」を見せろと言う人が必ずいる。 それはもっともな要望だ。しかしそれは、絶望的な要望でもある。 なぜなら、生産性は計測不能だからだ。 確かなデータがなければ、事例証拠に頼ることになる。 実際、私はこれまで事例証拠の分析に基づいた考えを広めることに費やしてきた。 客観的に計測できる事象には劣るかもしれないが、事例証拠を無視するのは賢明ではない。 そもそも、事例証拠以外に我々は何から学べるというのだ？ 我々は自身の経験から多くのことを学ぶ。 それに他の人の経験が加われば、情報源に厚みが増す。 こんなことを言
Martin Fowler's Bliki in Japanese - Rubyピープル
http://martinfowler.com/bliki/RubyPeople.html ここの読者ならご存知だろうが、ここ数年、私は熱心なrubyistだ。 言語としてのrubyは、リッチでありながらも整った文法、そして、よくデザインされたフレームワークが一体となっていて、すごく気に入っている。 rubyは個人的なプロジェクトで日常的に使う言語となり、 このサイトの多くもrubyで作っている。 昨年、Rubyは爆発的な注目を集めた。 Webアプリケーション フレームワークRuby on Railsがその火付け役だ。 私はまだrailsを触ることができていないが、 信頼を置ける多くの人から強烈な支持の声を聞いている。 その声はThoughtWorksの内外から聞こえてくる。 私はrubyのアーリーアダプタだったものだから（規模は小さかったけどね）、 このプラットフォームがますますポピュラ
翻訳 - Ruby on Rails: David Heinemeier Hanssonへのインタビュー
以下の文章は、Edd Dumbillによる「Ruby on Rails: An Interview with David Heinemeier Hansson」の日本語訳である。 O'Reilly Media, Inc.の許可を得て、ここに掲載する。 by Edd Dumbill 08/30/2005 プログラミングの世界で誰も無視できない最新のスタープラットフォーム――Ruby on Rails。そして、そのRailsの作者であるDavid Heinemeier Hansson。彼は、今年のOSCONで観衆を大興奮の渦に巻き込んだ。10月にはアムステルダムで開かれるEuropean O'Reilly Opensource Conventionで基調講演を行う予定だ。 Heinemeier Hanssonはデンマークのコペンハーゲンに住んでいる。彼は、革新的な企業37signals のパー
Martin Fowler's Bliki in Japanese - リファクタリングの誤用
http://martinfowler.com/bliki/RefactoringMalapropism.html かつて、わずかな人しか知らなかった用語「リファクタリング」は、 今ではコンピュータ業界の中でフラフラ迷走している。 これは私にも責任がある。 私はプログラマたちの生活の向上と、ビジネスに利益をもたらせたいと願っている （重要なことだが、私はリファクタリングの父でもないし、発明者でもない。ただの執筆者である） …… ……のだが、リファクタリングは、適切に使われてはいない。 リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、 んなもんリファクタリングじゃあなーいと言ってやれ。 ドキュメントをリファクタリングしちゃるとか言ってる奴、 それもリファクタリングじゃねーぞコラ。 そういうのは、リストラクチャリング（再構築）というのだッ。 「リファクタリ
Martin Fowler's Bliki in Japanese - コードがドキュメントだ
http://www.martinfowler.com/bliki/CodeAsDocumentation.html アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる――ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。 おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが"唯一の"ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。 なぜコードが重
Martin Fowler's Bliki in Japanese - いちばん大切なのは人
http://martinfowler.com/bliki/PeopleMatterMost.html 最近、考えるようになったことがいくつかある。 それは、私のソフトウェア開発観の基礎となるものである。 ソフトウェア開発の鍵となるものをまず1つ挙げるとしたら、 それはソフトウェア開発に欠かせない要素、つまり 「働く人」だ。 優秀な開発者の生産性は、平均値よりも遥かに高い。 その差は給与の差よりも大きいだろう。 つまり、費用対効果の高いソフトウェア開発を行うために最も重要なことは、 できるだけ優秀なチームを雇うということである （たとえ開発者のコストが平均より高くてもだ）。 少数の優秀な（単価の高い）開発者の生産性は、 多くの平凡な（単価の安い）開発者の生産性よりも遥かに高い。 つまり、少数精鋭の開発者は、日換算ではコストがかかるかもしれないが、 トータルで見るとより低価格なソフトウェアを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
