Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
Martin Fowler's Bliki in Japanese - 技術的負債の四象限
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html 2009/10/14 ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「 a mess is not a debt」だ。 彼の意見は、こういうことだ。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 技術的負債という言葉はもっと特別な場合を指すものだ。 検討の末に、長期的な持続性のない(けれども短期的には利益を生み出す。たとえばすぐにリリースできるなどの) 設計指針を敢えて選択するといった場合に使う。 要するに、負債を抱えれば早めに価値を生み出せるけれども、いずれ返済しないといけな
AgileData.org in Japanese - www.agiledata.org in Japanese
データ専門家とアプリケーション開発者を団結させる ここは Scott W. Ambler 氏による www.agiledata.org の翻訳 Wiki です。 Scott W. Ambler 氏より許可を得て運営しております。翻訳における注意事項やライセンスについては、ReadMe をご覧ください。そのほか、なにかご意見がありましたら、会議室にてお願いいたします。 概略 アジャイルソフトウェア開発者の基礎知識 進化的開発技術と成功要因 アジャイルデータベース開発技術 アジャイルデータ(AD) 手法 その他 重要なリンク アジャイルデータメーリングリストに入ろう！ アジャイルデータメーリングリスト（日本語）: 聞くところによると、大規模なミッションクリティカルプロジェクトは65〜85%の確率で失敗しているのだそうだ。 これはStandish GroupのChaos Report によるもの
AgileData.org in Japanese - オブジェクト・リレーショナル・インピーダンス・ミスマッチ
http://www.agiledata.org/essays/impedanceMismatch.html この論文は、Agile Database Techniques Chapter 7より抜粋。 オブジェクト指向技術はデータと振る舞いを持つオブジェクトを使ったアプリケーションの構築をサポートする。リレーショナル技術はテーブルへのデータの保管をサポートする。また、データベース内部においてはストアドプロシージャ、外部からはSQL呼び出しを用い、データ操作言語（DML; Data Manipulation Language）を使ったデータの操作をサポートする。 さらに進歩したリレーショナル・データベースには、内部的にオブジェクトサポートするようなものもある。 データベースがより強力になるというこの傾向は、時とともに強まりこそすれ弱まることはないだろう。 多くの組織において、オブジェクト
スクラムマスターは開発メンバーになれるのか？ - capsctrldays(2012-12-09)
スクラムマスターは開発メンバーになれるのか？スクラムに関する資料を作っていて疑問に思ったのでQuoraで質問してみました。自分で訳しておいてあまり覚えていないので、改めて「スクラムガイド」を読んだんですが、明示的に書かれているところはありませんでした（できるというようなニュアンスはある）。 で、はじめてQuoraを使ってわかったんですけども、名指しで回答してもらうことができるんですよね。というわけで、Jeffに名指しで質問してみました。そしたらソッコーで答えが返ってきた！ http://www.quora.com/Scrum/Can-scrum-master-be-one-of-development-team-members/comment/233021 簡単に訳しておきます（正確には上の英文を読んでおくれ）。 「スクラムガイド」に載ってないんだったら、ウォマック博士の『リーン生産方式が
Clean Coder プロフェッショナルプログラマへの道(Robert C. Martin/角征典) - capsctrldays(2012-01-27)
Clean Coder プロフェッショナルプログラマへの道(Robert C. Martin/角征典)宣伝。ボブおじさんの著書を翻訳しました。（Amazonにまだ書影がない!!） アジャイル開発やオブジェクト指向で有名な著者が自らの失敗を赤裸々に語りつつ、ソフトウェア開発者が本物のプロへと成長する方法を指南する啓発書。ボブおじさんの失敗から正しいプロの態度・規律・行動を学ぼう! 大雑把に言えば、プログラマのための自己啓発書みたいな感じですかね。まあ、そういうのに興味のない人はたくさんいると思いますけども、そういう人たちにとっても、ボブおじさんが20代・30代を過ごした昔話は、それなりに楽しく読めるんじゃないかと思うんです（1970年代の話です）。 技術的におもしろいというよりも、人間の過去がわかるというのは、それだけでおもしろいじゃないですか（そうじゃない？）。実際、ぼくには60歳以上のプ
Martin Fowler's Bliki in Japanese - Junit新インスタンス
http://martinfowler.com/bliki/JunitNewInstance.html JUnit testing framework のあるデザインについて、よく質問を受ける。 テストメソッドを走らせるたびに、新しいオブジェクトができる点についてだ。 blikiへ投稿するに値する内容だと思ったのでここに記す。 （ 念のために言っておくが、JUnitについて何か書くからといって、 その他のテストのやり方が重要じゃないと思っているわけじゃないですから。 有益なテスト方法はたくさんあるわけで、 JUnit やその親戚（xUnit）がいくら便利だからって、 すべてを解決してくれるわけじゃない。 テストについて言及してるblogがいくつかあるから、 そちらを読んでみることをお勧めする （ Brett Pettichord, Brian Marick, James Bach ）。
直訳の先に自然な日本語訳があるのか - capsctrldays(2011-04-11)
■ 直訳の先に自然な日本語訳があるのか 「オーソン・スコット・カードの「翻訳」記事がやばい件」に 実は英語を訳すときにまず必要なのは生硬な直訳をつくることなんだと思う。呼吸でもするように直訳がきちんとできるようになれば、その先にちゃんとした翻訳があるのだろう、と、そんなことを思っている。 というのがあった。これが正しいのかどうかはわからないが、 自分の場合もまずは直訳をするようにしている。英文を前から順番にそのまま訳すっていうやつ。 それが終わったら、 「不自然な日本語訳」に変えて、 最後に「自然な日本語訳」にするようにしている。 できているかどうかは別だけど。 直訳でいいなら機械翻訳を下訳にすればいいじゃん！と思って試してみたことがあるけれど、 あまり精度がよくないし、自分の言葉じゃない文章のリライトはスピードが落ちるのでやめた。 あと、最近気づいたんだけど、いかにも翻訳調の「不自然な日
私の翻訳のやり方 - capsctrldays(2011-03-26)
■ 私の翻訳のやり方 秋から半年かけて2冊の本の翻訳をしたので、そのやり方をまとめて書いてみる。翻訳本の宣伝はまた後日。 1. テキストデータ化する まずは何はともあれテキストデータにする。 私は、テキストエディタと電子辞書を使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。 元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙（原書）なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではな
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える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 - 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/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる
Martin Fowler's Bliki in Japanese - テストの癌
http://martinfowler.com/bliki/TestCancer.html 2007/12/6 本の執筆に専念するようになってから、ソフトウェア開発の現場と疎遠になるのがよく心配になる。 これまでに現場を離れた有名人を何人も目にしているが、私は彼らと同じような運命をたどりたくはない。 私にはThoughtWorksという最高の情報源があるので、まだ地に足をつけていられるのだ。 ThoughtWorksはまた、現場からのアイデアの源でもある。 同僚が発見し開発したものについて書くことは楽しい。 本当に役に立つものなので、読者のみなさんには是非とも使ってもらいたい。 さて、本日の話題は、あまり気持ちのいいものではない。 答えの出ていない問題についてである。 話はこうだ。 我々はプロジェクトを成し遂げ、ピッカピカのソフトウェアをクライアントに納品した。 納品時には自動テスト一式も
capsctrl - DesignPatternsInRuby
kdmsnr Rails勉強会でDesignPatternsInRubyのまとめって需要あんのかな。時間内けど。05:08 PM January 17, 2008 lchin @kdmsnr ある。良書だと聞いたし。 05:13 PM January 17, 2008 shachi @kdmsnr ある。良い本。 05:16 PM January 17, 2008 poppen @kdmsnr 聞きたいっす 05:20 PM January 17, 2008 kakutani @kdmsnr ぼくが聞きたいです! 05:48 PM January 17, 2008 良書なの？？？ 2007/12/XX Addison Wesley Professional $44.99 / ￥5,824 384ページ Patterns and Ruby ... Pattern入門、Ruby入門 Patte
capsctrldays - 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ
1 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ 私が翻訳しました『アジャイルレトロスペクティブズ』（オーム社）という書籍が9/26（水）に発売されます（オーム社!!オーム社!!）。 本書はPragmatic Bookshelfの『Agile Retrospectives - Making Good Teams Great』の全訳で、日本でいう「ふりかえり」にフォーカスした奇特な1冊です。 ふりかえりというと、日本では「KPT」が取り上げられることが多いですが、実はそれ以外にもふりかえりのプラクティスは存在します。 本書では、ふりかえりを5つのフェーズに分け、それぞれのフェーズで使用可能なプラクティスをカタログ的に紹介しています。いずれも30分程度の簡単なプラクティスです。ふりかえりをまだ導入されていない方、もっとふりかえりをうまくやりたい方、KPTに飽きた方ｗ、は是非ご一
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つある。それぞれ明確
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 - RailsConf2007
http://www.martinfowler.com/bliki/RailsConf2007.html 2007/5/22 以前ほどカンファレンスに参加することはなくなったが、 その分、好きなカンファレンスに参加する時間ができた。 ずっと前からRubyコミュニティには特別な愛情を捧げている。 というわけで、RailsConf?に一般参加者として参加してきたよ。 Chad FowlerとRich Kilmerによってカンファレンスの紹介が行われた。 Chadとは苗字が一緒だが、彼ほどのウクレレのスキルは私にはない。 若いテクノロジーには新しくて重要な特筆すべき点がいくつもある。 だが、私にとって最も重要なのは、JRubyだ。 現在、JRubyは最終的なRCの段階だ。 Java VM上で動くスクリプティング言語を提供するだけでなく、 Rubyプラットフォームの完全な実装をJVM上で行おうとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20100601.html
http://capsctrl.que.jp/kdmsnr/diary/20071231.html