サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
capsctrl.que.jp
http://martinfowler.com/bliki/PurposeOfEstimation.html 2013年2月27日 見積もりの目的 アジャイルソフトウェア開発の私の出会いは、エクストリーム・プログラミングの始まりとして、ケント・ベックと働いたときでした。そのプロジェクトで印象的だったことの一つは、計画のやり方でした。これは見積もりをする方法を含んでいます。それは今までに見たものよりも、軽量でありながら効果的であるという両方をもっていました。それから10年以上過ぎた今、経験のあるアジャイル主義者の間には議論があります。それは見積もりというものが、本当に行う価値があるものなのか、それとも実は激しく害があるかということです[1]。私は、この問題に答えるために、見積もりが何の目的に使われるのかを見ないといけないと思っています。 一般的なシナリオでは次のように進行します: 開発者は、
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった (この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ)。 ユニットテスティングは
■ [Agile] 新アジャイルマニフェスト Justin.tv - Startup Lessons Learned - Kent Beck talks beyond agile programmingで、ケント・ベック師父が言ったらしい。 Team vision and discipline over individuals and interactions (or processes and tools) 個人と対話(やプロセスやツール)よりもチームのビジョンと規律を、 Validated learning over working software (or comprehensive documentation) 動くソフトウェア(や包括的なドキュメント)よりも有効で妥当な学習を、 Customer discovery over customer collaboration (or
@@ -0,0 +1,81 @@ +http://martinfowler.com/bliki/DesignStaminaHypothesis.html + +2007/6/20 + +'''ソフトウェアをきちんと設計するのは、その労力に見合うことなのか?''' + +「ソフトウェアをきちんと設計することって、そんなに大切なことなの?」という問題について、遠回しなやりとりをすることが時々ある。 +あえて「遠回しなやりとり」と言ったのは、はっきりと「ソフトウェアの設計なんて無意味だ」と言う人を見たことがないからだ。 +そういう考えの人は、たいていこんな言い回しをする。 +「立ち止まっている暇なんてない。とにかく前に進まないと来年の目標を達成できないんだ。 +だから、≪設計に関する何かの作業≫は省略するよ」 + +そこにあるのは、設計と素早い開発の間には何らかのトレー
原文: http://www.martinfowler.com/eaaCatalog/identityMap.html ロードされたオブジェクトをマップ内に保持し、各オブジェクトが1度だけロードされることを保証する。オブジェクトが参照されたときは、マップを使って探し出す。 解説の全文は『PofEAA』 195 ページを参照。 古くから「時計を2つ持つ者は、決して時間が分からない*1」と言われる。 2つの時計が間違っていたら、データベースからオブジェクトをロードする際により大きな混乱に巻き込まれる可能性がある。 気を付けないと、同じデータベース レコードからデータをロードし、 異なる2つのオブジェクトに入れてしまうこともある。 2つのオブジェクトを更新した場合は、 変更点をデータベースに正しく書き出す際、注意しなければならない。 これに関係するのは、パフォーマンス問題である。 同一データを複
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html 2009/10/14 ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か? 逆に、そう呼ぶべきでないものは何か?といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「 a mess is not a debt」だ。 彼の意見は、こういうことだ。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 技術的負債という言葉はもっと特別な場合を指すものだ。 検討の末に、長期的な持続性のない(けれども短期的には利益を生み出す。たとえばすぐにリリースできるなどの) 設計指針を敢えて選択するといった場合に使う。 要するに、負債を抱えれば早めに価値を生み出せるけれども、いずれ返済しないといけな
新刊案内:スクラムの作者2人によるマネージャのためのスクラム入門 Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド Ken Schwaber/Jeff Sutherland/角征典/吉羽龍太郎/原田騎郎/川口恭伸 アスキー・メディアワークス ¥ 1,680 私にとっては10冊目の翻訳書です。日本のスクラムで著名な3名の方と共訳しました。ソフトウェア開発手法であるスクラムを使って「組織を変革していく」という内容です。 私は知らなかったんですが、組織改革では著名なジョン・P・コッター教授の『 カモメになったペンギン(ジョン・P・コッター/ホルガー・ラスゲバー/野村 辰寿/藤原 和博)』などを引き合いにだしながら、スクラムを組織に広めることをスクラム的にやる、という論を展開しています。また、付録に「スクラムガイド」もついていますので、ミドルアップダ
7つのデータベース 7つの世界2013年02月26日発売 7つのデータベース 7つの世界 Eric Redmond/Jim R. Wilson/角 征典 オーム社 ¥ 2,940 開発者に新しい視点を与える7つのデータベース! 近年、伝統的なRDBMS(リレーショナルデータベース管理システム)ではない、いわゆるNoSQL系の次世代DBMSが、クラウド上で動く分散アプリケーションの普及を背景に台頭しつつあります。しかし、さまざまな実装が群雄割拠しており、導入しようにもどこから手をつけたらよいか分かりにくい状態です。 本書は、NoSQL系DBMSに関心がある技術者を対象として書かれた“Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement"の日本語訳です。特徴的な7種類の次世代
スクラムマスターは開発メンバーになれるのか?スクラムに関する資料を作っていて疑問に思ったのでQuoraで質問してみました。自分で訳しておいてあまり覚えていないので、改めて「スクラムガイド」を読んだんですが、明示的に書かれているところはありませんでした(できるというようなニュアンスはある)。 で、はじめてQuoraを使ってわかったんですけども、名指しで回答してもらうことができるんですよね。というわけで、Jeffに名指しで質問してみました。そしたらソッコーで答えが返ってきた! http://www.quora.com/Scrum/Can-scrum-master-be-one-of-development-team-members/comment/233021 簡単に訳しておきます(正確には上の英文を読んでおくれ)。 「スクラムガイド」に載ってないんだったら、ウォマック博士の『リーン生産方式が
2012年のJolt Awards: The Best Bookshttp://www.drdobbs.com/joltawards/jolt-awards-the-best-books/240007480 How Google Tests Software James A. Whittaker/Jason Arbon/Jeff Carollo Addison-Wesley Professional ¥ 2,047 参考:グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? Running Lean: Iterate from Plan A to a Plan That Works (Lean Series) Ash Maurya Oreilly & Associates Inc ¥ 1,462 私が絶賛翻訳中です!! ワークショップも開催予定です。 Ele
学生になりますよと。いろいろ思うところがありまして、10月から産業技術大学院大学の情報アーキテクチャ専攻に進むことになりました。ずいぶん前に合格通知は来てたんですけど、ようやく入学案内がきたのでご報告(忘れられてるのかと思ったよ)。 理由は子どもが生まれたから なんで学校行くの?と聞かれるんですけど、子ども(1歳)と一緒にいたいってのが最大の理由です。大学院は2年間ですから、ちょうど幼稚園に行く頃までは一緒にいる感じですね。土曜日は授業でつぶれちゃうんですけど、平日の授業は夜からなので、今よりは時間に余裕ができるんじゃないかと思います。 mizzyさんのエントリを読んだから でも、どうすれば一緒にいられるのかよくわかんなかったんですよね。もちろん何もせずにプラプラしててもいいんですけど……。そんなときに、mizzyさんが大学に行きたいというようなことをFacebookに書いていて、ああ大学
サービスデザインパターン SOAP/WSDLとRESTful Webサービスの基本的な設計ソリューション(Robert Daigneau/角 征典/高木 正弘)発売日に表紙も在庫もないっていうのはどういうことなんだ!!!! 個人的にはマーチン・ファウラーの文章(序文)をはじめて翻訳したぜっていう記念(マーチン・ファウラーに縁がない私……)。あと、高木さんの翻訳スピードが半端ないので、遅れないようにキビキギとやれました。 RESTのところはyoheiさんに(これは間違いない)、SOAPやWSDLのところはレビューアの方々に助けてもらいました。 ツッコミを入れる
風邪治療のベストプラクティス子どもができてから頻繁に風邪をひくようになった。 これは自分だけでなく、きちんとデータも出ているらしい。 であれば、風邪にかからないようにするための予防策よりも、 風邪をいち早く治すベストプラクティスが知りたい。 基本知識 風邪の病原菌は細菌ではなくウィルスである。 したがって、抗生物質は効かない。 「風邪薬」は症状を緩和するだけで、風邪が治るわけではない。 風邪は治らないだと? 風邪は薬で治るわけではないけれど、 体内にはウィルスと戦ってくれる奴が存在する。 それがリンパ球である。 リンパ球がウィルスを退治すれば体内に抗体ができる。 抗体ができれば同じウィルスの風邪にかかりにくくなる。 ただし、風邪のウィルスは何百種類もあるので、 風邪全般にかかりにくくなるわけではない。 抗体のことはさておき、 このリンパ球を活性化させれば、 ウィルスを早めに退治できるという
リーダブルコード − 忘れてもいいコードを書こう。当日の資料を置いておきます。 20120706-readablecode View more presentations from Masanori Kado ツッコミを入れる
新刊『リーダブルコード』が6/23に発売されますが、すでに誤植がありました。『リーダブルコード』がInterropで先行発売されたようです。 私の手元にはまだ書籍がありませんが、先行で手に入れた方のツイートで誤植のあることに気が付きました。 具体的には、第1章にある「1.1 「優れた」コードって何?」のサンプルコードが間違っていました。 (1) for (Node node = list-head; node != NULL; node = node-next) Print(node-data); ↓ for (Node* node = list->head; node != NULL; node = node->next) Print(node->data); (2) Node node = list-head; if (node == NULL) return; while (node
http://martinfowler.com/bliki/TestCoverage.html 17 April 2012 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか?」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある
Fearless Journeyの簡単なまとめ作っておきました。 Fearless Journey View more presentations from Masanori Kado ツッコミを入れる
Fearless Journeyの翻訳の草稿を公開しました。『Fearless Change』という書籍で紹介されている48のパターンをゲームにしたFearless Journeyというものがあります。サイトの「FREE Download」から無料でPDFをダウンロードできます。このなかから「ルール」と「戦略カード」の2つを日本語にしておきました。 http://dl.dropbox.com/u/325565/FearlessJourney/FearlessJourney_v1.0_Rules(ja).pdf http://dl.dropbox.com/u/325565/FearlessJourney/FearlessJourney_v1.0_StrategyCards(ja).pdf 何かフォードバックをもらえると嬉しいです。しばらくしてから(1週間くらい?)本家に送って、本家のサイトか
昭和アジャイルライダーの解説 昭和ライダーとアジャイルマニフェストのメンバのマッピングの解説。 まあ、興味のある人だけ読んでおくれ。 Bob Martinが新しい方法論をまとめようと思い立ちました(一号ライダー)。 最初に声をかけたのは、Alistair Cockburnです(二号ライダー)。この2人で話し合った結果、一箇所に集まって議論しようということになりました。 開催場所はスノーバードに決まりました。ホテルを予約するときに3人の書名が必要になりました。そこでお願いしたのが、Jim Highsmithです(V3)。 1人だけ科学者っぽい人がいます。シュレイヤー/メラー法のSteve Mellorです。もちろん、ライダーマンです。 Ward & Kentはペアにしたいと思いました。この2人といえばxUnit。XライダーとZXに割り当てました(年下のKentがZX)。# 武器を使うのもこの
Clean Coder プロフェッショナルプログラマへの道(Robert C. Martin/角征典)宣伝。ボブおじさんの著書を翻訳しました。(Amazonにまだ書影がない!!) アジャイル開発やオブジェクト指向で有名な著者が自らの失敗を赤裸々に語りつつ、ソフトウェア開発者が本物のプロへと成長する方法を指南する啓発書。ボブおじさんの失敗から正しいプロの態度・規律・行動を学ぼう! 大雑把に言えば、プログラマのための自己啓発書みたいな感じですかね。まあ、そういうのに興味のない人はたくさんいると思いますけども、そういう人たちにとっても、ボブおじさんが20代・30代を過ごした昔話は、それなりに楽しく読めるんじゃないかと思うんです(1970年代の話です)。 技術的におもしろいというよりも、人間の過去がわかるというのは、それだけでおもしろいじゃないですか(そうじゃない?)。実際、ぼくには60歳以上のプ
http://martinfowler.com/bliki/DiversityImbalance.html 2012/01/11 簡単に慣れてしまうものだが、 ソフトウェア開発の世界で多様性の問題が深刻なのは明らかである。 つまり、一般的な人口比と比べると、その比率に顕著な違いがあるのだ。 最も明らかなのは、女性の比率が低いことである。 これは世界的にそうなっている(中国ではそうでもないが)。 アメリカでは、私は人生の大部分をここで過ごしているのだが、アフリカ系アメリカ人が少ないのも明らかである。 このような不均衡が存在する理由や、 その対策について書かれたものは数多く存在する[1]。 だが、私はより根本的な問いに集中したいと思う――これは重要な問題なのだろうか? 女性はプログラミングの適性や傾向を持っていないので、 こうした多様性の不均衡は自然のことだ、という意見をよく耳にする。 この考
次のページ
このページを最初にブックマークしてみませんか?
『http://capsctrl.que.jp/』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く