期末試験全日程終了

やっと期末試験終わりました。3〜5日目はドイツ語・数学B・古典・音楽・英語×2・物理でした。あまりよろしくないできでした。試験期間中なのにあぼーんフィルタ v0.2を仕上げたせいです。ええ、言い訳です。勉強に集中できなくて、気分転換にXcodeに向かったらそっちには簡単に集中できちゃって、結局勉強できませんでした、っていうストーリー。後期は頑張るつもり。

よし、物理・・・あれ？

明日の物理の試験に備えて今日は一生懸命勉強したつもり。問題集もガシガシやったし。疲れた。

で、勉強を終えて物理の本やらノートやらをしまいながらふと試験の時間割を見る。

数学B。

…。明日物理じゃないじゃん。しかもよりによって数学B。中間試験で平均点の半分しかとれなかった代物。ヤバい。ヤバすぎる。さて、どうする。

期末試験2日目

ええと、昨日が期末試験2日目でした。数学IIと表現。数学が苦手なので、そればっかり勉強してました。

で、試験を受けたわけなんですが、数学、入学して以来最高の点数をとるかも。完璧。最高。100点とは言わないけれども、限りなくそれに近い点数をとれた。と思う。とりあえず、よくできました。

…表現？なかったことにしてください。

期末試験1日目

今日から高校の期末試験が始まったわけですが、1日目の出来は1勝1敗1分といったとこでしょうか。

OC

普通。ものすごく普通。

世界史

ヤバい。半分くらいしかわからなかった。神聖ローマ帝国没落の原因なんて、知るかよ。返却される点数見るのが怖い。

地学

かなり出来た。自信あり。ほぼ完璧。こんなに出来たのは、かなり久しぶり。

ってことで、明日は恐怖の数学が待ち受けているので勉強をしなければならない。

スレッドインスペクタのUIを考える

スレッドインスペクタのUIについて考えてみた。

現在のスレッドインスペクタは、複数の機能をパネル上部のタブで切り替えている。ただ、これではバージョンアップを重ねて機能を追加していくとタブの数がどんどん増えていってしまい、扱いにくくなってしまう。（スレッドインスペクタ0.1 スクリーンショット）

つぎに、パネルの形。FinderやXcodeのインスペクタパネルは縦長だけど、スレッドインスペクタのパネルは横長。これはどうも使い勝手が良くないような気がする。先に言った、タブの数が増えすぎるのも、ここに繋がると思う。なんか、縦長の方がすっきりするような感じ。

そこで、ちょっと改良してみた（スレッドインスペクタ開発中スクリーンショット）。まずパネルは縦長に。やっぱりこっちのほうがすっきりする。で、タブをやめてポップアップボタンで機能を切り替えるようにした。これだと無駄に場所をとることはないし、見た目も美しい（？）。

ただ、いままでのタブ方式が1回クリックするだけでよかったのに対し、このポップアップ方式は2回クリックしないと目的の機能に切り替えることができない。そんなに頻繁に切り替えることはないだろうけど、やっぱり不便。アプリケーション本体とバッティングしちゃまずいから、ショートカットキーも付けるわけにはいかない。うーん、むずかしいなあ…

女性専用車、おかしいよ

ええと、僕は女性専用車両に対して否定的な考えの持ち主なわけなんですが、ちょっと気になる記事を1つ。女性専用車両、台湾では男女に不評…３か月で存続危機（読売新聞）。どうやら台湾の鉄道に導入された女性専用車に乗客たちが不満を抱いていて、早ければ11月にも廃止することになるそうです。

記事中には、「同じ運賃を払う男性の権益侵害」っていう乗客のコメントがありますが、全くその通りだと思います。鉄道のような公共性の高いものが性別によって利用が制限されるのはあってはならないと思うんですよ。一部の女性団体は「男女同権」の立場から“女性隔離”を強く批判しているとも書いてありますね。日本の女性団体は男性が少しでも優遇されるとすぐに騒ぎ出すのに、女性が男性より有利な状況では何も言わない。こういうのは男女平等じゃなくて女尊男卑って言うんですよ。

っていうか、この記事の見出しもおかしいですよね。「台湾では」って、まるで日本では好評みたいな書き方じゃないですか。日本でも専用車を嫌がる人は多いと思うんですけど。女性専用車両に反対する会なんてのもありますし、東急東横線で女性専用車の運行時間が縮小されたのも苦情が殺到したかららしいですし。

はっきり言って、これはただの女性客の機嫌取りにしか思えません。女性専用車以外の痴漢防止策ってないものでしょうか。

あー、ガベージコレクションよ、早く来い

今日、「スレッドインスペクタ」が原因でThousandがクラッシュするらしい、と名取さんから連絡をいただきました。スレッドを開こうとするとクラッシュするらしい。クラッシュログも送ってくださったわけなんですが、どうもNSURLDownload絡みのところで落ちてるらしい。よく調べると解放済みのオブジェクトにメッセージを送ろうとしてたらしい。

NSURLDownloadには、3つのデリゲートメソッドがある。次の3つね。

1. - download:decideDestinationWithSuggestedFilename:
2. - download:didCreateDestination:
3. - downloadDidFinish:

デリゲートオブジェクトには、これらのメソッドが順に呼び出されるわけです。ていうかそうだという前提でコーディングしてたわけなんですよ。ところがですね、僕はNSURLDownloadをT2ThreadProcessingの- processThread:appendingIndex:メソッドの中で使ってたんですが、このメソッドはスレッドを1回開く時に2回呼ばれるんですよ。検証してないけど、多分ログを取得する前と後で1回づつ読んでるんでしょうね。で、そうなると先ほどの前提が崩れてしまい、運が悪いと次の順番に呼び出されてしまうわけです。

1. - download:decideDestinationWithSuggestedFilename: // 1回目の呼び出し
2. - download:didCreateDestination: // 1回目の呼び出し
3. - download:decideDestinationWithSuggestedFilename: // 2回目の呼び出し
4. - download:didCreateDestination: // 2回目の呼び出し
5. - downloadDidFinish: // 1回目の呼び出し
6. - downloadDidFinish: // 2回目の呼び出し

こうなると、話がややこしくなる。実は、- download:decideDestinationWithSuggestedFilename:の中であるオブジェクトをretainして、- downloadDidFinish:の中でreleaseしてたんです。でも上の順番で呼び出されてしまうと、最初にretainされたオブジェクトはどこからも参照されなくなり、2回目にretainされたオブジェクトも最後のメソッドが呼ばれる段階ではすでに解放済みなわけです。そしてここで解放済みオブジェクトにメッセージを送ろうとして、クラッシュ。ずいぶんと初歩的なミス

実はこのバグ、v0.1.xだけで発生する問題。v0.2では看板画像の表示を実装する際にこの部分を書き換えたから問題無し。チェックしたらメモリリークがいくつかあったけど、開いた瞬間にクラッシュなんてことはない。でも一応v0.2.1を出しといた。

Javaとかにあるガベージコレクション、よくわからないんだけど、これがあればこういうミスを防げるんでしょうかね。Objective-CもLeopardでサポートされるらしいですから、待ち通しですよ。G4で動くならば。