TwitterAPIを利用したプロフィール画像更新はcontent-typeがimage/*じゃないとコケる。
正確にはステータス200が返ってくるけど、更新されないからもっとタチが悪い。
Twitter API Wiki / Twitter REST API Method: account update_profile_image
curl、rubyによるサンプルコードが載ってるけど、「Expect」ヘッダは不要。
PEAR公式のServices_Twitterを利用していたが、update_profile_imageが上手くいかない。
まだドキュメントが整理されていないので、ソースを読むかテストをみて、利用法を確認したが問題なし。
リクエストをトレースしてみたところ、content-typeが「application/octet-stream」だったのが気になったので「image/jpeg」にしてみたところ、画像の更新に成功。
PEAR::HTTP_Request2でmime-typeが取得できなかった場合、「application/octet-stream」がセットされていたというオチ。
pecl::Fileinfoかmime_content_typeを利用するようになっていたけど、–with-mime-magicとかコンパイル時に指定していなかった件。
cockok PHP PHP, services_twitter, twitter
PHPでtwitterを利用する場合にはServices_Twitterが便利です。
このServices_Twitterですが、公式のPEAR公式と野良(？)版が存在します。
openpear版はさっき見つけたけど、ちょっと使う気になれないので選択肢としてはPEAR公式か悠希さん版。
環境がCentOS5系、PHP5.1系だったので、悠希さん版を検討したのですが、CodeReposに入れられてるもののほとんど更新されておらず、APIが増えてる現状を考えると作業量的に厳しいということでPEAR公式を利用することに。
Services_Twitter-0.1.0 betaがリリースされたので日本のと比較してみた – 肉とご飯と甘いもの @ sotarok
この頃と状況は結構変わっていて、json必須ではない(でも速度の関係でpeclのjsonを利用)、HTTP_Request2でsocket通信とかになっています。
結構珍しい造りになっていて、api群はdata/api.xmlで管理されています。
pearコマンドを利用せずに利用する人は注意が必要。
cockok PHP PHP, services_twitter, twitter
いろいろな制約の関係でCentOS5系のPHP5.1.6でjsonの処理を行わなければならず、Jsphonだとパフォーマンス的に厳しいのでpeclのjsonを利用することになりました。
利用していたところ、mumber型がint型に桁落ちする現象に遭遇。
$ php -r "var_dump(json_decode('{\"id\":8271518654}'));"
object(stdClass)#1 (1) {
["id"]=>
int(2147483647)
}
調べてみたところ、PHP5.2.1の時代にバグレポートされてその後fixされたが、peclにはバックポートされてないようでした。
PHP Bugs: #41567: json_encode double conversion is inconsistent with PHP
バグレポートを参考に修正し、phpizeしてみましたが変わらず。
PHP5.2で取り込まれてるわけですが、そこでphpizeすればいけるんじゃ？ということで5.2.3のソースをダウンロードしphpize後make成功したのでインストールしてみましたが件の件は修正されていませんでした。
結局、PHP5.2.4で修正されていることを確認したのでここに軟着陸。
$ cd /usr/local/src
$ wget http://museum.php.net/php5/php-5.2.4.tar.gz
$ tar zxf php-5.2.4.tar.gz
$ cd php-5.2.4/ext/json
$ phpize
$ ./configure
$ make
$ sudo make install
$ php -i | grep json
$ php -r "var_dump(json_decode('{\"id\":8271518654}'));"
object(stdClass)#1 (1) {
["id"]=>
float(8271518654)
}
make通ったのはPHP5.2.9まで、PHP5.2.5～PHP5.2.9はjson_encodeで問題が見つかった為結局PHP5.2.4のを利用することに。
もうちょい時間があったらしっかり検証したいとこですが。
cockok PHP json, pecl, PHP
パッケージが見つからなかったのでソースからコンパイル
MeCabのインストール
cd /usr/local/src
wget http://nchc.dl.sourceforge.net/sourceforge/mecab/mecab-0.98.tar.gz
tar xzf mecab-0.98.tar.gz
cd mecab-0.98
./configure --prefix=/usr/local/mecab-0.98 --with-charset=utf8
make
make install
ln -sfn /usr/local/mecab-0.98 /usr/local/mecab
MeCab辞書のインストール
cd /usr/local/src
wget http://nchc.dl.sourceforge.net/sourceforge/mecab/mecab-ipadic-2.7.0-20070801.tar.gz
tar xzf mecab-ipadic-2.7.0-20070801.tar.gz
cd mecab-ipadic-2.7.0-20070801
./configure --prefix=/usr/local/mecab --with-charset=utf8 --with-mecab-config=/usr/local/mecab/bin/mecab-config
make
make install
cockok Linux mecab
ウノウラボ Unoh Labs: Q4Mを触ってみる
ずっと気になってるのでとりあえずインストールだけしておけば使うだろうってことで。
MySQLはremiリポジトリのものを利用してます。
CentOS5.3でPHP5.2を使う
バージョンは5.1.41の最新でした。
mysqlbugコマンドで–with-fast-mutexesオプションの有無を確認しましたが、有効になっていませんでした。
# wget http://q4m.31tools.com/dist/mysql-5.1.41-linux-x86_64-glibc23-without-fast-mutexes-q4m-0.8.9.tar.gz
# tar zxf mysql-5.1.41-linux-x86_64-glibc23-without-fast-mutexes-q4m-0.8.9.tar.gz
# cd q4m-0.8.9-linux-x86_64/
# cp libqueue_engine.so /usr/lib64/mysql/plugin
# mysql_upgrade
# install -m 755 support-files/q4m-forward /usr/bin
# cat support-files/install.sql | mysql -uroot
# DBI='dbi:mysql:database=test;host=localhost;port=3307'
./run_tests.pl
t/01-base-rnd_pos.........................ok
t/01-base.................................ok
t/02-queue-cond...........................ok
t/02-queue-owned-delete...................ok
t/02-queue................................ok
t/03-queue-error-wait.....................ok
t/03-queue-error..........................ok
t/04-blob-cond............................ok
t/04-blob.................................ok
t/05-multireader..........................
Multireader benchmark result:
Number of messages: 6400
Number of readers: 32
Elapsed: 1.184 seconds
Throughput: 5406.566 mess./sec.
t/05-multireader..........................ok
t/05-multirw..............................ok 1/4
Multi-reader-writer benchmark result:
Number of messages: 6400
Number of readers: 32
Elapsed: 1.718 seconds
Throughput: 3726.283 mess./sec.
t/05-multirw..............................ok
t/05-multiwait............................ok 1/4
Multi-reader-writer benchmark result under semi-starvation:
Number of messages: 6400
Number of readers: 32
Elapsed: 2.235 seconds
Throughput: 2863.895 mess./sec.
t/05-multiwait............................ok
t/06-multi................................ok
t/07-trans................................ok
t/08-forward..............................ok
t/09-pqueue-single-table-wake-listener....ok
t/09-pqueue-single-table..................ok
t/10-largedata............................skipped
all skipped: set BIG_TESTS=1 to run theese tests
All tests successful, 1 test skipped.
Files=18, Tests=68921, 222 wallclock secs (125.61 cusr + 12.97 csys = 138.58 CPU)
cockok Linux
