2007年6月26日火曜日

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

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



  1. 既存ユーザーを無視した

  2. 既存ユーザーを意識した



  1. 変えなかった

  2. 変えた


そうすると、



  • a-i. 放置。たぶんやる気がない。

  • a-ii. じゃんじゃん変更。自己中心的。

  • b-i. 現状維持。現ユーザの希望を重視。反面、自分の意見を通した結果生じる混乱や面倒を引き受ける気がない。

  • b-ii. 最後には変更。優しい独裁者。可能な限り現ユーザを説得する。説得できなかったときは最終的に自分の判断を重視する。


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

2007年6月25日月曜日

System.Data.SQLite

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


http://sqlite.phxsoftware.com/


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

2007年6月22日金曜日

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ドル以上出さないとメジャーアップグレードできないのは残念だが、まあこんな所かねえ。

2007年6月21日木曜日

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

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

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

2007年6月20日水曜日

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文を生成する。大きいコードブロックのインデントレベルがひとつ減り、メソッドのコード行もひとつ減る。すごい!

2007年6月18日月曜日

Web+DBでつきぬけろ!!

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


WEB+DB PRESS Vol.39


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


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


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


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

2007年6月17日日曜日

空気を読まずに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

2007年6月16日土曜日

RubyMicrosoft

ファウラー氏のblikiに"RubyMicrosoft"という記事が。



Indeed it's already past next year for Microsoft.



とか、



And the crucial point is that the attitude to Microsoft isn't hatred (a common attitude amongst many geeks) but boredom. This is what Paul Graham means when he says that Microsoft is dead because it's no longer dangerous.



あたりは感じるなあ。MS技術話はブログ界の大きな話題にならない。びっくりするほどユートピアだ。つかMSワールド=ディストピア、ってことか。



The attitude to open-source is a large part of this problem.



うんうん。nUnitもそうだけど、monoに対する態度とか、Ms-LPLとかもそうだし。僕は「待て、あわてるな。これはMSの罠だ」みたいなことは思っていないんだけど、歩み寄るのはどうしてこんなに難しいのか、とは思っている。気を持たせながらつれないそぶり、とか書くと何かちがうな。MSが変わろうとしているのは感じるんだけど。



But like any large organization, Microsoft is full of contradictory forces and we don't know which ones will prevail.



このあたりはMSの欠点でもあるけど強みでもある。手広く投資するし、大々的にアナウンスするけど、儲からないことの予算は大幅カット、みたいな。ビジネスとはそういうものだとも言えるが、そういうところで、ベイパーウェアとかバージョン3からとか突っ込まれる。



So what I see for Ruby and Microsoft is an opportunity.



愛だろ、愛。そこに愛はあるのかい?愛がなーい!


愛とはコミットし続ける覚悟ってことで、MSの覚悟を見たい(そしてまだ見れていない)んだよ。とか言いつつ、MS技術をメシのたねにしているいち開発者ももっとコミットする覚悟がいるなあと思いながら、駄文〆。

2007年6月15日金曜日

同僚&元同僚と呑み

まあ、職場つながりの飲み会なのは間違いないんだが、今日は8割が技術に関した話だった。

書ける話、書きにくい話、いろいろあった。僕が書きやすい話を2つほど選んでみると。

  1. 技術者のキャリアパスとしてアーキテクトが無いのは困るが、アーキテクトとはテクニカルデシジョンメーカーであり、ハッカーはアーキテクトとは別の所にいるのでは。(仮説)そしてハッカーはハッカーで評価されるといいな。
  2. 社内技術者の組織を超えたディスカッションは重要。掲示板や検索エンジンなどを使った支援は便利だが、それを補完するのはソーシャルネットワークではないか。煙草ネットを無くすならせめて社内SNSは欲しい。

煙草ネット=喫煙室コミュニケーションのこと。ユニシスは全館禁煙になり、煙草を吸う人は屋外の喫煙所に向かう。これが、さらに締め付けが厳しくなるという噂もあったりする。俺は禁煙して煙草フリーな生活なんだけど、煙草ネットのよさは知っている。

2007年6月14日木曜日

『数学ガール』を待つ間に

「ルートの無限入れ子クイズ」に答えてみる。


「僕」の回答


ルートが無限に入れ子になっているけど、落ち着いてみれば、無限積だと分かる。だから下の1行目が書けたら、もう解けたようなもの。
hyuki-a1
2行目の指数のところは、等比数列の和になっている。


ミルカさんの回答


……になっているかどうかはわからない。でもまあきっとこういうことなんだろう。
hyuki-a2


いろいろ追記。


個人的には、前者は手続き型、後者は関数型なイメージ。なぜなら、前者はforループ(等比数列の和ってあたりが特に)、後者は再帰だから。


後者についてはこんなこともぼんやり思った。


  • 求める極限値は、関数f(x)=(2*x)^(1/2)の不動点(のひとつ)

  • 求める極限値に対して「2倍する」という演算と「ルートをとる」という演算を(この順で)適用すると元の値に戻る


ただ値を求めるんじゃなくて、どれだけ寄り道するかだよね。

2007年6月13日水曜日

Day 20: Alt+Enterでエラーや警告を修正

元記事


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


Alt+Enterについては、エラーを修正する方法を2、3種類話した。でもそれは表面をひっかいただけだ。いろんなものが修正できる――全部とは言わないが、かなりのことはできる。それに対象はエラーだけじゃない。結構な種類の警告(灰色)も修正できる。


だから今日は、もう少し例を挙げよう。網羅的ってわけではないけど。


「この警告を表示しない」に関する注意点


コード中のReSharper警告(灰色のコードまたは青波線)の上でAlt+Enterを押すと、応急処置の中のひとつに警告を非表示にするものがある。例えば、「『未使用のprivateメンバー』の警告を表示しない」のように。忠告しておくけど、このコマンドはやめておけ。


一度試してみたんだ。「ここだけ特別にOKとする印として、コメントとか#pragmaみたいなものを追加する」って意味だと思ったから。違った。結局「この条件は二度と、決して、金輪際チェックしない」ってことだった。それにアンドゥもできない。もう一度オンにする正しい設定を見つけるには、ReSharper Optionsをくまなく探さないといけない。


幸い、このコマンド自体を停止させることができる(意図しないで選択してしまい、設定解除をしに行くのと同じページにある)。ReSharper Options > Highlightingに移動して、「『警告を表示しない』のアクションを表示する」のチェックを外そう。


エラーの修正: 戻り値の型の不一致


コードをVS 2003からVS 2005にアップグレードしようとしていて、ジェネリクスを使い始めているとしよう。そして、ユーティリティメソッドがIListではなくIList<foo>を返すようにリファクタリングする。でもそのせいで、それを呼び出している全ての箇所が壊れた。


戻り値の型の不一致に対するReSharperの応急処置


これはメソッドの戻り値をIListに割り当てている呼び出し元の一例だ。この例では、「'errors'の型を'IList<Exception>'に変更」を選びたいだろう。それに、他の呼び出し元でも同じ事ができる。同じ戻り値の型を何度も何度もタイピングし直すのを打ち破る。


エラーの修正: 具象クラスの抽象メソッド


テンプレートメソッドを取り入れている最中ならば、あるクラスに抽象メソッドがあるけれども、クラス自体をまだabstractでマークしていないということがあるかもしれない。


非抽象クラス内の抽象メソッドに対するReSharperの応急処置


この例では、abstractキーワードへカーソル移動して、Alt+Enterを押し、「'クラス名'を抽象クラスにする」を選べばいい。もちろん、クラス宣言までスクロールしてそこでabstractと入力するのには大してタイピングはいらない。ただ、この機能のいい所は、今作業しているコードの上に波線が表示されるので、ファイルの上部にスクロールする必要がないということだ。


警告の修正: 割り当てられたが読み取られない変数


ReSharperでは、宣言されたけど使われていない変数を修正することができるが、大して面白いことはない。一方通行の変数――読まれるけど書かれない、またはその逆――の方が少しは面白い。ということで下の例が、宣言内で割り当てられたけど一度も読み取られていない変数だ。


書かれるが読まれない変数に対するReSharperの応急処置


「(複数の)割り当て」と書いてあるけど、実際そうする。宣言部にある割り当てだったとしても削除されるし、他のどこにあったとしても割り当ては削除される。一度も読み取られないフィールドがあるなら特に顕著だ。ReSharperはどんなメソッド中のどんな割り当てでも削除する。不要になったコードをちぎり捨てるときにとても重宝する機能だろう。


1点だけ気をつけてほしい。もし割り当てに副作用があったなら、その副作用もなくなってしまうだろう。上の例で言えば、値がリストボックスに追加されなくなってしまう。


警告の修正: 読み取られるが書き込まれないフィールド


読まれるが割り当てられないフィールドに対するReSharperの応急処置


これはすごいよ。「(複数の)コンストラクタでフィールドを初期化する」を選ぶだけで完了だ。ReSharperは、新しい引数を自動的にコンストラクタに追加して、割り当てコードを生成する。


変なのは、読み取り/書き込みプロパティを作成する応急処置がないことだ。応急処置で見かけたと思ったんだけど、どう見てもここには無い。


警告の修正: 未使用のパラメータ


未使用パラメータに対するReSharperの応急処置


そうなんだ。ReSharperで未使用のパラメータを削除すると、自動的に呼び出し元も全部修正してコードがコンパイルできる状態を維持してくれる。


時には、余計に灰色コードが増えることもある。特に、7層のコード世界を垂直に掘り下げるようなオブジェクトがあったんだけど、リファクタリングしたのでいらなくなってしまったときなんかに。下の層で削除すると、その上の層でパラメータが灰色になってしまう。


でもそんなのはそうそう見ることはないだろう。ReSharperは、privateメソッドの中でパラメータを灰色に変えるだけのようだから。もちろんばかげている。最低でもprivateメソッド内と同程度には、publicメソッド内で使われていないパラメータのことを気にするだろうからね。


F12とAlt+Enter


エラーや警告を修正するためにAlt+Enterができることの味見ってだけなんだけどね。カラーバーが縞模様になっているなら、F12(次のエラーへ移動)とAlt+Enterを押し続けてみるといい。コードをきれいにするためにReSharperが何をやってくれるのかがよくわかるよ。

2007年6月9日土曜日

Day 19: Alt+Enterでメンバーを実装

元記事


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


Visual Studio 2003と2005にはどちらもインターフェースの実装を支援する機能があった。VS2003の機能はかなり気難しかった。VS2005はだいぶよかった。ReSharperはさらによい。見てみよう。


新しいクラスを作成してクラス宣言に: IFoo を追加すると、現在のコードは(インターフェースを満たすメソッドがクラスにないために)コンパイルできないので赤波線が出る。カーソルを波線つきコードに持ってくると赤い電球が表示され、Alt+Enterを押すと「メンバーを実装」という応急処置が表示される。


ReSharperの「メンバーを実装」する応急処置


同じことは、あるクラスが非抽象クラスなのに親クラスが抽象メソッドを持っているときにも起こる。ただこの場合には第2の応急処置がある。「○○クラスの抽象クラス化」だ。一目瞭然だから無視するよ。


注意してほしいのは、子孫クラスがすでにabstractでマークされているなら、未実装の抽象メソッドがあっても赤波線が出ないことだ。エラーではないからだ。だから応急処置は表示されない。ReSharperにはそれらを自動的にオーバーライドする方法もあるが、今のところ木曜日(22日目)にネタにする予定だ。


「メンバーの実装/オーバーライド」ウィザード


ReSharperの「メンバーの実装/オーバーライド」ウィザードの1ページ目。どのメンバーを実装するのか選択する。


ウィザードの最初のページではどのメンバーを実装したいかを選ぶ。デフォルトではすべてが選択されている。どれか1つでもチェックをはずすのは馬鹿なことだ。未実装のままのインタフェースメンバーや抽象メンバーが残ってしまい、コードはコンパイルできないままだろうから。


リストの上、右上にあるツールバーボタンに注目して欲しい。こいつらでリスト表示を切り換えられる。ツリー表示ではすべてがインターフェースでグルーピングされる。平らなリスト表示ではアルファベット順にソートされる。この設定は、ウィザードでの表示方法にしか影響しない。 どんな順序に並んでいようがReSharperはメンバーを生成する。


下には3つの選択肢がある。「ドキュメントコメントのコピー」、「明示的なインターフェース実装」、そして「インターフェース実装をリージョンで囲む」だ。これらはどう見ても自明です。本当にありがとうございました。それに僕はこいつらをいまだに使ったことがないから、これ以上取り上げることはない。2ページ目に行こう。


ReSharperの「メンバーの実装/オーバーライド」ウィザードの2ページ目。どのプロパティに裏付けフィールドを生成するのか選択する。


2ページ目はReSharper版の方がVisual Studio版よりずっとすごいところだ。プロパティのどれか、あるいは全部に裏づけフィールドを自動作成できるからだ。(ReSharper Optionsで設定した命名規約に沿った)フィールドを追加し、プロパティのゲッターとセッターでそれを読み書きする。メソッドには、一覧でチェックしなかったプロパティと同様、NotImplementedExceptionを投げる代替コードが置かれる。


一覧の全てのフィールドにチェックを入れるには、Ctrl+Aを押してSpaceを押す。


最後にFinishをクリックすればコードが生成される。


注:2ページ目にある「アルファベット順にソート」のチェックボックスは、1ページ目のツールバーボタンと同じ設定だ。「アルファベット順にソート」にチェックすれば、ソートされた平らなリストで表示されるが、チェックをはずせばツリーで表示される。要はこれは、両方のページのためのただ1つのオプション(一方を変えれば他方も変わる)だ。でも、なんだかよく分からない理由で、2つのページでは異なる表示になっている。


さて、「メンバーを実装」はこんな感じだ。単純だけど役に立つ。唯一足りないと思うオプションは、裏づけフィールドのどれか、あるいは全てに初期値を設定するためのコンストラクタを追加することだ。これを自動化する方法もある(22日目に予定してもいる)けど、ウィザードに追加のページがあったならもっとよかったのに。とはいえ、すべてをいっぺんに実装しながら、裏づけフィールドを作成もするという機能は、かなりすてきだ。

2007年6月8日金曜日

ミスター ァァァァーァー ムーンラーイッ

Mono meeting 2007-06-27 Moonlight Specialが気になっている。が、今行っても口ポカーンで聞いてるだけになりそうで気が引けている。


DLRとは言わないまでも(これが一番楽しそうなんだけど)、WPFやXAMLについては仕込んでおかないとダメだなあ。

Day 18: Alt+Enterでいろいろ追加

元記事


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


昨日は赤い電球のことと、それを使ってChange Allを実行する方法について話した。今日は、赤い電球のメニューにあるいくつかの応急処置について話そう。前に書いたとおり、赤い電球があるときには、Alt+Enterを押せばメニューがドロップダウン表示される。


コンテキスト感度


未定義の(赤い)シンボルがあれば、ReSharperはシンボルを定義するための選択肢を表示する。どの選択肢が表示されるかは賢く決まる。



  • シンボルが大文字で始まるなら、「プロパティの作成」(本当は「読み取り専用プロパティの作成」であるべきなんだが。実行されるのはそっちなんだから)が表示される。

  • 「get/setのプロパティ作成」もあるけど、どっちを割り当てるかはここの使用法だけできまってしまう。(全ての使用法を見た上でどっちを割り当てるべきか判断するほどはすごくない。追記: この件に関する要求が多かったので、ReSharperの次バージョンで実装することがすでに決まっている。)

  • シンボルが小文字で始まるなら、「フィールドの作成」と「局所変数の作成」が表示される。

  • シンボルの後に開き括弧が続くならば、(プロパティ/フィールド/変数ではなく)「メソッドの作成」が表示される。

  • 関連しているのは「セットアクセサの作成」で、読み取り専用プロパティに値をセットしようとしているコードでAlt+Enterを押すと表示される。実はこれは、赤いシンボルじゃなくて赤波線に基づいた動作だ。


これらも全部賢いんだけど、Change Allのように無気味なくらい賢いってわけじゃない。



















以下を入力して……「局所変数の作成」をすると
if (a)bool a;
ArrayList.Adapter(b)IList b;
c.PixelOffsetMode = PixelOffsetMode.Half;object c;

「局所変数の作成」が「Change All」と同じくらい賢いなら、上の3行目では単なるプレーンなobjectではなく、Graphics c;が生成されているだろう。(違いの理由はこんなところじゃないかと思う。Change Allでは既存のシンボルのどれが使用法に合致するかを知らなければならない。だから、見ないといけない変数とプロパティはたぶん2~3ダースだ。「局所変数の作成」の場合は出発点がフィルタリングされているという利点がないから、同じことをするには.Net Frameworkの何十万ものクラスをすべて見なければならないし、それはかなり遅い。でももしそうだったならとてもすごかっただろうに。追記: サポートが同意した。機能要請は追加されており、ReSharperの次のバージョンに入ると言ってた!)


型に関する賢さ


ReSharperがAlt+Enterメニューを作成しているとき、シンボルがどう使われているのかは見ていない。でも一度選択肢を選んだ後からは見る。


もしこんな風にシンボルを1箇所で使うだけならば、



ReSharper は、変数をそのものずばりの型で、この場合はBitmapとして宣言するだけだ。(でもカーソルは、一時的なコードテンプレートを伴って、新しく宣言された変数の所にくる。だから、別の型がよければそこに入力できる。)


でも、もしこんな風に基底型を期待する場所でもシンボルを使っているなら(DrawImageは第一引数にBitmapの親である型(Image)を期待する)、



それなら、「局所変数の作成」ではどの型を使いたいかという選択肢が表示され、デフォルトは基底型になる。



プロパティのための選択肢


プロパティを作成するとき、ReSharperは再び一時的なコードテンプレートを作る。最初は戻り値の型から始まり、受け入れるか変えるかすることができる。そしてTabを入力すると、ゲッター/セッターコードをどのように生成するかの選択肢が表示される。


Alt+Enterで「プロパティの作成」をした後のReSharper。裏づけフィールドかデフォルトボディテンプレートのどちらかを使う選択肢を表示。



  • 裏付けフィールドは、名前から連想されることをする。それは適切な型と(ReSharper Optionsで設定した命名規約設定に基づく)名前でフィールドを宣言し、ゲッターではフィールドを返し、(適用できるならば)セッターではフィールドにセットする。フィールドがすでに存在するなら二度と追加されない。

  • デフォルトボディテンプレートは、例外を投げるコードをゲッターとセッターに置く。


メソッドのための選択肢


メソッドを作成するためにAlt+Enterを使うと、一時的なコードテンプレートで戻り値の型、引数の型、引数名が指定できる。大して驚くようなことはない。


でもすごいのは、ReSharperの変数名提案が始まることだ。もし呼び出し元が変数かプロパティを渡しているなら、ReSharperは同じ変数名を引数名のデフォルトに使う。さらに、型名に基づいた通常の提案も行われる。


Tabキーを押して複数の名前が提案された引数に移動すると、補完用ドロップダウンボックスが表示される。もちろん、一覧にない名前を入力することもいつでもできる。


Alt+Enterで「メソッドの作成」をした後のReSharper。引数名の提案を表示。


接頭辞(例えば、"first")を入力してからCtrl+Spaceを押して残りの名前を提案させることだってできる。(残念なことに、これは呼び出し元の変数名で補完できず、型名に基づいて提案することしかできない。たとえば、上記のコードでfirstと入力してCtrl+Spaceを押すと、firstIntは提案されるが、firstCountはされない。)


制限:復帰


これらのコマンドのどれかを使うと、ReSharperは新しい宣言の中にカーソルを入れ、そして一時的なコードテンプレートを使って型やコードを変更できる。しかし、それが終わったときは、元いたところに戻る方法を分かっていないといけない。


ReSharperには「最後に編集した場所に移動」というコマンドがあって、Ctrl+Shift+Backspaceでアクセスできる。これで出発地点に戻ることができるようだ……少なくとも時々は。最初に押したときは何も動作しないだろうけど、ツイていれば2回目にはかつて赤かったシンボルに戻れるだろう。(でも、その後何か他のものをAlt+Enterで補完して、また戻ろうとすると、期待する動作はしないだろう。)


制限:命名規約を心得てない


これらの機能は、ReSharper Optionsにおける「命名規約」ページにちゃんと従うほど賢くはない。フィールドは_から始まるという半標準を指定すれば、すでに_ から始まっているシンボルには局所変数を作成する選択肢は出ないことが期待されるし、さらに、_のないシンボルには「フィールドの作成」オプションは表示されず、フィールドを作成するときに_を加えないことが期待される。ReSharperは、これらのどれもやらない。「フィールドの作成」と「局所変数の作成」はどちらも命名規約設定に全く気づいていない。(僕はこれを機能要求に入れておいた。)

2007年6月7日木曜日

USのTech Edにドクが!

凝ったKeyNoteだったようで。クリストファー・ロイド元気だなあ。



http://www.microsoft.com/events/teched2007/default.mspx


世間はフロリダで開催中のTechEdの話題でもちきりですねぇ(うそ


KeyNoteにはバックトゥザフューチャーのデロリアンとドクを招へいしたようですねw(ソース


motonの日記 - TechEd 2007 June 4-8, Orland

上記の「ソース」にはYouTubeの動画が貼ってあるし、公式サイトでも動画を見れる。

2007年6月4日月曜日

シンガポールその7

ナイトスポットであるクラークキーに行ってきた。古い倉庫跡地を再開発した商業施設だということなので、関東で言えば横浜赤レンガ倉庫といったところか。


シンガポール川の対岸にはリバーサイドポイントという施設がある。
ck1


晩飯は、この中の、Jumbo Seafoodで。この店名、漢字にするのはちょっとためらわれる;-)
ck2


ここでブラックペッパークラブとチリクラブを食べた。ものすごく手を汚しながら一心不乱に食べたので写真は無し。ものすごくおなかいっぱい。うまかったが、もうしばらくカニはいいや。


食べ過ぎたせいで、クラークキーに立ち並ぶお洒落なバーやクラブには入らずじまい。川のほとりを歩いて腹ごなしし、地下鉄で帰った。


ちなみに下の写真の左側、川沿いに見えるのはフーターズ。いや、だから行ってないって。マジで。
ck3

シンガポールその6

リトルインディアに行ってきた。
li1


名前の通り、インド人街な感じ。インド土産屋も多い。インド映画のサントラみたいなCDばかり置いている店もあったりして、なんとなくジャケ買いしたくなったがやめておいた。
li2


近くにはインド料理屋が多い。だが、近くのフードコートで昼飯を済ませてしまっていたため、食べなかった。残念。


駅の近くにはテッカマーケットという市場がある。


肉屋(宗教上羊肉が多い)とか
li3


八百屋とか果物屋とか。
li4


果物屋でマンゴーを1個買って(1SGD)、その場で食べた。うまい。


マーケットの横にはホーカーズという屋台村があって、市場に集まる人たちの腹を満たしている。フードコートよりも古くて猥雑でアジア的。だが、近くのフードコートで昼飯を済ませてしまっていたため、食べなかった。残念。
li5


市場にはこんな鳥がものすごく多くいて、残り物などを狙っていた。行動はカラス的だな。調べたところモリハッカという鳥らしい。
li6

シンガポールその5

腹痛は朝には治まった。よかった。


昼飯はリトルインディア近くのフードコート(またかよ)で、クレイポットチキンライス。


クレイポットチキンライス


いわゆる海南風チキンライスとは違い、釜飯みたいな感じ。結構日本人好みの味だと思った。

mixiの場合

連投した日の頭のほうの記事はマイミクシィからスルーされやすい。しかも外部blogの場合は一日1回ぐらいしか更新チェックしてくれないから尚更。


mixi経由でこのブログにアクセスして、その流れでこの記事にたどり着いた熱心な人(感謝)がいたらコメントよろしく。帰国したらシンガポール土産あげます。RSSリーダとかアンテナとかを経由した人は除く。

2007年6月3日日曜日

シンガポールその4

晩飯にはラッフルズのエンパイアカフェでラクサを食べた。うまかった。

でも、それがいけなかった。

アサリのような貝が入っていたのだが、一つ食べてみて「これ生じゃないか?」

とりあえず口から出した。で、食べないのはもったいないので貝だけ除けて食べたのだが、その後ズキューーーーン!

シンガポールスリング?呑んでる場合じゃないっつーの!

シンガポールその3

昼食はサンテックシティのフードコートで。
fc1


結構広くて、いろんな店が入っている。
fc2


カウンターはこんな感じ。
fc3


ホッケンミー(福建麺。えび入り五目焼きそば?)を選んで食べた。4SGD(約320円)。
fc4

シンガポールその2

世界三大がっかりとして悪名高いマーライオンを見に、マーライオン公園にやってきた。


おや、あれは……
マーライオン1


ちっちぇぇ。小さすぎだぞ。


いや、待てよ。後ろのほうに……
マーライオン2


おお。もう1体あるのか。
マーライオン3


こっちは凛々しいな。全長8メートルだとか。なんだ、噂に聞いていたほどがっかりじゃないぞ。しっかりしてる。
マーライオン4


とはいえ、ちょっと引いて見ると、やっぱり大したことないような感じだ。中途半端って言うか……
マーライオン5


セントーサ島には全長37メートルのマーライオンもいるそうだから、時間があれば行ってみるかな ;-)

シンガポールその1

サンテック・センターでPC Show 2007というのをやっている。


pc show 2007


すげえ混んでたので早々に退散。なんでも80万人以上集まる、東南アジア最大のコンピュータ・ショウらしい。