恐竜博2005に行くなら夕方がお勧め

恐竜博2005に行ってきました。ゴールデンウィーク中ということで相当混雑するだろうなーと思っていましたが、やはり恐ろしく混んでました。時刻は13:30。博物館のチケットを買うのに10分待ちで、館内に入るまで45分待ちという状況。とりあえず10分並んでチケットは買いましたが、45分並ぶのは嫌だし、夕方になればもう少し空くかもしれないと、近くで同時開催しているベルリンの至宝展に行ってみることにしました。

こちらはそれほど混んでなくてすんなり入場できました。このベルリンの至宝展ですが、エジプト美術や古代西アジア美術、ヨーロッパ古典絵画、ヨーロッパ近代美術などいろいろな時代の芸術品を一度に見ることができるので、芸術がほとんどわからない僕でも、飽きずに楽しめました。

至宝展を一通り見た後、近くの喫茶店で休憩し、そろそろ空くかなーという頃に再度恐竜博に向かいました。時刻は16:00。さすがに少しは待つだろうなーと思いつつ会場に向かったんですが、到着してみるとさっきまであんなに並んでいた人が一人もいません。なんと全く待たずに入場できてしまいました。博物館の中もそれほど混んでなくて、一つ一つじっくり見ることができました。これから恐竜展に行こうかなーと思っている人、夕方以降に行くのがお勧めです。

Posted by mob at 23:47 | Permalink | Comments (0) | TrackBack (0)

郵便番号変換でXMLRPCサーバのベンチ

XML-RPCを使って、郵便番号から住所引っ張ってくるサービスを作る際に、perlとPHPどちらの方がパフォーマンスがでるのか気になったので、ちょっと実験してみました。

perlの方はnaoyaさんのApache::XMLRPC::Lite を使った mod_perl ハンドラによる XML-RPC サーバのエントリを参考にApache::XMLRPC::LiteとClass::DBIを使って実装し、PHPの方はXMLRPCの実装にXML-RPC for PHPにあるライブラリを使い、DBとの連携は組み込みのmysql_connectとかを使って実装してみました。ちなみにPHPはまともに動くコードを初めて書きましたが、意外と書けるものですねｗ

ベンチマークにはabを使い、同時接続数が1,5,10,20の場合をそれぞれ測定してみました。

ab -n 100 -c 1 -T text/xml -p post.txt -w  http://horiuchi.vcube.net/zipconv/xmlrpc > result.html

以下結果です。

• Apache::XMLRPC::Lite
• Apache::XMLRPC::Lite（レスポンスを強制的にbase64にした場合）
• PHP
• CGI ( perl ）

レスポンスを強制的にbase64にした場合を測定したのはSOAP::Liteのドキュメントにそうするとパフォーマンスをあがるというようなことが書かれていたので試してみました。

ですが、結果としてはそれほどパフォーマンスはあがってません。逆に同時アクセス数を大きくするとパフォーマンスが落ちてしまいました。

また、PerlとPHPではそれほどパフォーマンスに違いがないようです。

PHPだと劇的に早いという結果になったらPHPにしようかとも思ったのですが、結局どちらにしても違いはそれほどなさそうなので、得意のＰｅｒｌで行くことにしました。

Posted by horiuchi at 10:42 | Permalink | Comments (2) | TrackBack (0)

Lightweight Language Day and Night

LLDN - LLDN 開催のお知らせ

軽量言語に関するイベントLLDNが今年も開催されるそうです。今年はさらにパワーアップして、昼の部と夜の部２部構成だそうです。今年も参加予定。楽しみ。

Posted by horiuchi at 09:21 | Permalink | Comments (0) | TrackBack (0)

702MOと702sMOひどいな

久しぶりに携帯の個体情報を利用するシステムを作るため、ボーダフォンのサイトを調べていて唖然。

3G携帯はユーザエージェントがえらいことになっているとは聞いていましたが、702MOと702sMOは特にひどいですね。。

ユーザーエージェントがMOT-で始まるのも相当ひどいけど、ボーダフォンをみると個体情報も送らないっぽい。。

そりゃあ、HTTP::MobileAgent::Vodafoneにこんなコメントもつきますよね。

#for 3gc orz

Posted by horiuchi at 23:58 | Permalink | Comments (0) | TrackBack (0)

AdobeがMacromediaを買収

ITmediaニュース：AdobeがMacromediaを34億ドルで買収より

かなり驚き。

Posted by horiuchi at 17:58 | Permalink | Comments (0) | TrackBack (0)

VMware v5.0リリース

窓の杜 - 【NEWS】複数の“スナップショット”が保存可能になった「VMware」v5.0 正式版が公開

より

VMwareのv5.0がリリースされたようです。スナップショットを複数保存できるようになったほか、仮想マシンの画面をAVI形式で録画する機能なんかもついたみたいです。

Posted by horiuchi at 01:03 | Permalink | Comments (0) | TrackBack (0)

秀丸Ver5の正規表現がよりPerl風に

hail2u.net - Weblog - 秀丸エディタ Ver5.00βより

秀丸Ver5の正規表現はperlのものにより近づいたらしい。

Posted by horiuchi at 05:33 | Permalink | Comments (0) | TrackBack (0)

Poderosa

タブ式 GUI・SSH2 をサポートしているオープンソースの Windows 用高機能ターミナルエミュレータ Poderosa: Epic->yoshimaxより

Poderosa(ポデローサ) は、タブ式 GUI・SSH2 をサポートしているオープンソースの Windows 用高機能ターミナルエミュレータです。

いいかも。

Posted by horiuchi at 05:26 | Permalink | Comments (0) | TrackBack (0)

Amazon Keyword Search クエリの文字コードを指定可能に

サイトの頭についているAmazon Keyword Searchですが、日本語を入力して検索すると文字化けて正しく検索できなかったのを修正しました。

そもそもAmazon Keyword Searchは文字コードについては何にも処理しておらず、飛んでくるクエリはEUCであるという前提で作っていたので、このブログのように文字コードがUTF8だと文字化けるんですよね。なのでcというパラメータでクエリの文字コードを指定できるようにし、対応しました。

Posted by horiuchi at 05:13 | Permalink | Comments (1) | TrackBack (0)

Acme::MorningMusume

antipop2.0 - Acme::MorningMusume リリース

より

Acmeというカテゴリ、いままで知りませんでした。CPANておもしろい。

Posted by horiuchi at 10:59 | Permalink | Comments (0) | TrackBack (0)

Template::Plugin::TagRescue0.04が特定条件で文字化け

あるサーバに移すとTempalte::Plugin::TagRescueを使ってタグをエスケープした部分の文字が化けるという現象が発生したため、原因を調査してみました。

サーバにインストールされていたのはその時点で最新のTemplate::Plugin::TagRescue0.04。

ソースをのぞくとタグのエスケープにApache::Util::escape_htmlもしくは、HTML::Entities::encode_entitiesが利用されていて、Apache::Utilが利用できない環境ではHTML::Entitiesが使われるという設計になっていました。

問題のサーバを調べてみるとApache::Utilが利用できない環境で、エスケープにはHTML：：Entitiesが使われていて、どうやらそのHTML::Entitiesでエスケープを行うと文字化けが発生するようです。

そこでHTML::Entitiesのドキュメントを眺めると、以下のような記述が。

encode_entities( $string, $unsafe_chars ) This routine replaces unsafe characters in $string with their entity representation. A second argument can be given to specify which characters to consider unsafe (i.e., which to escape). The default set of characters to encode are control chars, high-bit chars, and the <, &, >, and " characters. But this, for example, would encode just the <, &, >, and " characters:

encode_entitiesの2つめの引数に明示的にエスケープを行う文字を指定しないと、マルチバイト文字もエンコードの対象になるようで、これが原因で文字化けしていたようです。試しに第２引数をわたしてやると、文字化けが解消されました。

今回の件は作者のtanimotoさんに報告し、パッチを送ったのですが、送った数時間後には修正しCPANにアップしてくださいました。仕事がはやい！

しかも僕のパッチからさらに改良して、実行速度を向上させるあたり、さすがだなーと思いました。

Posted by horiuchi at 23:20 | Permalink | Comments (0) | TrackBack (1)

GmailのPOP、SMTPはSSL対応

GmailのPOP機能を試してみたんですが、SSLで受信できるんですね。さらにSMTPもTLSに対応してるみたい。下手なプロバイダのサービスより全然セキュアですね。。恐るべしGoogle。

Posted by horiuchi at 20:42 | Permalink | Comments (0) | TrackBack (0)