Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
Martin Fowler's Bliki in Japanese - コードがドキュメントだ
http://www.martinfowler.com/bliki/CodeAsDocumentation.html アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる――ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。 おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが"唯一の"ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。 なぜコードが重
新アジャイルマニフェスト - capsctrldays(2010-06-01)
■ [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
Martin Fowler's Bliki in Japanese - 最小インタフェース
http://martinfowler.com/bliki/MinimalInterface.html 最小インタフェースとはAPI設計のスタイルである。 ここでは、ヒューメイン・インタフェースと比較していく。 最小インタフェースの背景にある考えは、クライアントが必要な機能をすべて提供できるようAPIを設計するが、仕事を成し遂げるための必要最小限のメソッドしか提供しないというものである（両者の違いについての例がヒューメイン・インタフェースにあるので参照のこと）。 ヒューメイン・インタフェースの主張はそちらのページに書いている。 ここでは、最小インタフェースの根拠について述べていこう。 インタフェースの習得には時間がかかる。 膨大なインタフェースを持つクラスはうまく使われることが少ないため、 最初の段階ではインタフェースは少なくしたほうがよいだろう。 インタフェースを小さく保ち、それらのメソ
Martin Fowler's Bliki in Japanese - ヒューメイン・インタフェース
http://martinfowler.com/bliki/HumaneInterface.html Ruby界隈で「ヒューメイン・インタフェース」という言葉を何度も耳にした。 この言葉は、クラスのインタフェースを記述する際のrubyistたちの姿勢(attitude)の一部を表したものである。 APIの設計については、2つの異なる考え方を対比していくと面白い（もうひとつは最小インタフェースである）。 ヒューメイン・インタフェースの肝は、みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計することだ。 最小インタフェースとの明確な違いは、ヒューメイン・インタフェースの方が大きくなる傾向があるという点だ。ただ、ヒューメイン・インタフェースの設計者はインタフェースが大きくなることをそれほど気にしてはいない。 以上のことは、ヒューメイン・インタフェースで設
Martin Fowler's Bliki in Japanese - クロージャ
http://martinfowler.com/bliki/Closure.html 動的言語に興味がでてくると、 クロージャやブロックと呼ばれる概念に出会うと思います。 C/C++/Java/C# などクロージャを持たない言語をご使用の方は、 どういったものなのかご存知ないかもしれません。 ここでは簡単にクロージャについて説明します。 クロージャを持った素晴らしい言語を使ったことある方にとっては、 あまり面白くない話かもしれません。 クロージャは長年使用されてきました。 私が最初に出会ったのは、おそらく Smalltalk だったと思います。 Smalltalk ではブロックと呼んでいました。 Lisp ではクロージャを多用しています。 Ruby でもクロージャが提供されています――多くの rubyist がスクリプト言語に Ruby を選ぶのはこのためです。 基本的にクロージャとは、ブ
Martin Fowler's Bliki in Japanese - ドメイン特化言語
http://martinfowler.com/bliki/DomainSpecificLanguage.html ドメイン特化言語(DSL:Domain Specific Language)とは、 ある特定の種類の問題に特化したコンピュータ言語のことです。 様々な問題に対応できる汎用的な言語のことではありません。 ドメイン特化言語についてはこれまでも議論されてきましたし、 コンピュータが使われてきたのと同じくらい長い間使われてきました。 DSLを頻繁に使用しているコミュニティにUnixコミュニティがあります。 そこでは、DSLは「リトル言語」や「ミニ言語」などと呼ばれています （この伝統について、Eric Raymondが素晴らしい議論を提供してくれています）。 最も一般的なUnixスタイルのやり方は、 言語の文法を定義し、コード生成機能を使ってDSLから汎用的な言語を生成する、 あるい
私の翻訳のやり方 - capsctrldays(2011-03-26)
■ 私の翻訳のやり方 秋から半年かけて2冊の本の翻訳をしたので、そのやり方をまとめて書いてみる。翻訳本の宣伝はまた後日。 1. テキストデータ化する まずは何はともあれテキストデータにする。 私は、テキストエディタと電子辞書を使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。 元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙（原書）なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではな
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 のテスティングに対する考えなど、技術的な教訓についても触れる。
capsctrldays - gravatar.rb
1 [tDiary] gravatar.rb Gravatarというのがあるらしく、メールアドレスとアバターをヒモづけるものらしい。 tDiaryでも使いたいと思ったけど、コメント周りは直接skelに手を入れないといけないみたいだ。 とりあえず、以下のプラグインを入れてから、 # gravatar.rb # # [Manual] # http://gravatar.com/site/implement/url # # * image path # http://www.gravatar.com/avatar/3b3be63a4c2a439b013787725dfce802 # * to specify size # http://www.gravatar.com/avatar/3b3be63a4c2a439b013787725dfce802?s=80 # * to specify rate
PofEAA's Wiki - SingleTableInheritance
原文: http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html クラスの継承ヒエラルキーを、様々なクラスの全てのフィールドのためのカラムを持つ1個のテーブルとして表現する。 解説の全文は『PofEAA』 278 ページを参照。 関係データベースは継承をサポートしない。だからオブジェクトをデータベースにマッピングするときは、その綺麗な継承構造を関連テーブルにどう表現するかを考慮しなくてはならない。関係データベースへのマッピングでは join をできる限り少なくするように努め、複数のテーブルに置かれた継承構造の処理を速く実行できるようにする。Single Table Inheritanceは、継承構造にある全てのクラスの全てのフィールドを、1個のテーブルの中に対応付ける。
Martin Fowler's Bliki in Japanese - Blikiとは
http://martinfowler.com/bliki/WhatIsaBliki.html しばらくblog開発界隈を見てまして、参加せずにはいられませんでした。ただ、blogに夢中になれない何かがありました。まずその名前です。同僚のMike Twoは「blogというのはなんだか内科医に取り除いてもらうものみたいに聞こえる」と言っていました。名前はさておき、blogの記事の命は本来とても短いのです。パパっと書いたものは、読む分には良いのでしょうが、すぐに古くなってしまいます。消え行くものに筆を費やすのは、大変だということが分かりました。 Wikiにも同じような印象をもっています。すばやく記事をまとめられるというのは気に入っていますが、冗長で散漫なサイトになりがちです。 blogは何が更新されたか分かりやすいというのも気に入っています。 RSSとアグリゲーターのおかげです。 というわけで
capsctrldays - FileColumnを使ってみるよ（初級）
1 FileColumnを使ってみるよ（初級） FileColumn - easy handling of file uploads in Rails れしぴぶっくの『Processing Uploaded Images』の「Also See」に載っていたやつ。これはスゴス。クオリティタカス。画像のアップロードが面倒なのでRails嫌いになった人もこれで安心！（たぶん） でも、日本国では確認画面があるのですよ（しかもセッション使わないやつ！）とか思ってたら対応してやがんの！すげー！ というわけで、やり方を見てみるよ。 テキトーなモデルを作るよ(MySQL) CREATE TABLE samples ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, image VARCHAR(200) NULL, PRIMARY KEY(id) ) scaffol
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://martinfowler.com/bliki/Diversity.html 2005/8/28 ThoughtWorksでの大きなテーマのひとつに、 全社的に人材の多様性を促進するというものがある （ここでいう「多様性」とは、ジェンダー・人種・性的嗜好などを指す）。 我々は、女性や非白人種など歴史的に恵まれないグループが快適に過ごせ、 伝統的なWASPのリーダーと同様の機会を得られる会社にしたいと思っている。 Royも混血であり、彼もこの多様性について気にかけている。 私がThoughtWorksについて述べるのは、 会社の名を売ろうとしているからではない（マジで！）。 そうではなく、我々が行っていることについて、良い面と悪い面を深く掘り下げようとしているからだ。 Royの社会的実験という大きな目標と泥臭い現実との間には、大きな溝がある。 多様性はその一例だ。 私にとって至福
AgileData.org in Japanese - リレーショナルデータベース基礎
http://www.agiledata.org/essays/relationalDatabases.html ※ 正確なタイトルは「リレーショナルデータベース基礎: 全体像を視野に入れる」です。 この論文は、Agile Database Techniques Chapter 6より抜粋。 議論を始める前に。リレーショナルデータベースとは、データをストアしたり、場合によっては機能を実装することもできる永続化機構である。 この章の目標は、 リレーショナルデータベース（RDB）技術の概観をつかむこと。 そして、現代組織におけるリレーショナルデータベースの適用について掘り下げていくことである。 RDBはアプリケーションで必要となる情報をストアするために使用される。 アプリケーションとは、COBOLやFORTRANといった手続き型技術、JavaやC#といったオブジェクト指向技術、Visual B
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/concurrencyControl.html この論文は、Agile Database Techniques Chapter 17をまとめたものである。 私とあなた、二人が同時に Customer テーブルの同一行を読み取り、更新、コミットを行うとする。 このとき、どちらの変更が反映されるのであろう？ 私？あなた？どちらでもない？それとも両方？ 同様に、双方が共有のオブジェクトキャッシュから取り出したまったく同じ Customer オブジェクトを更新しようとしたとき、何が起こるだろうか？ 並行処理制御では、共有エンティティ、オブジェクト、データ行などへの同時アクセスを扱う。 システムへどのように並列処理制御を実装するかを理解するためには、まず、コリジョン（訳注: 衝突）の基本 - コリジョンを回避するか、検出して対処するか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20100121.html