こんばんは、aquaです。

すっかりスマートフォンがマイブーム。iPhoneに続いてandroidも入手を検討。こちらは私用のガラケーを機種変更するつもりなんだけど、ガラケーから引き継ぎたい機能はおサイフケータイのみ。これだけは何とか引き継ぎたいので、felica付きの国産スマートフォンにする必要がある。まあ、felicaがあったところで、edyやiDのサービス展開はまだ先なのだが。回線はdocomoなので、スマートフォンとしては3Dのシャープlynxか、防水の東芝regza phoneが選択肢。ガラケーでもずっとシャープを使っていたので、初物はシャープがマシという個人的経験からsh-03cに決定。

年末に探し回ったので、regzaは殆ど在庫がなかったものの、lynxは場所によってはそれなりに見つける事が出来た。docomoのポイントやらキャンペーンやら、更には5000円分のポイントが当たってたりして、やたら安くで買う事は出来た。実質、2万円くらいだった気がする。おサイフケータイがまともに使えるようになるまでは、SIMを差し替えながらオマケ的に使うつもりだったが、一度触りだすともはやガラケーを使う気はしないｗ edyとiDは封印して、suicaは以前使っていたpasmoに戻して使う事に変更。

iPhoneのときのように、自力で準備したActiveSyncサーバと同期するには『Moxier Mail』が一番相性よかった。しかし、android向けに用意されているアプリの殆どは、当たり前だがgoogleサービス向けに特化したものが多く、それらを利用できない事はandroidのメリットを小さくしてしまうように感じた。なので悩んだ挙句、自前サーバの機能をgoogle appsに置き換える事を決意し、試行錯誤しながらデータの移行に成功した。既存のデータをgmailに移行するのは何とかできたが、逆はかなり難しそうだね。

さて、ネットワーク上のリソース(メール、カレンダー、TODO、連絡先)がgoogle化した事でアプリの選択肢は大いに広がる。メールはK-9 Mailを、カレンダーはジョルテを、TODOはAstrid Taskを利用する事にした。他にもiPhoneで利用していた機能の代替となるものを少しずつ見つけ出して置き換えていく。podcastの代わりにMyPOD、iPodの代わりにMeridianなど。アプリの選択肢はandroidの方が充実していて、いろいろ試す楽しさなどwindowsを触り始めた頃の感触に似ているかもしれない。気が付けば、すっかりiPhoneを触らなくなってしまった。

こんばんは、aquaです。

忙しいときに限って自宅サーバが壊れる。一時的に読み込み専用のファイルシステムになったのに、再起動したら直っちゃったから先延ばしにして使い続けたからかな。遂に再起動しても読み込み専用のままで書き込みできなくなってしまった。ディスク2枚あったしミラーしていたはず、とか思いつつ見てみると何もしていなかった。ミラーだとオペミス救えないから、手動で同期しようと考えて何もしていない。自宅サーバの運用はずさんの典型になるね。読み込みだけできるうちに別のディスクへデータを退避。

実際にはあらゆるメールを自宅サーバで受け取っていたので想像以上に不便。一刻も早く直したいが仕事は忙しいし、細かい移行を考えている余裕がない。思い出したのが、さくらのVPS。仕事でも仮想サーバは使っていたし、思ったよりも便利な印象。もともと、さくらの専用サーバには入っていて、そこで動かしている機能をVPSに移して、毎年10万円以上かかっている専用サーバをやめようとも考えていた。4、5年前のサーバスペックに10万円かかるって、コストパフォーマンスが異常に悪く感じてしまう。

さくらのVPSはすぐに使えるって事で、早速申し込む。リソースはメモリ512MB、ディスク20MBと少な目だが、DNSやメール程度であれば充分。仮想化はKVMで完全仮想らしい。しばらくすると準備が整って、VPSコントロールパネルから操作してみる。CPUとかトラフィックがグラフで見れる。リモートコンソールで、普通にコンソール作業も出来るね、便利。rootのパスワード変更がわからないので、とりあえず再インストールを試してみる。CentOS5の64bitでセットアップが完了。ログインしてみると、特にエコーバックの遅延もなく快適に使える。

DNSは専用サーバの方で動かしていたので、とにかくメールサーバを移行する。postfix + postfixadmin + cyrus-sasl + dovecot + mysqlで構築。自分で作ったとはいえ、めんどいな。既に仕事で徹夜続きなのに、この対応作業で更に眠れない。が、死ぬ気で作るとすごい早さ。人間の底力って侮れないねｗｗｗ 何とか出来たもののsmtpのポートが動かない。iptablesを取っ払っても変わらず。改めてさくらのHPを見直すと、評価期間中はsmtp使えない模様。即座に本契約に切り替えてメールサーバ復活!!疲れた･･･。

こんばんは、aquaです。

さて、サイト構成の変更以来、googleからの誘導が激減して早半年。もはや以前のレベルでの誘導は期待できそうにない。あまり改善を見込めないものの、何となくウェブマスターツールはちょこちょこ見ている。4月頃から割とインターフェースが変わって、検索キーワードと表示順位や表示回数、そしてクリック数など非常にわかり易くなった。それにしたって
以前のスコアリングが返ってくる気配はない･･･。不思議な事にAdsenseによる売り上げは倍近く伸びてきているので、何だかしっくりこない。

何か好材料が見つからないかなあ、とウェブマスターツールを巡回していると、そのホームに当たるページに『サイトの再審査』という心躍らせるリンクを発見したｗ 早速クリックして内容を見てみると以下の表示。

『ウェブマスター向けガイドラインを遵守しているにもかかわらず、サイトが Google の検索結果に表示されなかったり、以前より掲載順位が下がったりしていると思われる場合は、サイトの再審査をリクエストできます。 』

まさにこれだ！同じページ内に『サイトの再審査をリクエストする』というリンクがあったので、こちらのページから思いの丈を送ってみる事にした。

何度もリクエストを処理してくれるとも思えないので、送信する文面は慎重を期した。まあ、取り繕う必要もなく、真実を書き連ねておけば、きっと思いは通じるだろう。コンテンツの増加に伴うサイト構成の修正と、それに伴うページ重複状態の発生、リダイレクトによるそれらの適正化など。どれもユーザービリティを考えての変更であったにもかかわらず、googleの検索結果において、表示順に大きなぺナルティを受けてしまった事をまとめた。これで後悔はない、という文面でフォームからリクエストを送信！

当日か翌日か忘れたけど、ウェブマスターツールのホームに『インデックス登録の再審査リクエストを、サイト所有者から受け取りました。』というメッセージが送られてきた。手続きには数週間かかると書いてあったので、あまり期待しないで待っていると、一週間後には『再審査リクエストを処理しました』というメッセージが入っていた。しかし、その後もあまり表示順に大きな変化は見受けられず･･･。現在のスコアリングが妥当という判断なのか、次回のディープ・クロール時に反映されるのか、またもや期待しないで待つ日々が続く･･･。

こんばんは、aquaです。

さて、何とかffmpegthumbnailerをインストール出来たので、そもそもの目的であったmediatombの動画サムネイル対応をトライしてみる。PS3で動画選択時に動画のサムネイルを表示出来るようにする。最新版である0.12.1をダウンロードしてソースからインストール。前バージョン同様、インストール自体はすんなり問題なく出来た。一応気にしたのは、configureの最後に表示されるCONFIGURATION SUMMARYの中で、ffmpegthumbnailerがyesになっている事。当然だが、ffmpegthumbnailerを準備する前はnoになっていた。

新しいconfig.xmlにて、もう一度設定を加える。設定ファイル内でffmpegthumbmailerが有効になっている事を確認。以前と同じく、mysqlを利用する設定やm2ts、asfなどの拡張子への対応を加えていく。DBも一度消去してテーブルから再作成した。mediatombを起動した後、ウェブから管理画面にアクセスして対象の動画ディレクトリを登録する。以上で再構築は完了なので、早速PS3からアクセスしてみる。XMBからmediatombの動画コンテンツを表示すると、しばらくウェイトした後に･･･サムネイルが表示された！

ここまでは非常に簡単だったのだが、再び動画タイトルの文字化け問題が発生。今回も様々な組み合わせを試みるが、なかなか解決せず。テンプレートもいじったりしてみたが効果なし。諦めて一旦設定を戻して、対応を翌日に延期する。翌日、改めて見てみると文字化けが解決してる･･･。結論から言うと、config.xmlでは以前と同じく、filesystem-charsetやmetadata-charsetをCP932に指定する。今回のバージョンでは、mysqlはutfのままでよいみたい。この組み合わせで、データをローディング直後は文字化けするのだが、しばらく放っておくだけでそれが直るようだ。

あとは各種フォーマットのコンテンツへの対応を確認する。動画コンテンツから見てみると、asfはwmvとして処理する事で問題なし。m2tsもmpegにマッピングして再生出来た。音楽コンテンツもomaについては再生可能。更に驚きだったのだが、前バージョンでは再生出来なかったaa3もomaに紐付ける事で再生出来るようになった。文字化けのところの動きがちょっと納得いかないが、基本的にやりたかった事は全て可能となった。参考までに、以下に自分で設定したファイル・フォーマットのマッピングを記しておく。

<map from=”asf” to=”video/x-ms-wmv”/>
<map from=”m2ts” to=”video/mpeg”/>
<map from=”oma” to=”audio/x-sony-oma”/>
<map from=”aa3″ to=”audio/x-sony-oma”/>

こんばんは、aquaです。

先日、導入したmediatombは主にPS3での写真閲覧や動画閲覧に利用している。写真についてはサムネイルが見れるのだが、ビデオ動画についてはサムネイルが表示されないため、ファイル名でしか特定することができない。mediatombでのサムネイル対応を行う方法を調べてみたところ、バージョン0.12からはサムネイル表示が可能との事。自分が構築したバージョンは0.11。既に0.12はリリースされているので導入を試みる。サムネイルに対応するには、ffmpegthumbnailerが必要らしいので、これから着手する。

ffmpegはインストール済みなので、それを利用する形でffmpegthumbnailerのインストールもそれほど難しくないだろうと思っていたのだが、実際には失敗しまくりで全く進まない。そもそもffmpegを/usr/localにmake installしているのがいけない気もするが、必要とする各種ライブラリを見つける事が出来ない。環境変数等で細かくライブラリのパスを指定して、configureは通ったがmakeが通らない。気になる箇所を書き換えてmakeなどもしたが、キリがなさそうなので諦めることにした。

ググってみると成功するパターンは、ffmpegをyumでインストールしているケースが多い。切り分けの為にもffmpegをyumで入れ直して、どうなるか見てみることにする。インストール方法はこちらのブログを参照し、まずはRPMforgeをyumリポジトリに追加するためにrpmforgeをインストール。続いて、yumにてrpmforgeを利用してffmpegをインストールする。この辺はどうという事もなくインストール出来た。インストールされたffmpegについて、前回同様に簡単な動作確認をしてみたが、それについても問題なし。

やっと目的のffmpegthumbnailerのmakeにリトライ。しかし、手動でインストールしたバイナリやライブラリのパスを見に行ってしまうので、古いものを全て削除した。すると今度はライブラリが見つからない、というエラーが出る。ちょっと考えてみた結果、ffmpegに加えてffmpeg-develが必要だろうと推測。上記同様の手順でインストールして、もう一度ffmpegthumbnailerに挑戦。結果から言うと、configureもmakeもあっさり通った。ちょっともやもやは残るが、今回はこの環境でよしとしよう。

wget http://dag.wieers.com/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
rpm -ivh rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
yum install ffmpeg
yum install ffmpeg-devel

以下、参考までに。

• ffmpegthumbnailerのインストール

こんばんは、aquaです。

メーラはbeckyを利用していたが、個人メール環境をimapに切り替えてから、ぼちぼちthinderbirdを使い始めてる。thunderbird 3.0がリリースされて全文索引が付いたり、魅力的な多くのプラグインが作成されていたりと、そろそろ本格的にthunderbirdへの切り替えを検討する。まず既存メールの移行だが、幾つかのサイトで紹介されている通り、それほど難しくなかった。CircleBeckyというbeckyのプラグインを利用する事で、mbox形式でメールデータをエクスポート出来る。各フォルダごとに1ファイルの形で生成される。

これらのファイルをthunderbirdのメール・フォルダへ移す。その際に拡張子の.mboxは削っておく。この状態でthunderbirdを起動すれば、フォルダのままでメールとして認識してくれる。しかし、thunderbird 3.0では全文索引を作成する事になるので、メール数によっては膨大な時間の索引更新が発生する。多くの場合、フォルダによるメール仕分けからthunderbirdらしいタグ管理に移行するので、一旦は索引更新を停止してメンテナンスする方が効率よい。ツール→オプション→詳細でグローバル検索の更新のチェックボックスを外すだけ。

最初はbeckyと同じ管理方式で30個くらいあるフォルダにそれぞれメールを振り分けていたが、フォルダを選択するだけで数秒待たされる程の遅さ。完全にディスクアクセスによる遅延なので、10年以上の間に貯まった100万通近いメールがよくないのだろう。これまた3.0から実装されたアーカイブ機能を使って、2010年のメール以外をアーカイブ・フォルダへ移していく。これでフォルダ選択は早く動くようになったものの肝心のタグ検索が遅い。フォルダ横断的にタグ検索をするのが原因か。何パターンか試験した結果、フォルダ数を減らす事でチューニング可能と判断。

不要になったフォルダを削除したり、一緒に出来るフォルダをマージしたり、30はあったフォルダを5個に減らした。thunderbird向けのデータ構造へと変更させた結果、タグ検索も高速化した。マージしたメーリングリストなども検索フォルダで絞り込んで表示できるように設定しておいた。そして、停止していた全文索引の更新を有効化する。全文索引の対象はアーカイブ領域も含まれるため、数日に渡って索引メンテナンスが必要だった。索引メンテ中は頻繁にウィンドウズが凍りつく時間があるので、かなり不便。寝てる時間などのみ索引更新を有効にして徐々に作成していくのがよいだろう。

こんばんは、aquaです。

MediaCoderを使ってPSP用の動画を作成したりしているが、ウィンドウズ環境を使っているとクライアント環境が重くなるため、いろいろと不便だ。なので、常時稼動状態のLinuxサーバで同様の処理が出来ないか検討する。少し調べてみると、そもそもMediaCoderもffmpegやmencoderというフリーのソフトを利用して(それ以外もあるが)フォーマット変換やサムネイルの生成などを行っている。これらのファイルはMediaCoder直下のcodecsというフォルダに入っている。これらのツールはオープンソースなので当然Linuxにインストールも可能だ。

この部分を可視化したい理由としてはもう1つある。MediaCoderのバージョンを少しあげただけで、それまで安定していた変換処理が不安定になり始めたためだ。結果的にはバンドルされているffmpegが問題で、それを使う変換やサムネイル生成の箇所で落ちる事がわかったが、今回は勉強も含めて絞り込みに多くの時間を要した。という訳で、変換ツールをLinux側に構築する作業を進める。調べた限りでは、初めて使うにふさわしい汎用性の高いツールとしてffmpegをインストールする事に決定。必要なソフトを洗い出してインストールしてみる。

必要とするライブラリは多いが、インストール自体はそれほど難しくなかった。まだ見慣れないソフトが多いため、微妙な派生バージョンがよくわからず、どれを導入すべきか悩む事はあったが。とりあえずは素直にインストールしてみて、実際にffmpegコマンドを発行してみる。主に利用するのはPSPで再生する動画向けのmp4変換とサムネイル用の画像生成処理だ。軽めの動画ファイルを使って動作確認を実施した。動画変換用のコマンドは以下。

ffmpeg -y -i INPUT.wmv -ac 2 -ar 44100 -acodec libfaac -ab 128k -vol 256 -s 480×272 -vcodec libx264 -aspect 16:9 -f psp -b 800k -bt 800k -threads 0 -vpre main -level 21 -refs 2 OUTPUT.mp4

サムネイル生成用のコマンドは以下。

ffmpeg -y -i INPUT.wmv -f image2 -pix_fmt jpg -vframes 1 -ss 300 -s 160×120 -an -deinterlace OUTPUT.jpg

これで特定のディレクトリの動画を自動でmp4化しておいたり、気に入らなかったサムネイルを個別に作り直す事が可能になった。問題はウィンドウズ経由のsambaフォルダなのでマルチバイトのファイル名が面倒なのと、サーバとはいえ数年前に購入したものなので30分の動画ファイルでも変換処理に45分くらいはかかってしまう。その処理を動かすサーバがウェブサーバやメールサーバを兼ねているので、余り負荷が集中するのも好ましくない。ウィンドウズ・クライアントもそうだが、この動画変換を始めてから数年振りに買い替えを検討したくなってきた。

以下、参考までに。

• lameのインストール
• opencore-amrのインストール
• faacのインストール
• faadのインストール
• x264のインストール
• xvidcoreのインストール
• ffmpegのインストール

こんばんは、aquaです。

以前の記事で紹介したとおり、ファイルサーバ上に貯まった動画や音楽をネットワーク上で共有するために、LinuxのDLNAサーバであるmediatombを利用している。ファイルサーバはsambaで公開されているので、Linux側ではsmbmountしてmediatomb上で公開している。DLNAクライアントは今のところPS3しかない。一般的な動画や音楽は再生できているが、幾つか気になる問題が残っていた。その1つが主題にもなっているコンテンツの日本語タイトルにおける文字化けだ。sambaサーバ上でコンテンツを管理しているため、ややこしい状況になってしまっている。

sambaサーバ上の文字コードだが、ファイルサーバであるtera stationなので細かい設定を確認する事は出来ない。が、windows環境から文字化けせずに見えているので、おそらくSJISだろう。これをmediatombのブラウザでアクセス出来る管理ツールで確認すると、既に文字化けしている。まずはここから修正を試みてみよう。これについてはそれほど難しくなく、mediatombのconfig.xmlにてファイルシステムとmediatombの文字コードをSJISに指定すればよい。具体的には以下のような設定を追加した。

<filesystem-charset>CP932</filesystem-charset>
<metadata-charset>CP932</metadata-charset>

この設定でブラウザ上で確認できる文字化けは解消する事が出来た。しかし、それはFilesystemタブ側だけの話で、Database側の文字化けは依然続いていた。DBにはmysqlを使用しているのだが、ここのテーブルの文字コードはutf8が指定されている。ここも同様にSJISに直さなければならないだろう。タイトルが含まれるテーブルはmt_cds_objectというテーブルなので、この表だけSJISで作成し直した。この変更はテーブル定義を修正する形で対応した。こちらも具体的には以下のDDLを実行した。

ALTER TABLE mt_cds_object CHARACTER SET sjis;

しかし、それでも文字化けは解消しない。ほぼ諦めかけていたのだが、もう一度DBの中身を確認してみると文字化けしたままの状態だった。何となく一度データを消して、コンテンツを再登録してみると･･･上手くいった！これで日本語を多く含む音楽データもDLNAサーバ上で扱う事が可能となった。ついでにATRAC3のaa3ファイルを対応させようとしたが、PS3では再生する事が出来なかった。ファイル名の拡張子をomaにして、以下の設定を追加すると再生出来るのだが。ATRAC3のハンドリングがいい加減面倒になってきたのでmp3に移行しようかな･･･。

<map from=”oma” to=”audio/x-sony-oma”/>

こんばんは、aquaです。

本ブログへgoogleからの誘導が激減してから約一ヶ月、しばらくはPVの改善も見込めなそうなので、思い切って携帯対応してみた。携帯コンテンツであれば、また別の評価がなされるかもしれないし。どうやらwordpressのモバイル対応はプラグインによって簡単に実現できそうだ。今回は『Ktai Style』という評判の良いプラグインを使う事にした。いつも通りダウンロードして解凍したファイルを${WORDPRESS}/wp-content/pluginディレクトリに配置し、『プラグインの管理』画面でktai styleの欄で『使用する』をクリックする。

プラグインを有効化すると、『設定』と『テーマ』というリンクが選べるようになる。まず設定から確認したが、特に気になる設定箇所はなかった。次にテーマを見てみると、最初から幾つかのテーマが用意されていた。『photolog』というものが最も好みだったので、これを選択してみた。『コメントなし』がやたら目立つので少しだけ内容をいじった(wp-content/plugins/ktai-style/themes/photolog/index.html)。コメントへのリンクを削るのと(38行目辺り)、スペースが出来たので記事サマリーの文字数を増やした(43行目辺り)。

コンテンツが出来たところで、今度はモバイル用のsitemapを作成する。プラグインの改造もやってみたかったが、今回は時間をかけずに生成されたsitemap.xmlを変換して構築する。大した変換は必要なく、以下の変更を行えばよさそう。ファイルはsitemap-mb.xml.gzとして保存する。

xmlnsの箇所にxmlns:mobile=”http://www.google.com/schemas/sitemap-mobile/1.0″の追加
urlの箇所にの追加

our @input;
our @output;
our $file;
our $root_dir="${WORDPRESS}";
our $source="sitemap.xml";
our $mobile="sitemap-mb.xml";

open(IN, "<$root_dir/$source"); open(OUT,">$root_dir/$mobile");
while(<IN>){
        s/(xmlns=\".*\")>/$1 xmlns:mobile=\"http:\/\/www.google.com\/schemas\/sitemap-mobile\/1.0\">\n/;
        s/<\/url>/      \n     <\/url>/;
        print OUT;
}
close(IN);
close(OUT);

my $src_file="$root_dir/$mobile";
my $zip_file="$root_dir/$mobile.gz";
gzip $src_file => $zip_file;

以上の設定でしばらく運用していると、googleのウェブマスターツールでHTTPエラー(400 bad request)が多く発生していた。調査してみると、これはktai styleの仕様らしいので、robots.txtで該当の処理をクロールされないように設定する。具体的には以下のように設定した。

User-agent: *
Disallow: /wp-content/plugins/ktai-style/inc/redir.php

以上で、本ブログを携帯でも使う事が可能となった。

こんばんは、aquaです。

最近、ブラウザはFirefoxを使っている。仕事上、user-agentを動的に変更できるブラウザが便利だからだ。言うまでもないが、Firefoxの魅力はその豊富なアドオンにある。好みの機能をアドオンという形で、どんどん追加できる。しかし、このアドオンが本体のバージョンアップに合わせて必ず更新されていく訳ではない。そのせいで、気に入ったアドオンがあると、それが無効になるのが怖くて本体のバージョンアップをしづらくなってしまう。現在はFirefox 3.0系を使っていたのだが、3.6が出てしばらく経つのでバージョンアップを試してみる。

本体のバージョンアップは非常に簡単で、『ヘルプ』→『ソフトウェアの更新を確認』を選択すれば、最新版をダウンロードして更新してくれる。問題はここからで既存のアドオンが使えるかどうか。現在、使っているアドオンはFirefoxのキャッシュを操作するための『Cache Viewer』、マウスのアクションでブラウザの操作を行える『FireGestures』、携帯系のサイトを閲覧するための『FireMobileSimulator』、googleページランクを確認できる『Live PageRank』、タブ機能を拡張＆カスタマイズできる『Tab Mix Plus』。この辺りは特に問題なく追随できた。

無効になってしまったアドオンは、最小化時にトレイへしまえる『MinimizeToTray』、各種検索を検索バーへ追加する『OpenSearchFox』、Firefoxのタブ内でIEが使える『IE Tab』、LAMPソーシャルブックマークのScuttleへリンクを追加する『Scuttle』。MinimizeToTrayは『MinimizeToTray Plus』というアドオンで完全に代替できた。『OpenSearchFox』も『Add to Search Bar』というアドオンを発見したが、同一FORMに複数の検索ボタンがあった場合、検索先を選択できた機能がなくなってしまった。

IE Tabも『Coral IE Tab』というアドオンに入れ替えたものの、showtimeなどのDRMを必要とする動画サイトで再生が出来ていたのが出来なくなってしまった。Scuttleは以前、無理矢理に内部の互換情報を書き換えてインストールしたが、今回はもう一度更新されたアドオンを探してみる。それほど、苦労もなくこちらのサイトでアドオンを見つけた。細かい事は知らないがクリックしてもインストール出来なかったので、一度『名前を付けてリンク先を保存』でファイルをダウンロードしてから、ブラウザにドラッグ・アンド・ドロップしてインストール。これで、以前の機能を全てFirefox 3.6に引き継げた。

こんばんは、aquaです。

先日のURL改変について、ほぼ全ての旧URLを新URLに301リダイレクトするように設定出来た。数日が経過した後、googleウェブマスターツールにて状況を確認してみる。しかし、残念ながらタイトルタグの重複数は減少していない。状況を正確に確認するためにアクセスログを見ながら、実際に旧URLをクリックしてみる。間違いなく新URLに転送されているが･･･、よく見てみるとリダイレクトのHTTPステータスコードが『302』になっている。ソースを確認し、『ylsy_permalink_redirect.php』ファイルの405行目を以下のように修正。

function wp_redirect($location, $status=302) {
↓
function wp_redirect($location, $status=301) {

これで、今度こそ301でリダイレクトするようになった。次にクロールエラーを確認してみると、数百件に及ぶ『クロールを完了できませんでした』というエラーと更に十件強の『見つかりませんでした』エラーが発生している事に気付く。中身を確認してみると、幾つかの投稿ページのうち、タイトルを変更したページの旧タイトルが404としてリストされている。それほど数もなかったので『Redirection』プラグインにて、新タイトルにリダイレクトするよう個別に設定していく。

今回は念のため、アクセスログにてHTTPのステータスコードを確認する。旧URLをクリックしながら、アクセスログをウォッチしていると妙な動きが目に入った。旧タイトルが新タイトルにリダイレクトしているのは想定通りだったのだが、投稿ページへのアクセスが大文字含むURLから全て小文字のURLへと301リダイレクトされている。気になったので、ウェブマスターツールにて先ほどの『クロールを完了できませんでした』ページを見てみると、全て投稿ページで『リダイレクトエラー』と表示されている。

とにかく、このリダイレクトが悪さをしていると判断。どのプラグインで処理がなされているかの特定から調査を始める。各プラグインを有効・無効を切り替えていく方法で、すぐに『Permalink Redirect』の問題とわかった。かと言って、プラグインを止める訳にも行かないので回避方法を検討。Permalink Redirectのページ内に『Paths to be skipped』という設定を行う箇所があった。うちのサイトは投稿ページのURLが『/%category%/%postname%/』で、しかもカテゴリが全て日本語のままなので、全ての投稿ページが『/%』で始まる。試しに『/%.*』と設定して動作確認したところ、投稿ページにおける小文字リダイレクトは発生しなくなった。URL改変は本当に怖いね･･･。

こんばんは、aquaです。

前回のURL改変後より相変わらずPVが回復していない。今度はsitemap.xmlを作成して、検索エンジンに認識して欲しいURLを明示的に伝える事を試す。wordpressでsitemap.xmlを生成するには『google-sitemap-generator』を利用する。こちらよりプラグインをダウンロードしたら、いつも通りプラグインのディレクトリに配置する。wordpressの『プラグインの管理』ページより『Google XML Sitemaps』を有効化する。設定メニュー内にある『XML-Sitemap』にて必要な設定を行った後、『サイトマップを構築する』リンクをクリックすれば生成できる。

生成と同時にgoogleへの通知も行ってくれるが、念のためgoogleの『ウェブマスターツール』でも確認しておく。実は今まで利用していなかったのだが登録は非常に簡単。『サイトを追加』ボタンをクリックして自サイトのURLを登録する。あとは幾つか用意されている確認方法にて正当性をチェックする。今回は一番簡単そうなメタタグによる確認を選択。発行された任意のメタタグを自サイトのトップページに埋め込む。これで確認が済めば検索に関係する様々な情報にアクセス出来るようになる。

適当に情報を見ていると『診断』の『HTMLの候補』ページにて『タイトルタグの重複』が数十件カウントされている。中身を見てみると、投稿ページの旧URLと新URLが幾つも表示されていた。canonicalで処理していたつもりだったけど、余り意味ないのかな･･･。日付ベースだった旧URLからカテゴリベースの新URLに301リダイレクトをする方法を考えてみる。URL内に動的要素があるので、ちょっと悩んでいると『Permalink Redirect』というプラグインを発見。早速、セットアップしてみる。

プラグインを有効化すると『設定』ページに『Permalink Redirect』というリンクが出来るので、そのページで設定を行う。『Old Permalink Structures:』というテキスト・ボックスがあるので、そこに旧URLである『/%year%/%monthnum%/%postname%/』という情報を記載。『Update Options』ボタンで変更を適用し、動作確認をしてみると旧URLはきちんと新URLへ転送される。これで、まずは期待通りの動きとなったので、しばらく様子見てみる事にする。後半へ続く。

こんばんは、aquaです。

前回ユーザビリティの改善のために各文言の和訳や表示順の入替などを実施した。この変更は図らずもページタイトルのフォーマットにも及ぶ事になった。基本的にはPVを上げるための施策だったが、結論から言うとPVは激減した。正確な因果関係は不明だが、状況としてはgoogleの検索結果順序が大きく落ち込んでしまった。やはりgoogleのクシャミ一つでネット上でのポジションが大きく変わるというのは相変わらずのようだ。以前に運用していたサイトも、この手の問題でやる気がなくなって実質凍結状態にした事を思い出した。他の誘導パス作りをさぼっていたのがいけないんだけどね。

そんな訳で、すっかりPVも減ってしまったので、今まで試せなかった実験的な変更を追加していく。主にSEO対策まとめ系のページを参考にした。カテゴリにシングル・バイトのスラッグを準備していたが、これを日本語に戻した。URL内の日本語がどういう意味を持つか怪しいものだが、とりあえず様子を見てみる。更に記事のURLも『/%year%/%monthnum%/%postname%/』から『/%category%/%postname%/』に変更した。この変更により記事ページのURLが世の中的には重複する事になるので、それを防ぐためのcanonical属性導入を考える。

canonical属性は、検索エンジンに任意の記事について正しいURLを認識させるために使用される。canonical属性の追加には幾つかのプラグインが用意されている。『All in One SEO Pack』を試してみたが、タイトルの変更も行われてしまう。タイトルを処理に任せると日付の表示が『YYYY MM月 DD』のようにイマイチになる。ここは手元で修正したので、canonical属性のみ対応してくれるプラグインに変更する。その名も『Canonical URL’s』。プラグインとしてのインストール以外は何も設定できないツールだが、期待通りきちんとcanonical属性の追加は行われている。

ここまで作業が完了したところで、『404 not found』がちょこちょこ起きている事に気付く。過去のスラッグに対するアクセスが404になっていた。直接『.htaccess』を修正しようかとも思ったが、それ用のプラグインである『Redirection』を発見したので、旧スラッグURLを新スラッグURLに転送するように設定。ここでふと気付いたのだが、外からawstatsへのアクセス可能になっている。awstatsは元々、狙い済ました直接アクセスが非常に多い。調べてみたところ、httpd.confにアクセスを許可する設定が追記されていた。以前にawstatsを再構築した際に、スクリプトか何かで入り込んだのだろう･･･、こわやこわや。

こんばんは、aquaです。

ここ最近のUU及びPVは右肩上がり。とは言っても元々が大したトラフィックではないけど。年末と正月の投稿ラッシュで誘導が増えたのかな。そんな訳で、前回もblogそのものを修正したのだが、今回はアクセスログ解析であるawstatsを久々に修正していく。awstatsはドメインごとに準備する『awstats.www.domain.com.conf』というファイルをカスタマイズする。まずは内輪からのトラフィックがノイズになりつつあるので、カウントしないように設定する。『SkipHosts』というパラメータにスペース区切りで必要なIPを記載する。正規表現も使える。今回は以下。

SkipHosts=”REGEX[^192\.168\.0] 123.234.56.254″

次に24時間に一度しか更新していなかったバッチを1時間ごとに変更する。最近のapacheのアクセスログはrotatelogsによって、日次でログファイルを分断する事が多い。その為、現在は昨日の日付になっているアクセスログを読み出す、という設定になっている。これを昨日のアクセスログと本日のアクセスログの両方を見るように修正する。本日のだけだと前日てのログが完成する24時の時点で解析してくれない事になるからだ。アクセスログのファイル指定は『LogFile』というパラメータに対して設定する。コマンドも使える。今回は以下。

LogFile=”cat /usr/local/apache/logs/access-%YYYY-24%MM-24%DD-24.log /usr/local/apache/logs/access-%YYYY%MM%DD.log|”

そして検索文字列の問題も検討する。googleなどからどのような検索文字列で誘導されたかをレポートしてくれるのだが、その際に全角スペースなどが使われてしまうと、それ前後の言葉と合わせて1語と判断されてしまい、ノイズになってしまう。ググってみると幾つか対応方法はありそうだが、今回は修正が簡単そうなこちらのページにあるパッチを当てる事にした。パッチ適用後に念のため全データをリフレッシュすると、検索文字列も妙な重複や文字化けが解消し、すっきりと期待通りに表示されるようになった。

最後は似たような問題で、ページ表示ランキングでよく見られたURLをまとめてくれるのだが、何故か同じページが幾つかに分かれてしまったり、そもそもURLEncodeされているため一見してどのページが分からない。このURLEncodeも変換出来ないか調べてみた。こちらのページにて、アクセスログのURLEncodeを変換するコマンドが準備されていたので利用してみたが効果なかった。自力で簡単な修正もしたが変化せず。設定ファイルをよく見ていくがそれらしきパラメータはない。しかし、偶然『URLNotCaseSensitive』というパラメータを見つけた。これを1に設定すると、URLの大文字小文字を無視して集計してくれる。400種類近かったURLが半分近くまで減って分かり易くなったので、今回はこれでよしとした。

こんばんは、aquaです。

まもなく100投稿目を迎える我がブログ。100投稿目は何がいいかなあ、とかぼんやり考えてみたりする。2009年を振り返ると、19投稿から70投稿が追加され、89投稿まで増えた。内容の良し悪しはともかく、日次の訪問ユニークユーザー数及びページビューも4倍に膨れ上がった。投稿が4倍近くになったためだろうか。規模に合わなくなった機能を諸々修正する。まずタイトルを見直していく。カレンダーやアーカイブで表示した際のタイトルなどを以下のように修正(※”>>”という表示も削除)。

<title>
<?php
if(is_year()):
	echo get_the_time('Y年');
elseif(is_month()):
	echo get_the_time('Y年m月');
elseif(is_date()):
	echo get_the_time('Y年m月d日');
else:
	wp_title('');
endif;
if(wp_title('', false))echo ' - '; bloginfo('name');
?>
</title>

次に主要な箇所の英語表記部分をコツコツと和訳していった。RSSの表示も『WP Multibyte Patch』というプラグインを利用して抜粋表示に変更。そして、投稿ごとに表示されているadsenseを最初の1記事目のみ表示されるように修正し、サイドバーにもスカイスクレイパー型のadsenseを追加する。広告収入もPVに比例していないので、ちょっとテコ入れしてみた。1記事目だけにする制御は以下のようなコード。

<?php $ad_flg=true;
while (have_posts()) : the_post(); ?>
	<div id="post-<?php the_ID(); ?>">
		:
	記事内容の表示処理
		:
	</div>
	<div align="center">
		<?php if($ad_flg): adsense_deluxe_ads(); $ad_flg=false; endif; ?>
	</div><p/>
<?php endwhile; ?>

最後にナビゲーションの改善に取り組む。何と言っても、まともな投稿ナビが『最近の投稿』のみでカテゴリやタグをクリック時に選択された記事の索引がないのが痛い。数十の記事であればページングしてスクロールしていけば記事を見つけ出せるかもしれないが、100投稿近くになると非常にだるい。そこで、これについてもサイドバーに表示中の記事が一覧できるようなスペースを設ける事にした。カテゴリを選んだ場合は該当カテゴリに所属する記事一覧、タグを選んだ場合も同様である。日付や月単位のアーカイブを選択した場合もそれに対応する。

また、少しだけ設定を捻って1記事しか表示されない場合は、その記事が所属するカテゴリの記事一覧を表示。更に日付で記事を表示する場合も、うちのサイトは必ず1記事になるので同様に処理する事にした。この対応によって、興味のある記事に関連する記事タイトルを一望出来るようになったので、はるかに使い易くなったはず。少しはユーザーの滞在時間に効果があればいいなあ。複数カテゴリに所属するケースなどの課題は残っているが実装コードは以下である。

<ul>
<li><div id="recent-posts-2" class="widget widget_recent_entries">
	<h1>表示中の投稿</h1><ul>
<?php if (is_single() || is_day())
	foreach ((get_the_category()) as $cat)
		query_posts('showposts=20&cat='.$cat->cat_ID); endforeach; ?>
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
	<li><a href="<?php the_permalink() ?>"
		title="<?php the_title(); ?>"><?php the_title(); ?></a></li>
<?php endwhile; else: ?>
	<p><?php _e('該当する記事はありません。'); ?></p>
<?php endif; ?>
</ul>

こんばんは、aquaです。

以前から頭を悩ましている問題の1つに、ビデオカメラで撮影した動画の再生方法がある。ビデオカメラはsony初のハードディスクモデルであるHDR-SR1で、全てAVCHD(m2ts)ファイルで保存してある。撮影した動画ファイルをSonyPictUtilというソフトでVAIOに取り込む。VAIOもノートPCなので、それほどハードディスクには余裕がない。sambaで利用可能なTeraStationへデータを移す事にしている。TeraStationはRAID5で冗長化されている上に、もう1台のTeraStationに同期しているので、安全性はかなり高い。しかしSonyPictUtilの再生ツールはネットワーク越しのフォルダを参照できない。

という訳で、SonyPictUtil以外での再生環境を調べてみた。klmcodec425.exeをインストールすれば、Media Player Classicで再生可能となるようだ。これで再生可能にはなったものの、マシンスペックが足りないせいか映像が途中で停止してしまう。他に良い方法がないか検討してみたところ、PS3のDLNAクライアント機能においてAVCHD(m2ts)の再生が可能とわかった。PS3はPSPgoとの連携(リモートプレイやbluetoothコントローラの転用など)も楽しめそうだし、金額的にもかなりリーズナブルになってきたので早速購入する方向で考える事にした。

ネットワークやら時刻やらの初期設定を終えて、まずは東芝レコーダRD-X9のDLNAを使えるか試してみる。特に何の設定もせずに録画データを参照することが出来た。VAIOでは再生不可だったHD画質の番組も再生可能。次にビデオカメラで撮影したファイルを参照出来るように、LinuxサーバでTeraStationをsambaマウントした上で、mediatombと呼ばれるDLNAサーバを構築した。今回はmediatombをmakeする形でセットアップしたが、特にはまりどころもなく普通にインストール出来た。尚、AVCHD(m2ts)を再生するにはmediatombの設定ファイルに追記する必要がある。

mediatombは構築したサーバの50500ポートにて、HTTP経由で設定を行う。Filesystemの中で公開したいディレクトリを選択し、右上の『＋』ボタンで追加すればDLNAで参照可能になる。定期的に公開内容をリフレッシュした場合は、矢印に囲まれた『＋』ボタンをクリック。『Scan Mode』を『Timed』に設定し、『Scan Interval』を適当な値に設定すればよい。ついでに、動画だけでなく写真画像やiPod用に作った音楽ライブラリなどもDLNAで公開した。各メディアともPS3から参照可能になり、動画再生だけでなく写真のスライドショーや音楽再生も可能となった。あ、ゲーム買ってないな･･･ｗ

以下、参考までに。
mediatombのインストールと構築

SONY CECH-2000A 　新型プレイステーション 3/PlayStation3/PS3 【送料無料】

こんばんは、aquaです。

なんと技術系のネタは夏以来。もともとは技術ブログのつもりだったのに何てことだ･･･。過ごし易い季節だったので、外ばかり行ってたとはいえ。そんな訳で、すっかり寒くなってきたせいか家で何かをする時間が増えてきた。今回は特定の使い方をすると、kernel panicを起こす現行のkernelをupdateしてみる。昔はmakeやら何やらでえらい時間がかかったものだけど、今はyumで一瞬で終わる。しかし、yumはその時点で最新のものに更新してしまうので、インストールしたrpmをローカルに保持しておく。何かあったら、この実績の出来るであろうカーネルに再び戻せるようにするためだ。

さっそく以下のコマンドで更新対象カーネルを確認する。
yum list | grep kernel

今回は kernel.x86_64 2.6.9-89.0.11.EL のカーネルになる。特に問題なければ更新する。
yum install -y kernel*

/etc/grub.confに選択できるkernelが追加されているので、今回構築したカーネルを選ぶ。defaultパラメータに番号でしているするのだが、選択肢はゼロスタートで上から連番にIDが振られている。今回はCentOS (2.6.9-89.0.11.ELsmp)が2番目にあったので、『default=1』と指定する。ここまで出来たら再起動する。再起動後に『uname -a』で更新されたカーネルかどうかを確認する。
reboot

再起動後に以下の確認。
uname -a
Linux ns 2.6.9-89.0.11.ELsmp #1 SMP Tue Sep 15 07:08:59 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

今回、導入されたkernelのrpmは/var/cache/yum/baseにキャッシュとして残っている。これをローカルのyumリポジトリに登録しておく。yumリポジトリを構築するには createrepo と言うコマンドが必要なのでインストールしておく。
yum install createrepo

リポジトリ用のディクレトリを作成し、これをウェブサーバで公開しておく。今回は/yum/repos/centos4/x86_64というディレクトリを準備し、/yumをapacheで公開した。作成したディレクトリに先ほどのrpmを置き、createrepoして準備完了。
scp ns:/var/cache/yum/base/*.rpm /yum/repos/centos4/x86_64
createrepo /yum/repos/centos4/x86_64

このリポジトリを使う場合は、対象サーバの/etc/yum.repos.d/CentOS-Base.repoにてローカルサーバを見るように修正する。

[update]
name=CentOS-$releasever – Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
↓
[update]
name=CentOS-$releasever – Updates
baseurl=http://repo.domain.com/yum/repos/centos$releasever/$basearch/

変更が終わったらリストを確認してみる。外のリポジトリを見た後だと、キャッシュが残っていてローカルのリストを取りにいかないので、以下のファイルを削除してキャッシュを無効にする。
rm /var/cache/yum/update/cachecookie

あとは前述した通りに、カーネルを更新すればよい。本当に簡単に出来るようになったね。

こんばんは、aquaです。

以前から気になっていたサーバ単位での冗長化を実現すべくロード・バランスの方法を検討してみる。一般的に考えて、自宅環境で実現可能なロード・バランスは、DNSラウンドロビンかLVSといったところ。専用ハードの導入は当然ながら無理。障害時のホット・スタンバイやダウンしたサーバの自動切り離しを実施したい場合はLVSが現実的である。うちのDNSはmydnsなので動的な変更も難しくはないが、機能の本質を考えてLVSを採用する。いまどきのlinuxであれば特に障壁もなく使えてしまう、というのもLVSを使い易くなった理由の一つである。

早速LVSの構築に入るが、CentOS 5系で必要な作業はipvsadmとkeepalivedのインストール。今回は実績のあるipvsadm-1.24とkeepalived-1.1.13を使用する。この2つの導入については特に何の問題もなく、いつものmake;make installでインストール出来た。ちょっと特殊な点としては、keepalivedに幾つかパッチを当てた。1つはkeepalivedのヘルスチェックを強化するパッチ(keepalived-extcheck.patch)と、もう1つはkeepalivedの設定ファイルをインクルードで別ファイル化できるようにするパッチ(keepalived-include.patch)である(幾つかのサービスを扱う場合、設定ファイルを別ファイルに整理できる方がベター)。

ロードバランスするための環境としてDSRを前提とする。DSRの特徴として戻りパケットをLB通さないで済む、というメリットがあるのも見逃せないが、それよりもサービスからの切り離しを容易に行えるのが採用のポイント。DSRを利用するサーバでは、バーチャルなループバック・インターフェースを使用するので、余計なarpを投げないように設定をする必要がある。実際にラウンドロビンの設定で動きを試したところ、ループバックVIPをダウンさせてもサービスから切り離されなかった事を除いて、あとは期待通りの動作をしてくれた。ループバックVIPの動きについては、よくあるLBとは異なる動きなので気を付ける事。

最後に簡単な負荷試験をしてみた。MySQLサーバ2台(ラウンドロビン)を使って負荷をかけてみたところ、軽く秒間3万クエリーは捌いていた。差し当たって性能面に不安点はなさそうだ。しかし、LVSサーバのリソースをウォッチしていると、リクエスト量に応じてCPUのsysは変動するが、usrは微動だにしない(常にゼロ)。何を以ってLVSサーバの限界点を見極めるかにもよるが、運用上において注意が必要そうだ。総論として、シンプルな使い方をするのであればLVS構築は非常に容易なので、積極的に使用を検討すべきである(但し、運用面で幾つか注意点あり)。

こんばんは、aquaです。

既に1年使っているwordpress。プラグインや改造にも大分慣れてきたところで、また苦痛になってきた箇所を修正していく。まず本体のバージョンアップについてだが、管理画面に『バージョンアップしろ』というメッセージが多く、何となく見ててイライラする。前回は手動更新したものの、そもそも自動更新できるはずだから、設定して頻繁にキャッチアップさせたい。どうやらローカルサーバ(wordpress稼動サーバ)上にFTPサービスが必要なので予め起動しておく。FTPはローカル上にあればよいだけなので、NATなどで外側に開放する事はしない。管理画面にてツール→アップグレードで日本語版の方の『自動インストールを実行』をクリック。フォームが現れるので、以下のように埋めていく。

• ホスト名 → localhost
• ユーザー名 → USERNAME
• パスワード → PASSWORD
• 接続形式 → FTP

USERNAMEとPASSWORDはそれぞれローカルサーバでFTP可能なユーザー名とパスワードを入れる。埋め終わったら『開始』ボタンをクリックして、しばらく待つと完了。すごい楽だね、これ。最初から設定しておけばよかった･･･。その後、2.8.3が出てたので、それも『自動アップグレードを実行』で一発完了。期待通りの結果。このバージョンから、編集画面のカスタマイズが強化されている。早速、編集リスト画面の表示件数を15→20件に変更(編集画面の右上にある表示オプション)。それから、編集画面の列数を2→1に変更(投稿記事編集画面の右上にある表示オプション)。これで、大分好みの画面に変わった。

次にスパム対策。大してPVも増えていないにもかかわらず、コメントスパムはやたら増えている。akismetというプラグインで対応できるようなので、管理画面→プラグインにてakismetの『使用する』をクリック。API KEYというものが必要らしく、公式サイトでユーザー登録をして入手する模様。サインアップの画面に行き、フォームを埋めてユーザーを作成する。『ブログを作る』という選択肢もあったが、今回は『ユーザー名のみ』という選択肢にした。すると、登録したメアドにメールが届いているので、そのメール内のリンクをクリックしてユーザーを有効化する。あとは、この辺のページで『Your API Key:』と書かれた箇所でキーを確認。かそのキーを管理画面にて入力すれば完了。あとはダッシュボードのakismet統計などで状況を見るだけ。スパムはすっかり消滅するようになった。

もう幾つか修正を行っている。記事ごとのadsense広告をテンプレート内に設定。管理画面→外観→編集で『main index template(index.php)』を選択。『<?php adsense_deluxe_ads(ad); ?>』というタグを該当箇所へ挿入。見づらかったstat traqのバージョンアップはプラグインの一覧画面からクリック一発で完了。ついで(？)にwp-slimstat-exというプラグインも入れてみたが、まだ見方がよくわからない。とりあえず日本語パッチはエラーになるので当てない事。最後にログイン期間のカスタマイズ。デフォルトで14日になっているが、これを好みの期間に変更する。設定値がハードコーディングされているので、ソースをいじる必要がある。例えば100日にする場合は、${WORDPRESS}/wp-includes/pluggable.phpの637行目にある数値を以下のように編集。

$expiration = $expire = time() + apply_filters('auth_cookie_expiration', 1209600, $user_id, $remember);

↓

$expiration = $expire = time() + apply_filters('auth_cookie_expiration', 8640000, $user_id, $remember);

こんばんは、aquaです。

今回もperlのお話。初期化に100秒くらいかかる処理を最大で50回くらい繰り返す必要がある。そもそも100秒かかるのってどうなのよという議論もあるものの、差し当たっては現行仕様にて対応を検討する。幸い並行処理のコストは殆どないと考えてよいので、並列化する事で実行時間を短縮したい。並列処理と言えばスレッド、スレッドと言えばJAVAというのが自分の先入観だが、前回同様perlの手軽さに慣れつつある現状、この処理もperlで作成してみようと思う。まずはググったり、詳しい人にヒアリングしたりで情報収集。

ググった限りでは、perlのスレッドはバージョン5.8以降で大分よくなった模様。しかし、perl経験者に聞いてみるとやはりスレッドに対する不安感は払拭し切れていないようでマルチプロセスを薦められる。確かに5.8系のスレッドでも、生成に時間がかかるなどの不具合はあるらしい。今回はスレッド間でステータスの共有などをしたいので、(プロセスモデルでも出来るのかもしれないが)ともかくスレッドで作ってみて不具合が起きるようであれば再検討する事とする。という訳で、next stepとしてサンプル探しとコーティングに移る。

サンプルも思ったより幾つもあるし、スレッドを使用するに当たって特にモジュール・インストール等も必要ないようだ。以下のようなサンプルを作って実際の動きを試してみたところ、あっさりと期待通りの結果となり、またしてもperlの手軽さを実感する。

use threads;
use threads::shared;

for (1..5) {
  threads->new(\&main, $_);
}
$_->join for threads->list;

sub main {
  for (1..10) {
    sleep 1;
    print "thread => @_, count => $_ \n";
  }
}

見慣れない処理の説明だけ加えておくと、各スレッドの処理が完了するのを待つ為に『$_->join for threads->list;』という命令を入れている。この処理に今度は、スレッド間で共有するステータス管理用のハッシュを追加する。このような変数は『our %status : shared;』のように定義する。これを加えてみたサンプルが以下。

use threads;
use threads::shared;

our %status : shared;

for (1..5) {
  $status{$_} = "starting";
  threads->new(\&main, $_);
}
for my $name (sort keys %status) {
  print "thread$name status : $status{$name}\n";
}
$_->join for threads->list;
for my $name (sort keys %status) {
  print "thread$name status : $status{$name}\n";
}

sub main {
  for (1..10) {
    sleep 1;
    print "thread => @_, count => $_ \n";
  }
  $status{$_} = "done";
}

これも期待通りの動き。特にスレッドの生成に時間がかかるということもなく普通に動いてくれる。今回の処理には最低でも2回に分けて動かすなど更に幾つかの要件があるが、それらは特に言語でどうこうという話でもないので、このサンプルを元にperlのスレッドを使って実装していく事にする。