平々毎々 (Hey hey, My my)

rock and roll can never die.

月別アーカイブ: 6月 2007

Day 23: 変数の導入(と、Ctrl+Shift+Rでリファクタリングすることの紹介)

元記事

31日間ReSharper一周」の23日目にようこそ。

今日は、そして31日間の残りは、ReSharperのリファクタリングサポートについて話そう。これはVisual Studio 2005で取り入れられたいくつかのリファクタリングと比べてずっと改善されたものだ。

Ctrl+Shift+Rで「ここをリファクタリングする」

ReSharperには、リファクタリング用のコンテキストメニューがある。このメニューには、現在のカーソル位置で意味のあるリファクタリングか、または現在の選択範囲に基づいたリファクタリングだけが含まれる。Ctrl+Shift+Rで呼び出せる。

そこで表示されるものの例はこれだ。

ReSharperの「ここをリファクタリング」コンテキストメニュー。現在のコンテキストで可能なリファクタリングを表示する。

このメニューには他のリファクタリングコマンドも含まれていて、その中には独自に定義されたキーストロークを持っているものもある(それらはれっきとしたVisual Studioコマンドだから、キー割り当てを追加変更することができる)。よく使うリファクタリングがあるのなら、他のキーストロークをいくつか覚えていくかもしれない。でも僕としてはとっかかりのコストが安いのは本当に嬉しい。覚えなきゃいけないのはCtrl+Shift+Rだけだ。

変数の導入

「変数の導入」では新たな局所変数が作成され、選択した式で初期化される。そして選択した式は新しい変数を参照するように置き換えられる。

ReSharperの「変数の導入」リファクタリングダイアログ。Ctrl+Shift+Rでアクセス。

オプションの概要は次のとおり。

  • 変数の型。このコンボボックスが使用可能になっているのを見た覚えがない。いつも式が表す特定の型に固定されている。代わりに基底型を使いたければ、まず変数を導入して、それから型を変えないといけない。
  • 変数名。もちろん、ReSharperによる変数名の提案はここでも効く。ある1つの提案名が記入されていて、他のを見るにはコンボボックスをドロップダウンすればいい。
  • 式をすべて置換。導入するのは局所変数なので、現在のメソッド中の式が置き換わるだけだ。もし同じ式が1回以上あるのなら、たいていはこのオプションにチェックしたいと思うだろう。でもこれは、副作用とか別名変数とかによって、コードの振る舞いを変えることがある。だからこのオプションはデフォルトでチェックされていないんだろう。
  • 定数の導入。これは別のリファクタリングでもおかしくなかったが、「変数の導入」に統合されている。このチェックボックスは、式をコンパイル時に評価することができる場合だけ使用可能になる。

青色を取り除く

このダイアログを表示するとき、式がメソッド中に1回以上現れているなら、ReSharperは使用部分をすべて青でハイライトする。そしてカラーバーに青い目盛りも表示する。

「変数の導入」ダイアログをキャンセルした後でも式が青くハイライトされたままになるReSharperの「機能」。

「変数の導入」ダイアログをキャンセルしても、青いハイライトは消えないし、カラーバーの青い縞も消えない。これをバグ報告したが、いいえバグではありませんと言われた; これには目的があって、この式が現れている全ての場所を見ることができるようにです、だと。キャンセルボタンを使って式を探すなんてことは初めて聞いたよ。(おまいら、OKとキャンセル以外に別のボタンがあった方がいいとは思わないか?「使用状況の表示」ボタンとか?)

追記: 最初に書いたときには気づかなかったが、OKをクリックしても青いハイライトはとどまっている。だから何をやろうが関係なく、ダイアログを表示したなら、閉じた後に忘れずにEscを押す必要がある。おまけで余計な1ステップを、毎回毎回。ReSharperはものごとを簡単にし、一般的なタスクにかける時間を少なくするためのものじゃなかったのか?ブーブー。

わーわー言ったが、2ヶ月かかってやっと青色表示を消す簡単な方法を見つけた。Escを押すだけ。これはぜひ知っておくべきだ。でないとかなりしつこいからだ。Escを押さなければ、このハイライトはファイルを閉じるかコードを削除するかするまでずっと残っているぞ。

注: 明日の記事はまだあんまりできてないけど、今週末は外出してしまう。なので明日分の記事は日曜日に投稿されるだろう。

広告

インタフェースの変更

私には全く信じがたい言葉です。まともなソフトウェア開発をやっている人間なら、決してこんな言葉は吐かないはず。普通、ソフトウェア開発をやっている人間には次のパターンが存在するように思います。

  1. もう関心がないので、実は放置したいと思っているか、実際にそうしている。
  2. やる気あり。どんどん改善できるところはやりたい。でも既存のユーザを無視できないので、そう簡単には変更できない。
  3. やる気あり。もういっぱい変えたくてたまらないし、実際にそうしている。ユーザなんて知ったことではない。

私が思うに、結城さんが言っているのは最初のパターンで、こんなのはまともな状態とは言えないのだから、変えない方が楽とかじゃなくって、何もしないのが楽って言っているだけです。放置プレイ。そんなのは開発とは言えません。

enbug diary 2007-06-24

外からの観測だと2×2=4通りじゃないかと思った。

  1. 既存ユーザーを無視した
  2. 既存ユーザーを意識した
  1. 変えなかった
  2. 変えた

そうすると、

  • a-i. 放置。たぶんやる気がない。
  • a-ii. じゃんじゃん変更。自己中心的。
  • b-i. 現状維持。現ユーザの希望を重視。反面、自分の意見を通した結果生じる混乱や面倒を引き受ける気がない。
  • b-ii. 最後には変更。優しい独裁者。可能な限り現ユーザを説得する。説得できなかったときは最終的に自分の判断を重視する。

ってなる。で、結城さんはb-iiよりはb-iの方が楽と言っているんじゃないのかな。もちろん本意はわからないけど。

System.Data.SQLite

SQLiteエンジンの.NET Framework実装(だと思う)

http://sqlite.phxsoftware.com/

本体はManaged DLL1個。組み込み用途としてお手軽。Javaにもこんなの(Pure Java SQLiteエンジン)があってもおかしくないと思ったが、JavaにはJava DB、というかApache Derbyがあるからいいのか?ごめんなさいよく知りません。

蒙古タンメン中本目黒店

蒙古タンメン中本

北極ラーメン

北極

から

うま

Day 22: Alt+Insでコード生成

元記事

31日間ReSharper一周」の22日目にようこそ。

さて、Alt+Enterはネタにし終わった。全てはコード修正に関するものだ。これで新規コードが生成されるときもある(例えば、クラスがインターフェースを実装するように変更したときには、Alt+Enterはメソッドの実装を生成しないといけない)けど、焦点はエラーや警告を修正することにある。

今回のネタはAlt+Insだ。これははっきりとコード生成に狙いを定めたものだ。

Alt+Insメニュー

Alt+Insを押すとメニューが現れ、コード生成コマンドを全て表示する。このメニューはいつも全てのコマンドを表示し、利用できないものはグレーアウトされる(利用可能なものだけ表示する他のReSharperメニューとは対照的だ)。

Alt+Insはクラス内にコードを生成するので、カーソルがクラス内にないときにAlt+Insを押したらすべてがグレーアウトされる。

Alt+Insウィザードの共通機能

Alt+Insコマンドはすべてウィザードを表示する。ウィザードのページには一般的に、生成されるコードで考慮したいもの(たとえばフィールド)を選ぶことができるリストが含まれているだろう。

ウィザードページには2種類のリストがある。チェックリストと普通のリストだ。

上の通り、チェックリストには各々のアイテムの隣にチェックボックスがある。アイテムを0個以上選ぶことができるときに(つまり、「選択しない」ことに意味がある場合に)使われるようだ。

普通のリストにはチェックボックスがない。選択するときはリストからアイテムを1つ以上選ぶ。これは標準的な複数選択リストボックスだから、Shift+クリックやCtrl+クリックで複数のアイテムを選択できる。

普通のリストは、少なくとも1つのアイテムを選ばなければならないときに使われるようだ。しかし実際には強制されない。唯一選択されているアイテムをCtrl+クリックして選択解除し、ウィザードの次の画面に進むと、ちょっと面白い結果になるだろう。

もしリストのすべてを選択したいなら、簡単にできる。チェックリストでは、Ctrl+Aを押した後にSpaceを押す。普通のリストでは、単にCtrl+Aを押すだけだ。

コンストラクタの生成

このコマンドでは、クラスのフィールドをいくつかまたは全て初期化するための、引数付きコンストラクタが生成される。どのフィールドを初期化したいかを選ぶことができるチェックリストが表示される。

注意すべき機能:

  • 垂直掘り下げ。ベースクラスのコンストラクタが引数をとる場合は、新しく生成されるコンストラクタは自動的に同じ引数をとり、それをベースクラスのコンストラクタに渡す。これらの引数はパラメータリストの最初に置かれる。(後で、お好みでパラメータを並び替える機能について話そう。)
  • 複数コンストラクタ。ベースクラスに複数のコンストラクタがあるときは、どのコンストラクタを呼び出すかを尋ねる第2のウィザードページがある。2つ以上選んだら、新しく2つ以上のコンストラクタが生成される。
  • アホ。コンストラクタがすでに存在しているかどうかのチェックはない。すでに存在するのと同じ引数を持つコンストラクタを生成するような指示をすれば、よろこんでやってくれる。その結果コードがコンパイルできなくなるので赤い波線が表示される。良いコードが生成されるか確認しないたった2つのAlt+Insコマンドのうちの片方がこれだ。

プロパティの生成

コマンドは3つある。「読み取り用プロパティ」、「書き込み用プロパティ」、「読み書き用プロパティ」だ。動作は一緒。どのフィールドにプロパティを生成するかを尋ね、その通りにする。

この機能は賢い。すでにいくつかのプロパティを作成していたなら、それらのフィールドはウィザードで選択できない。もしすべてのフィールドにプロパティを作成していたなら、メニュー内でプロパティ生成コマンドが全部使用不可になる。

インターフェースメンバーの実装

この機能は実はAlt+Enterを使った「メンバーの実装」と同じものだけれど、こっちはインターフェースメンバーだけが表示され、抽象メソッドは表示されない。

継承メンバーのオーバーライド

これも同じで、Alt+Enterの「メンバーの実装」とほぼ同じだけれど、(a)インターフェースメンバーは表示されないことと、(b)抽象メソッドだけでなく、(非抽象の)仮想メソッドも表示することが違う。

Equals()とGetHashCode()もリストに表示されるけど、それをオーバーライドするにはもっとすごい方法があるって事を覚えておいてほしい――Alt+Insメニューにある「EqualsとGetHashCode」を使おう。下で記す。

委譲用メンバーの生成

アダプタデコレータを書いているとき、もしくはデメテルの法則に従ったコードを書きたいってだけのときでも、この機能は本当に便利だ。こんなコードが生成される。

public int Length
{
    get { return _inner.Length; }
}
public void GetFoo(FooSpec spec)
{
    return _inner.GetFoo(spec);
}
public void DoSomething()
{
    _inner.DoSomething();
}

この例では、LengthプロパティとGetFoo()およびDoSomething()メソッドを_innerフィールドへ委譲している。「委譲用メンバーの生成」ウィザードでは2~3回クリックすればすむし、一度に複数のメンバーができるし、ヒューマンエラーの傾向は手で書くよりもずっと少なくなる。

どんなフィールドやプロパティに対しても委譲することができる(ので、例えば遅延初期化される何かに委譲してもいい)。まずフィールドやプロパティを選び、そして次のページで、委譲したいメンバーを選ぶ。

「コンストラクタの生成」と同じくこの機能もアホだ。同じメソッドシグネチャを1度以上委譲できてしまう。そうするとコンパイルできないコードになってしまう。

EqualsとGetHashCodeの生成

EqualsとGetHashCodeをオーバーライドしなきゃいけないことはそんなにないけど、もしやるなら、自動化の支援があれば大歓迎だと思う。

ウィザードはまず、Equals()メソッドでどのフィールドを比べたいのか聞いてくる。次に、GetHashCode()の計算にどのフィールドを使うのかを聞いてくる。賢いことに、等価性の決定に使われていないフィールドがあったなら、そのフィールドはハッシュコードの計算に使わないほうがいいことを分かっている(つまり、最初のページでチェックしなかったフィールドは、2ページ目で利用できない)。

もし選んだフィールドに参照型があれば、ウィザードに3ページ目が存在し、非ヌルであることが想定できるフィールドがあるか聞いてくる。もしあれば、GetHashCode()の実装を単純にできる。

下は結果として生成されるコードの例だ。_nameは非ヌルであるとしている。_addressは違う。

public override bool Equals(object obj)
{
    if (this == obj) return true;
    Foo foo = obj as Foo;
    if (foo == null) return false;
    if (_x != foo._x) return false;
    if (_y != foo._y) return false;
    if (!Equals(_name, foo._name)) return false;
    if (!Equals(_address, foo._address)) return false;
    return true;
}
public override int GetHashCode()
{
    int result = _x;
    result = 29*result + _y;
    result = 29*result + _name.GetHashCode();
    result = 29*result + (_address != null ? _address.GetHashCode() : 0);
    return result;
}

ReSharper3.0リリース

されました。

「the 31 days of ReSharper」訳し終わってNEEEE!

Customers who have purchased ReSharper 2.0 or 2.5 after April 15th, 2007 qualify for free upgrade* to ReSharper 2.5.

買ったのは2007年1月だから無料にはならNEEEEE!って、まあ半年近く使ってるわけだし、こんなもんだろう。もともと安く($99で)買ってるわけだし。

個人ライセンスのアップグレード価格は

Personal License $199

The upgrade price is $119

こんな感じ。100ドル以上出さないとメジャーアップグレードできないのは残念だが、まあこんな所かねえ。

「やさいのようせい」――天野喜孝の絵で3DCGアニメ――

朝起きてNHK教育をつけたら放送してたよ。

天野喜孝タッチの野菜たちが、実に繊細な動きをしていた。引き込まれてしまった。

Day 21: Alt+Enterでコード変形

元記事

31日間ReSharper一周」の21日目にようこそ。今日はAlt+Enterネタのまとめだ。

Alt+Enterでコードを修正して、エラーや警告を無くす方法はすでに説明した。赤い電球が表示され、Alt+Enterを押せば応急処置を表示できる。

任意の応急処置もある――コードに適用することもできるけど、しなくてもいい。単にみんながよくやることだから、ちょっと便利なようにReSharperが自動化してくれる。

任意の応急処置は、黄色の電球で表示される。

それらはちょっと見つけにくいかもしれない。カーソルを適切な場所に置かないといけないからだ。エラーや警告の応急処置についてもそうなんだけど、そっちは適用できる場所を見つけられる。赤や灰色や波線だ。それにF12で次の場所に移動できる。任意の応急処置については、カーソルを適切な場所に置いて0.5秒ほど待たないと、手がかりが見えるようにならない。それに次の場所に移動するキーストロークもない。まさに、(a)すでにそれらが存在することを知っているか、そうでなければ(b)偶然見つけるか、どちらかでないといけない。

だから今僕が何個かネタにする。何を探せばいいかわかるようにね。

使っていない中かっこを取り除く

複数の文を含んでいるので中かっこを持っているifブロックがあると思ってほしい。そこからコードを修正してコードが1行になったので、中かっこはもう不要になった。

カーソルの置き場所: 開き中かっこまたは閉じ中かっこの所(直前でも直後でも可)。

if文中の不要なかっこを取り除く、ReSharperの任意応急処置

可視性の変更

カーソルをprivateやprotectedやinternalやpublicキーワードの上に置くと、黄色の電球が表示される。Alt+Enterを押せば、その可視性を変更できる。タイピングの節約にはあまりならないけど、時々便利だ。

カーソルの置き場所: 可視性キーワード内ならどこでも可。

メンバの可視性を変更する、ReSharperの任意応急処置

変数と割り当ての分離

もしある変数が宣言の一部で値を割り当てられていて、値の割り当てを条件つきにするとかそんな類のことをしたくなったなら、「変数と割り当ての分離」を使って、値の割り当てを別の文にすばやく分割できる。

カーソルの置き場所: 変数名の上か、または’=’記号の上。

変数宣言と値の割り当てを分割する、ReSharperの任意応急処置

変数と割当ての結合

逆の変形も有効だ。「変数と割当ての結合」は変数宣言を、最初に値が割り当てられている行に移動する。

カーソルの置き場所: 変数が最初に値を割り当てられる行の、変数名の上か、または’=’記号の上。

変数宣言と値の最初の割り当てを結合する、ReSharperの任意応急処置

変形の後は下のような見かけになる。注意してほしいのは、宣言が割り当てのところまで下がっているのであって、割り当てが宣言のところまで上がっているわけではないことだ。だからコードの順序依存性が壊れることはない。

変数宣言と値の最初の割り当てを結合する、ReSharperの任意応急処置を適用した後

Ifの反転

これはお気に入りだ。これは単純にif文の条件式を反転させ、"if"と"else"のブロックを入れ替える。純粋に表面的な変更であり、コードの実際の動きには全く影響しない。

カーソルの置き場所: ifキーワードの上。

かなり予想がつくだろうから、つまらない実例は出さない。でもこれは単純に条件式およびブロックを反転させるよりはすこし賢い。どうしてお気に入りなのかは、下の例を見てほしい。

メソッド全体に広がるif文。ReSharperが改善できるコード。

こういうことは時々起きる。メソッド全体にif文が広がっているわけだ。「Ifの反転」をするとこうなる。

ReSharperがメソッド全体にわたるif文を反転させた後

if文がメソッドの最後にあることを判別し、することがなければ、早くメソッドから出て行くようなreturn文を生成する。大きいコードブロックのインデントレベルがひとつ減り、メソッドのコード行もひとつ減る。すごい!

Web+DBでつきぬけろ!!

見本誌いただきました。いつもありがとうございます。

WEB+DB PRESS Vol.39

id:amachang、かくたにさん、高橋さんの連載も始まり、ますますすごいことに。

特集1は構成管理。重要だ。いいところついてきた。(ところで今号の表紙、特集1のフォントはメイリオだ。)何気に面白いと思ったのは特別企画。うーん、エンタープライジー。あと一般記事にマジカ!。こっそりカメラスキープレス。

.NET連載では予告どおりAJAX話です。ポトペタでできるのはやっぱすごいですよ。

次号予告!いよいよIronRubyがベールを脱ぐ!!IronRubyの目的は!?Silverlightにつきぬけろ!→[マタ]

空気を読まずにRubyMicrosoft粗訳した

昨日書いた記事について、「サヌールがやらねば俺がやる」的な感じで(うそです。調子乗ってすんまっせん)おおざっぱに訳してみた。

(追記)マーティン・ファウラーの Bliki の日本語訳が更新された。訳文のおかしなところが直ったし、ハイパーリンクも追加されているのでそっちを参照のこと。

(更新:反応リンク集を末尾に追加)

RailsConf2007ではJRubyに大興奮だった。この小さなチームは瀕死のプロジェクトを引き受け、JVM上のRubyプラットフォームの一級実装に見えるように変えた。多くの賞賛を得たのは当然だ。

JRubyについてはまさにそんな感じとして、スポットライトはもう一つの共通マネージコード・ランタイム上に動く。.NETだ。Rubyについてのマイクロソフトの意図は今のところすごく不透明だ。彼らはSilverlightのスクリプティング言語としてRubyを発表した――でも未解決の問題が多く残っている。これってRuby言語をフル実装するのか、それともRuby++みたいなもの――Rubyサブセットの拡張――なのか?

JRubyの目的には、異なっているが相補的なものが2つある。1つはJVM用の強力なスクリプト言語であり、Javaアプリケーションに動的言語を織り込むことができる。2番目の目的はJVM上のRubyプラットホームの実装であり、Rubyアプリケーション、特にRuby on Railsアプリケーションを、MRI(Matz’s Ruby Interpreter、現在のC版ランタイム)で動くのと同じようにJVM上で動かすことができる。

マイクロソフトの”Iron Ruby”に対する大きな疑問は、どのくらい互換性をもつことになるか?だ。CLR上にフル実装されるのか?私が受信した電波によれば、John Lam(Iron Rubyの中の人)は完全互換実装にするつもりらしい。でもこれは今の状況だとかなり困難なことかもしれない。もうじきThoughtWorkの中の人になるOla Bini(JRubyのコミッタ)は、MRIのソースコードを見ずにRubyランタイムを実装する方法を知るのはほぼ不可能だと推測している――しかしMicrosoftは、従業員がOSSのソースコードを見るだけでなくダウンロードすることにもおもいっきり制限をかけている。オープンソースコミュニティでは、多くのコミュニケーションがソースコードを通して行われる――このため、オープンソースコミュニティとの共同作業が非常に難しくなっている。

これに暗雲を投げかけているのはもちろん、マイクロソフトとオープンソース界との歴史的な難しい関係だ。過去においては、マイクロソフトはオープンソースコミュニティを中傷し脅す努力をしていた。近年、もろもろは改善されたけれど、マイクロソフトの奥の意図については本当に謎だ。特許による脅しを、マイクロソフトはオープンソースが死ぬまで戦おうとしていることの証明だと見ている人が多い。

他の多くの技術会社とは違い、マイクロソフトはオープンソース界と共存する方法を発見するのに苦労している。マイクロソフトにとっては難しいことなのだ――SunやAppleやIBMとは違い、彼らは圧倒的にソフトウェア会社だから。LinuxやGNUやOpen Officeのようなオープンソースプロジェクトは、マイクロソフトの重要事業ともろに競合する。しかし私は、オープンソースに宣戦布告し、それを根絶しにしようすることが、長期的に現実的な解決案だと感じたことはない。オープンソースは定着している。問題はどのように対応するべきかということだ。

Rubyでは、マイクロソフトの立ち位置は明白なデスマッチとは違う。Rubyはマイクロソフト製品群の中心的な収益発生源とは競合しない。それ以上に、Rubyコミュニティはマイクロソフトと協力したいと本当に願っている。私がRailsConfで話した人たちの大部分は、マイクロソフトがRubyを全面的に支援するのをとても見たがっていた――そして、どうすればそれを実現させるような提案を持ち込むことができるかについての創造的な意見がたくさん出回っていた。コミュニティで聞いた意見は圧倒的に、「Rubyは邪悪なマイクロソフトを倒す」ではなく「どうすれば問題を解決してマイクロソフトのRubyを得ることができるのだろうか」だった。

Chris Sellsが指摘したように、「マイクロソフトは何を狙っているのか」という疑問を考慮しないといけない。理由は2つほど思いつく。1つめは、データセンター内での.NETやWindowsの役割だ。もしマイクロソフトがRubyプラットフォームをサポートしなければ、Ruby on Railsが成功したときにサーバーファームにおいて.NET(およびWindows)から人々が去ってしまうリスクを冒すことになる。

もう1つの理由は人だ。マイクロソフトは公式に認めたくないだろうが、アルファギークがマイクロソフトプラットフォームから去りつつあるというのが本当に懸念されている。マイクロソフトのビジョンは指揮管理組織における死の軍隊だという意見が増えている。優秀なエンタープライズ開発者に可能性を与えるツールや、アジャイル開発プロセスに対するあからさまな支障がたびたび見られる。

数年前、レドモンドの(ちょっとした)つては、技術リーダーたちがWindowsプラットフォームから実際に離れていっているのを見ていると言っていた。最近この兆候は増加しているようだ。私のブログロールの「お人よし部分」を読んで、長い間マイクロソフトのサポーターだった人たちの間に実際に幻滅があるという感じを受けた。アジャイル指向の開発者たちはマイクロソフトツールの方向性に不満を持っている。アジャイルプロセスにはほとんど触れず、ウォーターフォールアプローチにかなり傾いているマイクロソフトのカンファレンス。ツールは、役割の分離が厳密なため、アジャイラーたちが好むぼんやりとした境界を積極的に阻止している。

Tim BrayはRailsConfで、技術についての鍵となる決定はプログラミングコミュニティによってなされると主張した。部分的に同意する。余計で重いソフトがIT界に多すぎる理由は、ITの購買は、ソフトウェア開発の現実との大きな接点をなくした人々によってゴルフコース上で決定されるのが普通だからだ。短期的にはゴルフコースでの決定が支配するかもしれないが、時間が過ぎれば、Timの主張が正しいと思う。だからアルファギークを失っても今年や来年には影響しないかもしれないが、時間とともに容赦なくマイクロソフトに危害をもたらすだろう。

実はマイクロソフトにとってはすでに「来年」が過ぎている。私たちは、マイクロソフトなプロジェクトの顧客、特にアメリカの顧客から、関心が目だって減少していくのを見た。オーストラリアでは、.NETは顧客の地盤をまったく得られなかった。このデータから何を受け取ればいいのかはよく分からない。私たちは統計学的に有効なサンプルになるほど大きくはない。でもそうは言っても、私たちの顧客は「アルファITショップ」だと考えているから、部分的には役に立つデータ点だ。

たぶんもっと重要なのはThoughtWorksの中の話だ。.NETが登場したときは多くの関心が注がれた。たくさんの人がJavaプラットフォームに強力な競争相手が現れたことを歓迎し、.NETのプロジェクトに参画したがった。しかし去年あたりは.NETからの大転換があった。レドモンドから出てくるものには本当に面白いものもあるという事実にもかかわらずだ。Mike TwoはWindows Workflowツールにすごく熱心だし、私はLINQや他の言語進化にとても感心した。でもマイクロソフト技術の全体図にはあくびが出る。これが重要なのは、Tim O’Reillyが信じるように、アルファギークたちは他の人たちが数年間やるであろうことを指し示すからだ。そして決定的な点は、マイクロソフトに対する態度が憎悪(多くのギークで一般的な態度)ではなく退屈であるということだ。これが、Paul Grahamが「マイクロソフトは死んだ、もはや危険ではないから」と言ったことの意味だ。

オープンソースに対する態度こそがこの問題の大部分だ。Javaが現れたとき、そのポートフォリオには大きな隙間があったし、さらに悪いことにはAPIにはひどい標準ツールがあった(Entity Beansのビジョンが思い浮かぶ)。これらの隙間やひどいアイディアはオープンソースコミュニティが修正した。Antがビルドツールを与え、EJBはSpringとHibernateで置き換えられた。.NETにもギャップはあって、再びオープンソースコミュニティがギャップを埋めるために力を注いだ。ところがマイクロソフトはこういう努力に協力することを拒否している。むしろ台無しにしようと努力しているかのようだ。特にうんざりしたのはNUnitに対するマイクロソフトの反応だ――優れたXUnitテストツールであり、その設計要素がOOPSLAでAnders Hejlsbergに称賛されたが、マイクロソフトは競合ライブラリを出荷してきただけでなく、故意に非互換にしてきた。これは、人々がプラットフォームに対して時間をつぎこむことを奨励するような反応ではない。

公平に言えば、この大失敗は2年も前のことだ。Jim HuguninとJohn Lamを雇うといった行動は、あの印象に対抗するのに一役買った。Chris Sells、Don Box、Jim Newkirkといった技術者はマイクロソフトがより開かれた環境になる努力をしている。しかし、大きな組織はどれも同じだが、マイクロソフトは矛盾する勢力であふれており、どれが勝利するのかは私たちには分からない。

同僚のJohn Kordybackは、全ての中心では、Rubyは「もう一つの.NET言語」ではなく、ソフトウェア開発のコミュニティと態度の全てなんだと気づきつつあるんだと指摘した。Rubyとは、オープンソース、アジャイル思考法、軽量ソリューションが価値としてとても深く浸透したコミュニティなのだ。彼が言うには、レドモンドでの共通の疑問は、「『なぜこの考えが重要なのか?』じゃなくて『なぜこの言語が重要なのか?』って聞かれるんだよ」とのことだ。

だから、私がRubyとマイクロソフトに見ているものはチャンスだ。Rubyコミュニティは、マイクロソフトとともに働きたがっているようだ。このことが、レドモンドがオープンソースとともに働くという問題にどう対処するべきか知ることと、将来の協同作業のための模範となる努力のための機会を提供する。完全なRubyプラットフォームの.NETでの一級実装は、この共同作業のすばらしい成果となるだろう。もっといい結果はたぶん、マイクロソフトがオープンとアジャイルを対象にしたコミュニティとどうやって共同作業するかという例をこの作業が示すことだろう――プログラマーと顧客にとってさらに役に立つ姿勢が、マイクロソフト界の中でさらに広がっていくような、そんな跳躍台となりえる例に。

これについてかなりの反応があった(全リストはTechnoratiにある)。特に読むべきなのは次の人たちからの反応だ: Sam Gentile, Cory Foy, Luke Melia, Jeremy Miller, Rockford Lhotka, John Lam, Evan Hoff, Karl Seguin, Ola Bini, Miro Adamy, Charles Nutter, Peter Laudati, Nick Malik