朝ぜんっぜんっ起きれない。
またイベントサイトを作り始めてるんだけど、作る度にいろいろインフラのサービスを変えたくなってこまる。
DBはHerokuの標準で無料のやつ使ってるんだけど、お試し的なものなので5MBで10000行までのようだ。足りてはいるんだがちょっと不安な容量だよねと有料にしようとすると月$9～と急に高くなる。最近気になってるCouchDBのホスティングがやたらと安いんだが、DBの形からして違うから乗り換えるのも大変そう。
でかいファイル達はDropboxにつっこんでホスティングするようになっちゃってるんだけど、イベントやる月だけとはいえ有料契約しないといけないし、不特定多数にホスティングするのがメインなサービスじゃないので遅い。 Amazon S3で東京リージョンに置きたいけどそこそこお金かかるしなーと思ってたんだけど、計算してみると転送量によってはAmazon S3使った方が安くなるな。データ保存の料金は2GBもデータ置かないので月$0.2くらい。月20円もしないってことか。
転送量はイベント中は下手すると80GBも転送するんだがそれだと$16くらいで、さすがにDropboxの月$9.99よりは高いが、速度考えたらべつにいいかなーという感じ。相対的には1.6倍近いが、絶対的な値段で比較するとたかだか数百円だし、年2～3回のイベントで数百円余計にかかるくらいは全く痛くもない。転送量は幅があるのでもし40GBになるとむしろS3の方が安くなるくらいだしな。
なんにせよ変更するにはいろいろと手間がかかることが一番のネックなんだよなぁ。
イベントサイトいじり始めた。 ビューをいじってるくらいだとそう難しいところもなかったんだけど、ログイン方法を変更しようとしたらビューだけで済むわけもなく。
今まではTwitterアカウントだけでログインできてたんだけど1、Twitterアカウントを持ってないという人もいくらもいて、Twitterと連携なんぞ一切しないサイトなのでそりゃ当然の話でせめてOpenIDでもサポートしようかとした。
サイトは元を俺が作った物じゃないのでJava+Play! 1.2.xとかで作られててどっちもよく知らないのでこまる。よく知らんといってもJavaはそんな変な言語でないので見れば分かるけど。DBのユーザー情報にログイン方法とかの入ってないよなーと見てみたが、やはりTwitterのユーザーIDを整数で保持している程度だった。うーん、せめて文字列だったらDBいじらずになんとかつっこめたんだがなぁ。
Play!のDBいじる部分ってどうなってんだろうと調べてたが、少なくとも1.2.xではあんまり高度なことはやってくれないようだ。JPAというのを使ってるようだが、読み書き程度のアクセスする部分は勝手にやってくれそうだが、テーブル作ったりmigrateしたりは自分でやれという形式っぽい。それはそれで分かりやすいので安心だ。
ところでHerokuでDBいじるのってどうすればいいんだろうと調べたが、HerokuのPostgreに外から接続して頑張れ的な感じらしい。ふむ。Postgreもさっぱりわからんのでそこからか。
DBはともかくOpenIDにしたって自前で書くのはめんどいのでライブラリなどを探す。そういやRubyにはいろんなサイトを使ってログインするのを統一的にやるライブラリというのがあった気がして、Javaにもあんだろと調べたらあった。あったんだけど入れるの面倒そうだなーと思ってたらPlay!にはSecureSocailていうモジュールがあるよと教えてもらった。これは簡単に導入できそうだ。直接OpenIDは使えないがTwitterのほかにGoogleがあるので我慢できる程度じゃないかな。あとで調べたら自分でプロバイダ追加するのも難しくはなさそうだった。
そこからPlay!とEclipseの使い方がわからんといいつつなんとかビルドでき2、起動してみたんだがなんか変なエラー出てるなー。同じ認証プロバイダが2回追加されてんよ！と例外が出てるんだが、なんでアプリ起動時にしか呼ばれないはずのところが2回呼ばれてんだよ。デバッガで調べようとしたがまたEclipseとPlay!の使い方がわからなくてしばらくこまってた。
デバッグ起動しようとすると引数で～idwp～とかいうのが2回指定されてんじゃねーかとエラーが出てくる。実行時に指定する引数を見るとそんな感じの引数はあるが、ちゃんと1回しか指定されてない。検索してみると管理者権限でEclipseを実行しないとだめだ的なのが出てきたがそんなわけねーだろと試すがやっぱりだめ。今時管理者権限じゃないとWebアプリのデバッグができない開発環境なんてあったらぶち切れるかぶち切れるかぶち切れるかするしかないよ。
他の情報では、普通にデバッグ実行じゃなくてリモートアプリケーションからConnect to～みたいなの使ってデバッグしませう的なのがあったので実行してみると接続できませんでした的なエラーが出て実行できん。うーん、さっぱりわからん……。
しばらく悩んでいたんだが、実行引数とか見ててわかった。アプリ実行用の引数に～idwp～みたいなのが設定されてるけど、これってデバッグ実行時にEclipseが勝手につけるから通常の実行引数につけちゃってると二重になるってことなんじゃねーか？ということは通常起動でサーバ立ち上げた時点でデバッグ可能なので、その状態でリモートデバッグ接続すると……いけました。なるほど理解できればその通りだが、Play!の通常の設定といい勝手に引数追加するのにコマンドライン表示しないEclipseといい、わかるわけねーだろ。まあできるようになったのでいいや。
なんとかデバッグはできたが、securesocialプラグインがなぜか2回読み込まれてるんだろうという結論に。なぜ2回読むし。 読み込み部分やファイルをいろいろ調べた結果、play.pluginsというファイルをEclipseがeclipseフォルダにコピっちゃってるせいで、元の位置にあるplay.pluginsとeclipse/play.pluginsを両方読み込んで2回読まれるようになってるっぽい。しかし検索した感じではそんな状況になって困ってる人は見当たらない。俺の環境だけなんだろうか……。どうすりゃいいのかさっぱりわからんのでeclipse/play.pluginを手動で消して対応することにした。開発中だけだからこれでもいいか。
次はDBいじらないとなぁ……。
一部チャンネルのチャンネル情報が文字化けして表示されるという情報をもらった。知ってたけど。
たまにあるのは知ってたんだけど原因が謎なので手をつけてなかったんだよなぁ。 まあ謎つってもUTF-8じゃないチャンネル情報が流れてきているというのは明らかなんだが、なんでUTF-8じゃないチャンネル情報を流してしまうのかだ。 たまに見かけるけどほんとたまにで、ほとんどのチャンネルは問題ないんだよ。
PeCaStarter使ってる人が化けてるんじゃないかという話を貰ったんだが、それだけではない模様。 それだけだともっと多いはずだ。あとチャンネル名だけは化けずに正しく表示されてんのもちょっと謎。
PeerCastIMのソースを見てみたが、チャンネル情報設定している箇所ではUTF-8に変換しているように見える。 また表示部分でも変換して表示してるのでPeerCastStation以外では表示が化けないようだ。
PeerCastのIMじゃない奴とかPeCaStarterのソースも確認しないといけないんだけど、 * PeCaStarterがPeerCastStationにShiftJISでチャンネル情報を設定しちゃってる1 * PeCaStarterがPeerCastにShiftJISでチャンネル情報を設定しているがIM版でないのでUTF-8への変換が入っていない のどちらかが考えられるかな。PeCaStarter使うと起きるという前提だが。
前者はPeerCastStation上で化けて表示されるはずなのでPeCaStarter作ってる時にすぐ気付くと思われる。 なので後者が有力で、VP版のソース確認するのがよさそうだ。 ただ後者の場合はPeCaStarterに限らず、普通にブラウザから配信開始した時点で起こりそうだけどそんなチャンネルほぼ無いのが不思議。
原因はともかく、対処方法は限られる。 * そんなデータを送る奴が悪いので放っておく * 受け取った時点で文字コードをなんとか判別して変換する のどっちかだが、使う側からすれば当然文字コード変換しろよって話にはなるだろう。 PeerCastIMとかでは表示する時にも変換してるわけだしね。
しかしUTF-8、ShiftJIS、EUC-JPに限れば判別は成功しやすいだろうが、やはり失敗することもある。 さらに当然他の文字コードには対応できない。 実用上は困らんだろうけど、今時日本語の文字コードに限ってるってのもしょっぱいなーという気がするんだ……。
基本的にはよくわからん文字コードで送る奴が悪いってことにしたいがどうだろな。
PeerCastStationは文字コード判別変換してない。JSON-RPC経由で設定なんだから当然UTF-8で送れよ。 ↩
コンテントパケットを受信時刻でソートするようにした。 してみたんだが、テスト書いてたら駄目だった。同時刻に複数パケット受け取ることもあるんだった。時間の精度もそんなに高くないしね。
時刻が競合するなら今まで使ってたバイト位置もキーに追加すればよい。ストリーム番号・時刻・バイト位置の順に比較して古い順に並べるようにした。ストリーム番号は新しくストリームが開始されたら(=コンテンツヘッダが更新されたら)増加させる番号で、ストリームが途中で切り替わってバイト位置が巻き戻ってもストリーム番号が増えてればループと混同しない。まあ今のところパケットに含まれる物じゃなくて受信時に更新される物なので意味はあまりないんだけれども。
テストをいじりまくってなんとか通るようになったのでコミットしといた。テストは以前から駄目だったところがいまさら見つかったりするんでその対処に時間かかっちゃった。もうちょい綺麗に書けないもんかなぁ。
とりあえず数時間視聴に使ってた分には問題ない感じ。4GB越えた時に大丈夫かも試さないといけないだろうなぁ。