Martin Fowler's Bliki in Japanese - AltNetConf
http://martinfowler.com/bliki/AltNetConf.html 先週私はAlt.NETのカンファレンスに出席した。 これは、私がブログ界隈で長い間ウォッチしてきた人たちのグループによる、名前を持った最初の会合だ。 Microsoft 技術の長期利用者たちで、自分達の開発哲学が、レドモンド発の正統と思われるものから乖離してきたと感じている人たちのグループだ。 一方、このグループから離れ、Microsoftの世界にとどまって影響を与えてみたいと考えた人たちもいる。 alt.netという単語は David Laribeeがブログで初めて使ったものだ。 カンファレンスはオープンスペースの手法で開催された。 このやり方はそのコミュニティの性質にちょうどぴったりくるものだったと思う。 私はこのコミュニティを代表してしゃべりたいわけじゃないし、コミュニティの定義をしたいわけで
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
Martin Fowler's Bliki in Japanese - Rubyの評価
http://martinfowler.com/bliki/EvaluatingRuby.html ここの読者なら世の中でRubyが騒ぎになっていることをご存知だと思う。 特にRailsというWebアプリケーションフレームワークは大騒ぎだ。 Railsはプログラミングの未来を表したものだという人もいれば、 危険な流れだという人もいる。 私がRubyに触れたのは数年前のことだ。 達人たちにすすめられて、興味を持つようになった。 そしてすぐにお気に入りのスクリプト言語となった。 そのうちRubyを使ってこのサイトのプロダクトを作るようになった。 たとえばこのblikiがそうだ。 諸君、私はRubyが大好きだ。 ただ、私がRubyを好きなことと、Rubyをクライアントのために使うかというのは別問題だ。 クライアントのために使えるかどうかは、Rubyの機能を評価することによって判断できるだろう。
Martin Fowler's Bliki in Japanese - 設計力
http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム
Martin Fowler's Bliki in Japanese - エンタープライズRails
http://www.martinfowler.com/bliki/EnterpriseRails.html Railsのコミュニティでは「エンタープライズ」という言葉がダーティーワードになりつつある。 多くの人にとってRailsフレームワークとは、貪欲にシンプルさを備えたものであり、複雑になり過ぎた「エンタープライジー」なフレームワークへのアンチテーゼなのだ。 先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。 その中にはエンタープライジーなことも含まれていた。 たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。 これに対するDHHの反応は、この上なく痛烈な拒絶であった。Wired誌*1の表紙になった画像をうまく編集して、DHHは自らをソフトウェア界のネオ（救世主）として
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/Transactionless.html 2007/3/18 (更新：Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって（私もそうだが）トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
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 - GroovyかJRubyか
http://martinfowler.com/bliki/GroovyOrJRuby.html 2007/11/27 現在、Java仮想マシン（JVM）上で動くスクリプト言語として、GroovyとJRubyはどちらが優勢なのかという議論が巻き起こっている。 この言語戦争の勝者はどちらなのか！？ 知りたいよねー。知りたいでしょ。 みんなは「プロジェクトに使うのはどっちだ？」とか「今から学習するならどっちだ？」とか気になっていると思う。 まず最初に押さえなきゃいけないのは、このレースの出走馬が2頭だけだと考えるのは公平じゃないってことだ。 JVM上のスクリプト言語の歴史は古く、Jython（JavaによるPython実装）なんてずっと昔から存在している。 他にもいろいろありすぎてよく分からない状況なので、ここではあえて列挙することはしない。「XXXがないじゃないか！」と怒られても困るしね。
Martin Fowler's Bliki in Japanese - 生産性は計測不能
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler's Bliki in Japanese - ひとつの言語