に、カソウケンの内田さんが就任された。
内田さんは応化卒なんですね。知らなかった。
独自ドメインや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回検索するだけでいいけれども)。
