transit

changi airport, singapore.

there is no global ime installed and i don't have a permission to install it. but it's okay.

changi is interesting. free movie, free internet service, free xbox game, pool, fitness gym, and so on...

輝度

今メインモニタはDell 2005 FPWなんですが、使ってたら目が疲れてきて視力も落ちてきた気がしたので、輝度を下げました。

ディスプレイ自体の設定ではBrightnessは0にしてます。

個人的にはこのぐらいでちょうどいいです。まだ下げてもいいくらい。

スマブラXが欲しい

Wii「大乱闘スマッシュブラザーズX」の音楽スタッフが異常すぎる

ギャッ。オタク心をくすぐる……

Wii持ってる友人夫婦にプレゼントしようかな(そして自分がプレイしようかな)

Day 17: Alt+Enterで全部修正(あと赤い電球の紹介も)

元記事

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

数日間続けてAlt+Enterをネタにする。今日のネタはAlt+Enter > Change All の利用だ。

赤い電球

最初に言っておきたいのは、昨日の機能（Alt+Enterで名前空間をインポートする）は、たとえどこにカーソルがあっても動作する点が特殊だということだ。Alt+Enterがそういう動作をするのは名前空間だけなんだ。通常は位置との関係性が強くて、現在カーソルがあるコードに対してだけ作用する。これからネタにしていくAlt+Enterの機能は全部そうなっている。

ReSharperが修正方法を知っている問題(赤や灰色や波線)があったとき、カーソルを問題のコードに持ってくれば、ReSharperはその行の隣に赤い電球を表示する。

赤い電球は、何かを修正しなければならないことを示している。黄色の電球も存在する。こっちの場合、修正してもいいけど全ては自分の判断に任されている。こっちは後日の投稿でネタにしよう。

電球はクリックしてもいいし、Alt+Enterを押してもいい。どちらの方法でも、エラーを修復する方法の選択肢がドロップダウンメニューで表示される。

追記: このドロップダウンメニューのコマンドは「応急処置」と呼ばれている。(最初に投稿したときに言及しておけばよかったね。)

Change Allについて

赤いシンボルのための応急処置のうちの1つがChange Allだ。これは名前から連想される通りのことをする。全ての（赤い）シンボルを、別の（定義済みで赤くない）シンボルに変える。これが便利なのは、たとえば、あるメソッドからコードを切り取って別のメソッドにコピーするときに、変数またはパラメータ名が違っている場合だ。

Change Allには2つの部分がある。提案リストと同期編集だ。

提案リスト：読心術稼働中

Change Allを選ぶと提案リストが表示される。しばしば提案が1つしかなく、それがまさに希望のものだったりする。便利すぎて気味が悪い。

今この機能について書きながら、どう動くのか正確に理解しようとして限界を試しているんだが、改めて感心した。この機能は基本的にはCtrl+Shift+Spaceの裏返しだ。

何が起きているかと言うと、シンボルが赤く表示されている場所を全部見て、（同名の赤くないシンボルを持つメソッドは全部無視して、）各々の場所でどのように使われているかを知り、エラーのない利用法に沿ったシンボルを提案している。

だから、もしシンボルがif文の条件式なら、ReSharperはbool型の変数だけを提案する。もしシンボルの後に「.PixelOffsetMode =」とあるなら、ReSharperはGraphics型の変数だけを提案する。（別の型にPixelOffsetModeプロパティを定義していなければね。）

多くの場合、シンボルの使い方に合致した、ただ1つのパラメータまたはプロパティになる。だからReSharperが心を読んでいるかのように見える。(そう言っても過言ではない！)

注意点：Change Allの提案リストは、変数のようなもの（変数やパラメータやプロパティ）を対象とする。メソッド名や型名にもChange Allを使うことができるけど、Change Allのリストにはそれらの提案が出ない。

同期編集がVisual Studioにやって来た

これは素晴らしい感触だ。新しい名前を入力するダイアログボックスをポップアップする代わりに、Change Allではエディタ上の1箇所で直接新しい名前を入力できて、入力したとおりに他のところを変えることができる。

ReSharperのドキュメントにはこの「エディタウィンドウの指定場所でリネームする」機能に名前がない。でもこれはDelphi 2005の同期編集機能とほぼ同じもののようだから、そう呼ぶことにする。Visual Studioでこの機能が利用できてうれしい。

不在のお知らせ

知人以外どうでもいい話だが。

5/24～6/6まで旅行に行ってくる。6/2まではインターネットにもアクセスしない(できない)ので悪しからず。

Day 16: Alt+Enterで名前空間をインポート

元記事

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

今日から数日の間は、ReSharperでいちばんよく使うキーストロークの1つについて話そう。Alt+Enterだ。前に言及したときにはReSharperの「十徳ナイフ」と呼んだけど、それはとにかく万能だからだ。ある種のコンパイラエラーを修正できたり、コードを補完できたり、使われていないコードを削除できたり、総じて言えば、コーディング中に繰り返し現れる作業を自動でやってくれる。

今日のネタ: 名前空間のインポート。

基本

前にも言ったけど、ReSharperは認識できないシンボルを赤く表示する。でも、まだusingしてない別の名前空間の中に存在するシンボルであることが分かっていれば、ReSharperは別のものも表示する。エラーを修正させようとするヒントだ。

だから、もしソースファイルPixelOffsetModeとだけ入力したら(しかも、まだusing System.Drawing.Drawing2Dをやってなかったら)、ReSharperは名前空間を全部スキャンして、その名前のクラスを探し出し、目的のものはこれですかと聞いてくる。Alt+Enterを押して同意すれば、ソースファイルに using System.Drawing.Drawing が追加される。

この機能について知っておくべき追加情報を以下に記す。

• ソート。ReSharperは、予期した順序でusing文を追加する。その順序とは、修正版アルファベット順だ。最初にSystem名前空間以下の全部を(アルファベット順で)並べ、その後ろに残りの全部を(アルファベット順で)並べる。注意してほしいのは、この機能では、今言った順序に並んでいないときだけ並び替えをするんだけど、再度並び替えるときはCtrl+Alt+Fを押すだけでいい。


• 場所にあまり依存しない。Alt+Enterで実行できる他の機能については後から話すけど、普通は、カーソルが存在するコードに特有のものだ。でも、今回に限った使い方――名前空間のusing――では、その必要はない。たとえカーソルが赤いシンボルの上になくても動く。(赤いシンボルがファイル内に複数あるなら、Alt+Enterの対象になるのはいつもカーソル位置に近い方だ。)


• (あんまり)瞬間的ではない。コードの色分けと同じだけど、ヒントが表示されてAlt+Enterを押せるようになるまで、入力を止めて1～2秒待たないといけない時もあるだろう。ReSharperはコードを調べて、(a)型が認識されていないことと、(b)その型が別の名前空間に存在していることに気がつかないといけない。これが終わってからでないとAlt+Enterのヒントは出せないし、それまではAlt+Enterを押しても何も起こらないだろう。長くはかからないけど、時々は手を止めて待つ必要があるだろう。


• あいまいさの解消。もしシンボルが複数の名前空間で見つかったら、ReSharperはどっちにするか聞いてくる。ヒントには「(複数の選択肢)」と表示されるだろう。Alt+Enterを押したら、選択肢一覧の中から欲しいものを選ばないといけない。
  
  
  


• 参照に依存する。これは驚くような事じゃない。新しいアセンブリを作成して、クラスに[TextFixture]属性を追加すれば、ReSharperはそれを赤く表示するだろうけど、アセンブリを右クリックしてNUnit.Framework.dllへの「参照を追加」しないと、修正の手助けはやってくれない。

Ctrl+Alt+Spaceとの比較

昨日はCtrl+Alt+Spaceで型名が自動補完されusing文が追加されることを話した。

Alt+EnterはCtrl+Alt+Spaceが動かないところで動く。たとえば、オンラインのサンプルコードをコピペしている時に、必要なusing文が追加されていないような場合とか。でもコーディング一般ではCtrl+Alt+Spaceの機能の方が向いているとは思う。ただね、こっちを使うことをどうしても思い出せないんだな。「そうそう、今はメソッド名じゃなくて型名を入力しているんだから、Ctrl+Alt+Spaceを押すんだったな。」って考えられるようになるには時間がかかる。でももし使うことを思い出せたなら、何か入力してAlt+Enterを押すよりも適してるように思われる。

主な理由は、どっちの機能でも1～2秒待たなきゃいけない場合があるんだけど、待ちのタイミングはCtrl+Alt+Spaceの方がふさわしいからだ。

Alt+Enterだと、識別子を入力してスペースキーを押した時には、気持ちはもう次に入力する内容に移っている。でもコードが赤くなったことに気づいて、さっき書いた内容に注意を戻さないといけなくなる。「ありゃ、この文を入力し終わったらAlt+Enterで修正しないといけないな」という判断を意識の裏でするだけとは言っても、まあ気が散るよね。

一方Ctrl+Alt+Spaceでは、識別子の一部を入力したらキーストロークを押す。ここまでが識別子の入力の範囲だ。そしたら頭を行内の次のところに切り替える。だからすでに書いたコードの確認で流れがさえぎられるってことがない。

人によってメリットは違うだろう(し、僕のメリットだってそうだ)。べ、別にAlt+Enterがダメ機能だって言ってるわけじゃないんだからね！ただ、Ctrl+Alt+Spaceに適したところではそっちを使ってもいいんじゃないかって思っただけなんだから……

Visual StudioのAlt+Shift+F10との比較

Visual Studio 2005にも似たような名前空間をインポートする機能がある。VSが知っているシンボルを入力したときには、小さいスマートタグが表示される。マウスを乗せる(か、Alt+Shift+F10を押す)とドロップダウンメニューが表示され、そこからusingを追加することができる。ReSharperのAlt+Enterと比べるとどうかな？

• キーストローク。もしシンボルが1つの名前空間だけに存在するなら、ReSharperではAlt+Enterを押すだけでいい。Visual StudioだとAlt+Shift+F10を押した後にEnterも押さないといけないから操作しにくい。ReSharperの勝ち。


• ソート。Visual Studioだとusingブロックの最後尾に名前空間が追加されるし、すでにあるusing文の順番がでたらめでも放置される。ReSharperだと自動的に並べ替えられる。ReSharperの勝ち。


• 位置関係。Visual Studioでは、カーソルがシンボルの上にないとスマートタグは表示されない。ReSharperでは、赤いシンボルが画面内にあるなら常に「名前空間の追加」というAlt+Enterのヒントが表示されるので、名前空間をインポートするときにカーソルを動かす必要がない。ReSharperの勝ち。


• 応答時間。Visual Studioでは、型名の最後の文字を入力したらすぐにスマートタグがポップアップ表示される。ReSharperでは、シンボルが赤くハイライトされてヒントが表示されるまでに1～2秒かかることがある。かろうじてVisual Studioの勝ち。(3GHz/2GBの開発マシンよりも800MHz/256MBの個人用ノートPCの方が、もっと差が目立つけど)

Yakety Yak

Hackety Hackを見て思い出したのが、The Coastersの"Yakety Yak"という曲。映画"Stand By Me"のサントラに入っていたなあ。

散らかした紙くずを捨てなさい
じゃないとお小遣いあげない
台所の床も磨きなさい
じゃないともうロックンロールさせない
無駄口叩かない 口答えしない

部屋の掃除はちゃんとやりなさい
ほうきで余計にほこりが舞ってるじゃない
そのがらくたは全部片付けなさい
じゃないと金曜の晩に遊びに行かせない
無駄口叩かない 口答えしない

コートを着て帽子をかぶりなさい
そしたらコインランドリーに行ってきなさい
終わったらワンちゃんを部屋に入れなさい
入れ替わりに猫ちゃんは出しなさい
無駄口叩かない 口答えしない

そんなだらしない格好しない
お父さんを見習って格好よくなさい
不良のお友達は帰ってもらいなさい
車を運転する年にはまだ早い
無駄口叩かない 口答えしない

んー。50年前のアメリカでも、母ちゃんはやっぱりやかましい。

Day 15: Ctrl+Spaceの一族

元記事

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

昨日はReSharper版Ctrl+Spaceについて話した。今日はReSharperが追加する2つの仲間を取り上げる。Ctrl+Shift+SpaceとCtrl+Alt+Spaceだ。

(「パラメータ情報」は以前はCtrl+Shift+Spaceだったが今はCtrl+Pになっているのを忘れないように。)

Ctrl+Shift+Space：予想される型でフィルタリング

Visual Studioの標準のCtrl+Spaceは(ReSharperでもそうなんだけど)、現在インポートしている全名前空間に含まれるあらゆる型を表示する。ReSharperにはコンテキスト依存の選択肢もあり、それだと正しい型だけを――現在のカーソル位置から予想される全ての型を――表示する。コンテキスト依存版はCtrl+Shift+Spaceで起動する。

たとえば、

Stream stream = new FileStream(fileName, FileMode.Open);
StreamReader reader = new StreamReader(

と入力してCtrl+Shift+Spaceを押せば、かなり短い補完候補一覧が得られる。というのは、StreamReaderのコンストラクタの第1引数となりえるものだけを表示するからだ。streamは候補の1つだし、Stream.Nullもそうだ。それに、文字列を返す静的メソッドの山もそうだ。StreamReaderのコンストラクタには文字列を受け取るオーバーロードもあるからだ。

この機能はコンストラクタではまだ動作しない。

Stream stream = new

と入力してCtrl+Shift+Spaceを押したときは、このコンテキストで使用できる具象クラスが全部表示されることを期待するだろう。ところが表示はされない。「候補なし」となるだけだ。サポートいわく、新しいシナリオはまだサポートされていないけれど、すでに将来のリリース計画にはあるとのこと。

でもなー。こういう時ばっかりはDelphiで作業するほうがいいと思うわけだよ。（もちろん、Delphi IDEが「バックグラウンドで」コンパイルしようとして(そして何度もやり直して)いる間、マウスを動かそうとしても30秒ずつ固まったりしないならと仮定しての話だけどね――ありえない希望だとは思うけど、人は夢を見る生き物だし。）どうしてかと言うと、今でもDelphiのCtrl+Spaceの方がすごいからなんだ。こっちもコンテキスト依存だけど、正しい型を持つ式を表示するってだけではない。正しい型を得ることができる式をも表示するんだ。たとえば、Integer型が予想されるコンテキストなら、Delphiは一覧にTFormのインスタンスを表示する。なぜならInteger型のプロパティ(Width、Height、Constraints.MinWidthなど)を持つからだ。この機能にはあっという間に慣れるよ。だから僕は、制限がずっと多いReSharperのコンテキスト補完に慣れるのに苦労している。とはいえ、たぶんそのせいで、Delphiが候補一覧を作るのは泣くほど遅い。

追記: 空のメソッドを新しく作って、その中でCtrl+Shift+Spaceを押すと、補完できる型がないはずなのに自動補完ボックスがポップアップする。ReSharper開発者のIlyaが言うには、

空のメソッド内か、文が予想されるならどんな場所でも――たとえば、ある2つの文の間とかで――Ctrl+Shift+Spaceを押すと、「void」型が予想されるから、戻り値のないメソッドだけが表示される。

Ilyaありがとう！

Ctrl+Alt+Space: どこかの名前空間に属する型全部

方向性が違うんだけど、Ctrl+Alt+Spaceは型名だけを表示する――プロパティも、メソッドも、定数も表示せず、ただ型だけ。でもCtrl+Spaceとは違い、全ての名前空間から探してくる。しかも、その時点でusing文がある名前空間に限らない。

（Ctrl+Alt+Spaceのドキュメントには、現在のソリューションの中にある型名を補完するとある。でもそれは正しくなくて、参照しているアセンブリからも型が補完される。だから、マイクロソフトやサードパーティが作ったアセンブリから来る、FileStreamやTestFixtureAttributeのような型でも動作する。）

ここまで聞いただけだと、まあ少し面白いけどねーって感じだと思う。いやいや、ここからが面白いんだ。型を選択したとき、まだusing文がなかったなら、ReSharperは適切なusing文を自動的に追加する。

（ReSharperには、必要なusing文を追加する別の機能もある――実は、明日その話をしようと思っているんだけどね。それでも、ちょくちょくCtrl+Alt+Spaceを使うくせをつけたほうがいいと思う。こっちの方が速くて簡単であると断言しよう。)

Ctrl+Alt+Spaceは、押す前に型名の最初の数文字を入力しておかないといけない。これはわざとなのかサポートに連絡して聞いたところ、ええ、その通りですと言われた。全部のアセンブリから候補一覧を拾ってくるから、何か入力してフィルターをかけないと時間がかかりすぎるだろうとのこと。納得いく理由ではある（その理由をドキュメントに記載していたなら素晴らしかっただろうけれど）。

Day 14: たとえばこんな変数名

元記事

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

ReSharperは、Ctrl+Spaceを独自のバージョンに入れ替える。ほとんどはVisual StudioのCtrl+Spaceと同じ動きをするが、ReSharper番には追加機能が1つある。変数名を提案できるんだ。

変数宣言を入力してCtrl+Spaceを押すと……

ReSharperは型名に基づいた名前の候補を自動補完ドロップダウンで表示する。ドロップダウンリストの振舞いは他の自動補完ドロップダウンと同じだから、項目にカーソルを合わせてEnterを押すことも、そのまま入力することもできる。そうすれば現在の選択肢で名前を決定し、セミコロンを入力してくれる。

賢いことに、インターフェース名の先頭にあるIは無視してくれる。しかも、型名が1単語だけなら邪魔なドロップダウンを出さない。だから、もしISprite (空白)と入力してCtrl+Spaceを押せば、黙ってspriteと入力してくれる。

もちろん、この機能はローカル変数だけのためにあるのではない。パラメータとフィールドでも動作する。独自の命名規則を教えることだってできる。例えば、全てのフィールド名は_で始めないといけないとか。ReSharperオプションの「命名規則」のページを見てくれ。

Ctrl+Spaceを押す前に、接頭語を入力することもできる。

残念なことに、ReSharper 2.5.1だとバグがある。提案では、もともとキャメルケースで入力していた接頭語が、全て小文字に変えられていることに注意。(このバグ用のチケットが作製されている。)

変数名の提案は、変数宣言の際のCtrl+Spaceに限らない。ReSharperの他のところでも出てくる。たとえば、引数を定義しているとき、名前を入力するか提案から1つ選ぶかすることができるコンボボックスが出てくるとか、変数をリネームしているとき、名前の提案がポップアップするとか、メソッドを抽出しているとき、パラメータ名でも提案が作動するなど。

Day 13: ファイル構造ビュー

元記事

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

Delphiのいくつかのバージョンには「構造」ビューがあり、フィールドとメソッドとプロパティをツリー表示する。ReSharperは「ファイル構造」ビューで更に数歩進んでいる。Ctrl+F11でアクセスできるが、素晴らしいショートカットってわけではない。多分、一旦ウインドウを表示したら、後はそれをドッキングさせたままにするだけだろう。

メソッドのソート

名目上は、コードの構造を一目で見るためにこれを使える。でも実のところ僕はそのためには使っていない。僕の指は「すべて折りたたむ」のショートカットを覚えこんでいる(Ctrl+M、Ctrl+Oだと思うけど、気にとめた事ないからな……どれどれ……ああ合ってた）。

僕が「ファイル構造」ビューを使うのは並べ替えのためだ。全メソッドがアルファベット順になっていれば、僕らの人生はさらに楽ちんだろう。しかしReSharperにはその選択肢がないので、抽出したメソッドは常に間違った場所に置かれる。でも、「ファイル構造」ウインドウではドラッグ＆ドロップができて……

メソッドを新しい場所にドロップすれば、ReSharperはコードエディタでメソッドを移動する。

空行についてはたまにおかしな動きをする。でも、ものごとを正しい順序に保つ選択肢がReSharperに追加されるまでは（世の中には無数の異なるコーディングスタイルがあることを思えば、それは難しい注文なのだが）、ツリーのノードをドラッグ＆ドロップした後に「すべて折りたたむ」をし、空行の一部を取り除く、というのはカット＆ペーストよりはるかに速い。

リージョンが好きなら……

リージョンを実際に使っているし気に入ってるという人たちのために、ReSharperの「ファイル構造」ビューのリージョンは見栄えがするし、折りたためる。

リージョンが嫌いなら……

個人的には、コードにリージョンがあると読みにくくなると思う――それに、もしコードが複雑すぎるからリージョンによる組織化が必要だっていうのなら、それはクラスから匂いがするってことだよ。

もしこの陣営にいるのなら、ReSharperが力になれる。リージョンボックスの右上に、小さくて青い「X」が見えるかな？それを1回クリックすれば、リージョンタグを消せる(#regionと#endregionのコード行が削除されるだけで、リージョンの中身は削除されない)。そしたらすでに「ファイル構造」ウインドウの中にいるわけだから、メソッドをドラッグして並び替えする作業に取り掛かれる。

もちろん、意図しないときにうっかりリージョンタグを消してしまったとしても、それは他と同じくコードの変更だから、元に戻すことができる。

ガシャポン「サウンドロップ ナムコクラシックス」

商品説明ページへジャンプ

こんなものが豊洲駅構内においてあったので、酔った勢いで1つ購入。

「マッピー」ゲットだぜ。敵に捕まったときの効果音がサンプリングされているようで、ボタンを押すとそれが鳴る。ストトン表記だと「ソー^レ_シーソ^レー_シソーファミ♭ーーーーーレーーーーー」ってとこか。

最初は面白くて何回も鳴らしていたんだが、この商品の致命的な欠陥に気づいたのは電車に乗った後だった。

何かの拍子にすぐ鳴りやがるので大変うっとうしい。

それというのも、ボタンが大きい上に遊びがほとんどないためだ。しかも電源スイッチもないので、もうどうしようもない。とりあえず持って帰ったけど、これどうしようかな……

ちなみに音がなる様子は以下。

Day 12: 型階層ビュー

元記事

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

今日ネタにする機能は、あまりに長いこと欲しい欲しいと願っていたせいか、もうすでに存在しているってことをどうにも覚えられない。「型階層」ビューだ。Ctrl+Alt+Hでアクセスできる。

カーソルが型名の上にあるときにCtrl+Alt+Hを押すと、型階層ウインドウがポップアップし、その型の先祖型と直接の子孫型が表示される。(ReSharperの他のウインドウと同じくドッキング可能だ。)ツリーを展開すれば、さらに下の子孫型も表示できる。もしも型階層が複雑で、いつもインタフェース経由で操作しているのであれば、インターフェースにカーソルを置いてCtrl+Alt+Hを押せばツリー全体を表示できる。

ノードを右クリックすると「ここを基点にする」を選択できる。そうすると、その型の上でCtrl+Alt+Hを押したのと同じ状態にツリーが再構成される。あるクラスの親クラス上でこれをすれば、より多くのクラスがツリー上に表示される。(先祖型については元クラスの直系の先祖しか見れないからね。でも先祖型のうちの1つを基点にするなら、他の子孫も全部ツリー上に表示できる。)現在の基点クラスは太字で表示される。

「ここを基点にする」は、どの型を展開してどれを折りたたんだかを記憶して、その状態を保つ。これはマジですごいと思った。

型階層ウインドウには他のビューもいくつかあって、ツールバーの右側にある、小さいオブジェクトグラフのようなボタンで切り替えられる。メインビューの他に、子孫だけを表示するビューがある。これはあんまり面白くない。インデントが少ないメインビューと変わらない。

第3のビューでは先祖型だけが表示される。先祖型ビューが面白いのは、ツリーを逆にする(親が下位ノードとして表示される)ところだ。だから、親クラスだけじゃなく、クラスが実装しているインターフェースも全部表示できる。

右クリックコンテキストメニューには、「ここを基点にする」の他に、「使用箇所を検索」と「リファクタ」サブメニューがある。だから、型階層を見ているときに、その中にあるクラスの名前を突然変えたくなったって、実際に変更できる。(賢いことに、ソースコードを持っていないクラスを「リネーム」するといった操作はグレーアウトされる。)

最後になるが、ツリー上の型をダブルクリックすれば、その型のコードにジャンプできる。(ソースコードを持っていない型だと、Visual Studioの新しい「メタデータから」コードビューではなく、おんぼろクラスブラウザが使われるけれども。)

Day 11: コードナビゲーション

元記事

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

今日のネタはコード内のナビゲーションだ。ReSharperの3つの機能を扱う。「Navigate From Here」コンテキストメニュー、ガター(左余白)アイコン、「宣言に移動」だ。

「Navigate From Here」コンテキストメニュー

ReSharperのすごい所に、コンテキストメニューが1つ以上あるってことがある。対象を絞ったコンテキストメニューは2、3のキーストロークで表示されるから、「今ここで少しでもやりたいかもしれないこと全部」ではなく「コードナビゲーション関係でやりたそうなこと全部」とか、「リファクタリング関係でやりたそうなこと全部」といったものを表示できる。(もちろん、すべてを含むコンテキストメニューを利用することもできる。)

対象を絞ったコンテキストメニューとは、脳能力とコーディング速度との大きな歩み寄りなんだ。使い始めるのは簡単だ。だって全種類の機能を表示するなら1つのキーストロークだけ覚えておけばいいから。でもコンテキストメニューの個々の項目は実際は別種のコマンドなんだし、それらの多くには独自のショートカットキーもある(そいつらはメインのコンテキストメニューには表示されず、対象を絞ったコンテキストメニューだけで表示される)。だから、普段使う機能についての専用のショートカットキーを徐々に覚えていくことも、それによって機能を速く呼び出すこともできる。

下記は「Navigate from Here」コンテキストメニューの例だ。Ctrl+Shift+Gで呼び出せる。

コンテキストメニューなんで、現在のカーソル位置から見て意味のあるコマンドだけが表示される。もしクラス名の上にカーソルがあるなら、メソッド名や名前空間名の上にあるときとは別の選択肢が表示される。

すべての選択肢を使ったことがあるわけではないけど、今気に入っているのは「継承先」だ。もし、とあるインタフェースのメソッドを呼び出すコードの上だったなら、そのインタフェースメソッドを実装しているクラスの一覧が表示される。

さらにすごいのは、もしインタフェースの実装が仮想(virtual)メソッドだったなら、そのメソッドをオーバーライドしている派生クラスまで一覧に表示される。最上位のオーバーライド(インタフェースを実装しているクラス)は太字で表示される。それより下位のオーバーライド(メソッドをさらにオーバーライドしている派生クラス)は普通の文字だ。

ガター(左余白)アイコン

この機能は、僕はそんなに頻繁には使わない。上にたどるだけだし、それってそもそも簡単だ(同じことは「Navigate From Here」でもできる)から。まあでも書く価値はある。

ReSharperでは、基底クラス(または実装しているインターフェース)に関連するメソッド宣言の隣にガターアイコンが表示される。だからFooメソッドが基底クラスのメソッドをオーバーライドしているなら、あるアイコンが表示される。もし基底クラスのメソッドをシャドウしているなら別のアイコンが表示されるし、インターフェースメソッドを実装しているなら、さらに別のアイコンが表示される。

ReSharperのガターアイコン。上から順に、インタフェースの実装、オーバーライド、メソッドのシャドウ。

(考えてみると、これらのアイコンを眺めるところから始めないといけない。緑の「I」は、あるクラスにおいてどのメソッドがインタフェースから来ているものかを表すいい指標だ――でも一目瞭然とはいかないな。)

ガターアイコンをクリックすれば、関係する継承元メソッドにジャンプする。よさそうに思えるが、僕はめったに使わない。別に何もしなくても、普段は基底クラスしか使わないからね！(テンプレートメソッドはコードの重複を除く良い方法だけど、コードを追うのが面倒だったりする)

宣言へ移動

これは、ReSharperをインストールすると変更されるキーストロークのうちの1つだ。F12だったのがCtrl+Bになっている。識別子をCtrl+クリックするのでもいい。

キーストロークは別として、動作はVisual Studio版(コードの興味がある部分にジャンプ)とほぼ同じだが、1点だけ違う。その違いとは、(Microsoftのアセンブリみたいな)ソースコードのない識別子の上にいるときの動作だ。VSもReSharperもコード定義の説明を表示しようとするんだけど……

<怒>

ReSharperは古い「クラスブラウザ」を表示しやがる。ボロいから使うのは本当に苦痛だ。

実は、Ctrl＋クリック以外のどのコードナビゲーション機能を使ってもこうなる。たとえば、ガターアイコンをクリックしても「クラスブラウザ」に行き着く。

一方Visual Studio 2005はクラスのメタデータをコードとして表示する新しい機能(「メタデータから」という機能)を持っていて、「オブジェクトブラウザ」は原則これで置き換えられているんだが、ReSharperに関係したところだけは例外だ。

Visual Studioのコードビューのほうがずっといい。理由は2つ。

1. ナビゲーションに関して「クラスブラウザ」はダメダメ。たとえば、Graphics.DrawImageを見ているとする(上の「クラスブラウザ」のスクリーンショットを見てほしい)。そうすればそのメソッドが引数としてImage型をとるのはわかる。ではImageクラスにどんなメソッドがあるか知りたくなってジャンプするときはどうだ？コードビューだったらCtrl+クリックで移動できるだろう。でもReSharperでは「クラスブラウザ」しか使えない。重要な情報は別のペインにある。まず右上のペインにある右側のオーバーロードをクリックし、右下角のXMLドキュメントコメントにある引数の型を見つけ、そしてそこのハイパーリンクをクリックしないといけないんだ。(長いこと、「クラスブラウザ」で引数の型にジャンプする方法があることに気づいてなかった。この記事を書いていて始めて見つけたんだ。)


2. コードビューはコードっぽく見える。これなら見慣れているし、使い慣れている。どうやって動き回ればいいのかも完全に分かっている。コードなら毎日作業している。一体なんでReSharperみたいな生産性向上の道具で僕の生産性が下がんないといけないんだってことだ。全く同じことをするのに別のGUIを覚えないといけないし、しかももっといい代替物があるっていうのにだよ？

ReSharperでも新しいコードビューを使えるようになってほしいので、そういうい機能要求を送っておいた。返事は、コンテキストメニューからならVSの「定義に移動」にアクセスできるんだから、現状のままにしておくとのことだった。がっかりだよ！おんぼろオブジェクトブラウザが出てくるのは「宣言に移動」だけじゃないんだ――ReSharperのコードナビゲーション関係全部がそうなんだから。

(もし君たちもReSharperを使っていてこの件に不満だったら、サポートに知らせてやってくれ。)

</怒>

昭和の雰囲気を出した居酒屋「赤羽 トロ函」

魚介を炭火であぶって喰う店。
わりと最近オープンした店だが、わざと昭和の雰囲気を出してある。店内のテレビはチャンネルを手で回すタイプだし。
山ほど魚を食べて軽く呑んで、ひとり3000円強だった。
次に来たときは蟹味噌の甲羅焼きと鮪の潮汁をいただこうかな。

赤羽 トロ函

Day 10: 型に移動

元記事

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

今日の話題はCtrl+N、「型に移動」だ。

Ctrl+Nを押すと、小さいウインドウがポップアップする。型名の一部または全体を入力すると、候補一覧が表示される。それから1つを選んでEnterを押せば、そのファイルが開かれる。

ソリューションエクスプローラが必要になるのは、もはや新しいファイルを追加するときだけだ。それ以外では、Ctrl+Nですべて事足りる。

しかも、ショートカット機能もある。

• 先頭の大文字で探す。大文字を入力すれば、頭字語として入力されたかのように検索する。つまり、もしMDTと入力したならMyDataTableとMenuDropTagにマッチする。(これは普通の検索と混ぜてマッチさせることができる。だから、MDatTを探してMyDataTableを見つけるということもできる。)


• ワイルドカード。* と入力すれば0以上の文字にマッチするし、+ では1以上の文字にマッチする。(これはファイルグロブ式のワイルドカードだ。つまり、「0文字以上のすべての文字」の意味だ。)

Ctrl+Nは、VSFileFinderとかなり直接競合する。両者ともほぼ同じように「あるパターンにマッチするファイルの一覧を表示して、そのどれかを開く」的なことをする。だから両者を比較してみると面白いんじゃないかと思った。以下に比較内容を記す。

• 明らかにReSharperの方が良い点：
  
  
  • VSFileFinderは、ReSharperでいう「先頭の大文字」的なものをサポートしない。
  
  
  • Ctrl+Nにはキーバインドがあるが、VSFileFinderのキーストロークは見つけられないままだ。Visual Studioを終了して再起動するとまた表示されるんだけど。
  
  
  • Ctrl+Nは使い終わればすぐ消えるけど、VSFileFinderはドッキング可能ウィンドウになっていて、検索が終わっても場所をを取り続ける。
  
  
  
  
• VSFileFinderの方が少し良い点：
  
  
  • どっちのツールでも検索したいもののフルネームを知っている必要はない。どちらも名前の一部分を指定できる。しかしVSFileFinderでは、一部分を指定するときに順序を問わない。「data table」はDataTableとTableOfDataにマッチする。ReSharperの方が制限が多い。一部分を指定するときには、型名に現れる順序のとおりでなくてはならない。(しかも、それぞれの語間に*を入力しないといけない。VSFileFinderではスペースを入力するだけでいいのに。)
  
  
  • 部分文字列で捜す場合はVSFileFinderの方がずっと簡単だ。名前のどこかに「Foo」を含む型を全部見つけたい時は、ReSharperでは「*Foo」と入力しないといけない。でもVSFileFinderでは「Foo」と入力するだけでいい。
  
  
  
  
• 明らかにVSFileFinderの方が良い点：
  
  
  • VSFileFinderでは、一度に複数のファイルを開くことが簡単だ。 (まあそれは、ウインドウが常に表示されていて場所をとっているからこそだが。) これは、テストの際には本当にいい――「Foo」と入力すれば「Foo」と「FooTests」の両方が一覧に表示されるし、両方ともクリックして両方とも開くことができる。ReSharperにはこのオプションはない。
  
  
  
  

最後の項目がいい例だが、ReSharperとVSFileFinderとでは狙いがちょっと違い、適材適所だということがわかる。(僕らは全部の開発用PCに両方ともインストールした。)だけど両者を使ってみると、僕の場合は大体ReSharperのCtrl+Nを使う方に落ち着く。だからキーバインドの有無にはかなり説得力を感じる。

もしも、何かの理由で各ファイル1クラスにしていないなら、Ctrl+Shift+Nにも興味があるかもしれない。これだと(Ctrl+Nのように型名で探す代わりに)ファイル名で探す。

Day 9: パラメータ情報

元記事

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

昨日はとあるVisual Studioの機能(すべての参照の検索)をReSharperが置き換え、強化し、キーストロークを変更したってことを話した。今日はもうひとつそんな話をしよう。パラメータ情報だ。以前はCtrl+Shift+Spaceだった。

ReSharperのパラメータ情報（Ctrl+Pでアクセスできる）は、全てのオーバーロードを一度に表示する。Visual Studioみたいに1つだけではない。

Visual Studioのパラメータ情報


ReSharperのパラメータ情報(クリックで拡大)

呼び出したいメソッドがオーバーロードを持ってなければ、ReSharperのパラメータ情報はVisual Studioのものとかなり似ている。でも、オーバーロードされたメソッドを呼ぶのなら（たとえば、マイクロソフトが提供しているアセンブリに含まれる何かを使うなら）、新しいパラメータ情報にははっきりとしたメリットがいくつかある。

• どこに向かえばいいのかわかる。.NETでカスタムペイントコードを書こうとするなら、死のオーバーロードに直面する羽目になる。マジで、どぉなっちゃってんだよSystem.Drawing。オーバーロードを30種類持ってるメソッドだってある。ImageAttributesを引数にとるオーバーロードが必要だとわかっているような時は(そしてそれは結局、全オーバーロード一覧の一番下にあるんだな)、たくさんのオーバーロードを一度に見ることができると助かる。


• カーソルキーが使える！ Visual Studioのパラメータ情報ツールチップが表示されているときは上下カーソルキーを使うことができない―― VSはキー入力を横取りして、「次の/前のオーバーロードについてのパラメータ情報を表示」する。おかげで僕は、次の行へ移動したい時に「End」と「右矢印」を順番に押す癖をつけないといけなかった (「Esc」と「下矢印」でもいいけど、こっちだと距離が遠いんだよね……)。しかしReSharperでは、オーバーロードの選択をぐるぐると切り替える時には、上下キーではなくCtrl+PとCtrl+Shift+Pを使う。だから、カーソルキーは実際にコードの中の移動に使える。ああよかった！


• 適用できないものをスキップする。Ctrl+PやCtrl+Shift+Pでオーバーロードの選択をぐるぐる切り替えると、入力してある引数に一致するオーバーロードだけを移動する。たとえば上のコードでは、僕はGraphics.DrawImageを呼ぼうとしているけれど、引数にImageとintを渡している。ここでもう一度Ctrl+Pを押せば、一覧における次のオーバーロードは第2引数としてRectangleをとるから、これは飛ばされる――引数にRectangleを渡していないから、望みのものでないのは明らかだ。その代わり、一覧を2つ下がって、次のfloatを引数にとるオーバーロードに移動する。

公式Webサイトによれば、ReSharperのパラメータ情報では、適用できないオーバーロードが灰色で表示されるはずだ。残念だがReSharper 2.5.1ではこの機能は動かない。(このことはサポートに伝えた。そしたら、動くはずですがと言われた。今は調査中らしい。）

Day 8: 使用箇所の検索

元記事

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

サバイバルガイドで書いたように、ReSharperはVisual Studioの「すべての参照の検索」(Shift+F12)を独自の「使用箇所の検索」(一貫性なくAlt+F7に変えられた)に差し替える。ReSharper版とVisual Studio版がどう違うのか、詳しい情報を記す。

「get」や「set」の使用箇所をフィルタリングする

そこかしこで読み取られるけどごく一部でしか書き込まれないようなプロパティってあるよね。そしたら「すべての参照の検索」でプロパティのセッターだけ探したくならなかった？こうすればいい。

フィールドでも同じことができる。あるフィールドが読み取られているところだけ、または書き込まれているところだけを探すことができる(Reflectorにもこの機能があればいいのになあ)。

スクリーンショットを見ればわかるが、「検索結果」ウインドウのフィルタメニューには、「読み取りを表示」と「書き込みを表示」と「呼び出しを表示」と「その他を表示」(どういう意味か分からない)、そして「ドキュメント中の使用箇所を表示」(XMLドキュメントのコメントのことだろうか)という選択肢がある。「その他を表示」はメソッドを参照するデリゲートのことかとも思ったが、明らかにそれらには「読み取りを表示」が使われている。

今後のバージョンでは、プロパティ宣言中の「get」や「set」を右クリックして「使用箇所の検索」を選択すれば、状況に応じて読み取りや書き込みだけが表示されるようになるとのことだ。これは待ち遠しい。

検索結果を前後移動する

「使用箇所の検索」を実行した後でCtrl+Alt+UpとCtrl+Alt+Downを使えば、検索結果を前後移動できる。カーソルが次の検索結果のところに移動し、場合によっては別のファイルが開かれる。端まで移動した後はループしない。最後まで来たことが分かるからある意味便利だ。

「検索結果」ツリー

嫌なところはといえば、「検索結果」ウインドウ内での検索結果の見せ方がどうにも好きになれない。

Visual Studioでは、全部が一覧表示されるだけだった。

全ての項目にはファイル名と行番号(とカラム番号。気にするかっつーの。)が表示されるから、少なくとも、それぞれの参照がどのクラスにあるのかは分かる。いっぽうReSharperでは、すべてはツリー表示される。

いつも最初はツリーが折りたたまれている。だから検索結果を見るだけじゃすまなくて、最低1回は(すべてを開くために)クリックしないといけない。しかも、ツリー表示をやめて結果をそのまま表示するために、「グループで分類」の設定を「なし」に変えたとする。そしたら検索結果がどのファイルに含まれているのか知ることができなくなる。各行は一致したコード行を表示するだけで、ファイル名や行番号といった情報が表示されなくなってしまう。

(僕はデフォルトで検索結果を展開表示できるように機能改善する要求を出した。回答には、まったく同じことをたくさんの人が要求しているとあった。だからどこかのタイミングで機能改善されるかもしれない。)

とはいえ、ツリーを展開さえすれば、結果がどのクラスに含まれるかだけじゃなくて、どのメソッドにあるのかといった、VSの一覧表示では表示されない情報を見ることができる。

Day 7: コードフォーマット

元記事

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

ReSharperは、コードフォーマットについて多くの支援をする。支援方法は大きく3つのカテゴリーに分類される。入力時、ファイル単位での必要時、複数ファイルでの必要時だ。

入力時のフォーマット

こんなの目新しくないよね。Visual Studioだってこの機能はしばらく前から持ってた。でも、ReSharperのフォーマット設定はもちろんバージョン管理できるし共有もできる。だから、型変換の直後にスペースを置くマシンと置かないマシンが混在したりしない。ここだけは勝っている。

ReSharperの他のフォーマット機能で素晴らしい所は、空のカーリーブレースの中でEnterを取り扱う方法だ。Visual Studioでの取り扱いより少しよくて、自動終了デリミタにきちんと関連づいている。

空文で始める。
開始ブレースを入力して...
Enterを押す。

ファイル全体をフォーマットする: Ctrl+Alt+F

ReSharperには、作業中のソースファイル全体を再フォーマットするコマンドもある。Ctrl+Alt+Fを押せば、「コードを再フォーマットする」ダイアログボックスが出る。

注目してほしいのは、この機能は空白文字をいじるより多くのことができるってことだ。コード中の灰色部分を修正させることもできる。「using文を最適化する」とか「冗長な'this.'修飾子を削除する」なんてのは見たまんまだ。「参照を短くする」では、System.Drawing.Graphicsが単にGraphicsに変更され(、usingが足りなければ追加され)る。

僕らはいつも、このチェックボックスの全部にチェックを入れている。コードはできるだけきれいであってほしいからね。ここでの設定は次回にも引き継がれる。

追記: Maruis曰く、Ctrl+Alt+Shift+Fならサイレントモードになり、ダイアログはポップアップしない。しかもちゃんと前回選択した設定を使ってくれる。すばらしい！ありがとうMaruis！

コードを再フォーマットする時に、ReSharperは以下のこともする。

• 明示的な可視性修飾子を追加する。可視性修飾子のないクラスにはinternalが追加される。可視性修飾子のないフィールドにはprivateが追加される。(これは、ReSharperの他のすべてと同じように、変更可能だ。だから、コードを読みやすくしたくない理由があるのなら、この設定をオフにしたっていい。)


• 単純なゲッターとデリゲートを一行に置く。もし、ゲッター/セッター/デリゲートの本体が1文なら(例えば、値の付与だけとか、return文だけとか)、ReSharperは閉じカッコもまとめて1文にする。だからReSharperは下のようなひどいフォーマットのコードを見つけて……
  

  public Color BorderColor {
      get
      {
          return _borderColor;
      }
      set { _borderColor = value; Invalidate(); }
  }
  

  
  こんな具合に再フォーマットする。
  

  public Color BorderColor
  {
      get { return _borderColor; }
      set
      {
          _borderColor = value;
          Invalidate();
      }
  }
  

  
  Visual Studio 2005は、ゲッターやセッターが1行なら「折りたたみ」用の＋記号を出さないでいてくれるので、この機能は本当にありがたい。

プロジェクトまたはソリューションを再フォーマットする

最後になるけど、ReSharperにはたくさんのファイルをまとめて再フォーマットするオプションがある。フォルダかプロジェクトかソリューションを右クリックして、「コードを再フォーマットする」を選択するだけだ。

言うまでもないことかもしれないが、一応注意しておこう。コードを変更していたのなら、まとめて再フォーマットする前にソース管理リポジトリにコミットするべきだ。ソリューション全体の再フォーマットをするなら、また別途コミットするほうがいい。この機能で変更する場合、やってほしくない変更をしてしまう時だってある。設定を変更するにしろ、予想外の結果を受け入れるにしろ、その前に一部だけ前の状態に戻したいと思うこともあるだろうからね。

あんまりうまくいかないところ #1：デリゲートのインデント

デフォルトでは、ReSharperはインラインのデリゲートをおかしなところにインデントする。これはReSharperのデフォルトが間違ってると思うことの1つだ。コードは普通にインデントしてほしい。コードの半分がこんな風にでこぼこの中央揃えになるのは嫌だ。

Block incrementer = delegate {
                        ++i;
                        ++j;
                    };
Block resetter = delegate {
                     i = 0;
                     j = 0;
                 };

これを直す方法をやっと見つけた。匿名メソッドのフォーマット設定はReSharperオプションの2つのページに分けられている。「Braces Layout」と「Other」だ。「おかしなインデントはやめろ」は「Other」のページにある「匿名メソッドの本体をインデントする」だ。これをオフにして、カッコの設定を「行の最後に置く」にすれば、ずっとましになる。

Block incrementer = delegate {
    ++i;
    ++j;
};
Block resetter = delegate {
    i = 0;
    j = 0;
}

あんまりうまくいかないところ #2：Xceedのライセンス

ReSharperは修飾子をできる限り短くしようとする。変な状況にはまってしまうと可読性が悪くなることもある。以下がそんな例だ。僕らの回避策(けっこううまくいったと思う)も載せておく。

僕らはXceed社のコンポーネントを使っている。Xceedで何よりイライラするのはライセンスの許諾方法だ。配布されるライセンスキーはアホほど長い英数字で、実行するためには、初期化コードでこの文字列を静的プロパティに突っ込まないといけない。こんな感じだ。

Xceed.Grid.Licenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
Xceed.Editors.Licenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

そう。Xceedのアセンブリごとにライセンスキーをセットしないといけないんだ。そうしないと、実行時に文句を言われることがある(言われないこともあるから意味が分からん。でもとにかくライセンスキーはセットするようにしている。念のためにね)。

変なのは、複数のアセンブリに含まれているLisenceKeyというクラスについてだ。ReSharperはこんな感じで短くしようとする。

using Xceed;
using Xceed.Grid;
...
Licenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
Editors.Licenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

ぎゃぼー。回避策はこんな感じ。こう書けばReSharperはそのままにしておいてくれる。

using GridLicenser = Xceed.Grid.Licenser;
using EditorLicenser = Xceed.Editors.Licenser;
...
GridLicenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
EditorLicenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

ツールの制限を避けるためではあるけど、こっちの方が読みやすいんじゃないかな。

Day 6: 共有設定は.resharperファイルの中に

元記事

「31日間ReSharper一周」の6日目へようこそ。

時々、IDEがマシンごとに違う設定になってることがある。僕らは全員、ブルペン内の全マシンを使うから、時間がたてば相違点は解消されていくんだけど、ムカつくときだってあるわけ。特にコードの自動フォーマット設定は最悪だ。デザイナ画面で何かをちょっと動かすとかいった、一見無関係な変更をしたときでさえファイルが自動的に再フォーマットされてしまう。

頼みの綱はReSharper。いくつかの設定は、ソリューションディレクトリ上のとあるファイルに格納される。それは.resharperファイルだ。だから、.resharperファイルを他のファイル全部と一緒にソースコードリポジトリに突っ込めば、開発チームの誰でも同じ設定を使用することになる。

.resharperファイルに保存されるものには面白いものが2つある: コードフォーマット設定とテンプレートだ。

コードフォーマット設定の共有

上の(ReSharper > Options > Code Styleとたどった)スクリーンショットの通り、ReSharperには、コードフォーマット設定の共有に関して3つの異なる選択肢がある。

• すべてが現在のユーザー専用。これがデフォルトだ。マシンは1台、開発者は1人ってだけならこれで問題ない。


• 現在のソリューションをチームで共有。開発者が複数で、Visual Studioのソリューションは1つだけなら、この設定がいい。全員が同じコードフォーマット設定を使う。


• 現在のソリューションを外部ファイルで設定。これを使うにはもう少しやることがあるけど、(僕たちみたいに)同じソースツリー内に複数のソリューションがあるなら、これを使おう。

最後の設定を使うには、Exportボタンを使って、設定をどこかの.xmlファイルに保存しておかないといけない。それからそのファイルのパスを指定する。同じソースツリーに含まれている複数のソリューションで設定を共有しているのであれば、相対パスを指定したいところだ。

テンプレートの共有

以前は、ソリューションに新しいクラスを追加したときは、そのコードをきれいにするのに数秒はかかっていた――クラスの可視性を修正したり、不要なusing文を削除したり。新しいインタフェースが欲しいときは、「新しいクラスの追加」をやってから「class」キーワードを「interface」に置換していた。たいした手間ではないけど、その手のことは自動化できたっていいじゃないか。コンピュータだもの。

ReSharperでは数種類のコードテンプレートを定義できる。「ライブテンプレート」(Tabキーで移動して値を入力するようなフィールドをもつもの)、「囲む」、そして「ファイルテンプレート」だ。どれも設定を変更でき、変更した設定は全部.resharperファイルに保存される。というわけでもう一度言うけど、開発チームの全員で自動的に共有される。

ReSharperにはサンプルのテンプレートがいくつか含まれているから、中を見て、どういう動きをするのかを知ることができる。ただイラつくのは、そのサンプルだと各ファイルの先頭にコメントブロックがあって「作者」だとか「日時」だといった欄があるんだ――何が楽しくてこんな情報を複製するんだって話だ。ソースコードリポジトリを見れば、誰がファイルを追加したのか一目瞭然だってのに。(たぶんイラつくようにわざと作ってあるんだ。そしたら間違いなく自分用のテンプレートを作る気になるだろうから。僕たちはそうだった。)

独自のテンプレートは簡単に作れるけど、若干ひねくれている。ここが大事なんだけど、「Available everywhere」っていうハイパーリンクはクリックした上で、「いや、C#だけで使う」って指示しないといけない。(そうしないと、ファイル名の拡張子を追加してくれないんで、ファイルが正しくフォーマットされなくなる。) しかも、$NAMESPACE$ みたいな特別なプレースホルダを使いたいなら、名前だけでは認識してくれないので要注意だ。「テンプレート変数」のグリッドの中で「マクロを選ぶ」をクリックして、一覧の中からマクロを選ぶ必要がある。

友人のライブと外山恒一

新中野のライブハウスに行ってきた。

帰りに新宿駅で降りたのだが、そのときに外山恒一氏と思しき人を見た。話しかけたりしなかったので本人かどうかは分からないけどね。

ライブはこんな感じ。携帯電話で撮ったから何がなんだか分からないかもしれない。だが、それがいい。

大木ちゃん？

仮面ライダー電王に大木ちゃんが出てた？
別人かなあ。どうかな。第15話、6分30秒あたりからなんだが……やっぱ違う人かな。

Day 5: 統合されたユニットテストランナー

元記事

「31日間ReSharper一周」の5日目へようこそ。今日はReSharperのユニットテストランナーを紹介する。

(ReSharperのユニットテストランナーは無料で別個にダウンロードすることもできる。もし完全なReSharperが不要ならばね。)

しかし、なぜ世界に更なるユニットテストランナーが必要だったのか？テストを実行する方法はすでにたくさんあるわけだし。NUnit GUIもあるし、NUnitコンソールランナーもある。MSBuildでソリューションをビルドした後NUnitコンソールを実行するようなrakefileを書いて、そのファイルを呼び出すようにツールメニューのオプションを設定して、それに対してキーストロークを割り当てることもできる(僕はそうしている)。TestDriven.NETをインストールしてもいい。(Microsoft謹製テストランナーに大枚をはたいたっていい。実際にはテストを実行させてくれないとしても。)これで選択肢は全部カバーできてない？

そうかもしれない。でも、ReSharperのテストランナーはピカイチだ。IDEのアドインだから、うまく統合されている。では見ていこう。

テストを全部実行する

前にもぶーたれたことがあることだし、テストツールのいっちばん基本的な機能から始めよう。全テストの実行だ。

もちろんReSharperでできるし、それに簡単だ。全テストを実行する一番よい方法は、ReSharperAddIn25.UnitTestRunner_RunAllSolutionコマンドにキーストロークを割り当てることだ(僕らはCtrl+Shift+Tにしてる)。そうすれば、Ctrl+Shift+Tを叩けばいつでも、自動的にソリューションがビルドされ、全テストが実行され、結果に応じて緑(または赤)のバーが表示される。

もしそこまで簡単にしたくないのなら、ReSharperメニュー > Unit Testing > Run All Tests from Solution を実行するのでもいい。Unit Testingメニューにはあと2つほど別のオプションがあるけど、僕は無視してる。全テストを実行する以外のことをするように見えるからだ――今のところ、NUnitのテストをすばやく実行することでかなりうまくやれている。

対応しているテストランナー

追加設定なしで、ReSharperのテストランナーはNUnitとcsUnitのテストに対応してる。ReSharperのUnitRunをmbUnitに対応させるサードパーティのアドインもある。

統合

ReSharperのテストランナーアドインはVisual Studioの中にいることを本当にフル活用する。

• ドッキング可能。テストランナーのウィンドウはIDEの他のウィンドウとまったく同じようにドッキング可能だから、邪魔にならないところに押し込んでおくこともできる。僕はIDEの一番下のところの、「出力」ウィンドウや各種「検索結果」ウィンドウのタブにくっつけている。(タブの中に置いておいたとして、テスト実行時にもし別のタブが表示されていたら、テストランナーのウィンドウが前面にくる。期待通りにね。)


• キー割り当て可能。上でも書いたが、1キーストロークが「全部ビルドして、全部テストして、結果を赤や緑のバーで表示する」に割り当てられているのは超楽。マジで楽。


• 注意を払う。コードを変更してリビルドすると、テストツリーの全アイコンが小さいクエスチョンマークに変わるから、まだテストされていないことが見てわかる。でも色はそのままだから、前回はどれが成功でどれが失敗だったかも見ればわかる。以下は「最新の実行」(チェックマーク)と「リビルド後」(クエスチョンマーク)のスクリーンショットだ。
  
  さらに賢いのは、ソリューションをビルドしたときに、実際にはコードを何もいじっていなかったなら、クエスチョンマークにはならないんだ。(この機能はありがたい。なにしろ、しゃべったりなんかするとすぐ気が散って、テストを実行したかどうかも覚えてられないからだ。)


• コードへジャンプ。これには素晴らしい機能が2つある。1つ目。テストツリー上のテストをダブルクリックすれば、そのテストのコードがエディタに表示される。2つ目。テストが失敗したら、テスト結果ペインの呼び出しスタック中にハイパーリンクが出力され、そのうちの1つをクリックすればエディタでその場所へジャンプする。
  


• テストを走らせたりデバッグしたりするガター(左余白)アイコン。テストメソッドを発見すると、ReSharperはコードの隣のガターに緑と黄色の小さい円を表示する。その円をクリックするとドロップダウンメニューが表示される。メニューの中にはそのテストをデバッガで実行するオプションがある。だからテスト中にブレークポイントを設定してデバッグしたいなら簡単にできる。
  

実のところ、ReSharperのユニットテストランナーの機能には別段革新的なものはない。「コードにジャンプする」機能はかなりすばらしいけどね。要は、機能が全部そろっていて、どれもちゃんと使えるってだけだ。ユニットテストをするんなら、ReSharperのテストランナーを試してみるといい。

ワンス・オブ・センダー

ナハッ

えーと、仕事してないときはこういうことばっかり考えています。

MS主催のWeb系カンファレンス "MIX '07"

http://visitmix.com/
現地時間の4月30日～5月2日開催。現地では初日は終わったかな。
以下メモ、随時更新。

• Silverlightで.NETサポート


• 上記から必然的に、クロスプラットフォームCLR


• Dynamic Language Runtime。Python(IronPython2.0)、JavaSscript(ECMAScript 3.0)、VB、そしてRuby(結局IronRubyという名前でFA?)


• Windows Live APIの拡充。REST APIなど。

関連して

• http://blogs.msdn.com/somasegar/archive/2007/04/30/mix-07-silverlight-shines-brighter.aspx


• http://d.hatena.ne.jp/akiramei/20070501/p1


• Miguelが予想した「Silverlight for Linux」はハズレかな。

Day 4: 自動閉じデリミタ

元記事

「31日間ReSharper一周」の4日目へようこそ。

タイプし始めるとすぐ気付く機能がある。開始デリミタを入力すると、ReSharperが終了デリミタを入力してくれるんだ。

単純な機能だけど、ちゃんとやるのはそれほど単純じゃないし、2.5から紛れ込んだバグ(その後2.5.1では修正されたけど)を除けば、ちゃんとやれている。おかしなことをすることはめったにない。

この機能は次のデリミタで動作する; { 、( 、[ 、" 、そして ' だ。ただしジェネリクスの文法は自動補完してくれない。< は対象外なんだ。

動作サンプルは以下だ。

最初は空文。
メソッド名を入力して……
「(」を入力する。
部分式を入力して……
「(」を入力する。
おっと、「(」じゃなくて「[」だった。Backspace……
「[」を入力する。
パラメータを入力し終わったら……
「]」を入力して……
「)」を入力して……
「;」を入力する。

正しくやるべきときに正しくやってくれている。開始デリミタの直後でバックスペースを押せば、(カッコの中で何も入力してなかったなら)終了デリミタも消してくれる。しかも、カーソルが終了デリミタの直前にあるときに終了デリミタを入力しても、終了デリミタは2つにならない。この動作はセミコロンでも同様だ; カーソルがセミコロンの前にある時にセミコロンを押したって、セミコロンが2つになることはない。しょっちゅう右矢印を押したりせず、いつもどおりに入力できる。

この機能は賢いので任意のネスト内でもちゃんと動く。もし開始デリミタを入力したときに終了デリミタがすでにあるなら、終了デリミタは追加されない。当てずっぽうの時だってあるに違いないと思うんだが、気付くような間違いが起きたことなんてなかったように思う。

注意: {を入力したときには対応する}が自動的に入力される――つまり、中カッコでコードブロックを囲もうとしていたとしても、対応するデリミタはカーソル直後に入力されてしまうということ。その代わり、現在の選択範囲を中カッコで囲みたいときには「囲む」コマンドを使うといい。ショートカットはCtrl+Alt+J、8だ (Ctrl+Alt+Jでメニューがポップアップ表示されるから、8のとこは覚えなくていい)。

(追記: ReSharper開発者のIlyaが指摘してくれたんだけど、ReSharperでは、{キーの直後ではなく、Enterキーを押したときに閉じカッコを追加するようにできるから、既存コードブロックを中カッコで囲むのがやりやすくなるだろうって。Ilyaありがとう!)