ありがとう。
今後ブログの更新はしないですが、過去の記録のため残しておきます。
どこで歯車が狂ったんでしょうか。
なんかGoogleと関りたくないのです。
もはや。
でも確かに輝いていました、かつては。
それでいいじゃないですか。
2012-03-06
2012-01-21
グランドセントラルディスパッチィィィ
カッコいいですね、Appleの新必殺技グランドセントラルディスパッチ
通称GCD。
勉強不足なもので、非同期処理するにはNSThreadとかNSOperationQueueとか使うもんだと思ってましたが、この新しいテクノロジであるGCDを使えば、もっとずっとシンプルに複雑なものごとを解決できます。
使わないと損です。
なので時期的には今さらですし、他のサイト見たほうがいいんですが書いときます。
たとえば重い処理をUIの裏で実行して結果が出てきたらUIに反映する。これ言うほど簡単じゃないですが、GCDなら簡単に書けます。
非同期処理がまるで同期的に書けてしまいます。dispatch_asyncと^{ }で囲むだけ!
やるべき処理の内容が複数箇所に分散しないで書けるのがいいですね。
また、performSelector:系だと渡せる引数は1個という制限が地味に面倒でしたが、ブロックで渡すのでコンテキストで見えてる値はなんでも参照できるのもありがたい。
気になったのは、dispatch_asyncの第2引数のブロックはBlock_copyされるとドキュメントにはあるのですが、そこでメモリが足りなかった場合何が起きるのでしょうか、という点。
dispatch_asyncの戻り値はvoidなのでエラーが返ることはないし...。でもBlock_copyは失敗する可能性あるだろっ、ていう。
通称GCD。
勉強不足なもので、非同期処理するにはNSThreadとかNSOperationQueueとか使うもんだと思ってましたが、この新しいテクノロジであるGCDを使えば、もっとずっとシンプルに複雑なものごとを解決できます。
使わないと損です。
なので時期的には今さらですし、他のサイト見たほうがいいんですが書いときます。
たとえば重い処理をUIの裏で実行して結果が出てきたらUIに反映する。これ言うほど簡単じゃないですが、GCDなら簡単に書けます。
- (IBAction)onClick:(id)sender {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// UIと関係なく実行できる重い処理を別スレッドでやる
NSData *data = [[HardWork new] doYourJobWithVeryHard:YES];
// 結果が出たらメインスレッドで以下の実行を依頼(UIはメインスレッドでのみ動く)
dispatch_async(dispatch_get_main_queue(), ^{
[self updateMyData:data];
});
});
}
非同期処理がまるで同期的に書けてしまいます。dispatch_asyncと^{ }で囲むだけ!
やるべき処理の内容が複数箇所に分散しないで書けるのがいいですね。
また、performSelector:系だと渡せる引数は1個という制限が地味に面倒でしたが、ブロックで渡すのでコンテキストで見えてる値はなんでも参照できるのもありがたい。
気になったのは、dispatch_asyncの第2引数のブロックはBlock_copyされるとドキュメントにはあるのですが、そこでメモリが足りなかった場合何が起きるのでしょうか、という点。
dispatch_asyncの戻り値はvoidなのでエラーが返ることはないし...。でもBlock_copyは失敗する可能性あるだろっ、ていう。
アプリケーションデリゲートをレスポンダチェインに含められるようになった
これまではアプリケーションデリゲートはこんなふうに書いてたけど、
こう書くことで、
レスポンダチェインにAppDelegateのインスタンスも参加できるようになった。
いつ仕様変更になったのかのドキュメントは見つけられなかったけど、Storyboardのドキュメントに書いてあったからたぶんiOS5以降だろう。シミュレーターでiOS4で試した場合はダメだったから。
これでnilをターゲットとしたアクションの最後のターゲットとしてAppDelegateを使えるようになる!
@interface AppDelegate : NSObject <UIApplicationDelegate> |
@interface AppDelegate : UIResponder <UIApplicationDelegate> |
レスポンダチェインにAppDelegateのインスタンスも参加できるようになった。
いつ仕様変更になったのかのドキュメントは見つけられなかったけど、Storyboardのドキュメントに書いてあったからたぶんiOS5以降だろう。シミュレーターでiOS4で試した場合はダメだったから。
これでnilをターゲットとしたアクションの最後のターゲットとしてAppDelegateを使えるようになる!
2011-10-20
スティーブ・ジョブズが死んだ
スティーブ・ジョブズとRMS
フリーソフトウェアの偉大な指導者ストールマンもジョブズの死にコメントしたそうだ。
引用の形で述べた「彼がいなくなってよかった」という言葉。
ストールマンという立場にいる人の彼なりのやり方での敬意表明なのかな、と思った。戦って勝てる相手ならいなくなってほっとする事なんかないから、わざわざ言葉にする必要がない。深読みしすぎかな。ほんとに単にせいせいしてるだけかもしれん。
自由なソフトウェアの未来ははたして現実のものとなるのだろうか。
僕はそうあってほしいと思うけど、自分が実際やってることといったらiCloudすげーとかApple信者になったりとか、なんかダメなんだよな。
ただまあ自由なソフトウェアのようにすべてが自分の制御化にあるってのは凡人にとっては結構大変なことだよ。すべて制御しなきゃいけないわけだし。
自由を失うこととひきかえに制御をまかせて楽をする道を選んでしまった。iCloudまじすげーとかそういう。
フリーソフトウェアの偉大な指導者ストールマンもジョブズの死にコメントしたそうだ。
引用の形で述べた「彼がいなくなってよかった」という言葉。
ストールマンという立場にいる人の彼なりのやり方での敬意表明なのかな、と思った。戦って勝てる相手ならいなくなってほっとする事なんかないから、わざわざ言葉にする必要がない。深読みしすぎかな。ほんとに単にせいせいしてるだけかもしれん。
自由なソフトウェアの未来ははたして現実のものとなるのだろうか。
僕はそうあってほしいと思うけど、自分が実際やってることといったらiCloudすげーとかApple信者になったりとか、なんかダメなんだよな。
ただまあ自由なソフトウェアのようにすべてが自分の制御化にあるってのは凡人にとっては結構大変なことだよ。すべて制御しなきゃいけないわけだし。
自由を失うこととひきかえに制御をまかせて楽をする道を選んでしまった。iCloudまじすげーとかそういう。
2011-10-15
俺はgmailをやめるぞーJo
iCloudとgmail(ほかgoogleアカウントでできること)とどちらも似たようなサービスだと思った。
で両方使うわけにはいかない。そんな2度手間なことあほらしくてできない。
ちょっと悩んだが....
gmailはやめた。IMAP経由ですべてiCloudのメールアカウントに転送。
chromeも捨てた。safariのブックマーク同期ならiCloudでできる。
ついでにpicasaも投げ捨てた。iphoto'11を購入してしまったぞ。フォトストリーム使いたいからな。
当然カレンダー同期もやめだ。iCalならほっといても同期してくれる。
googleとappleのクラウドへのアプローチは180度違うように思う。
appleのやり方ではクラウドは見えない操作できないサーバがどこにあるのか気にすることもない、ただユーザがアプリを使えば裏で勝手にクラウドが良きにはからってくれる。
まるで空気のようなクラウド、これでいいんじゃないかと思ったのだ。
googleのサービスからは順次足を洗っていくぞ。
あ、ちょっと待った。
投稿のプレビューして思い出したが、このブログサービスってgoogleのやつだ...
んー
で両方使うわけにはいかない。そんな2度手間なことあほらしくてできない。
ちょっと悩んだが....
gmailはやめた。IMAP経由ですべてiCloudのメールアカウントに転送。
chromeも捨てた。safariのブックマーク同期ならiCloudでできる。
ついでにpicasaも投げ捨てた。iphoto'11を購入してしまったぞ。フォトストリーム使いたいからな。
当然カレンダー同期もやめだ。iCalならほっといても同期してくれる。
googleとappleのクラウドへのアプローチは180度違うように思う。
appleのやり方ではクラウドは見えない操作できないサーバがどこにあるのか気にすることもない、ただユーザがアプリを使えば裏で勝手にクラウドが良きにはからってくれる。
まるで空気のようなクラウド、これでいいんじゃないかと思ったのだ。
googleのサービスからは順次足を洗っていくぞ。
あ、ちょっと待った。
投稿のプレビューして思い出したが、このブログサービスってgoogleのやつだ...
んー
2011-09-23
defpackageのニックネームを指定しないよう再考を
defpackageでは:nicknamesでパッケージの別名を指定できる。
でまあ、ニックネームというぐらいだから短い名前を指定してみたり、何もしなかったりと特に考えたことは無かった。
そして今日始めてニックネームが衝突した。どうやって解決すればいいんでしょう。元のソースはQuicklispでダウンロードしたものなので、それを書き換えるのは無しの方向で。
具体的にはbordeaux-threadsとbinary-typesでどっちもニックネームに:BTを使ってる。
せっかくパッケージ機能で名前空間の衝突の可能性を下げたにもかかわらず、ニックネームに短い名前を書いちゃうことでニックネームの名前空間の衝突が起きてるというバカな事態だと思った。
こんなまぬけな機能がなぜあるんだろうか。
じゃあどうすればいいのか。
まず、パッケージ機能の趣旨からしてdefpackageに指定するパッケージ名はグローバルにユニークになるように努力する。
そして、defpackageの:nicknames機能は封印して使わない。
そうすると利用者は:useでパッケージをまるごとインポートするか、グローバルユニークな(おそらく長ったらしい)パッケージ名修飾されたシンボルを使うかせざるを得なくなる。
そこで、ニックネームを自由に設定できる機能をAPIとして用意してあげればいい。
こうしてみる。
これで利用者は
もし:tstが衝突する場合は他の衝突しない名前をnickname-packageの引数として利用者側のコードで指定できるのでライブラリのコードを書き換える必要がない。
もう一点はパッケージ名をグローバルユニークにする方法について。
Java式にドメイン名を逆にするのが簡単で無難なんだろうけど、たとえばメインで開発してる組織の所属が変更になったらどうするんでしょ、って思う。
Sunが消滅した後もcom.sun.プレフィックスのパッケージはそのまま?それともリネーム?とかいう問題。
そこでPerlとかGaucheとかまわりをキョロキョロしてみる。
するとライブラリの提供する機能のカテゴリで分類して階層にするのがベターなんじゃないかと考えた。
たとえばHTTPに関するライブラリだったら、:net.rfc.http とか。
これなら開発母体に変化があっても、ライブラリ機能そのものはそうそう変化しないだろうから、将来的にも破綻しにくい。
かつ、この機能分類の方法に言語コミュニティでコンセンサスができてれば利用者側もライブラリを検索しやく、作成者側もグローバルユニークにしやすい。
自分の書くコードについては少なくともそうしてみようか、と思った。
ていうか、Common Lispでの名前衝突回避のまっとうな解決方法ってどんなもんなのか知りたい。
でまあ、ニックネームというぐらいだから短い名前を指定してみたり、何もしなかったりと特に考えたことは無かった。
そして今日始めてニックネームが衝突した。どうやって解決すればいいんでしょう。元のソースはQuicklispでダウンロードしたものなので、それを書き換えるのは無しの方向で。
具体的にはbordeaux-threadsとbinary-typesでどっちもニックネームに:BTを使ってる。
せっかくパッケージ機能で名前空間の衝突の可能性を下げたにもかかわらず、ニックネームに短い名前を書いちゃうことでニックネームの名前空間の衝突が起きてるというバカな事態だと思った。
こんなまぬけな機能がなぜあるんだろうか。
じゃあどうすればいいのか。
まず、パッケージ機能の趣旨からしてdefpackageに指定するパッケージ名はグローバルにユニークになるように努力する。
そして、defpackageの:nicknames機能は封印して使わない。
そうすると利用者は:useでパッケージをまるごとインポートするか、グローバルユニークな(おそらく長ったらしい)パッケージ名修飾されたシンボルを使うかせざるを得なくなる。
そこで、ニックネームを自由に設定できる機能をAPIとして用意してあげればいい。
こうしてみる。
自分のオリジナルの思い付きではない。Climbから拝借した。(defun nickname-package (&optional (nickname :tst))(rename-package :this.is.a.test(package-name :this.is.a.test)(adjoin nickname (package-nicknames :this.is.a.test):test #'string-equal)))
これで利用者は
(this.is.a.test:my-function)と書かなければならなかったところを
(this.is.a.test:nickname-package)と一度どこかで呼び出せば以降は
(tst:my-function)と短いパッケージ修飾で書けるので:useでインポートしなくても使えるようになる。
もし:tstが衝突する場合は他の衝突しない名前をnickname-packageの引数として利用者側のコードで指定できるのでライブラリのコードを書き換える必要がない。
もう一点はパッケージ名をグローバルユニークにする方法について。
Java式にドメイン名を逆にするのが簡単で無難なんだろうけど、たとえばメインで開発してる組織の所属が変更になったらどうするんでしょ、って思う。
Sunが消滅した後もcom.sun.プレフィックスのパッケージはそのまま?それともリネーム?とかいう問題。
そこでPerlとかGaucheとかまわりをキョロキョロしてみる。
するとライブラリの提供する機能のカテゴリで分類して階層にするのがベターなんじゃないかと考えた。
たとえばHTTPに関するライブラリだったら、:net.rfc.http とか。
これなら開発母体に変化があっても、ライブラリ機能そのものはそうそう変化しないだろうから、将来的にも破綻しにくい。
かつ、この機能分類の方法に言語コミュニティでコンセンサスができてれば利用者側もライブラリを検索しやく、作成者側もグローバルユニークにしやすい。
自分の書くコードについては少なくともそうしてみようか、と思った。
ていうか、Common Lispでの名前衝突回避のまっとうな解決方法ってどんなもんなのか知りたい。
Clozureでスレッドからの出力が出ないんですが
(bordeaux-threads:make-thread (lambda () (format t "hello~%")))とかやってもSLIMEのプロンプトに何も表示されない。
SLIMEを通さない場合は何も問題なく出力される。なんかSLIMEはEmacsとの通信のために複雑なことをしてるようだ。
~/.swank.lisp にこう書いてEmacs起動し直したら期待どおり別スレッドの出力も見ることができるようになった。
(setf swank:*globally-redirect-io* t)
printfデバッグというローテクに頼る自分には大事なことです。
2011-09-12
クラウドストレージで気を付けること
クラウドストレージで気になる事
- ローカルとクラウドの間の通信は暗号化されるのか
- クラウドに保存されるときのデータは暗号化されるのか平文なのか
- クラウドにアップする前に暗号化されるのか
- クラウドに暗号化して保存されるデータの暗号鍵は誰が持っているのか
- クラウド上に置いたデータをサービス提供者はどう使うのか
- クラウドに保管したデータはいつ消されるのか
- サービス終了したときデータを回収できるか
- サービスを終了せずあと何年続けられそうか
2011-09-10
HDD番長
HDDの故障について調べていたら面白いサイトを発見。
ハイテク製品について「あたりはずれ」や「相性」という言葉をまっこう否定するすばらしい考察がある。
http://hddbancho.co.jp/deteriorationandmeasuresof_hdd.html
まあつまりHDDは熱と熱変化に極端に弱いということらしい。
僕としてはこのHDDという物理デバイス自体をもう持ちたくないと思ったよ。
読めば読むほど、HDDってのはごく普通の家庭では壊れてあたりまえの製品だ。
そんな毎日運を試すようなものに自分のデータを置いときたくない。
ハイテク製品について「あたりはずれ」や「相性」という言葉をまっこう否定するすばらしい考察がある。
http://hddbancho.co.jp/deteriorationandmeasuresof_hdd.html
まあつまりHDDは熱と熱変化に極端に弱いということらしい。
僕としてはこのHDDという物理デバイス自体をもう持ちたくないと思ったよ。
読めば読むほど、HDDってのはごく普通の家庭では壊れてあたりまえの製品だ。
そんな毎日運を試すようなものに自分のデータを置いときたくない。
2011-09-08
2011-08-25
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を使い始めたときもまずやったのはキーバインドの変更だった。
僕の場合、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を使い始めたときもまずやったのはキーバインドの変更だった。
2011-08-21
UDID廃止
あのintelでさえ、Processor Serial Number(PSN)の導入を撤回せざるを得ないぐらいだったのだから。
ただ、当時と違って固体識別は金もうけに繋がると多くの人がしっかり理解した現在では、代替の固体識別子で個人を特定するクソが出てくるのは避けられないだろうね。
承諾なく追跡されない権利を基本的人権に含めることを検討する時期ではないのか。
追記：思ってた以上にたくさんのオロオロしたコメントをネット上で見かけた。そんなデベロッパはAppStoreからもAndroid Marketからもさっさと退場させられてほしい。
DRMとからめてたとか、残念だったね(笑)。
ただ、当時と違って固体識別は金もうけに繋がると多くの人がしっかり理解した現在では、代替の固体識別子で個人を特定するクソが出てくるのは避けられないだろうね。
承諾なく追跡されない権利を基本的人権に含めることを検討する時期ではないのか。
追記：思ってた以上にたくさんのオロオロしたコメントをネット上で見かけた。そんなデベロッパはAppStoreからもAndroid Marketからもさっさと退場させられてほしい。
DRMとからめてたとか、残念だったね(笑)。
登録:
投稿 (Atom)