に、カソウケンの内田さんが就任された。
内田さんは応化卒なんですね。知らなかった。
独自ドメインやt.u-tokyo.ac.jpを(選ぶことはできたはずだが)選ばなかったのは、話題性とかユーザコミュニティとかを鑑みた上での決定なんだろうなあ。はてなを選んだのは(立ち上がりとして)いいと思う。人力検索やブログ(ダイアリー)やブックマークや、最近だとスターもだね、そういうのが「つながる」のがはてなだし、実際つながってる感じはするし(はてな村と揶揄もされるが)、コミュニティ力は高いように感じるから。
内田さんには思う存分腕を振るっていただきたい。
メモリを1GB以上積んでいるWindows XP sp2マシンで掲題のエラーが出る人は、KB909095をインストールすると直る……かもしれない。
……こういう記事を書くと、ここばっかりページビューが上がるんだよなあ。crypt32の記事も常にアクセスがあるからなあ。
プログラミング言語について見てみたら面白いかもと思って調べた。測定方法は、『タグ「●●」を含む人気エントリー』の、●●部分を各言語に置き換えてみるというもの。
(追記)「h指数だと対応する概念はないような……」というのはその通りです。Wikipediaには
ある研究者のh指数は、「その研究者が公刊した論文のうち、被引用数がh以上であるものがh以上あることを満たすような数値」となる。
とありますんで、本来は人を評価する概念ですからね。ただ、「その言語に関する記事のうち、ブクマ数がh以上であるものがh以上あることを満たすような数値」と無理やり読み替えてみました。
説明しておくと、リンク先は"http://b.hatena.ne.jp/t?tag=言語名&of=スキップするブクマの数&sort=count"ってなってます。なのでたとえば"of=100"だと、101件目から表示します。
ちなみにこの方法だとJavaは測定不可能でした(JavaScriptが混ざるため)。Cも無理くさい。C++なら測定できそう。
後で推敲
「h-index を Ruby で書いてみた」を見て、ついカッとなってやった。後悔はしていない。でもSQLで書くなんて当たり前すぎてつまらない。
Oracle8.1.6EE以降またはSQL Server 2005なら分析関数が楽。
SELECT COUNT(*) FROM
(SELECT
ITEM,
ROW_NUMBER OVER (ORDER BY ITEM DESC) AS INDEX
FROM DATA
WHERE INDEX <= ITEM)
COUNT(*)ならROW_NUMBERの代わりにRANKでもおｋ。
ROW_NUMBER限定ならCOUNT(*)の代わりにMAX(INDEX)でもおｋ。
ROWNUMならサブクエリが増える(ORDER BYのため)
SELECT COUNT(*) FROM
(SELECT
ITEM,
ROWNUM AS INDEX
FROM (SELECT ITEM FROM DATA ORDER BY ITEM DESC)
WHERE INDEX <= ITEM)
MySQLとかSQL Server 2000とかみたいに上の手段が×ならJOIN(ここでは書いていないけど、ユーザ変数でも可。効率がいいのはどっちなんだろう。誰か教えて)。
SELECT COUNT(*) FROM
(SELECT
T1.ITEM AS ITEM,
COUNT(*) AS INDEX
FROM DATA AS T1, DATA AS T2
WHERE T1.ITEM <= T2.ITEM
GROUP BY t1.ITEM
HAVING INDEX <= ITEM)
これだとROW_NUMBERというよりはRANK的な数値になるんで、
INDEXというエイリアシングは良くないけど、上の例にあわせた。
サブクエリも試してみたけど
昔のMySQL相手じゃ意味が無い！
だから次は絶対勝つために
僕は一時テーブルだけは最後までとっておく
やっと終わった……
「31日間ReSharper一周」の31日目にようこそ(はいはい1日遅いですよ。昨日は休んだから)。
ネタにする最後のReSharperリファクタリングは「安全な削除」だ。Ctrl+Shift+Rメニューからでも、直接Alt+Delでも利用できる。
「安全な削除」は、また別のReSharperリファクタリングウィザードを表示する。最初のページ(大抵このページしか見ない)はかなりつまんない。まあそりゃ、何かを削除するのにそんなに何種類もやり方があるはず無いよね。
「安全な削除」の基本的な考えは、コードを壊さずに削除するということだ。次の2つのことをやってくれる。
「安全な削除」は、理論的には素晴らしい。コードが使われていないと思ったときに、実際使われていないことを確認し、それを削除し、全呼び出し元を更新するまでを1つの操作でできる。未使用パラメータについては手で確認する方法だってある。なぜならReSharperは、publicメソッドの未使用パラメータを確認したりしないから。ソリューションに含まれる全メソッドの全パラメータに対して「安全な削除」を手で動かすのは嫌だろうけど、何かが不適切ではないかと思った時にはいいクリーンアップツールだ。
ただ、この投稿のために調査しながら気づいたんだけど、ReSharperのチェックは完璧とは言いがたい。変更の完遂についてはかなりよくやってくれるようだが、最初に問題をチェックし通すことからはだいぶ離れている。だから……
「安全な削除」の直前および直後には、いつもコンパイルすること。コードが壊れるかもしれないからだ。
1～2分探りまわって見つけた2つのケースは以下の通り。
いつでもコードが壊れると言いたいわけじゃない。それはありえない。注意してればなおさらだ(僕はイベントハンドラメソッドのパラメータを削除してみるほどバカじゃなかった。どうなるか知りたいとは思ったけども)。ほとんどの場合、ReSharperのチェックにひっかかるだろう。でもやっぱり前後にコンパイルしておいたほうがいい。
「31日間ReSharper一周」の30日目にようこそ。
今日は全リファクタリングの母について。「リネーム」だ。F2で利用できる。もちろんCtrl+Shift+Rメニューから使うこともできる。
今となっては「リネーム」リファクタリングについて言わなきゃいけないことはそんなにない。まとめて言えば、機能したりしなかったりだ。すごさにも限度はあるけど、ReSharperではすてきな技をいくつかキメることができる。
注: 技術的な問題や、計画不足や、何回かの大吹雪なんかが相まって、現在自宅でReSharperを使うことができない。だから今日の(たぶん明日も)投稿にはスクリーンショットが無いし、詳細は記憶頼みだ。もし何か間違ってたら訂正してほしい。それらはいつか反映させるから。
局所変数をリネームするとき、ReSharperでは同期編集(僕がこう呼んでるだけで公式名称ではない)によりエディタ上で変更できる。変数名の提案リストもポップアップするから、リストから名前を選ぶこともできる。
僕はDelphiに慣れているが、Delphiでは同期編集モードを終了して変更を確定させるのにEscを押さないといけなかった。ここからの転向はReSharperには準備不足だったね。というのは、ReSharperの同期編集でEscを押すと、変更が取り消されてしまうんだ。ReSharoerでは、変更の確定にはEnterを押さないといけない(そう、もしDelphiでも同じ動きをするんならとても納得のいくことだったんだろうけど)。
今はEnterを押して変更を保存するのは納得なんだけど、弱点もある。もし変数名リストが表示されていたら、Enterを押すとリストで選択中のアイテムが選ばれてしまう。だから例外オブジェクトに名前をつけようとして、たとえばexとするけど、exと入力してEnterを押しても変数名はexにリネームされない――exceptionになってしまうだろう。なぜならexで始まる変数名の提案の先頭だからだ。
短い変数名を入力するための回避策は次の通り。Enterを1度押せば変数名提案は消えるけど、同期編集はまだ終わらない(提案リストがもう消えていても、もう1度Enterを押す必要がある。押さないとリネームは取り消される)。だから、Escを押して提案リストを消し、それからEnterを押してリネームを確定させよう。
僕は長い間、伝播リネームのリファクタリングを待ち望んでいた――関係する全コードに影響するやつ。たとえば、SongFileという名前のクラスがあったとすれば、songFileとかfileという名前の変数や、SongFileという名前のプロパティやなにかがたくさんある可能性が高い。僕が望むリネームとは、SongFileからSongDataStoreに変えたら、それら変数名やプロパティ名のすべてに影響して、そっちもリネームしてくれるものだ。
ReSharperにはその機能がある。
さて、どちらにせよ普通は、クラスをリネームするときはウィザードが表示され、最初のページでは新しい名前を聞かれる。そこまでは何も目新しくない。しかしその後、次のような変数とプロパティを探す。(1)リネームする型に一致するもの、(2)変えようとする名前の一部分に似た名前をもつもの。そして2番目のページでそれらをリストアップし、それら全部に新しい名前を提案してくる。リネームしたくないものはチェックをはずすこともできるけど、そうする意味はあるか？
唯一の弱点は、子孫クラスには同じことをしてくれないことだ。でも僕は機能要求を起こしたから、いずれきっと……
フリーセルの続き。
アルゴリズムはほとんど変えず、内部構造だけ変えたら、とたんに3秒で答えを出すようになった。
答えあわせはまだだけど、100倍近く速くなったのでびびった。
ちなみに深さ優先探索で、発見された解の手数は6000ステップ強。これを幅優先探索に変えたらどうなるんだろうか。楽しみ。
「31日間ReSharper一周」の29日目にようこそ。
インターフェースを使うのは、昔からかなりいらいらの種だ。テスト可能なコードを書くときには必要で、ファイルシステムに見せかけたヌルオブジェクトを渡すことができる。でもコードが実際にやっていることを追いかけようとするときには辛い。
ReSharperには、インターフェースを使うのをずっと簡単にする機能がいくつかある。2つはもうネタにした。「先祖クラスへナビゲート」と「型階層ビュー」だ。
今日はインターフェースを使うときに便利な機能をもう1つネタにする。「ベースメソッド」プロンプトだ。
メソッドのリファクタリング――たとえばリネーム――をするときに、そのメソッドがインターフェースを満たすためのものなら、ReSharperはそのリファクタリングをインターフェースの方に適用するかどうか聞いてくる。
このダイアログボックスはポンコツ的だ。思考の流れを中断させるし、質問は簡単に理解できるようなものでもない。僕の考えるようには動かない。残念だが、改善案はひとつも思い浮かばない。
そうは言っても、この機能が嫌いなわけではない。メソッドをリネームしようと思ったときに、ReSharperが自動的に割り込んできて、インターフェースもリネームするか聞いてくる。答えは勿論Yes！コードがコンパイル可能に保たれるからだ(時には先に「はい」を押してしまい、その後で「ああー、このメソッドはインターフェースから来てたんだ！」ってなる)。
同じことは「使用箇所の検索」でも当てはまる。インターフェースを実装するメソッドについて「使用箇所の検索」をするなら、「このメソッドを探しますか、それともインターフェースを経由して使う同じメソッドを探しますか？」と聞かれるだろう。この場合、このメソッドの使用箇所を全部知りたければ2回検索しないといけないかもしれない(インターフェース経由での使用箇所だけ知りたいのなら、「はい」と答えて1回検索するだけでいいけれども)。
「31日間ReSharper一周」の28日目にようこそ。
今日は、「メソッドの抽出」と一緒に使えるリファクタリングを(昨日話した「パラメータの導入」を除いて)もう2個ふれる。
ReSharperではいつでもスタティックメソッドを抽出できるわけではない(たとえば、コードがインスタンスフィールドやメソッドを参照している場合など)。でも2ステップかければできる。まずメソッドを抽出し、それから「メソッドをスタティックにする」リファクタリングを使う。
このリファクタリングはあまり使ったことがないから詳細には触れない。これがあるって事を指摘したかっただけだ。
ReSharperには「プロパティの抽出」リファクタリングがない。でも2ステップかければできる。まずメソッドを抽出し、それから「メソッドをプロパティに変更」を使う。
もし逆をやりたければ、「プロパティをメソッドに変更」のリファクタリングもある。
翻訳に時間をかけている間にメジャーアップデート。
でもそんなの関係ねぇ！
「31日間ReSharper一周」の27日目にようこそ。
今日のネタは「メソッドの抽出」だ。おそらく史上2番目に役立つリファクタリングだ(もちろん「リネーム」が1番だ。2～3日以内に扱うつもり)。
ReSharperは、必要だと判断したパラメータの名前を提案してくれる。でもダイアログが開いたときの1度きりだ。他の提案リストをドロップダウンすることはできない。
パラメータのチェックをはずすと渡されなくなる。その代わり、ReSharperは局所変数を生成して、3つの点(...)で初期化する。だからコンパイラは必ず、何か他のものを記入しなさいと穏やかに諭してくる。
何度か、ReSharperの(Delphiのもそう。この件に関してはね)「メソッドの抽出」ダイアログにパラメータを追加するオプションがあったらなあと願ったことがある。でも今夜このことを考えていて、必要ない――少なくともReSharperでは――ことに気づいた。
テスト用のセットアップコードがあるとしよう。こんな感じだ。
_foo = new Foo(42);
そして、このコード行を新しいメソッドに変えたいとする。メソッド名はInitializeFoo()で、int引数をとる。望みのものは、「メソッドの抽出」ダイアログがこれから書き出すコードを表示し、それが42をハイライトして、「さあ、この式に別のパラメータを追加してくれ」と言ってくることだ。
って、どんだけー。まさにそれをやってくれる機能はもうあったんだよ！な、なんだってー！実際にはまずOKをクリックしてメソッドを抽出しないといけない。でもそれからコードエディタで42をハイライトさせて「パラメータの導入」をすることができる。そうすると呼び出し元が42を渡すように自動的に更新される。全部オッケー。
「31日間ReSharper一周」の26日目にようこそ。
3つの関数が同じ引数を持つんだけど、それぞれ順序が違う、なんてことが今までにあった？もしあったなら、「シグネチャの変更」はぴったりの機能だ。
ReSharperの「シグネチャの変更」ダイアログは、メソッドのシグネチャに関するどんなものでも変えることができる。ReSharperの他の機能にもメソッドのシグネチャを特定の手段で変更するものはある。たとえば「パラメータの導入」とか。でもこれにはショートカットが無い。以下のことができる。
どの場合でも、ReSharperは全部の呼び出し元をちゃんと更新してくれる。
新しいパラメータを追加するとき、コードをコンパイル可能に保つために、ReSharperはすでにこのメソッドを呼んでいるすべての呼び出し元を修正する必要がある。つまり、何かを渡す必要があるということだ。これは必須フィールドであり、すべての呼び出し元から渡される何かを指定しないといけない。
じゃあ、すべての呼び出し元からまったく同じ値を渡すのが嫌なら、どうすればいい？それにはいくつか選択肢がある。
モチベーション低下中……
「31日間ReSharper一周」の25日目にようこそ。
導入系リファクタリングは3つのうち2つ話した(「変数の導入」と「フィールドの導入」)。今日は3番目、「パラメータの導入」。
「型」コンボボックスのてっぺんのピクセルが欠けてたり、「定数の導入」チェックボックスが無かったりするのを無視すれば、かなり「変数の導入」とそっくりだ。動きもほとんど同じ。青いハイライトは邪魔だったり、そんな感じ。
代わり映えしないように聞こえるだろうけど言う。これは効く。びっくりするぐらい賢い。
以下はつまらない例だ。
_tilesWide = GetTilesWide(_previewer);
...
private int GetTilesWide(Control control)
return (control.Width + TileWidth - 1) / TileWidth;
}
この関数に対するユニットテストを書きたいが、テスト内でControlのインスタンスを作りたくはないとする。単にcontrol.Widthをハイライトし、「パラメータの導入」ができた。
おかしなことに、最初に提案されるパラメータ名は、ありそうなwidthじゃなく、iだ(widthはコンボボックスをドロップダウンすれば使えるけど)。controlWidthを提案してくれないのはちょっとサムい。
変数名としてcontrolWidthを入力したとすれば、結果のコードは以下のようになる。
_tilesWide = GetTilesWide(_previewer, _previewer.Width);
...
private int GetTilesWide(Control control, int controlWidth)
{
return (controlWidth + TileWidth - 1) / TileWidth;
}
そうすると、controlパラメータが灰色になる。もう使ってないからね。なので、カーソルをそこに動かしてAlt+Enterを押し、未使用のパラメータを削除できる。するとコードから恐ろしい依存性が消え、よりユニットテストがやりやすくなる。
_tilesWide = GetTilesWide(_previewer.Width);
...
private int GetTilesWide(int controlWidth)
{
return (controlWidth + TileWidth - 1) / TileWidth;
}
(メソッドがpublicだったならパラメータは灰色で表示されなかっただろう。ReSharperは臆病だからpublicメソッドを見てくれないんだ。個々の警告を抑制する#pragmaがサポートされるようになればこれは直るかもしれない。その機能は次のリリースに含まれているそうだ。でもあきらめないように。ReSharperにはパラメータを削除する方法を知っている別の機能もある。)
パラメータを追加することがすごいわけではない。実際、局所変数を追加するのよりすごいことは何もない。すごいのは、呼び出し元に対して自動的に「正しいことを為す(Do The Right Thing)」ことだ。もし呼び出し元に、Conotrolインスタンスを返すようなあいまいで複雑な式を渡すようなものがあったとしても、結果は素晴らしい。あいまいで複雑な式の末尾には.Widthが追加されるだろう。
もっと複雑な式を抽出していてもうまくいく。他のパラメータだけでなくスタティックメソッドも使えるし、現在のクラスが持つインスタンスメソッドやプロパティであったとしても問題ない。ReSharperはちゃんと正しいことを為すだろう。
もう少し現実に近い例を挙げよう。コード中で実際にやるようなことに近いかもしれないし、近くないかもしれない。でもこの記事の残りの部分がフィクションだとしても、すごさが減るわけではない。
processor.ProcessFile(FileType.Foo);
...
public void ProcessFile(FileType fileType)
{
string fileName = this.Configuration.GetFileName(fileType);
...
}
僕らはConfigurationプロパティを取り除こうとしていた。テストハーネス内で何かをインスタンス化するのは怖いし大変だからだ。だからまずはthis.Configurationをパラメータとして抽出するところから始めた。
processor.ProcessFile(FileType.Foo, processor.Configuration);
...
public void ProcessFile(FileType fileType, Configuration configuration)
{
string fileName = configuration.GetFileName(fileType);
...
}
僕が本当にうなってしまったのは(君からすれば単純なことかもしれないが、僕は昔パーサーを書いてみたことがあるから、この手のことは評価するんだ)、呼び出し元に対してちゃんと正しいことを為したことだ。呼び出し元はprocessor.Configurationを渡している。追加したパラメータは、自動的に正しいオブジェクトの正しいインスタンスを使って渡されている。
いやー、すごい。
「31日間ReSharper一周」の24日目にようこそ。
昨日はReSharperの「変数の導入」リファクタリングについて話した。今日は「フィールドの導入」だ。
フィールドの追加は変数の追加にかなり似ているが、オプションが追加されている。
ここでは通常の変数名提案(ReSharper Optionsで指定した命名規約に従うもの)が動作する。
「局所変数の導入」と同じく、これも「式を全て置換する」チェックボックスを持ってる。ただ「フィールドの導入」はクラス全体に影響するから、青いハイライトやカラーバーの青い縞は式がいくつ置換されるのかを見る上でもっと便利になった(まあそれらが消えないっていう事実には相変わらず腹立つけど)。
「キャンセル」が文字通りの「キャンセル」ではなく「すべてハイライトさせる」として使われてるというまぬけなふるまいは「フィールドの導入」にもある。本当の「キャンセル」をしたければ、「キャンセル」をクリックした後にEscを押さないといけない(そしてもし本当の「OK」をしたければ、「OK」をクリックした後にEscを押さないといけない。ぎゃぼー)。
基本設定については特に言うことはない。オプションは見るだけでよく分かる。
もしテストコードを書くなら、「××内で初期化する」系のオプションはテストクラスでは1つも使わないほうがましだと気づくはずだ。「現在のメンバー」が便利な時もあるかもしれないが、期待するようなものではないことが普通だ。(私見だが、「コンストラクタ」や「フィールド宣言」は、［TestFixture］付きクラスを書いているときには使用可能にするべきですらないと思う。テスト間の依存性をむざむざ与えてしまうことになる。)
「［SetUp］メソッド内で初期化」を付け加えるように、ReSharperに機能要求を送ったんだが、プラグインとして実装できるからと言われ、「修正しません」としてクローズされてしまった。もしそれが正しいなら、ReSharperプラグインAPIのドキュメント化を続行するという長い道のりを歩き出しているってことになるぞ。だってリファクタリングのサンプルなんてひとつも無いわけだから。書く予定があるとはビタイチ見えない。リファクタリングについては1節だってない。そういうことだから、もし誰かが、既存のダイアログボックスにラジオボタンの選択肢を追加して、その新しい選択肢は既存のリファクタリングの動作を変更するために使う、そんなReSharperプラグインを書こうと思っているならば、最大級の幸運が今すぐ訪れますようにと祈るだけだ。
これで世界の終わりってわけじゃない。「フィールドの導入」はそれでも適切に使える。ReSharperのほとんどの部分ほど良くは無い。手でSetUpメソッドのところまでスクロールしたりとか、そういったことをしないといけない。(にっこり)
もしテストクラスで「フィールドの導入」を使いたいのなら、うまくいくようにする方法は次の通りだ。もしもプラグイン用ドキュメント作成が回避されるんでなければ、それまではね。
実際はそんなに大変じゃない。ただいらいらするだけだ。全てがとても簡単になったのに慣れてしまった。だから、いつもやってることを取り上げられて、簡単にするべきなのにきっぱり断られたりすると、がっくりする。
行ってきた＠C.C.レモンホール。メンバーはミウラ＆愛理夫妻、ボビナ先輩、おれ。ミウラとボビナ先輩とおれは大学時代に筋少のコピーバンドをやっていた仲。
先陣はすかんち。
実はすかんちはそんなに知らなかった(恋のマジックポーションと恋のミラクルサマーだけだ。ごっつ世代)ので、事前にYouTubeなどで何曲か聴いておいた。改めて聴いてみたら結構面白いね。元ネタ探すのも楽しい。『恋するマリールー』はQueenの"Now I'm Here"とT-Rexの"Get It On"かな。『ウルトラロケットマン』はリフに聞き覚えがあるが思い出せない。全体的にZep風。Black Dogも。曲はExteremeっぽくもある。他に『恋の$1,000,000マン』も聴いた。どうやら定番曲のようだ。今回のステージでも演るかな？
Rollyはギターも巧いが、歌も上手い。何より声がいい！オーケンとは比べるべくもない。
Keyboardは、前任のDr.田中と後任の小川文明が両方とも参加してた。Dr.田中はキャラ濃すぎ！小川文明はキーボード積みすぎ！
YouTubeで予習した曲は演奏しなかったが、大満足だった。
ステージを入れ替えて、筋肉少女帯の時間。
ギターアンプが2セット準備されたのを見て苦笑。橘高アンプはマーシャルを壁のようにスタックしていたが、おいちゃんのアンプはちんまりしていたからだ。
今回、というか再結成筋少の見所はなんといってもエディと橘高のカラミだろう。その二人による『サンフランシスコ』を楽しみに来たようなもんだ。
『イワンのばか』から客は大興奮！やっぱりすかんちファンより筋少ファンの方が多かったみたいだ。
オーケンがブースカ人形を使って新曲『仲直りの歌』を披露するくだりはいかにもオーケンらしいグダグダ感。続く『ダメ人間』ではダメジャンプ(Xジャンプ的なもの)でぴょんぴょん。
そしてニューアルバムのタイトル発表！タイトルは『新人』……苦笑する客席。へこむオーケン。そりゃ誰だってネタだと思うだろう。
嬉しかったのは『戦え！何を！人生を！』から『サンフランシスコ』の流れ。いやー来てよかった。そして最後は『ア太郎』。これは完全に予想外。このあたりが80年代的というか、エディがいてこそというか。
最後は両バンド出てきて、学園天国で〆。楽しゅうございました。
サービス概要
日本の休日情報を提供する Web サービスです。
SOAP 1.1 および 1.2 に対応しています。REST にはサーバの都合により対応していません。
bear.mini の実験室 「休日情報 Web サービス」
いや、それはサーバの都合じゃなくて、実装してないだけだと思う。確かにASP.NETならSOAPによるXML Webサービスを書くのは簡単だけれども。(←私の勘違いのようでした。bear.miniさんにお詫びして訂正。)面白いと思ったので、自力でREST対応したらどうなるか書いてみた。
ってなわけで、サンプル書いてみた。ソースコードはzipにしておいた。
ポイントはいくつかあるが、
といった所か。
暇なときに、リンク先のアンケートに答えてみる。(あとで書く)
