2013/07/21

Notification Center と UIApplicationDelegate

iOSのUIApplicationDelegate ProtocolはApplicationに関するイベントを伝達するためのプロトコルです。

その中の「- (void)applicationDidBecomeActive:(UIApplication *)application」は、APIドキュメントによれば、「非アクティブステートとアクティブステート遷移を知らせる際に呼び出される」と定義され、「アプリケーションが起動された時」や「電話着信やSMSメッセージ等による中断をユーザが無視した際」に呼ばれる、と書かれています。

また「- (void)applicationWillResignActive:(UIApplication *)application」は、同じくAPIドキュメントへ「電話着信やSMSメッセージ等による一時的な中断」や「ユーザがアプリケーションを中断し、バックグラウンド状態へ遷移し始めた際」に呼ばれる、と書かれています。

しかし、APIドキュメントに明示されていないものの、これらの両メソッドは、利用者がiOSのNotification Center(NSNotificationCenter ではなく、ステータスバーから引き出す「通知センター」)を呼び出した際にも呼び出されます

具体的には、

  •  Notification Center画面を少しでも表示させると、- [UIApplicationDelegate applicationWillResignActive:] が呼び出される
  • Notification Center画面を完全に画面外へ追い出すと、- [UIApplicationDelegate applicationDidBecomeActive:]が呼び出される

ことになります。

なおこれは、Notification Centerに関わらず、ユーザ指示により呼び出される「アプリケーション画面へ覆いかぶさる形式で表示されるシステムメニュー画面」でも同様の挙動となるようです。

実験の為、ただApplicationDelegateの各種メソッド呼び出しを、コンソールへ表示する為だけのサンプルアプリをGitHubへ置いてあります

MacBook Air 2013 + AirMac Exteme を使い 802.11ac で通信速度を計測

MacBook Air 2013 で IEEE 802.11acドラフトが採用されましたが、同時にAirMac Time CapsuleAirMac Extremeも802.11acドラフトを採用した新製品が発売になりました。 

MacBook Airの新調に併せAirMac Extremeも購入し、802.11ac環境を整えることができたので、従来の802.11nとの速度を比較してみることにしました。

AirMac Extremeは非常に縦長の外装。同時に発売されたTime Capsuleと同一の形状です。



 端子類を覆うようにシールが貼られている点はAppleTVでの対応と同様。


国産アクセスポイントなどと異なり、内容物もシンプルな構成で、マニュアル類はほとんど含まれていません。設定を専用のアプリで行うことが前提になっている為でしょう。



まずは、MacBook Air 2013を従来から利用しているアクセスポイントであるNEC AtermWR9500Nへ接続し、速度を計測してみました。

接続には5GHz帯域を使用します。アクセスポイント自体はチャンネルボンディング/3ストリーム対応の為、理論値450Mbpsですが、MacBook Air側が2ストリームまでの対応であるため、理論値は300Mbpsとなります。

設置環境は従来までの計測同様、木造2階建ての1Fと2Fで行いました。但し今回は、計測プログラムへnuttcpを使っています。

   26.6250 MB /   1.00 sec =  223.1951 Mbps
   27.3750 MB /   1.00 sec =  229.6127 Mbps
   27.0625 MB /   1.00 sec =  227.2098 Mbps
   27.5000 MB /   1.00 sec =  230.5712 Mbps
   27.2500 MB /   1.00 sec =  228.6858 Mbps
   27.5625 MB /   1.00 sec =  231.2739 Mbps
   21.5625 MB /   1.00 sec =  180.8837 Mbps
   26.6875 MB /   1.00 sec =  223.6922 Mbps
   26.7500 MB /   1.00 sec =  224.5920 Mbps
   27.7500 MB /   1.00 sec =  232.7531 Mbps

  266.6250 MB /  10.02 sec =  223.3137 Mbps 7 %TX 2 %RX 0 host-retrans 2.14 msRTT

結果は223.3137 Mbps。非常に優秀な成績です。

今度は、アクセスポイントをAirMac Extremeへ切り替えて計測しました。

こちらもアクセスポイントは3ストリーム対応ですが、MacBook Airの制限で理論値866.7Mbpsとなります。接続帯域は、同じく5GHz、設置環境も同様です。

   62.0000 MB /   1.00 sec =  519.7294 Mbps
   66.3125 MB /   1.00 sec =  556.4387 Mbps
   65.8125 MB /   1.00 sec =  551.9108 Mbps
   67.0625 MB /   1.00 sec =  562.8503 Mbps
   66.4375 MB /   1.00 sec =  557.2151 Mbps
   65.9375 MB /   1.00 sec =  553.4338 Mbps
   66.5625 MB /   1.00 sec =  558.3874 Mbps
   66.9375 MB /   1.00 sec =  561.3261 Mbps
   66.1875 MB /   1.00 sec =  555.2543 Mbps
   66.4375 MB /   1.00 sec =  557.5490 Mbps

  660.3750 MB /  10.01 sec =  553.4260 Mbps 15 %TX 9 %RX 0 host-retrans 2.70 msRTT

結果は553.4260 Mbps。802.11n接続時の2.5倍近い速度が計測できました。

一般的に家庭で利用される有線接続がGbEであることを考えれば、その実効速度へ迫る転送速度です。3ストリーム対応クライアントと共に使えば、有線環境を超える速度が得られるかもしれません。もはや「無線は有線よりも遥かに遅い」という固定観念は通じなくなってきています。

802.11acは、まだドラフト段階の仕様ではありますが、対応クライアントをお持ちの方は、アクセスポイントの新調を行えば十分投資に見合う快適な接続環境を構築できる可能性が高いでしょう。

快適な通信速度を求める方へ、非常にお薦めのネットワーク環境です。

2013/07/20

GitLabをインストールする際に陥った問題のまとめ

GitLabGitHubのようなGitホスト環境を手元で構築できる、大変有益なツールです。

主なサポートプラットフォームはLinuxの各ディストリビューションですが、私はGitLab v5.3をFreeBSD 8.4 + ruby 1.9で利用しています。

やや環境設定で戸惑う事があったので、FreeBSD で動作させるコツと共に、ハマった点をまとめておきます。

FreeBSD へインストールする際の参考ドキュメント


FreeBSD へのインストールには、gitlab-freebsd/gitlabhqで公開されているインストールガイドが、大変参考になります。概ねこの手順に従えば、トラブルなくインストールが完了します。

なおgitlab-freebsd/gitlabhqではgitlabhq/gitlabhqのforkが公開されていますが、GitLabのコード自体へ特殊な変更が行われているわけではありません。オリジナルリポジトリへ、FreeBSDのportsと親和性の良い各種設定ファイルを同梱している、と捉えると分かりやすいと思います。

実際、forkされているコードは比較的古い版であるため、設定ファイルを参考に、オリジナルの最新版を動作させると良いでしょう。

FreeBSDではgitlab-shellへ注意


GitLabのv5系はgitlabhq/gitlab-shellへ依存しています。但し、gitlab-shell v1.6までのコードはFreeBSDでは動作しません。

gitlab-shellをFreeBSDで利用する場合にはf13afa2db3以降のコード利用する必要があります。

問題の本質はGNU sedとBSD sedの-iオプション引数取り扱いの差あり、変更差分はわずかです。

FreeBSD向けGitLab起動スクリプト


FreeBSD向けGitLab起動スクリプトとしては、Eyes JAPAN Blogで公開されているスクリプトが綺麗にまとまっており、利用させていただいています。

但し、ここで公開されているスクリプトの最新版にはバグが有り、重要な外部プログラムであるsidekiqが動作しません。

修正した版をgistで公開していますので、こちらの利用をお薦めします。本質は変数の初期設定ミス修正です。

repos_path へは symbolic link を含んではならない


gitlab/config/gitlab.yml ならびに gitlab-shell/config.yml へはrepositoryを格納するディレクトリを設定するrepos_pathがあります。コメントへ書かれている通り、この値はsymbolic linkを含んではいけません。

ここで注意すべきは、FreeBSDを標準設定でインストールした場合、/homeディレクトリが、usr/homeへのsymbolic linkとしてインストールされることです。

結果、GitLab標準設定に基づき、repos_pathとして/home/git/repositories/を指定すると、結果的にsymbolic linkを含んでしまうことになります。

もしこのディレクトリを使いたい場合には、明示的に/usr/home/git/repositoriesと設定するか、/homeの位置を再調整する必要があります。

sidekiq が動作していることを確認する


FreeBSD へ限った話ではありませんが、GitLabではsidekiqプロセスが正しく動作していることが非常に重要です。

sidekiqプロセスが動作していない場合、表面上は正常に動作しているように見えるものの、実際には正常動作しない、という、分かりにくい状況へ陥ります。

例えば、Web画面ではssh鍵の登録が正常終了したように見えたにも関わらず、実際には、authorized_keysへ鍵が登録されていない、といった状況や、プロジェクトの作成指示が正常動作したように見えたにも関わらず、repos_pathで指定したディレクトリ内へはリポジトリが作られていない、という状況になった場合、sidekiqプロセスが、正しく動作していることを確認すると良いでしょう。 

例えばsidekiqが正常動作している場合、psでは次のように見えます。
# ps ax | grep sidekiq
41032   0  I      0:22.50 ruby19: sidekiq 2.11.1 gitlab [0 of 25 busy] (ruby19
なおsidekiqプロセスは、GitLabの起動スクリプト内で起動されることが一般的です。うまく動作しない場合にはスクリプトを確認すると良いでしょう。

.ssh/authorized_keys 内の鍵へ注意する


これもFreeBSD へ限った話ではありませんが、GitLabを動作させているユーザの .ssh/authorized_keys ファイルは、リポジトリアクセス権管理に使われる重要なファイルです。

何らかの不具合により、このファイル内へ同一の鍵が複数個登録されてしまった場合、GitLabが正常に動作できなくなる可能性があります。

GitLab 管理下にある repository へ push を行った際、
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
といったメッセージが表示された場合、.ssh/authorized_keys が正しいかどうかを確認すると良いでしょう。

なお、鍵が正しくインストールされている場合、
% ssh -t gitlab@GitLabServerName.example.com
とのコマンドに対し、
Welcome to GitLab, <YOUR USER NAME>
との応答が返ります(<YOUR USER NAME>はGitLabで登録したユーザ名です)。この応答が返らない場合、鍵設定に問題のある可能性があります。

GitLabは大変便利なツールです。ツールの規模がやや大きいため、トラブルシュートでやや混乱しがちですが、設定ファイル自体はシンプルなため、問題を適宜切り分ければ、対処は難しくないと思います。

2013/07/06

MacBook Air 2013 を購入しました

MacBook Air 2013 11inchを購入しました。



MacBook Air 2010は現在でも十分使い勝手の良いデバイスですが、バッテリの持続時間に関してはやや不満を感じ始めていました。

Wi-Fiを有効にしなければ、実質計測で10時間程度は持つのですが、Wi-Fiを有効にすると、仕様上謳われている「ワイヤレス環境で最大5時間」程度でバッテリが力尽きてしまいます。

一方MacBook Air 2013 11inchでは、CPUをHaswellへ変更したことが影響しているのでしょう、仕様上の表記が「最大9時間のワイヤレスインターネット閲覧」となりました。2010モデルからバッテリ稼働時間が約2倍へ伸び、まさに望んでいた改良です。最近はWi-Fiスポットも増え、Wi-Fiを有効にしている時間が多くなった為大変嬉しいアップデートとなりました。

加えて、無線LANの規格が802.11ac(draft)へ向上すると共に、2010モデルでは最大128GだったSSDの上限が最大512Gへ拡大されるなど、モバイルデバイスとして魅力が大きく向上しています。

今回購入した構成は、CPU Core i7 1.7GHz、8GBメモリ、256GB SSD、英語キーボード。
従来のモデルは、CPU Core2 Duo 1.6GHz、4GBメモリ、128G SSD、英語キーボードでしたので、大幅な性能向上です。

外箱の様子。上が2010モデル、下が2013モデル。同じ大きさですが、2010モデルで黒かった箱表面の背景は、白になりました。


 開けた様子は変わりません。


中の構成。上が2010モデル、下が2013モデル。


基本収納物は同一ですが、今回Lightning Ethernetアダプタも同時購入した為、2013モデルではそれを収納可能な内箱になっています。この辺りの仕組みは、iMac 27-inch Late 2012の内箱と同様です。


2010モデルではOSのインストールされたUSBメモリが付属していました。


2013モデルでは本体のみで再インストール可能になった為、外部メディアは付属していません。

本体はほぼ見分けが付きません。マイク形状が異なること、また、電源がMagSafeからMagSafe2へと変更になったこと位が判別のポイントです。



動作は大変キビキビしており、全く問題を感じません。特にSleepからの復帰は素早く、蓋を開けた時には既に利用可能な状態になっています。この点は、2010モデルとは一線を画しています。

今まで使っていた2010モデルは、ソフマップの中古下取りへ。売価は34000円と上限価格で買取して貰えました。3年前のモデルですが、この価格で買い取ってくれるという点に、MacBook Airの人気が伺えます。

従来機同様、有効に活用して行きたいと思います。


2013/07/01

iOSアプリでのアイコン設定

iOSアプリでアイコンを設定する場合、「App-Info.plist」ファイルの「CFBundleIcons」key内にある「CFBundleIconFiles」keyへArray形式でアイコンを列挙します。例えば次のような形式になるでしょう。
        <key>CFBundleIcons</key>
        <dict>
                <key>CFBundlePrimaryIcon</key>
                <dict>
                        <key>CFBundleIconFiles</key>
                        <array>
                                <string>Icon-72.png</string>
                                <string>Icon-72@2x.png</string>
                                <string>Icon-Small.png</string>
                                <string>Icon-Small-50.png</string>
                                <string>Icon-Small@2x.png</string>
                                <string>Icon-Small-50@2x.png</string>
                        </array>
                        <key>UIPrerenderedIcon</key>
                        <true/>
                </dict>
        </dict>

しかし、特定の環境下構築した場合、この「CFBundleIconFiles」へ結びついたArray内へ、Default Screenのファイル一覧が含まれている場合があります。具体的には、次のような記述が含まれていました。
                               <string>Default-Portrait@2x~ipad.png</string>
                               <string>Default-Landscape@2x~ipad.png</string>
                               <string>Default-Landscape~ipad.png</string>
                               <string>Default-Portrait~ipad.png</string>
                               <string>Default-Portrait~ipad.png</string>
                               <string>Default-Portrait~ipad.png</string>
                               <string>Default-Landscape~ipad.png</string>
この設定が存在する場合、特定のiOS環境では、アプリアイコンが正しく表示されず、Default Screenをアイコンサイズへ縮小した画像が使われてしまいます。

もし「アプリアイコンがDefaut Screenになってしまう」という状況へ陥っている場合、「CFBundleIconFiles」keyへ紐付いたArrayの内容を確認すると良いでしょう。