パッケージの概要を説明するファイルである。 一般的にパッケージを入手した人はまず README ファイルを読む。
を書くよう指示している。
複製条件の部分は一般的には他のライセンス等についての言及を書く事になるであろう。
Software Release Practice HOWTO (Eric S. Raymond, V2.0) では README または READ.ME としている。
HOWTO で、書いておくべき項目としてあげているものの中で、GNU コーディング規約にないものとして
等がある。
最近 StealthSwitch というUSB接続のフットスイッチが(ちょっぴり)話題になっている。 「ボスが来た」用。
Debian に Boss is coming がないかと探したらかわりに cappuccino というのを見つけた。
Run this software on your computer when you are not motivated to work, and enjoy doing something different. — README より
こちらは、ボスが来た時用ではなくてあらかじめ動かしておくタイプのソフトウェア。 どんな画面になるかは……スクリーンショットを貼ったら、会社で効果が無くなるのでやめておこう。
私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと
perl Makefile.PL make manifest make make test make dist
で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、
tar zxvf <pacakge>-<versionno>.tar.gz cd <pacakge>-<versionno> perl Makefile.PL make make test make install
という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。
逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。
ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。
本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、
あたりを考慮しなければならない時は面倒くさくなってくる。
自動化としては
あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。
ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。
ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。
Module::Build も Perl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。
use Module::Build; my $class = Module::Build ->subclass(class => 'NonmoduleBuilder', code => q{ # Don't make blib sub ACTION_code {}; # Don't make blib sub ACTION_docs {}; # Don't make META.yml sub ACTION_distmeta { # no warning on ACTION_distdir $_[0]->{metafile} = 'MANIFEST'; }; # Don't add MEATA.yml to MANIFEST sub ACTION_manifest { $_[0]->{metafile} = 'MANIFEST', $_[0]->SUPER::ACTION_manifest(@_); }; }); # Set your archive name and version. $class->new(dist_name => 'mypackage', dist_version => '1.0.2', )->create_build_script;
カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。
上記のようなファイルを Build.PL という名前で作っておけば
perl Build.PL ./Build manifest ./Build ./Build test ./Build dist
等として、アーカイブ作成が容易にできるようになる。
しばらくこの方法でいろいろ試してみることにしてみよう。
iTunes に プラグイン iScrobbler For Windows 1.1.0 をインストールして、曲を再生してみたところ Last.fm へ曲情報をうまく送信できた。 アカウントの方は特に問題ないらしい。
やはり amaroK 側の問題か。
何度か amaroK の svn 版をコンパイルして試してみるうちに、そういえば configure した際にいくつか optional なライブラリが無くてそれらの機能が外されている旨の表示が出ていたことを思い出した。 apt-get build-dep amarok では全部入らないらしい。
README をみて必要なライブラリを確認。 libmp4v2 あたりが怪しい。ということで libmp4-dev パッケージをインストール。 また前回インストールされていなくて configure に --without-akode していたので aKode 関係のライブラリもあわせていれておく。
で再インストール。
で再生してみたら、あっさりうまくいった。
よし。
1週間前にEmacs 22 に乗り換えたのだが、これだと昨日から使いはじめた howm に色がつかない。
あまりにも寂しい。
というか色分けされないと便利さ半減。 なのであっさり Emacs 21 に戻すことにした。 vc-svn.el の方は、Subversion Debian パッケージの README.Debian にある通り、Emacs 21 用に
svn export -r9195 \ http://svn.collab.net/repos/svn/trunk/contrib/client-side/vc-svn.el
でとってきてローカルに置き動くようにしておく。
(setq vc-handled-backends (append vc-handled-backends (list 'SVN)))
も忘れずに。
ポータブルアプリケーション詰め込み。
自分の場合エディタと Perl があれば随分できることが増えるので、何とか Perl を入れておきたい。 しかし定番の Windows 用 ActivePerl はセットアップが必要であり、持ち歩きには向かない。
何かいい Perl ディストリビューションがないかなと探してみたところ、インストール不要の Apache ディストリビューションが目についた。 そういえばこれらには Perl が含まれていてインストール不要で使えるものがあるらしいので、それらが使えるかもしれない。
標準の XAMPP では Perl インタプリタしか入っていなかった。 さすがにこれでは使い物にならない。
XAMPP で実用的な Perl 環境を用意するにはこちら。ActivePerl 5.8.8.817 上に Web アプリケーションに必要そうな パッケージが用意されている。 そのかわり 200MB (!) 近い容量が必要。 でかすぎ。
README には setup_xampp.bat に実行の指示がある。
ActivePerl 5.8.7.815 が含まれている。 Perl インタプリタと、いくつかのパッケージが含まれている。 パッケージは結構少なめにおさえてあるので、容量はかなり少ない。 しかし
perl -MConfig -e "print Config::myconfig()"
が動かないなどそのまま使えるわけではなさそうだ。
試した2つとも結局は ActivePerl を使っているようである。 ActivePerl の部分のライセンスはどうなっているのだろう?
もしかしたら ActivePerl の AS package を展開して、不要なファイルを削除すれば (インストーラで設定されるリポジトリなどの情報を使う部分は駄目にしろ)、ある程度動くのかな。
それと Installer.bat の中で、一部ファイル(.bat、Config.pm、Config_heavy.pl、perllocal.pod、.packlist、config.h) のリロケーションをしているので、このあたりがポイントになりそう。
要確認。
自分の Tweet は API で取ってきておおむね nDiki の記事にまとめてあるのですが、使い始めの頃はそんなことをしていなかったので手元にデータとして取ってありませんでした。公式機能で全ツイート履歴ダウンロードができるのは知っていましたがそのうちと思いつつずっとやり忘れていたので、ようやく腰を上げて全ツイート履歴リクエストを設定からしてみたところ、ほどなくして準備完了のメールが届きました。
ダウンロードした ZIP ファイルの中をみると、予想していた通り人間用に HTML ファイルがありました。そしてそれ以外に CSV 形式ファイル・JSON 形式ファイルが含まれていてきちんと利用しやすい形になっていて良くできているなと感心してしまいました。良いですね。
きちんと README.txt をみてみたら HTML ファイル (index.html) は JSON 形式ファイルを読んで表示するページになってました。なるほど。API のレスポンス仕様と同じ JSON 形式をエクスポートデータにしているのですね。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。