NSAttributedString に lineSpace を付与したとき、1行であるにも関わらず lineSpace が下端に付与されて困っている人はこれを読んだら直ります

突然ですが皆さん、NSAttributedStringには2017/03/07付のiOS 10.3現在でも致命的にバグっている箇所があります。

症状:

• NSAttributedStringにNSParagraphStyleAttributeNameを利用してNSParagraphStyle経由でlineSpaceが付与されている。
• NSAttributedStringに複数の「区間」が存在する。例えばNSAttributedString全体が単一のAttributeによって構成されているときはこの問題は発生しません。2つ以上の異なるAttributeの区間が必要です。
• NSAttributedStringを描画するときに、横幅及び文字列の長さの都合で、1行で描画される。複数行になるときにはこの問題は発生しません。
• NSAttributedStringにNSBackgroundColorAttributeNameが付与されていない。または、NSBackgroundColorAttributeNameとNSKerningAttributeNameの両方が付与されている。

上記の条件を全て満たすとき、

本来、1行の文字列はレンダリングしたときに下端にlineSpaceが付与されてはいけませんが、この条件が満たされていると下端にlineSpaceが付与されてしまいます。先頭の画像の左上のケースがこの問題に相当します。

具体的な問題としては、

• 問題が発生するNSAttributedStringを使用したUILabel, UITextField, UITextViewの描画内容が思いっきり上にずれます（下に無駄なスペースが発生するので）
• NSAttributedStringの地点で壊れているので、Core Textを利用したり、boundingRect(with size: CGSize, options: NSStringDrawingOptions = [], context: NSStringDrawingContext?) -> CGRectを使っても一切回避できません

解決策: 

この問題に対する正しいワークアラウンドの方法は一つしかありません。

NSAttributedStringの全Attribute区間にNSBackgroundColorAttributeNameを付与し、かつどの区間にもNSKerningAttributeNameを付与しない。

背景色が不要の場合はUIColor.clearでも付与してごまかしてください。

以上です。よろしくお願いします。

参考:

• この問題の発端、一番わかり易い図説がある、誰も正しい回答を示せていない
• http://stackoverflow.com/questions/23575958/uilabel-size-incorrect-for-single-line-of-text-with-linespacing-and-multiple-col
• もう一つの例、カスタムフォントが悪いということにされているが、カスタムフォントは一切関係ない、システムフォントでも発生する
• http://stackoverflow.com/questions/32291105/line-spacing-for-uilabel-with-a-single-line-of-text
• 最後の例、この例によって「背景色があれば問題が発生しない」「カーニングを付与すると背景色があっても問題が再発する」ことが示され、この問題の正しい解決策が得られた
• http://stackoverflow.com/questions/32216700/uilabel-with-paragraph-style-line-spacing

CALayer を使って UIImage を描画する

UIImage を高速で描画する必要がある案件に遭遇したため、 CALayer を使ってみました。 CALayer と聞くとなにやら難しい感じがしますが、実際に使ってみると非常に簡単で高速です。

CALayer を使うと良い場面は以下のような場合です。

• 画像を大量に描画する必要がある
• 画像を高速に描画する必要がある
• 画像を高速に変形・移動する必要がある
• CGContextDrawImage を今使っている箇所がある

とくに変形に対して非常に強いです。 CGContextDrawImage で変形後の UIImage を再度描画し直したりするのに比べると、 CALayer の変形は格段に高速に動作します。


■実際に描画してみる

まず最初に <QuartsCore/QuartsCore.h> をインポートします。 QuartzCore.framework をプロジェクトに追加するのも忘れないようにしましょう。

準備ができたので描画します。 CALayer.contents プロパティに CGImageRef を渡すと後は全部勝手にやってくれます。簡単でしょ？

- (void)viewDidLoad {
    // UIImage* 型のプロパティ self.image があると仮定して・・・
    CALayer *l = [CALayer layer];
    l.contents = self.image.CGImage;
    l.position = CGPointMake(255, 255) // l.position はデフォルトではレイヤー中央の座標になります
    [self.view.layer addSubLayer:l];
}

CGContextDrawRect のような Core Graphics (Quartz) の関数を使用すると、座標系が左下基準になるため、 UIImage を描画する際にコンテキストの上下を反転してやらないと画像が上下反対に表示されてしまう問題がありますが、 CALayer はこの座標系の差異も勝手に考慮に入れてくれるので、 UIImage の CGImage プロパティをそのまま渡すだけでよく、ラクチンです。


■アニメーションしてみる

もともと CALayer は Core Animation フレームワークのクラスですから、当然アニメーションにも対応しています。といいますか、何もしないでそのまま CALayer のプロパティを変えると勝手にアニメーションします。 http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CoreAnimation_guide/Articles/AnimatingLayers.html の Animation > Implicit Animation あたりに記載されている内容がそれです。

// 既にこの l が addSubLayer されている場合、
// これだけで勝手にアニメーションします
l.transform = CGAffineTransformCreateScale(1.1, 1.1);

が、ときどきこのアニメーションが邪魔になる場合があります。そんなときは

// CATransaction というクラスを使用して, 一時的にレイヤーのアニメーションを切ります
[CATransaction begin];
[CATransaction setValue:(id)kCFBooleanTrue
                 forKey:kCATransactionDisableActions];
[aLayer removeFromSuperlayer];
[CATransaction commit];

// CATransaction というクラスを使用して, 一時的にレイヤーのアニメーションの時間を変化させます
[CATransaction begin];
[CATransaction setValue:[NSNumber numberWithFloat:10.0f]
                 forKey:kCATransactionAnimationDuration];
theLayer.zPosition=200.0;
theLayer.opacity=0.0;
[CATransaction commit];

こんな具合でアニメーションを調整できます。


■まとめ

たったのこれだけで画面上に高速でアニメーションもできる画像を描画することができます。お絵かきソフトなどで、画面上にユーザーが任意の画像を挿入できるようにしたい、と言ったときに大変役立ちますのでおすすめです。是非試してみてください。

iOS 開発者が Android 開発者になるために用意したものまとめ

これまでiOS 2.0の登場から今日に至るまでiOS開発者として仕事してきたわけですが、今年はいよいよ本格的に仕事でAndroidの開発を行っていきたいと思っています。そこで正月休みを使って準備したAndroidの開発環境や勉強用の資料をまとめてみました。同じく今年からAndroidやってみよう！という方の助けになればと思います。

■前提条件

まず最初に前提条件として筆者のスペックをまとめてみました。

• iOS開発歴4年ぐらい (iOS 2~7)
• Android開発歴半年ぐらい (Android 1.5~2.1の間、仕事では殆ど使ってない）
• Java歴は3年ぐらい (大学時代と最初の会社でSIerをやっていた間、SJC-P所持だがJava 7とか8とかはわからない)

iOSの開発歴が長く、モバイル開発で必要な要素や落とし穴などをひと通り踏んでいること、少しですがAndroid開発歴があること、Javaについてもひと通りの文法がわかるのを前提としています。従いまして完全にモバイル開発もJavaも初めてという方にはおそらく今回の資料は少しハードルが高過ぎると思います。ご了承ください。

特にJavaについてはどの資料も何の説明もなしに匿名クラスや内部クラスをふんだんに利用するので、最低限Javaの事前勉強をしておいたほうが良いかと思います。

■開発環境の用意

今回はMac上にAndroid Studioをインストールする方針でいきます。
http://developer.android.com/sdk/installing/studio.html
Eclipse+ADTな現場もまだまだ多いかと思いますが、今後は間違いなくAndroid Studioが主流になってくると思われるからです。あとは個人的にEclipseが嫌いというのもあります(´･_･`)

インストール時の注意点としては初回起動時に少々時間がかかるのと、アップデートが必要になる程度です。0.3.2から0.4にアップデートする前にプロジェクトを作ってしまうとアップデート後にビルドが通らなくなってしまったので、最初にまずアップデートすることをオススメします。

Android StudioではEclipse+ADTの環境や、旧来のJava開発とは異なりGradleというビルドツールが何をするにも主体となります。そのためGradleについてある程度の知識が必要となります。幸いにしてWeb上に良い記事がありましたのでこちらを参考に勉強しました。

• Android Studio最速入門～効率的にコーディングするための使い方: http://gihyo.jp/dev/serial/01/android_studio

■シミュレータの用意(Genymotion)

ADTには最初からAndroidエミュレータが付属されていますが、これは残念ながらiOSのシミュレータとは異なり、再現度も悪く異常に動作が遅いため使い物になるシロモノではありません。Android SDK 1.6のころから現在4.4に至るまで全く改善の気配が無いため、おそらく未来永劫改善は望まれないと思われます。その代わりと言ってはなんですがGenymotionというサードパーティ製の非常に使い勝手の良いAndroidシミュレータがありますのでこちらをインストールします。
http://www.genymotion.com

アカウントを作成してFree版をダウンロード・インストールします。Free版と有料版の違いは加速度センサーのエミュレーションや、スクリーンキャスト機能の有無程度なので、Free版でまったく問題ありません。Genymotionの起動にはOracle VirtualBoxが必要になるため、https://www.virtualbox.orgからダウンロードしてインストールしておきます。

最後にAndroid StudioのGenymotionプラグインをPreferences -> Plugins -> Brows RepositoryからGenymotionで検索してインストールして完了です。

■開発機の用意

Genymotionだけでもかなりの開発はできますが、やはりモバイル開発では実機上での確認が必須です。特にAndroidはiOSと異なり端末種類が多い上に端末差異が激しいので、出来る限り多くの実機を用意しておくことが望ましいです。またそれだけではなく、実際に日常生活でAndroidを触り多数のアプリに触れておくことで、Android上でのアプリの作法や最近の流行、iOSとの違いなどを肌で学ぶことができます。

開発用の端末は白ロム（中古品）販売店で安く買うのが良いと思います。通販でも購入可能です。
http://masterka.seesaa.net/article/252845343.html

ですが今回は折角なので最新機種Nexus 5をGoogleから直接購入することにしました。

https://play.google.com/store/devices/details?id=nexus_5_black_16gb

こちらから直接SIMロックフリーのNexus 5を通販することができます。私の場合は1/1に16GB Whiteを注文して1/5に届きました。正月でなければもうちょっと早かったかもしれません。

届いたら開封して起動すればそのまますぐに使えます。iPhoneと異なりSIMがアクティベーションに必要だとか、iTunesと接続を要求するとかそういう内容は一切ありませんので、SIMを購入しなくても開発機として使用可能なのがいい感じです。ただし最初の言語選択とWiFi接続時のエラーメッセージが非常に不親切なのでちょっとハマりました。

Nexus 5を使ってみての感想ですが、正直信じられないぐらい良いです。Android 2.x時代のダメダメ端末ばかり触っていたのでギャップが大きいというのも有りますが、電池の消耗がiPhoneと比べると激しい以外は欠点らしい欠点が見当たりませんし、余計なものが一切入っていないのでAndroidの長所を存分に味わう事ができます。iOS開発者の人でAndroid開発に手を出したい人にはまずオススメしたいです。

そのままSIMなしで開発機として使っても良かったのですが、3G回線でのテストも行いたかったので、今回はさらにMVMO業者のSIMパッケージを購入しました。初期費用3000円、月額1000円以下、二年縛り無しでSIMが手に入るため非常に安価で便利です。

• 楽天ブロードバンド: http://broadband.rakuten.co.jp/lte/cpn-entry.html
• 日本通信(b-mobile): http://www.bmobile.ne.jp/zsim/
• u-mobile: http://mobile.unext.co.jp/umobiled/
• OCN モバイル One: http://service.ocn.ne.jp/mobile/one/

などがありますが、今回はOCN モバイル Oneを選択しました。

■Hello World!

さて開発環境も開発機も手に入ったので、あとはコードを書くだけです。最初はまず以下のWebサイトを参考資料に簡単なTwitterクライアントアプリを書いてみました。

• Android Studio最速入門～効率的にコーディングするための使い方: http://gihyo.jp/dev/serial/01/android_studio
• Android再入門 - Twitterクライアントを作ってみよう: http://qiita.com/gabu/items/70689560618f8e67e726

やはりモバイルアプリ開発の手習いはTwitterクライアントアプリからスタートするのが良いと思います。データのリスト表示、非同期通信、画像の非同期読み込みとUIへの反映、一覧と詳細表示など、モバイルアプリに必要な要素がバランスよく学べます。

■購入した書籍

Webの資料も悪くないですが、やはり最初は書籍を読みながら進めるのが情報がまとまっていて近道だと思います。というわけで以下の書籍を購入しました。すべて達人出版会の電子書籍で手に入るため便利です。

• Google Androidプログラミング入門改訂2版: http://tatsu-zine.com/books/androidprogramming2ed
• 入門に必要な内容はひと通り網羅されていると思います。ただし入門書を名乗っていますが、途中からサンプルプログラムが手元にあること前提の説明になったり、コードの一部が説明されていなかったり、Javaがわかること前提のコードが登場したりなど難易度が急激に跳ね上がるので、本当の本当に入門な人には向かないと思います。
• Effective Android: http://tatsu-zine.com/books/effective-android
• Effective系は外れないと思って購入しました。Effective Javaも名著でしたしね。
• Android UI Cookbook for 4.0　ICS（Ice Cream Sandwich）アプリ開発術: http://tatsu-zine.com/books/androiduicookbook40
• 4.0でUI周りは大きく変わっているので、2.3との互換性維持のノウハウも含めて欲しかったので購入しました。iOSの手習いの時もObjective-Cの本とUIKitの本を選びましたが、最初は言語の本とUIフレームワークの本を選ぶのが良いと思います。
• Android Security 安全なアプリケーションを作成するために: http://tatsu-zine.com/books/androidsec
• 仕事でAndroidを使うつもりなのでセキュリティ周りの情報は必須です。セキュリティに関してはiOSよりも更に環境がシビアですので、念には念を入れておきたいです。

メモ: CoreDataで更新処理をするときは、lockをわすれずに

単なるメモ書きです＞＜

http://twitter.com/#!/akisutesama/status/83521489382555650
http://twitter.com/#!/akisutesama/status/83521729380626433

ある一つのCore Dataのモデルを非同期的に複数箇所から更新するときは、たとえどんなに軽微な、プロパティ一つだけの、他からは触られない様な変更ですら、きちんとlockを取らないと危険ということがわかった。API実行クラスだけでは不十分であった。非同期であればロック必須。

変更を行うコードブロックを渡して、内部で安全にロックして実行、必要に応じてロールバックや失敗通知も行える様にする仕組みを作ろうと思った。

CoreDataのモデルオブジェクトの更新はただのsetterプロパティの使用だけで発生してしまうのでついつい忘れがちになるのですが、これが原因で実際にクラッシュしたアプリもあるので油断禁物。

MacPortsを使って、Pythonの開発環境を整えてみた

ここ最近勉強会続きだったため、複数のバージョンのPythonの開発環境の整備をする必要に迫られました。
まずはPython2.6.2をインストールしようと考えたのですが、python.orgからdmgでダウンロードしてインストールすると余計な物をたくさんインストールされてしまいますし、何より環境の切り替えが大変です。
（Mac付属の2.5.1でないとDjangoがエラーを吐いたりするため、いつでも2.5.1に切り戻せるようにしたい）

そこで今回はMacPortsを使って開発環境を整えてみました。

■Pythonのインストール
これはMacPortsから以下のコマンドを実行するだけでいけました。

sudo port install python26

ただ、依存するモジュールが非常に多いためビルドに大変時間がかかりました。MacBook Airで、およそ1時間ぐらい。
これで/opt/local/Library/Frameworks以下にPython.frameworkがインストールされるのですが、インストールしただけでは自由に元々存在するPython 2.5.1との切り替えができません。
そこで、同じくMacPortsで提供されている、python_selectというスクリプトをインストールします。

sudo port install python_select

インストールしたら、以下のようにして自由にPythonのバージョンを切り替えることが出来ます。

$ python_select -l #利用可能なバージョン一覧を表示
Available versions:
current none python25-apple python26
$ python_select python26 #python2.6に切り替え

こいつは大変便利です。

■Djangoのインストール
DjangoもMacPortからインストールできます。

sudo port install py26-django

Djangoだけではなく、jinjaやSQLAlchemy, Werkzeugなど、名前の知られているPythonのフレームワークはすべて存在しているようです。とっても楽ちん。
ちなみにインストールできるportとしてpy25-djangoのようにPythonのバージョンを指定しているものと、py-djangoのように指定していないものがありますが、py-djangoをインストールしようとすると突然Python2.4をインストールしようとしやがりましたので、基本的にはPythonのバージョンを指定しているportを選んだ方が良さそうです。

さて、MacPortでインストールしたPythonのためにDjangoをインストールするのは簡単でしたが、
問題になってくるのは元々標準で入っているPython2.5.1のためにDjangoをインストールするときです。
easy_installが使えるようなので、今回はeasy_installを使ってインストールしました。

sudo easy_install django

ただしportと比較すると後からアンインストールするのが面倒だという欠点があります。portが使えるならportがいいですね。

■PILのインストール
PILのインストールも基本はMacPortで。

sudo port install py26-pil

問題はPython 2.5.1にインストールするときです。私の環境では、easy_installが失敗してしまい簡単にインストールできませんでした。
悩んだあげく、PILのウェブページからPython Imaging Library 1.1.6 Source Kitをダウンロードし、直接setup.pyを実行して解決しました。

tar zxvf Imaging-1.1.6.tar.gz
cd Imaging-1.1.6
sudo python setup.py install

TestFlight 経由のアプリのダウンロード速度を調べてみた

最近 iOS 界隈を賑わせている TestFlight というWebサービスがあります。詳細についてはまぁ TechCrunch さんでも読んでいただくとしまして、この TestFlight が非常に便利そうなので私のほうでも早速試してます。登録も簡単、アプリのマネジメントも良くできていますし、チームを複数用意して管理できるというのも良いです。なんで Apple がデフォルトでこれを用意してくれないのかというぐらい便利です。

が、一つだけ気になったことがあって、まぁタイトル通りなのですが、TestFlight経由だとアプリのダウンロードが遅いのではないか？ということです。ということで実際にやってみました。


■条件

対象のアプリのサイズは17.7MB。
以下の2カ所の回線で計測しました。

• 会社の回線（確かバッファロー, IEEE 802.11g, だいたい300KB/s程度)
• 自宅の回線（AirMac Extreme, IEEE 802.11n, だいたい1MB/s程度)

■結果

会社の回線・・・ダウンロードに12分~15分程度
自宅の回線・・・ダウンロードに1分前後、インストール完了まで2分ちょっと

それぞれ別の日に計測したので何とも言えませんし、会社の回線は自分以外の人も使うので遅いときがあるのですが、およそ

遅いとき・・・20KB/s程度
早いとき・・・300KB/s程度

とまぁずいぶん幅がある結果になってしまいました。どうやら時間帯や相手のサーバー側の混雑具合によっても速度が違ってくるようです。いずれにせよそんな猛烈に速いわけではないので注意が必要そうです。たとえば100MBぐらいあるゲームアプリをテストしたいときなどは、今まで通りの地味な配布のほうがよい・・・ということもあるかも。


■余談：TestFlightってどれぐらいのファイルサイズまでアップロードできるのか？

と思って調べてみたらありました。500MBだそうです。400MBのファイルを実際にアップした人がいるみたいです。
http://support.testflightapp.com/discussions/questions/60-max-file-size-on-build-upload

canvasとJavaScriptでゲームなど(2) タイトルつけてみました

http://akisuesandbox.appspot.com/games/zzz
（前回とパスが変わってます、注意）

前回のゲームに悪のりしてタイトルをつけてみました。

ついでにソースコードも公開してみました。まぁ、JavaScriptなので意図しようとも意図すまいとも自動的にオープンソースになってしまいますけれども、一応ｗ
http://github.com/akisute/gae_akisutesandbox/tree/master

---

以下、余談。

ゲームの画面を制御するにはループと入力受付を制御しなくてはならないのですが、
JavaScriptを用いると、
ループの制御はsetIntevalとclearInterval
入力受付の制御はhogehoge.onmousemoveとかhogehoge.onmousedownに適切なファンクションをセットする
ことで制御が出来るので比較的簡単な気がします。

すごーく昔にDirectXでプログラムを作ったときに
このあたりの制御をするのが余りにも面倒で（といいますか手続き型のプログラミングが面倒で）嫌になって辞めてしまった記憶があります。

最近のゲーム開発環境はどうなんでしょう。特にiPhoneのゲーム開発フレームワークとか大いに気になります。

iOS開発でエラーコードを調べるときはOSStatus.comを使おう

久しぶりに書く価値のあるネタが見つかったのでご紹介します。

iOSのフレームワークがNSErrorを返してきたとき、そのcodeが何を意味するのかを調べる必要が出てくることが往々にして発生します。新し目のフレームワークは比較的簡単に調べられるようにまとまっているのですが、厄介なのがOSStatusなどの大昔から存在するエラーコードの場合です。

NSError コードの調べ方 こちらのブログ記事で紹介されている通りに一つ一つヘッダファイル内を探す方法でもいいのですが、もはや平成の終わりが目の前に迫っている2018年の年の瀬にもなってこのような原始的な方法を使っているようではよろしくありません。

そこで OSStatus.com の出番です。こちらの検索欄にcodeをコピペして検索ボタンを押すだけであらゆるエラーの詳細が一発で帰ってきます。実際にやってみましょう。

一発ですね。素晴らしい。

名前での検索もバッチリです。

偶然見つけたのですが、はてブもほとんどついてないし、ネット上で紹介されている記事も全く見つからなかったので書いてみました。便利です！

第2回 Google App Engine Hackathon

• 今回で第2回目
• 主催は@tmatsuoさん
• 4チーム（内部でさらに分かれるため合計6チーム）に分かれて作業をし、最後に発表する形式
• 1回目よりも運営が格段にスムーズで素晴らしい時間を過ごせた
• GDataの認証はすさまじく難しい。またGDataアクセス用のライブラリがあるが、これまた非常に機能が多く難しい
• Google App Engine Oilは凄く良い、余計なことをしないし必要な者は全部作ってくれる
• gaeogenはバージョン0.21の地点ではバグがあるためまともに機能しない
• DropBoxを使ったグループ開発はすさまじいスピード感がある

http://groups.google.co.jp/group/google-app-engine-japan?hl=ja
ちょっと遅くなりましたが、2008年12月13日に開催されました第2回 Google App Engine Hackathonについてご報告です。

主催は前回に引き続きGoogleの認定エキスパートである@tmatsuoさん。
前回は好き勝手にGAEで物を作るだけという感じだったのですが、今回は趣向を変えて、

• チュートリアル：RSS Reader作成
• チュートリアル：Twitterもどき作成
• GDataを用いたマッシュアップ：Bloggerなどとマッシュアップする組
• GDataを用いたマッシュアップ：Picasaなどとマッシュアップする組
• フレームワーク
• データモデル

以上の6組に分かれてそれぞれ活動し、結果を最後に発表すると言う形式で行われました。
目標がはっきりしていたおかげで、最後にはものすごいアプリが次々飛び出しました。大成功だったと思います！
運営の皆さんありがとうございました！
前回に引き続きお弁当おいしかったです =)


詳細につきましてはHiiroさんのブログをご参照ください。
Hiiro_memo: GAEハッカソン参加感想＆まとめ：Google凄いが周辺人も凄い


私はマッシュアップ班に参加いたしました。
ちなみに隣の席が世界に名だたるおっぱいプログラマー@technohippyさんでした。びっくりです。
Da変態な人かと思っていたら、意外と普通の人でした。Vistaに泣かされていましたけど。

今回のマッシュアップ班の開発の際には、DropBoxに全員のプロジェクトファイルを配置して、いつでもみんなのファイルを参照できるようにして作業しました。
コレが凄くいいです。誰かが一人難所をクリアできれば、すぐにみんながそのソースを参照して動かせるように出来たため、作業効率が格段に良かったです。
（共有する人はコミット作業すら必要ありません。全部自動的に同期してくれるから）

さっそくDropBoxが大のお気に入りになりました。Windows機にはあまり導入したくなかったのですが、
こんなに便利なら使うしかないですね。


また、噂のGoogle App Engine Oil（GAEO）も試してみました。

gaeo testproject

とすると、testprojectを作成してくれるのですが、コレが素晴らしい！
最初から絶対に必要になるjs, img, cssフォルダを作成してくれたり、faviconの設定もしてくれたり、かゆいところに手が届く感じです。
RequestHandlerの実装も非常に簡単になっていて、

class WelcomeHandler:
  def index(self):
      #get All models from DataStore
      models = AModel.all().fetch()
      #set models to self object to use it when rendering the template
      self.models = models

たったのこれだけで、テンプレートのレンダリングまで全部自動でやってくれます。

本当はgaeogenというrailsのscaffoldのような機能があるのですが、こちらは0.21の段階ではバグがあるようでまともに機能しませんでした。
（ソースを参照したところ、argvに対してgetメソッドを呼び出したりしていました。
Pythonのargvはlist型だからdict型にしか使えないgetメソッドは利用できないです）
でもgaeoだけでも十分すぎるほど便利ですから導入する価値は有りだと思います。

lipo を使って簡単に Universal Binary を作成する方法

iOS 向けのライブラリやフレームワークは、よく static library (.aファイル) の形式で配布されています。これは iOS がユーザーが作成した dynamic library (.dylibファイル) や framework バンドルをサポートしていないからなのですが、ときどきこの static library がシミュレーターとデバイス両方で使える形式、いわゆる Universal Binary になっていない場合があります。

たとえばこんな感じですね。



この状態でビルドを行うと、シミュレーター向けビルドを行えばデバイス用のバイナリが、デバイス向けビルドを行えばシミュレーター用のバイナリが、それぞれ対応していないアーキテクチャであると警告を出してしまいます。警告ですからコンパイルは通るのですが、私は几帳面で気になってしまうので、これを解消したいと考えます。


■lipoの出番

そこで lipo を使います。 lipo は Xcode に付属されているコマンドラインツールですので、 iOS SDK をインストールしている人でしたら誰でも使えます。詳しい使い方は man を見ていただければわかりますが、普通使うのは以下のパターンだけです:

lipo -create ライブラリ1.a ライブラリ2.a -output 出力するライブラリ.a

たったのこれだけで二つのライブラリを組み合わせて Universal Binary を生成してくれます。さっきの画像の例ですと、

lipo -create libAbesi_dev.a libAbesi_sim.a -output libAbesi.a

これでOKです。


■本当に Universal なの？

それでは本当に Universal Build になったのか見てみましょう。 static library の中身を見るには、 nm コマンドを使います。



どうやらうまくいったみたいですね。一つのライブラリファイルの中に、3種類のアーキテクチャに対応したオブジェクトが格納されています。

Swift を使ってみてがっかりした点まとめ

数日間iOS8/Xcode6/Swiftな環境で色々試してみて、Swiftを使っていて思ったよりがっかりした点が多かったのでちょっとまとめてみようと思います。

動的な処理がSwiftだけでは一切できない

[NSObject performSelector:]の類と、NSInvocationがSwiftからは一切呼び出せません。使おうとすると怒られます。objc/runtime.hは試していませんが、同様に直接Swift経由では呼び出せず間にObjective-Cをかます必要があるのではないかと思われます。

@optionalなprotocolが限定的にしか使用できない

具体的には@objc属性を付けないと使えません。しかしながらこのような後方互換性のためだけに存在する属性をいつまでもAppleがサポートするかは疑問が残るというのと、もう一つ以下の様な問題があります。

@objc属性のついたSwiftの型はただのObjective-Cクラスになる

@akisutesama @hironytic 通常のクラスのメソッド呼び出しは vtable 方式で、NSObject のサブクラスや、@objc を付けたものは Objective-C の動的ディスパッチになるようですね。 https://t.co/WWWp9nZRZZ
— Hoshi, Takanori (@hoshi_takanori) June 5, 2014

こういう問題があるのであまり使いたいとは思えません。ちなみになのですがCocoaのクラスはほぼすべて@objc属性が付いているため、それを継承して使うことになるアプリでは事実上Swiftの本来の能力を出せないのではないかと思っていますが、実際のところはわかっていません・・・

メモリ管理が相変わらず必要

Swiftのメモリ管理はGCではなくARCでありただの参照カウント方式にすぎないため、Swiftでも循環参照が発生しないようにプログラマが明示的に参照の種類を指定しなければなりません。その上Objective-Cでも存在したstrong, weakに加えunownedという新しい種類のメモリ管理が追加されています。これはweakは参照が消滅するとnilにするという挙動であるためOptional型を使わなければならないのに対し、unownedは参照が消滅してもnilにならない代わりに通常の型がそのまま使えるというもののようです。

closureでselfをキャプチャするときの循環参照対策が相変わらず必要

いちばんがっかりしたのがこれです。Swiftはdelegateよりもclosureを使ったcallbackのほうが言語構造上向いているためclosureを大量に使うことになると思うのですが、このときselfがclosureを強参照し、closureがselfをキャプチャするようなコードを書いてしまうと、循環参照になるためメモリが開放されなくなるという問題がObjective-Cから引き続き発生します。対策としてclosure capture listと呼ばれる新たな構文が追加されています。closureの先頭、引数宣言の前に[unowned self]のような構文を追加することで、selfをunownedとしてキャプチャすることができます。

以下に使用前・使用後の例を示します。

Objective-CのweakSelfよりはマシに思えますが、とはいえこの辺りはコンパイラが自動的に対応してほしいところです(´･_･`)

アプリのクラッシュ検知・クラッシュレポート系ライブラリを調べてみた

アプリのクラッシュを検知したり、クラッシュレポートを作成したりするライブラリやサービスを試してみたくなったので色々調べてます。まだ実際に検証できていないので主に自分用メモです。

■なぜクラッシュ検知なのか？

以下の様なメリットが考えられます。

• アプリのクラッシュを100%絶対完全に阻止する方法は無い。どんなアプリでもクラッシュする可能性がある。
• 開発者のメリットとして、クラッシュ時に詳細なクラッシュレポートやクラッシュログを数多く収集することができれば、迅速確実な修正が可能になり、結果としてユーザーのメリットに繋がる。
• ユーザーのメリットとして、クラッシュを検知して即座に編集中データが失われないよう退避したり、次の起動時に同じクラッシュが発生しないようセーフモード起動するなどの措置を開発者が取ることができるかもしれないので、利便性向上につながる。
• アプリを通じたサービス提供者のメリットとして、カスタマーサポートに飛んでくる何の付加価値もない「動きません」「落ちます」といった苦情を具体的に解決しやすくなり、カスタマーサポート品質を高めたり要員コストを削減したりすることが可能になるかもしれない。
• ゲームなどでは、例えばクラッシュが発生したら、次の起動時に1つのバージョンに付き1回だけ自動的に詫び石が配られる仕組みなどを作ることができるかもしれない。ゲームのキャラクターにごめんなさい＞＜と謝らせるとなおグッドかもしれない。

逆にデメリットもあって、例えば

• クラッシュ検知の仕組みが入ることで動作がかえって不安定になるおそれがある。SDK自体が問題を起こすなど。
• クラッシュ検知の際に対応して行う処理がかえって致命的な問題を起こすリスクもある。exception handlerやsignal handlerを捕まえて検知する仕組みのため、それらを利用している他のSDKなどと競合するおそれがある。
• 当然それらの機能の分だけ実装とQAと保守のためのコストが上がる。
• 特にプロプライエタリなサービスのものに関しては会社の方針で導入ができないことがある。

メリデメをよく考えて導入する必要がありそうです。

■サービスとして提供されているもの

以下のページのまとめが詳しいです。
http://www.raywenderlich.com/33669/overview-of-ios-crash-reporting-tools-part-1

Crashlytics
http://try.crashlytics.com

Crittercism
https://www.crittercism.com

Bugsense
https://www.bugsense.com

TestFlight (クラッシュ検知以外の方が有名)
https://www.testflightapp.com

HockeyApp (クラッシュ検知以外の仕組みもある)
http://hockeyapp.net

■オープンソースなもの

KSCrash (iOS)
https://github.com/kstenerud/KSCrash

ACRA (Android)
https://github.com/ACRA/acra

実際に使ってみてまたレポートなど書いてみようと思います。

Byline 3 ヘルプ と Tips

Byline 3 のちょっとした日本語ヘルプとTipsをこちらに掲載しようと思います。

※2010/05/11よりBylineの日本公式アカウント @bylinejp を開設しましたので、是非ご活用ください。


■メインフォルダって何？

設定画面の同期セクションにあるメインフォルダという設定。これは、簡単に言えば Bylineで表示するフォルダ です。デフォルトでは「すべてのアイテム」になっています。この状態だと、 Google Reader 側にあるすべてのフォルダがBylineと同期されて画面に表示されます。メインフォルダを設定することで、 Google Reader 側の指定されたフォルダのみをBylineと同期して表示する事ができます。一部のフィードのみを同期したい場合に有効です。

注意点として、 一度に指定できるメインフォルダは一つだけ です。


■Webページのキャッシュ設定について

設定画面のキャッシュセクションにあるWebページという設定。こちらの内容が少々難解になっているので解説したいと思います。

• モバイル向けデザイン
  この設定をONにすると、外部Webサービスを使用して対象のWebページのコンテンツを「モバイル向けデザイン」に変換してキャッシュします。モバイル向けデザインにすると、CSSが除去されたり、イメージが除去されたりリサイズされたりします。また、全体的に縦長なデザインになり、モバイルデバイスで読みやすい形式になります。
• 自動でキャッシュするコンテンツ
  メインフォルダ、スター付きアイテム、メモのうち、同期時に自動的にキャッシュするものを選択します。画像はメインフォルダが「すべてのアイテム」にセットされている場合の物ですが、メインフォルダを変更するとここの名前も変化します。この設定項目をONにした場合、以下のようなポリシーでキャッシュが行われます。
  • メインフォルダに含まれるフィードは、次の「フィードごとのキャッシュ設定」で設定した内容に従ってキャッシュされます。
  • スター付きアイテムに含まれるフィードは、すべてのフィードがキャッシュされます。
  • メモに含まれるフィードは、すべてのフィードがキャッシュされます。

• フィードごとのキャッシュ設定
  メインフォルダに含まれるフィードのキャッシュポリシーを設定します。 この設定が適用されるのはメインフォルダに含まれるフィードのみです。 スター付きアイテムおよびメモには適用されず、常にすべてのフィードがキャッシュされます。
  一覧にある各フィード名をタップすると、以下の三つの状態が順番に変化します。
  • 無印（デフォルト状態）
    本文が意図的に削られていると判断されたアイテムのみを自動的にキャッシュします。すべての本文が含まれているアイテムはキャッシュしません。
    本文が意図的に削られているアイテムというのは、たとえば このような ニュース本文全体を乗せない RSS フィードの記事のことです。
  • √マーク付き
    本文が削られているか否かに関わらず、常にキャッシュします。
  • ×マーク付き
    本文が削られているか否かに関わらず、常にキャッシュしません。
  また、右側の図にある薄い色の√マークがついているフィードは、「Bylineによって本文が意図的に削られていると判断されたフィード」であることを示します。この薄い色の√マークはメインフォルダを自動でキャッシュする設定にしているときにのみ表示されます。左側の図のCNET Japanにはチェックが無くて右側の図のCNET Japanにはチェックがあるのはこれが原因です。

■Twitter連携の設定方法

BylineではOAuthを使用してTwitterアカウントにログインします。残念ながらこのOAuthの画面が英語のままになっているため、こちらで代わりまして簡単に解説いたします。



設定画面のアカウントセクションにあるTwitter欄をタップすると、上のような画面になります。ユーザー名とパスワードを入力して、ログインボタンを押してください。



この画面が正常に表示されれば完了です。画面右上の「完了」をタップして終了してください。なんか下の方で Redirecting you back to Byline とか表示されちゃってますが無視してOKです。


■Twitter投稿時にURLを短縮する方法

Twitter投稿画面には一見、URLを短縮するためのボタンがありません。ですがご安心ください。BylineにはURLを自動的に短縮する機能があります。



このように普通に本文をタイプして、140文字よりも長くなってしまうと・・・



ご覧の通り！自動的にURLが短縮されます。



さらに本文が長くなってそれでも投稿できなくなってしまったらこのようになります。どうでしょうか、いちいちボタンを押して縮めるよりスマートだと思います。


■裏技：Byline 2と同じ感覚で「すべて既読にする」方法

Byline 3ではUIが変更されて、Byline 2ではアイテム一覧の一番下にあった「すべて既読にする」ボタンがありません。個人的にはこの変更はすごい抵抗があって作者の人にも何とかならないかとお願いしてみたのですが、その代わりにちょっとした裏技を付けてくれました。



画面一番下のツールバーをスワイプすると、ツールバーに「すべて既読にする」ボタンが表示されて、すべて既読にすることができます。これで多少はByline 2に近い感覚で操作できるかと思います。

Three20 の TTURLRequest は POST メソッドのリクエストもキャッシュしてしまう

Three20 には TTURLRequest という Three20 フレームワークの通信関連を一手に引き受けている通信用クラスがあります。基本的には　NSURLConnection クラスとほぼ同等なのですが、リクエストを作ったりレスポンスを delegate でハンドルするのがより簡単になるように作られていたり、独自のキャッシュを使用してより効率的なキャッシュをするようになっていたり、様々な点で NSURLConnection より優れていて便利に使えます。

ですがいくつかハマリどころもありまして、今回はそれを紹介します。ちなみに今回使用した Three20 のバージョンは http://github.com/facebook/three20 の default ブランチの 2010/09/05 付での最新コミットです。今後修正される可能性があります。

実は TTURLRequest は、デフォルトでは HTTP メソッドの種類に関係なく、一律すべてのURLをキャッシュするようになってしまっています。そのため、キャッシュ設定をせずに POST メソッドを使って Web API を実行したり、 RESTful な Webアプリ に PUT や DELETE を送ってしまうと、二回目以降のリクエストがキャッシュされてしまいサーバーにリクエストが飛ばなくなってしまいます。回避方法は以下のどちらかを使うと良いです。

1. 手動でリクエストを作成する際にキャッシュ設定を明示的に指定する
2. フレームワーク側を書き換えてしまい、　POST, PUT, DELETE 実行時にはキャッシュを無視するようにする

■手動でリクエストを作成する際にキャッシュ設定を明示的に指定する
一番簡単です。以下のようにして明示的にキャッシュを使わないように指定します。

TTURLRequest *request = [TTURLRequest requestWithURL:@"http://mypage.example.com/api/something/post" delegate:self];
request.httpMethod = @"POST";
request.cachePolicy = TTURLRequestCachePolicyNone;

■フレームワーク側を書き換える
でも個人的には GET 以外でリクエスト結果がキャッシュされるのは誰がなんと言おうと不具合だと思っているので、 TTURLRequestQueue.m の loadRequestFromCache: メソッドを以下のように書き換えて対応しました。

- (BOOL)loadRequestFromCache:(TTURLRequest*)request {
    if (!request.cacheKey) {
        request.cacheKey = [[TTURLCache sharedCache] keyForURL:request.urlPath];
    }

    if (IS_MASK_SET(request.cachePolicy, TTURLRequestCachePolicyEtag)) {
        // Etags always make the request. The request headers will then include the etag.
        // - If there is new data, server returns 200 with data.
        // - Otherwise, returns a 304, with empty request body.
        return NO;
    //-----------------------------------------------------------------------
    // ここから下が変更点
    //-----------------------------------------------------------------------
    } else if ([request.httpMethod isEqualToString:@"POST"] || [request.httpMethod isEqualToString:@"PUT"] || [request.httpMethod isEqualToString:@"DELETE"]) {
        // HTTP POST/PUT/DELETE should not use cache.
        // Only HTTP GET can use this cache.
        return NO;
    //-----------------------------------------------------------------------
    // ここまでが変更点
    //-----------------------------------------------------------------------
    } else if (request.cachePolicy & (TTURLRequestCachePolicyDisk|TTURLRequestCachePolicyMemory)) {

これですべてのHTTPリクエストにおいて、 POST, PUT, DELETE 時にキャッシュが使われなくなります。

Keychain Accessから秘密鍵を書き出すときに、「エラーが発生しました。項目を読み込めません。」と表示されたときの対処法

iPhone開発にはAppleが発行する証明書が必要になるため、なにかとKeychain Accessのお世話になることが多いです。特に、複数台のMacで開発を行っている場合は、証明書を認証するための秘密鍵を複数台のMacにインストールする必要があります。
このとき、最初のMacから別のMacに秘密鍵を移すために、Keychain Accessから秘密鍵を書き出しする必要があるのですが、書き出した秘密鍵を取り込もうとすると「エラーが発生しました。項目を読み込めません。」とエラーが出て取り込みが出来ないケースがあります。


こんなダイアログです。

このダイアログが出てしまったときの対処法をまとめてみました。


■結論から言うと
このダイアログが出てしまったときは、秘密鍵の書き出し方を間違っています。


この「すべての項目」画面から鍵を書き出してしまうと、書き出しには成功しますが読み込むときに100％失敗してしまいます。


こちらの「証明書」画面から証明書の階層を開き、鍵を書き出すと、正常に読み込むことが出来ます。

[pyspa]Python温泉おつかれさまでした

普段Blogを愛読しているこの人に会えたのでちょっと嬉しい
アクセンスの中の人からPythonぬいぐるみをいただきました
本物のHackerとはどういう人種か、大変勉強になりました
っていうかアクセンスすごいよアクセンス ← 今の今までどういう会社か知らなかった

Python温泉、2泊3日お疲れ様でした。無線LAN完備の温泉完備の布団完備（？）の食料完備で大変有意義な時間を過ごすことが出来ました。本物のHacker集団はバイタリティがすごい。ニコ動の（正確にはニコニコ大百科の）中の人とお話しできたり、実は毎日自分がクレクレ厨をしていた相手が取締役と社長さんだったりとあとから思い返せばなかなか冷や汗ものでしたが、まぁ旅の恥はかきすてっていいますから・・・駄目？

一番勉強になったのは「徹底的な探求心」、感じ取れたのは「集中力」、自分に必要なのは「現在の環境に対するチャレンジ」。たとえばEclipseをやめてVimとEmacsでPythonを書いてみたりとか。

Mac の Skype のデータベースを最適化してパフォーマンスを向上させる小技

もりよしさんにSkypeで教えてもらったのですが、Mac版のSkypeクライアントってデータベースにsqlite3を使用しているんですね。少なくとも3年前には既に知られているネタみたいなのですが、ぜんぜん知りませんでした。
http://d.hatena.ne.jp/shishimaruby/20101214/1292288183

というわけで、Mac版のSkypeをお使いの方は

~/Library/Application Support/Skype/(自分のアカウント名)/

以下にsqlite3のデータベースファイルがあるので、Skypeを一度終了した状態で

sqlite3 main.db VACUUM
sqlite3 main.db REINDEX

という感じでVACUUMとREINDEXを実行すると劇的にパフォーマンスが改善します。特に仕事とかで大量のログを見ている方におすすめです。私の場合、370MBもあったログが270MBまで減って、Skypeの起動も高速化しました。

※注意: このコマンドはSkypeのログデータベースを直接操作します。最悪全てのログが失われる危険があります。何を言っているのか分からない、ターミナルの操作なんて知らないという人は実行しないことを強くおすすめします。

Android で Dagger DI を使いやすくするライブラリを書きました

Daggerというsquare社がオープンソースで提供しているAndroid向けDI (Dependency Injection)フレームワークがあります。

• 公式ページ
• 非公式日本語訳ドキュメント

これを試しに自分のAndroidアプリで使ってみようと思い立ったのですが、幾つか問題が発生しました。

• DI自体の概念が難しい
• そもそもドキュメントを読んでもDaggerの使い方がよくわからない、公式のサンプルを真似してみても正直いまいちわからない
• AndroidでDIを行うとなるとandroid.content.Contextの注入が必須になるのだが、Contextは動的なインスタンスであるためDIでの取り扱いが難しい

そこで四苦八苦しながら動くようになったものをライブラリとして公開し、少しでも簡単にDIのメリットだけを享受できればと思いまして DaggeredAndroid なるものを作ってみました。

使い方とかはREADMEを見てください。全部英語ですがすみません(´･_･`)

AndroidでDIを使う際のメリットは主に以下のとおりです。

• オブジェクトをメンバに接続するだけのコードを無くせるので、コード量が減る。
• シングルトンの取り扱いが楽になる。
• Contextの取り扱いが楽になる。
• Moduleを差し替えればインスタンスが安全に差し替わるので、テスト環境を作ったり、本番と開発環境を分離したりなど、環境の差し替えが楽になる。テスト時のみModuleを上書きすることもできる。

天気予報アプリが作りたい、その名はjWeeklyForecast（仮）

• マップをタップしたら、タップしたあたりの天気予報がぱぱっと出る。ただそれだけのアプリ
• 出来れば一週間先まで見たい。
• 天気情報はYahoo.co.jpからスクレイピングする（Yahooさんごめんなさい）
• そのためにバックグラウンドサーバーが欲しいのでGoogle App Engineで作っちゃう

最近、fladdictさんが日本のiPhone開発コミュニティ全体に「情報をもっとオープンにしていこう」と働きかけています。
その結果が少しずつ実をつけてきたのを肌で感じています。

• みんなが競って作りたいiPhoneアプリのネタを披露するようになったり、売り上げを報告するようになった
• @iphone_dev_jpなるTwitterアカウントが誕生し、毎日たくさんのTipsが飛び交うようになった
• iPhone Create List Japanなるリストまで誕生した

たった一人の働きかけでここまでコミュニティ全体の流れを変えることができるものなのか、と感動することしきりです。

ということで私もこの流れに乗っかり、現在作成中のアプリを洗いざらい公開することにしました。

現在、jWeeklyForecastという天気予報アプリを作成しています。

• 地図から予報を見る場所を選択したい
• 一週間先の予報が見たい
• 日本の天気だけ見られればよい
  

というニーズを満たすために開発を始めたのですが、私がトロトロしているうちにウェザーニュースさんがもうこれ以上完璧な天気予報アプリは無いだろうというぐらい完璧なアプリをリリースされてしまいましたので、すでに私のニーズは満たされてしまいました。
ここから先は自分の勉強と日本iPhone開発コミュニティへのネタ還元のためにアプリの作成を続けていこうと思います。

「日本iPhone開発コミュニティに対するネタ還元」という観点から見たjWeeklyForecastの価値ですが、

• 地図（route-me）を使っている
• バックエンドサーバーを自作している（Google App Engine）

この2点が大きくアピールできるのではないかと思います。
特に最近fladdictさんをはじめとして台頭しているFlasherさんたちは、バックグラウンドサーバーを自分で作った経験がほとんど無いはずです。ですので、無料で簡単に、自分の（ひいては他の開発者の皆さんのための）iPhoneアプリ用APIサーバーなどを作る方法のノウハウなどが提供できれば少しでも価値になるのではないかなーなどと考えてます。

問題は、私が大変飽きっぽい上にすぐ挫折するので、最後までやり遂げられるかとっても不安ですが・・・
まぁ若輩者の戯れ言と思っておつきあいいただければ幸いです。

Macbook Air (Early 2008)にMac OS X 10.6 Snow Leopardをインストールしてみた

最初は見送ろうかと思っていたのですが、Twitterのタイムラインを眺めていると「速い！」とか「良い！」との声が多数見受けられ、居ても立っても居られず仕事帰りにさくっと買ってきてさくっとインストールしてみました。
iMacとMacBook Airの2台あるので、まずはAirのほうに試しにインストール。

(2009/08/30追記) QuickSilverが動作するようになったので追記しました。
(2009/09/13追記) 64bit Kernel起動を試してみたので追記しました。


■インストールにかかる時間
大体40分〜50分ぐらいでした。OKボタンを数回押して放置するだけ。簡単です。


■インストールしてみて第一印象
確かに「速い！」です。もっとも印象に残るのが再起動やスリープ→復帰。また、アプリの起動や終了も明らかに速くなっています。具体的にはDockの上で4回はねないと起動しなかったアプリが1回はねただけで起動したりします。

それから地味に嬉しいのが入力ソースをアプリごとに保持するオプション。10.4までは可能で10.5で廃止されたオプションですが、10.6でめでたく復活しました。QuickSilverとTextMateは英字でTweetieは日本語でとか保持してくれるのがいい感じ。
http://d.hatena.ne.jp/Psychs/20090828/1251467136

そして何よりトップにも載せましたが4本指スワイプが使えるようになりました。最近のMacBookでは当たり前でしたが、なにせ私が使っている初代MacBook Airはこのオプションが無くてずいぶん肩身の狭い思いをしていたので嬉しくてたまりません。もうこれだけのために3000円払ってもいい。


■使えて良かった開発系のツール一覧
Firefoxは完全にそのままOK。Multiclutchの設定もそのまま使えました。
XcodeとiPhone SDKは専用の物をインストールしなおしてすぐにそのままビルド出来るようになりました。こちらも問題なし。
TextMate問題なし。OmniFocusやEvernoteも問題なさそうです。DropBoxも動いています。Growlも意外なことにきちんと動作しています。日本語入力のATOK2008 for Macも大丈夫です。
最大の問題としてMacPortがバージョン1.7系だと動作しませんが、つい先ほど公式の1.8インストーラがリリースされたため、こちらからSnow Leopard用の1.8をインストールしなおし、sudo port uninstall installedしてから必要な物を再度installし直すことで復旧できました。
QuickSilverもそのままでは設定画面が壊れて表示されなくなってしまいますので、最新のβビルドをこちらのページ（http://code.google.com/p/blacktree-alchemy/downloads/list）からダウンロードして入れ直すことで無事使えるようになりました。


■使えなくなってしまったアプリ一覧
SIMBLを使っていたアプリは32ビットモードで起動しても使えなくなっているようです。たとえばTerminalColourは完全にダメ。MenuMetersもダメです。QuickSilverも起動するだけなら問題なさそうですが、設定画面を開いた瞬間にフリーズして落ちてしまいます。
幸いにしてあまりSIMBLに依存した生活をしていなかったおかげで、ほとんど被害無く過ごすことが出来ています。


■64bit kernel起動は？
そもそもMacBook Air(Early 2008)は64bitカーネルのサポート対象外なのですが、ダメ元で試してみました。
結果、Boot modeは64bitにできましたが、実際に立ち上がるカーネルは32bitになってしまいました。やっぱりダメみたいです。あと、EvernoteとFirefoxのEvernoteプラグインの挙動が変になってしまったため、すぐに戻しました。


■まとめ
普通に使っている方にはアップグレードの手間もほとんど無くいい感じです。特に初代MacBook Airをお使いの方は是非アップグレードをお勧めします。逆にSIMBLやSafariプラグインに依存した生活をお送りで、ユーティリティが動かないと困る方はしばらくアップグレードを見合わせた方がよいかもしれません。

あと各所でインストールディスクが傷だらけでインストールできないという症例が報告されておりますのでご注意ください。最悪の場合はApple Storeに持ち込めばたぶん交換してくれます。