ExtUtils::MakeMakerでMETA.ymlにmeta情報を追加する方法

repository情報をCPANに載せたい

githubで管理しているモジュールをCPANに上げたら、(誰かがpull requestを送ってくれるかもしれないので)repository情報をCPANに載せたいところです。

Module::Installを使用している場合は、 auto_set_repositoryを使うと勝手にセットしてくれますが、ExtUtils::MakeMakerでの書き方を知らなかったので調べました。

META_MERGEを使う

    WriteMakefile(
        NAME         => 'MyApp',
        VERSION_FROM => "lib/MyApp.pm",
        ABSTRACT => 'My great Application!!',
        PREREQ_PM => {
            'ExtUtils::MakeMaker'     => 6.31,
            'ExtUtils::Install'       => 1.46,
        },
        META_MERGE => {
            resources => {
                license => 'http://dev.perl.org/licenses/',
                repository => 'git://github.com/example/myapp.git',
            },
        },
        LICENSE   => 'perl',
    );

META_ADDでも追加できるがMETA_ADDはdefaultのmeta情報を上書きするので、とりあえずMETA_MERGE使っておけってExtUtils::MakeMakerのPODに書いてありました。

App::pfswatchをリリースしました（0.04に合わせて修正）

2011-07-01 追記

配布場所

http://beta.metacpan.org/module/App::pfswatch

概要

ファイルの変更を検知して、指定のコマンドを実行するツール

インストール

CPANから

    cpanm App::pfswatch

CPANで見つからない場合はgithubから

    git clone git://github.com/ysasaki/p5-app-pfswatch.git
    cd p5-app-pfswatch
    cpanm .

使い方

App::pfswatchに付属しているpfswatchコマンドを使います

2011-07-01 0.04で修正

-eは残りの引数すべてをCOMMANDとして受け取るようになりました

    $ pfswatch lib/ -e echo Hello, world

監視するパスを与えない場合はカレントディレクトリが監視対象になります。
指定のコマンドを実行後はまた監視状態に戻ります

Log::Minimalの出力先をファイルに変更するLog::Minimal::Fileを書いてみた

配布場所

github https://github.com/ysasaki/p5-log-minimal-file

インストール

git clone git://github.com/ysasaki/p5-log-minimal-file.git
cd p5-log-minimal-file
cpanm .

作成した理由

Log::Minimalの手軽さがナイスだったのですが、出力先をファイルに変更するのがめんどうだったので作成しました。

使い方

Log::Minimal::File->guard($filename)を呼ぶとguardオブジェクトが返ってきて、
guardオブジェクトが消えるまでは指定したファイルに書きこまれます。

    use strict;
    use warnings;
    use Log::Minimal;
    use Log::Minimal::File;
 
    infof("send to STDOUT");
 
    my $guard = Log::Minimal::File->guard('/tmp/your.log');
    infof("send to your.log");
    undef $guard;
 
    infof("send to STDOUT");

TODO

• Log::Minimal::Fileの名前で大丈夫か？
• 別途Log::Minimalをuseするのはなんかカッコ悪い
• 実装方法がいまいちな気がする

O'reillyでEbookをまとめ買い

被災者支援キャンペーンでEbookが半額だったのでいっぱい買ってしまった！

検索と発見のためのデザイン
GDBハンドブック
Binary Hacks
Linuxシステムプログラミング
プロダクティブ・プログラマ
ソフトウェアアーキテクトが知るべき97のこと
実用Git
プログラマが知るべき97のこと
C++クックブック
イノベーションの神話
キャパシティプランニング
並行コンピューティング技法
Real World Haskell
RESTful Webサービス

bashのexceとはなんぞや

発端

    #!/bin/bash
    exec 2>&1
    somecommand

というコードがあって、exec 2>&1が何をしているかはわかるけど、内部はどうなっているのか知らなかった

execってsystem callにあるよね

exec(2)は既存のプロセスのまま新しくコマンドを実行する

例えば

    $ exec ls

上記コマンドは既存のshellのプロセスのままlsを実行して終了する。実行中だったshellはexecされたら、lsになってしまうのでshellも結果として閉じる。

    $ ls

だとfork(2)して子プロセスでexec lsしているので、shellは終了しない

bashのexecはなんだよ

よくわからないからbashのsourceを読んでみる。Open Sourceに感謝する瞬間である。

Bash公式からダウンロード。tar ballを展開して、中身を改める。

ざっくり中身を見るとbuiltins/exec.defが怪しいので中をあらためる。そうするとshell_execveが見つかる。これを追いかけると以下のようになる。

builtins/exec.def
↓
shell_execve関数発見
↓
execute_cmd.cにあり
↓
int shell_execve (command, args, env)が見つかる
↓
execve (command, args, env);
↓
こいつはunistd.hで定義されているexecve(2)のようだ

眠いので限界です

次回へ続く？

第1回 Movable Type勉強会 in Hokkaido 参加記録

第1回FacebookMovable Type勉強会に参加してきました。

さっくりと今回のまとめ

1. Facebookの「いいね！」は少なくても意外と効果がある
2. Facebook広告のコスパがいい。現在はセグメントをかけない方が良さげ
3. hootsuiteは便利
4. ポポポポーン
5. Facebookページはiframeで表示させていた
6. 懇親会の同じテーブルでFacebookを使った新手のイジメがあった

イジメは冗談です。
あまり積極的にFacebookを活用していなかったので、いろいろと参考になる話しが多かったです。

今回はiframeで表示するFacebookページの管理はMTから行いましたが、このプラグインは来週火曜日に公開になるそうです。
個人利用は無償とのことでしたので、興味のある方はスカイアークさんのところ公開されるのを待ちましょう

アーキテクチャスタイル

システムアーキテクチャ構築の原理の読書メモ

ソフトウェアパターンの分類

一般に以下の3つに分類される

• アーキテクチャスタイル
• デザインパターン
• 言語イディオム

この3つの違いはシステム上でのレイヤーの違いで、アーキテクチャスタイルはシステムレベル、
デザインパターンはソフトウェア設計、言語イディオムはもっとも具体的な言語固有の問題の解決方法を表す。

アーキテクチャパターンのメリット

デザインパターンと同様で直接の解決策だったり、土台に利用したりもできる。
また一般的なパターンであれば、作業者のシステムの理解も早くなる。

アーキテクチャスタイル

1. パイプとフィルタ Pipes and Filters

   • メリット
     • フィルタ処理が独立化するので変更、再利用が用意
   • デメリット
     • 状態情報の共有が困難
     • フィルタ間でデータ変換のオーバーヘッドがある
     • エラー処理が難しい

2. クライアント/サーバ Client/Server

   • メリット
     • 複雑な処理の集中化
     • 機密性
   • デメリット
     • クライアントとサーバが同一マシン上ではない場合のオーバーヘッドの高さ

3. 階層化（ティア）コンピューティング Tiered Computing

   それぞれ段階層がクライアント/サーバの役割する

   • メリット
     • 階層ごとに関心事を分離できる
     • 階層の再利用が可能になる
   • デメリット
     • 階層間の通信のオーバーヘッド
     • システム要素数の増加による追加開発の複雑さ

4. ピアツーピア Peer-to-Peer

   各ピア（システム要素）がクライアント/サーバとなるが、中央サーバを必要とせずピア同士で自由に通信する

   • メリット
     • スケーラビリティの高さ
   • デメリット
     • 中央ピアリストが入手できないと、ピアのネットワーク分断が起こりやすい
     • 任意の時点でのシステムからの特定の応答が保証するのが困難
     • どういうこっちゃ？

5. レイヤ実装 Layered Implementation

   システム要素をレイヤとし、各レイヤをスタックする。
   レイヤは抽象レベルによって分割されて、スタックの一番上が特定の操作等にあたり、 スタックの下にOSのシステムライブラリが来る。

   Note
   Tiered Computingとの違いはいまいちわからないが、単体でサービスを提供するかどうか、
   レイヤは機能の垂直分割、Tiered Computingは機能の水平分割の模様。
   所謂Web ApplicationのMVCのスタイルはTiered Computingにあたるんだろうか

   • メリット
     • レイヤの再利用
     • 関心ごとの分離
     • 各レイヤの分離による保守管理の用意さ
   • デメリット
     • 実装の柔軟性の低下
     • レイヤ毎に順番に開発する必要性がある

6. パブリッシャ/サブスクライバ Publisher/Subscriber

   • メリット
     • SubscriberをPublisherの緩やかな結合
   • デメリット
     • 実装が複雑
     • 信頼性のあるメッセージ配信が必要な場合、複雑になりがち

7. 非同期データ複製 Asynchronous Data Replication

   Publisher/Subscriberの変種。データを同期させる必要がある場合に利用される。
   データソース、データレプリカ、レプリケータの3つの要素で構成される

   Note
   DBのレプリケーションとかがこれにあたるのか

   • メリット
     • ロジックを複雑化させることなく、データが同期できる
   • デメリット
     • ソースとレプリカの更新の間で発生するタイムラグ
     • レプリカデータストアでの更新処理に対応すると複雑化する

8. ディストリビューションツリー Distribution Tree

   パブリッシャ、ディストリビュータ、消費者の3つのタイプのシステム要素がある。
   パブリッシャがツリーの根になって、ディストリビュータが中間ノードを作り、消費者がツリーの葉になる。

   Note
   PubSubHubbubがまさにこれのような感じがする

   • メリット
     • 小規模から大規模まで拡張可能
   • デメリット
     • ディストリビュータを挟むので更新待ち時間がある
     • ディストリビュータが蓄えるキャッシュが規模の拡大に伴って負担になる

9. 統合ハブ Integration Hub

   多数の異なるシステム間で情報を同期させる必要がある状況に利用される。
   非同期データ複製(Asynchronous Data Replication)を拡張したもの。

   データソース、データ送付先、ハブ、アダプタの4つのシステム要素がある。
   ハブを経由してデータソースとデータ送付先がデータを同期する。その際にアダプタがデータを共通形式に変換し、自由にデータを同期させられるよう責任をもつ

   • メリット
     • 新しいデータソースや送付先の追加による影響が少ない
     • アダプタによってソース独自の詳細等を隠蔽できる
   • デメリット
     • 全部の形式をサポートするのは現実的じゃないので、共通モデルの設計が難しい
     • 変換が多く挟まるので非効率的
     • ハブの作り込みが甘いと障害点になる

10. タプルスペース Tuple Space

    クライアント（情報を生成して処理するコンピュータ処理要素）とタプルスペースそのもの（型づけされた情報タプルまたはレコードをクライアントが読み書きする記憶空間)の二つのタイプのシステム要素がある。
    クライアントとタプルスペースはクライアント/サーバネットワーク接続で接続する。クライアント同士は接続しない

    Note
    並列処理向きの模様。
    Job Queueもこれの一種？worker, clientがクライアント要素で、daemonがタプルスペースに当たるよね？

    • メリット
      • 単純なコンピュータ処理モデルを提供
      • クライアント間の緩やかな結合
    • デメリット
      • タプルスペースのスケーラビリティの限界