unknownplace.org

multiverse.elで現在のファイルのスナップショットを取る - '(rubikitch wanna be (a . lisper))

プログラミングしているとき、実験的修正をしたくなることがあるだろう。もし実験が失敗したときに元に戻す...なんてことは日常茶飯事だ。

RCS、CVS、Subversion、Gitなどのバージョン管理システムはまさしくそれをやっているのだが、未完成のままではコミットはできない。たとえば、複数の（細かな）実装が思い付いたとき、どっちかひとつをコミットしたいなんて場合とか。

そこにgitを一緒に入れるのはなぜなんだ？

それをやるためにgitみたいなdistributedなバージョン管理システムがあると言っても過言でないくらいだと思うのだが。

まず、xcode で新規プロジェクト作成。Window-Based Application が余計なもの作らないのでおすすめ。

.
|____Classes
| |____my_test_projectAppDelegate.h
| |____my_test_projectAppDelegate.m
|____Info.plist
|____main.m
|____MainWindow.xib
|____my_test_project.xcodeproj
| |____project.pbxproj
| |____typester.mode1v3
| |____typester.pbxuser
|____my_test_project_Prefix.pch

こんなファイル構成ができあがる。

まず、nib ファイルは toolchain 環境では扱えないので MainWindow.xib は削除。Info.plist からも

<key>NSMainNibFile</key>
<string>MainWindow</string>

って部分を削除。nib ファイルを使わないということはすなわち xcode のインターフェースビルダーが使えないということだけどまぁしょうがない。

つぎ、プリコンパイルヘッダ (my_test_project_Prefix.pch) も僕はいらないので削除。また、project.pbxprojに

GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = my_test_project_Prefix.pch;

という部分がDebugとReleaseの二カ所あると思うのでそこを

GCC_PRECOMPILE_PREFIX_HEADER = NO;

に変更。

Classes ってディレクトリ名が気に入らないので、src に変更。xcode側では読み込み直す。

アイコンとかリソースファイル用には resources ってディレクトリを作っておく。

最後に toolchain 用の Makefile をおく。

この時点でファイル構成は

.
|____Info.plist
|____my_test_project.xcodeproj
| |____project.pbxproj
| |____typester.mode1v3
| |____typester.pbxuser
|____main.m
|____Makefile
|____resources
|____src
| |____my_test_projectAppDelegate.h
| |____my_test_projectAppDelegate.m

こんな感じ。

これでどっちでもビルドできるようなアプリを書くことが可能。

めんどくさいので自動化したい。

追記＠2008-12-11

project.pbxproj を直いじりすると、その後 xcode から実機デバッグしようとするとUUIDがちげーよとかいう警告がでるようになるっぽい。(実際にデバッグは出来るのけど)

直いじりするかわりに xcode のプロジェクト設定で GCC_PRECOMPILE_PREFIX_HEADE とかを編集すれば大丈夫。

この間作った KillApple という iPhone のメモリに残ったビルドインアプリケーションを殺すアプリケーションですが、いろんなところでデモするとなかなか好評で、使いたいとおっしゃってくださる方もいたので、Cydiaからインストールできるようにしてみました。

Cydia のソースに

http://apt.unknownplace.org/iphone/

を追加すると、検索に KillApple が引っかかるようになると思いますのでそのままそれをインストールすればOKです。

今後作ったほかのアプリもここで公開していこうかなと思っております。

Wowza Media ServerでSWFVerification(っぽいこと)をする方法 - blog.katsuma.tv

それなら kamaitachi でもできるよ。ってことで使いやすいようにサービス化。

AutoConnect の代わりに、AutoConnectACL というサービスを使うと URL ベースでのアクセスコントロールをつけることができるようにしてみた。

echo サンプルの例なら、

package Service::Echo;
use Moose;

extends 'Kamaitachi::Service';

with 'Kamaitachi::Service::AutoConnectACL';

sub allow_pages {
    'http://www.unknownplace.org/*',
    'http://unknownplace.org/*',
}

sub allow_swfs { 'http://unknownplace.org/*' }

sub on_invoke_echo {
    my ($self, $session, $req) = @_;
    $req->response(@{ $req->args });
}

のような感じで、AutoConnectACL を with して allow_pages と allow_swfs を定義すればそこに書かれたURLにマッチするアクセスだけを許可することが出来る。

いちおう Flash の流儀にあわせてなんか glob マッチ方式にしてるんだけど、使いにくいので正規表現でもいけるようにしてある。

sub allow_pages { qr{^https?://(www\.)?unknownplace\.org} }

とか Regexp リファレンスつかえばおｋ。

allow_pages が swf の貼り付けてあるページの URL、allow_swfsが swf 自体の URL にマッチする感じ。

土曜に FMS 勉強会という名目で行われた kitasando.as で kamaitachi を紹介してきました。

スライド：

http://svn.coderepos.org/share/docs/typester/kitasandoas-2/start.html

本家 FMS の話と、Wowza の話がおもしろかった。Wowza完成度高杉だろ。

SWFVerification とか機能自体しらなかった。どうやるんだろうなぁ。connect時swfのURLは送られてくるけど、それだけじゃ無理だし。

kamaitachi のサンプルアプリで Air アプリをつくろうとおもってつくろうとしたんだけど、adl がうまくうごかなくてはまった。

環境は OSX 10.5.5 + Air1.5 + Flex SDK 3.2.0.3958。

普通に実行すると

$ adl HelloWorld-app.xml
unknown error
Error: Error #2014: Feature is not available at this time.
        at runtime::SecurityManager$/initAppDataDirRoot()
        at runtime::SecurityManager$/GetPersistentStorageDirectoryName()
        at runtime::AppRunner/run()
        at global/runtime::ADLEntry()

こんなんなる。別にコードが悪い訳じゃなくて、adtでパッケージ作るとそれは起動できる。

でなんかよく見るとディレクトリ関係のとこでこけてるからためしに sudo でうごかしてやったらうごいた。。なんやねん。

どっかのパーミッションかえてやればいいんだろうけどそれがどこだかわからんなぁ。

IRCチャンネルできました。

#kamaitachi @ chat.freenode.net

kamaitachi に興味なくても RTMP のパケットが云々という話とか興味ある人は入るとおもしろいかも。

土曜にはじめてチェックアウトして翌日ハッカソンに挑むという無謀さでしたが、いやいやなかなか、おもしろかったです。

remedieはつかってみるとかなり面白いですね。対応しているURLを含んでいれば別にメディアRSSとかじゃなくても追加できるので、おもむろに自分の del.icio.us などのページを食わせてあげても、YouTubeやニコニコ動画などをブックマークしてたらそれがリストにでてくる。

気になる人のブックマークとかは突っ込んでおくだけですぐにその人がブクマったものをremedieで見られるという訳ですね。

で、ハッカソンでなにをしてたかっていうことがいいたいんですが、刺されたくないのでやめておきます。コミットログとかから察してください。

作ったもの、あとでコミっときます。

ライブコーディングをしてきました。シンプルなwikiです。

ソースコードはこちら。

http://github.com/typester/yiki

会場で書いたものに.gitignoreファイルを追加(coしたときにディレクトリがそろってないとうまく動かないので)しただけなものとなっています。

コード書くのに必死だったのであんまり解説ができなかったのですが、まず最初に Yiki.pm というところに wiki のページ編集の機能をモジュールとして作成し、それをあとから作った Yiki::Web という Catalyst アプリから使うというのがポイントでした。

単体モジュールとして wiki の機能を実装することでテストが書きやすいので安心だとか、ほかのアプリからも使えるだとかいろいろな利点が生まれます。

今回のコーディングの流れは

1. 01_module.t に SYNOPSIS を書いてみる。(自分がどんなふうにアプリを使いたいかデザインする)
2. その SYNOPSIS をもとにテストをおこす
3. Yiki.pmを実装
4. テストを走らせ正しく動作しているか確認
5. 3,4を繰り返す
6. それを Yiki::Web から使用する

となっています。

kamaitachi のデモをしてきました。

スライド：

kamaitachi - perl flash media server

デモ使ったサーバーサイドとクライアントサイドのソースコードはこの辺にアップしました：

example/shibuya.pm

動かし方は

git clone git://github.com/typester/kamaitachi.git

してきて、example/shibuya.pm で perl server.pl するとサーバーが立ち上がります。

そのあと、example/client 以下にある swf ファイルをブラウザで開けばローカルでデモが動かせます。

asソースをみてもらえばわかりますが、接続先が localhost 決めうちになっているため、それ以外のところで動かす場合は swf を作り直す必要があります。

フリーで公開されている flex sdk をつかえば一応誰でもコンパイルできます。

mxmlc chat.mxml

などとすればOK。

というか本当は swf の URL から接続先のホスト名を自動的に設定したかったのだけど、mxml内でインクルードしてるasで、Stageオブジェクトを取得する方法がわからなかったのであきらめた。もしこの方法がわかったらコードをアップグレードします。

というわけで、サーバー・クライアント両方のサンプルをやっと作れたので、これで一応誰でも試せるところまではきたかと。

使ってみて、いろいろフィードバックいただけたら幸いです。