2008-12-02 [長年日記]
_ RotationMaker を作った
最近は iCal づいています。
/lang/ruby/misc/rotation-maker – CodeRepos::Share – Trac
これは何か?
README より抜粋
- 例えば毎週月曜に何かやります
- メンバーが 5人いて担当は 2人ずつとします
- いつ誰が担当するのか先々の予定を算出したい
- ハッピーマンデーがあるので、その場合は火曜にスライド
みたいなときに便利かもしれないツールです。
使い方
オプションを与えずに起動するとなんとなく分かります。たぶん。
$ ruby rotation-maker.rb
Usage: rotation-maker [options]
-x, --exclude DATE
--exclude-from-ical ICS
--exclude-from-file FILE
--exmethod [METHOD]
-s, --dtstart DATE
-e, --dtend DATE
-i, --interval INTERVAL
-d, --date EVENT DATE
--date-from-ical ICS
--date-from-file FILE
-m, --member MEMBER
--member-from-file FILE
-a, --atonce NUMBER
-y, --yaml FILE
最低限必要なものは
- date
- member
です。-d や -m を複数書いてもいいですが、それぞれ1行1アイテム形式のファイルから読み込ませることもできます。
また、date ではなく -s START, -e END, -i INTERVAL でくり返しの予定を記述することもできます。INTERVAL は基本的に整数ですが、activesupport をインストールしてあれば week, month, year も指定できます。
exclude で除外する日付を指定します。デフォルトでは除外日に予定が当たったらその日はスキップします。exmethod オプションに backload を与えていたら次の日にずらします。次の日も除外日だったら除外日でなくなるまでスライドします。*1
あ、今気づいたけど slide オプションは YAML からしか与えられないじゃないか。後で直します。
YAML で設定を書く場合はこんな感じで書きます。
dtstart: '2008-12-01' dtend: '2009-03-31' interval: week atonce: 2 exmethod: backload members: - abc - def - ghi - jkl - mno - pqr - stu excludes: # PATH or URI ical: http://www.google.com/calendar/ical/japanese%40holiday.calendar.google.com/public/basic.ics
出力部分は自分で書いてください^^;
例えばこんな感じのものを用意すると iCal 形式で予定を吐き出せます。
#! /usr/bin/env ruby # -*- coding: utf-8 -*- require File.dirname( __FILE__ ) + '/rotation-maker' require 'erb' require 'nkf' def main rot = RotationMaker.new.run puts NKF::nkf( '-w -Lw', ERB.new( template, nil, '-' ).result( binding ) ) end def serialized_time( time ) return time.gsub( /-/, '' ) end def template return <<EOD BEGIN:VCALENDAR VERSION:2.0 BEGIN:VTIMEZONE TZID:Asia/Tokyo X-LIC-LOCATION:Asia/Tokyo BEGIN:STANDARD TZOFFSETFROM:+0900 TZOFFSETTO:+0900 TZNAME:JST DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE <%- rot.each do |r| -%> BEGIN:VEVENT SUMMARY:社内勉強会 DESCRIPTION:発表 <%= r['member'].join( ', ' ) %> DTSTART;TZID=Asia/Tokyo:<%= serialized_time( r['date'] ) %>T180000 DTEND;TZID=Asia/Tokyo:<%= serialized_time( r['date'] ) %>T190000 END:VEVENT <%- end -%> END:VCALENDAR EOD end main
結果はこんな感じ。

あ。あれ? Google Calendar にある Japanese Holidays の成人の日の情報が
DTSTART;VALUE=DATE:20090112 DTEND;VALUE=DATE:20090113 DTSTAMP:20081203T115909Z
になってますね。見た目は 12日だけに見えるんだけど。えーまぁ、これはデータの問題ということで。
問題というか
iCal の Rrule *2って、くり返しの終了が指定されていない場合、無限に続いてしまいますよね? これをどう扱ったらいいのかが全然分かっていません。今回、除外日を設定できるようにしたため、除外日を Array にして Array#include? でチェックしているのですが、Array で無限なんて扱えないですよね。
実際には Vpim::Icalendar がイベントの日時情報を DateTime ではなく Time で扱っているため、2037年問題に引っかかって有限の配列を取得することができているのですが、本当に無限のものを扱いたい場合は全部を計算で扱う Array 以外の何かが必要になるんじゃないかと思っています。とにかく動くものを作りたかったのでその辺突っ込んで調べてませんが。
またこのため Time の ArgumentError を rescue してそのまま知らん顔するという暴挙に出ています。こんなんじゃいかんよなぁ。limit を設けるようにした方がいいのか、Icalendar に戻した方がいいのか。Icalendar は DateTime で扱っているので少なくとも 2037年問題には引っかからなそうなのですが。Icalendar にこの include?( date ) みたいな便利メソッドがあれば Array に展開することなく処理を続けられるのかな。ただ、実際にはどこかで区切らないと処理が終わらないのでどっちみち limit は要るのか。
Icalendar は Icalendar で to_ical がマルチバイト文字列をぶった切る問題があるしなぁ。ふーむ悩ましい。
何かご存知の方はツッコミください。
TODO とか
slide オプションをコマンドラインからも与えられるようにするslide オプションで予定の前倒しもできるようにする- 土日を除外するのはもっと簡単にできてもいいような気がする
げ。
*atonce をコマンドラインから与えられるようにする><
参考
- http://icalendar.rubyforge.org/
- vPim - vCard and iCalendar support for Ruby
- RFC 2445 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)
2008-12-04 追記
前のエントリのツールも一緒に checkout できるようにしました。手軽に cat できるなら月水金カレンダーとかでも割とすぐ作れるので、こっちで頑張りすぎる必要ないかなぁという気がしてきました。
2008-12-06 [長年日記]
_ CGI を rackup してみた
Ruby は自分の大好きな言語だが、実は長く運用する Web アプリを Ruby で書いたことはない。cgi.rb の評判はずいぶん前から芳しくないし、決定打となるフレームワークの不在が長く続いたこと、すでに PHP を使っていたことが大きな理由だった。
Rails が登場した。勉強した。「うーん、なんか DBMS とか要らないんだけど、どうしたらいいのよ?」と思っているうちに世間ではすっかり定着、代わりに自分の中では興味は薄れていった。そうこうしているうちに Rails の問題点もちょこちょこ指摘されるようになり、prototype.js とともに先駆者ゆえの苦難を味わっているなぁと感じている今日この頃。
Merb だなんだと言われていた中、Rack が登場した。これだ!と思った。こういうシンプルなやつが欲しかったんだよ! しかしそれから特に何の理由もないまま一年半の月日が流れた。なんかこんなんばっかだな。RSS の登場により情報の収集は速くなったけど、知識にするための時間、手を動かして「つかむ」までの時間は、自分という人間の性能が変わらない*1のでちっとも短くならない。
そんなオレ語りはどうでもよく、今回はようやく自分で Rack を使ってみましたよというお話。しかも、あんまり見ない、WEBrick と CGI の二本立て。試したのは gem で入れた rack 0.4.0
Rack の使い方は二段階ある
超簡単なチュートリアルを読んでもリファレンスを見てもこの違いを明確に意識することができなくて苦労した。Rack の機能には以下の二段階がある。
- Handler によってアプリケーションサーバの違いを抽象化する
- rackup によって便利なミドルウェアを使う
この違いは
- ruby から直接 Rack::Handler::FOO.run( App.new )
- rackup から run( App.new )
の違いからくる。要するに
ミドルウェアを use したければ rackup しろ
ってこと。
逆に言うと rackup しなくても Request, Response の抽象化は行えるので基本的なことはできる。
ではそれぞれの方法をもう少し詳しく見てみる。
※ ブコメいただきました。ミドルウェアの中にアプリケーションを突っ込んで、ミドルウェアを Handler に渡すという方法もあるようです。なんかちょっと不思議な感じもしますが、そもそも内部ではミドルウェアでアプリケーションを再帰的に wrap する構造のようです。
lib/rack/lobster.rb at master from chneukirchen's rack ― GitHub
ruby から直接 Handler を呼ぶ方法
WEBrick の例
komagata さんの記事から拝借。
ウノウラボ Unoh Labs: RackでWebアプリのWebサーバー依存を無くす
#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
end
end
Rack::Handler::WEBrick.run HelloRack.new, :Port => 3000
この hello-rack.rb を
ruby hello-rack.rb
で起こし、これにブラウザからアクセスすると
Hello, Rack
と表示される。うむ。
CGI の例
同じことは CGI でも当然できる。
#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
end
end
Rack::Handler::CGI.run HelloRack.new
こんな感じで Handler を CGI にしてやれば ok. これを
- Web サーバ配下の CGI の実行可能なディレクトリに置いて
- 実行権限を付けて
ブラウザからアクセスしてやるとさっきと同じように
Hello, Rack
と表示される。めでたしめでたし。
これで cgi.rb を使わなくても Ruby で CGI を書けるようになったよ!
(CGIAlt があるとか言わないでね。)
気をつけなきゃいけないこと
以下は自分のためのメモ
- CGI の場合は Web サーバがアプリケーションを勝手に起こしてくれるけど、実行権限の付与が必要
- WEBrick(など)の場合は自分でアプリを起こしてやらないといけない
自分の場合は生 CGI を触る機会が減っているので実行権限の付与をしょっちゅう忘れる。
でも Rack の本当の威力を味わうなら rackup
rackup は
rackup -s webrick [config file]
などとして server(handler) を指定してアプリケーションサーバを起動する。rackup が行われると、中で
Rack::Builder
がアプリケーションサーバの環境を作ってくれ、自分の書いたアプリケーションはこの中で実行される。
ここで初めて use が使えるようになる。
もうちょっと細かく見てみよう。
use は Rack::Builder の instance_method
Rack でミドルウェアを追加する use は Rack::Builder の instance_method となっている。
irb(main):001:0> require 'rack' => true irb(main):002:0> Rack::Builder.methods.grep( /use/ ) => [] irb(main):003:0> Rack::Builder.instance_methods.grep( /use/ ) => ["use"]
つまり
require 'rack'
しただけでは use は使えない。
rackup の流れ
rackup を読んでみると、アプリケーションは rackup の中で以下のように実行されている。(詳細は端折ってある)
Rack::Builder.new {
run inner_app
}
つまりそういうこと。Rack の便利機能を使いたければ rackup すべし。
では実際に rackup してみる。
WEBrick の例
直接起動で use の使えない様子
さきほどの hello-rack.rb に use を加える。
#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
use Rack::ShowExceptions
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
end
end
Rack::Handler.WEBrick.run HelloRack.new, :Port => 3000
すると、当然ながら
$ ruby hello-rack.rb hello-rack.rb:6: undefined method `use' for main:Object (NoMethodError)
怒られる。use なんて使えない。
rackup してみる
#! /usr/bin/env ruby
require 'rubygems'
require 'rack'
use Rack::ShowExceptions
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
cho_www
end
end
run HelloRack.new
ここで注目してほしいのは、
- cho_www という syntax error をアプリケーションの中に仕込んであるところ
- run の呼び方を変えたところ
どうも
rackup するときは Handler は外から(rackup の -s オプションで)指定してあげた方がなんかうまくいく感じ。
これを hello-rack.ru の名前で保存し、
rackup -s webrick -p 3000 hello-rack.ru

で実行。
ご覧のようにブラウザ上に Exception を表示できる。画像では端折ってあるが TraceBack も表示できる。当然のことながら cho_www を削除すれば普通に動く。
CGI の例
直接起こして use してダメなのはさっき WEBrick で見たので省略。
rackup する
ru ファイルはさっき用意した hello-rack.ru をそのまま利用。CGI の方は以下のようにする。
#! /bin/sh /opt/local/bin/rackup hello-rack.ru

パスが /opt/local/bin なのは MacPorts で入れた Ruby で gem を使ってインストールしているから。rackup のパスは適宜調整すること。
これを hello-rack.cgi の名前で保存、ごにょごにょしてブラウザからアクセスしてみる。画像の中の URL の違いに注目。確かに CGI で動いている。
ただし、当然のことながら CGI で rackup するのは負荷的には不利。
従来の流れ
- shebang から Ruby を起動
- 自分自身を読み込ませる
rackup 時の流れ
- shebang で sh や他のインタプリタから
- rackup コマンドを呼び出し
- そこから ruby が呼ばれ
- アプリケーションがロードされる
という長い道のりを要するようになってしまう。でもメリットでかいし。
わざわざ別プロセスの rackup から起動しなくてもいんじゃね?と思いたいのは分かる。自分も思った。でも結局 rackup と同じとまではいかないまでも似たような流れで Rack::Builder を呼んであげなきゃいけないので、Rack に頼るうまみが薄れちゃうよね?と思うのでそういうことはしないことにした。
まとめ
何はともあれ、Rack の基本的な使い方は分かった。map とかは分かってないけど、これで
- WEBrick で開発
- とりあえず CGI で deploy
- 負荷的にまずいので FastCGI にしましょうか
といった柔軟な運用が可能になった。
よしよし。
参考
*1 というか加齢とともに落ちる一方だぜ! オレは10代の若者じゃねぇ!
2008-12-18 [長年日記]
_ Capistrano は思ったよりシンプルで思ったよりすごい
システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な(らしい)Capistrano についてです。紹介? いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。
システム管理の話なのになんで Puppet じゃないの?と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。
で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない?と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。
なお、例によって嘘書いてる可能性があります。識者のツッコミお待ちしております。
Capistrano の動作に必要なのは Ruby と ssh だけ
- Puppet は daemon をいくつか用意してやる必要があります。
- https を使ってくれるので fw friendly ですが、それにしたっていろいろ準備が必要です。
- Capistrano の準備で大事なのは以下の2点だけ。
- Capistrano*1 をセットアップする1台のマシン
- 管理される方のマシンには sshd と作業用の ssh アカウント
しかも Puppet と違い C/S 方式ではないため、Capistrano のセットアップが必要なマシンは1台だけです。
なんか、ちょっとお手軽な感じがしませんか。
Capistrano 自体は Windows でも動く
依存している gem パッケージは以下の通り。
$ gem dependency capistrano Gem capistrano-2.5.3 net-ssh (>= 2.0.0, runtime) net-sftp (>= 2.0.0, runtime) net-scp (>= 1.0.0, runtime) net-ssh-gateway (>= 1.0.0, runtime) highline (>= 0, runtime) echoe (>= 0, runtime)
あと echoe がこんな感じ。*2
$ gem dependency echoe Gem echoe-3.0.2 rake (>= 0, runtime) rubyforge (>= 1.0.0, runtime) highline (>= 0, runtime)
ext なライブラリはないので Capistrano 自体は Windows でも動かせます。*3自分で実際に確認はしてないですけど、動かしている例は探せばすぐ見つかります。
ただ管理対象は ssh でなんでもできる Un*x 系システムじゃないと Capistrano の利用に旨味はないでしょう。
要するにできることは ssh HOST COMMAND
ssh は interactive な login shell を提供するだけではなく、
ssh HOST COMMAND
の形で
HOST に接続して COMMAND に書かれた処理を実行して終了する
という使い方もできます。大雑把に言うと Capistrano はこの機能をより便利に使うために
- 接続先の管理と接続の自動化
- 接続先と作業内容のセットをタスクで管理
- タスクの実行
を提供してくれるものです。そして
そのために Rake を使う
ようになっています。
deploy ツールとして紹介されることの多い Capistrano ですが、それは deploy 用のタスクがあらかじめ定義されていて、変数をセットするだけで便利に使えるようにしてあるからであって、
タスクを用意すれば ssh でできる仕事はなんでもできます。
たぶん。
ただし、Puppet と違い、接続先のサーバ OS の抽象化などは行ってくれないため、基本的にその部分は生で相手しないといけません。逆に Puppet のように独自文法の習得を要求しません。
ということは従来の方法からの移行コストが小さい
まともな管理者なら、サーバ上のたいていの作業は sh や Perl、Ruby などのスクリプトである程度自動化されていると思います。これが cron ジョブとして管理できるなら手作業はずいぶん減っているはずです。ただ、
完全に定期実行になっていない作業
も中にはあるでしょう。その場合、しぶしぶ個々のサーバにログインしてスクリプトを実行していませんか? 恥ずかしながら自分はそうです。しかし Capistrano を導入すれば
最後の「ログイン -> 実行」の部分を自動化、管理できます。
そうです。個々のサーバの管理方法を大幅に変える必要はありません。「ログイン -> 実行」という、最後に残った手作業部分を Capistrano のタスクとして管理できるようになるだけなのです。しかもサーバ側は基本的にいじる必要がありません。
これが複数のサーバ上の作業なら目に見えて楽になりますし、サーバの数がそれほど多くなくても
一定のワークフローを保証しやすくなります。
つまり
管理作業の共有、引き継ぎを楽にしてくれます。
もちろん独自タスクの管理のためには Ruby と Rake への理解を要求するので、楽になる一方ではありません。しかも Rake も Capistrano もそんなにドキュメントが充実しているわけでもありません。しかし、スクリプトを書いて自動化して、手作業によるミスを減らせるようにしてあるはずなのに、なんとなく属人的な作業が残っちゃう部分があって、なんか気持ち悪いなぁと感じているような場合には Capistrano の導入は十分に検討の価値があるんじゃないでしょうか。
超簡単な例
えーと概念の話からインストールの方法をすっ飛ばしていきなり実例に入ります。*4
カレントディレクトリに以下のような内容で Capfile という名前のファイルを作ってください。ここでログイン先のサーバのユーザー名、パスワードは一致しているものとします。
role :server, 'server1, 'server2' set :user, 'user' set :password, 'password' desc "reporting disk usage with 'df -h'" task :check_disk, :roles => :server do run 'df -h' end
で
cap check_disk
と実行すると
* executing `check_disk' * executing "df -h" servers: ["server1", "server2"] [server1] executing command [server2] executing command ** [out :: server1] Filesystem Size Used Avail Use% Mounted on ** [out :: server1] /dev/xvda1 32G 24G 7.2G 77% / ** [out :: server1] tmpfs 201M 0 201M 0% /dev/shm ** [out :: server2] Filesystem Size Used Avail Use% Mounted on ** [out :: server2] /dev/mapper/XXX 17G 14G 2.1G 88% / ** [out :: server2] /dev/xvda1 99M 27M 67M 29% /boot ** [out :: server2] tmpfs 181M 0 181M 0% /dev/shm command finished
みたいな結果が得られます。つまり、server1, server2 にログインして実際に df -h した結果をそのまま、Capistrano をインストールしたマシン上で確認できたということです。
どうです、なかなか面白くないですか。
情報収集が楽になるはず
これはちょっといきすぎてるかな?と思わなくもないのですが、cron ジョブの実行を Capistrano マシンに集中させることも可能ですね。こうすると
- 個々のサーバで crond が不要
- cron ジョブのレポートメールを Capistrano マシン上に集約可能
- cron ジョブの様子を一カ所で確認できるので、スケジュールを考えやすくなる
というメリットがあります。もちろんデメリットや不安材料もあって、
- ssh login のコスト
- 長い時間掛かる仕事をさせたときの ssh connection はどうなる?
なんかが気になるところです。まだ見落としてることもあるかもしれません。
cron のレポートの受け取りが面倒くさい
ただ、cron はレポートのメールの受け取りが面倒だなと以前から感じていたので、この問題を解決しやすくなるとしたらとても嬉しいです。というのも、cron のレポートは基本的にローカルのアカウントにメールされるのですが、
どうやって読むの?
という問題がつきまといます。今思いつくのは
- 個々のサーバにログインして読む
- 個々のサーバに POP サーバ立てる
- forward する
- mail -> html -> feed 変換して feed reader で読む
くらいですかね。数が増えてくれば当然 1, 2 はナシだと思うんですが、
forward する場合、forward 先のサーバには SMTP サーバと SMTP の通る穴が必要
になります。これがまた悩ましい。メールサーバが LAN 内にあるなら LAN 内のレポートは文句なし LAN 内のメールサーバで処理すればいいです。でもインターネット向けに公開しているサーバのメールはどうしましょう? LAN 内のサーバ向けに forward ? fw で閉じてませんか? じゃあインターネット上の SMTP サーバに転送? OBP25 とかに引っかかりませんか? それにインターネット上に置いた SMTP サーバはあっという間に spam やエラーメールの嵐に飲み込まれてしまいます。すると今度は spam filter だ anti virus だ…。ふー。違うんだよ、オレはそんなことしたいんじゃないの。要するに
forward も意外に面倒なのです。
もう一つ、メールったってこんなの返信の必要もないし、みんな feed reader で読みたいなぁと以前から思っていました。実際、mail -> html -> feed 変換をしている人は見かけます。HTML にして URI が付けば内容の共有も楽です。*5しかしどうしても転送の部分がネックになります。各サーバで feed 吐いてそれpla で収集してもいいですけど、なんかそれもどうなんだと。
でも Capistrano からタスクを実行すれば、自動的に、少なくとも stdout や stderr の内容は取得できます。結果をファイルに落とすタイプでもファイルの転送が可能*6なのでそれを取得してくればオッケーです。
てことは、レポートの収集の部分は自動的にクリアしてしまいます。おう、なんかこれ面白そうじゃん。
できそうなことの一覧
クラスの一覧から一部を抜粋。
Capistrano::Configuration Capistrano::Configuration::Actions Capistrano::Configuration::Actions::FileTransfer Capistrano::Configuration::Actions::Inspect Capistrano::Configuration::Actions::Invocation Capistrano::Configuration::Actions::Invocation::ClassMethods Capistrano::Configuration::Callbacks Capistrano::Configuration::Connections Capistrano::Configuration::Execution Capistrano::Configuration::Loading Capistrano::Configuration::Loading::ClassMethods Capistrano::Configuration::Namespaces Capistrano::Configuration::Namespaces::Namespace Capistrano::Configuration::Roles Capistrano::Configuration::Servers Capistrano::Configuration::Variables Capistrano::Deploy Capistrano::Deploy::Dependencies Capistrano::Deploy::LocalDependency Capistrano::Deploy::RemoteDependency Capistrano::Deploy::SCM Capistrano::Deploy::SCM::Accurev Capistrano::Deploy::SCM::Accurev::InternalRevision Capistrano::Deploy::SCM::Base Capistrano::Deploy::SCM::Base::LocalProxy Capistrano::Deploy::SCM::Bzr Capistrano::Deploy::SCM::Cvs Capistrano::Deploy::SCM::Darcs Capistrano::Deploy::SCM::Git Capistrano::Deploy::SCM::Mercurial Capistrano::Deploy::SCM::None Capistrano::Deploy::SCM::Perforce Capistrano::Deploy::SCM::Subversion Capistrano::Deploy::Strategy Capistrano::Deploy::Strategy::Base Capistrano::Deploy::Strategy::Checkout Capistrano::Deploy::Strategy::Copy Capistrano::Deploy::Strategy::Export Capistrano::Deploy::Strategy::Remote Capistrano::Deploy::Strategy::RemoteCache
いやーこうして見ると Deploy の充実っぷりがやはりすごいですね。Mercurial や Bzr なんて文字も見えるので、これらを使った deploy もできるんでしょう。
使えそうなリソース
Capistrano 自体が github でホスティングされているためか、github で検索するといちばんたくさん引っかかるようです。
- Capistrano 入門 - Ruby on Rails with OIAX
- まとまって日本語で読めるのってこれくらい?
あとはシステム管理系のレシピが載ってそうなところとか。まだあんまちゃんと見てないですけど。
- deprec - Trac
- sauliusgrigaitis's centostrano at master ― GitHub
- → ‘capitate’: Capistrano recipes, plugins and templates.
- vigetlabs's capistrano_rsync_with_remote_cache at master ― GitHub
- capistrano-mailer - Google Code
- Capistrano 2.1向けのAPTレシピ : \ay diary
- Andrew Beacock's Blog: A Capistrano recipe for restarting Apache 2 (on Linux)
- CapistranoでタスクをDRY化したいときは Capistrano.plugin が便利 - 半隠遁日記
最後に。
みんな、実際に試してオラにやり方を教えてくれ!
*1 当然、Ruby も必要
*2 これ recursive に取れないのかな? もしかして使ってる gem が古い?
*3 公開鍵認証を利用するための鍵作成には Putty などの ssh クライアントがたぶん必要です。
*4 実際、rubygems さえ動いていればインストールはそれくらい簡単です。
*5 例えば管理用のメールを複数人で受信していて、何か気になるアラートがあったとします。この情報を共有したいわけですが、メールを一意に特定するのは Message-ID です。しかし Message-ID の確認や検索の容易なメーラーは寡聞にして知りません。
*6 やり方はまだ分かってません!
_ Johann [大変分かりやすいです。参考にさせていただきます。]