平々毎々 (Hey hey, My my)

rock and roll can never die.

月別アーカイブ: 7月 2007

菅平虫 = ブヨ

先週末、菅平にテニスしに行ってきた。人生3回目のテニスなので、お話にもならないレベルだ。でも本題はテニスではない。

同行した人たち曰く「菅平には『菅平虫』略して『平虫(だいらむし)』がいる。」よく話を聞くと、ブヨのことらしい。菅平にはブヨがたくさんいて、よく誰かが足を刺されてしまう。足を刺されると腫れてかなり痛いのだとか。

実際、刺された人は今回もいた。菅平に行く際は虫除けスプレーを持っていくといい。

広告

東大工学部広報室

に、カソウケンの内田さんが就任された。

内田さんは応化卒なんですね。知らなかった。

独自ドメインやt.u-tokyo.ac.jpを(選ぶことはできたはずだが)選ばなかったのは、話題性とかユーザコミュニティとかを鑑みた上での決定なんだろうなあ。はてなを選んだのは(立ち上がりとして)いいと思う。人力検索やブログ(ダイアリー)やブックマークや、最近だとスターもだね、そういうのが「つながる」のがはてなだし、実際つながってる感じはするし(はてな村と揶揄もされるが)、コミュニティ力は高いように感じるから。

内田さんには思う存分腕を振るっていただきたい。


カソウケン(家庭科学総合研究所)へようこそ

システムリソースが不足するため、APIを終了できません。

メモリを1GB以上積んでいるWindows XP sp2マシンで掲題のエラーが出る人は、KB909095をインストールすると直る……かもしれない。

……こういう記事を書くと、ここばっかりページビューが上がるんだよなあ。crypt32の記事も常にアクセスがあるからなあ。

IronRuby Pre Alpha

via 荒井省三のBlog

公開されました

ソースコードが公開されてます。.NET Framework 2.0 再頒布可能パッケージがあればビルドできます。

プログラミング言語別「はてブ指数」

「はてブ指数」についてはリンク先を参照のこと。

プログラミング言語について見てみたら面白いかもと思って調べた。測定方法は、『タグ「●●」を含む人気エントリー』の、●●部分を各言語に置き換えてみるというもの。

(追記)「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をSQLで

後で推敲

「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でもおk。
ROW_NUMBER限定ならCOUNT(*)の代わりにMAX(INDEX)でもおk。

OracleのROWNUM

ROWNUMならサブクエリが増える(ORDER BYのため)

SELECT COUNT(*) FROM
  (SELECT
  ITEM,
  ROWNUM AS INDEX
  FROM (SELECT ITEM FROM DATA ORDER BY ITEM DESC)
  WHERE INDEX <= ITEM)

JOINで順位付け

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相手じゃ意味が無い!
だから次は絶対勝つために
僕は一時テーブルだけは最後までとっておく

フリーセル(その3)

幅優先探索を実装してみたのはいいけど、枝が発散する。

breadth-first search

アルゴリズムを真面目に考えないといけないんだけど、面倒なのでヤメ。

Day 31: 安全な削除

やっと終わった……

元記事

31日間ReSharper一周」の31日目にようこそ(はいはい1日遅いですよ。昨日は休んだから)。

ネタにする最後のReSharperリファクタリングは「安全な削除」だ。Ctrl+Shift+Rメニューからでも、直接Alt+Delでも利用できる。

「安全な削除」は、また別のReSharperリファクタリングウィザードを表示する。最初のページ(大抵このページしか見ない)はかなりつまんない。まあそりゃ、何かを削除するのにそんなに何種類もやり方があるはず無いよね。

「安全な削除」の基本的な考えは、コードを壊さずに削除するということだ。次の2つのことをやってくれる。

  • 問題が起きるかチェックする。メソッドを削除しようとしたときに、そのメソッドがどこかでまだ使われているならReSharperが警告するので、削除をキャンセルできる。ハイパーリンクのどれかをクリックすればコードにジャンプできるし、問題を全部「結果検索」ウィンドウに表示することもできる。
  • 変更を完遂する。パラメータを削除する場合は全部の呼び出し元が更新されるだろう。仮想メソッドかインターフェースメソッドを削除する場合は、全子孫クラスからも削除するかどうか聞かれる。

「安全な削除」は、理論的には素晴らしい。コードが使われていないと思ったときに、実際使われていないことを確認し、それを削除し、全呼び出し元を更新するまでを1つの操作でできる。未使用パラメータについては手で確認する方法だってある。なぜならReSharperは、publicメソッドの未使用パラメータを確認したりしないから。ソリューションに含まれる全メソッドの全パラメータに対して「安全な削除」を手で動かすのは嫌だろうけど、何かが不適切ではないかと思った時にはいいクリーンアップツールだ。

ただ、この投稿のために調査しながら気づいたんだけど、ReSharperのチェックは完璧とは言いがたい。変更の完遂についてはかなりよくやってくれるようだが、最初に問題をチェックし通すことからはだいぶ離れている。だから……

注意の言葉

「安全な削除」の直前および直後には、いつもコンパイルすること。コードが壊れるかもしれないからだ。

1~2分探りまわって見つけた2つのケースは以下の通り。

  • メソッドがデリゲートとして使われていて、そのメソッドのパラメータを「安全な削除」する場合は、ReSharperは止めない。その後はもう、メソッドは同じデリゲート型には明らかに一致しないから、コードはコンパイルできなくなる(メソッド全体を削除しようとしたときは警告してくれるから、少なくとも部分的にはデリゲートを意識しているんだろう)。
  • もし別アセンブリのメソッド(たとえばSystem.Windows.Forms.Control.IsInputKeyとか)をオーバーライドしていて、メソッドからパラメータを「安全な削除」するのなら、ReSharperは先祖についての警告もなしにパラメータを削除するだろう。だからそのオーバーライドがコンパイルを通らなくなる。オーバーライドするメソッドと一致するシグネチャが無くなってしまうからだ。

いつでもコードが壊れると言いたいわけじゃない。それはありえない。注意してればなおさらだ(僕はイベントハンドラメソッドのパラメータを削除してみるほどバカじゃなかった。どうなるか知りたいとは思ったけども)。ほとんどの場合、ReSharperのチェックにひっかかるだろう。でもやっぱり前後にコンパイルしておいたほうがいい。

Day 30: リネーム(伝播リネームを含む)

元記事

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番目のページでそれらをリストアップし、それら全部に新しい名前を提案してくる。リネームしたくないものはチェックをはずすこともできるけど、そうする意味はあるか?

唯一の弱点は、子孫クラスには同じことをしてくれないことだ。でも僕は機能要求を起こしたから、いずれきっと……

フリーセル(その2)

フリーセルの続き。

アルゴリズムはほとんど変えず、内部構造だけ変えたら、とたんに3秒で答えを出すようになった。

答えあわせはまだだけど、100倍近く速くなったのでびびった。

ちなみに深さ優先探索で、発見された解の手数は6000ステップ強。これを幅優先探索に変えたらどうなるんだろうか。楽しみ。