Automatic Ruby v12.6 をリリースした

※この記事はすでに内容が古くなっています。こちらをご覧ください。

Automatic Ruby v12.6 をリリースした。日にちが経つと忘れるので今のうちにいろいろ書き留めておく。

使ってみる

いつも通り日本語ドキュメントに詳しくは書いてるけど、とりあえず安定版を入れるなら以下の通り。

で処理を起動できる。

レシピの仕様は特に変わっていない。具体例を挙げると以下の通り。コピペすればそのまま動く。

automatic-config scaffold コマンドを実行するとホームディレクトリに ~/.automatic というディレクトリが生成される。この下はユーザー用のディレクトリであり自由に使うことができる。

-c オプションでファイル名のみをした場合 ~/.automatic/config に同名のファイルがあればそれが読み込まれる。データベースを使うタイプのプラグインは ~/.automatic/db の下にデータベースファイルを生成する。自作したプラグインは ~/.automatic/plugins 配下に配置することで本体同様に読み込まれる。

開発版を動かす場合は以下の通り。

この script/bootstrap と script/build は Ruby Patterns from GitHub's Codebase に影響を受けて見よう見まねで真似したというかパクったものである。詳しくは以下のプレゼンの前半部分を参照。

Ruby Patterns from GitHub's Codebase

script/build は CI 用のスクリプトで、オプション無しで実行すると RSpec を全部実行、 all を付けるとさらに結合試験 (test/integration 配下) もすべて実施する。

なんとなく格好いいので Rails でアプリケーションを開発する時には導入している。ちなみに RSpec のためのヘルパーや Rakefile なんかも毎回そうしているので、どうせなら最初から Rails のデフォルトにしてほしいものである。

テストとコードカバレッジ

今回のリリースでは RSpec のコードカバレッジ率を 100% にすることを目標として RSpec を書いた。異常系を除いて一応全体を網羅し 99% 以上は達成したのであるが、テストケース自体がふさわしいかと言うとなんとも微妙である。また RSpec らしさを出したテストになっていない気がするのでこのあたりは The RSpec Book 等を読んできちんと書けるようになりたい。あと独自のマッチャを定義して簡易に記述できるようにしたい。たとえばこのブログ記事にあるように instance_variable_get をマッチャにするとか。このへんの独自マッチャをみんなどんな命名規則でどんな感じに作り込んでいるのだろう。

v12.6 での仕様変更

v12.4 から v12.6 までに文字通り 2 ヶ月程度経過している。とはいえ、実際にコミットしたのは数日だし、実作業時間はせいぜい 10 〜 20 時間程度だろう (ちゃんと計測していない)。前回のリリースから今までにコミットしたのは自分一人なので、主に仕様が曖昧だった部分を明確にしようとコードを書いた。

まず、 ChangeLog には明記されていないが、そもそもこのフレームワークの要である @pipeline の扱いが変わったことが大きい。いままではフィードを格納する前提だったが、何を格納しても良いこととした。たとえば Subscription::URI は HTML を @pipeline に放り込んで後続に渡す。これにより、レシピ内で書いたプラグインの前後でデータの互換性が保たれていなければならないことになった。なんでもフィードにする Plagger とは全く異なるソフトウェアになったことになる。プラグインの互換性を気にしないといけないことでプラガブルなフレームワークと言えるかどうかは謎だが、なんでもフィードにしないといけないという制約には縛られないことになる。つまりどんな用途にも使えることになる。

v12.4 では不完全だったユーザーディレクトリの扱いも改善された。そもそも gem でインストールした場合、パッケージルートの db ディレクトリを見にいくので問題があった。そこで v12.6 では scaffold 時に ~/.automatic/db ディレクトリを作成するようにした。ついでに ~/.automatic/config も作成して、ユーザーのファイルはすべて ~/.automatic 配下に置くことを前提とするようにした。これもまだ改善の余地があって ~/.automatic/config になんでもレシピを置くと見通しが良くないので、 config の下にサブディレクトリがあればそこも読みに行くようにしたい。ファイル名の重複の場合をどうするかなど考慮する必要がある。

今回追加したプラグイン

既存の部分でも色々と改善したいところは多い。まずは今回追加したプラグインについて。

Subscription::URI
これは要するに open-uri で HTML を取得するだけのプラグインである。しかし URL は config でしか指定できない。そこで Subscription::Feed でフィードをチェックし、新しいパーマリンクがあればその URL を後続のプラグインで HTML を取得、さらに後続に渡す、といった処理をしたい。それができると Plagger の Entry::FullText みたいなことができるであろう (多分)。

Extract::Link
HTML から nokogiri で a リンクを抽出するだけのプラグインである。抽出する条件を config で指定可能とするなどして、もう少し nokogiri の汎用性を引き出したいものである。

Filter::ImageLink
特定の拡張子のリンクを選択するプラグイン。条件を config で指定できるようにすると汎用的であろう。

Store::Database
kzgs さんによって DB ハンドリングの部分を共通化していただいたモジュールで、これだけ他と少し違う位置付けになっている。いまは決め打ちで sqlite3 を使うこととなっている。 config でアダプタを指定可能にできたら良いだろう。

ドキュメント
OSS の世界はソースがドキュメントという文化があるだろうしそこまで求められていないだろうけどドキュメントはやはり重要だと思う。特に英語がほとんど機械翻訳を通しただけのひどい状態なのでこれもなんとかしたい。英語に精通した人に修正コミットして欲しいところである。もちろん日本語のほうもお世辞にもちゃんとしているとは言い難いが。

環境
global セクションが全然生かされていない。たとえばログメッセージの出力レベルや、時刻のタイムゾーンなど global セクションで指定したものが反映されるようにしたい。

Automatic::Pipeline
欲を言えばクラスをきちんと定義して、オブジェクトを格納する形にしたい。利用用途にあわせてクラスを定義して、どんなインスタンスでも格納できるようにしたら良いのではないだろうか。

実現したい機能
HTML 全体を取得し、なんでも加工可能ということは、かなり適用範囲も広がるはずである。まず基本的な機能として HTML をメール送信したり、保存したりするプラグインがあると良いだろう。それ以外にも HTML を料理するあらゆるバッチを Automatic Ruby に移植できるはずである。

業務系のバッチを Automatic Ruby で実行するのも現実的である。バッチで実行できる内容で、なおかつシビアな効率を求められないものなら適用の可能性がある。たとえば rsync のオプションを組み立て実行するプラグインを書いて Automatic Ruby でデータを毎日自動バックアップするのも良いだろう。

録画や BitTorrent でのダウンロードに Automatic Ruby を使うのも良い。EC2 とか virt-manager の仮想マシンをあれこれするプラグインとか、システム管理や監視系もおもしろそうである。まあ要するに何でもできるので何でもこれでやりたい。

複数人での開発の難しさ
そもそも言い出しっぺが何を意図してどこを目指して開発しているのかを伝えるのがいかに難しいかというのをこの開発を通して感じた。会社内等であれば意識の統一はしやすいであろうが、オープンソースソフトウェアを公開して開発する場合、言い出しっぺの意図を汲み取りにくいし、結果的に人々が無秩序に開発していった場合に方向性をうまくコントロールするのは難しい。Twitter は簡単だけど技術者以外もいる場所であり、技術的な議論は避けたい (そもそも議論に向いてない) 。 Skype や IRC は個人的に好きじゃないのだけど、利用したほうが良いのだろうか。せめて ML や掲示板くらい用意するべきか。

最初にこのブログ記事を書いて、特にテストまわりでは kzgs さん、 ainame さん、 hsbt さんといった方々にコミットしていただいた。他にもいろいろな方にプラグインを作っていただいたりしたので大変感謝している。この場を借りてお礼を言いたい。

テストまわりはおかげでだいぶ充実したと思う。

開発に参加する

試しに Subscription::URI などの簡単なプラグインを読むと良い。見ての通り、わずか数行程度書けばプラグインを実装することができる。 RSpec は既存のものを流用すれば楽だろう。プラグインの追加、テストの追加、互換性を損なわない変更であればなんでもウェルカムである。既存部分の変更も大体の人は自分より優れたプログラマだろうから積極的に欲しい。プラグインの雛形を生成するジェネレータがあったら便利だろうか。

Automatic Ruby は Windows で一切テストをしていない。そこで Windows での動作確認、及びもし修正があれば pull request をいただけるとありがたい。それ以外にもメジャーな GNU/Linux 以外での動作報告があればそれだけでも助かる。

コードをあらかじめレビューしたいので、できるだけ変更は pull request で欲しい。簡単な修正なら直接コミットで良いけれども。ところで GitHub で pull request されたコードのレビューやテストってみんなどうやっているのだろう。更新部分を取り込んで別途テストしているのだろうか。マージしないと CI にも回せないと思うし、レビューをどうやっているのかといった話もぜひいろんな人から意見を聞いてみたい。

次のリリースへ

思うままにつらつらと書いてみたけどこんな感じである。このあたりの話を整理して Issues にして、次のリリースに向けて開発したい。ちなみにリリースは不定期だが Ubuntu の真似をして年月のバージョン番号を付与するものとする。