nDiki : 2006年02月中旬

2006年2月11日 (土)

野良パッケージと依存 Perl モジュールインストールセット をCPAN::Site

WiKickerオフラインで簡単にインストールできるようにしたい。 WiKicker 自体は

 perl Makefile.PL
 make
 make test
 make install

で簡単にインストールできるのだが、事前に CPAN にある依存 Perl モジュール(とそれらが依存している Perl モジュールら)をインストールしておかなければならない。

オンライン環境では CPAN.pm を使って芋蔓式にインストールできる。 WiKicker は次回のリリースから Module::Install を採用するので、perl Makefile.PL 時にそれらを行うことができるようにもなる。

しかしオフライン環境になると、話は変わってくる。

普通にやろうとするとあらかじめ依存関係を全部洗い出して事前にダウンロードしておき、依存関係の順番を考えながらインストールしていかなければならない。

これがかなり面倒。しかも各モジュールのバージョンアップにともない、その時その 時で変化する可能性があるので、適宜確認しなければならない。

でれば CPAN.pm の力を借りたい。

CPAN.pm はインストール時に $CPAN::Config->{keep_source_where} (通常 ~/.cpan/sources) に溜め込むので、これを CD-ROM 等に書き込んでオフラインインストールで使用することができる (cf. perldoc CPAN)。

だいたいはこれでうまくいくのだが問題もあって、この方法だと(WiKicker などの)野良パッケージを、うまく一緒にすることができない。

野良パッケージを扱うには CPAN::Site、あるいは CPAN::Mini::Inject あたりを使えば良さそうだ。

今回はまず、CPAN::Site での手順を調べてみる。

~/perl-5.8.8 以下にクリーンな Perl 5.8.8インストールしてインストールセットを作成していく。

CPAN::Siteインストールする (オンライン)

 rm -rf ~/.cpan
 ~/perl-5.8.8/bin/perl -MCPAN -e shell
 cpan> install LWP
 cpan> install CPAN::Site
 cpan> exit

これで CPAN::Site が使えるようになるとともに、CPAN::Site と LWP および依存モジュールのソースアーカイブが ~/.cpan/sources 以下にたまる。

WiKickerインストール中に libwww-perl を途中で入れると CPAN.pm が使ってこともあってかうまくいかないので、先に一緒に入れてしまう。

インストールしたい野良パッケージ用のローカル CPAN サーバを作成する

野良パッケージら (今回は WiKicker のみ)を含んだ ローカル pseudo CPAN サーバを作成する。

 mkdir -p ~/public_html/CPAN/authors/id/N/NA/NANEY
 cp WiKicker-0.xx.tar.gz ~/public_html/CPAN/authors/id/N/NA/NANEY
 ~/perl-5.8.8/bin/mkpackages ~/public_html/CPAN

CPAN::Site に含まれている mkpackages を使うことで、CPAN::Site が参照することのできるインデックスファイルが作成される。

WiKicker と依存するモジュールをインストールする (オンライン)

次に ローカル CPAN サーバと、CPAN (ミラー) からパッケージを自動ダウンロードしてインストールする。ここでは CPAN.pm のかわりに CPAN::Site を使用する。

 ~/perl-5.8.8/bin/perl -MCPAN::Site -e shell
 cpan> o conf urllist unshift http://localhost/~myname/CPAN
 cpan> reload index
 cpan> install WiKicker
 cpan> exit

ここでローカル CPAN サーバを file:/// 等で指定すると、そこから読みとったファイルは ~/.cpan/sources/ 以下にコピーされないので一箇所にまとめることができないので注意 (かなりはまった)。

これが終わると、WiKicker とそれに必要なファイルが ~/.cpan/sources にたまる。

これを適宜アーカイブして保存する。

オフラインインストールする

別の環境で例えば /usr/local/perl-5.8.8 にインストールされた PerlWiKickerオフラインインストールするとする。

先の工程で作成したファイルセットが /tmp/CPAN においてあるものとする。

 /usr/local/perl-5.8.8/bin/perl -MCPAN -e shell
 # 初期化でオフラインのため CPAN ミラーの選択ができずに URL の入力を
 # 求められたところで file:///tmp/CPAN を指定
 cpan> install LWP
 cpan> install CPAN::Site
 cpan> exit

まずは以上で CPAN::Site が入るで、CPAN::Site で shell を起動しなおす。

 /usr/local/perl-5.8.8/bin/perl -MCPAN::Site -e shell
 cpan> install WiKicker
 cpan> exit

これで /tmp/CPAN から芋蔓式に WiKickerインストールされる。

ポイント

Debian のパッケージリポジトリなどとは違って、CPAN は基本的に「一つのリポジトリおよびそのミラー」という概念しかないようである。 したがってモジュールのインデックスファイルも1組しかなく、複数のサイトから異なるモジュールセットを配布するということができるようになっていない。

これに対し、自前パッケージ群用にも1セットインデックスファイルを作って扱えるようにしようというのが CPAN::Site である。

これを用いると「もう一つのリポジトリ」を扱えるようになるが、逆にいうと利用する場合は CPAN::Siteインストールしなければならないということでもある。

スポンサード リンク
[ 2月11日全て ]

2006年2月12日 (日)

野良パッケージと依存 Perl モジュールインストールセット を CPAN::Mini::Inject

前回は CPAN::Site を用いたオフラインインストールセットを作成した。

今回は空の CPANミラーを作り、そこに野良パッケージを突っ込んで使用する形でインストールセットを作成してみる。

~/perl-5.8.8 以下にクリーンな Perl 5.8.8インストールしてインストールセットを作成していく。

CPAN::Mini::Injectインストールする (オンライン)

 perl -MCPAN -e shell
 cpan> install CPAN::Mini::Inject
 cpan> exit

CPAN::Mini::Inject は、インストールセットには必要ない。 ~/perl-5.8.8 にはインストールせずに、普段使っているほうにインストールしておく。

インストールしたい野良パッケージ用のローカル CPAN サーバを作成する (オンライン)

以下スクリプト例(エラー処理などは省略)

 #!/usr/bin/perl -w
 use strict;
 use File::Path;
 use CPAN::Mini;
 use CPAN::Mini::Inject;
 my $remote     = 'ftp://ftp.dti.ad.jp/pub/lang/CPAN/';
 my $local      = '/home/myname/public_html/CPAN';
 my $repository = '/home/myname/repository';
 mkpath([$local, $repository], 1, 0755);
 # module_filters で全てのモジュールを対象外にして、空の CPAN ミラーを作る
 CPAN::Mini->update_mirror(remote => $remote,
                           local  => $local,
                           diremode => 0755,
                           trace => 1,
                           module_filters => [ qr/./ ]);
 my $injector = CPAN::Mini::Inject->new;
 $injector->{config}{remote} = $remote;
 $injector->{config}{local} = $local;
 $injector->{config}{repository} = $repository;
 $injector->{config}{diremode} = 0755;
 # CPAN::Mini::Inject リポジトリに追加したあと、
 # CPAN ミラーへ 注入
 $injector->add(repository => $repository,
               module => 'WiKicker',
               authorid => 'NANEY',
               version => '0.xx',
               file => 'WiKicker-0.xx.tar.gz')
  ->inject;

これで、~/public_html/CPAN に野良パッケージの追加された CPAN ミラーが作成される。

WiKicker と依存するモジュールをインストールする (オンライン)

 rm -rf ~/.cpan
 ~/perl-5.8.8/bin/perl -MCPAN -e shell
 cpan> o conf urllist pop
 cpan> o conf urllist push http://http://localhost/CPAN
 cpan> reload index
 cpan> o conf urllist push ftp://ftp.dti.ad.jp/pub/lang/CPAN/
 cpan> install WiKicker
 cpan> exit

ここでローカル CPAN サーバを file:/// 等で指定すると、そこから読みとったファイルは ~/.cpan/sources/ 以下にコピーされないので一箇所にまとめることができないので注意。

またCPAN ではモジュールインデックスファイルは1組しか持てないようで、初期設定のままだと野良パッケージを含む CPAN ミラーのインデックスファイルが使われない。 そのため一旦 urllist を空にした後、 自分の CPAN ミラーを指定しインデックスファイルをロードする。 その後にソースパッケージを取得するセカンダリとして通常の CPAN (ミラー)を指定するようにしている。

これが終わると、WiKicker とそれに必要なファイルが ~/.cpan/sources にたまる。

これを適宜アーカイブして保存する。

オフラインインストールする

別の環境で例えば /usr/local/perl-5.8.8 にインストールされた PerlWiKickerオフラインインストールするとする。

先の工程で作成したファイルセットが /tmp/CPAN においてあるものとする。

 /usr/local/perl-5.8.8/bin/perl -MCPAN -e shell
 # 初期化でオフラインのため CPAN ミラーの選択ができずに URL の入力を
 # 求められたところで file:///tmp/CPAN を指定
 cpan> install WiKicker
 cpan> exit

これで /tmp/CPAN から芋蔓式に WiKickerインストールされる。

ポイント

CPAN::Site を利用して構築した場合は、インストール時にも CPAN::Site が必要だが、こちらはインストールセットの利用には CPAN.pm だけで良いというのが利点。

今回は CPAN::Mini で空の CPAN ミラーを作成し野良パッケージを追加した。

ここで最初から CPAN の最新パッケージの全ミラーCPAN::Mini で作成し、これに野良パッケージを追加してインストールセットを作ってしまうという方法もある。 この場合は後で必要に応じてミラーからパッケージを入れられるというメリットがあるかわりに、ミラー作成のコストがかかるというデメリットがある。

片方からしか音の出ない DVD コンポ

rimage:http://www.naney.org/img/2004/X/X2004-01-31-0001.jpg

ここ最近 DVD コンポ (FR-SX7DV(D)) の左側のスピーカーから音がが聞こえない。 今日部屋の掃除をした際に、合わせて接続や設定の確認をしてみた。

左右のスピーカーやケーブルを入れかえて試した結果スピーカー・ケーブルは問題ないようで、どうも信号自体が出てないようだ。 イヤホン端子からは両方音が出ている。

修理に出さなければならないか。持ち込むには重い。ちょっと手間だな。


[ 家電 ]

[ 2月12日全て ]

2006年2月13日 (月)

WiKicker 0.29 リリース - ビルドまわりの改良など

2005年10月6日以来、約2カ月ぶりのリリース。

Makefile.PLModule::Install ベースにして、依存 Perl モジュールインストールを楽にした。 Wiki 機能の方は大きな変更なし。DiKicker には はてなブックマーク上の検索結果を表示する機能を追加。

また今回は、実験的な実装でほとんど使われていないと思われるモジュールについて、メンテナンスの問題から削除を行った。 大きなところでは、GnuPG による電子署名によりアップロード利用者をチェックする画像アップロードページ/機能を削除。

利用している方がいれば削除した機能は復活させようと思うが、多分いないかなと。

アップロード機能は、今後のユーザ管理機能の追加時にあらためて追加する予定。

[ 2月13日全て ]

2006年2月14日 (火)

バレンタインデー

本命チョコをいただく。

ついに花粉きたか?

何か顔が粉粉する感じがする。 粉っぽいというよりも、肌が過敏になっている感じの。

鼻水はしばらく前から出はじめてきていたが、そろそろ体感レベルまで飛散量が増えてきたようだ。


[ 花粉症 ]

[ 2月14日全て ]

2006年2月15日 (水)

ドキュメンテーション大全

開発の現場 Vol.003 効率UP&スキルUP ドキュメンテーション大全

プロジェクトの後半で納品用ドキュメントの整備を始めるのだが、その時はたいがいもう切羽詰りはじめていて構成やら体裁やらマネジメントやらを工夫する余力が無かったりする。 ついつい(次回は改良しようと思っていつも思っている)前回のプロジェクトの手法を踏襲してしまいがちだ。 ともすれば劣化コピーになりかねない。

やはり、忙しくても日頃からの改善は重要である。

最近はアジェンダ議事録開発メモなどを、積極的に WikiSubversion で共有するようにし、その点では以前より改善してきている。

今後はさらに、出荷ドキュメントのレビュープロセスなどを確立し品質を高めていきたいところである。 現状でもチームメンバでのピアデスクチェックやパスアランドを非形式的に行っているのだが、「チェックの程度」やその後の「修正」および「修正の確認」については、まだなんとなくやったかなという具合。この辺りを工夫したい。

先月発売されていて気になっていた「開発現場 Vol.003」に、何かヒントがあるかなと思って買ってみた。

パラパラと見た感じではテクニカルライティングの話はあまりなく、主にソフトウェア開発における中間成果物としてのドキュメントや開発者間ドキュメントをどうとりまとめていくかという話が中心のよう。 Wiki による開発資料のライトな共有など、うちのチームでも進めている話など。

「(最初から)完全なドキュメントを書こうとしない」というのはもっとも。 状況はほとんどの場合変わるし、最初の段階では未確定の部分も多い。 だからといって、いつまでたっても手元で温めていてもしょうがない。

技術的な話では PerlPod を活用しようという話。 Perl 以外の言語のコメント中に Pod 形式でドキュメントを書こうという提案や、Apache で動的に Pod ドキュメントを整形しようという話とか。

テキストフォーマットとしての Pod は =over / =item / =back によるリスト表現など、最近のフォーマットに比べてすごく読み易いわけではないが、たしかに他の言語のコメントに埋め込んでおいて処理するのは、標準の Pod 関連のモジュールでできるな。

自分も Pod でドキュメントを書くけれど、(Perl 以外は) 個人的には reStructuredText にしたいと考えている。 ただ Pod みたいに他のテキストの一部に埋め込んでその部分のみ処理する記法およびツールがが標準の reStructuredText / Docutils には見当らない。 実はどっかにあるのだろうか。


[ 読書ノート ]

マスク着用開始

去年・一昨年より約1週間遅れで。 一応早めに超立体マスク買いだめしておくか。

[ 2月15日全て ]

2006年2月16日 (木)

社内 mixi 登録率とマイミクシィ

最近オフィスの昼休みに、また mixi が話題になることが多くなった。 本社の人が1人新たに登録したのがきっかけ。 第2次ブーム到来。

知る範囲での社内での mixi 登録率は約50%。 多いとみるか、少ないとみるか。 自分の周辺だけに限れば(当然ではあるが)登録率が高く、昼休みにふと見るとオレンジ色のディスプレイを見ることもしばしば。

しかしそれぞれの人のページを覗いてみると、あまりお互いにマイミクシィになっていない。

  • 遠慮しあっている
  • マイミクシィの機能・意味合いがよくわからない
  • 面倒くさい
  • そもそも mixi をほとんど使っていない

さてどれかな。

ま、マイミクシィになることをメリットと感じるかどうかはその人によっても違うと思うが。 自分にとっては、なにはともあれマイミクシィ日記へのアンテナが張られるのが便利。

[ 2月16日全て ]

2006年2月17日 (金)

SVN::Webインストール失敗

社内サーバ上の Subversion リポジトリを気軽に閲覧できるように、以前から試そうと思っていた SVN::Webインストールしてみる。

しかし SubversionPerl バインディングである SVN::Core は、Subversion パッケージに同梱されていて独立していないのか。 SubversionRed Hat Linux 8.0 へ RPM パッケージで入れているのだが、SVN::Web の方は /usr/local/perl-5.8.8 以下にインストールした Perl 5.8.8 上へ入れようと思っていたので、はたと困る。

 --with-perl5=/usr/local/perl-5.8.8/bin/perl

で configure して、Perl モジュールだけインストールしてみたけれどうまく動かず。

素直に Red Hat Linux 8.0 に標準で入っている Perl 5.8.0 に入れるかなぁ。

会長現る

昼休みに会長がぶらりと立ち寄った。 入社以来、お会いするのは初めてである。

その後、南極だか北極だかの話をして帰っていったようだ。

[ 2月17日全て ]

2006年2月18日 (土)

11:00 床屋

wish-水野美紀写真集

いつものアドバンストヘアーナカタニで。

2005年12月10日以来2カ月ぶり。

去年からきている女性スタッフは水野美紀似の声をしている。

Mozex を使って Firefox 1.5.0.1 の textarea の内容を Emacs で編集する

uimuim-skkFirefoxキーバインディングをきちんと設定していないせいか、どうも textarea での日本語編集にストレスを感じる。 Wiki 等で textarea での編集作業も少なくないので、Mozex を使って Emacs で編集できるように設定しておくことにした。

より降旗氏が公開されている Firefox 1.5以降用 mozex 1.07.1 日本語 version (1.5.0.1 インストール対応)を Firefoxインストール

そういえば今まで emacsclient も使ったことがなかったな。Emacs 立ち上げっぱなしのくせに。まずは起動している Emacs 上で M-x server-start (.emacs で (server-start))しておく。

Mozex の設定で

 Directory for temporary files: /tmp
 Textareas: /usr/bin/emacsclient %t

を設定。自分の環境だと Commands は絶対パスでないとうまく呼べないようだ。

これで textarea 上で右クリックし、[mozex] -> [Edit Textarea] で開いている Emacs 上に Textarea の内容が新しいバッファで開く。 編集して保存して C-x # し、Web ブラウザ側に戻ると反映される。

便利便利。

ところで Emacs server と gnuserv とどっちがいいのかな? 特に設定なしでどちらも使える。 何も設定していない状態だと gnuserv の方は新しい frame が開いて好みじゃないので、とりあえずは Emacs server を使うことにする。

ついでに EDITOR 環境変数も emacsclient に直しておこう。 これで CVSSubversion のコミット時に新しい Emacs を起動しなくてよくなる。

とっとと設定しておけば良かった。

Perl CGI プログラムのテストには WWW::Mechanize::CGI

CGI プログラムを書いていて、いつも困るのがリグレッションテスト

パッケージのビルド時に実行するテストスーツ (make check / make test 用テストプログラム群) に含めておきたいが、さすがにその場で Web サーバの下へセットアップするわけにもいかない。 ミニ Web サーバを同梱してテストスーツ内で起動する方法はちょっとおおがかかりだし、ポート番号の選択やらサーバの停止の問題もあって、かなり面倒。

結局、テストスーツの中で環境変数や標準入力など CGI リクエスト環境をセットアップして、CGI プログラムを実行するという王道(?)かつ泥臭いテストを書くことになったりする。

何かいいものはないかと探していたところ、WWW::Mechanize::CGI というものをみつけた。

LWP::UserAgent を継承した WWW::Mechanize モジュールは Web ブラウジングを容易にする有名どころのモジュールである。

WWW::Mechanize::CGI モジュールはさらにこれを拡張したモジュールで、HTTP リクエストを、仮想的に CGI プログラムやサブルーチンへの呼出しにしてくれる。 これを用いるとあたかも Web サーバ上の CGI プログラムにリクエストしレスポンスを受けとっているかのように、テストプログラムを書くことができる。

素晴しい。

さっそく WiKicker のテストを書き換えてみた:

 use Test::More tests => 2;
 use WiKicker::WikICGI::Controller;
 use WWW::Mechanize::CGI;
 use File::Temp qw(tempdir);
 use File::Spec;
 my $www_dir = tempdir(CLEANUP => 1);
 my $mech = WWW::Mechanize::CGI->new;
 $mech->cgi(sub {
              $ENV{PATH_INFO} = '' if $ENV{PATH_INFO} eq '/';
              WiKicker::WikiCGI::Controller->new->run});
 $mech->env($mech->env,
            SCRIPT_FILENAME => File::Spec
                                 ->catfile($www_dir . '/wiki'),
            SCRIPT_NAME => '/wiki');
 my $response = $mech->get('http://localhost/wiki');
 ok($response->is_success);
 like($response->content,
      qr|<title>WikiForum\[WiKicker\]: FrontPage</title>|);

WWW::Mechanize::CGI オブジェクトを new した後、cgi メソッドで CGI サブルーチンを指定するか、cgi_application メソッドで外部 CGI プログラムを指定する。 ここでは直接、CGI サブルーチン (WiKicker::WikiCGI::Controller->new->run を実行)を指定した。

なおここで WWW::Mechanize::CGI が使っている HTTP::Request::AsCGI 0.5 における PATH_INFO の扱いが Apache などとは違って、空でも必ず '/' が入るようになっている。 これだと WiKicker では困るので、サブルーチンのところで修正している。

後は必要ならば WWW::Mechanize::CGI::env で、追加の環境変数設定を行っておく。

セットアップが済めば通常の WWW::Mechanize と同様に get 等でリクエストを行いレスポンスを受けとることができるようになる。

いい。しばらく試してみて不具合がなさそうなら、定番のテストスタイルにしたい。

ちなみに Test::Harness 用の Test::WWW::Mechanize にあわせて、Test::WWW::Mechanize::CGI というものもある。 これらを用いるとさらにテストを書くのが楽になるが、依存するモジュールも多いので無理に使わないほうがいいかもしれない。

からのバレンタインデーのチョコレートを貰いにいく

は律儀にも毎年バレンタインデーのチョコレートを用意してくれる。 ただし決して渡しにはこないので、味が悪くなる前に受け取りに出向く必要があるのだ。

ということで、今日実家に受け取りにいく。

の失せ物騒動でちょっとごたごたしたものの、無事いただいて帰ってくる。

[ 2月18日全て ]

2006年2月19日 (日)

ヤマザキ春のパンまつりシール収集スタート

出遅れたが、今年もシールの収集を開始。

[ 2月19日全て ]

2006年2月20日 (月)

ノート PC に触れる前に静電気除去グッズで放電しておく

naney:102323155

パチッ。静電気体質なのかそれとも着ているもののせいか、は頻繁に静電気のショックを受けるらしい。 聞くところによると、コピー機を使うときにはかなりの確率でビリッっとくるとか。

そんな話の途中、ヨドバシカメラ静電気除去グッズを見かけたのを思い出した。 それほど高くもないので、どんなものかと購入してみた(自分の分も)。

  • ぺんてる ビー・シェイプ

さっそく家に帰って試してみる。 手に持って先端のタッチゴムをホーム・エレクターのポールに触れてみると、液晶に顔が浮かびあがる。 お、まだバチッっとくるほどではないけれど帯電していたということか? 何かリセットした感じで気分がいい。

放電は別にこういったグッズでなくてもできるだろうが、見た目にフィードバックされるという楽しさがあって良い。

自分の場合、離席先からふらふらっと戻ってきて ThinkPad のフタを触れた時によくバチッとくる。 痛いとことより、ノート PC が大丈夫だったかの方がいつも心配だ。 そういう時に先に放電しておく方が良いのだろう。

そういえば大学時代、学科の計算機室では助手の人がコンピュータのケースを開く時には静電気防止リストバンドできちんとアースしていたなぁ。 最近は PC を開ける時もまったく意識してなかったよ。反省。

「しかし」グッズを身につけておいたりとかあるいは手元に置いたりしておいたりすることとか、こまめにどっかにタッチすることとかというコストは、リスク回避としては大きめ。 飽きたら使わなくなりそう。

普段どう身につけておくかがポイントになりそうだ。 車のキーを持っているわけではないし、携帯電話のヘビーユーザでもないし、IDカードを首からぶらさげているわけでもないし、どうしよう。

何もせずに持っているだけで空中放電してくれるものの方がいいかなと思うのだが、そういうグッズは効果があるのだろうか。

[ 2月20日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.049491s / load averages: 0.26, 0.33, 0.38
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker