xmlrpcブログ投稿時の投稿時刻指定

2007/09/13 | XML

あいもかわらずxml-rpcで遊んでいる今日この頃(生活も厳しくなってきたT_T)。ブログ投稿時に、投稿時刻をプログラムを動作させたその日時以外を指定したい場合が出てきた。つまり、例えば「投稿日時を過去の日付を指定したい」といった具合だ。iso8601のフォーマットがどうとかこうとか書いてあるウェブサイトはいっぱい見つけたけど、「じゃぁ、実際どうすりゃいいのよ!」というところで放置していた。
今日ふと思い立ってやってみたら、簡単に出来た。でも忘れそうなのでメモしておく。ちなみに使用するのはxmlrpc.inc(http://phpxmlrpc.sourceforge.net/)。

まず実際のデータから。記事投稿時はもちろんXMLでサーバにデータを送るわけだが、そこはこんなXMLになる。
<dateTime.iso8601>20060418T21:00:21<dateTime.iso8601>

上記の真ん中のデータはUTC指定で、日付(年月日)と時刻(時:分:秒)を「T」でつないだもの、ということになる。2007年12月31日23時59分59秒なら
「20071231T14:59:59」
という値が入るはずだ(日本は9時間早いのだからUTCの時刻表記では9時間引いておく)。

これを手動で計算するのが一番いい。ちなみにPHP5ではiso8601フォーマットで日時を返すdate関数のオプションが用意されているらしいのだが、自分の環境は全てPHP4なので、ここでは使えない。でもxmlrpc.incには相応の関数が用意されていた。こんなの。

function iso8601_encode($timet, $utc=0)

戻り値はUTCの時刻だ。引数$timetは自分が指定したい日時のユニックスタイムスタンプ値。これを直接UTCで指定した場合は次の引数$utcに1を指定する。デフォルトは0で与えられたタイムスタンプから自動的にUTCに変換した値が返される。簡単お手軽関数だ。

でも、実は注意が必要で、サーバの「タイムゾーンのオフセット秒数」を使っているので、海外サーバで日本向けサービスを・・・なんて場合にはヘンテコリンな時刻になってしまう。どうせなら

function iso8601_encode($timet, $offset=0)

みたいにして、オフセットの時刻で指定できるようにすればよかったのに・・・。てことでここの関数は簡単なので、すぐ自作してしまおうっと。

APIとPHPのまとめ

2007/09/11 | XML

最近はYahooやAmazon、楽天といった各種ウェブサービス(API)を絡めた開発を多くやっている(といっても、仕事が暇なので自分用サイトとかアフィリエイト用サイトを数多く作っているのだが・・・)。またAPIを提供する会社もたくさん増えてきたので、これから本業でもそういう仕事が増えていくと思っている。実際、最近新規で受けたり相談されている仕事もウェブサービス絡みだ。そこでウェブサービス利用の「傾向と対策」みたいな、受験勉強的メモを残しておくことにする。

(0) APIを利用するために
各種APIを利用するためにはいろいろな手順を踏まないといけないことが多い。例えば、Yahooの開発者向けAPIを利用するためには「Yahoo JAPAN IDを取得」「アプリケーションIDを取得」などの手順を踏む必要があるし、さらに一日あたりのアクセス回数上限なども気にする必要がある。もちろん利用規約も守らなくてはならない。実際にプログラムを組む前に、API毎に諸々調べておく必要がありそうだ。

(1) APIで必要な知識
APIを使用するに当たって必要な知識がいくつかある。知識といっても難しいことではなく、プログラムのスキルと言ってもいいだろう。必要なスキルは以下の3つくらいに分けられる。
・データを取得する
・取得したXMLをPHPで解釈する
・一日のアクセス上限回数を越えないよう制御する

(1)-1.データを取得する
データの取得は、最近ではRESTが一般的だ。xmlrpcやsoapを使うものもあるが、簡単と言う点からか、RESTが広く普及してきたように思われる。実際のアクセスにはPEARが使えるならHTTP_Requestや、その関連のものを使うのがいいだろう(関連リンク)。ちなみに一番お手軽なのは、file_get_contentsだ。引数にURIを与えればXMLを取得できる。ただし利用できるように設定されていることが必要だ。file_get_contents(‘http://www.yahoo.co.jp’)等として、データを取得できるかどうかチェックしてみたほうがいい。またデータの取りこぼしが出る場合があるので、要注意だ。一番確実なのはfsockopenを使って、直接HTTPでお話しすることだ。そういうクラスを一つ書いておくのがいいだろう(今後、要望次第で時期を見て公開する予定)。もちろんHTTPの最低限の知識は必要になる。

(1)-2.取得したXMLをPHPで解釈する
XMLは構造化されているとはいえ、ただのテキストだ。PHPで扱いやすいようにするには、配列や構造体に格納してやるのがわかりやすい。そのためのライブラリや関数は以前に紹介した。
XMLを配列に読み込む
楽天APIを少し・・・(XMLを配列に)
XMLを配列に・・・これが最適解かも
上記の記事を参考にしていただきたい。

(1)-3.一日のアクセス上限回数を越えないよう制御する
ウェブはいつ誰がアクセスしてくるかわからない。もちろん、いつ誰がアクセスしても、うまく動いているように見せたい。「なぜかあのサイトは夕方以降はエラーが出る」なんてことにならないようにしなくてはいけない。例えば、単純にデータを毎回取得するとし、ウェブサービスの一日のアクセス上限回数が5000回と仮定して、一日6000回アクセスがあると、最後の1000回は、上限回数を超えているので必ずエラーになるのだ。これは避けなければいけない。
上限回数が決まっているのであれば、それを超えないようにすれば良い。一番簡単なのは「一度取得したデータを使いまわす」ことだ。いわゆるキャッシュだ。キャッシュの実現方法はさまざまだが二つ紹介すると・・・。

[a] cronで一定時間ごとにデータを取得しておき、ウェブからのアクセスの際はそのデータを参照する。
[b] PearのCacheを使い、前回アクセス時刻から一定時間以上経過していない場合は前回取得したデータを使いまわす。

前者の場合は、取得したデータをデータベースなどに格納しておけば、参照は容易だろう。後者の場合はPEARのCache_Liteがおすすめかな(以前の記事「キャッシュして軽いページを(Cache_Lite)」参照)。

これだけのことを知っていれば、メジャーなウェブサービスAPIの利用は難しくない。あとは(1)-2でPHPで扱いやすいように整形したデータを、いかに使うか、ということに尽きる。

ウェブサービスやAPIの利用に関しては、今後発展していくと思うので、もし不明な点があれば気軽にコメントで相談してもらっていいです(「スクリプトを書いてくれ」みたいなのはお金もらいますが、一緒に相談できるような人がいれば、勉強会を主催してもいいくらい・・・)。

WordPress MUの不具合その2

2007/09/09 | SNS/CMS/ブログ

WPMUのもう一つ致命的な問題。xmlrpc接続にはたくさん問題があるようだ。しかも現在対応中とのことだ。検索してみると、かなりコアな部分の修正もあるらしく、時間がかかる模様、とのことだった。

自分にとって一番致命的だったのは「記事投稿して、その記事にカテゴリ設定する」という仮定が、普通のブログシステムと同様にはいかないことだ。普通なら以下の手順で記事を投稿する。
(1) 記事本文等を投稿
(2) (1)の戻り値として記事番号を取得
(3) 記事番号とカテゴリを送信してカテゴリ設定

この手順はWordPress MUには使えない。なぜなら・・・ブログを作成するたびにテーブルを増やすような設計になっているので、記事番号が必然的に重複するからだ。「ブログIDでしていすればいいじゃん」ってことになるが、ノーマルなカテゴリ設定のメソッドmt_setpostcategoriesではブログIDは指定できない・・・。つまりは基本的な仕様外っぽい。

そこで仕方なくソースを読んでみた。どうもWordPressでも独自のxmlrpcメソッドを用意しているようだ。そしてmetaweblog_newPostも若干拡張されているようで、記事投稿時にカテゴリ設定もできるっぽい感じだ。

しかし今回はカテゴリ設定のメソッドを自分で実装した(今から思えばなぜこんな手間なことをしたのか・・・)。wp.setPostCategoryなるものを用意した。通常のmt.setPostCategoriesにプラスしてブログIDもあわせて送信するのだ。いずれにしても独自拡張だからいい方法とはいえない。WPMUに実装されているメソッドだけで対応可能と思われるので、時間を作って再度ソースの解読にチャレンジしたい。

WordPress MUの不具合

2007/09/08 | SNS/CMS/ブログ

実は知らずに採用したのだが、WordPress MUはまだまだ出来て間がないらしい。どおりで情報が少ないはずだ。
まず日本語環境での利用については、htmlentitiesに関する記述はなかった。どうやらこれは変更しなくても問題ないのかもしれない。ただしMySQLにたいして発行する「SET NAMES binary」の記述は必須だろう(MySQLのバージョンに依存する問題だと思われる)。
普通にダウンロードして使用すると(現時点での最新版は1.2.4)、全て英語での環境となるが、日本語版のパッチが出ているらしい。以下のページにその記述が。

http://wpmudev.org/project/WPMU-Japanese-language-pack-1.2.1%20

基本的に、コレを入れなくてもメニュー等が英語になだけで日本語を使用する分には問題なさそうだから、自分は入れなかった。

そして根本的な問題。
xmlrpcで接続して記事投稿する際に・・・デフォルトのブログにしか投稿できないのだ。つまりブログを3つも4つも作ったとしても・・・あとから追加したものにはxmlrpcで投稿できないのだ。具体的には、まだその仕組みが用意されていないのだ。プログラム中に「we will support this in the near future」と書いてあったりする!。これはちょっと困る。

仕方ないのでハック。xmlrpc.phpの当該部分にブログIDからブログを選択する一行を書き込んでみた。

switch_to_blog($blog_ID);

これだけ。他で不具合があるのかもしれないけれど、とりあえず記事投稿さえ出来ればいいから、組み込んでしまった。これで問題なくブログを選択して、記事投稿できるようになった。
まぁ、まだできて間がないプログラムらしいので、これからもいろいろでてくるだろう。

しかしこのWordPress MU(略してWPMUというらしい)、大規模向けとか書いてあったりする。そういう意味でテーブルをわけるような設計にしてあるのだろうか・・・。

海外レンタルサーバ3iXの技術力の高さ

2007/09/07 | 海外サーバ

海外レンタルサーバ3iXネタが続くが、今日もいろいろあったので、コメントを残しておくことにする。

サーバ会社のウェブはこちら

とあるプログラムがうまく動かないので、サポートチャットにつないでみた。プログラムが動かないといっても、自分でプログラムの動きがわからないのではなくて、「動くはずなのに動かない」というパターン(まぁ、コレに関しては、そもそも動かないサーバに問題があるわけだが・・・)。
サポートが「ちょっとまってくれ」と言って約3分、今度は「試してみてくれ」という。すると、なんともう動いてしまうじゃん!。

おそらくセキュリティか何かの面で、サーバ側に特殊なプログラムがいれてあるような感じなのだが、それをサポートチャットの人が的確に理解して、わずか数分で修正してしまうとは・・・。
おそらく日本のサーバ会社だと、まずは「プログラムの動作確認については当社では保障しておりません」などというのが関の山だろう。また、たとえ問題があることがわかったとしても「仕様です」とでも、いうだろうし、さらに「設定変更いたします」と言ったとしても、確実に数日は待たされる。

それを思えば、やはり3iXは優秀だ。実は少人数の技術屋ばかりで運営していて、サポートチャットも技術者がやっているのではないか、と思う。海外のサーバなので、現地での評判がわからないところが不安ではあるが、それを乗り越えれば、好環境が手に入るわけだ。

まぁ、倒産したら・・・そのときはあきらめるしかないけど。


守谷市(まちの情報ポータル) 無料アンケートレンタルjpForm.net