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に適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
Martin Fowler's Bliki in Japanese - ビジネスリーダブルなDSL
http://martinfowler.com/bliki/BusinessReadableDSL.html 2008/12/15 ビジネスピープルは、DSLを使えば、プログラマがいなくてもソフトウェアのルールを書けるのだろうか？ DSLの話になると、ビジネスピープルが自分でコードを書くのかといった話によくなる。 こうした考えには、COBOLのインターフェースの話を持ち出そう。 元々のCOBOLの目的は、プログラマがいなくてもソフトウェアを書けるようにすることだった。が、結果は見ての通りである。 プログラマがいなくてもコードを書けるという話には、COBOL（とその他大勢）が失敗したところを、今回はどうやって克服するのかと尋ねるようにしている。 私は、プログラミングには特殊なマインドセットが必要だと考えている。 それは、マシンに正確な指示を与えること、そして、そうした膨大な指示を構造化して、
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 ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
capsctrldays - erase_render_results で render をキャンセル , 人月の価格調査 , 給与とコストで人月計算 , あなたの会社を潰さない最後の戦略..
1 erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file => File.j
Martin Fowler's Bliki in Japanese - 支払利息の見積もり
2008/11/6 http://martinfowler.com/bliki/EstimatedInterest.html 技術的負債は、かなり使える考え方である。 しかし、負債がどれくらいあるかなんて、どうやったら分かるのだろう。 残念ながら金融の負債とは違い、どれだけ技術的負債があるのかは分かりづらい。 （とはいえ、最近は金融の負債だって分かりにくくなっているようだけど） たとえば、こんなのはどうだろう。 チームがある機能を完成させたときに、どれだけ時間がかかったかを聞く（実値）。 それから、もし仮にシステムがきれいだったとしたら、どれだけ時間がかかったかを聞く。 この2つの違いが技術的負債の利息である。 （実際の作業に5日かかって、きれなシステムなら3日だとすれば、2日分の作業を技術的負債の利息として支払ったことになる）。 これにはいくつかの深刻な問題がある。 きれいなシステムなら
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 - 優れたほうが安い説
http://martinfowler.com/bliki/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる
Martin Fowler's Bliki in Japanese - 設計力
http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム
capsctrldays - 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ
1 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ 私が翻訳しました『アジャイルレトロスペクティブズ』（オーム社）という書籍が9/26（水）に発売されます（オーム社!!オーム社!!）。 本書はPragmatic Bookshelfの『Agile Retrospectives - Making Good Teams Great』の全訳で、日本でいう「ふりかえり」にフォーカスした奇特な1冊です。 ふりかえりというと、日本では「KPT」が取り上げられることが多いですが、実はそれ以外にもふりかえりのプラクティスは存在します。 本書では、ふりかえりを5つのフェーズに分け、それぞれのフェーズで使用可能なプラクティスをカタログ的に紹介しています。いずれも30分程度の簡単なプラクティスです。ふりかえりをまだ導入されていない方、もっとふりかえりをうまくやりたい方、KPTに飽きた方ｗ、は是非ご一
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://martinfowler.com/bliki/CustomerLoyaltySoftware.html 2007/9/4 先週、カナダのカルガリーオフィスでJohn Kordybackと楽しい会話をすることができた。 彼は最も信頼できる技術リーダーの1人だ。 彼は、旅行関係のロイヤルティソフトウェアシステムに従事（というか、どっぷり漬かって）いる（たとえば、Frequent FlyerやSleeperなどだ）。 我々は、これらのシステムの本質について、 そして、 より実りある方法で考えるにはどのようにすればよいか、 といったことについて話し合った。 ロイヤルティシステムの肝は、ポイント（やマイル）の記録にある。 顧客は自分のポイントを参照できなければならないし、会社はまだ引き換えられていないポイントを管理できなければならない。 多くの人はそうは思わないかもしれないが、実はこれ
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://martinfowler.com/bliki/DuplexBook.html 2007/6/13 先週、私のシグニチャシリーズの新刊が出た。 Gerard Meszarosによる『xUnit Test Patterns』だ。 Gerardとは数年間この件についてやり取りをしてきたので、 内容についてはよく知っているのだが、 実際の本を見てかなりショックを受けた。 なにこの厚さ。883ページて。 シグニチャシリーズのなかでダントツの厚さだ。 私は厚い本があまり好きじゃない。 『UMLモデリングのエッセンス』が薄いのには誇りを持っているくらいだ。 厚い本は怖い。一体いつ読めるっつーんだ？ だが、『xUnit Test Patterns』は見た目ほど怖くはない。 なぜなら、これは2冊の本が1冊になったものだからだ。 私が『PofEAA』で使ったやり方でもある。 1冊目は物語（nar
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20090611.html
http://capsctrl.que.jp/kdmsnr/diary/20070920.html
capsctrl - フォトリーディング
http://capsctrl.que.jp/kdmsnr/diary/20070415.html