カテゴリ別 2003年 | 2004年 | 2005年 | 2006年 | 2007年 | 2008年
知り合いサイト: よんだもの / 暴想 / Linuxでやる夫 / 新宿Vipper / 僕だけが幸せになればいいのに。
libcsv が 1.0.0 になったのに合わせて少し手直ししました（先週の金曜日に）。使い方は変わりません。
以下メモ。
libcsv 1.0.0 の変更でコールバック関数に任意のデータを渡して情報共有できるようになったので、Ruby の拡張ライブラリのインタフェイスを libcsv のそれと合わせることができそう。self をコールバック関数に渡して、インスタンスに保持させた proc を call すればいいわけですし。でも、メソッドの引数で proc を二つ渡すようなインタフェイスのライブラリはあんまり使いたくないですね。せめてテンプレートメソッドパターンにしようかな。
とりあえずクラスメソッドの parse/write は残しつつ、インスタンス生成して parse メソッドを呼ぶこともできるようにしようと思います。
2006/08/25 に Ruby 1.8.5 がリリースされてから半年弱ですね。
NEWS で変更の詳細が確認できます。個人的には、
辺りが大きな変更かなと思います。
* date * Updated based on date2 4.0.3.
とありますように、標準添付ライブラリの date のバージョンが変わりました。その影響で Rails の行っている Date クラスへの拡張がぶつかってしまい、ActiveRecord::Base#create などで NoMethodError になる問題が報告されています。
Rails 側では 1.8.6 に対応した Rails 1.2.3 をリリースするとしています。一方、Ruby 本体側は、NEWS ファイルを更新して errata を告知する予定とのことです。
それにしても Rails な人たちは誰も 1.8.6 の preview を試してなかったんですかねえ。
REST と ActiveResource の考えについての資料を公開しています。シンプルで分かりやすいですね。
BlueCloth は Ruby 用の Markdown ライブラリです。使っていて不思議に思ったのがリストの扱い。番号付となしを続けて記述した場合には以下のように HTML 化されます。
$ ruby -rbluecloth -e 'puts BlueCloth.new(<<_EOL_).to_html
1. first
2. second
- 3rd
* 4th
+ 5th
_EOL_
'
<ol>
<li>first </li>
<li>second</li>
<li>3rd</li>
<li>4th</li>
<li>5th</li>
</ol>
$ ruby -rubygems -e 'require "bluecloth"; puts BlueCloth.new(<<_EOL_).to_html
* first
* second
1. 3rd
2. 4th
3. 5th
_EOL_
'
<ul>
<li>first </li>
<li>second</li>
<li>3rd</li>
<li>4th</li>
<li>5th</li>
</ul>Markdown の仕様なのか BlueCloth の実装依存なのかどちらなのでしょう。
SimpleCSV 0.1.3 をリリースしました。サブクラスでコールバックメソッドを定義することでパースの挙動をカスタマイズできるようになりました。
class PrintFirstLetterParser < SimpleCSV
def on_field(str, pr)
print "#{str[0, 1]} "
end
def on_row(str, pr)
end
end
PrintFirstLetterParser.new.parse(<<_CSV_)
first, second, third, fourth, fifth
_CSV_
#=> f s t f f on_field と on_row の第二引数は parse メソッドに渡されたブロックです。デフォルトの挙動を再定義すると以下のようなコードになります。
class DefaultParser < SimpleCSV
def initialize
@row = []
end
def on_field(str, pr)
@row << str
end
def on_row(str, pr)
pr.call(@row)
@row = []
end
end個人的にはデフォルトの挙動で十分なのでこの部分のテストが不十分という罠。
eban さんがdel.icio.us の rss を Yahoo! Pipes でフィルタリング したというのを読んで私もやってみることにしました。
大まかには
Pipe 作成を細かく説明しますと、
Pipe を作った後は Back My Pieps で戻って、作った Pipe を Run this Pipe して実行しないといけません。Run するとプレビューと RSS や JSON へのリンクが表示されますので、それを Bloglines に登録して終わりです。
出力される RSS は元の RSS にあった、dc:creator や dc:subject が抜け落ちているのでちょっと微妙です。この辺は制御できないのでしょうか。
2007/03/25 追記。Puppet の情報がほしい方はmizzy.orgを読むべし。Linux カテゴリの記事を順に読むのがおすすめ。
タイトルは(ry
OSC2007 のセミナーオープンソースによるシステム管理の自動化 の 発表 で、cfengine に代わる次世代のシステム管理ツールとして puppet が紹介されたとのことです。
新規サーバの構築や運用中のサーバの監視は結構手間のかかる作業です。しかし、新規サーバの投入頻度がそう多くなかったり、障害の発生頻度が低かったりすると、その場その場での人手の作業に頼りがちです。専任の担当者がおらず、開発から運用までまとめて面倒を見ているとなかなか手が回らない箇所です。後者のケースの方が自動化を必要としているにも関わらず。
私の職場の場合は、アプリケーションサーバ構築に cfengine、運用ツールとして capistrano を使っています。導入前に比べると属人的だった作業が手順化・ドキュメント化され、チームメンバーの誰でもできる作業になりました。
cfengine もまだ使いこなす域には達していませんが、より良いツールがあるのなら使ってみたくなるのが人の性です（あと Ruby 製なのが個人的にポイント高し）。
ディストリビューション側での puppet 対応も進んでいるというのことですし、徐々に広まっていくのではと思います。まだ日本語のリソースはほんとどありませんが、いくつか関連リンクを挙げておきます。
追記:タイトルに色々誤字があったので修正しました。。。
Ruby初心者スレッド Part 10 と Ruby初心者スレッド Part 11 でメソッドの出口はひとつにしたほうが良いか？という話題が出ています。
結論としては、不用意に call/cc を使ったり例外以外に例外処理を使ったりせず、またメソッドのやる仕事が適切であるならば、読みやすさのために出口を複数にしても良いと思います。また、「出口はひとつ」は「そうできる」といっているだけで、「そうしなければならない」ということではありません。
メソッドの出口が複数であることを気にするよりも前に、メソッドが長すぎないか、条件分岐が不適切で流れがわかりにくくなっていないか、メソッドとして抽出できる部分が存在しないか、ローカル変数がその役割を把握できる名前になっているかなどを気にするべきです。また、例外やガード節を導入すると大抵出口が複数になりますが、エラー処理とメインロジックを分離してコードの見通しをよくするメリットを捨てるべきではありません。
以下長文。読まなくても構いません。
この「出口がひとつ」というのは、構造化プログラミングに由来します(構造化プログラミング)。正確には Boehm と Jacopini によって 1966 に証明された構造化定理です。構造化プログラミングについて簡潔にまとめているサイトがありましたので、構造化定理の部分を引用させていただきます。
全てのプログラムは、一つの入口と出口を持つ形（適正プログラム）に等価変形可能であり、適正プログラムでは任意のアルゴリズムを次の三つの基本的な制御構造で記述できます。
- 順次(Sequence)
- Javaでは、セミコロン区切りの命令（ステートメント）を列挙した構造。
- 選択(Selection)
- 条件式の結果に応じて実行するブロックを変更する条件分岐構造。Javaでは、if文、switch文、try文をサポート。
- 繰り返し(Iteration)
- ブロック内部を繰り返し実行するループ構造。Javaでは、do文、while文、for文をサポート。JDK 5.0では拡張for文を追加。
変換可能といっているだけで、そうしなければならないといっているわけではないことが分かります。制御構造 - Wikipedia : 必要最小限の構造化制御フローによれば、「他の研究により入り口と出口がそれぞれひとつになっている制御構造が他の構造よりも理解し易い」とあるように、プログラムの構造を把握しやすくするのが目的です。守ることで分かりにくくなるなら本末転倒でしょう。
余談ですが当時のプログラミング言語の状況を知るとなぜこのような定理が提唱・証明されたかが分かります。プログラミング言語年表 によれば、1966 年までに開発されている主要な言語には FORTRAN、COBOL、LISP、BASIC などがあります。これらの言語は今も使われていますが（一度広まった言語は非常に息が長いですね）、当時のままではありません。構造化プログラミングが提唱される前に開発された言語なので、あとから構造化プログラミングをサポートする機能を追加しています（LISP は別として）。例えば FORTRAN の JIS 仕様の変遷を読むと時代の流れに合わせて自由プログラム形式やオブジェクト指向などを取り入れていることが分かります。また、Microsoft の BASIC 製品の変遷は MS-BASIC → QuickBASIC → Visual Basic → Visaul Basic .NET といったところですが、同じ BASIC の名を冠していてもそれぞれほとんど別物といえます。当時の言語では困ることがあったので構造化定理が提唱されたり、それに基づいて言語に機能が追加されたわけです。
若い人たちはもう知らないかもしれませんが、昔 NEC の PC-8801/PC-9801 シリーズには N88-BASIC という BASIC 処理系が搭載されていました。IF 文や FOR 文といった制御構文が言語に含まれていましたが構造化プログラミングをするのに十分だったとはいえません。BASIC - Wikibooks : 条件分岐にあるように古い BASIC では IF 文を一行で書かなくてはならないため、複数行にわたるものを実行したい場合には GOTO で別の場所に飛ばす必要がありました。また、プログラム一行一行ごとに行番号が必要であること、GOSUB 命令はあるがサブルーチンに名称は付けられず行番号を指定するといったところから、プログラムを部分に分けるという手法へのサポートが希薄なことがわかります（そういう考えが現れる前に作られた BASIC の仕様を踏襲しているので当たり前ですが）。
構造化定理が提唱された当時は GOTO 文が多用されたプログラムが蔓延していたようです。制御構造を使うことでもっと読みやすく書きやすいプログラムになることは実感として明らかですが、GOTO 文の代わりに（GOTO 文よりも自由さが制限された）制御構造を使ったとしても同じ機能を実現できることを証明する必要があったのだと思います。
Ruby は構造化プログラミング、オブジェクト指向プログラミングを言語仕様でサポートしています。Ruby プログラムとして適切なプログラムを書いていれば、最低限かもしれませんが構造化プログラムあるいはオブジェクト指向プログラムといえます。つまり、if/case/for/while といった制御構文の利用や、メソッド、クラスの作成を行えば、そうしないよりは構造化/オブジェクト指向プログラムといえるだろうということです。構造化定理当時のプログラムを読んだことはありませんが、N88-BASIC でプログラムを書いた経験からすると、平均してそのころの基準からすればはるかに洗練されて読みやすくなっています。構造化プログラミングは十分下地として浸透していると思いますので、GOTO 文不要論も含めて金科玉条のように守ろうとする必要はないんじゃないかなと思います。
タイトルは(ry
redMine は rails 製のプロジェクト管理＆問題追跡(issue tracking) システムです。redMine のサイトの OverView に特徴が挙げられていますのでいくつか紹介します。
オンラインデモ を触ってみると分かりますが、trac と機能的に重複するものが多く trac を意識して開発されていると感じます。一方で上に特徴として挙げたように trac が弱い部分についてのサポートを積極的に行っており、非常に意欲的なソフトウェアだと思います。現在は svn 関連や wiki など trac よりも劣っている機能がありますが、trac というお手本がある以上追いつくのは時間の問題だといえます。
では、将来有望に見えるこの redMine が流行らない理由とはなんでしょうか。
それはシンプルでないことです。
オンラインデモにアクセスして、どうやったらチケットを新規作成すれば良いか分かったでしょうか？正解は以下の通りです。
trac の場合は、
だけです。ユーザ管理をしていてもアクセス時にベーシック認証が増えるくらいです。
複数のプロジェクト管理、役割ベースのアクセス制限という機能と引き換えにシンプルさを失っているのではないでしょうか。これはプロジェクトのメニューについても言えます。trac は 7 のメニューが並んでいますが、redMine は倍の 14 です。
なぜこれだけのメニューがあるのかを考えてみますと、
ためです。
ところで、この機能群を眺めていると気付くことがあります。 GForge と同じメニューがあるということです。 GForge は RubyForge などで おなじみのソフトウェア開発/プロジェクト管理システムです。
問題追跡、Wiki、SCM 連携は trac、redMine、GForge 共通して持っている機能です。 一方 プロジェクトの新着情報をアナウンスする「ニュース」、 tarball などを配布するための「ファイル」、文書を管理・公開する「ドキュメント」などは、 trac にはなく redMine と GForge には存在する機能です（trac はデフォルトで比較）。
trac が開発チーム内部での利用を前提としているのに対して、 redMine は GForge のようにユーザ（開発者ではない）の利用も視野に入れているようです（メニューみた限りではそう見えるけど思い込みかも……後で調べます）。
しかし、開発者ならぬユーザが redMine にアクセスしたときに見せられるのは開発者と同じ画面です。 ほしい最新版のプログラムをダウンロードすることが簡単にできるとは思えません。
redMine は trac よりも広い範囲をサポートするために複雑なシステムになっています。 そのため、現状のままでは trac のようには流行らないでしょう。 しかし、複雑なシステムをシンプルに見せることはできるはずです。 redMine が持っているポテンシャルを活かせるユーザインタフェイスが必要です。 redMine の行方を注意深く見守っていこうと思います。
最近のコメント：
RSS
This work is licensed under a
Creative Commons License
(note: text only. w/o web design, citations, (re)distributed softwares).
