Perl

…あ、Objective-Cはやりますよ？やるけどこっちは趣味だから。

自分は今んとこサーバーとかネットワーク周りの仕事がほとんどなので、たまぁにプログラム書いてもPerlで簡単なスクリプト書いてcronで回すとかそんなもんですが、時々ちゃんとMVCとかオブジェクト指向を今のウチに習得しとかんと、年くったら吸収悪くなんぞ？という危機感はあります。

Perlで先に進むのも一つの選択肢ですが、悲しいかなOOPやWebアプリケーション開発という時流を汲んで開発（または拡張）された後続言語からすれば、Perlの実装は特殊すぎて他に使い回せねぇじゃねーか、と思うところはなくもない。こないだ少し大きめの社内用アプリをWebベースで書いてたらキレそうになった。まあ、packageの使い方がダメダメだとか能力的なものはあるけど、少なくとも素人が書いたらどうしようもなくなる言語は、そこそこの人が書いても規模が大きくなったときにほころびがより出やすいんじゃないだろうか。

もちろん、mixiなどもmod_perlで書かれてますし、キチンとコーディングルールを作った上でpackageやライブラリ化などを適切に使えるならそれでもOKなのでしょうが、それが出来ないレベルの素人（＝自分）にはしんどいです、正直。フレームワークも…なぁ。

んなワケで。会社で使ってるから?という理由で同じ言語やフレームワークを使ってもイイのですが、OOPに向いてる言語、可能だけど不向きな言語とかはよく聞きますよね。ruby on railsはものすごく賞賛されていますが、概念自体はいろんな言語に取り入れられたけど、rubyで開発された大規模なシステムって（あるんだろうけど）そういえば聞かない。実行速度やソース行数（記述）などを考えると、かなり大規模なシステムでは、むしろPython使ったりとかいうケースが多いらしい。

JAVAはよくオブジェクト指向という言葉と同時に出てきたりしますが、周囲にJAVA使いがまったくいないし、故にTomcatをわざわざ入れることもないので使いません（ちょっとだけ書いてみたことはある…触りだけね）。Webアプリ＋フレームワークで気軽に覚えられることを考えると、やはりLAMPでフレームワークをどうするか、って感じが一番ラクなのかねぇ（基本的に概念を掴むことが目的なので、資料が豊富な言語であればいいし）。

じゃ、フレームワークは？会社で使ってるヤツは、特性と目的が決まってて選んでるだけなので、世間的にはマイナーで資料もホントに少ない。Zend Frameworkとか、cakePHPとか、Symfonyは本屋でよく見ますね。そのへんはホント素人なのでPHPプロを見てみると、…。どうなんだろう。symfony、自動生成部分が多いということは、少なくとも初心者があまり考えずに書いても、ViewにActionほとんど書いてしまったり、ということは少ないんじゃないか、と思うのだが…。実行速度で劣るようだが、書きやすさや安定性を重視した結果そうなっているのなら、実務は知らんが学習にはいいんじゃなかろうか…。

以前、symfonyのデモ動画を見たら、WebアプリケーションのクセにデスクトップのIDE並みにサクサクブログとかを実装してて驚いた記憶があります。んー、ちーと入れてみたりするかなぁ。

ここ数日の間に、ITmediaでもGoogle マイマップ自動保存による情報漏洩問題が取り上げている模様。まあしかし、少し前だとグーグル八分、しばらくはストリートビュー、今度はマイマップと、何かときな臭い話の絶えないGoogleですが、正直Googleにまったく依存しないのは難しいし、Web業界だったら不可能だ。

まーだからこそ寡占ってイヤだねぇという話なのだけど、検索精度の上がってきたYahooやMSNはどうなのだろう、とちょっと使ってみたところ、やはりテキスト検索ではさっぱり使い物にならん。いや、Googleのテキスト検索精度がそれだけ高いということなのだろうけど、履歴記憶一切無しにしていても、テキスト検索でGoogleは強い（まあ画像はイマイチだけど）。

その上、先日故あってインターンシップのサンプルプログラムでGoogle Map APIのプログラムを作ったのも皮肉な話だ。まあ、GPS連携とか、同様の処理（Yahoo!地図とか）には部分的に使いまわせるトコもあると思うのでメモっておこう。あ、Perlです。

今回試したのは、携帯GPSとGoogle Static Map APIの組み合わせデモプログラム。通常のGoogle MapはJavascriptでAjaxバリバリですが、携帯ブラウザでは閲覧できないので、Static Mapを使います。と言っても、値を渡すURLと、一枚の画像として出力される点が異なるだけです。URLは以下のような形式になっていますので、値を渡してやれば画像が出力されます。

<img src=”http://maps.google.com/staticmap?center=[緯度],[経度]&zoom=[ズーム]&size=[横x縦]&maptype=mobile&markers=[緯度],[経度],redp&key=[APIキー]” />

こんな感じで…staticmap?の後に引数を渡します。各項目の詳細は以下。

• center 画像の中心の経度と緯度。カンマで区切る。
• zoom 画像の倍率。数値。大きいほど寄り、小さいほど引きになる。とりあえず15くらいでテストした。
• size 横x縦。ピクセル単位、真ん中はx（小文字エックス）で区切る。今の携帯だと240×320くらいかな。
• maptype 今回は携帯なのでmobile。roadmapというのもありますが、今回使ってないからやってません。
• markers マーカーの緯度,経度,色と文字。緯度経度はcenterと同様に指定すればOKですが、色と文字は例えば赤でAと表示したければreda、青でPと表示したければbluepと指定。どんな色があるかは調べて下さい。
  ちなみに[マーカー引数]%7C[マーカー２引数]%7C…とやることで複数のマーカーを指定できます。
• key APIキー。

とりあえず基本はこんだけ。ドコモの場合、formタグやaタグの最後に

<form action=”url” method=”GET” lcs>

とlcsをつけると位置情報をプログラムに渡せるので、取得した位置情報を先ほどのURLに渡…したいのですが、実はGoogleとドコモはどちらも世界測地系のWGS84とやらを使っているのですが、ドコモで取得した値はdms（度分秒）なのに対し、ここでAPIに渡す値はdegree（度）になっているので、途中に変換処理をかます必要があります。計算式もあるようですが、PerlならGeo::Coordinates::Converterを使うと、さまざまな表記法を相互変換してくれます。とりあえず、今回のdms→degreeであれば、

use Geo::Coordinates::Converter;
（略）
my $geo = Geo::Coordinates::Converter->new( lat => $lat, lng => $lon, datum => ‘wgs84′);
my $point = $cgeo->convert( dms => ‘degree’ );

こんな感じで緯度・経度・測地系、変換元形式・変換後形式を指定してやればOK。

このモジュールの使い方は、なんか今CPANつながらなかったので、飛んで検索してもらえばよいかと。

昨日書いたCPANモジュールのインストールがやたらコケる件ですが。

基本的にmake testでコケてることがほとんど（依存関係で足りないモノがある場合は入れればいいだけですが）。実際に個々のモジュールをmakeした後testせずにmake installしてしまうとアッサリインストール出来ることがほとんどのようです。また、cpanコマンドからinstallしてコケた場合、/作業ユーザのホームディレクトリ/.cpan/build/ 以下に、モジュールを落としてきてビルドしようとしたところまでのファイルが残っています。というワケで、個々のモジュールのディレクトリに入って、大抵は

# perl Makefile.PL
# make
# make install

してしまえば（make testを飛ばせば）、大抵ちゃんとインストールできてしまいます。依存関係にあるモジュールが足りない場合も、そのままcpanコマンドからインストールして通ればよし、コケてもそこにまたモジュールのディレクトリができるので、そのまま先にインストールしてしまうもよし。コレであっさり必要なモジュールが揃ってしまいました。

ま、どのみちCatalystなんかは膨大なモジュール群なので、相互の依存関係でループしまくるし、ログがざーっと流れちゃってどのモジュールが足りていないのかも分かりにくいし、インストールできそうではあるものの、そこまで必要性にも迫られていないのであんまりやろうという気になりません…。それよりもっとコード書いてたほうがタメになるだろうしなぁ。

Yahoo! APIで遊んでたときの参考サイト。主にPerl。
Geekなぺーじ：Yahoo!APIでプログラミング

さて、会社はPHPメインなのですが自分はPerl書き、かつプログラマでもないのですが、上司に「やっぱPerlよりPHP書けたほうが何かと便利ですかね？」と聞いたら「Perlでおｋ」だった。まあ、無理にゼロに戻らんでも得意な方面伸ばして補完してやれということでしょうね。まあ、そもそもサーバー屋なんだからPHPよりはPerl書けたほうがよっぽど役に立つんだケド。

まあでも、ちょっとしたスクリプト書きとかはするのですが、個人で大規模開発なんかするわきゃないので、一度MVCフレームワークとか使っておきたいよねー的好奇心で、自鯖にCatalystを入れようとゴリゴリやってたワケなのですが、マジで勘弁してほしい程エラーが出ます。CPANからなんか入れようとすると結構エラー吐いて失敗することが多いです。今日はなんか無限ループしてたし。（Aが足りないから入れるよ？→失敗した→Bが足りないから入れるよ？失敗した→Aが（略）

上でちょこっと書いたYahoo! APIのXMLをパースするのにXML::Simple入れようとしたらそれだけでエラーて。色々ワケがわからないエラーが多いんだぁなぁ、PerlっていうかCPANモジュール…。較べても意味ないですが、仕事でサーバー環境構築してるときにEthnaとかPEARはサクッと入るだけに、結構凹みます。

とりあえず詰まってんのにあんまり意味ないですが、なんとなくCPANモジュールが古い場合の更新ネタを。ガリガリやってる間に見つけておいたProject MultiBurstさん：古いCPANモジュール(Perlモジュール)のアップデート方法。
インスコされているモジュールの中で、現行リリースより古いものを洗い出すのがこちら。

# perl -MCPAN -e ‘CPAN::Shell->r’

で、これらをアップデートする場合はこちら。

# perl -MCPAN -e ‘CPAN::Shell->install(CPAN::Shell->r)’

凄くラクでいいんだけど案の定すんなりコケてくれやがるとこらへんがもうマジ勘弁してくださいって感じです。あーもうサーバー内のPerl周り環境グダグダになってそうだけど大丈夫だろか…。

tarとDAR、DARのよくあるエラーと対処法でも触れたバックアップの話題ですが、実際にできたアーカイブを外部のストレージなりメディアなりに保存しないと意味がありません。今回はマウントする類の話ではなく、NASやストレージサーバーに転送する話。

よく使われるのがscpやsftpだと思いますので、今回はscpを使います。scpは基本的にSSHベースなので、既にSSHでクライアントから操作している場合は、特に何の設定もなく利用することができるのが利点でしょうか。個人的にはGB単位のデータを転送してみたりしましたが、ローカルネットワークを使うならば特に遅いなどとは感じませんでしたので、余程ファイルサイズが巨大といったことがなければscpを利用するのが良いかと思います。ちなみにscpとはSecure CoPyの略。

んではまずscpをシェルで利用する場合。基本的な使い方をする分にはcpと似たようなもんなのでさほど困ることはないかと思います。

# scp report.tex username@hostname.com:filename

ハイ。scp コピーするファイル コピー先 と、cpと変わりません。これがリモートサーバからローカルへ、という場合は引数の順序が逆になるだけです。ディレクトリをコピーする場合は、scp -r としてやればOK。簡単ですね。

ではスクリプトに埋め込む場合ですが、以前も書いたように、セキュリティの観点からは、シェルスクリプトでexpectを使うのは良い方法とは言えません（ローカルからしか参照できない・しない、とかなら別ですが）。いろいろ方法はあると思いますが（パスワードなし鍵認証にするとか）、自分の場合はPerlモジュールにあるNet::SCPやNet::SCP::Expectを用います。Net::SCPは鍵認証用で対話機能がないので、ユーザー名・パスワードを利用して認証をしている場合の対話処理はNet::SCP::Expectを用います。とりあえずこれらが入っていない場合は

# perl -MCPAN -e shell　←初回起動の場合は設定に入ります。標準的な構成であれば、基本的にEnter（デフォルト）で問題ありません
↓　こうなるので
cpan> install Net::SCP　←install 必要なモジュール名 を。

…とやると、簡単にCPANからモジュールがインストールできます。（※ちなみに先ほどCentOS5.2でやったら、perl -MCPAN -e shellではなくcpanだけでも起動しました…んー？）

サーバーにあわせて必要なモジュールをどっちかまたは両方導入したら、Perlスクリプトで use Net::SCP::Expectなど利用するモジュールを書いときます。んで簡単なスクリプトとしましては

#!/usr/bin/perl

$usr = ‘root’;
$pwd = ‘xxxxxxxx’;

use Net::SCP::Expect

my $scpe =　Net::SCP::Expect->new(user=>”$usr”,password=>”$pwd”);
$scpe->scp(’192.168.0.2:/dir/filename’,”/dir/filename”);

これがリモートサーバーからローカルサーバーに落とす場合です。詳しい記述法は各モジュールの配布元などをごらんください。
ちなみにファイル単位ではなく、ディレクトリごと落としたい場合はコレだとエラーになるので、上の「my $scpe =…」の行を

my $scpe =　Net::SCP::Expect->new(user=>”$usr”,password=>”$pwd”,recursive=>’1′);

とrecursiveオプションを追加して1にします。

　PHPは一般的なハイパーテキスト処理ではさすがにPerlより格段に高速ですが、DBアクセスなんかの処理はPHPより数倍速いんだそうです（個人サイトで見たので定かではない…）。またmod_perlなんかもあるほか、次期バージョンのスクリプトエンジンでも高速化が期待されているようで。PerlからWebプログラムに入った自分としては（今もシェルの処理はPerlで書いてるし）是非ともPerlに頑張って欲しいところです。

　そんな中、PHP次期メジャーリリースでも、その高速なPerlなどで用いられるスクリプトエンジンParrotを採用することに前向きだとか（これも会社で見たのでうろ覚えだ…但しニュースサイト）。　一時期Perlはより書きやすいPHPに押されてちょっと寂しい感がしてましたが、最近のバージョンではまたPerlが盛り返してきていて良いですね。

　しかし、一方で文法が変わったり、オブジェクト指向関連で大幅に仕様変更される部分もあったりして、会社でやってるような規模のデカい開発は将来どうなるんだろうなーとは思いますが。幸いPHP4系ではないので今のところは問題ありませんが…。PHP4系のサポート打ち切り時で多くのISPがPHP5や（ついでに）MySQL5系に移行したりしましたが、あのときはどうだったんでしょうね？

　結局昔趣味でやってたPerlで昨日のSSH通信を書いてしまいました。Net::SSH::Perlモジュール。RHEL系（うちのCentOSとか）でRPM使わずに入れるとかなりの確率でプロセスがハングしちゃったり、うまくいっても計算に相当時間が掛かったりしちゃうので。今回のサーバは計算プロセスをkillしたらなんかインストールできちゃったので、やっちまった次第ですｗ

　ところで、ウチはあまり大きな会社ではないので、結構どの部署でも複数の職種を兼ねていることが多いのですが、中でもサーバー屋は何でもやってるなぁ、ホント。LANケーブルも業種上いろんな長さが必要になるので、100メートルのを買ってきて基本的に手作りです。上司はPGの仕事覚えて開発参加してますし、割といろんなスキルが要求されたりします。
　今日はサーバールームで仕事があったので、そのとき見つけた通電しないケーブルを修復して、ついでにこんなん作ってました。一応ノートPCで通電確認したので使えますが…用途はわかりませんｗ