Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
capsctrl - プロフェッショナルの条件
生産性をいかにして高めるか 資本と技術は生産手段にすぎない 「より賢く」働くことが生産性向上の唯一の要因 ただし、肉体労働と知的労働の場合とでは意味がちがってくる 「何が目的か。何を実現しようとしているか。なぜそれを行うか」を問う 仕事の再定義 仕事の種類（成果の判断） 質のみ 質と量 成果が肉体労働と同様（質は制約条件） 自らが教えるときにもっともよく学ぶ なぜ成果があがらないのか ものごとをなす ＝ 成果をあげること だけど知的労働において、成果とは簡単には上げられない 従来の肉体労働における「成果」とは違う 知的労働で生まれる「成果物（知識、アイデア、情報）」はそれ単体では役に立たない 自らの成果物を、他人に供給する必要がある 成果を求められるが、成果をあげられない環境にいる 時間は他人にとられる 日常業務に追われつづける 組織で働いている 自分の成果を使うのは、組織上で上から横のひ
7つのデータベース 7つの世界 - capsctrldays(2013-02-14)
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種類の次世代
Martin Fowler's Bliki in Japanese - ドメイン特化言語
http://martinfowler.com/bliki/DomainSpecificLanguage.html ドメイン特化言語(DSL:Domain Specific Language)とは、 ある特定の種類の問題に特化したコンピュータ言語のことです。 様々な問題に対応できる汎用的な言語のことではありません。 ドメイン特化言語についてはこれまでも議論されてきましたし、 コンピュータが使われてきたのと同じくらい長い間使われてきました。 DSLを頻繁に使用しているコミュニティにUnixコミュニティがあります。 そこでは、DSLは「リトル言語」や「ミニ言語」などと呼ばれています （この伝統について、Eric Raymondが素晴らしい議論を提供してくれています）。 最も一般的なUnixスタイルのやり方は、 言語の文法を定義し、コード生成機能を使ってDSLから汎用的な言語を生成する、 あるい
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
PofEAA's Wiki - CatalogOfPofEAA
原文: http://www.martinfowler.com/eaaCatalog/index.html Last Significant Update: January 2003 以下は、『Patterns of Enterprise Application Architecture (P of EAA)』で扱ったパターンの簡単なサマリである。 各パターンの概要をページ毎に載せているが、パターンは単独で用いられることを想定していない。これは、パターンに馴染みのある人向けの、単なる覚書のようなものである。これで気軽にオンラインでパターンを参照することが出来ましょうぞ。 将来的にここにコメントを追加するかもしれないが、とりあえずこれがうまく行くことを見守ろう。 David Heinemeier Hanssonが私のために素晴らしいダイアグラムを書いてくれたんだが……このVisioが吐いたG
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 - 生産性は計測不能
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
Martin Fowler's Bliki in Japanese - 大きな画面
http://martinfowler.com/bliki/BigScreen.html 2006/12/16 ソフトウェア開発者の生産性を向上させるにはどうすればよいか？ 私が長年使っている答えは、大きな画面を与えよというものだ。 これは、コンピュータを使用している人ならばどんな人にも当てはまることである。 15年前に「すべての開発者は21インチ以上の画面で仕事をすべきだ」と言ったときには、ものすごい勢いで驚かれたものだが、今は「20インチの画面を2つ以上使うべきだ」と言っている。 なぜこれが重要なのだろうか？ 小さな画面を使っていると、一度に多くのことを見ることができない。 別のものを見るには、そのウィンドウを前面にもってこなければならない。 画面を2つ使えば、すべてを一度に表示できる。頭を横に振るだけで済むのだ。 Emacs上でタイプしているテキストと、firefox上にレンダーされ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
