Flickrの短縮URLを生成する方法(Base 58によるエンコード)

Flickr上の画像の短縮URLは、以下の形式となっており、{base58-photo-id}の部分には画像のphoto_idをBase 58でエンコードした値を設定します。
http://flic.kr/p/{base58-photo-id}

このFlickrのphoto_idをBase 58でエンコードする処理をObjective-Cjavascriptで実装してみました。
以下がそれぞれの言語での実装です。

Objective-C

- (NSString *)base58EncodedStringFrom:(long long)photoId {
    NSMutableString *encodedStr = [NSMutableString string];
    long long number;
    
    if(photoId) {
        number = photoId;
    } else {
        return nil;
    }
    
    // Base62の[0-9a-zA-Z]から" 0, O, I, l"を除いた58文字にphoto_idを変換する
    NSString *base58Characters = @"123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ";
    
    NSUInteger baseCount = [base58Characters length];
    
    while(number > 0) {
        long long mod = number % baseCount;
        
        unichar ch = [base58Characters characterAtIndex:mod];
        NSString *str = [NSString stringWithCharacters:&ch length:1];
        [encodedStr insertString:str atIndex:0];
        
        number = number / baseCount;
    }
    
    return encodedStr;
}

javascript

function base58EncodedStringFromPhotoId(photo_id) 
{
    var num = photo_id;
    var base58Characters = '123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ';
    var baseCount = base58Characters.length;
    var encodedStr = "";

    while(num>0)
    {
        var mod     = num % baseCount;
        encodedStr  = base58Characters.charAt(mod) + encodedStr;
        var div     = num / baseCount;
        num         = Math.floor(div);
    }
    
    return encodedStr;
}

CLLocationManagerDelegate内でアプリの位置情報サービス利用可否を判断する方法

[設定]-[一般]-[位置情報サービス] では、アプリ単位に位置情報サービスの使用許可をユーザがON/OFFを設定できる。
アプリ単位で「〜は現在の位置情報を利用します。よろしいですか?」でOKされたかを判断する方法をメモ。


この場合、[CLLocationManager locationServicesEnabled]では判断不可。
このメソッドは全体の設定がONかOFFをBOOL値で返すだけ。


位置情報サービスの使用をアプリが許可されていない場合はエラーが発生し、CLLocationManagerDelegate ProtocolのlocationManager:manager didFailWithError: が呼ばれる。
そのため、OFFに設定されている場合のハンドリングはこのメソッド内で行う。

以下、サンプルコード。

- (void)locationManager:(CLLocationManager *)manager 
       didFailWithError:(NSError *)error {
	if(error) {
		int code = [error code];
		switch (code) {
                        // 位置情報サービスの利用を許可されていない場合
			case kCLErrorDenied: 
				// ここでエラーハンドリングを行う
			
				break;
			default:
				break;
	}
}

レフェリー 知られざるサッカーの舞台裏

レフェリー 知られざるサッカーの舞台裏」という映画観てきました。
サッカー好きの人にはお勧めです。


この映画は、EURO2008を舞台として、審判にフォーカスを当てたドキュメンタリーです。

最近の審判はインカムを付けていますが、それを使って主審、副審、ラインズマンがジャッジを下す際に頻繁にコミュニケーションを取ってる場面や、ゲーム中のシーンのみならず、ピッチ外での私生活の様子などが描かれています。
舞台となっているEUROのようなビッグコンペティションにおける審判団の公私をついて窺い知ることができてとても興味深かったです。

この映画により、現在は真っ直中のW杯の試合を見る目が変わりました。どうしても試合を観てる際は審判の挙動より、チーム戦術や選手の個人技の方に目がいってしまいます。
しかし、決定的なジャッジが下った時(この前のクローゼの退場など)は審判の振る舞いにも注意しようと思います。審判団の中で凄まじい情報交換が行われているのは間違いないと思いますので。


興味がある方は、以下の公式サイトをチェックしてみてください。

 >> webDICE - 映画『レフェリー 知られざるサッカーの舞台裏』公式サイト

深大寺

今日は年休を取得して、夫婦でのんびりと深大寺に行ってきました。
調布からバスで15分くらいのところに、東京とは思えない雰囲気の場所があるとは思いませんでした。
"NHKドラマ - ゲゲゲの女房"効果で混んでるかと思ったのですが、平日のせいかそんなことはなく、ゆっくりと散策できました。
気軽に行けるのでおすすめです。

行く前に参考にしたWebページ、本日撮った写真を以下に掲載しておきます。

観光ガイド


>>  深大寺観光ガイド


写真:深大寺内にて

P6161524

P6161509

P6161510

P6161512

P6161515

O6161520


写真:鬼太郎茶屋にて


O6161542
O6161544

O6161547

iPhoneアプリと外部アクセサリの通信方法に関するまとめ

iPhoneアプリを使って、外部アクセサリ(Bluetooth機器など)と通信する方法を調べた結果をメモしておく。

なお、調査には以下のページを参照。
  >>  iPhone Application Programming Guide: Device Support - Communicating with External Accessories

基本事項


iPhoneアプリにて外部アクセサリと通信するためには、External Accessoryフレームワーク(ExternalAccessory.framework) を使用する。(iPhoneOS 3.0以降)

アクセサリとの通信はデータ通信用のプロトコルを使用する。
アクセサリは少なくとも1つのプロトコルをサポートしているが、サポートするプロトコルはベンダ独自で決定することができるため、必ずしも標準コマンドがサポートされている訳ではない。(ベンダ独自でプロトコルを作ることが出来る)

アプリがアクセサリと通信を行う際は、EASessionクラスのインスタンスを生成し、アクセサリがサポートしているプロトコルを指定しセッションをオープンする。
※プロトコル名の記法は、reverse-DNS stringとなっている。(例:com.myDomain.myProtocol)

セッションオープン後、アプリとアクセサリ間の通信はストリームデータを送受信することで行う。
そのため、アプリ開発社は指定したプロトコルのバイナリデータの仕様を理解しておく必要がある。(ここの実装が大変そう。。。)

アプリがサポートするプロトコルの宣言


アプリがサポートしているプロトコルは、Info.plistに宣言する必要がある。
iPhoneOSはInfo.plistの宣言を元に、接続されたアクセサリに対応するアプリを認識する。
アクセサリ接続時、iPhoneOSは対応するアプリを起動する。(らしい)
接続されたアクセサリに対応するアプリが存在しない場合は、App Storeを起動する(可能性あり)。

上記の記述には少し自信がないが、原文を読む限りそういう動作をするみたい。

Declaring the Protocols Your Application Supports

Applications that are able to communicate with an external accessory should declare the protocols they support in their Info.plist file.
Declaring support for specific protocols lets the system know that your application can be launched when that accessory is connected.
If no application supports the connected accessory, the system may choose to launch the App Store and point out applications that do.

実行中にアクセサリとセッションを張る方法


iPhoneOSに接続され使用可能な状態になるまで、External Accessoryフレームワークからアクセサリは使用できない。
アクセサリが使用可能な状態になると、アプリは所定のアクセサリオブジェクトを取得し、セッションをオープンすることで通信できるようになる。

その方法は、原文で説明されているので割愛。

イベントの監視(接続/切断)


External Accessory フレームワークからアクセサリの接続/切断のイベント通知を受け取ることは可能。
ただし、デフォルトでは通知してくれないため、EAAccessoryManagerクラスのregisterForLocalNotifications:メソッドをコールする必要あり。

アクセサリが接続(+認証)されると、notificationとしてEAAccessoryDidConnectNotificationがフレームワークから通知される。
また、切断されるとEAAccessoryDidDisconnectNotificationが通知される。

notificationの他にDelegateを使用してアクセサリの切断を監視する方法もある。

EAAccessoryのサブクラスを作り、そのクラスにEAAccessoryDelegateプロトコルを割り当てる。
アクセサリ切断時にはaccessoryDidDisconnect: メソッドがコールされる。

iPhoneアプリのアイコン、画像に関するまとめ

iPhoneアプリ内で使用する画像やアプリアイコンなどについて調べた内容をまとめておく。
ソースは、↓のドキュメント。

 >> iPhone Human Interface Guidelines:Creating Custom Icons and Images


まず、iPhoneアプリで使用できる画像ファイルについて。
フォーマットは、JPEG,PNG。
PNGはαチャネル(透明、半透明)が使用可能。


以下は、アプリ内で使用される各アイコンの仕様です。


アプリアイコン

フォーマット:PNG
サイズ:57 x 57 (px)

その他:

  • 形状は、正方形(ラウンドではない。)
  • 光沢、αチャネルの使用は不可。

なお、iPhone OS はアイコンを表示する際、以下の処理を自動的に行う。

  • 正方形から丸角にする
  • ドロップシャドウを付加
  • 光沢を付加


App Storeのページ用アイコン

フォーマット:JPEG, PNG
サイズ:512x512(px)


起動時に表示する画像

フォーマット:PNG
サイズ:320x480(px)

小アイコン(small icon)

小アイコンとは、spotlightの検索結果や設定アプリの画面上に表示されるアプリアイコンのこと。

フォーマット:PNG
サイズ:29x29(px)


アイコン(ナビゲーションバー、ツールバー、タブバー)

フォーマット:PNG
サイズ:およそ20x20(px) <- ナビゲーションバー、ツールバー
         およそ30x30(px) <- タブバー


サイズは厳密ではなくて数ピクセルの誤差はOKみたい。


その他:

  • 色はpure white(適切なαを設定))
  • ドロップシャドーは使用不可
  • アンチエイリアジングを使用すること

なお、iPhone OS はこれらのバー上のアイコンに対するプレス状態や選択状態の表示の面倒を見てくれる。
そのため、プレス状態、選択状態用のアイコンを作成する必要はない。
また、逆に言うと、プレス状態、選択状態のアイコンを変更することは出来ない。

although と even though の違い

日本人の英語 (岩波新書)

日本人の英語 (岩波新書)

通勤時に聞いているポッドキャスト "ESL Podcast" で、althoughとeven thoughの文法的な違いが説明されており、ためになったのでまとめておきます。

今までは全然気にせずに使ってたから、今後気をつけようと思ってます。

althoughの場合:主節が否定文、althoughに続く従属節が肯定文
以下は紹介されていた例文。

  • Although I studied for my test last night, I did not pass it today.
  • There is not any room on this bus although another one is coming in two minutes.

even thoughの場合:主節が肯定文、even thoughに続く従属節が否定文
以下は紹介されていた例文。

  • Even though my brother didn't study for his test, he got a good grade.
  • This cake turned out great even though I din't follow the recipe.


上記の内容が紹介されていたエントリのリンクを掲載しておきますので、よろしければどうぞ!

 >> ESL Podcast - English Café 242

続・日本人の英語 (岩波新書)

続・日本人の英語 (岩波新書)

実践 日本人の英語 (岩波新書)

実践 日本人の英語 (岩波新書)