OS XでPharo使うときのメタキー設定

Settings browserで System > Keyboard > Control and Alt keys からメタキーの扱いを調整できる。
僕の場合、Control-Dでの文字削除を多用するので標準のままだと削除しようと思って Do-it されてすごい苦痛だった。
Handle apart を選ぶとControlとAltを区別して扱ってくれるみたい。

Objective-Cの文法はSmalltalkにヒントを得たそうだ。
その昔AppleもSmalltalk-80の処理系を売ってたんだそうで、不思議なものだねえ。
その設計のセンスみたいなものを感じたくてSmalltalkを勉強してみようと思ったのだ。

追記：テキスト編集のキーバインドを変えるという、そのものずばりのFAQがあった。ありがたい。
http://squeak.qp.land.to/wiki/index.php?Squeak%2FFAQ%2F36

追記2：テキスト編集はTextEditorクラスに変更になったみたい。ParagraphEditorは呼ばれてない。
#dispatchOn: にTranscriptを仕掛けてキー番号を見るなどしてカスタマイズしてみた。

それにしてもKeyRemap4MacBookには本当に感謝、もう俺キーバインドでない環境では生きていけそうにない。
iPhoneの開発でXcodeを使い始めたときもまずやったのはキーバインドの変更だった。

UDID廃止

あのintelでさえ、Processor Serial Number(PSN)の導入を撤回せざるを得ないぐらいだったのだから。
ただ、当時と違って固体識別は金もうけに繋がると多くの人がしっかり理解した現在では、代替の固体識別子で個人を特定するクソが出てくるのは避けられないだろうね。


承諾なく追跡されない権利を基本的人権に含めることを検討する時期ではないのか。

追記：思ってた以上にたくさんのオロオロしたコメントをネット上で見かけた。そんなデベロッパはAppStoreからもAndroid Marketからもさっさと退場させられてほしい。
DRMとからめてたとか、残念だったね(笑)。

どのNSThreadにでもperformSelector:onThread:する

iOSには performSelector:onThread:withObject:waitUntilDone: という非常にすばらしいAPIがある。指定のスレッド上でレシーバーのセレクタを実行してくれるのだ。

だからメインスレッドでUI処理をしているインスタンスなんかから、ちょっとこの重い処理やっといててな感じで別スレッドに処理を投げるのが、ものすごく簡単にできる。

waitUntilDone: のYES NO指定だけで同期・非同期も簡単に選べる。

ただし、そのスレッドでランループが回っていなければならない、という条件が付く。

このランループってのは概念としてはイベントディスパッチャであり、複数ある入力ソースのどれかが準備できるまで寝て待ちソースが発火したら取り出して処理の無限ループというフレームワークになってる。

で、入力ソースがひとつも無いとランループはループを抜けて終了してしまう。

だから単にスレッドを起動しただけではダメで、スレッド上でランループをランしただけでもダメなのだ。

このあたりを考慮にいれて、

1. スレッドを作成して
2. 発火しないダミーの入力ソースを一個ランループに取りつけて
3. ランループを回して別スレッドからの performSelector:... を待つ

ということをやってみた。

これならばいつでも performSelector:onThread: で投げた処理を受けつけてくれる。

コードはgithubに。

NSOperation使ったらどうかと思うかもしれない。このクラスは細粒度の並列では使いやすいけど、長期間生きてるリソースをもとにしたバックグラウンドサービス的な並列では制御が逆にしづらいんだよな。

UITableViewのセル選択デリゲートが呼ばれない

テーブルビューのセルが選択されてもデリゲートがなぜか呼ばれない、別のセルを選択するとひとつ前のセルが選択されたかのように振る舞う。

なぜだろう。なぜなんだっっと激しく悩んでいたが、...

tableView:didSelectRowAtIndexPath:

ではなく、

tableView:didDeselectRowAtIndexPath:

を間違って実装していた。

いや、なんちゅうか自分のミスを棚に上げてなんだが、どっと疲れた。