ククログ

たのしい開発 スタートアップRuby

2012年8月に「たのしい開発をするにはどうしたらよいか」という内容の本が技術評論社から出版されました。

たのしい開発 スタートアップRuby
大場 寧子/大場 光一郎/五十嵐 邦明/櫻井 達生
技術評論社
￥ 7,356

Rubyを使ってたのしく開発できている著者たちがRubyを軸にどのように考えて開発しているかを紹介する本なのですが、だれが読むとうれしいのかが難しい本です。「Rubyに憧れを持っている人」、「Ruby界隈にどっぷりと浸かった人」が読むとうれしい本ではないでしょうか。そうではない人、例えば、「Rubyを当たり前のこととして使っている人」、「Rubyに興味がない人」などは読むと違和感があるでしょう。

この本にはRuby界隈で聞かれるキラキラした単語がたくさん詰まっています。「たのしい」、「いきいき」、「勉強会」、「DSL」。Rubyに憧れているけど、自分ではまだ動き出せていない人には、この本の内容が力強い後押しになるでしょう。「とある企業のRuby導入事例」で以下のような話がでています。憧れているだけのときは「Rubyを使うにはどうしたらよいか」視点でばかり考えてしまうでしょうが、そこを乗り越えて「このためにRubyが適しているから使う」と考えられるようになれればRubyを使える機会が増えるということを伝えています。これは「Rubyを当たり前のこととして使っている人」には普通の感覚ですが、憧れているだけの人はそこまで考えられていないことが多いので、この話が入ることでバランスがよくなっています。

まず、自分がやりたいことを言うときに「Ruby」や「Rails」と言わなくなりました。RubyやRailsはどうすごいのかということを語らずに、お客さんの課題や問題に対するソリューションという形を中心に話すようになりました。

また、この本にはRuby界隈の人の名前がよく出てきます。Ruby界隈にどっぷりと浸かった人は親近感を持って楽しく読めるでしょう。

一方、そうでない人にはなかなか難しい本です。というのは、この本全体が一貫性に欠けるからです。上記の人たちは勢いで読んでいって一貫性はあまり気にならないでしょうが、普通に読み進めていくと気になってしまいます。

例えば、この本の中では以下のようにチームで協力してたのしく開発したいという思いを伝えています。

問題をチームで捉え、チームにフィードバックしながら学び教え合うことで個人やチームはさらに大きく成長できる、そんな流れをイメージしています。そして、それはとてもたのしいことだと思うのです。

一方、Rubyの動的な性質をメリットとして紹介している部分では、動的な性質を使えば他の人と協力しなくてもよい点を挙げています。

ソースファイルを変更する権限がBさんにない場合は、Aさんに連絡をつけ、依頼して変更してもらわなければなりません。これはかなりの手間であり、時間の損失です。

また、Railsに関してはRailsの思想に従うべきだとしています。

Railsで開発を行うのであれば、Railsの思想に従うべきです。そうしないと、Railsの用意してくれた楽な道をたどることができず、各種のやりにくさに対抗しながら我が道を切り開くということになります。流れに逆らって進むようなものです。これではせっかくのRailsの良さを十分に活かすことができません。

一方、Railsの「高機能Scaffold」プラグインに関してはプラグインの思想から外れることが前提のように書かれています。

1. デフォルトの設定にない機能を追加する際は、プラグインの用意したやり方で行う必要がある。そのやり方を調べるのに時間がかかる
2. プラグインの想定外の機能追加をする際は、プラグインそのものをカスタマイズしないといけなくなり、苦労する

これはそのままRailsにも当てはまることです。おそらく、Railsとプラグインでは扱いが違うのでしょうが、その理由が明示されていないため一貫性がないと感じる原因になっています。

他にも、Rubyの名前付けの慣習がわかりやすいという説明もしています。

破壊的メソッドは概して「!」で終わる、真偽値を返す問い合わせメソッドは「?」で終わる、といった慣習があり、名前だけでかなりの情報を把握することができるようになっています。

その後、慣習ではなくルールで決めているものもあり、ルールなので他の言語よりもよいと説明が続きます。

定数名は大文字で始まる、インスタンス変数は「@」で始まるといった記法上の決まりも、名前だけで多くのことを判断でき、一貫性があって便利です^注3。

注3) JavaやC++などでは、メンバー変数を「m_」で始めるといったやり方が使われますが、これは文法上の約束事ではないため、漏れが生じたり、チームによって作法が違ってしまいます。Rubyでは@の有無に統一され、このような問題はありません。

この本は複数著者で書かれているため単一著者の本に比べて一貫性が損なわれるのはしょうがないのでしょう。ただし、全体（300ページほど）の1/3強を使ってRubyとRailsを紹介してる部分を除けばそれほど一貫性を欠かずに読み進められそうです。すでにRubyとRailsを知っている人はこの部分を除いて読むという読み方がよいかもしれません。

おまけ: 「判断基準を伝えよう。（技を）盗むのは大変。盗んでないでもっと先へ行け。」を覚えていてくれたのはうれしかったです。

「札幌Ruby会議2012のチケットを譲るキャンペーン」当選者発表

札幌Ruby会議2012をPlatinumスポンサーとして後援し、3名に参加チケットを譲ります - ククログ(2012-06-21)で告知した札幌Ruby会議2012の参加チケットを譲るキャンペーンですが、先週末が締め切りでした。応募少数のため選考は行われず、以下の3名（2012-09-03: 2名から3名に変更 2012-08-22: 3名から2名に変更 2012-08-08: 2名から3名に変更）に譲ることになりました。

• @hayabusa333

  応募ツイート: 参加が出来るのが15日からになりますが幌RubyKaigi2012に参加したいです。参加してクリアコードの皆様がたと話をしてみたいです。よろしくお願いします

• @vestige_

  応募ツイート: 札幌RubyKaigi2012に参加して、Rubyist達と遊びたいー！

• @Satoko_R

  応募ツイート: 札幌RubyKaigi2012に参加したいです!

ぜひ、札幌Ruby会議2012を楽しんできてください！

2012-09-03追記: チケットの譲り先は全部決まりました。

2012-08-22追記: なお、あと1枚チケットがありますので、今回の応募に乗り遅れた方がいれば@_clear_code宛てに応募してください。先着1名に譲ります。もし、特に応募がない場合は札幌Ruby会議2012実行委員会に返すなど別の形で有効利用できないか検討する予定です。

2012-08-08削除: チケットの譲り先は全部決まりました。

2012-08-08削除: なお、あと1枚チケットがありますので、今回の応募に乗り遅れた方がいれば@_clear_code宛てに応募してください。先着1名に譲ります。もし、特に応募がない場合は札幌Ruby会議2012実行委員会に返すなど別の形で有効利用できないか検討する予定です。

金融機関からの運転資金借入

会社を運営するためにはお金が必要です。

事務所の家賃、社員の給料、PCの購入代金など毎月様々な支出が発生します。一方で収入は、毎月一定して入ってくるものもあれば、受託開発の場合など開発着手から入金まで半年以上かかるものもあります。この支出と収入のギャップがいわゆる運転資金です。

一般的に運転資金は一時的に発生するものではなく、事業を継続している間は常に存在します。また会社の規模が大きくなるとその額も増加します。

クリアコードの場合、だいたい月商の3から4ヶ月分が運転資金となります。また運転資金のうち、資本金で賄いきれない部分を金融機関から借り入れています。創業間もない頃は日本政策金融公庫から、現在は信用保証協会を利用して信用金庫から調達しています。

日本政策金融公庫

かつての国民生活金融公庫です。

創業前あるいは創業間もない企業に対して事業資金の貸し出しを行っています。比較的融資の条件は緩いですが、その分金利は高く設定されています。

クリアコードで利用したときの融資額は資本金と同額となりました。

信用保証協会

信用保証協会とは、企業が金融機関から資金調達する際に、金融機関に対して企業を保証する機関です。

規模の小さな企業や創業間もない企業が、金融機関から融資を受けるときによく利用されます。

また信用保証協会は、自治体などと連携して特定の条件にあてはまる企業を対象とした様々な融資プランを展開しています。クリアコードのある文京区では、創業支援資金、地球温暖化等環境対策資金といった制度融資があります。制度融資の中には企業が支払う利息の一部を区が補助するものもあります。

ここで実際にクリアコードで信用保証協会を利用して金融機関から融資を受ける際に検討した点や工夫した点を紹介します。

取引金融機関の選択

信用保証協会を利用する場合、実際に融資をするのは銀行や信用金庫といった金融機関になります。どの金融機関から融資を受けるのかは、融資を受ける側が選ばなければなりません。

都市銀行、地方銀行、信用金庫、信用組合と様々な金融機関がありますが、クリアコードでは信用金庫を利用しています。これは融資を受ける額がちょうど信用金庫が扱うのによいサイズで、振込や納税など日頃の決済に利用するのに便利だったからです。おそらく都市銀行で扱うには金額が小さすぎたのでしょう。

融資を通じた金融機関との取引は長期に及びます。せっかく取引するのであれば取引を喜んでくれる金融機関を選ぶべきでしょう。数百万円の融資を面倒だと思う金融機関もあれば、よろこんで取組む金融機関もあるのです。

融資のタイミング

企業が融資を受けるのはお金が必要となる時ですが、金融機関が融資をしたいのは必ずしもその時とは限りません。例えば9月や3月は金融機関の期末の時期であり、融資残高の目標到達のため、融資に積極的になることがあります。このような時期に融資を受けることは、単に取引金融機関の担当者が喜ぶだけでなく、借り手が有利な融資の条件を獲得するチャンスにもなります。

クリアコードでは、5月頃に資金が必要となる状況にありましたが、前倒しして3月に融資を受けました。

また、金融機関や保証協会は主に財務内容を見て融資可能か検討します。そのため財務内容を判断するための資料として、借り手は決算書、試算表、資金繰表を提出します。クリアコードの場合、受託開発案件の納期などが影響して黒字の月もあれば赤字の月もあるという状況でしたので、ちょうど試算表の月次損益が黒字となるタイミングで融資を申し込みました。

「銀行は雨の日に傘を取り上げ、晴れの日に傘を貸す」という言葉もありますから、余裕がある（現金残高が多い、黒字である）ときに融資を申込むのがよいでしょう。

まとめ

借入を通じた金融機関との取引は長期に及びます。返済が進んだ数年先にはまた運転資金を調達することもあります。取引金融機関は長く付き合えるところを慎重に選ばなければなりません。

また融資を申し込む際は、貸し手にとって貸しやすい＝借り手にとって借りやすいタイミングを考慮することが大切です。

「パッチ採用」はじめました

クリアコードはプログラミングが好きな人を1名募集していますが、採用にあたって、新しく「パッチ採用」という選考プロセスを用いることにしました。

これまでは、面接と社長とのペアプログラミングで選考していましたが、この選考プロセスではクリアコードも応募者もお互いに十分に判断できる情報を得られませんでした。そのため、新しく「パッチ採用」という選考プロセスを考えました。「パッチ採用」はクリアコードがフリーソフトウェアの開発で学んだことを選考プロセスにも活かせないかということから考えられたクリアコードらしい選考プロセスです。「パッチ採用」の説明は採用情報ページにありますが、現時点のものを転載します。「パッチ情報」は今後も改良していく予定なので最新情報は採用情報ページで確認してください。

それでは「パッチ採用」の説明です。

パッチ採用

クリアコードはフリーソフトウェアを活用してソフトウェアを開発しています。

私達クリアコードのメンバーが業務でも使っている開発スタイルはフリーソフトウェアの開発の中で学んできたことです。私達はこの開発スタイルでお客さんの問題を解決するソフトウェアを開発しています。

私達は、クリアコードの開発スタイルを優れたものだと考えており、新しく一緒にソフトウェアを開発する人とも同じ開発スタイルで開発したいと考えています。しかし、これまで行なってきた面接とペアプログラミングによる選考プロセスでは、クリアコードの開発スタイルにあうかどうかを判断することが困難だとわかりました。ここの「判断する」は、私達だけが判断するという意味ではなく、私達と応募者がそれぞれ判断するという意味です。判断することが難しい理由は後述します。

そのため、私達も応募者もクリアコードの開発スタイルで一緒にソフトウェアを開発していけるかどうかを判断できる選考プロセスを考えました。それが「パッチ採用」と呼んでいる選考プロセスです。

注意

選考プロセスを説明する前にあらかじめ注意点に触れておきます。この選考プロセスでは、応募者は従来の就職活動とは違う活動をする必要があります。例えば、面接対策よりもよいコードを書くことや他の開発者との円滑なやりとりに注力する必要があります。これは応募者にとって大きな負担となる可能性があります。

応募する際は本当に就職候補の会社としてクリアコードを検討してもよいのかを十分に考慮してください。

選考プロセス

パッチ採用は以下のような選考プロセスです。

1. 応募者: プログラミングが好きであることを再度自分で確認する。
2. 応募者: 会社説明会に応募する。
3. クリアコード: 応募者に会社説明をする。
4. 応募者: クリアコードに興味があれば、クリアコードのメンバーがコミット権を持っているフリーソフトウェアの開発に参加する。具体的には、パッチを送り、パッチに関してやりとりをする。
5. 応募者: 開発に参加した結果、「自分は応募資格（後述）を満たした」と判断する。
6. 応募者: クリアコードに応募する。
7. クリアコード: 応募者と面接し、一緒にフリーソフトウェアを開発した経験から、業務でも一緒に楽しく開発していけそうかを話し合う。
8. クリアコード: クリアコードが一緒に楽しく開発できそうだと判断したら応募者に処遇を提示する。
9. 応募者: 提示された処遇でクリアコードで一緒に楽しく開発できそうだと判断したら就職する。

「パッチ採用」の名前は、開発に参加するところでパッチを送ることに由来しています。

内定を検討する段階では、応募者が新卒かどうかや、学歴、前職などは重視しません。一緒に開発した経験を重視します。

「応募資格」は以下のいずれかです。

• クリアコードのメンバーからコミット権をもらっていること
• コミット権をもらっていなくても、クリアコードの開発スタイルを実践できていると自己判断していること

どちらのケースも、応募者がクリアコードの開発スタイルを実践できていると認められたかどうかが基準となります。前者はクリアコードのメンバーが認めたケースで、後者は応募者自身で認めたケースです。どちらが認めたケースでも応募可能です。ただし、応募資格を満たしたとしても必ずしも就職できるとは限らないことに注意してください。クリアコードが就職しない方がよいと判断する場合もありますし、応募者が判断する場合もあります。

なお、選考プロセス中で開発した成果はクリアコードに就職するかしないかに関わらず自由に利用可能です。これは開発対象のソフトウェアがフリーソフトウェアだからです。

パッチ採用で開発スタイル全体を確認できるか

パッチ採用は、これまでの選考プロセスでは判断することが難しかった「お互いに開発スタイルを確認する」を実現することが目的です。本当に確認できるのかを検討してみましょう。

これまでの選考プロセスでは社長と応募者でペアプログラミングをしていました。ペアプログラミングの題材はクリアコードが開発に関わっているフリーソフトウェアの中から、クリアコードのメンバーと応募者で相談して選んでいました。ペアプログラミングをすることにより、クリアコード側は「この人はよいコードを書ける人だ」ということがわかります。このことから、「もっと大きな問題でもよいコードを書けるだろう」ということなどを想像できるようになります。しかし、これは開発スタイルの一部しか確認できておらず、他の開発スタイルは想像することになります。応募者は、クリアコードのメンバーが書いたコードを題材にするため、クリアコードのメンバーがどのようなコードを書いていたかがわかります。しかし、どのように開発しているかまではわかりません。

例えば、開発中に使用しているソフトウェアの問題を発見した場合は、そのソフトウェアへ問題を報告し、可能ならパッチを添えるのがクリアコードの開発スタイルです。問題を発見しても、手元で適当に回避しておいて問題を報告しない人とは一緒に開発できません。応募者が入社後に「こんなに徹底していると思わなかった」となるようでは応募する側がちゃんと確認できていなかったといえます。

このように、開発スタイルの一部しか確認できないため、開発スタイルを理解した上でお互いが判断する、ということができません。

一方、フリーソフトウェアを一緒に開発する場合は、開発の一部分を切り取ってペアプログラミングする場合とは違って開発そのものになります。そのため、一部から全体を想像する必要はありません。また、応募者がコードを書くだけではなく、クリアコードのメンバーもコードを書きます。そのため、クリアコードのメンバーが応募者のコードを確認するだけではなく、応募者もクリアコードのメンバーがちゃんとしたコードを書くのかどうかを確認できます。

これにより開発スタイル全体をお互いに確認できるため、適切な判断ができるようになると考えています。

パッチ採用をしたい理由

クリアコードはフリーソフトウェアの開発を大事にしている会社です。そのため、選考プロセスにもフリーソフトウェアの開発に由来する方法を持ち込めないかと考えました。なぜなら、その方法がクリアコードにとって自然だからです。

そう考えたとき、クリアコードのメンバーはパッチをやりとりするなど一緒に開発することで相手のことをわかっていくことを思い出しました。クリアコードで必要としている選考プロセスは相手のことをわかって一緒に開発していきたいかを確認するプロセスです。であれば、一緒に開発する方法を使うことがクリアコードにとって自然でとても大事なことではないかと考えたわけです。そして、フリーソフトウェアの開発では「コミット権」をもらうことが1つの信頼の目安になります。そこで、それを応募条件としました。

参考までに、フリーソフトウェアの開発で「コミット権」とはどういうものかを説明します。

フリーソフトウェアの開発では、その開発コミュニティ内で信頼されると「コミット権」という権利をもらえます。これはソースコードを自分で直接変更してもよいという権利です。フリーソフトウェアではソースコードはとても大事なものなので、これを直接変更してもよいということは、信頼の証となります。

通常、コミット権をもらえるくらい信頼されるには以下のようなプロセスになります。

1. 問題を修正するパッチや機能を改良するパッチを送る
2. パッチやパッチが扱う領域について開発者とやりとりをする
3. ↑を何度も繰り返す

開発者はパッチ提供者のコードやパッチ提供者のやりとりの中から、「この人はよいコードを書く人だな」、「この人とはコミュニケーションがとりやすいな」などといったことを感じ取っていき、「この人と一緒に開発したい」と思うと「コミット権いりませんか？」と声をかけます。パッチ提供者もこのやりとりの中で「この開発者とはコミュニケーションがとりやすいな」などといったことを感じ取っています。その上で「この開発者と一緒に開発したい」と思えばコミット権を受け取り、より積極的に開発に参加します。

このプロセスの中で、開発者もパッチ提供者もお互いに一緒に開発していけそうかどうかを判断していました。クリアコードでも同じように一緒に開発していけそうかどうかを判断したいと考えています。

まとめ

クリアコードの新しい選考プロセスとして考えた「パッチ採用」について紹介しました。このクリアコードらしい選考プロセスでクリアコードも応募者も納得できる選考ができると期待しています。

2012年8月リリースまとめ

昨日は肉の日でした。 肉の日ということでたくさんのフリーソフトウェアをリリースしました。

今月から始めたパッチ採用では「クリアコードのメンバーがコミット権を持っているフリーソフトウェアの開発に参加する」とあります。しかし、クリアコードのサイトでは3つのフリーソフトウェアしか紹介していません*1。明らかに提供している情報が不足しています。そこで、肉の日を含め今月リリースしたフリーソフトウェアを紹介することにしました。

以下が今月リリースしたフリーソフトウェアのリストです。それぞれ簡単に紹介します。

• ActiveLdap
• Cutter
• gettext
• grntest
• groonga
• Groonga CloudSearch
• locale
• mroonga
• Packnga
• Rabbit
• Ruby-GNOME2
• Rubyリファレンスマニュアル刷新計画（るりまプロジェクト）
• test-unit
• Tree Style Tab（ツリー型タブ）
• UxU

ActiveLdap 3.2.0

ActiveLdap 3.2.0 リリースアナウンス

ActiveLdapはオブジェクト指向らしいAPIでLDAPを操作するためのRuby用のライブラリです。

前回のリリースはRails 3.1系にしか対応していませんでしたが、今回のリリースでは最新のRails 3.2.8に対応しています。Rails 3.2系でLDAPを扱いたい人はぜひ試してみてください。

前回のリリースからの変更点: ActiveLdap 3.2.0

Cutter 1.2.1

Cutter 1.2.1 リリースアナウンス

Cutterは書きやすさとデバッグのしやすさを重視しているC言語・C++言語用の単体テストフレームワークです。

今回のリリースからUbuntu PreciseとFedora 17用のパッケージも用意しています*2。最新のディストリビューションでも使いやすくなっています。

さて、テストを作成したら継続的インテグレーションツールと連携したいですよね。そこで、Travis CIで簡単にCutterを使えるような仕組みを用意しました。.travis.ymlのinstall:を以下のように書くだけです。

install:
  - curl https://raw.github.com/clear-code/cutter/master/data/travis/setup.sh | sh

後で出てくるgroongaもこの仕組みを使っています。興味がある人はTravis CIでCutterを使うためのドキュメントを参考にしてください。

前回リリースからの変更点: Cutter 1.2.1

gettext 2.3.0

gettext 2.3.0 リリースアナウンス

gettextは地域化（L10N）を実現するためのRubyライブラリです。ライブラリだけではなく関連ツールも提供しています。gettextはGNU gettextパッケージをモデルにして実装されています。ちなみに、Pythonには同様の機能がgettextモジュールとして標準添付されています。

これまでは「Ruby-GetText-Package」という名前でしたが、今回のリリースから「gettext」に変更しました。 また、2012年からruby-gettextプロジェクトとしてメンテナンスをしています。

今回のリリースでは、GNU gettextのmsginitをRubyで実装したrmsginitを追加しました。これで、GNU gettextなしでも.potから新しく.poを作成できるようになりました。Windowsでもgettextだけあれば必要最小限のツールが揃います*3。

grntest 1.0.0

grntest 1.0.0 リリースアナウンス

grntestは後で出てくるgroonga用のテストツールです。 groongaのコマンド（selectやloadなど）列が期待する結果になるかを確認するために使います。MySQLのmysql-testというツールのgroonga版です。

grntestは今回が最初のリリースです。

もちろん、groonga本体のテストに使われていて、grntestで書かれたテストは徐々に増えています。パッケージされたことにより、groongaのプラグインを開発する人にも簡単に使えるようになりました。

groonga 2.0.6

groonga 2.0.6 リリースアナウンス

groongaはオープンソースのカラムストア機能付き全文検索エンジンです。groongaを使うと全文検索機能付き高性能アプリケーションを開発することができます。

今回のリリースでは指定した語句を含まない文書を検索できるようになりました。このようなクエリは多くの文書がヒットするため重いクエリとなります。例えば、ククログで「PHP」を含まない文書を検索するとほとんどの文書がヒットしてしまいます。このような検索がたくさん実行されるとシステム全体に大きな負荷がかかります。そのため、groongaではこの機能をサポートしていませんでした。しかし、使い方によっては便利なこともあることはたしかです。そこで、デフォルトでは無効で本当に必要なときだけ有効にすることでこの機能を提供することにしました。これにより、システムが過負荷になる危険性を回避しつつ必要なときは便利に使えます。

前回リリースからの変更点: groonga 2.0.6

Groonga CloudSearch 1.2.0

Groonga CloudSearch 1.2.0 リリースアナウンス（英語）

Groonga CloudSearchはAmazon CloudSearch互換のAPIを備えるオープンソースの全文検索システムです。名前からわかる通り、バックエンドにgroongaを使っています。

Amazon CloudSearchは有償のクラウド型サービスですが、Groonga CloudSearchは任意のサーバ（開発環境のPC自体でも問題ありません）にデプロイして利用するソフトウェアです。Amazon CloudSearchを使用するアプリケーションの初期開発段階などにおいて、自由に利用することができます。

groongaを利用する際には転置インデックスの準備などのように検索エンジンそのものに関する知識が必要となってきます。そのため、使い始められるようになるまでの障壁が若干高い事は否めません。Groonga CloudSearchはそのような部分を内部で自動的に処理するため、groongaベースの全文検索システムを、論理的なインターフェースのみを用いて簡単に利用することができます。

このリリースでは簡易的なアクセス制限のための仕組みなどが投入されており、公開の実サービスでの利用も可能となっています。

locale 2.0.6

locale 2.0.6 リリースアナウンス

localeは地域化（L10N）を実現するためのRubyライブラリです。localeに関する情報の扱いはプラットフォーム毎に異なりますが、そこを抽象化し、プラットフォームに依存せずに扱えるようにします。前に出てきたgettextもlocaleを使っています。

今回のリリースでRuby 1.9 + Windowsの組合せでも動くようになりました。

前回リリースからの変更点: locale 2.0.6

mroonga 2.06

mroonga 2.06 リリースアナウンス

mroongaは全文検索可能なMySQLのストレージエンジンです。すべてのMySQLユーザーに高速な全文検索機能を提供します。バックエンドには前に出てきたgroongaを使っており、日本語にも対応しています*4。

今回のリリースではMATCH(...) AGAINST("-語句" IN BOOLEAN MODE)というクエリを書けるようになっています。これは指定した語句を含まないレコードを検索するクエリです。このクエリはMyISAMでは使えたのですが、mroongaでは使えませんでした。理由はバックエンドのgroongaがこの機能をサポートしていなかったからです。groongaでこの機能が実装されたため、mroongaでもこの機能をサポートしました。

前回リリースからの変更点: mroonga 2.06

Packnga 0.9.5

PackngaはRubyのパッケージ作成を支援するライブラリです。国際化に対応したドキュメントを生成するための機能も含んでいます。ドキュメントの生成にはYARDを使います。

今回のリリースではYARDの国際化（i18n）機能を使うようにしました*5。これまではxml2poを使って国際化機能を実現していましたが、ドキュメント中のシンタックスハイライトされたサンプルコードなどでノイズ*6が多くなるという問題がありました。国際化機能をYARDと統合することでノイズがなくなり、翻訳しやすくなりました。

また、xml2poがなくてもドキュメントを生成できるようになったため、特にWindowsでPackngaを使うハードルが低くなっています。

Rabbit 2.0.0

Rabbit 2.0.0 リリースアナウンス

RabbitはRubyistの多くが使っているプレゼンテーションツールです。 約1年ぶりにメジャーバージョンアップして2.0.0になりました。

今回のリリースではスライド・テーマを共有する仕組みが導入されました。スライド・テーマともにgemで公開できるようになりました。gemはすでに実績のあるパッケージ配布システムです。gemをベースにすることで共有するために必要な機能が一気に揃いました。簡単にスライド・テーマを公開できますし、インストール・アンインストールもコマンド一発です。

また、SlideShareにもコマンド一発で公開できる機能も追加しました。Rabbitで作ったスライドがより共有しやすくなりました。

前回リリースからの変更点: Rabbit 2.0.0

Ruby-GNOME2 1.1.5

Ruby-GNOME2 リリースアナウンス

Ruby-GNOME2はGTK+-2.xなどGNOME 2関連のライブラリをRubyから利用するための拡張ライブラリです。

今回のリリースではネットワーク周りが改良されています。TLSを扱えるようになったり、Windows用のパッケージにglib-networkingが追加されています*7。

前回リリースからの変更点: Ruby-GNOME2 1.1.5（英語）

Rubyリファレンスマニュアル刷新計画（るりまプロジェクト）

Rubyリファレンスマニュアル刷新計画」2012-08分のスナップショットリリースアナウンス

Ruby1.9対応にも一区切りつけた約一年振りのスナップショットリリースです。 BitClust、ReFe2がgemになりました。gemになったので簡単にインストールできます。

コマンドラインから高速に日本語のリファレンスを読みたい人におすすめです。

test-unit 2.5.2

test-unit 2.5.2 リリースアナウンス

test-unitはRuby用のxUnit系の単体テストフレームワークです。

今回のリリースではshoulda-contextやRSpecにある（便利と思われているらしい）機能をいくつか追加しました。

--locationコマンドラインオプションはRSpecの--line_number相当の機能です。sub_test_caseはshoulda-contextとRSpecのcontextと似た機能です。

前回リリースからの変更点: test-unit 2.5.2

Tree Style Tab（ツリー型タブ）0.14.2012081101

このバージョンでの変更点一覧（Mozilla Add-ons）

ツリー型タブは、Mozilla Firefoxのタブバーをサイドバー状に縦型に表示した上で、タブ同士の親子関係を視覚的に表現できるようにするアドオンです。開発に必要な資料を検索する場面など、タブを大量に開いたままの状態でそれぞれのタブを行ったり来たりする場合がありますが、そのような場合でも、切り替える先のタブがどこにあるのかを直感的に把握しやすくなります。

このリリースでは目立った新機能の追加はなく、Firefoxの仕様変更への追従と、細かい不具合の修正が主な内容です。

UxU (UnitTest.XUL) 1.0.1

このバージョンでの変更点一覧（Mozilla Add-ons）

UxUは、Mozilla FirefoxやMozilla Thunderbird用のアドオン開発者向けのテスティングフレームワークです。

このリリースでは、テスト対象のアドオンを、テストケース内でメタ情報として明示できるようになりました。テスト対象のアドオンがインストールされていない場合は警告が表示されるため、何が原因でテストが失敗したのかが、より分かりやすくなります。また、プロファイルを明示して別プロセスでテストを実行する場合に、現在のプロファイル内にインストールされているテスト対象のアドオンを、テスト実行用の一時プロファイル内に自動的にコピーするようになるため、一時プロファイルの雛形を用意する際の手間が軽減されます。

より詳しい説明: Firefox/Thunderbird用アドオン開発者向けテスティングフレームワーク UxU 1.0.0をリリースしました - ククログ(2012-07-24)

まとめ

今月リリースしたフリーソフトウェアを簡単に紹介しました。 どのフリーソフトウェアも（程度の差はありますが）継続的に開発を継続しており、その成果がこれらのリリースです。

気になるものがあったらぜひ使ってみてください。