OmniFocus を軽く快適に使えるようにメンテする技

普段からGTD用ツールとしてOmniFocusを便利に活用しております。iPhoneと3G経由でいつでも同期できたり、タスクレビュー機能があったり、何でもできて凄く助かるのですが、このOmniFocusには弱点がありまして・・・

そう

重すぎ

定期的にデータベースをメンテしてあげないととんでもない重さになってしまいます。
具体的には、サーバーと同期しようとしたiPhoneが10分間固まって帰ってこなくなったり
mobileme上に置いてあるデータベースファイルを開こうとしてFinderが固まって帰ってこなくなったり
とにかく、相当な破壊力を持つ代物です。その上公式サイトにも正しいメンテナンスの仕方が書いてありません︵一番大事なところが書いてない︶。そこでOmniFocusユーザーの方必見︵？︶、OmniFocusデータベースのメンテナンス方法をまとめてみました。

参考にしたページは以下の通り。
http://forums.omnigroup.com/showthread.php?t=14631&highlight=compact
http://forums.omnigroup.com/showpost.php?p=70253&postcount=3


■予備知識‥OmniFocusのデータベースの構造
OmniFocus.ofocusというファイルがOmniFocusのデータベースファイルです。その正体はMac Bundle︵わかりやすく言えば単なるディレクトリ︶で、中に以下のような形式でZIPファイルが入っています。

0000000000-日付.zip
ランダムな文字列-日付.zip
ランダムな文字列-日付.zip
ランダムな文字列-日付.zip
以下たくさん・・・

このZIPファイルを解凍するとcontent.xmlというXMLファイルになります。このcontent.xmlの集合がOmniFocusデータベースの基本構造になります。
content.xmlには﹁一番最初のデータベースの状態﹂か﹁前回保存時からのデータベース操作内容﹂が記載されています。要するに先ほどのZIPファイルの集合には以下のようにデータが格納されています。

このデータベースにはタスクが10個入ってるよ - 2009/11/10.zip
タスクBを完了したよ - 2009/11/10.zip
タスクXYZを新規作成したよ - 2009/11/10.zip
タスクDを削除したよ、あとコンテキストXXXを作成したよ - 2009/11/12.zip

これらのZIPファイルが自動的に削除されることはありません。要するにこのままではデータベースの領域が増える一方なわけです。これが重さの原因です。


■公式で推奨されている方法‥定期的に"Move Old Data to Archive"を実行する
実はこれ全然役に立ちません。
なぜか？
このコマンドを実行すると何が行われるかって、先ほどのデータベースに

タスクAとBとCはArchiveしたからもう二度と表示しなくていいよ.zip

これが追加されるだけなんです。

・・・え、かえってデータベースのサイズ増えてね？


■本当に有効な方法‥定期的に"Compact DataBase"を実行する
で、こっちが本命です。このコマンドを実行すると、操作内容を格納しているZIPファイルをすべて削除して、一つの新しい﹁現在の状態を表すZIPファイル﹂だけが存在するデータベースを作り直してくれます。効果は劇的で、たとえば私の場合は11.5MBあったデータベースファイルのサイズが25KBになりました。
問題はこのコマンド、実は﹁同期設定を行っている最中は実行できません﹂。この辺マニュアルや公式FAQに書いてなくて困りました。
ということで、いったん環境設定からiPhone等との同期を﹁OFF﹂にしてから再度"Compact DataBase"を実行すると良いです。


■対策3‥余計なバックアップを作成しない
初期設定ではクライアントが終了するたびにデータベースのバックアップを取るようになっていますが、これを放置しているととんでもない量のバックアップファイルが作成されてしまうので、設定を適当に変更しておくと良いと思います。

Java 使いの人向け ActionScript3 のクラス仕様まとめ

仕事の都合でJavaからActionScript3︵FlexじゃなくてFlash 10みたいです︶に乗り換えることになったので、クラスの仕様に親しむためまとめを作ってみました。


■参考文献
http://www.tom.sfc.keio.ac.jp/~fjedi/wiki/index.php?%A5%AF%A5%E9%A5%B9%BC%FE%A4%EA%A4%CE%BB%C5%CD%CD%28ActionScript3%29
こちらのWikiに完璧にまとまっていますので、ぶっちゃけこのWikiを見ればすべて解決すると思います。


■大原則
迷ったらJavaと同じ。
以下のJavaと違う点に掲載のない事項はすべてJavaと同じ。多重継承が無くてinterfaceが用意されている点など。


■Javaと違う点


(一)package宣言は.NETやC++のように{}で囲む必要がある。{}で囲んだ中はJavaとほぼ同じ。publicクラスが一つしか持てない等。

package {
    //以下javaと同じ
    import flash.text.TextField;
    public class Hogehoge extends TextField { /*...*/ }
}

(二)package{}の外側にファイルローカルな関数や変数やクラスを宣言できる。この領域はpackage{}の内側でインポートしたクラスやメソッドが使えない。別途インポートし直す必要がある。

package {
    import flash.text.TextField;
    public class Hogehoge extends TextField { /*...*/ }
}
// 別途インポートが必要
import flash.text.TextField;
var abesi:TextField = new TextField();

(三)dynamicクラスがある。

(四)abstractクラスやabstractメソッドが無い。

(五)その他、native, synchronized, transientなどが無い。

(六)namespaceがある。︵が、正直使い道がよく分からない︶

(七)enum型はない。

(八)コンストラクタにもfunctionを付ける必要がある。

(九)コンストラクタは必ずpublicになる。アクセス制御修飾子を指定しないとpublicとして扱われる。

(十)オーバーロードが一切使用できない。コンストラクタもオーバーロードできない。

(11)オーバーライドの際には必ずoverride修飾子を付ける必要がある。

(12)プロパティのgetter/setterを作るために特別な仕様がある︵get修飾子, set修飾子︶


その他、クラス以外の違いとして、


(一)String型が参照渡しではなく値渡し︵プリミティブ扱いなので︶

(二)関数の引数にデフォルト引数が利用できる︵オーバーロードの代わりに使う︶

function abesi(a:String="abesi", b:String="hidebu") { /*...*/ }
abesi(); //自動的にデフォルト引数が使用されるのでこういう呼び出しが可能

(三)関数の可変長引数の指定の仕方が異なる

//Javaでは
public void abesi(String... args) { /*...*/ }

//AS3では
public function abesi(...args) { /*...*/ }

■サンプル
以上を踏まえて、練習がてらにプレイスホルダー付きテキストフィールドクラスを作ってみました。

PlaceholderTextField - wonderfl build flash online

Javaではコンストラクタのオーバーロードが必要になったところ、AS3ではデフォルト引数のおかげですっきり書けました。やっぱりデフォルト引数はいいですね。あと試しにtextColorプロパティのsetterをオーバーライドしてみたのですが、そのせいでthis.textColor = 0x999999とすると意図しないタイミングでdefaultTextColorが書き換わってしまいはまりました。super.textColorとしてスーパークラスのsetterを呼びだすようにして回避。getter/setterのオーバーライドは強力ですが上手く使わないと混乱を招く諸刃の剣になりそうです。

iMovie 08 でニコニコ動画にアップロードするための動画をエンコードする設定まとめ

皆さんご存じニコニコ動画。Windows環境で動画を作ってアップするための情報はたくさんあるのですが、Mac環境用のネタが少ないので、メモしておきます。

参考にしたページは以下の通り。
http://d.hatena.ne.jp/KZE/20091106/p1
http://www.smilevideo.jp/static/www/help/#000562
http://nicowiki.com/encode.html


■環境編
Mac OS X 10.6.2 Snow Leopard
iMovie 08
QuickTime Player X (Snow Leopard付属)

iMovieは08を使用します。各所でお勧めされているiMovie HDであれば高性能でflvも扱えるらしいのですが、新しいソフトを入れて管理するのが面倒という理由により却下です。また、iMovie 09からは動画クリップごとの再生速度管理もできるらしいので、kskとかスローモーションの演出もできるためそっちのほうがお勧めです。

エンコの際にはQuickTimeを利用してエンコするため、一応QuickTimeのバージョンも載せておきました。たぶんLeopard付属のQuickTime Player 9とかでもうまくいくと思います。


■エンコ設定編
まず注意点として、私はプレミアム会員なので、以下の設定はプレミアム会員用に合わせています︵ビットレート最大1000Kbps程度、ファイルサイズ最大100MB︶。一般会員の方はビットレートを落とせばそのまま利用できるかと思います。

さて肝心の設定内容ですが、http://d.hatena.ne.jp/KZE/20091106/p1で解説されている内容とほとんど同じです。iMovie 08からはそのままflvを書き出すことができませんので、mpeg-4 H.264でエンコードします。具体的には以下の通り。


(一)メニューの﹁共有﹂から、﹁QuickTime を使用して書き出す﹂を選択する
Cmd+Eの﹁ムービーを書き出す﹂では上手くエンコできませんので注意。

(二)﹁書き出し﹂欄は﹁ムービーからMPEG-4﹂を選択する
ここで﹁ムービーからQuickTimeムービー﹂を選択するとどんなに上手くエンコしてもニコ動側で再エンコされてしまいます。絶対に﹁ムービーからMPEG-4﹂を選択すること。

(三)以下の画像のように設定する
一番上のファイルフォーマットを﹁MP4(ISMA)﹂から﹁MP4﹂にしないとH.264でエンコできませんので、まず最初に変えておくこと。
一般会員の方はムービーのデータレートをもっと落としてください。300ぐらいかな？逆に600より上げる必要はよっぽど画質が気になるか短い動画でもないかぎり無いと思います。ビットレートについては私なんぞよりもまとめWikiなどのほうが詳しいのでそちらをご覧ください。

(四)﹁ストリーミング﹂の﹁ストリーミングを使用する﹂チェックボックスは入れない
入れても大丈夫かどうかは未確認ですが、余計な物を入れると変なことになるのではと思い外してます。入れた方がいいのかな・・・


■仕上がり編
上記の設定でエンコしてみた結果がこちら。


特に問題なく見られていると思います。ただしエコノミー回避はしていないのでエコノミーが発動すると悲惨なことになりそうですが・・・


■FLVでエンコしたい編
FLVでエンコしたい場合や、もっと詳細な設定がしたい場合には、ffmpegXというツールを使うと良いようです。試していないのでここでは割愛します。
その他、iMovieから直接FLVでエンコできるようにする方法もあるらしいです。しかしH.264で直接アップロードできるようになった今となっては別にFLVにこだわるメリットも無いかも。

bulkloader.py を使って Google App Engine の本番サーバーから開発サーバーにデータを移す

Google App Engine SDKの開発サーバーのデータストアはtmpディレクトリにデータを保存するため、マシンを再起動するとデータの中身が全部消えてしまいます。毎回テストデータを用意するのが面倒なので、本番サーバーからデータを移してくるための方法を調べてみました。するとbulkloader.pyというユーティリティを使うと、簡単に本番サーバーのデータをダウンロードして保存し後からリストアすることができることがわかりました。ということで早速試してみます。
参考にしたのは以下のサイト。
http://code.google.com/intl/en/appengine/docs/python/tools/uploadingdata.html

※2010/01/31追記‥--db_filenameオプションの使い方を掲載しました。 


■前準備
app.yamlに以下の設定を追加してから、appcfg.py updateで本番デプロイを行います。

- url: /remote_api
  script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
  login: admin

これだけで準備ばっちりです。余談ですが、app-engine-patchを使うと、最初からこの設定がapp.yamlに含まれています。


■使用方法
本番サーバーからローカルにデータをダンプするときは以下のコマンドを実行します。

bulkloader.py --dump --kind=<kind> --url=http://<appname>.appspot.com/remote_api --filename=<data-filename>

たとえば私のアプリからhon_heroという名前のModelのデータをダンプしたいときには、

bulkloader.py --dump --kind=hon_hero --url=http://akisutesama.appspot.com/remote_api --filename=hon_hero.dump

などとするとうまくいきます。

ダンプしたデータを本番サーバーにリストアするときは以下のコマンドを実行します。

bulkloader.py --restore --kind=<kind> --url=http://<appname>.appspot.com/remote_api --filename=<data-filename>

--dumpが--restoreになっただけです。本番障害でデータが失われたときにリストアするためのコマンドなので、実行すると本番サーバーのデータがすべてダンプした地点のデータに置き換えられます。ご利用の際には細心の注意を！

ダンプしたデータをローカルサーバーに入れるときは以下のコマンドを実行します。

bulkloader.py --restore --kind=<kind> --url=http://localhost:8080/remote_api --filename=<data-filename> --app_id=<appname>

本番だけではなくてローカルサーバーにもリストアができます。ローカルサーバーにリストアする際の注意点として、
●dev_appserver.pyでアプリケーションが動いている必要があります。
●--urlオプションをローカルホストに書き直す必要があります。
●--app_idオプションで、自分のアプリケーションのapp_idを指定してやる必要があります。
これでローカルテストがだいぶ楽になりました。

同様にして、本番からデータをダンプしてローカルに入れるだけでなく、ローカルからデータをダンプして本番に入れることもできます。新しく実装した箇所に最初からデータを入れたい場合などに使えると思います。


■log, progress, resultを賢く使う
bulkloader.pyを実行すると、デフォルトでは以下のような名前のファイルが自動的に生成されると思います。

bulkloader-log-20091211_145622.log
bulkloader-progress-20091211_145622.sql3
bulkloader-result-20091211_145622.sql3

これらはそれぞれ﹁ログファイル﹂﹁現在どのエンティティまでダンプされたかを格納するデータベース﹂﹁実際にダンプした内容を格納するデータベース﹂となっており、上手く使えば2回目以降のダンプ実行時間を劇的に短くすることができます。

ログファイルを指定する際には--log_fileオプションを、データベースを指定する際には--db_filenameと--result_db_filenameを、それぞれ指定してください。たとえば、以下のようなシェルスクリプトを用意しておくと便利です。

#!/bin/sh

# 前回の実行結果が残っているとエラーになる（上書きしてくれない）ので、まずいったん消す
if [ -e hon_hero.dump ]; then
    rm hon_hero.dump
fi
# bulkloader.pyを実行する
# db_filenameとresult_db_filenameは一緒のファイルを指定してもかまいません。
# （その場合は、一つのsqlite3データベースに一緒に格納されます）
# db_filenameとresult_db_filenameは、db_fileやresult_db_fileのように短縮して書いても動作するみたいです
bulkloader.py --dump \
        --url=http://akisutesama.appspot.com/remote_api \
        --kind=hon_hero \
        --filename=hon_hero.dump \
        --log_file=bulkloader-log-hon_hero.log \
        --db_file=bulkloader-progress-hon_hero.sql3 \
        --result_db_file=bulkloader-progress-hon_hero.sql3

こうすることで、2回目以降はbulkloader-progress-hon_hero.sql3の中身とリモートのdatastoreの中身を比較して、追加更新のあったもののみをダウンロードし、それ以外はローカルに保存してあるデータベースの中身を利用するので、劇的に処理が速くなります。結果はこちら。

[INFO    ] Connecting to akisutesama.appspot.com/remote_api

[INFO    ] Have 2610 entities, 2610 previously transferred
[INFO    ] 2610 entities (974 bytes) transferred in 0.4 seconds

1回目のロードには130秒かかったのですが、2回目はすべてローカルに保存されているデータを使ったので、なんと0.4秒で済んでいます。

こうしてダンプしたデータをローカルサーバーでリストアするときは、たとえば以下のようなシェルスクリプトを使います。

#!/bin/sh

# --db_fileと--result_db_fileには先ほどのダンプ時に指定したものとは別のファイルが必要になります
# （先ほどのデータベースはappspot.com用として設定されるので、localhostで使用するとエラーになってしまいます）
# --db_fileと--result_db_fileには特別な名前としてskipを指定することができます
# この名前を使用するとデータベースへの書き込み/読み込みを行いません
bulkloader.py --restore \
        --url=http://localhost:8000/remote_api \
        --app_id=akisutesama \
        --kind=hon_hero \
        --filename=hon_hero.dump \
        --log_file=bulkloader-log-restore.log \
        --db_file=skip \
        --result_db_file=skip

■注意点
appspot.com以外のサーバー︵たとえばlocalhostなど︶からデータをdumpしたりrestoreしたりする際には、必ず--app_idオプションを指定する必要があります。これを忘れていて詰まりました＞＜

もし特定の条件を満たすデータのみをダウンロードしたいという場合などは、設定ファイルをPythonで書く必要がありますが、appcfg.py download_dataを使うと良いと思います。

Highcharts.js を使ってみた

最近IDEA*IDEAさんで取り上げられていたHighcharts.jsを試してみましたので、躓いた点などをメモしておきます。


■公式サイト
http://www.highcharts.com/
ダウンロード、更新履歴はこちらから見られます。ライセンスもこちらに記載があります。
個人利用、教育目的の利用、および非営利組織での利用については無料ですが、商用利用の際にはライセンスの購入︵1サイト$80、複数サイト$360︶が必要になるので注意です。


■公式リファレンス
http://www.highcharts.com/ref/
おそらく全部JSで実装されているのだと思いますが、凄いクオリティ高いです・・・


■実際に導入してみて躓いたポイント
以下、すべてバージョン1.0.2︵2009/12/09︶での気づきです。

グラフを描画する領域のサイズは、CSSでは定義できない、直接style属性に書く必要がある
たとえばCSSを使って、

<style>#chart_area {width:800px; height:400px;}</style>
<div id="chart_area" ></div>

のようにしても描画時に無視され、高さが0になります。必ず直接style属性を用いて

<div id="chart_area" style="width:800px; height:400px;"></div>

のように書く必要があります。

Zoom機能を使う際、画面のスクロールが発生すると選択領域がバグる
Mac OS X 10.6上のFirefox3.5.6とSafari4.0.4にて再現。他のブラウザは未チェックです。論より証拠、こちらのページを開いて、少し画面全体を下にスクロールしてから、チャートを縦にドラッグしてY軸ズームしようとしてみてください。まぁ、ひどいバグなのですぐに直るとは思いますが。

seriesに与えるデータは、必ずX軸方向の昇順にソートされている必要がある
特にxAxisにdatetimeを指定しているときが危険です。たとえばこのようなデータはNGです。

series: [{
        name: 'Plague Rider',
        data: [[Date.UTC(2009, 12, 4), 57.4],
        [Date.UTC(2009, 12, 3), 57.6],
        [Date.UTC(2009, 12, 2), 59.1]]
}]

かならずこのようにソートしなければなりません。

series: [{
        name: 'Plague Rider',
        data: [[Date.UTC(2009, 12, 2), 59.1],
        [Date.UTC(2009, 12, 3), 57.6],
        [Date.UTC(2009, 12, 4), 57.4]]
}]

ソートされていないと、チャートにマウスカーソルを合わせてもラベルが表示されなくなります。気づきにくいバグでした。

seriesに与えるデータにnullがあると、0として扱われる
そのため、たとえば12月1日は100、12月2日は110、12月3日はデータが分からないのでnull・・・とすると、12月3日のところだけいきなり0になってグラフが滅茶苦茶になります。回避方法としてはxAxisのtypeをdatetimeにするか、yAxisのminを自分で計算して指定してください。

xAxisのtypeがdatetimeのとき、連続していないデータがあるとsplineは使用できない︵lineは使用できる︶
原因は不明です。たぶんバグじゃないだろうかと思ってますが、公式のxAxisのtypeがdatetimeなサンプルを見てもsplineではなくてlineを使っているのでひょっとしたら仕様かもしれません。

■まとめ
公開されたのがつい先月の末ということで、まだちょっとBuggyな感じです。また、エラーメッセージがまともに表示されないため、JSファイルのどこでエラーになっているかはわかっても原因が何か分からないなど、デバッグが結構大変です。しかしながらデザイン美麗で機能豊富、カスタマイズも容易と、一通り優れた点は持ち合わせていると思います。PrototypeやjQueryなど他の外部ライブラリに依存しないのも良い点です。$80なら支払ってもよいのでは？


■Google Charts APIとの比較
やはり気になるのはGoogle Charts APIと比べてどちらが使えるかでしょう。ちょっと調べてみました。ただしGoogle Charts APIについては実際に試したことがないのであくまで公式ページのドキュメントを見て気づいた点のみです。間違っていたらごめんなさい。

Highcharts.jsの優れている点
●美麗なデザイン
●ズームや特定データの一時消去、ラベル表示など、対話性に優れたUI
●単体のJSファイルなので外部のサーバに依存しない
●Ajax対応が容易

Google Charts APIの優れている点
●より多数のグラフに対応︵レーダーチャートや地図など︶
●商用利用でも完全に無料

Django の Template Filter には任意の変数を使用することができる

公式ドキュメントに記載がなかったので、自分用メモ。

たとえばDjangoのフィルターで、

{{ some_value|floatformat:1 }}

としているところを、viewから変数を渡して

{{ some_value|floatformat:floatpoint }}

のように書くことができます。他にも

{{ now "%Y %m %d" }}

を

{{ now date_format }}

みたいに書くとか。・・・常識？

Heroes of Newerth の統計情報を集めるサイトにグラフを付けてみた

前回に引き続きおしらせです。
HoN統計情報サイトに、今度は時系列の折れ線グラフを付けてみました。


■追加した機能
今のところ、以下の3種類の統計をグラフで見ることができます。
●Usage Percent︵ヒーロー使用率、高いほうが人気があります︶
●Winning Percent︵勝利率、高いほうが強いです︶
●K/D ratio︵Kill/Deathレシオ、高いほうが俺Tueeできます︶

グラフに表示されるのはトップ10までです。11位以下のヒーローにつきましては現在ページングして見られるように対応を進めてますので少々お待ちください＞＜


■日本語化？
すみません、︵主に作者の怠慢が理由ですが︶英語版しかありません・・・でも数字ばっかりなのでたぶん大丈夫です！

Heroes of Newerth の統計情報を集めるサイトをつくってみた

ということで、作ってみました。

■そもそもHeroes of Newerthって何？
http://wikiwiki.jp/hon/
βキーが一つ余ってますので先着一名で差し上げます︵コメントなりTwitter Dなりください＞＜︶


■何これ？
http://www.heroesofnewerth.com/heroes.phpあたりからデータを抜いてきて蓄積し、現在どのヒーローが一番使われているか、どのヒーローが一番勝率がいいか、等を一覧表示しています。

デフォルトのソート順序はUsage %︵使用率︶です。テーブルのヘッダをクリックするとソート順序を変更することができます。1回クリックで昇順、2回クリックで降順です︵たぶん︶。

データは1日1回アメリカ西海岸時間の朝9時半ぐらいに更新するようにしています。日本だと深夜1時ぐらいかな。朝起きたらちょうど良く変わっていると思います。

あ、あとspan機能はいま動きません。あのセレクトボックスを選択しても何も起きません。あしからず＞＜


■で、どうするの？
Opheliaたんが余りにも使われていないのを見て嘆き悲しむといいと思います。


■今後
時系列での変化を見られるようにしたいですね。パッチが当たってScout使用率減って涙目とか、Maliken先生勝率アップとか見てみたいです。

Processingはじめました

こんにちは。いろいろ始めすぎて終わってるakisuteです。
今更ですが、積ん読していたビジュアライジング・データを読み始めたので、Processingに手を出してみました。

ビジュアライジング・データ ―Processingによる情報視覚化手法 増井 俊之 (監訳) オライリージャパン 2008-12-01 by G-Tools

楽です。とにかく楽です。文法は慣れ親しんでいるJavaですし、グラフィックを描画する以外の一切余計な機能がありません。そして、グラフィックを描画するために必要な機能は一通りあります。まさに、どうやってコンピュータにグラフィックを書かせるか、どうやってアニメーションさせるかを学ぶのに最適の環境じゃないでしょうか、これ。

たとえばこんな感じの弾幕が、

たったのこれだけのソースで動きます。すばらしい。
http://gist.github.com/246029

Processingももちろん素晴らしいですが、ビジュアライジング・データの内容そのものも素晴らしいです！

Google App Engine SDK の dev_appserver.py が自動的に index.yaml を更新してくれない時の対処法

ときどきGoogle App Engine SDKのdev_appserver.pyが自動的にindex.yamlを更新してくれない時があるので、原因を調べてみました。


■いきなりネタバレ
犯人は改行文字


■前提条件
index.yamlは、以下の様な作りになっています。

indexes:

- kind: django_admin_log #手動で定義したインデックス
  properties:
  - name: content_type
  - name: object_id
  - name: action_time

# AUTOGENERATED

# This index.yaml is automatically updated whenever the dev_appserver
# detects that a new type of query is run.  If you want to manage the
# index.yaml file manually, remove the above marker line (the line
# saying "# AUTOGENERATED").  If you want to manage some indexes
# manually, move them above the marker line.  The index.yaml file is
# automatically uploaded to the admin console when you next deploy
# your application using appcfg.py.

- kind: hon_herostatistics #ここから下は、自動的にdev_appserver.pyが追加してくれるindex
  properties:
  - name: fetchCompleted
  - name: hid
  - name: datetimeCreate
    direction: desc

このように、# AUTOGENERATEDコメントが存在すれば、その下に自動的に必要なindexを生成してくれるようになっているのですが、時々この自動生成がうまくいかない場合があります。


■症状
具体的には、以下のように余計な物をすべて消した状態のindex.yamlを用意しても、dev_appserver.pyが﹁indexが手動定義されているので、自動生成しないよ﹂とエラーを吐きます。

indexes:

# AUTOGENERATED

困りました。


■原因と対処
そこでよくよく調べてみるためにvimではないエディタでこのindex.yamlを開いてみたのですが、すると末尾の改行文字がCRLF(dos形式)になっていました。そこで私のMacの環境に合わせて改行文字をLF(unix形式)にしてみたところ、無事にdev_appserver.pyのindex自動生成が動作するようになりました。vimで操作するなら、

:set fileformat=unix

とすればよいです。

maven2を使ってScalaのHello Worldを書いてみた

先日@yuroyoro氏により開催されましたScala Hackathon #1に行ってきました。Scalaは初めてだったので、ハッカソン資料に従ってまずはHello Worldから作ってみました。資料によると、
●インタラクティブコンソールを使う
●Eclipseのプラグインを使う非推奨
●NetBeansのプラグインを使う
●IntelliJ IDEAのプラグインを使う
●テキストエディタとMavenとmaven-scala-toolsを使う
●テキストエディタとsbt(Simple build Tool)を使う
これだけの開発手法を選択することが出来るそうです。そこであえて私はMaven2を使ってScalaのHello Worldを書いてみることにしました。

参考にした資料はこちら。
http://dl.dropbox.com/u/261418/scala-hackathon/setup.html#maven2
参考にしたページはこちら。
http://scala-tools.org/mvnsites/maven-scala-plugin/plugin-info.html
http://scala-tools.org/mvnsites/maven-scala-plugin/usage_run.html


■まずはmvnプロジェクトを作る
基本的には資料に記載されている内容と全く同じです。次の殺人的に長いmvnコマンドを入力するだけでプロジェクトを作ってくれます。

mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create \
  -DarchetypeGroupId=org.scala-tools.archetypes \
  -DarchetypeArtifactId=scala-archetype-simple \
  -DarchetypeVersion=1.2 \
  -DremoteRepositories=http://scala-tools.org/repo-releases \
  -DgroupId=scalahackathon.helloworld -DartifactId=scalahackathon.helloworld

ただし、このコマンドによって生成されたデフォルトのScalaプロジェクトではそのままビルド結果を実行することができません。多少不備があります。後ほど詳しく説明します。とりあえずビルドとテストはできるので後回しにします。


■Appクラスを書かなくちゃ始まらない
生成されたデフォルトのScalaプロジェクトにあるAppクラスを書きます。このAppクラスと言う奴が、いわゆるJavaでいうmain関数を持ったメインクラスの扱いになってるみたいです。

akisute scalahackathon.helloworld$ cd src/main/scala/scalahackathon/helloworld 
akisute helloworld$ vim App.scala

package scalahackathon.helloworld

/**
* Hello world!
*
*/
object App extends Application {
  println("Hello World!");
  val l = List(1, 2, 3, 4, 5, 6); 
  l.foreach(println(_));
}

Applicationを拡張したAppクラスの中身が、そのままmain関数相当になるみたいです。このあたりよく分かってませんが、Appクラスの中で再度main関数を定義すると思いっきり怒られるのできっとそうなんだと思います。


■さて実行、その前に
さてここで

mvn scala:run

を実行すればプロジェクトをビルドして実行してくれるのですが、実は先ほど申し上げましたようにこのままではビルドには成功しますが実行に失敗します。原因はメインクラスがpom.xmlで定義されていないためです。
実行するためには、以下のように直接メインクラスを指定するか、

mvn scala:run -DmainClass=scalahackathon.helloworld.App

または以下のようにpom.xmlを修正してから実行する必要があります。毎回毎回直接メインクラスを指定するのは骨が折れるので、pom.xmlを直してみましょう。

<!-- reportingの中を直す、build要素はそのままでよい -->
<reporting>
  <plugins>
    <plugin>
      <groupId>org.scala-tools</groupId>
      <artifactId>maven-scala-plugin</artifactId>
      <configuration>
        <scalaVersion>${scala.version}</scalaVersion>
        <!-- このlaunchers要素を新規に作る。idとmainClassは必須。 -->
        <launchers>
          <launcher>
            <id>app</id>
            <mainClass>scalahackathon.helloworld.App</mainClass>
            <!-- 以下、任意要素。 args と jvmArgs を指定できます。 -->
            <!--
            <args>
              <arg>arg1</arg>
            </args>
            <jvmArgs>
              <jvmArg>-Xmx128m</jvmArg>
              <jvmArg>-Djava.library.path=...</jvmArg>
            </jvmArgs>
            -->
          </launcher>
        </launchers>
      </configuration>
    </plugin>
  </plugins>
</reporting>

修正してからmvn scala:runを実行すると、長い長いjarダウンロードの末、以下のような結果が得られます。

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'scala'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - scalahackathon.helloworld:scalahackathon.helloworld:jar:1.0-SNAPSHOT
[INFO]    task-segment: [scala:run]
[INFO] ------------------------------------------------------------------------
[INFO] Preparing scala:run
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [scala:compile {execution: default}]
[INFO] Checking for multiple versions of scala
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [scala:testCompile {execution: default}]
[INFO] Checking for multiple versions of scala
[INFO] Nothing to compile - all classes are up to date
[INFO] [scala:run]
[INFO] Checking for multiple versions of scala
[INFO] launcher 'app' selected => scalahackathon.helloworld.App
Picked up _JAVA_OPTIONS: -Dfile.encoding=UTF-8
Hello World!
1
2
3
4
5
6
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Mon Nov 23 20:59:51 JST 2009
[INFO] Final Memory: 18M/79M
[INFO] ------------------------------------------------------------------------

うまくいったみたいですね。

Mac OS Xには最初から/usr/share以下にmaven2やantが付いてくる

先日のScala Hackathon #1にて初めて気づいた驚愕の事実。なんとMac OS Xには最初からJavaの開発ツールが付いてきていたのでした。

akisute ~$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_15
OS name: "mac os x" version: "10.6.2" arch: "x86_64" Family: "mac"
akisute ~$ ant -version
Apache Ant version 1.7.0 compiled on July 20 2009
akisute ~$ which mvn
/usr/bin/mvn
akisute ~$ which ant
/usr/bin/ant

ちょっとmaven2のバージョンが古いですが、普通に使う分にはたぶん問題なさそうです。ちなみにこれらのツールは/usr/share以下に用意されています。

akisute ~$ cd /usr/share
akisute share$ ls
NotificationServer/       distcc_compilers          info/                     sandbox/
Ssh.bin                   doc/                      java/                     screen/
TargetConfigs/            emacs/                    junit/                    sdef/
aclocal/                  enscript/                 langid/                   servermgrd/
aclocal-1.10/             examples/                 libiodbc/                 skel/
ant/                      file/                     libtool/                  snmp/
apr-1/                    ftpd/                     locale/                   statsCollector/
autoconf/                 gdb/                      man/                      swig/
automake-1.10/            germantok/                maven@                    tabset/
bakefile/                 gprof.callg               mecab/                    tcsh/
bison/                    gprof.flat                misc/                     terminfo/
caldavd/                  groff/                    mk/                       texi2html/
calendar/                 gtk-doc/                  openmpi/                  texinfo/
cracklib/                 gutenprint/               openmpi-default-hostfile  uucp/
cups/                     heapdiff/                 openmpi-mca-params.conf   vim/
cvs/                      hiutil/                   openmpi-totalview.tcl     xcode-select/
derby/                    httpd/                    podcastproducer/          zoneinfo/
dict/                     icu/                      ri@                       zsh/

おお、他にもderbyとかありますね。TomcatやJettyのようなサーブレットコンテナがないので、そのまますぐにWebアプリ開発とはいきませんが、なかなか面白そうです。

・・・む、ひょっとしてこれ常識ですか？ ＞＜

表示専用のカレンダーJSが欲しい

日付を選択するためのカレンダーJSはよく見るのですが、表示に特化したものは余り見ないので。たとえばこんな感じでjQueryのプラグインみたいに使えるカレンダーが欲しいのです。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Calendar object test</title>
<script type="text/javascript" src="js/jquery-1.2.6.min.js" type="text/javascript"></script>
<script type="text/javascript" >
    $(function(){
        // add a new text and set its style
        $("calendar")
        .from(2009, 10, 30)
        .to(2009, 10, 31)
        .text("Halloween")
        .color("#ffcccc")
        .style("bold")
        .backgroundcolor("#ffddcc");
    });

    // calendar event handling
    // use customized Event object which has "day" and "from, to" attr
    $("calendar").click(function(e){
        day = e.day
        this.day(day).text("clicked")
    });
    $("calendar").select(function(e){
        from = e.from
        to = e.to
        this.from(from).to(to).text("selected")
    });
</script>
</head>
<body>
    <div id="calendar">Calendar will be shown here</div>
</body>
</html>

どうでしょ？探せばあると思うのですが・・・

PDFをiPhoneから生成するサンプルプロジェクトを公開いたしました

本編はこちら
エラーハンドリング編はこちら

ここまでの成果をgithubにアップいたしました。ダウンロードしてXcodeを開き、ターゲットのビルド設定から開発用コードサインをご自身のものと入れ替えてビルドすれば、すぐにPDF作成がお試しいただけます。
http://github.com/akisute/iPhonePDF

ライセンスはlibHaruと合わせてZLIB/LIBPNG Licenseにしてみました。


当方でも動作確認は行っておりますが、何か不具合ございましたらご一報いただけると幸いです。

libHaru on iPhone: Objective-Cでエラーハンドリング

前回記載できなかったエラーハンドリングについて軽くさわってみました。


■libHaruのエラーハンドリング
http://libharu.org/wiki/Documentation/Error_handlingに詳しく書いてあります。要するに、一番最初のPDFドキュメントを生成するところでエラーハンドラ関数を渡したらあとはエラーが発生するたびにその関数が呼び出されるみたいです。

// まずはヘッダファイルの中で
// ユーザーデータ用の構造体の宣言と、エラーハンドラ関数のプロトタイプ宣言をしておく

typedef struct _PDFService_userData {
    HPDF_Doc pdf;
    PDFService *service;
    NSString *filePath;
} PDFService_userData;

// エラーハンドラ関数のシグネチャは常にこうでなければならない
// 関数名は自由に決めて良いが、引数と返り値は決められている
void PDFService_errorHandler(HPDF_STATUS   error_no,
                             HPDF_STATUS   detail_no,
                             void         *user_data);

// 注意点として、エラーハンドラ関数はHPDF_Newより前の行で実装しておかなければならない
// （プロトタイプ宣言しておいてもだめみたいです）
void PDFService_errorHandler(HPDF_STATUS   error_no,
                             HPDF_STATUS   detail_no,
                             void         *user_data) {
    // ユーザーデータを取得する
    // C言語の構造体からでもObjective-Cのクラスが取り出せますよ
    PDFService_userData *userData = (PDFService_userData *)user_data;
    HPDF_Doc pdf = userData->pdf;
    PDFService *service = userData->service;
    NSString *filePath = userData->filePath;

    // エラーハンドリング後、PDF関連の処理を続行したい場合は
    // このHPDF_ResetError関数を呼び出す必要がある。
    // これを呼び出さないと後続の処理がうまくいかない。
    HPDF_ResetError(pdf);

    // 逆にエラーハンドリング後、PDF関連の処理をすべて中断したい場合には
    // HPDF_Free関数を使ってpdfオブジェクトを解放するとよい。こうすると、以後の
    // HPDF関連の関数はすべて何もしないで終了してくれる。ただし、同じpdfオブジェクトを
    // 2回HPDF_Freeしてしまうとエラーになるため、HPDF_HasDocを使って制御すること
    HPDF_Free(pdf);
}

// あとはPDFドキュメント生成時に関数とユーザーデータを引数として渡す
int main(int argc, char** args) {
    PDFService_userData userData;
    HPDF_Doc pdf = HPDF_New(PDFService_defaultErrorHandler, &userData);
    userData.pdf = pdf;
    userData.filePath = @"/var/tmp/hogehoge.pdf";
    // 以下省略
}

■CとObjective-Cをつなげる
C言語的にはこれでよいのですが、Objective-C、ひいてはCocoa Touchフレームワーク的にはこういうエラー処理はdelegateにしてしまったほうが便利です。たとえば、PDFファイルを生成するためのObjective-CクラスPDFServiceに、PDFServiceDelegateを持たせて運用してみましょう。libHaruのエラーハンドラ関数を以下のように作ってみます。

void PDFService_defaultErrorHandler(HPDF_STATUS   error_no,
                                    HPDF_STATUS   detail_no,
                                    void         *user_data)
{
    // ユーザーデータを展開
    PDFService_userData *userData = (PDFService_userData *)user_data;
    HPDF_Doc pdf = userData->pdf;
    PDFService *service = userData->service;
    NSString *filePath = userData->filePath;
    
    // 以後のPDF作成処理をすべてストップする
    HPDF_Free(pdf);
    
    // Delegate呼び出し
    if (service.delegate) {
        [service.delegate service:service
         didFailedCreatingPDFFile:filePath
                          errorNo:error_no
                         detailNo:detail_no];
    }
}

あとはこのDelegateを適当なViewControllerなどに準拠させて、

#pragma mark -
#pragma mark delegate method
- (void)service:(PDFService *)service
didFailedCreatingPDFFile:(NSString *)filePath
        errorNo:(HPDF_STATUS)errorNo
       detailNo:(HPDF_STATUS)detailNo
{
    NSString *message = [NSString stringWithFormat:@"Couldn't create a PDF file at %@\n errorNo:0x%04x detalNo:0x%04x",
                         filePath,
                         errorNo,
                         detailNo];
    UIAlertView *alert = [[[UIAlertView alloc] initWithTitle:@"PDF creation error"
                                                     message:message
                                                    delegate:nil
                                           cancelButtonTitle:@"OK"
                                           otherButtonTitles:nil] autorelease];
    [alert show];
}

とすると、冒頭のイメージのようになります。

libHaruを使ってiPhoneアプリからPDFを作成する

ある日突然、iPhoneからPDFファイルを作ったら面白そうだと思ったので、早速試してみることにしました。既に先駆者の方がいらっしゃるかと思ったのですが、調べてもそれらしい資料が無いので自力でなんとかしてみることにしました。需要はあまり無いかと思いますが、何かのお役に立てば幸いです。


■PDFファイルを生成する方法
まずはPDFファイルを生成する方法を知らなければ話になりません。ということで、調査しました。
●一からライブラリを自作する
jspdf︵http://code.google.com/p/jspdf/︶などという漢気あふれるライブラリがあるのですから、やってやれないことはない！と思い、さっそくPDFの仕様書︵http://www.adobe.com/devnet/pdf/︶をAdobe社からダウンロードしてきたのですが、31MB, 500ページ以上あります。なにこれこわい。
●Adobe PDF Library︵http://www.adobe.com/devnet/pdf/library/ http://www.est.co.jp/pdfl/index.html︶
本家のライブラリです。日本ではイースト社がライセンスしてるみたいですが、どう見ても有償です。チェンジお願いします。
●libHaru︵http://libharu.org/wiki/Main_Page︶
こうして散々探した挙句ついに見つけた至高のPDFライブラリがこちら。C言語で書かれており、iPhoneでもバッチリ動きそうです！もちろんオープンソース！素晴らしい！
ということで、今回はlibHaruを使ってみようと思います。


■libHaruをXcodeでビルドする
1．libHaruのソースコードをダウンロードしてXcodeプロジェクトに追加
最新のソースコードをhttp://libharu.org/wiki/Downloadsからダウンロードしてきて解凍します。このまま自分のMacで使えるようにするだけなら. configureしてmakeしてmake installすれば一発なのですが、あいにくそれではiPhoneで動かすことが出来ません。
includeディレクトリにヘッダファイルが、srcディレクトリにCソースコードが入ってますので、これら全部を自分のXcodeプロジェクトにコピーして取りこみます。


2．libpngのソースコードをダウンロードしてXcodeプロジェクトに追加
libHaruを用いてPDFに画像を出力したいときには、別途libpngが必要になります。そこで、libpngも一緒にビルドすることにします。libpngのソースコードはhttp://www.libpng.org/pub/png/libpng.htmlから入手できますので、これをダウンロードしてきてXcodeに追加してビルドすればよいのですが、ここではもっと簡単で確実に動く方法をご紹介します。そう、﹁既にlibpngをビルドして使っている他のiPhoneプロジェクトからパクる﹂です！︵もちろん、きちんとライセンスに違反していないことを確認しましょう︶
おあつらえ向きなことに、cocos2d for iPhoneの0.8.1以降︵http://code.google.com/p/cocos2d-iphone/source/browse/#svn/trunk︶では内部的にlibpngを使用しています。これを真似しない手はありません。さっそくcocos2d for iPhoneの最新ソースを取得し、Xcodeでプロジェクトを開いて、Support/external/libpng以下のソースをコピーして自分のプロジェクトに追加しましょう。


3．libHaruをconfigureする
. configureで動けばいいのですが、多分. configureしても今の自分のMacの環境に合わせてConfigureされてしまい、iPhoneでは動かないだろうと思ったので、自分の手でconfigureすることにしました。といっても、直すのは一箇所だけです。includeディレクトリに入っていたhpdf_config.h.inファイルを以下のように修正します。

/* include/hpdf_config.h.in.  Generated from configure.in by autoheader.  */

/* Define to 1 if you have the  header file. */
#undef HAVE_DLFCN_H
#define HAVE_DLFCN_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_INTTYPES_H
#define HAVE_INTTYPES_H 1

/* Define to 1 if you have the `png' library (-lpng). */
#undef HAVE_LIBPNG
#define HAVE_LIBPNG 1

/* Define to 1 if you have the `z' library (-lz). */
#undef HAVE_LIBZ
#define HAVE_LIBZ 1

/* Define to 1 if you have the  header file. */
#undef HAVE_MEMORY_H
#define HAVE_MEMORY_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_STDINT_H
#define HAVE_STDINT_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_STDLIB_H
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_STRINGS_H
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_STRING_H
#define HAVE_STRING_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_SYS_STAT_H
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_SYS_TYPES_H
#define HAVE_SYS_TYPES_H 1

/* Define to 1 if you have the  header file. */
#undef HAVE_UNISTD_H
#define HAVE_UNISTD_H 1

/* debug build */
#undef HPDF_DEBUG
#ifdef DEBUG
#define HPDF_DEBUG 1
#endif

/* debug trace enabled */
#undef HPDF_DEBUG_TRACE
#ifdef DEBUG
#define HPDF_DEBUG_TRACE 1
#endif

/* libpng is not available */
#undef HPDF_NOPNGLIB

/* zlib is not available */
#undef HPDF_NOZLIB

/* Define to the address where bug reports for this package should be sent. */
#undef PACKAGE_BUGREPORT

/* Define to the full name of this package. */
#undef PACKAGE_NAME

/* Define to the full name and version of this package. */
#undef PACKAGE_STRING

/* Define to the one symbol short name of this package. */
#undef PACKAGE_TARNAME

/* Define to the version of this package. */
#undef PACKAGE_VERSION

/* Define to 1 if you have the ANSI C header files. */
#undef STDC_HEADERS
#define STDC_HEADERS 1

/* Define to `unsigned int' if  does not define. */
/* #undef size_t */

書き換えたら、ファイル名をhpdf_config.hに変更します。


4．Xcodeから新規ビルドターゲットを作成する
ソースコードの準備が出来たら、次はソースコードをビルドしてlibharu.aとlibpng.aを生成するためのビルドターゲットを新規に作成します。ビルドターゲットは使い方を覚えると非常に便利です。


最初にlibpngのビルドターゲットを作ります。libpngのビルドターゲットは、2．でご紹介したとおりcocos2d for iPhoneの最新ソースのXcodeプロジェクト内に既に用意されていますので、これを真似して作るとよいです。ただし、libpngをビルドする際にzlib.dylibが必要になりますので、自分のプロジェクトにzlib.dylibを追加するようにしておいてください。最初からiPhone SDKの一部として用意されています。


続いてlibHaruのビルドターゲットを作成します。こんな感じです。


最後に、libharu.aを自分のiPhoneプロジェクトの依存ライブラリに追加します。


5．レッツコンバイン！
これでビルドする準備が整いましたので、いよいよビルドします。
緊張の一瞬！Cmd+Bをプログラムドライブ！！


できました！！！！


■Hello, libHaru!
無事にビルドが完了いたしましたので、次はいよいよPDFを生成してファイルに出力してみます。

// TEST CODE: testing libharu
NSString *path = nil;
const char *pathCString = NULL;
NSLog(@"[libharu] PDF Creation START");
HPDF_Doc pdf = HPDF_New(NULL, NULL);
NSLog(@"[libharu] Adding page 1");
HPDF_Page page1 = HPDF_AddPage(pdf);
NSLog(@"[libharu] SetSize page 1");
HPDF_Page_SetSize(page1, HPDF_PAGE_SIZE_A4, HPDF_PAGE_LANDSCAPE);
NSLog(@"[libharu] TextOut page 1");
HPDF_Page_BeginText(page1);
HPDF_UseJPFonts (pdf);
HPDF_UseJPEncodings (pdf);
HPDF_Font fontEn = HPDF_GetFont(pdf, "Helvetica", "StandardEncoding");
HPDF_Font fontJp = HPDF_GetFont(pdf, "MS-Mincyo", "90ms-RKSJ-H");
HPDF_Page_SetFontAndSize(page1, fontEn, 16.0);
HPDF_Page_TextOut(page1, 100.00, 100.00, "Hello libHaru!");
HPDF_Page_SetFontAndSize(page1, fontJp, 16.0);
HPDF_Page_TextOut(page1, 100.00, 60.00, [@"はろー日本語" cStringUsingEncoding:NSShiftJISStringEncoding]);
HPDF_Page_EndText(page1);
NSLog(@"[libharu] Path drawing page 1");
HPDF_Page_SetLineWidth(page1, 4.0);
HPDF_Page_SetRGBStroke(page1, 1.0, 0, 0);
HPDF_Page_Rectangle(page1, 200, 200, 40, 150);
HPDF_Page_Stroke(page1);
NSLog(@"[libharu] PNG image drawing page 1");
path = [[NSBundle mainBundle] pathForResource:@"portrait2"
                                       ofType:@"png"];
pathCString = [path cStringUsingEncoding:NSASCIIStringEncoding];
NSLog(@"[libharu] LoadPngImageFromFile path:%@\n pathCString:%s", path, pathCString);
HPDF_Image image = HPDF_LoadPngImageFromFile(pdf, pathCString);
HPDF_Page_DrawImage(page1, image, 300, 50, 245, 319);

// Get documents directory
NSArray *arrayPaths = 
NSSearchPathForDirectoriesInDomains(
                                    NSDocumentDirectory,
                                    NSUserDomainMask,
                                    YES);
path = [arrayPaths objectAtIndex:0];
path = [path stringByAppendingPathComponent:@"test.pdf"];
pathCString = [path cStringUsingEncoding:1];
NSLog(@"[libharu] SaveToFile path:%@\n pathCString:%s", path, pathCString);
HPDF_SaveToFile(pdf, pathCString);
NSLog(@"[libharu] Freeing PDF object ");
HPDF_Free(pdf);
NSLog(@"[libharu] PDF Creation END");

これを実行すると、アプリのDocumentディレクトリにtest.pdfが生成されるはずです。


■実機で試してみる
シミュレータでは動くようになりましたが、実機で動かなければ何の意味もありません。ということで、いよいよ実機でテストしてみます！生成したPDFファイルを表示するためのUIWebViewを作成し、実機で表示してみた結果がこちら。


Hooray!!


■さて次は
いよいよ次からが本番、UIViewの中身をPDFに変換して出力する機能を作ってみようと思います！

iPhone向けに最適化されたPNGをlibpngで扱う方法

メモ。
iPhoneアプリのバンドルに同梱したPNGファイルは、ビルド時に最適化処理が行われてしまうため、そのままではlibpngで読み込むことが出来ません。iPhone向けに最適化されたPNGをlibpngで扱う方法は、いまのところ二つ。


1‥最初から最適化をしないようにする
参考にしたページはこちら。
http://d.hatena.ne.jp/wasabi-arts/20090301/1235856525

このように、IPHONE_OPTIMIZE_OPTIONS=-skip-PNGsを追加するか、

またはこのように、最初っから圧縮をしないように設定する。


2‥最適化したファイルをいったんUIImageで読み出して、再度PNGでファイル書きだしする
いったんUIImageを使って当該ファイルをロードして、ファイルにpng形式で書き出せばよいらしいです。
︵@nakamura001さんありがとうございます！︶

[2009/10/24 22:20追記]
@nakamura001さんがご自身のブログで検証結果をアップされてます。
http://d.hatena.ne.jp/nakamura001/20091024/1256371800

UIButtonからPNG画像を抜く方法ですが、これを応用すればUIButtonに最適化されたPNGを使用していても普通のPNG画像を取得することが出来ます。私の環境でもテストしたところ、うまくいきました！

PythonのEvernote APIをProxyに対応させることに成功しました

前回記事で見事大失敗したので、今回改めてThriftのTHttpClientのPython実装にProxy機能を持たせるチャレンジを行いました。結果、無事成功しました！さっそく共有させていただきたいと思います。


■PythonのEvernote APIをProxyに対応させる方法
まずはEvernote APIの中で使用されている通信クラス、thrift.transport.THttpClientを修正する必要があります。
以下のようにTHttpClient.pyを修正してください︵または別名ファイルとして保存してください︶。

http://gist.github.com/204501

修正しましたら、APIを呼びだす側のコードを以下のように変更してください。

# これを・・・
# import thrift.transport.THttpClient as THttpClient
# こうする
import thrift.transport.MyTHttpClient as THttpClient
import evernote.edam.userstore.UserStore as UserStore
import evernote.edam.userstore.constants as UserStoreConstants
import evernote.edam.notestore.NoteStore as NoteStore
import evernote.edam.type.ttypes as Types

##########
# 中略
##########

# プロキシを使わなくて良いときはproxy引数を無視すればよい
# userStoreHttpClient = THttpClient.THttpClient(userStoreUri)
# プロキシを使いたいときはこうする
userStoreHttpClient = THttpClient.THttpClient(userStoreUri, proxy="myproxy.example.com:8080")
userStoreProtocol = TBinaryProtocol.TBinaryProtocol(userStoreHttpClient)
userStore = UserStore.Client(userStoreProtocol)

versionOK = userStore.checkVersion(applicationClientNameString,
                                   UserStoreConstants.EDAM_VERSION_MAJOR,
                                   UserStoreConstants.EDAM_VERSION_MINOR)

これだけで通信時にプロキシを介してくれるようになりました！


■何をやっているか
そもそもThriftのTHttpClientはプロキシを使うこと自体が全く想定されていない？作りになってまして、他の言語の実装でもすべてプロキシは使えるようになっていません。たとえばC#での実装はこちら︵http://issues.apache.org/jira/secure/attachment/12391517/THttpClient.cs︶ですが、これもプロキシは使えません。connection.Proxy = null;ってなってます。

というわけで、勝手に自分でTHttpClientを再実装してプロキシを使えるようにしています。あんまりよい方法ではないと思いますので、本番サーバーなどでは真似しないでください＞＜


■前回からの改良点
前回はhttplib.HTTPを使うのを辞めて、httplib.HTTPConnectionクラスを使うようにしたのですが、コレがそもそもの大失敗でした。といいますか、httplib.HTTPのソースを見たら内部でばっちりhttplib.HTTPConnectionが使われてるじゃないですかorz

self.__http = httplib.HTTP(self.host, self.port)
self.__http._conn #これでhttplib.HTTPConnectionが取得できる

そして前回最大の失敗がread()メソッドが呼ばれるたびに接続をcloseしてしまっていたところです。httplib.HTTPの実装をみてようやく気づいたのですが、ここでは接続をCloseしてはいけないんですね・・・
これらを踏まえて、今回はTHttpClientの中でhttplib.HTTPをそのまま使うようにして解決しました。

他にもhttplib.HTTPResponseは以下のようにしてファイルポインタが取得できるとか

response = conn.getresponse()
response.fp # これがファイルポインタ。httplib.HTTP.read()でも使われている

httplibはとにかくドキュメントに書いてない仕様が多すぎです＞＜

UIViewControllerのtouchesBeganとかtouchesEndedが上手く機能しなかったと思ったら・・・

ひさっびさに普通のUIKitを使ったiPhoneアプリを作ったりし始めたらかなりの範囲を忘れてしまっていて大ハマりしてます。中でも一番困ったのがこれ。

@implementation AbesiViewController

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.wantsFullScreenLayout = YES;
}

- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
}

- (void)dealloc
{
    [super dealloc];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    // なぜか出力されない
    NSLog(@"touchesBegan");
}

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
    // なぜか出力されない
    NSLog(@"touchesMoved");
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    // なぜか出力されない
    NSLog(@"touchesEnded");
}

@end

とまぁ、なんの変哲もないUIViewControllerにタッチを扱うためのイベントハンドラを搭載してみただけなのですが、コレがまぁ動かない動かない！

こういうときに考えられる原因は、だいたいがInterface BuilderでInteraction Enabledのチェックを入れ忘れているとか、ViewControllerとViewをつなぎ忘れているとかそんなのばっかりなので真っ先に調べてみました。が、やはり問題は見つかりません。

試しにUIViewControllerではなくUIViewにtouchesBeganを載せてみるとコレが動くんです。ああ、OS 3.1.2ぐらいから挙動が変わったのかなとか思っていたら、

http://stackoverflow.com/questions/1025574/uiviewcontroller-not-receiving-touchesbegan-message
OK, I'm a dummy. It works fine. The problem was, I didn't realize I was sending a release message to the UIViewController without having retained it elsewhere first. So that was causing the problem.
あーーー！そうだ！！！UIViewControllerをretainしてない！！！orz

retainしたら解決しました。ほんと腕がなまってる・・・

PythonのEvernote APIをプロキシに対応させようとして挫折した

Evernote APIで使用されているThriftのTHttpClientクラスには、プロキシの設定を行うためのインターフェースが用意されていません。そのため、プロキシ越しにEvernote APIの呼び出しを行うことが出来ないみたいです。
︵ひょっとしたら出来るのかもしれませんが、調べた範囲ではわからず︶

そこでThriftのTHttpClientクラスのPython実装をプロキシに対応させるべくチャレンジしてみました。

http://gist.github.com/204501

基本的には元々httplib.HTTPで実装されていたところをhttplib.HTTPConnectionに変えただけなのですが、ところがこれがうまくいかない。このクライアントで/edam/user/にCheckVersionリクエストを投げると500エラーが返却されてしまいます。で、500エラーを拾うと再度試行するようになっているのか、あえなく無限ループに突入＞＜
プロキシの設定が間違っているのかと思い、試しにプロキシを外してデバッグログをはかせた結果がこちら。

send: 'POST /edam/user HTTP/1.1\r\nHost: sandbox.evernote.com:443\r\nAccept-Encoding: identity\r\nHost: sandbox.evernote.com\r\nContent-Type: application/x-thrift\r\nContent-Length: 82\r\n\r\n'
send: '\x80\x01\x00\x01\x00\x00\x00\x0ccheckVersion\x00\x00\x00\x00\x0b\x00\x01\x00\x00\x00(Python URL to Evernote/0.1; Python/2.5.2\x06\x00\x02\x00\x01\x06\x00\x03\x00\r\x00'
debug: HTTPConnection
Request-sent None
reply: 'HTTP/1.1 200 OK\r\n'
header: Server: Apache-Coyote/1.1
header: Content-Type: application/x-thrift
header: Content-Length: 29
header: Date: Wed, 07 Oct 2009 09:04:29 GMT
read start
read POST request
send: 'POST /edam/user HTTP/1.1\r\nHost: sandbox.evernote.com:443\r\nAccept-Encoding: identity\r\n\r\n'
read getresponse
debug: HTTPConnection
Request-sent None
reply: 'HTTP/1.1 500 \r\n'
header: Server: Apache-Coyote/1.1
header: ETag: W/"3401-1254794526000"
header: Last-Modified: Tue, 06 Oct 2009 02:02:06 GMT
header: Content-Type: text/html
header: Content-Length: 3401
header: Date: Wed, 07 Oct 2009 09:04:29 GMT
header: Connection: close
read start
read POST request

うーん、HTTPSの実装が間違っているのか、リクエストパラメータが間違っているのか。1回目のリクエストはうまくいくけど2回目のリクエストが失敗しがちみたいです。もう少し調査してみます。


あ！今気づいた！！
2回目のリクエスト時︵readメソッド実行時︶のHTTPヘッダがめちゃくちゃだ！！ここを直せば動くかも。

Evernote APIためしてみた

API Keyくださいとお願いしたらすぐに発行してもらえたので、試しにEvernote APIを触ってみました。


■準備


●http://www.evernote.com/about/contact/support/?application=EvernoteAPI&summary=API+Key+Request#inquiryからAPIキーくださいとお願いする

●http://www.evernote.com/about/developer/api/からSDKみたいなのをダウンロードして解凍

http://blog.lilyx.net/2008/11/03/evernote-api/を見ると発行するときに手間がかかったとの記述がありましたが、私の場合は半日で発行されました。まぁ1年たってますし、状況が良くなったのかもしれませんね。申請時にアプリの詳細を事細かに書いたのが良かったのかもしれません。


■Hello Worldを動かす
まず最初にsandbox環境に自分用のアカウントを作成します。http://sandbox.evernote.com/login.jspにアクセスして、いつも通りアカウントを作成。忘れがちなので注意です。
アカウントが出来たら、ダウンロードしてきたSDKに最初っからサンプルスクリプトがついてきているので、こちらを実行するだけです。今回はPythonのサンプルスクリプトを試してみました。

cd sample/python
cp * ../../lib/python
cd ../../lib/python
python EDAMTest.py username password

■ENMLを試してみる
今回の最終目的は﹁はてブみたいにURLだけ渡したら勝手にEvernoteに取り込んでくれる﹂ことなので、まずはどのぐらい気軽にHTMLを取り込めるかを調べてみました。Evernoteの本文はENMLというHTMLに似たマークアップ言語で記述されています。
http://www.evernote.com/about/developer/api/evernote-api.htm#_Toc200272588
こちらの記載を読んでみたところ、かなーーーーーり面倒くさいということが判明。htmlタグやbodyタグが含められないのはまだいいとして、id属性もclass属性も許可されません。さらに困ったことに・・・
pタグ閉じてないからダメー。

brタグ閉じてないからダメー。

さすがXML、厳しい。どうやらHTMLとは全く互換性がないと考えた方が良さそうです。
HTMLをENMLに変換するライブラリとかないかなー？

ENMLは死ぬほど面倒ですが、それ以外のところは今のところ簡単です。

cocos2dでParticleSystemを使うときのメモ

懲りずにcocos2dで遊んでます。今回はParticleSystemを触ったときに気づいたことなどをメモしてみます。


■ParticleSystemが放出するParticleを回転させたい
http://www.cocos2d-iphone.org/api-ref/latest-stable/interface_particle_system.html
こちらの公式リファレンスには2009/10/02現在記載されていませんが、startSpin, startSpinVar, endSpin, endSpinVarというプロパティが用意されており、こちらの値を調整することで放出される個々のParticleに回転を与えることが出来ます。

        // angle of particles
        startSpin = 90;
        startSpinVar = 0;
        endSpin = 1800;
        endSpinVar = 3600;

注意点として、PointParticleSystemを継承したParticleSystemでは、spin系のプロパティは利用できないみたいです。パフォーマンスで劣るそうですが、QuadParticleSystemを継承するようにしましょう。

結果はこんな感じ。青いミミズみたいなのがParticleSystemから放出しているParticleです。
回転の中心軸の位置がおかしいのかな？


■Particleの大きさを変化させたくない
endSizeにkParticleStartSizeEqualToEndSizeを指定すると、放出されたParticleの大きさが変化しなくなります。

        // size, in pixels
        startSize = 90.0f;
        startSizeVar = 30.0f;
        endSize = kParticleStartSizeEqualToEndSize;
        endSizeVar = 30.0f;

■応用‥Particleの回転を変化させたくない
現在のcocos2dではまだサポートされていませんので、適当にParticleSystem.mのコードを書き換えます。具体的には180行目のあたりを以下のようにします。

 // angle
 float startA = startSpin + startSpinVar * CCRANDOM_MINUS1_1();
 particle->angle = startA;
    if (endSpin == kParticleStartSpinEqualToEndSpin ) 
        particle->deltaAngle = 0;
    else {
        float endA = endSpin + endSpinVar * CCRANDOM_MINUS1_1();
        particle->deltaAngle = (endA - startA) / particle->life;
    }

これで放出されたParticleがくるくる回転するのを防げます。でもこのマジックナンバーを使った実装、正直イマイチです。

 // angle
 float startA = startSpin + startSpinVar * CCRANDOM_MINUS1_1();
 particle->angle = startA;
    if (spinFixed) 
        particle->deltaAngle = 0;
    else {
        float endA = endSpin + endSpinVar * CCRANDOM_MINUS1_1();
        particle->deltaAngle = (endA - startA) / particle->life;
    }

個人的にはこの方に実装するほうが好きです。パフォーマンスは悪いかも。

各種WebサービスのAPI認証方法を調べてみた

自分でWeb サービスを作る際に、APIの認証ってどうやって作ればよいのだろうと思い立ち、各種Web サービスのAPIの認証方法を調べてみました。


■Google
参考にしたページはこちら。
http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI


認証方法

ユーザーIDおよびパスワードを元に、Cookieを生成

認証時のAPI通信

HTTPS POST

認証URL

https://www.google.com/accounts/ClientLogin

認証後のAPI通信

HTTP GET/POST, HTTPS GET/POST

トークン送出方法

HTTPリクエストヘッダのCookie属性に﹁SID﹂を含める
Cookieを使う方法ですので、Webブラウザを用いるWebアプリケーションに対する認証の場合は非常に簡単ですが、クライアントアプリケーションの場合は、認証URLのレスポンスを元にSIDを保存し、HTTPリクエストヘッダのCookie属性にSIDを追加する処理を自分で行う必要があるため、ちょっとだけ面倒です。それでもシンプルで分かりやすい方法だと思います。


■Remember the Milk(RTM)
参考にしたページはこちら。
http://www.rememberthemilk.com/services/api/authentication.rtm
http://www.rememberthemilk.com/services/api/methods/rtm.auth.getFrob.rtm


認証方法

APIキー、開発者とサーバー間の共通鍵、使い捨てセッションの3つを元に、セッションIDを生成

認証時のAPI通信

HTTP GET

認証URL1︵使い捨てセッションの取得︶

http://api.rememberthemilk.com/services/rest/?method=rtm.auth.getFrob&api_key=abc123

認証URL2︵本認証︶

http://www.rememberthemilk.com/services/auth/?api_key=abc123&perms=delete&frob=123456&api_sig=zxy987

認証URL2︵認証済みセッションIDの取得︶

http://api.rememberthemilk.com/services/rest/?method=rtm.auth.getToken&api_key=abc123&frob=123456


認証後のAPI通信

HTTP GET

トークン送出方法

HTTPパラメータに﹁auth_token﹂を含める
Webアプリケーションだけではなくクライアントアプリケーションへの対応を行っているためか、先ほどのGoogleのAPIと比べて格段に難しくなります。その代わり、HTTPS POSTを用いなくても、HTTP GETのみで認証を行うことが出来ます。こういうのをRESTって言うんでしょうか？正直良く分からず。
以下、クライアントアプリケーションでの認証手順。

1．APIキー申請をすると、以下の2つの値がもらえる
api_key・・・開発者がサーバーからもらえる公開鍵。公開鍵なので外に漏れても良い。
shared secret・・・開発者とサーバーが持つ共通鍵。絶対に外に漏れてはならない。

2．api_keyを元に、使い捨てセッションを生成する
frob・・・使い捨てセッション。以降、認証手続きの間のみ利用する。
frobの意味についてはhttp://en.wikipedia.org/wiki/Frobを参照。

3．shared secretと認証URLのリクエストパラメータを元に、api_sigを生成する。
認証URLには以下の3つのリクエストパラメータがつきます。

api_key=abc123&perms=delete&frob=123456

これを記号を抜いて結合して、

api_keyabc123permsdeletefrob123456

先頭にshared secretをつけて、

BANANASapi_keyabc123permsdeletefrob123456

md5 hash値を計算します。計算結果がapi_sigになります。

md5('BANANASapi_keyabc123permsdeletefrob123456')

4．api_key, frob, api_sigの値を元に、ユーザー認証画面を開いてIDとパスワードを入力してもらう
ここで認証URL2をユーザーにブラウザで開いてもらって、IDとパスワードを入力してもらえば認証が完了します。

5．認証が完了したセッションIDを取得する
auth_token・・・セッションID。次以降のリクエストには、全てこのauth_tokenをHTTPリクエストパラメータとして含める。


■Evernote
参考にしたページはこちら。
http://www.evernote.com/about/developer/api/evernote-api.htm#_Toc200272584


認証方法

メールアドレス、パスワード、consumerKey, consumerSecretを元に、セッションIDを生成

認証時のAPI通信

Thrift TBinaryProtocol wrapping a THttpClient transport

認証URL

https://www.evernote.com/edam/user

認証後のAPI通信

Thrift

トークン送出方法

UserStore Authentication Token？を付与する
Thriftというフレームワークが使われているようです。Thriftの実装がC, Java, PHP, Python, Perl, Rubyなどで用意されていて、クライアントはこれらの実装を用いて認証すればよいらしいです。詳細は良く分かりませんが、こちらもAPI Keyと共通鍵を利用しているため、比較的RTMの認証に近いことをしているように見えます。
ちなみに上記はクライアントアプリケーション用の認証で、Webアプリケーション用の認証にはOAuthを使用しています。OAuthについてはまた別の機会に調べます。


■Twitter
参考にしたページはこちら。
http://usy.jp/twitter/index.php?Twitter%20API
http://twitter.pbworks.com/API%20Docs#Authorization
http://watcher.moe-nifty.com/memo/2007/04/twitter_api.html


認証方法1

ユーザーID、パスワードを利用したBasic認証

認証時のAPI通信

なし

認証URL

なし

認証後のAPI通信

HTTP GET

トークン送出方法

http://username:password@twitter.com/のようにしてユーザーIDとパスワードを送出する


認証方法2

ユーザーIDおよびパスワードを元に、Cookieを生成

認証時のAPI通信

HTTP POST︵HTTPSは無い？︶

認証URL

http://twitter.com/login

認証後のAPI通信

HTTP GET

トークン送出方法

HTTPリクエストヘッダのCookie属性に﹁_twitter_session﹂を含める


認証方法3

OAuth
詳細については不明
以下、http://watcher.moe-nifty.com/memo/2007/04/twitter_api.htmlから転載。

public_timeline の取得等一部の API を除くほとんどの API で、認証を使用する。応答に protected なユーザに関する情報が含まれる可能性のある API は認証が必須となっている。
現在、OAuth認証とBASIC認証が使用可能。

トークンベースの認証 OAuth は、今のところベータ版であるが、将来、OAuth 認証を標準的な認証方法にする予定。
BASIC認証で使用するユーザ名はメールアドレスまたはスクリーン名のどちらでも構わない。

Webブラウザ等を経由して Twitter にログインしたときに発行される cookie を使うことで BASIC 認証の代わりにすることもできるが、公式には cookie を使っての API 実行はサポートしない。
(訳者による注記: API によっては cookie 使用時も BASIC 認証が要求されるものもある。また、BASIC認証での API 実行と cookie を利用しての API 実行では、異なる結果が返る API もある。特に、protected なユーザに関する挙動に違いが見られる。
OAuth 認証時も API の応答に cookie が含まれるが、次回 API 実行時にこの cookie をサーバーへ送り返す必要はない)。

もうこれを見るだけでばっちりでした。

スティーブ・ジョブズが目の前なう

2009/09/25: 帰宅したらきちんとした写真アップします。
2009/09/28: 写真アップしました。

■これまでのあらすじ
アメリカ旅行1日目
アメリカ旅行2日目〜3日目


■まずはGoogleへ
今日はCaltrainに乗ってシリコンバレーへ向かいます。お目当てはGoogleとAppleの本社！
↓
Caltrainのサンフランシスコ駅へ到着。日本の駅と作りが全然違ったり、標準軌道︵広軌？︶だったり、全2階建ての客車をディーゼルの機関車が引っ張る構成だったり、そんな機関車がずらりと横一列に並んでいる姿が拝めたりと、鉄道マニアにはたまりませんよ。あ、私は鉄道マニアなんかじゃないんだからねっ？＞＜
↓
一路San Antonio駅へ。ここからVTAのバス40番に乗り換えて一路Googleへ移動。
駅で降りてまず感じたのが、空が広い！明るい！緑が鮮やかで綺麗！暖かい！家並みが美しい！まるで絵に描いた楽園のような風景です。なるほど、これはすごい。みんなシリコンバレーで起業したがるわけです。
↓
Google到着。めっちゃめっちゃ広い！！＞＜
雰囲気としては途中Palo Alto駅すぐそばにあるスタンフォード大学のキャンパスとそっくりで、全然﹁会社﹂って感じがしません。緑がたくさんあって、へんちくりんな形の建物がどーんと。大学のキャンパスかカフェか何かみたいです。
↓
さんざん周りをうろついて写真を撮りまくったあげく、何かの間違いで中に入れてもらえないかとVisitor用のロビーに向かったら、受付のおねーさんに﹁ここはClosed Campusです、知り合いが面会者がいない奴は立ち入り禁止です。でてけ﹂とやんわり怒られ、外に出たらセキュリティのお兄さんにまたやんわり怒られ、あえなく撤退。入れないのはわかっていたもののやはりショック。
↓
"There are no public visitor center or a shop"だそうです。嘘つき！俺は知ってるよ！某氏がGoogle社内見学したとき、お土産にバッグ買って帰ってきたのを！
↓
あ、そうか、だから"public"って断りを入れたのね。というわけで、技術にはオープンですが、本社警備には大変クローズドなGoogleでした＞＜


■続いてAppleへ
ふたたびCaltrainに乗って、こんどはSunnyvale駅へ。
↓
駅からVTAバス55番で南下するとAppleの本社に到着。外見はGoogleと違ってテクノロジー企業らしい企業ビルって感じです。あたりの交差点にたくさんリンゴマークの住所書きがあります。
↓
先ほどのGoogleでの失態を教訓に、まずはすぐに施設に近づかずInfinity Loopの公道からゆっくり観察することに。あ、6 Infinity Loopに山積みのMac Proがある。一つお土産に欲しい。
↓
Infinity Loopを左回りに進むと、6, 5, 4, 3, ....という風に施設が並んでいます。一番最後が1 Infinity Loop, 本社ビルです。
↓
本社ビル前に到着。お土産屋さん発見。観光バスと観光客らしき人も発見。どうやら思ったより観光客に対してオープンになっているみたいです。
↓
しかし当たり前ながら本社ビルの中には入れないようで、入り口の前で立ち往生。


■あんびりーばぶる！
で、中にも入れないし写真も撮ったしそろそろ帰るかと思っていたら。

http://twitter.com/akisutesama/status/4354424273
http://twitter.com/akisutesama/status/4354453168
http://twitter.com/akisutesama/status/4354498099

まさかのジョブズ降臨！！

目の前3メートルの位置にジョブズが！声をかけたけど無視されてすたすた行ってしまわれた。
↓
いや待て、本物がこんなド真ん前を堂々と歩くわけがない、偽物か影武者だと思って売店のおねーさんに聞いてみたら、"then it might have been"︵ならたぶん本物だったのよ︶とのお返事が。あと"He usually doesn't answer because he's so busy"らしいので、どうやら本物っぽいです。ああ、来て良かった！
↓
最後に記念撮影してたら建物の中が写るからそこで撮るなとセキュリティのイケメン兄ちゃんにやんわり怒られました。またか！＞＜


■じゃあ帰りましょ
Sunnyvaleの駅前で食ったsushiはなかなかおいしかった。カリフォルニアロール、言うほど不味くないですよ。私の舌がゲテモノ食いなのかもしれませんけど。ただし握りはいまいち、しゃりがなんだか変。食えないことはないけど、近所のスーパーのパック寿司のほうがおいしいと思う。これで4ドルは日本だとぼったくり。
↓
帰りのPalo Alto駅で乗ってきたスタンフォードの学生が目の前でMacBook広げてプログラミングを始めたので興味本位でのぞいてみた。ソースはよく見られなかったけど、たぶんAdobe AirかFlash。集中力が凄くって、乗ってからサンフランシスコの駅についてドアが開いてもまだMacとにらめっこしていた。きっと朝から夜遅く︵19時︶まで授業があっただろうにと思うと、さすがスタンフォードの学生だと感心するとともに、自分も負けていられないと思うのでした。

アルカトラズなう

1日目に引き続き、2〜3日目。


■2日目
朝起きてまずは近所の散策。Whole Food MarketとWalgreensを発見。
↓
ジャパンタウンへ行ってみるがあまりにも閑散としていておもしろくないので即撤退。伊藤園の充実野菜が売ってあった。
↓
おもむろに目の前を走っていたMUNIバスに興味本位で乗ってみたら降り方がわからず大変苦労した。運ちゃんに降り方を聞いてようやく降りたらなぜかシビックセンターについた。
↓
シビックセンター見学
↓
ダウンタウンへ移動
↓
ダウンタウン見学、Apple StoreでWifi電波を借りたりFallout 3の実物大Power Suitにつられて地元のゲーム店によってみたり。DSとWiiのソフトが日本と全然違う。ほかはにたりよったり
↓
あ、Walgreensにおーいお茶︵濃い味︶売ってる、$1.69
↓
ケーブルカーでフィッシャーマンズワーフへ
↓
Pier39で飯、ようやくこっちのレストランの作法とか文化的背景がわかった
↓
Pier33で明日のアルカトラズ行きのチケットを入手
↓
適当にバスに乗ったらゴールデンゲートブリッジについた
↓
ゴールデンゲートブリッジを見学。風が糞強い！めちゃ揺れる！落ちる！！ロードバイクにひき殺される！！死ぬ！！＞＜
↓
ゴールデンゲートウェイ公園に移動。広すぎる上に車道があって公園というイメージがしない。地元の田舎道みたいな雰囲気。
↓
なぜかツタンカーメン展をやっていたので入ってみた
↓
やばい、ツタンカーメン展ヤバい、超おもしろい！
日本で一般的に開催されている展覧会と違って見せ方が上手い！展示に移る前に、決められた人数ずつ展示室前の墳墓を模した暗室に誘導され、そこでディスカバリーチャンネルみたいなかっこいいムービーを見る。凄い盛り上がる！ムービーが終わったらいよいよ中へ、入ると同時にツタンカーメンの像がお出迎え！とこんな具合にストーリー性があっておもしろい。美術品を順番に置いて説明テキストおいて終わりじゃなくて、映像とか部屋の構造まで使ってストーリー性を持たせているのが、まるでディズニーのアトラクションみたいだと思った。
↓
2時間もたってしまって19時になったのだが、外がまだ明るい。よく考えたらサマータイムのおかげでまだ日本時間では18時相当なのだった。サマータイムに生まれて初めて感謝した。
↓
近所のWhole Food Marketで晩ご飯を買って食う。普通に食える。おいしい。誰だアメリカの飯が不味いとか言ったやつは。自分にはこれでちょうどいいぐらいだ。


■3日目
朝9時半からアルカトラズへ移動
↓
昼14時半までアルカトラズ観光。とにかくすばらしいの一言につきる。島から見えるサンフランシスコの町並みも、刑務所跡も、とても綺麗で歴史が感じられる。ここの歴史なんてたかだか100年とちょっとしかないはずなのだが、数百年歴史があるはずの地元山口・錦帯橋よりも歴史が感じられるのは、やはり見せ方が上手いのと、音声ツアーガイドがあまりにも秀逸であるおかげだろうなぁと思った。アルカトラズ刑務所の音声ツアーガイドは本当にすばらしい！ディスカバリーチャンネルの世界を自分の足で歩いているような雰囲気がたまらない！
※帰ったら写真と動画うｐします。
↓
フィッシャーマンズワーフで遅い昼飯。ただのハンバーガー︵10ドル︶、これが凄くおいしい。ポテトもマックやバーキンの安物とは全然違って、30分たってもおいしい！このぐらいなら、なるほど料理と読んで差し支えないなぁ。
↓
近所のWhole Food Marketで晩ご飯と朝ご飯を買いだめ
↓
終了


作法や町歩きの仕方が身についてきて、英語も耳に慣れ聞き取れるようになり、おもしろくなってきました。明日はいよいよGoogleとAppleの見学に行ってきます。余裕があればStanfordも！

サンフランシスコなう

思い立ったが吉日ということで今サンフランシスコに来ております。初海外です。
●飛行機で9時間10時間は思ったより全然楽。ただし酔い止めと耳栓とマスクとエア枕は絶対必須。どれか一つでも欠かすと結構きつい。
●飛行機機内寒すぎ
●サンフランシスコも寒すぎ︵体感で東京の10月下旬以降︶、長袖が必須
●こっちの人は皆さんとっても親切、アメリカ人は意外とフレンドリーだった
●でも何言ってるかわからん←一番困る、TOEICの点数とリスニング力は全く比例しません
●SUBWAYの味は東京と代わらなかった︵量が多いしピクルスが酸っぱくて不味いが基本同じ︶
明日はダウンタウン行ってみたり町になれようかと思います。23でアルカトラズでも見て、24でGoogleでも見て帰る。

iMacもSnow Leopardにしてみた

MacBook Airに引き続き、iMacのほうもようやくSnow Leopardに乗り換えてみました。


■ユーティリティとか動くの？

USB Overdrive
動きました！一番気がかりだったので嬉しいです！
Shades
こちらも動作しました。Snow Leopardで多少マシになった輝度設定ですが、まだまだ明るすぎるので重宝しています。
ただし、画面右上のアイコンをクリックして表示されるスライダーが動きません。輝度設定を変更したいときは、システム環境設定のパネルからShadesを直接起動して変更する必要があります。まぁ、その程度なら全然OK！
MenuMeters
やっぱりダメでした。残念ですが忘れようと思います＞＜


■その他、iMacの気になるところ直った？

画面の輝度が明るすぎる
多少マシになってます。一番最低まで下げれば、以前よりはまぶしくない︵気がします、単にコントラストの設定が2.2になったせい？︶。でもまだまぶしいです、引き続きバグチケットをAppleに投げてきます。
マウス
相変わらず加速度がオフに出来ない糞仕様です。反応速度自体はマシになっていますが・・・しかも困ったことに初代Macintoshからこうらしいです、伝統だとか。改善されることはなさそうです＞＜ USB Overdrive様々。
ExposeとSpacesのマウス操作仕様
困ったことにSpacesのマウス操作が微妙に変わっています。Spacesをボタンで起動した後、開きたいSpaceを﹁左クリック﹂しない限りSpaceが切り替わらない仕様になってしまいました。いままでは﹁Spacesの起動ボタン﹂でもSpaceが切り替わっていたのですが。Exposeは従来通りなので差異が発生してます。地味に困るのでこれもバグチケット投げないと。

Mac OS X 10.6 Snow Leopardのeasy_installでPILをビルドするときに気をつけることなど

Snow LeopardにPIL(Python Imaging Library)をインストールしようとして見事にハマりましたので、後学のために事の顛末を記しておきます。


■まず最初に、調べて分かった結論

●Snow LeopardでPythonを使うときは、デフォルトで付属しているPython 2.6.1を使用すること。
●Snow LeopardにはPython 2.5.4も付属しているが、こちらは使用するべきではない。
●Snow LeopardのPython 2.5.4のdistutilには不具合？があり、UnixCCompilerクラスがC言語のモジュールを64bitでビルドしてくれないため、Snow Leopardでは動作しなくなる
●したがって、C言語のモジュールを使用しているPILはSnow LeopardのPython 2.5.4を使うとビルド出来ない
●どうしても2.5.4を使いたいときには、環境変数にARCHFLAGS "-arch x86_64"を追加してからPILをビルドするとうまくいくかもしれない︵未確認︶
●MacPortやMacPythonからのインストールは実験していないため未確認

※ あくまで2009年9月8日現在での断片的な情報です。皆様がごらんになっている時点では既にMacPort上のPythonやMacPythonも対応を完了しているかもしれませんので、参考程度にご覧ください。でもSnow Leopard上のPython 2.5.4はほんとお勧めしません。


■ことのはじまり
Leopardのころはきちんと動いていたGoogle App Engine SDKが、Snow Leopardにアップグレードしたとたん突然PILモジュールがないと警告を出すようになってしまいました。確認してみると/Library/Python/Python2.5/site-packages/以下に確かにインストールされているのですが、何度試しても警告が消えません。Pythonのバージョンも以前から使っているPython 2.5のままです。これは何かがおかしい、再インストールした方がいいだろうと判断し、http://www.pythonware.com/products/pil/から1.1.6のソースコードを落としてきていざビルド。

sudo python setup.py install
python selftest.py

・・・が、動きません。なにやらImagingMathが見つからないだのなんだのとエラーが出てしまいます。これだけではよく分からないので、直接PILのモジュールをPythonからimportしてみることにしました。

akisute PIL$ python2.5
Python 2.5.4 (r254:67916, Jul  7 2009, 23:51:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Imaging
>>> # 問題なくインポートできました
>>> import _imaging
Traceback (most recent call last):
  File "", line 1, in 
ImportError: dlopen(./_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
  Referenced from: /Library/Python/2.5/site-packages/PIL/_imaging.so
  Expected in: flat namespace
 in /Library/Python/2.5/site-packages/PIL/_imaging.so
>>>

ふむふむ、どうやらこの_imaging.soというのがなにやら悪さをしているようです。@tokibito先生にお尋ねしたところ、このsoファイルというのはC言語のソースをコンパイルしたライブラリで、Pythonから動的にインポートできるようにpython.hというヘッダをインクルードしてつくられているらしいということが分かりました。なるほど、それでPythonから直接C言語で書かれてビルドされたライブラリをimportできるんですね。凄いなPython。

となると怪しいのはPILのビルド工程。先ほどのエラーを見ると_jpeg_resync_to_restartというシンボルが見つからないと表示されていたため、インストールに使ったlibjpeg︵MacPortよりインストール︶に何か問題があったのではないかと推測したのですが、特に問題は見つからず。

次にPILのビルドログを調査。細かいwarningが出まくるのはいつものことなので無視して調べてみますが、一見何もエラーは出ていません。するとあることに気づきました。

gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc build/temp.macosx-10.6-i386-2.5/_imaging.o build/
temp.macosx-10.6-i386-2.5/decode.o build/temp.macosx-10.6-i386-2.5/encode.o build/temp.macosx-10.6-i386-2.5/map.o build/
----
中略
----
 -L/o
pt/local/lib -L/System/Library/Frameworks/Python.framework/Versions/2.5/lib -L/usr/lib -ljpeg -lz -o build/lib.macosx-10
.6-i386-2.5/_imaging.so

うん、なるほど、原因が分かりました。-arch i386と -arch ppcでしかビルドされていないのがまずそうですね。Snow Leopardは64bitですから、-arch x86_64を追加してビルドしなければならないはずです。

ためしにPython 2.6.1でこの_imaging.soを読み込もうとしてみた結果がこちら。

akisute PIL$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _imaging
Traceback (most recent call last):
  File "", line 1, in 
ImportError: ./_imaging.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
>>>

ビンゴ！間違いなさそうです！あとは、どうすれば64bitでビルド出来るかを調べるだけです。


■distutilとの戦い
とは言ってみたものの、そもそも一体全体どういうカラクリでpython setup.py installコマンドがgccビルドを実行しているのかが分かりません。まずはsetup.pyのソースを読んでみることにしました。するとdistutils.command.build_extなるモジュールをimportして使っていることが判明。怪しい。Python2.5のシステムライブラリをあさってみると、ありましたありました。

さっそくコードを読んでみると・・・

475         objects = self.compiler.compile(sources,
476                                         output_dir=self.build_temp,
477                                         macros=macros,
478                                         include_dirs=ext.include_dirs,
479                                         debug=self.debug,
480                                         extra_postargs=extra_args,
481                                         depends=ext.depends)

おおっといきなり発見、self.compiler.compileとか怪しさ抜群です。こいつはどこからやってきたのかとソースをたどると、なにやらunixccompiler.pyというモジュールを発見。いかにも私がコンパイラだと言わんばかり。犯人はこいつに違いない。さっそくコードを開いて-archとかで検索をかけてみましたが、i386とかppcとか直接指定している箇所は見あたりませんでした。その代わり別の収穫を発見。

def _darwin_compiler_fixup(compiler_so, cc_args):
    """
    This function will strip '-isysroot PATH' and '-arch ARCH' from the
    compile flags if the user has specified one them in extra_compile_flags.

    This is needed because '-arch ARCH' adds another architecture to the
    build, without a way to remove an architecture. Furthermore GCC will
    barf if multiple '-isysroot' arguments are present.
    """
----
中略
----
    if stripArch or 'ARCHFLAGS' in os.environ:
        while 1:
            try:
                index = compiler_so.index('-arch')
                # Strip this argument and the next one:
                del compiler_so[index:index+2]
            except ValueError:
                break

    if 'ARCHFLAGS' in os.environ and not stripArch:
        # User specified different -arch flags in the environ,
        # see also distutils.sysconfig
        compiler_so = compiler_so + os.environ['ARCHFLAGS'].split()
----
後略
----

環境変数ARCHFLAGSとかいうのを見てるみたいです。なるほど、じゃこいつに"-arch x86_64"とか追加すればきちんと64bitビルドしてくれるのでしょうか？


■そしてあっけない幕切れ
ここまでなんとか一人で調査していたものの、たまりかねた隣の席の皆さんからアドバイス。

﹁Python 2.6じゃないのがまずいんじゃね？﹂

え、何、そういうこと？まぁ念のために試してみるか、ということでPythonを2.6に切り替えて再度PILをビルド。

あ、-arch x86_64がビルドオプションについてる。

あ、python selftest.py一発で通った。

あ、Google App Engine SDKがPILの警告吐かなくなった。

終了。

なにそれ。俺の苦労、何よ。


■あれ？
・・・おかしいな、今日作るはずだったGoogle App Engineのアプリ、まだ10行ぐらいしか書いてないよ＞＜

.tmux.confをいじってtmuxのエスケープキー(prefix)を変える

~/.tmux.confというのがtmuxの設定ファイル、screenにおける~/.screenrcのようです。
制御キー︵screenでいうescapeに相当︶を設定するには、

set-option -g prefix C-t
unbind-key C-b
bind-key C-t send-prefix

こんな感じで書きます。C-を付ければControlキーが修飾キーになるようです。
.screenrcのときは

escape ^Tt

みたいに書けばOK。

参考にしたページはこちら‥
http://ktjx.blogspot.com/2009/08/tmux.html


■トラブルシューティング
間違ってこんな設定を.tmux.confに書き込んでしまうと、

set-option -g prefix t

Tキーがprefixになってしまうためターミナルからexitやquitを入力させることが出来なくなりtmuxを終了させられなくなります。Control-Cも試してみましたが無視されてしまいました・・・仕方ないので強制的にMacのTerminal.appを落として解決したのですが、問題がその後。tmuxにはセッションを保持する機能があるので、強制的にTerminalを殺してもtmuxのプロセスはまだ生き残っています。再度Terminalからtmuxを起動すると、tmuxがこの生き残っているセッションを復活させてしまうため、設定ファイルを正しく書き換えても反映されなくなってしまい泥沼に突入します。

ということで、tmuxプロセスを先にkillしてから再度tmuxを起動すれば無事に設定が反映されます。こんな恥ずかしいミスをしでかすのは私ぐらいかと思いますが、何かの拍子にお役に立てば幸いです。

Python 2.5系列では__repr__()でunicodeを返すといろいろトラブルが起きる

Django︵正確にはapp engine patch︶のmanage.py shellで遊んでいるとき、とあるクラスを生成すると必ずUnicodeEncodeErrorが発生していることに気づきました。具体的には以下のような感じ。

>>> from game.models import *
>>> hts = HeroTemplate.all()
>>> ht = hts.fetch(1)[0]
>>> ht.template_name #問題なし
>>> ht.name          #問題なし
>>> hero = Hero(
... name=ht.name,
... symbol=ht.symbol,
... max_life=ht.max_life,
... life=ht.max_life,
... max_move=ht.max_move,
... move=ht.max_move,
... weapon=None,
... item=None,
... )
>>> hero             #ここでUnicodeEncodeError
>>> ht.createHero()  #上記と同じ処理をやるメソッド、これもUnicodeEncodeError

原因を調べていてわかったのですが、Python 2.5系列では__repr__()がunicodeを返すようにしてしまうとトラブルの元になってしまうようです。
参考にしたサイト‥
http://d.hatena.ne.jp/alisue/20090402/1238690818

たとえば、

>>> class Abesi:
...   def __repr__(self):
...     return u'¥u3059¥u305a¥u304d¥u3044¥u3061¥u308d¥u30fc'
... 
>>> abesi = Abesi()
>>> abesi #UnicodeEncodeError

これを実行するとabesiを表示しようとしたタイミングでエラーになります。環境はWindowsXP上のCygwin 1.7 + Python 2.5.4で、ターミナル上ではshift_jisを使っています。始めっからターミナルがutf-8を扱えるような環境なら__repr__()でunicodeを返しても上手くいくかもしれません。
しかしながらどこの環境でも動くとはいいがたい状態なので、


●__str__()と__repr__()はstrを返す

●__unicode__()はunicodeを返す

Python 2.5系列ではこのルールを守っておいたほうが無難のようです。Python 3.0からはunicodeがデフォルトになるらしいのでこんな面倒ごとをいちいち考えなくてもよいのでしょうか？いまだにPython 3.0試していませんが、ちょっと興味が湧いてきました。


■っていうかそもそも
Djangoのdjango.db.models.Modelクラスは特にオーバーライドしなくても綺麗な__repr__()を出力してくれるので、デフォルトの__repr__()を使えばよかった＞＜

多少マシになったかな

相変わらずこんなしょぼっちい物を作っていたりします。


■前回からちょっとだけ改善
敵が出るようになりました︵キャラの向き滅茶苦茶ですが︶。
弾が出るようになりました︵タダの自機狙い３Wayですが︶。
ちょっとずつデザエモン程度には近づいてきたかなぁと。
あとは自機が動いて弾が出れば一応STGっぽくはなります。

今回作ったところまでの経過をgithubにうｐしてみました。
http://github.com/akisute/MyShooting/tree/338e164b4716ec27a6a9b8d384f7714243f53d2e

最新のソースはこちら。
http://github.com/akisute/MyShooting/tree/master


■今回の気づき
弾の発射とか敵の出現タイミングをフレーム単位で計測して実行しているのですが、cocos2dのフレーム時間はかなりばらつくようです。弾が200発程度出ただけでフレーム時間が2倍になったりします。要するに弾の発射間隔が2倍になります。ちょっとこれはいただけない感じ。毎フレームごとに前フレームから何秒経過したかが取得できるので、それを元に時間単位で発射タイミングを測った方がいいかもしれません。

あとはActionがやたら重いです。何が重いってActionの動き自体よりもActionオブジェクトの作成と解放に時間がかかっている感じです。頻繁に起動が変わったり単純直線移動しかしない動きを再現するとき︵たとえば高速弾や自機コントロール︶は、昔ながらのvx, vyを使った方法のほうが軽くて良さそうです。

どのクラスのインスタンスを作っているかに注意しましょう・・・

突然ですが問題です。以下のソースはコンパイルできますがバグがあります。
http://github.com/akisute/MyShooting/blob/4570825e7384157d3572b689cc23f9bb3acc0b82/Classes/MSTGObjectFactory.m

さて、どこが間違っているでしょうか？

---

■なんて突然言ってもわからないですが
正解はこちら。

+ (MSTGObject *)cannon
{
    // ここが間違い。MSTGObjectではなくてMSTGCannonのインスタンスを生成する必要がある
    MSTGObject *object = [MSTGObject spriteWithFile:@"cannon.png"];
    return object;
}

で、MSTGObjectはライフがデフォルトゼロなので、生成された瞬間に即死して画面から退場してくださるという悲しいバグが。うーむJavaではこんな情けないバグ作ったりはしないのですが・・・ともかくこれで一歩前進。