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 ）。
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/LanguageForLearningObjects.html オブジェクト指向を教えるとき、どの言語がよいか？ ここ数年、オブジェクト指向を覚えるときには、Javaが使われてきました。Javaを使うのには、いくつかの理由があります。 広く知られている C を基本とした文法（一般的なスタイルとなりつつあります） フリーで高性能な開発環境が利用可能である Javaの知識があれば仕事に就ける こういった理由から、私はJavaの使用をやめさせようとはしませんでした（C#にもこういった特徴があり、いずれC#が代わりになるだろうと指摘してはいたんですが）。ただ、Javaだけに任せようとは思っていません。Java、C#、C++はいずれも、オブジェクト指向プログラミングのある形を提示してくれていますが、誰かにオブジェクト指向を紹介するならば、選
Martin Fowler's Bliki in Japanese - アクセス修飾子
http://martinfowler.com/bliki/AccessModifier.html オブジェクト指向言語ではプログラムはクラスと呼ばれるモジュール群に分かれます。 それぞれのクラスは機能(features)をもっており、データ（フィールド）とメソッドで構成されます（すべての言語がこの用語を使うわけではありませんが、役割は一緒です）。 言語には、どのクラスがあるクラスの機能にアクセスできるのかについてのルールがあり、たいていクラスに適応されるアクセス修飾子に基づいて決まっています。 C++ の選択 おそらく最も影響力のあるアクセス修飾子はC++の３つから始まりました。 public: どのクラスもアクセスできる protected: どのサブクラスもアクセスできる private: どのクラスもアクセスできない 他のクラスやメソッドに対して _friend_ を使ってアクセス
Martin Fowler's Bliki in Japanese - ビルド言語
http://martinfowler.com/bliki/BuildLanguage.html 追記: Jon Tirsenが、Rubyを使って複雑なantビルドプロセスを動かすという面白いストーリーを書いていました。 Bruce Eckel が最近、antとmakeに関する投稿をしたのだが、それに影響を受けて、私のビルド言語に関する考えをここでシェアしておきたいと思う。 antとmakeはどちらもビルド方法を指定するものであり、ビルド方法を記述するための言語である。どちらも非常に広く使われており、成功もしている。 しかし、どちらも限界に達しているようだ。大規模システムでは、ant/makeファイルを他のプログラムから生成している人をよく見かける。 上記の理由で、私はBruceの意見に賛成なのだと思う。 簡単なビルドならば、一連のタスクと依存とで簡単に表現することが出来る。こういうビルド
Martin Fowler's Bliki in Japanese - コードがドキュメントだ
http://www.martinfowler.com/bliki/CodeAsDocumentation.html アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる――ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。 おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが"唯一の"ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。 なぜコードが重
Martin Fowler's Bliki in Japanese - ヘロヘロScrum
@@ -0,0 +1,79 @@ +http://martinfowler.com/bliki/FlaccidScrum.html + +2009/1/29 + +//There's a mess I've heard about with quite a few projects recently. It works out like this: + +多くのプロジェクトで混乱が起こっているようだ。 +次のようなことになっているらしい。 + +// * They want to use an agile process, and pick Scrum +// * They adopt the Scrum practices, and maybe even the principles +// * After a while progress is
私の翻訳のやり方 - capsctrldays(2011-03-26)
■ 私の翻訳のやり方 秋から半年かけて2冊の本の翻訳をしたので、そのやり方をまとめて書いてみる。翻訳本の宣伝はまた後日。 1. テキストデータ化する まずは何はともあれテキストデータにする。 私は、テキストエディタと電子辞書を使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。 元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙（原書）なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではな
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に適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
