Cocos2d for iPhone のゲームで、iOS 標準ではない独自のフォントを使おうとしました。ゲームですからね。得点の表示とかは、ゲームっぽいフォントにしたいわけです。

ググると、以下をすればいいことがわかりました。 ・TTFファイルを Resourcesフォルダに置く（まあ、たぶんどこでもいいです） ・その TTFファイルを Xcode プロジェクトに追加する（フォルダに置くというのと同時にやってもいいはずです） ・info.plist にフォントを追加する。 ・フォントを使うときは、TTFファイル名ではなく、フォント名を指定する。

info.plist へのフォント追加は、こうやります。これは Cocos2d for iPhone 固有の手順ではなく、UIKit 一般の手順です。

</code>

実は Cocos 2D for iPhone は、以下のように内部的に UIFont を用いてフォントを探すので、上記が必要になるのです。

libs/cocos2d/CCTexture2D.m uifont = [UIFont fontWithName:name size:size];

#if CC_FONT_LABEL_SUPPORT if( ! uifont ) uifont = [[FontManager sharedManager] zFontWithName:name pointSize:size]; #endif // CC_FONT_LABEL_SUPPORT if( ! uifont ) { CCLOG(@”cocos2d: Texture2d: Invalid Font: %@. Verify the .ttf name”, name); [self release]; return nil; }

さて、info.plist で指定したフォントは、次のようにして使います。fontName: に指定するのは、ファイル名ではなくフォント名です。TTFファイルをダブルクリックすると開くはずの、Mac の Font Bookアプリのタイトルバーに表示される文字列を指定してください。

CCLabelTTF *time = [CCLabelTTF labelWithString:@"00:00" dimensions:CGSizeMake(100, 50) alignment:UITextAlignmentCenter fontName:@"CubicSans"];

ここまでやればいいはずなのですが、なぜかエラーがでます。

cocos2d: Texture2d: Invalid Font: CubicSans. Verify the .ttf name

[UIFont familyNames] でフォントの一覧を取得しても、CubicSans は出てきませんでした。困った。

実は、Xcodeプロジェクトの Build Phases タブの、Copy Bundle Resources に TTF ファイルを入れておく必要があったのです。これを指定しないと、ビルドしたバンドルにTTFファイルが含まれず、プログラムから探せなくなります。

外苑前駅から歩くこと10分。kajalさんの南インドランチに行ってきました。南インドではこれをミールスと呼びます。要は、定食です。北インドだとターリーと呼びますね。

本日のメニューは、

・mix野菜入り酸っぱ辛い豆カレー（サンバル） ・トマトスープ（ラッサム） ・ビーツのココナッツ炒め蒸し（トーレン） ・イモ入りココナッツミルク煮（オーラン） ・ジャスミン・ライス ・豆の粉でできた煎餅（パパド） ・梨とリンゴの漬けもの（アチャール） ・ココナッツのディップ（チャトニ） ・豆とチリのふりかけ（ポディ） ・ドリンク：コーヒーまたはハーブティー

これだけ食べて、1,100円。しかもお代わり自由。優しい味わいで、南インド料理が初めての人でも抵抗なく食べられると思います。そこら辺のインド料理屋さんに行くより、ずっとおいしいです。今日のメニューは辛くありませんでしたが、それでもスパイス料理なので、じんわりと汗が出てきます。

サンバル、ラッサムは定番です。お代わりを一回しました。ラッサムをもう一回お代わりしたかったかも。オーランというのは初めて口にしました。ほんのり甘めなので、デザートでしょうか。それとも、サンバルやラッサムと一緒に、ご飯にかけてしまってよかったのかな。梨とリンゴのアチャールは、カクテキのような歯ごたえがありました。ほう、こんな感じにできるんだ。

会場のナチュラルスペース＆キッチン Vayuさんは、外苑前、原宿、表参道から徒歩10分。閑静な住宅街の中にあります。

View Larger Map

「みかん書院」という出版社をつくりました。IT系技術書の翻訳出版を柱にしています。オフィスは自宅、社員もナシの、零細出版社です。最近はやりの電子書籍ではなく、紙で本を出します。少なくとも今のところは。

出版社を作ったと人に話すと、どうやら非現実的に聞こえるようで、なかなか理解してもらえません。お店を作ったとか、独立してシステムの受託開発を始めたというのと違い、ウケが悪いように思います。出版社とは存在するものであって、作るものではないという固定観念があるようです。

でも、出版社の立ち上げはとても簡単です。誰にでもできます。ただ、本屋さんの独立開業本コーナーにいっても『明日から始める出版社』みたいな本はなく、立ち上げ方のノウハウを集めるのに、やや手間がかかります。出版業界の人たちが門外不出のヒミツにしているわけでもなく、単に需要が無いから情報がまとまって存在しないだけです。直接教えを請いに行けば、みなさん親切にしてくださいます。

一方、出版社を継続させるのは、立ち上げよりも難易度が高いでしょう。みかん書院が3年後にも残っているかはわかりませんが、自分の器を超えて無茶をしなければ、そう簡単につぶれるものでもありません。そう信じているし、実際、継続する意思のある零細出版社はなかなか倒産しません。

インターネットの興隆とともに出版不況になり、年々市場が縮小し、改善する見込みもなく、講談社や集英社などの大手出版社が軒並み本業で利益を出せなくなっていますが、零細出版社はしぶといです。大手は不動産を持っているので、身を削りながらも、しばらくは倒産せず、零細は身の丈にあった事業を細々とやるので倒産しません。自転車操業している中堅出版社は、いつばたばたと倒れてもおかしくない状況のようですが。

とはいえ、紙から電子書籍への移行タイミングには気をつけないといけません。電子への転換期のどこかで、取次（本の問屋）の支払い能力に問題が生じるはずです。それが3年後なのか、10年後なのかは予測できませんが、紙本の売掛金が全額回収できなくても事業を継続できる程度の余裕は必要です。

Wordpress とスマホアプリを連携させるのに JSON を使っています。WP が出力した JSON を、iPhoneアプリで読むのです。JSON API という、拡張性の高いプラグインがあったので、これを利用しました。

JSON API プラグインに対して、「コントローラ」というクラスを登録します。すると、コントローラのメソッドが JSON API としてアクセスできるようになります。Rails のコントローラクラスの仕組みと似ています。

必要なのは、フック2つと、コントローラクラス1つです。まず、JSON_API_Hello_Controller クラスを作ります。

<?php

class JSON_API_Hello_Controller {

public function hello_world() { return array( “message” => “Hello, world” ); }

} ?> </code>

これをフックで登録します。

// カスタムコントローラを登録します add_filter('json_api_controllers', 'add_hello_controller');

function add_hello_controller($controllers) { // JSON_API_Hello_Controller に対応します $controllers[] = ‘Hello’; return $controllers; }

// JSON_API_Hello_Controller.php のパスを指定します add_filter(‘json_api_widgets_controller_path’, ‘hello_controller_path’);

function hello_controller_path($default_path) { return ‘/path/to/JSON_API_Hello_Controller.php’; } </code>

さらに、wp-admin の管理画面で JSON API の設定を開き、Helloコントローラを有効にします。これがわからなくて、時間を無駄にしました。

ここまでやると、http://example.com/?json=hello.hello_word というURLで Helloコントローラの hello_world() メソッドが呼ばれるようになります。

クエリストリング（URLパラメタ）を見て動作を変えたい場合は、グローバル変数 $json_api から取得できます。

public function hello_person() { global $json_api; $name = $json_api->query->name; return array( "message" => "Hello, $name." ); }

UNIXを使い始めて20年近くたちますが、初めてのエラーに遭遇しました。ディスク容量が十分あるのに、ファイルを作ろうとすると No space left on device エラーが発生するのです。

touch rarara

touch: cannot touch `rarara’: No space left on device

df

Filesystem 1K-blocks Used Available Use% Mounted on /dev/xvda1 8256952 6870384 1302704 85% / tmpfs 848476 0 848476 0% /dev/shm /dev/xvdf 8378368 4902356 3476012 59% /mnt </code>

これは、inode が足りなくなっていたためでした。

df -i

Filesystem Inodes IUsed IFree IUse% Mounted on /dev/xvda1 524288 524288 0 100% / tmpfs 212119 1 212118 1% /dev/shm /dev/xvdf 8388608 75096 8313512 1% /mnt </code>

inodeというのは、ファイルのオーナーやパーミッションなどのメタデータを保持する領域です。ここを使い尽くすと、新たなファイルが作れなくなります。通常のファイルシステムでは、inodeの数はディスクのサイズに応じて有限です。足りなくなったら、既存のファイルを削除するしかありません。

細かいファイルをたくさん作りすぎたのでしょうか。そんなに激しい使い方をしているサーバだという認識はないのですが。df -i の結果を見ると、52万ファイル作られているということですよね。

調べ回っていたら、Capistrano による Rails のデプロイメントが一役買っているであることがわかりました。Capistrano は、標準の設定では過去のバージョンを全部ディスクに残してくれます。デプロイする度に、1万個近くの inode を消費するのです。

古いデプロイメントを削除して inode領域を空け、ひとまず正常運用に戻すことができました。