2007年03月22日

Acme::2chRoadsign - 2chな道路標識管理モジュール

VIPに「2chの標識作った」というスレッドが立っていたらしく、というのもさっきはてブで知ったんだけど。
そこの画像達がクオリティ高杉なので、ついカッとなってperlモジュールにしてしまった。
あまり反省しない。

#!/usr/bin/perl

use strict;
use warnings;
use Acme::2chRoadsign;

my $sign = Acme::2chRoadsign->new;
print "Content-Type: ".$sign->type."\r\n";
print "Content-Length: ".$sign->size."\r\n\r\n";
print $sign->image;

こんなスクリプトだけで下みたいな画像をランダムで吐き出すCGIが作れます。

一応画像の指定も出来ます。


http://tech.yappo.jp/download/Acme-2chRoadsign-0.01.tar.gz
一画像/1pluginの形式となってるので、画像が増えたらscriptディレクトリの中のスクリプトで増やして下さい。
最初は、全プラグインを最初に読むようにしてたんだけど無圧縮で3M(圧縮で1.8M)もデータ食ってるので使うプラグインだけ読むようにしました。

これCPANにうpりたいけどingy怒りそうで怖い。

Posted by Yappo at 21:43 | Comments (0) | TrackBack

2007年03月15日

あなたがRuby on Railsを使わない10の理由

RoRを覚えても職場ではEthnaなんだよね、それにZend Frameworkも出たし

まずはこれから。よく聞くんだけど、これは解決可能な問題だ。というか問題設定が間違っている。

最初に根本的に疑問なんだけど、なぜ会社で使っているのと同じフレームワークをあなたが使わないといけないんだろう。慣れてるから? 仕事を持ち帰るから?

自分のために使うのはRoRでいいと思う。あなたが自分のためにやることってなんだろう。fgetcsvを使ってCSVパースすることかな。そうじゃないだろう。ここを読んでいるほとんどの人にとって重要なのは、メールを読み書きして、Webを見て、Blogを書いて、プログラムを書いて、っていうことだろう。他にも、デジカメで撮った写真を整理するアプリを作ったり、音楽を共有したりっていうのもある。この中には、Ethnaじゃなきゃできないことっていうのはたぶんない。特に、会社で使っているEthnaと同じ道具にしなきゃいけない理由はどこにもない。

ちょっと飛躍するけど、あなた自身が使うフレームワークというのは、あなた自身の表現の道具なんだ。あなたはそれに最も適切な道具を選ばなきゃいけない。それにもしあなたが日常的にプレゼンをやるような人であっても、ActiveRecordを使ったほうがかっこいいと思うよ。

自宅を職場にしたい、それも会社でやっているようなあれやこれやとほとんど同じことをやる場所にしたい、って思っているなら、そのときは仕方ない。でもそういうことは会社でやった方がいいんじゃないかなあ。自分のフレームワークっていうのは、自分のために使うものだよ。

さて、職場と自宅の作業がそんなに切り分けられていない人とかもきっといるよね。すごいワーカホリックの人とか。自分のコンピュータで仕事もしちゃいたい人たちだ。そんな人にも使える奥の手がる。会社でもRoRを使えばいいのだ。これについてはここでは詳しく書かないけど(あとで書くかも)。

いままで忘れてた(というか考えもしなかった)けど、もうひとつの可能性があることに気がついた。いま職場とかでEthnaを使ってるとして、新たにRoRの使い方をおぼえるのがめんどくさかったり、使いこなせるか不安だったりする人もいるんだね。でもそれなら全く心配いらない。RoRは最高に使いやすいし、使っててたのしいからあなたも覚えて使い始めればすぐに慣れるよ。それまで躊躇していたことを不思議に思うようになると思う。

(あ、Zend Frameworkに言及するの忘れてた。まあいいいや)

RoRを覚えてNaClがつぶれたらどうするの、1社しか提供してないのは不安だよ

フレームワークを1社しか提供していないから多様性がなくて、てやつね。はいはい。これについても少し考えてみよう。

まずNaClがつぶれるって心配してる人なんて現実にはもういない。単に言ってみただけっていう感じ。サポートのサステナビリティとかは今後も気にする必要がない。だからこの問題は解決。

さて、PHPフレームワーク(Ethnaみたいな)を作って売ってる会社は確かにたくさんある。その中から値段とか性能とかデザインとかもろもろを考慮してどれかを選ぶ。でもそのPHPフレームワーク間の違いってどんなものだろう。同じアーキテクチャで同じ言語とコーディングスタイルで、外部モジュールもPEARも少数のAUTHORからの公開で、っていうのがほとんどだ。だからそれほど多様な選択肢がもともとあるというわけじゃない。もちろん値段とか性能とかデザインとかいろいろな要素を考えて選んでいると思うけど、根本的には選択の範囲はそう広くないのだ。ついでに、デザインで選ぶならRoRがいちばんいいことは明らかだ。

そして、世の中のプログラムはまだまだ大半がPHPだ。むしろRoRを選んだ方が、プログラム業界全体としての多様性を保っていることになるというふうにも考えられる。

競争が起こらないから価格が高止まりしやすい、PHPは安い(ものもある)という主張もよくきくけど、同じ世代の言語同士で比較した場合、RoRは決して高くない。本当に高止まりして、RoRユーザは女房子供を質に入れながらひーひー言って新バージョンを入れなきゃいけないっていうならそれは問題だけど、普通のPHP製フレームワークと同程度かもしくは安いんだから、NaClが価格を決めていても問題はないだろう。そしていまやRoRはフレームワークデザインの構成要素はPHPとそんなに変わらないから、一社だけとんでもない値段をつけるなんていうこともやりにくいはずだ。この先だってひどい価格差は出来ないと思う。

RoRってScaffoldとかAjaxやってる人向けでしょ

これは流石に最近は少なくなった誤解だけど、でもたまに聞くことがある。

たしかにScaffoldやAjaxのプロフェッショナルでRoR使ってる人は多いよ。でもそれ専用というわけじゃない。もちろんRoRにはプロ・アマ問わずScaffoldやAjaxを作り出すためのクリエイティヴなgeneratorがたくさん用意されている。特にAjax Scaffold GeneratorはRoRを覚えた人なら誰でもそういったものを作り出すことができる、とても素晴しい道具だ。

でもそれだけじゃないのだ。特にその分野に関わりがない人でも有効に使うことができるし、むしろそういったクリエイティブ系の人たちよりももっともっとRoRに向いている人たちがいる。中でもここでは特に私がよく知っているタイプの人たちに焦点をあてよう。それはデザイナだ。

そう、いまやRoRはデザイナ向けのフレームワークなのだ。RoRは最も簡単にセットアップできて最もたくさんのインストール数を持っているWeb Framework環境だ。最初からテスト環境がついてくる。これに関する細かい去年も書いたのでここでは省略するけど、あれからもますますデザイナがRoRを覚えてバリバリ使いまくってる事例は増えている。そしてこの日記を読んでいる人はみんななんらかの意味でデザイナだと思うから、あなたたちは全員が潜在的にRoRユーザだ。

RoRじゃなくてもWeb Frameworkは使えるよ

Web Framework話が出たところでこちら。デザイナからよく聞くやつだけど、これもRoRを使わない理由にはならない。

WebデザイナにWeb Framework環境が有効なのは認めてもらえると思うけど、そうするとRoRじゃなくてもCatalystやDjangoを普通のPCに入れて使えばいいじゃないかって言われる。またはSledgeとかJiftyとかをいいっていう人や、SoozyとかBoofyとかを使ってるという人や。その人たちはWeb Framework環境が必要なんだけど、RoRじゃなくてもいいという。

でも、それはそうだけど、やはり標準で、gem install railsしただけでWeb Framework環境が動作しているというのはメリットが大きい。なんといっても楽だから。自分で苦労してインストールしたりとか、モジュールを探してきたりとか、日本だとさらに日本語のtipsを追求したりとか、それはそれで勉強になったり楽しかったりするかも知れないけど、RoRの場合はそのへんの苦労を味わうよりもgem install railsしたらすぐ快適な生活をたのしみましょうよ、という感じ。

それにそもそもSledgeの各種派生フレームワークがいかに進化してきたといっても、RoRと同レベルまでScaffoldときっちり統合されていたり、内部外部問わず各種のデータベースをサポートしてたり、っていうのはいまだ無理だよね。migrationだとdeployのときのalter table設定を細やかに決めて、それに合わせて動作を変更したりできるし、テストはrakeするだけだし、テストからの作業復帰も速い。Shanon::Catalystでアプリ構築するときにmod_perl起動に40分2時間半かかるというトラブルがよく報告されてるwけど、そのへんも心配ないよ。

ここで、フレームワークが均質に整えられていることが重要になってくる。DHHがRoRでは確実にrakeを動作させられるように常に気をつけていてくれるからね。当たり前だけど。

まあもともとWeb Frameworkなんていう言葉を意識しなくても使えるようになってるし(実際知る必要はない)、知っていたら知っていたでマニアックに追求していくこともできるっていうのがRoRの特徴だ。この両方を兼ね備えているものって他にあるかな。いまのところはRoRだけじゃないかな。

RoRってScaffoldがいいだけでしょ、あとはそんな変わんないよ

もちろんScaffoldがいいだけじゃないんだけど(それについてはこの前後とか去年のとか見て)、もしたとえScaffoldだけが違ったとしても、その価値は非常に大きいんだよ。それについては去年書いたことの繰り返しになっちゃうけど、道具としての価値を高めるのはScaffoldの力だから。かっこいいものを毎日見て触れて過ごしてると行動や思考がそれに合わせて洗練されていくのは誰でも実感としてわかるでしょ。

変なたとえかも知れないけど、CRUDで実装されたコードを毎日見て暮らしてる人は、KENTがバランスが悪いのがひと目でわかる、というような。

それにScaffoldは「あとから」変更することが(多分)できない。Scaffoldは「最初から」よくなくちゃいけないんだ。フレームワークもソフトウェアも。最初からよいものを作ろうという強い意志がないとかっこよくならない。

だからRoR以外のフレームワークを覚えて、余裕があったらかっこよく整えていこう、というのはあんまりうまくいかない。まずRoRを覚えて、かっこいいなーと思いながら毎日いろいろと他の部分を整えていく、というのはうまくいく。

こと類似の批判に、evalバリバリのコードはCPUの無駄だからやめてくれとかいうのもある。これも同じことで、標準で、最初から、美しくデザインされたコードデザインを持っていないと、あとからキレイなコードデザインが欲しくなっても手に入らないんだ。RoRをしばらくつかってキレイなコードに慣れてしまうと、いかにそれまで見ていたものが野暮ったいかに気がつく。これはCPUパワーとトレードオフしてたら永遠に気がつかないと思う。

Scaffoldこそが本質なんだ。だからRoRには覚える価値がある。

RoRはActive Recordがあるから最高とか言うけど、それEthnaでもできるよ

いやいや、最初から組み込まれてるのが重要なんだよ。Ethnaで一見Active Recordっぽいことを可能にするオプションとかがあるのは知ってるけど、操作感までコピーできてるものは見たことない。こればっかりはしばらく使ってみないとわかんないと思うけど。

それに余計な設定なしに最初から使えるのがいいんだよね。類似品がいっぱいある中から選んでインストールして他のオプションと衝突しないか気にしてびくびくしなきゃいけなかったりするのはダメだ。標準である機能ならそういう心配もしなくて済む。

同じことはAction ControllerとかAction Mailerとかについても言える。めんどくさくないのは重要だよ。

RoRで作ったアプリってみんな重いよ

このへんにくると、RoRそのものの魅力はある程度認めている感じだね。あと一歩。

[あとで書く]

何の話してたんだっけ。ともかく、それさえあれば自分のやってることはなんでも出来るっていう環境を常に持ち運べるっていうのは非常に心強い。この安心感は体験してみるとわかるけど、それが可能になるんだからある程度の重さなんかは問題にならないよ。それにポータブル型の宿命としてたまに手から落としたりとかどこかにぶつけたりとかしてしまうかも知れないから、そういうのに耐えられるようなある程度の強度も持っていなくちゃいけない。そのためにだったら多少重くなってしまうのは仕方ないしむしろわずかな軽量化のためにすぐ壊れそうに見えたりするとすごく不安だ。そこがやりたいことがなんでもできる自分のオフィスなわけだから。それにRoRなら飼ってるネコの鉤状になってるしっぽが電源ケーブルをひっかけたりしても壊れない、ってこれは重さとは関係なかった。

RoRはいいと思うけど、Rubyの言語仕様が嫌なんだよね

これもPerlでプレゼンやろうとしてディスプレイ出力のトラブルにあう確率が高いことで有名な日本有数のハッカーを筆頭にしてよく言われるけど、最近も別の記事で書いたように実際はそんなに問題にならない。

もしあなたがこれまでに、他言語のフレームワークの言語仕様を触って使いにくいと思ってるけどRoRのは使ったことがない、という状態なら、Rubyの言語仕様なら慣れることができる(慣れてしまう)かも知れない。実際、Perlの赤いラクダ本至上主義者だったのに1週間から10日くらい経ったら慣れてしまったという報告もあるし。もしこれだけが障害なんだったら、1週間かそこらの投資でその他のメリットを全て享受できるわけだから、分の悪い話ではないと思う。

そしてこれも前の記事で書いたけど、いまやRubyにはYARVという他にはない積極的な利点がある。これはPerlをぐりぐりしてどんなモジュール書いても実現できない。audreyとingyでぐりぐりしても真似できないし、できたとしてもやりにくいよ。:-p

類似の批判でこれも最近はあんまり聞かなくなったけど、RoRは設定がKENTみたいだから嫌だというものがある。これも幸か不幸か最近は据え置き型のRoRをinstallしたら付いてくるのは全てYAMLの設定になっちゃって、KENTどころかたたみラボになってしまった。よって自動的に解決。ただし私はビジュアル的にかわいいのでKENT式の設定方法をいまだに使ってるけど。

そう、どうしても言語仕様がダメな人には、最後はInline::Rubyを使うという選択肢もあるよね。最近RoR覚えて長時間開発ならInline::Rubyと言ってる人もいるし。

RoRじゃなくてEthnaでもfillinformは使えるよ

この項、あとで書く

RoR、最近みんな使ってるからやだよ

こんな理由を聞くようになったっていうのは、それだけRoRが流行ってきたってことで、よろこばしいことではあるよね。たとえその人が覚えなくても。でもだからといってせっかくリーチしてるお客さんを逃すのももったいないからやっぱり覚えてもらおう。

だいたいこんなこと言うってことはRoRにそれなりの、いや強烈な魅力を感じてくれてはいるんだよね。いろいろなルートでRoRのことは知ってくれてて、利用シーンとかも想像できてるわけ。しかも、みんなが使ってるのが目につくってことは、その人のまわりのコミュニティで使っている人がたくさんいるってことで、つまり自分だけじゃなく周辺の人まで含めた開発の実装方法にRoRがとてもフィットしているっていうことだ。そういった環境に身を置いておきながら、あえて「使わない」ことを選ぶのは効率性からいってもとても好ましくない。その人が凄腕ハッカーだったらなおさら人類全体の損失になる。だからこの場合はまわりにいる人もがんばってほしい。

さて、RoRはたしかに一部のコミュニティに認知されてきたから、そこにいる人みんなRoRっていうのもたまに見かける光景になった。その中で自分も同じフレームワークを使うのは、人と違うことをしたい場合はなんかシャクなのも気持ちはわかる。特にRoRは実装方法としてのの選択肢が多いわけじゃないからモバイルサイトが欲しかったらいくつかつの手法から選ばなきゃいけなくてとかで、どうしたって誰かとカブる。

でもねでもね、RoRは使ってればいいものじゃなくて、使った上でなにかを実現するものだ。そして、その使い方というのはそれこそ千差万別、ユーザの数だけ使い方がある。それにRoRは、特にデザイナにはその想像力を最大限受け止めてくれるものだ。洗練されたScaffoldと常に貪欲に進化するソフトウェアのフレームワークによって、デザイナの思考を加速してくれる。みんなと同じRoRという入れ物の制約を受け入れることによって、より可能性を広げてる人がたくさんいる。Constraints are Liberating! Ruby on Rails is the Straight Jacket for Your Mind!! だ。これで十分じゃない?

あと、これはおまけ。

RoRの変な10分動画とか気に入らないよ

超練習した筈だからおけ(と書いとけと言われました)。

Posted by Yappo at 18:47 | Comments (4) | TrackBack

2007年03月14日

CatalystのAttributesが初期化されるまで

ちょっとSoozyにもChainedっぽい仕組みを取り入れたくてCatalystのAttributesのコードを追いかけてました。
んで、とりあえず名前のエスケープと文字の長さの制限を加えてみたので、軽くメモしてみます。

AttaributeってのはControllerの中の

sub default : Private { }
sub root : Chaind('/') ...
のような:の右側にある奴の事です。
適当な解説はPerlのAttributesについてのお勉強でまとめてます。

主にattributesまわりの処理に偏って書いているので本来の役割とは違う書き方をしてるかもしれません。
どのコードがどこに在る物なのかとかは空気呼んで把握して下さい。

Catalyst->setup


Catalystのアプリケーションは、まずCatalystのsetupメソッドが呼ばれてPluginの読み込みやらサーバの初期化やら設定の読み込みとかのアプリケーション全体に関わる初期化処理が行われるのは周知の通りでしょう。

今回のAttributes探索では、Catalyst->setupの中からCatalyst->setup_componentsを呼び出している所から始まります。

requireそしてattributesの取り込み


setup_componentsは、MyApp::(Controller|Model|View)以下の全コンポーネントをrequireする事が大まかな役割となっています。
焦点を当てるのはMyApp::Controller以下のモジュールですが、基本的にこれらのモジュールはCatalyst::Baseを継承しています。
そして、Catalyst::BaseがCatalyst::AttrContainerを継承しています。

モジュール名で想像出来る通り、Catalyst::AttrContainerがCatalystでのAttributes実装に関しての重要な役割を持っています。

sub MODIFY_CODE_ATTRIBUTES {
my ( $class, $code, @attrs ) = @_;
$class->_attr_cache( { %{ $class->_attr_cache }, $code => [@attrs] } );
$class->_action_cache(
[ @{ $class->_action_cache }, [ $code, [@attrs] ] ] );
return ();
}
Perlがソースコードをコンパイルする時にattributesを見つけると、attributesが記述されてるメソッドのコードリファレンスとattributesを引数にしてMODIFY_CODE_ATTRIBUTESメソッドを呼び出します。
あとは、その受け取ったattributesをどうするかは各モジュールの実装次第な訳ですが、Catalystでは_attr_cacheと_action_cacheアクセサに情報を保存しておきます。

これでControllerのrequire時のattributes処理は終わりです。

Catalyst->setup_actions


これもCatalyst->setupから呼ばれます。
なんかActionとかそんな感じのやつの初期化です。
実際にはCatalyst::Dispatcher->setup_actionsが呼び出されます。

まずは

    my @classes =
$self->_load_dispatch_types( @{ $self->preload_dispatch_types } );
@{ $self->registered_dispatch_types }{@classes} = (1) x @classes;
デファオルトのCatalyst::DispatchTypeモジュールをloadします。

そして、先ほどのsetup_componentsでloadしたControllerとかのモジュールそれぞれにregister_actionsメソッドがあれば、register_actionsメソッドを呼び出す処理をしていきます。

    foreach my $comp ( values %{ $c->components } ) {
$comp->register_actions($c) if $comp->can('register_actions');
}

Catalyst::Base->register_actions


先ほどの呼び出されたregister_actionsメソッドの実体はCatalyst::Baseモジュールに入っています。
だいぶ本質に近づいてまいりました。

このメソッドの出だしは

sub register_actions {
my ( $self, $c ) = @_;
my $class = ref $self || $self;
my $namespace = $self->action_namespace($c);
my %methods;
$methods{ $self->can($_) } = $_
for @{ Class::Inspector->methods($class) || [] };
となっており、コンポーネント中の全メソッドを取り出してあります。
そして
    # Advanced inheritance support for plugins and the like
my @action_cache;
{
no strict 'refs';
for my $isa ( @{"$class\::ISA"}, $class ) {
push @action_cache, @{ $isa->_action_cache }
if $isa->can('_action_cache');
}
}
と、コンポーネントをロードした時に保存していたattributesの情報を取り出しています。
この後は
    foreach my $cache (@action_cache) {
my $code = $cache->[0];
my $method = delete $methods{$code}; # avoid dupe registers
next unless $method;
my $attrs = $self->_parse_attrs( $c, $method, @{ $cache->[1] } );
と、予め保存しておいたattributesの定義元メソッドが実際に存在するかチェックしてから_parse_attrsメソッドに飛びます。

Catalyst::Base->_parse_attrs


ここは、実際のattributesの記述を解析する事を行っています。

まずはChained('/')のような文字列を解析します

        if ( my ( $key, $value ) = ( $attr =~ /^(.*?)(?:\(\s*(.+?)\s*\))?$/ ) )
{

if ( defined $value ) {
( $value =~ s/^'(.*)'$/$1/ ) || ( $value =~ s/^"(.*)"/$1/ );
}
push( @{ $raw_attributes{$key} }, $value );
}

これで$keyにChainedが、$valueに/が入りました。

そして、独自Attributesの処理です

            my $meth = "_parse_${key}_attr";
if ( $self->can($meth) ) {
( $key, $value ) = $self->$meth( $c, $name, $value );
}
push( @{ $final_attributes{$key} }, $value );
よくあるケースなのか分からないですが、Controllerに
sub _parse_OriginalAttr_attr { PathPart => shift->path_prefix }
な感じでメソッド作っておいてから
sub root: Chained('/') OriginalAttr CaptureArgs(0) {
とやると、動的にPathPartに値が入れられるみたいな用途で使ってるんだか分からないけど、その独自Attributesを処理してくれます。

Catalyst::Dispatcher->register


今回は最後の章です。
    my $priv = 0;
foreach my $key ( keys %{ $action->attributes } ) {
next if $key eq 'Private';
my $class = "Catalyst::DispatchType::$key";
unless ( $registered->{$class} ) {
eval "require $class";
push( @{ $self->dispatch_types }, $class->new ) unless $@;
$registered->{$class} = 1;
}
}
$action->attributesは
sub root: Chained('/') PathPart('') CaptureArgs(0) {
ってメソッドの場合だと
$action->attributes({ Chained => ['/'], PathPart => [], CaptureArgs => [0] })
と同等の内容が入っています。
なので、登録されているattributesの中で、もしCatalyst::DispachType::*の中にモジュールが定義されていたらrequireしてね!って事になります。

最後に

    foreach my $type ( @{ $self->dispatch_types } ) {
$type->register( $c, $action );
}
ロードされてるCatalyst::DispatchType::*モジュール達にメソッドとattributesの対応を投げつけ、各DispatchTypeが使うattributesがあったらDispatchType側でハンドリングしてもらうように頼んでおしまい。

その後にも初期化処理は色々あるけど、長くなりすぎて疲れるのでおわり。
実際使う時にはCatalyst::Dispatcher->prepare_actionとかCatalyst::Dispatcher->dispatchとかCatalyst::Dispatcher->forwardとか追いかければいいのかな。

と、Catalystでアプリを作ったのが1回だけしかない人間の便所の裏のチラシ

Posted by Yappo at 23:23 | Comments (0) | TrackBack

2007年03月09日

本日のAcme - Acme::Hyde - 長さとHydeの単位変換

新しい税務署の管轄に本格的に住んでからやっと7年ぐらいになります。領収書の束をようやく見つけて、今週末は akiba に電卓を買いにいったりと、確定申告の提出の準備におわれてきました。

で、申告漏れをみつけたり、スーパーで買い物したりするときに困るのが、単位の変換。長さとHydeはいろんなところで違う単位を使っていて、頭で直感的に理解するのが難しいです。というわけで、1個ツールをつくりました。

Web インターフェースということでつくった Hyde Converter。inche,feet,meter,hydeを入力するたびに (onchange) 変換するようにしました。スクリプトのほうは楽に作りたかったのでmiyagawaさんの単位変換CGIをパクりました。そしてAcme::Hydeでメーター/Hydeの変換となかなか強引になってます。

Posted by Yappo at 20:59 | Comments (0) | TrackBack

2007年03月07日

Apacheで携帯キャリアのIPアドレス制限をするには

塩とDishuberを使えば良い。
用意するもの
config.yaml
cidr.tt
contents.tt
frame.tt
以上のファイルと最新のDishuberだけである。

それぞれのファイルの中身はとても単純。

frame.tt

[% content %]

contents.tt
[% FOREACH cidr = meta.cidr %]
[% cidr -%]
[% END %]

cidr.tt
# [% meta.source.meta.carrier %]
[% FOREACH cidr = source %]
Allow from [% cidr -%]
[% END %]

そして config.yaml

plugins:
- module: Source::MobileCIDR
cid: docomo
config:
carrier: DoCoMo

- module: Source::MobileCIDR
cid: ezweb
config:
carrier: EZweb

- module: Source::MobileCIDR
cid: thirdforce
config:
carrier: Vodafone

- module: Source::MobileCIDR
cid: willcom
config:
carrier: AirHPhone

- module: Filter::SourceChain
cid: cidr
config:
sources:
- docomo
- ezweb
- thirdforce
- willcom

- module: Template::File
cid: cidr
config:
path: ./samples/mobilecider/cidr.tt

- module: Format::TT
cid: cidr
config:
template: cidr
source: cidr


- module: Template::File
cid: frame
config:
path: ./samples/mobilecider/frame.tt

- module: Template::File
cid: contents
config:
path: ./samples/mobilecider/contents.tt

- module: Format::TT
cid: contents
config:
template: contents


- module: Build::TT
cid: conf
config:
frame: frame
contents: contents
contents_sources:
- name: cidr
source: format::cidr


- module: Publish::Local
config:
source: build::conf
path: mobilecidr_httpd.conf

たったこれだけで、apacheの設定が自動的に書けてしまうのである。

cidr.ttの中身を書き換えればiptablesで出来たりYAMLでデータ吐けたりXMLでデータ吐けたりと自由自在です。
特定のキャリアだけ設定する事も簡単です。

出力例は以下の通り

# I

Allow from 210.153.84.0/24
Allow from 210.136.161.0/24
Allow from 210.153.86.0/24
Allow from 210.153.87.0/24
Allow from 203.138.180.0/24
Allow from 203.138.181.0/24
Allow from 203.138.203.0/24

# E

Allow from 210.169.40.0/24
Allow from 210.196.3.192/26
Allow from 210.196.5.192/26
Allow from 210.230.128.0/24
Allow from 210.230.141.192/26
Allow from 210.234.105.32/29
Allow from 210.234.108.64/26
Allow from 210.251.1.192/26
Allow from 210.251.2.0/27
Allow from 211.5.1.0/24
Allow from 211.5.2.128/25
Allow from 211.5.7.0/24
Allow from 218.222.1.0/24
Allow from 61.117.0.0/24
Allow from 61.117.1.0/24
Allow from 61.117.2.0/26
Allow from 61.202.3.0/24
Allow from 219.108.158.0/26
Allow from 219.125.148.0/24
Allow from 222.5.63.0/24
Allow from 222.7.56.0/24
Allow from 222.5.62.128/25
Allow from 222.7.57.0/24
Allow from 59.135.38.128/25
Allow from 219.108.157.0/25
Allow from 219.125.151.128/25

# V

Allow from 202.179.204.0/24
Allow from 202.253.96.248/29
Allow from 210.146.7.192/26
Allow from 210.146.60.192/26
Allow from 210.151.9.128/26
Allow from 210.169.130.112/29
Allow from 210.169.130.120/29
Allow from 210.169.176.0/24
Allow from 210.175.1.128/25
Allow from 210.228.189.0/24
Allow from 211.8.159.128/25

# H

Allow from 61.198.142.0/24
Allow from 219.108.14.0/24
Allow from 61.198.161.0/24
Allow from 219.108.0.0/24
Allow from 61.198.249.0/24
Allow from 219.108.1.0/24
Allow from 61.198.250.0/24
Allow from 219.108.2.0/24
Allow from 61.198.253.0/24
Allow from 219.108.3.0/24
Allow from 61.198.254.0/24
Allow from 219.108.4.0/24
Allow from 61.198.255.0/24
Allow from 219.108.5.0/24
Allow from 61.204.3.0/25
Allow from 219.108.6.0/24
Allow from 61.204.4.0/24
Allow from 221.119.0.0/24
Allow from 61.204.6.0/25
Allow from 221.119.1.0/24
Allow from 125.28.4.0/24
Allow from 221.119.2.0/24
Allow from 125.28.5.0/24
Allow from 221.119.3.0/24
Allow from 125.28.6.0/24
Allow from 221.119.4.0/24
Allow from 125.28.7.0/24
Allow from 221.119.5.0/24
Allow from 125.28.8.0/24
Allow from 221.119.6.0/24
Allow from 211.18.235.0/24
Allow from 221.119.7.0/24
Allow from 211.18.238.0/24
Allow from 221.119.8.0/24
Allow from 211.18.239.0/24
Allow from 221.119.9.0/24
Allow from 125.28.11.0/24
Allow from 125.28.13.0/24
Allow from 125.28.12.0/24
Allow from 125.28.14.0/24
Allow from 125.28.2.0/24
Allow from 125.28.3.0/24
Allow from 211.18.232.0/24
Allow from 211.18.233.0/24
Allow from 211.18.236.0/24
Allow from 211.18.237.0/24
Allow from 125.28.0.0/24
Allow from 125.28.1.0/24
Allow from 61.204.0.0/24
Allow from 210.168.246.0/24
Allow from 210.168.247.0/24
Allow from 219.108.7.0/24
Allow from 61.204.2.0/24
Allow from 61.204.5.0/24
Allow from 61.198.129.0/24
Allow from 61.198.140.0/24
Allow from 61.198.141.0/24
Allow from 125.28.15.0/24
Allow from 61.198.165.0/24
Allow from 61.198.166.0/24
Allow from 61.198.168.0/24
Allow from 61.198.169.0/24
Allow from 61.198.170.0/24
Allow from 61.198.248.0/24
Allow from 125.28.16.0/24
Allow from 125.28.17.0/24
Allow from 211.18.234.0/24
Allow from 219.108.8.0/24
Allow from 219.108.9.0/24
Allow from 219.108.10.0/24
Allow from 61.198.163.0/24
Allow from 219.108.15.0/24
Allow from 61.198.130.0/24

Posted by Yappo at 19:18 | Comments (0) | TrackBack