2007年5月アーカイブ

今更だけど、MovableTypeを3.34-jaから3.35-jaにバージョンアップ。
今回は、ファイルを更新するだけではなくて、コメント・プレビューのテンプレートも更新する必要がある。
んだけど、うちのテンプレートは2.66から持ってきたものなので、今回の修正に該当しなかった。(もともとencode_html="1"がついてた)
見ていて気がついたのは、inputタグのidが2.66と3.35で違うこと。もともとはauthorとかで、3系はcomment-authorらしい。それでも動いているのが面白い。
twitterで知り合った(?)nirvashさんのサイトを見ていたら、Snap Shotsと言うのを使っていた。
面白そうだったので、うちでもやってみることに。
いろいろ質問に答えて、javascript のソースを入手する。これを自分のページに貼れば良いらしい。
でも、MovableTypeを使っている場合はプラグインがあると言うので、MT-SPAと言うプラグインを入れてみた。
設定画面で、blog毎にpluginのon/offが切り替えられる。onにして再構築・・・。
って有効になりませんけど?
マニュアルを良く読んだら、有効にしたいテンプレートにMTSnapPreviewAnywhereと言うタグを入れろと。
幸い、このblog自体は共通のヘッダをincludeするように作っていたので、そこにMTSnapPreviewAnywhereを書いてOK。
でも、こう言うのなかったら全てのテンプレートに手で入れないといけないのか。それって、javascript貼るのと大して手間が変わらない気が・・・。
さらに、webからjavascriptのコードを手に入れる場合は、プレビューのサイズと言語が選べたんだけど、MT-SPAの場合はそれが選べない。
そこで、mt/plugins/SPA/SPA.pl の115行目を以下のように修正したら、日本語で大きいサイズにできた。
  $str .= '&size=large&lang=ja-jp&domain='.$blog_url;
FeedBurnerを使ってみることにした。
手順は、以下のとおり。
  1. テンプレートで、RSS2.0の保存ファイル名をfeed.xmlとか既存のものと変える。
  2. FeedBurnerにfeed.xmlのurlを登録する。
  3. blogの.htaccessに、以下のように書いてリダイレクトする。
    Redirect permanent /mt/pc/index.rdf http://feeds.feedburner.jp/wizard-limit/mt/pc
    Redirect permanent /mt/pc/index.xml http://feeds.feedburner.jp/wizard-limit/mt/pc
    Redirect permanent /mt/pc/atom.xml http://feeds.feedburner.jp/wizard-limit/mt/pc
    
参考にしたページでは、main indexのheadのlinkのところをfeedburnerのurlに変えるとあったけれど、いつまた気が変わって戻すかわからなかったので、今は変えていない。
あとは、インデックスの構築時にfeed.xml以外のrssが生成されないようにすれば良い筈。
twitterにはまっているわけですが、携帯をパケット定額にするのはもったいないので悩んでいました。
i-modeからアクセスできる手段はいろいろな人が提供してくれているのですが、webページを毎度リロードするのでパケット代がかかります。(その後の追試で、画像をoffにするとだいぶ違うことがわかりました)
で、iアプリで作ってしまえば、通信部分を最小化できるのではないか?と考えてiアプリの開発をはじめてみました。
調べれば調べるほど、iアプリの制限のきつさに泣きそうになりながら、当初の予定からどんどん仕様を削っていき、なんとか最低限の機能のα版までこぎつけたので、公開してみます。(人柱募集)
しかし、実際に端末(SO903i)で動かしてみて、画面いっぱいに表示されないわ、激しく遅いわで、開発意欲は減退気味です。
itm.JPG
さて、動かすための前提条件ですが、以下になります。
  • php4(gdとかmbstringとか対応してるもの)が使えるサーバがある
  • DoJa-5.0プロファイル対応の携帯を持っている(903i, 904iシリーズ)
  • 携帯に、sdカード等のメモリカードが刺さっている
  • 動かすことによって何かあっても文句言わない
では、実際の手順です。
  1. ここからアーカイブをダウンロード。サーバの好きなところに展開する。
  2. itm(ディレクトリ名は好きなものに変えて問題ありません)/itwitter.php を編集する。
    $icc = ''; /* 携帯のicc */
    $user = ''; /* twitter のログインid */
    $pass = ''; /* twitter のパスワード */
    
    上記3つを適切に設定する。携帯のicc(UIMカードのID)がわからない場合は、空欄のままiアプリからアクセスすると、itm/dat/log.txt に書き込まれるので、それをコピーする。
  3. itm/iTwitter.jamを編集して、PackageURLがjarをダウンロードするURLになるようにする。
  4. 携帯から、itm/ にアクセスする。"DOWNLOAD"のリンクがあるので、iアプリをダウンロードする。
  5. 後は、普通にiアプリとして起動するなり、待ちうけアプリに設定するなり。
説明書
  • 更新ボタンを押すか、1分立つとサーバに取りに行って更新します。
  • 右上(?)のソフトキーを押すと、1分毎の自動更新をするかどうかをトグルします。
  • 待ちうけアプリのときは、自動更新がonでも、フリップを閉じると自動更新をやめます。
  • エラー処理とかまだまだなので、突然アプリが落ちることがあると思います。
今後の予定
  • 設定画面をつけて、通常時、待受時それぞれの更新間隔を設定できるようにする。
ちなみに、iアプリのソースはここから

javaはちょっとわかるものの、phpは全然わからなかったので、miniturboさんのtwitterMobileをはげしく参考にさせていただきました。ありがとうございます。
その中で使われている、Service_Twitterを作成された悠希さんにもはげしく感謝しております。

EclipseのDoJaの開発プロジェクトを、subversionに入れて、デフォルトのworkspace以外の場所にチェックアウトしたら、スクラッチパッドのサイズが変えられなくなりました。
ちょっと調べたら、以下がひっかかりました。
バグだよな~これって。
それと、EclipseでDoJaプロジェクトをデフォルト以外のワークスペースに作成し、ADFのSPsize値を設定しようとすると 「スクラッチパッドの作成に失敗しました。」 とメッセージが出てファイルが作成されません。 デフォルトのワークスペースに作成すれば問題無いし、iアプリ実行時にはちゃんとspファイルを作成してくれるので困らないのですが。
iTwitterMobile0.2.1を公開して、次の0.3に取り掛かっています。
最初に携帯から送る時に「~」が化ける問題をなんとかしようと思いましたが、なかなか根が深いです。
現在の実装としては、以下のようになっています。
  1. テキストボックスに入力された文字列をStringで取得。
  2. 文字列をcom.nttdocomo.net.URLEncoder.encode()でx-www-form-urlencoded 形式の文字列に変換。
  3. サーバに送信
  4. サーバ側で、phpのmb_convert_encoding()で自動判別してutf-8に変換。
  5. phpのhtmlspecialchars()を通して、twitterのサーバに送信
曲者なのがcom.nttdocomo.net.URLEncoder.encode()で、APIリファレンスによると「文字列を URL エンコード形式の文字列に変換します。 Unicode 文字列をデフォルトエンコーディングの文字列に変換した後、 x-www-form-urlencoded 形式の文字列にエンコードします。」とあります。
で、DoJaのエミュレータの場合、Windowsで動いているので、Javaの内部形式からWindows-31Jに変換されてx-www-form-urlencoded 形式になります。
phpのmb_convert_encoding()の自動判別は、windows-31jではなくsjisとして解釈するので、ここで「~」が化けます。
なので、とりあえずサーバ側を自動判別でなく、sjis-win(mb_convert_encodingでのwindows-31jのことらしい)でやってみたら、エミュレータでは問題なく「~」が投稿できるようになりました。
で、さっそくと実機(SO903i)でやってみたら、今までどおり化けてくれます。
追試してみたところ、com.nttdocomo.net.URLEncoder.encode()を呼んだ段階で「~」が「?」に化けているようです。
えぇぇぇ~!って感じです。普通にキーから入力した文字が「デフォルトエンコーディングの文字列に変換」で化けちゃうってどう言うこと?WAVE_DASHがFULLWIDTH TILDEに化けるとかならわかるけど、?になるって・・・。
今のところ、com.nttdocomo.net.URLEncoder.encode()が悪いのかSO903iの実装が悪いのかわかりませんが、とにかく今のやり方では「~」が使えません。

ん~、utf-8でgetBytes()して、自前URLEncoderを書くしかないかなあ・・・。
追試プログラムを書いて実験したところ、以下のことがわかりました。
  • SO903i で、「から」を変換して入力される「~」はJavaの内部では\uff5e。
  • SO903i で、記号から選択して入力される「~」はJavaの内部では\u301c。
  • SO903i上では、上の二つの文字はまったく同じグリフで表示される。
  • SO903iのJavaでデフォルトエンコーディングでgetBytes()した場合、\uff5e は 3f(?)に、\u301cは8160(~)に変換される。
  • WindowsのDoJaエミュレータでは、\u301cは~で表示されるが、\uff5eは?になる。getBytes()の結果はSO903iと同じ。
と、言うわけで、iアプリ側の対応としては、サーバに送信する前に、\uff5eを\u301cに変換してあげれば良さそうです。
ただし、この8160をphpのmb_convert_encodingでsjis→UTF8の変換をしてtwitter.comに送ると、帰ってきたときには 上がって下がる「~」ではなく下がって上がる「〜」になります。なので、サーバ側はsjisではなくsjis-winを指定してやれば良さそうです。
ちなみに、サーバから送られてくる文字列に関しては、SO903iの場合は\uff5eでも\u301cでもどちらでも同じ文字として表示されるため、sjisに変換しない限りはそのまま扱って問題なさそうです。

参考
xorg 7.2祭りで、ここのところ凍結されていた portsの更新が始まったので、セキュリティ系でひっかかるportsをupdateしようとしたら、当然のごとくxorg7.2関連で文句を言われた。
なので、/usr/ports/UPDATINGを見ながらxorgを7.2に上げる。
手順の中で、portupgrade -aするところがあり、途中でportsのconfigを聞かれてしまうため止まりながら実行して、ほぼ丸1日かかってしまった。
なぜか、やる前にインストールされていたportsの数は400だったのに、終わってみたら600だった。エラーが出て更新できなかったのは以下の二つ。
 ! www/mod_perl2 (mod_perl2-2.0.2,3)     (unknown build error)
 ! mail/faces (faces-1.7.7_6)    (checksum mismatch)
その後のmergebase.shとか言うシェルスクリプトは、conflictとか言ってファイルの一覧をずらずら出されたうまくいかなかったので、/usr/X11R6を消して/usr/localからリンクを張った。
ついでなのでOS本体もmake world。
再起動したら、sambaがcoreを吐きまくり。なんかわからないけど、sambaを再起動したら直った。(OSのシャットダウン時に適切にファイルが削除されなかったらしい)
SPAMメールがひどい。SpamAssassinとRazor2のおかげで、だいぶはじけてはいるものの、最近日本語のSPAMが目立つようになってきた。
これはいかんと調べて見た所、SpamAssassin関連実験場にパッチを発見。
パッチ自体は、日本SpamAssassinユーザ会が開発しているらしいのだが、このサイトには3.1.4までのパッチしかない。(上のサイトには3.1.8のパッチがある)
下準備として以下を実行。
  1. portsから、japanese/mecabを WITH_CHARSET=utf-8 でインストール。
  2. portsから、japanese/mecab-ipadicを WITH_CHARSET=utf-8 でインストール。
    ※ ドキュメントには、char.defを書き換えるように書いてあるけど面倒なのでパス。どのくらい影響があるのかは判断できなかった。
  3. portsから、japanese/p5-Text-MeCabをインストール。
  4. portsから、converters/p5-Encode-Detectをインストール。
パッチをダウンロードしてきて、portsのfilesディレクトリにpatch-aaとか言うファイル名で置いてみたが、うまくパッチがあたらない。
しょうがないので、一度makeしてから、work/Mail-SpamAssassin-3.1.8ディレクトリに移動して手動でpatchをあてる。make install してみたが、spamdを起動するとライブラリが足りないみたいなことを言われる。
最初は足りないファイルを一つづつコピーしていたのだが、面倒になってwork/Mail-SpamAssassin-3.1.8/lib/Mailを/usr/local/lib/perl5/site-perl/5.8.8/ にコピーしてしまった。
続いて、/usr/local/etc/mail/spamassassin/local.cfに以下を追加。
normalize_charset 1
そして、/usr/local/etc/mail/spamassassin/tokenizer.preを以下の内容で作成。
loadplugin Mail::SpamAssassin::Plugin::Tokenizer::MeCab
これで、spamdは無事に動いている。効果があるかどうかは、現在の状態で日本語のメールを学習させてからかな。
2007年5月
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

このアーカイブについて

このページには、2007年5月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2007年4月です。

次のアーカイブは2007年6月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.1.1