ククログ

Mac OS X版GTK+における日本語入力対応の近況

以前の記事で、Mac OS X版GTK+の日本語入力対応モジュールGtkIMCocoaを開発中であることを紹介しました。

今回は以下の最新のトピックについて紹介します。

Xamarin Studio用GtkIMCocoaバイナリのリリース
最新版GTK+での日本語入力対応状況
既知の不具合とその修正状況

Xamarin Studio用GtkIMCocoaバイナリのリリース

5月の記事で、Xamarin Studioでの日本語入力がもう少しで可能になりそうだということを紹介しました。その後の調査で、GtkIMCocoaにいくつかのワークアラウンド*1を入れることで最低限の動作は可能であることを確認しました。これを機にGtkIMCocoaのバイナリモジュールをリリースしましたので、興味のある方は試して頂き、不具合等があれば報告して頂けると大変助かります。

Xaramain Studioでの日本語入力の様子

なお、GtkIMCocoaは既にMonoのビルドシステムに取り込まれています。また、新しいGTK+とともに後述するim-quartzも導入されるものと思われるため、今すぐ試したい・開発に協力したいということでなければ、慌てて本モジュールをインストールする必要はありません。今後リリースされるXamarin Studioではデフォルトで日本語入力が可能になるものと思われます。

入手およびインストール方法

GtkIMCocoaのバイナリモジュールは以下のリンクからダウンロードして下さい。

gtkimcocoa-0.0.2-gtk2-i386.zip

これに対応するソースコードは以下のリンクからダウンロードすることができます。

gtkimcocoa-0.0.2.tar.gz

GUIのインストーラは用意していません。インストールは本パッケージに含まれるシェルスクリプトをコンソールから実行することで行います。

$ unzip gtkimcocoa-0.0.2-gtk2-i386.zip
$ cd gtkimcocoa-0.0.2-gtk2-i386
$ sudo ./install-for-xamarin.sh

すでにGtkIMCocoaがインストールされている場合は上書きされますので、ご注意下さい。また、後述するim-quartzがインストールされている場合は、im-quartz.so.bakにリネームされます。リネームされたim-quartzは、下記のコマンドでGtkIMCocoaをアンインストールすると元に戻されます。

$ sudo ./install-for-xamarin.sh uninstall

上記スクリプトは、Unityに付属するMonodevelopへのインストールには対応していません。ただし、インストール自体はim-cocoa.soをコピーしてGTK+の設定ファイルをgtk-query-immodules-2.0で更新するだけですので、興味のある方は上記スクリプトを参考に挑戦してみて下さい。

バグ報告方法

何か問題が見つかった場合は、GitHubのissueに登録して頂けると助かります。日本語・英語どちらでも構いません。

既知の不具合

既知の不具合については後述します。

既知の不具合とその修正状況

現在のGtkIMCocoaやim-quartzには、ある程度詳細がわかっているものだけでも以下のような問題があります。

Google日本語入力使用時に反応が遅くなる不具合

3月の記事で紹介したGoogle日本語入力が動作しないという問題ですが、これは正確には「Google日本語入力等の一部のIMでキーをタイプすると反応が非常に遅くなり、また一部のキーは完全に動作しなくなる」という問題でした。その後の調査で、これはGTK+の問題であり、immoduleを無効にしていても発生する問題であることがわかりました。このため、GtkIMCocoaだけではなくim-quartzでも再現します。ただし、環境によっては問題が発生しないこともあるようです。

この問題についてはGTK+にパッチを提供済みで、既に修正は取り込まれています。gtk+-2.24.19には間に合いませんでしたが、2.24.20以降で適用されるものと思われます。GTK+ 3系については、3.9.6以降で適用されています。

GNOME Bugzilla – Bug 698183

英数キーやかなキーでのモード切り替え時の挙動不具合

5月の記事で、Sylpheedにおいてキー操作による入力モード切り替えを行うと、フォーカスウィジェットが勝手に切り替わってしまう問題があることを紹介しました。その後の調査で、これはGTK+側で英数キーやかなキーをスペースキーとして認識していることによって発生している問題であることがわかりました。GTK+の問題であるため、GtkIMCocoaだけではなくim-quartzでも再現します。

この問題についてもGTK+にパッチを提供済みですが、まだGTK+開発者のレビューは受けていません*3。

GNOME Bugzilla – Bug 702841

今回リリースしたGtkIMCocoaのバイナリモジュールでは、ワークアラウンド処理を入れることでこの問題を回避しています*4。

Xamarin Studioで未確定文字列が表示されない

5月の記事で、Xamarin Studioにおいて未確定文字列が表示されない問題があるということを紹介しました。その後、Xamarin Studio側で修正して頂きましたので、今後リリースされるXamarin Studioではこの問題は解消されるはずです。また、今回リリースしたGtkIMCocoaのバイナリモジュールにはこの問題を回避するための処理が入っています*5ので、このモジュールを使用する場合は、修正が入っていないXamarin Studioでも日本語を入力することが可能です。

変換中のカーソルキーの動作不具合（GtkIMCocoa・im-quartz）

カーソルキーでキャレットを未確定文字列*6の先頭より前あるいは最後尾より後に移動しようとすると、変換中文字列が消える問題があることを確認しています。GtkIMCocoa・im-quartz両方で再現します。これについては修正方法を検討中です。

かなテーブルや文字ビューアでの入力不具合（im-quartz）

im-quartzでは、かなテーブルや文字ビューアで文字を入力できないという問題あります*7。

この問題の存在自体は報告済みですが、3月の記事で紹介した根本的な設計上の問題点に起因している部分があるため、現在のim-quartzの設計を保ったままでの修正方法は提示できていません。

GNOME Bugzilla – Bug 702843

英数キー2回押しによる英数変換の不具合（im-quartz）

Mac OS X標準の日本語入力システムである「ことえり」には、英数キーを2回連続で押すと、未確定文字列をアルファベットに戻して確定する機能があります。im-quartzでこの機能を使用すると、アルファベットは期待通り確定されるものの、未確定文字列が表示されたままになってしまう問題があります。この問題は上記のような設計の問題とは関係なく修正できる可能性があるため、修正方法を検討中です。

かなキー2回押しによるかな変換（GtkIMCocoa・im-quartz）

「ことえり」には、かなキーを2回連続で押すことで確定済み文字列を再変換する機能があります。GtkIMCocoaやim-quartzにはこの機能に対応するためのコードが実装されていません。GTK+側のAPIの制限のために他のプラットフォームでも問題になっている機能であるため、実装可能かどうかも含めて検討中です。

マルチディスプレイ環境で候補ウィンドウの位置がずれる（GtkIMCocoa）

GtkIMCocoaには、マルチディスプレイ環境で候補ウィンドウを出すと期待する位置に表示されない問題が存在します。im-quartzに同様の問題があるかどうかは確認はできていません。

まとめ

今回の記事では、Xamarin Studio用のGtkIMCocoaをリリースしたことと、最新のMac OS X版GTK+ではデフォルトで日本語入力が可能となっていることを紹介しました。また、これらの実装の既知の不具合とその修正状況について紹介しました。ぜひ一度これらの実装を試して頂き、さらなる改善にご協力頂ければ幸いです。

GtkIMCocoaとim-quartzに共通の不具合を修正した場合は、GTK+プロジェクトに報告してim-quartz側にもマージしていくことを考えています。im-quartz固有のバグについても可能な限り直して行きたいと考えていますが、設計に起因するものについては修正が難しい可能性もあるので、引き続きGtkIMCocoaのようなアプローチによる実装も提案していきます。

*1 正式な対応については、後述の通りGTK+本体やXamarin Studio側での修正が必要です。

*2 3月の記事で紹介している通り、GtkIMCocoaはim-quartzにインスパイアされて開発を開始したものですが、根本的な設計が異なります。

*3 MonoのGTK+には先行して本パッチが取り込まれています。

*4 ソースからビルドする場合は、configureに--enable-workaroundオプションを追加することでこの処理を有効にできます。

*5 ソースからビルドする場合は、configureに--enable-workaroundオプションを追加することでこの処理を有効にできます。

*6 InputMethod用語ではコンポジション文字列あるいはプリエディット文字列などと呼ばれます。

*7 かなテーブルについては、正確には未確定文字列が表示されない、確定操作をすると逆に未確定文字列が現れて表示されたままになるという問題です。

この記事の続き

2013-07-03

Software in 30 Days - スクラムによるアジャイルな組織変革"成功"ガイド

2013年3月に「ソフトウェア開発を『しない』人がスクラムでスクラムを導入する」ための本がASCIIから出版されました。

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド
Ken Schwaber/Jeff Sutherland/角征典/吉羽龍太郎/原田騎郎/川口恭伸
KADOKAWA/アスキー・メディアワークス
￥ 15,557

RubyKaigi 2013に参加したときに訳者の角さんと川口さんからもらったので読みました。過去にソフトウェア開発をする人向けのスクラムの本は何冊か読んでいて、実際ソフトウェア開発をする人なので、ソフトウェア開発をする人視点で読みました。実は読んでからしばらく経っているので、最初の方を少し読み返してみたところ、いくつか考えることがありました。まとまっていませんが、書いてみます。

スクラムと開発者

スクラムを導入すると開発者がすばらしくなる、という描写が印象的でした。最初の方の記述なので、メリットを強調するための記述なのかもしれません。この本を読む前までのスクラムのイメージは、「できる人に任せるとうまくいくよ」であって、「できない人でも任せるとできる人になってうまくいくよ」ではなかったので、これまでの印象と違いました。ただ、実際はどうなのかはわかっていません。この本を読むと「できない人でも任せるとできる人になってうまくいくよ」の方な気もします。

P.29

ジェーンが新しいソフトウェア開発手法のことをみんなに伝えると、懐疑的に受け止められた。特に開発チームのメンバーは、受け入れるのに時間がかかった。（中略）しかし、新しいプロセスの経験を積んでいくと、（中略）開発者は、イテレーションで顧客と直接やり取りができるようになった。要求を自分たちで理解して、どうすればうまく実装できるかを考えられるようになった。

途中で止めることは成功か

最初に、ウォーターフォールと比べてスクラムの方がいいよ、というような話がでてきます。わかりやすいからでしょう。

その中に「ウォーターフォールは途中で止めると何も成果をえられないけどスクラム（経験主義のソリューション）では途中で止めてもそこまで作ってきた価値を利用できるからよい」というようなことが書いてあります。（P. 38の「2.2 経験主義は問題を解決するか？」の「ウォーターフォールの問題1」。）

同じようなことで「スクラム（経験主義のソリューション）ではすべてが完成する前から途中まで作ったものを利用できるから利用者に早く価値を届けられるのでよい」ということも言われています*1。これはたしかにそうだというのは理解できます。実際にフリーソフトウェアをそのようにリリースしていて、その通りであることを実感しているからです*2。

しかし、途中で止めたプロジェクトがその後も有益に利用し続けられるのかというとピンときません。メンテナンスされなくなったフリーソフトウェアをその後も使い続けたいとは思わないからかもしれません。例えば、以前はWebブラウザーとして風博士を使っていましたが、メンテナンスされなくなってしばらくすると新しい環境では動かなくなり、Firefox*3に移行しました。フリーソフトウェアの場合、有用なソフトウェアならたとえ元々メンテナンスしていた人たちがメンテナンスしなくなっても他の人たちが代わりにメンテナンスするようになったり、代替となるフリーソフトウェアが開発されます。このような場合は一度は途中で止まったプロジェクトでもその後も有益に利用してきました*4。

このように、自分の経験に合わせて考えると、途中で止まってその後メンテナンスされないプロジェクトでも有益に利用し続けられる、ということがピンときませんでした*5。

やわらかなマネジメント

スクラムでは開発チームは自己組織化していなければいけません。これは、マネージャー（スクラムマスター）から管理されない代わりに、開発チームは自分たちで考えて決めなければいけないと理解していました。例えば、プロダクトバックログのそれぞれの項目をどのくらいの時間でどうやって実現するかは開発チームが自分たちで考えて宣言し、それを守るために行動する。もし、時間がオーバーしそうならそれの調整も自分たちでする。そのような開発チームだと理解していました。

しかし、その理解は違ったようです。P. 44の「やわらかなマネジメント」には以下のように書いてあります。

プロジェクトの開発チームが自分たちのやり方で進めていたとしても、管理されていないということではない。自己管理に重点を置いて、十分なチェックポイントを作り、不安定・あいまい・緊張がカオスにならないようにする。

開発チームは、自分たちがどうやって行動するかを決めて、それを実現するために行動をするというところまでは理解があっていたようですが、それがうまくいくようにサポートする人が必要だ*6ということは理解が違っていました。スクラムマスターは開発チームが自分たちだけでできるようになるまでサポートする、くらいのイメージでしたが、ずっとサポートしているようです。

スクラムはなんでもそつなくこなせる人たちばかり集めなければ（ばかりにならなければ）実現できないやり方というわけではなさそうです。これまで、一部苦手なことはあるけれど他はしっかりできる人を何人かみてきたのですが、そのような人たちには向いていないやり方だと認識していました。なので、「習得は非常に困難」はその通りだろうと理解していました。この「やわらかなマネジメント」もあるなら、最初の認識ほど敷居は高くなさそうです。ただ、習得は非常に困難というのは変わらないでしょう。

まとめ

Software in 30 Daysの最初のところを読み返して考えたことをまとまりなく書いてみました。ここでは、最初の方だけにしか触れていませんが、後半はスクラムでスクラムを導入するということまでやっているので、組織にスクラムを導入してみたいと考えている人は読んでみるとよいでしょう。

*1 すぐにはみつけられませんでしたが、たぶん、この本にも書いているでしょう。

*2 例えば、groongaを毎月（30日毎に！）リリースしていて、何人ものユーザーが活用していることを知っています。

*3 本当はIceweasel。

*4 違うプロジェクトに移行していることもありますが、前のプロジェクトを使っていたときに得た知見を引き継いで利用するので、ムダとは感じません。

*5 この本で想定しているCXOとしての経験が足りない気がします。

*6 たぶん、2日でこの機能を実現するためには、1日目では○○まで進んでないといけなそうだね。大丈夫？みたいなことをそれとなく、鬱陶しがられないように聞いたりするのでしょう。違うかしら。

2013-07-08

クリアコードの開発の様子をフォローしやすくしました

クリアコードでは、社名からわかる通り、日頃からクリアなコードを書くべく日々コードと向き合っています。そのために「みんながみんなのコードを読む文化」を維持しています。

クリアコードでは自分たちがクリアなコードを書くだけではなく、自分たち以外の人たちがクリアなコードを書くことを支援したいと考えています。そのために、他社の開発チームに「みんながみんなのコードを読む文化」を根付かせる支援をするコミットへのコメントサービスも提供しています（導入事例）。また、クリアなコードを書くために実践しているノウハウを文書化して公開しています。例えば、以下のようなノウハウです。

よいコードの書き方に関して
デバッグに関して
- デバッグ力: よく知らないプログラムの直し方 - ククログ(2011-12-06)
- デバッグしやすいassert_equalの書き方 - ククログ(2011-02-28)
コミットに関して

これらのような集中的な支援やまとまった文書も役に立つと信じていますが、クリアコードの日々の開発の中にも役に立つノウハウが転がっているはずです。そして、そのノウハウは私たち自身がまだ気づいていないまま無自覚にやっているものもあるでしょう。無自覚なものは自分たちで文書としてまとめることができないため、社外の人たちと共有する機会がありません。

そこで、クリアコードの開発の様子をフォローしやすくしました。具体的にはクリアコードが開発しているフリーソフトウェアのコミットメールを流しているメーリングリストcommit@clear-code.comに誰でも参加できるようにしました。

このメーリングリストにはGitHubのclear-code organizationにあるリポジトリーのコミットメールとTravis CIからの通知メールが流れています。milter managerなど別organizationにしているプロジェクトは以前から公開のメーリングリストに流していますが、それらについては変更ありません*1。

commit@clear-code.comではコミットへのコメントサービスで示しているように、クリアコードのメンバーがコミットに対してコメントすることがあります。コミットへのコメントサービスがどのように実施されるかについて興味のある方や、体験してみたい方、クリアコードのメンバーの日々のコミットからノウハウを学びたいという方はぜひ購読してみてください。

今、クリアコードではインターンシップを実施していますが、その様子をclear-code/internshipに記録しています。この記録もcommit@clear-code.comに流れます。

インターンシップでは、今まで無自覚にやっていたことを説明する場面がたくさんあります。そのたびに、どうしてそのようなコードを書くのかという「理由」を明確にしたり、どこに気をつけたり着目したりしてコードを書いているのか、ということを明確にしています。例えば、コメントを書かないといけないところは本当にコメントが必要なのかを考えるということに気をつけているということを自覚しました。

このインターンシップの記録をみれば、クリアコードではどのように考えて開発しているかがわかるはずです。コミットへのコメントサービスを検討している方や、クリアコードで仕事としてフリーソフトウェアを開発したいという方は参考にしてください。なお、クリアコードの選考プロセスはパッチ採用です。

*1 別organizationにしているプロジェクトへコミットすることが多いので、実は、commit@clear-code.comの流量はそれほど多くありません。

この記事の続き

2013-07-11

Fedoraプロジェクトでパッケージを更新するには

はじめに

以前、Fedoraプロジェクトで新規パッケージをリリースする方法という記事を書きました。パッケージを初めてFedoraプロジェクトでリリースしようとしているときに、どんなことをするのかというのを実際の例にもとづいて紹介する内容でした。

今回はパッケージをリリースした後の話として、既存パッケージを更新するときにどうすればいいのか、というのをカラムストア機能付き全文検索エンジンであるgroongaを例に紹介します。

既存パッケージの更新作業の流れ

Fedoraプロジェクトで既存のパッケージを更新するケースは二つあります。一つは、自分で新規にパッケージを追加したものを引き続き更新する場合です。もう一つは、他の人がメンテナンスしているパッケージを更新する場合です。前者と後者では、パッケージの所有者に共同メンテナとして認めてもらう必要があるという違いがあります。ただし、その違いさえ除けばあとの作業は同じです。

以下に既存パッケージの更新作業の流れを簡単に紹介します。

共同メンテナになる（他の人がメンテナンスしているパッケージに参加する場合）
新規リリースを取り込む
SRPMを作成する
ビルドチェックする
パッケージをコミットする
パッケージをビルドする
パッケージをアップデートする
パッケージをリリースする

既存パッケージの更新についてはPackage update HOWTOという文書があるので、一読をおすすめします。

groongaの場合は、すでにFedoraプロジェクトにパッケージが登録されていました。ただし、groongaが毎月29日に肉の日リリースを定期的に行っていることもあり、最新バージョンが利用できる状態にはありませんでした*1。

そこで、共同メンテナになることにしました。

共同メンテナになる

共同メンテナになるには、Fedora Pacakge Databaseにアクセスし、FASアカウント*2によるログインが必要です。

パッケージ名で検索し、詳細ページで自身をメンテナとして登録します。登録するとパッケージの所有者に通知が送られます。

あとは共同メンテナになりたい旨をメール等で交渉します。groongaの場合は、こちらからお願いする前にパッケージの所有者である上野さんから共同メンテナになる意思確認のメールをもらいました。そのためその後のやりとりで、共同メンテナとしてすぐに承認してもらえました。

新規リリースを取り込む

共同メンテナとして承認してもらったら、実際に更新作業に入ります。groongaの場合、リポジトリの以下の三つのブランチで更新する必要があります。

master*3
f19
f18

masterブランチを更新し、その変更を別のブランチにマージしなければなりません。注意すべきは、masterブランチとそれ以外では若干手順に違いがあることです。これについては「ブランチごとの作業まとめ」で後述します。

以下のコマンドでgroongaのリポジトリをcloneしてからソースアーカイブを更新します。

$ fedpkg clone groonga
$ cd groonga
$ wget http://packages.groonga.org/source/groonga/groonga-3.0.4.tar.gz
$ fedpkg new-sources groonga-3.0.4.tar.gz

実行すると、以下のようにソースアーカイブがアップロードされます。

Uploading: d37e6391f9a7346166e0d1301e88dea5  groonga-3.0.4.tar.gz
######################################################################## 100.0%
Uploaded and added to .gitignore: groonga-3.0.4.tar.gz
Source upload succeeded. Don't forget to commit the sources file

fedpkg new-sourcesは.gitignoreやsourcesファイルを更新します。しかしspecファイルはそのままなので、エディタでgroonga.specを適宜修正します。groongaの場合は特にパッケージ構成やスクリプトの変更等はなかったので、修正したのはchangelogやRelease、Versionくらいでした。

specファイルの修正が終わったら、次のステップ「SRPMを作成する」へ進みます。

SRPMを作成する

ビルド確認に使うSRPMを作成します。

SRPMを作成するには以下のコマンドを実行します。

$ fedpkg srpm

SRPMがカレントディレクトリに作成されたら、次のステップ「ビルドチェックする」へ進みます。

ビルドチェックする

作成したSRPMをもとにビルドに支障がないか確認します。

そのままrpmbuildでビルドを確認するという方法もあります。ただし通常利用している環境でのビルド確認ではパッケージの依存関係の漏れを見過す可能性があるので、以前紹介したKojiを使って確認します。例えば、Fedora 19向けのビルド確認をするには以下のコマンドを実行します。

$ koji build --scratch --arch-override x86_64 f19 groonga-3.0.4-1.fc20.src.rpm

すると以下のようにFedoraのビルドサーバーにSRPMがアップロードされ、パッケージのビルドが始まります。

Uploading srpm: groonga-3.0.4-1.fc20.src.rpm
[====================================] 100% 00:00:34   9.87 MiB 289.95 KiB/sec
Created task: 5436609
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5436609
Watching tasks (this may be safely interrupted)...
5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm): free
5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm): free -> open (buildvm-07.phx2.fedoraproject.org)
  5436610 buildArch (groonga-3.0.4-1.fc20.src.rpm, x86_64): open (buildvm-23.phx2.fedoraproject.org)
  5436610 buildArch (groonga-3.0.4-1.fc20.src.rpm, x86_64): open (buildvm-23.phx2.fedoraproject.org) -> closed
  0 free  1 open  1 done  0 failed
5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm): open (buildvm-07.phx2.fedoraproject.org) -> closed
  0 free  0 open  2 done  0 failed

5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm) completed successfully

他の環境でもビルドを試すにはkojiのオプションを変更します。例えば、Fedora 18向けにビルドするには以下のようにします。

$ koji build --scratch --arch-override x86_64 f18 groonga-3.0.4-1.fc20.src.rpm

パッケージに問題がないか確認する方法はほかにもいくつかあります。

rpmlintによるチェック
mockによるビルドチェック
fedora-reviewによるチェック

詳細は、「Fedoraプロジェクトで新規パッケージをリリースする方法」の「レビューリクエストの準備」を参照してください。

masterのパッケージをコミットする

ローカルでの動作確認やkojiでのビルド結果に問題がなければ、コミットした後にリポジトリへとpushします。リポジトリへの反映は以下のコマンドを実行します。

$ fedpkg commit
[master 8e64aaf] Update to 3.0.4-1
 3 files changed, 6 insertions(+), 2 deletions(-)

$ git push
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 503 bytes, done.
Total 5 (delta 2), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
To ssh://kenhys@pkgs.fedoraproject.org/groonga
   ee49528..8e64aaf  master -> master

masterのパッケージをビルドする

リポジトリへpushした後、パッケージをFedoraのビルドサーバーでビルドします。ビルドには以下のコマンドを実行します。

$ fedpkg build

リモートのビルドサーバーでビルドしているので、それなりに時間がかかります。masterでの作業はこれでおしまいです。

次はmasterの変更を別のブランチへマージします。

f19ブランチでパッケージをコミットする

masterでパッケージのビルドまで終わったら、今度はその変更をFedora 19向けにも反映します。そのためには作業するブランチを以下のようにしてmasterからf19ブランチへと切り替えます。

$ fedpkg switch-branch f19

masterから変更点をマージして、リポジトリへとpushするには以下のコマンドを実行します。

$ git merge master
$ git push

f19ブランチでパッケージをビルドする

masterと同様にして、Fedora 19向けにパッケージをビルドします。そのためには以下のコマンドを実行します。

$ fedpkg build

これで、Fedora 19向けのリリースパッケージをビルドできました。

f19ブランチでパッケージをアップデートする

ビルド済みのリリース用パッケージをBohdi経由で配布できるようにします。そのためには以下のコマンドを実行します。

$ fedpkg update

このとき、アップデート情報を入力します。今回はバグフィックスリリースなので、typeをbugfixにして、notesには更新理由を書きます。

Creating a new update for  groonga-3.0.4-1.fc19 
Password for kenhys: 
Creating a new update for  groonga-3.0.4-1.fc19 
Update successfully created
================================================================================
     groonga-3.0.4-1.fc19
================================================================================
    Release: Fedora 19
     Status: pending
       Type: bugfix
      Karma: 0
    Request: testing
      Notes: Update to 3.0.4. See changes at
           : http://groonga.org/docs/news.html#release-3-0-4-2013-0
           : 5-29
  Submitter: kenhys
  Submitted: 2013-05-29 06:37:33
   Comments: bodhi - 2013-05-29 06:37:36 (karma 0)
             This update has been submitted for testing by kenhys.

  https://admin.fedoraproject.org/updates/groonga-3.0.4-1.fc19

これで、f19ブランチでの作業はおしまいです。次はf18ブランチを更新します。

f18ブランチでパッケージをコミットする

Fedora 19のときと同様に作業ブランチを切り替えます。

$ fedpkg switch-branch f18

Fedora 19のときと同様にmasterの変更点をf18ブランチへとマージ、リポジトリへpushします。

$ git merge master
$ git push

f18ブランチでパッケージをビルドする

Fedora 19のときと同様にパッケージをビルドします。

$ fedpkg build

f18ブランチでパッケージをアップデートする

Fedora 19のときと同様にパッケージをBohdi経由で配布できるようにします。

$ fedpkg update

これで、f18ブランチでの作業はお終いです。

ブランチごとの作業まとめ

ここまでで、master、f19、f18と三つのブランチで作業しました。

それぞれのブランチで必要な作業を以下にまとめます。

作業	masterブランチ	Fedora 19ブランチ	Fedora 18ブランチ
新規リリースの取り込み	必要	不要	不要
パッケージのコミット	必要	必要	必要
パッケージのビルド	必要	必要	必要
パッケージのアップデート	不要	必要	必要
パッケージのテスト	不要	必要	必要
パッケージのリリース	不要	必要	必要

まず、masterで「新規リリースの取り込み」から「パッケージのビルド」まで行いました。次にfedpkg switch-branch f19でFedora 19のブランチに切り替えmasterブランチからマージした後、「パッケージのコミット」から「パッケージのアップデート」まで行いました。同様にして、fedpkg switch-branch f18でFedora 18のブランチに切り替えmasterブランチからマージした後、「パッケージのコミット」から「パッケージのアップデート」まで行いました。

上記を具体的な実行コマンド列で比較すると以下のようになります。

masterブランチの場合

$ fedpkg new-sources groonga-3.0.4.tar.gz
$ fedpkg commit
$ git push
$ fedpkg build

Fedora 19ブランチの場合

$ fedpkg switch-branch f19
$ git merge master
$ git push
$ fedpkg build
$ fedpkg update

Fedora 18ブランチの場合

$ fedpkg switch-branch f18
$ git merge master
$ git push
$ fedpkg build
$ fedpkg update

ここまでの作業がブランチごとに完了したら、次のステップ「パッケージのテスト」へと進みます。

パッケージのテスト

fedpkg updateまで終わったら、あとは新規パッケージを登録したときと同様にtestingリポジトリでフィードバックを待ちます。詳しくは「Fedoraプロジェクトで新規パッケージをリリースする方法」の「パッケージのテスト」を参照してください。

パッケージのリリース

testingリポジトリで一定期間が経過するとパッケージをリリースすることができます*4。Bohdiのインターフェースから一般ユーザーが利用しているyumリポジトリへとパッケージを反映します。詳しくは「Fedoraプロジェクトで新規パッケージをリリースする方法」の「パッケージのリリース」を参照してください。

まとめ

今回はFedoraプロジェクトで既存パッケージを更新する方法を紹介しました。パッケージは一度登録したらそれで終わりではありません。アップストリームで新規リリースがあれば、それに対応していく必要があります。継続してメンテナンスしていくことはとても重要です。

Fedoraプロジェクトでパッケージをメンテナンスすることになったら参考にしてみてください。

*1 当時3.0.2がgroonga.orgの独自リポジトリでリリースされていたものの、Fedoraプロジェクトでは2.0.9のままになっていた。

*2 パッケージのメンテナンスに用いるアカウント。https://admin.fedoraproject.org/accounts/にて登録する。

*3 rawhideとも呼ばれるブランチ。

*4 フィードバックで問題なしとされた場合は自動的に一般ユーザ向けyumリポジトリへと反映されます。

この記事の続き

2013-07-17

クリアコードのフリーソフトウェアビジネス

はじめに

7月12日につくばインターンシップ・コンソーシアム主催の夏休みインターンシップマッチングフェアにインターンを受け入れる企業として参加してきました。中小、ベンチャー企業16社と50名ほどの学生さんが参加していました。クリアコードのブースには10名近い学生さんがきてくれました。ブースではクリアコードの業務内容、インターンシップを実施する理由、現在実施しているインターンシップを紹介しました。ブースにきてくれた学生さんはフリーソフトウェアでビジネスをしているというクリアコードの特徴に興味をもったようで、どうやってフリーソフトウェアでビジネスができるのかという質問をよく受けました。そこで今回はクリアコードがどうやってフリーソフトウェアでビジネスをしているのか紹介します。

クリアコードの業務内容

クリアコードは2006年7月25日に創業し、今月7周年を迎えました。これまでの7年間、さまざまな業務を行ってきました。この7年間に携わった案件を3つの時代にわけて紹介します。

初代社長時代

初代社長時代は第1期と第2期です。エンジニアの雇用を確保する目的で立ち上げたのがクリアコードでしたので、雇用を維持できるように案件を確保することが当時の最優先課題でした。エンジニア全員がデスクトップ関連のフリーソフトウェア開発に関する高いスキルを有していたので、それを活かすことが案件獲得の近道でした。また当時は経済産業省主導でOSSの推進事業がIPAなどで行われていました。

第1期（2006/7から2007/6）

IPAや自治体など公共系の案件が中心でした。フリーソフトウェアのデスクトップ環境導入支援やフリーソフトウェアを使ったシンクライアントシステムの開発など、デスクトップ分野の案件が多くありました。また「ソースコードがあればなんとかできる」を合言葉に他社で対応できなかった案件や、開発が頓挫しかけた案件を獲得していました。

主な業務

IPAのOSS活用基盤整備事業
- Linux環境における外字管理システムの仕様開発とプロトタイプ作成
- 栃木県二宮町での自治体導入実証事業（OpenOffice.orgの導入支援やデスクトップ環境の整備を担当）
シンクライアントシステムの開発
シンクライアントシステムの自治体導入
マーケティング・デザイン業務の労働者派遣
動画共有サイトの開発（Ruby on Rails）

第2期（2007/7から2008/6）

第1期にIPAの事業を一緒に行なった企業との取引が拡大し、フリーソフトウェア本体へ機能追加する業務がでてきました。またMozilla Japanのサポートパートナーとして、FirefoxやThunderbirdのアドオン開発やサポートを本格的に開始しました。さらにRubyをつかったWebサービスの開発など、民間企業との取引が拡大しました。またこの時期に、CutterやUxUといったテスティングフレームワークの開発を開始しました。

主な業務

IPAのOSS活用基盤整備事業
- 国際標準文書フォーマットの日本語機能拡張開発プロジェクト（OpenOffice.orgの拡張機能開発）
動画共有サイトの開発（Ruby on Rails）
Thunderbird、Firefoxのサポート業務
Firefoxのアドオン開発
フリーソフトウェアの機能追加や性能評価
テスト自動化フレームワークの開発

2代目社長の20代

第2期に黒字化し、取引先も順調に増加しました。フリーソフトウェア開発者集団として、社長はフリーソフトウェア開発者が務めるのがよいとの判断で、第3期に現社長に社長を交代しました。

第3期（2008/7から2009/6）

milter managerをIPAの事業で開発しました。このmilter managerが後の取引先拡大につながりました。また全文検索エンジンSennaを開発していた未来検索ブラジルさんとCutterをつかったテスト開発で取引が始まりました。Mozillaのサポート業務は順調に拡大し、数万人規模の企業への導入支援など大規模な案件が増加しました。

主な業務

Senna、groongaのテスト開発
IPAのOSS活用基盤整備事業
- 迷惑メール対策ポリシーを柔軟に実現するためのmilterの開発（milter managerを開発しフリーソフトウェアとして公開）
Windows用デスクトップ・アプリケーション開発
動画共有サイトの開発（Ruby on Rails）
Firefox、Thunderbirdの企業導入・サポート業務

第4期（2009/7から2010/6）

リーマン・ショックの影響で、Webサービスの開発案件やフリーソフトウェア導入案件が中止となるなど、案件の確保に奔走した1年でした。groongaやデジタルサイネージの開発がスタートし、拡大しました。これらのプロジェクトではお客様の開発チームと一緒に開発することになります。

主な業務

デジタルサイネージシステムの研究開発
groongaの開発
大学へのLinuxデスクトップ環境ならびにmilter manager導入
Firefox、Thunderbirdの企業導入・サポート業務
Firefoxのツールバー開発、Firefoxをつかった研究開発
NICTベンチャー支援事業（モバイル分野の研究開発を行いました。後のデジタルサイネージシステム開発（組込システム開発）参入の基礎となりました。）

第5期（2010/7から2011/6）

2010年8月に主要取引先であるミラクル・リナックスさん、未来検索ブラジルさん、コスモエアさんと資本提携し、この3社との取引が拡大しました。さらにmilter managerの導入案件がきまり、milter managerとmilterの開発がビジネスに発展しました。他にも開発、サポート、システム構築などさまざまな業務が同時に進行し、かつ新規取引先との取引開始も多く、社内リソースが逼迫しました。

主な業務

groongaの開発
デジタルサイネージシステムの開発
社内文書検索システムの開発
milter managerの機能追加とmilterの開発
Sambaの導入とサポート
Firefox、Thunderbirdのサポート、導入支援
メールマガジンシステム開発（リソース足りず外注する）

2代目社長の30代

あんなに若かった社長も30歳を迎えました。

第4期、第5期と激動の2年をすごし、あらためてフリーソフトウェア開発をしたいという思いを社員間で再確認しました。フリーソフトウェアの開発だけでなく、フリーソフトウェアに関する技術情報やノウハウを積極的に伝えることを社長だけでなく他のメンバーも意識するようになりました。

第6期（2011/7から2012/6）

第5期にgroongaの開発とデジタルサイネージシステムの開発が柱となり、お客様のビジネス拡大にあわせて開発体制を強化しました。また、milter managerの大規模導入案件は長期に渡る開発、テスト期間を経て、無事運用開始しました。Mozilla関連では、他のサポートパートナーとの連携やESR版リリースによって企業導入案件が増加しました。導入やサポートに関連して開発したアドオンをフリーソフトウェアとして公開できるよう契約を見直しました。

主な業務

groongaの開発（準委任契約）
デジタルサイネージシステムの開発（受託と準委任）
milter managerの大規模導入案件
Firefox、Thunderbirdのサポート、導入支援

第7期（2012/7から2013/6）

主要取引先との開発案件がすべて準委任契約になりました。クリアコードがお客様の開発チームに対して提供するものを最大化しながら、一緒に開発をすすめていくには、受託よりも準委任という契約形態があっていました。

この時期、新規のお客様からもフリーソフトウェア開発のお話をいただきましたが、一緒に開発するためのリソースが確保できない状況でした。そこでサポートサービスを利用し、設計支援やコードレビュー、障害調査といったサービスを提供して、milter manager、groonga、GStreamerをつかったシステム開発を支援することができました。また、クリアコードの開発スタイルを伝えるサービスとしてコミットへのコメントサービスを開始しました。

主な業務

デジタルサイネージシステムの開発
groongaの開発
milter manager、groonga、GStreamerのサポート
Firefox、Thunderbirdのサポート、導入支援
サーバ監視ツールの研究開発
コミットへのコメントサービス

クリアコードがフリーソフトウェアをビジネスにできた理由

クリアコードがフリーソフトウェアの開発やフリーソフトウェアを使ったシステム開発をビジネスにできたのは、次の2つの要因によるものと考えています。

確度の高い案件からフリーソフトウェアへ貢献できる案件へ

初代社長時代は国の事業が中心でした。また民間企業との取引においてもフリーソフトウェアと関係ない案件も請けていましたし、フリーソフトウェアに関係するものでも本体の開発よりは、システム構築などフリーソフトウェアの導入支援が中心でした。

2代目社長の20代ではmilter managerを開発し、groongaの開発やデジタルサイネージシステムの開発がスタートするなど、現在の事業のベースとなるものが始まりました。しかし契約形態は短期の受託開発がほとんどでしたので、経営を安定させるために、案件が途切れないようにすることを優先していました。そのためフリーソフトウェアとして公開できるできないに関わらず受注確度の高い案件を優先していました。

2代目社長の30代では、フリーソフトウェアへのこだわりを強く打ち出すようになりました。また、主要取引先からクリアコードの開発チームを評価していただき、長期の契約のもと、一緒にフリーソフトウェアやフリーソフトウェアを使ったシステムを開発できるようになりました。その結果、その他の企業との取引でもフリーソフトウェアに貢献できる案件を優先できるようになりました。

フリーソフトウェア活動の広告宣伝効果

クリアコードのはこれまでに数多くの企業と取引をしてきました。一般的に取引先を獲得したいと考えれば、こちらから対象となるお客様に対して営業活動を仕掛けるものですが、クリアコードの場合そのようなコストはほとんどかけていません。もちろんこちらからの働きかけによって取引先を獲得したこともありますが、お客様の多くはフリーソフトウェアに関するなんらかの課題を解決しようと調べた結果、クリアコードを知り、問合せしてきてくれました。

milterであればクリアコードが開発するmilter managerのサイトやククログに関係する情報があり、そこからクリアコードを知って、電話やメールでご相談いただくという具合です。GStreamerやgroonga、Mozillaなどはククログで公開している技術情報がきっかけとなることが多いです。クリアコードのメンバーが業務に関連してフリーソフトウェア開発プロジェクトにパッチを送っていたことを手がかりにお問合せいただいたこともあります。つまりクリアコードはフリーソフトウェアを開発したり、開発に関するノウハウを公開することで、他社から認識され、場合によっては技術力を認めてもらうことができ、取引先獲得につながっています。フリーソフトウェアに関する案件の獲得には、この戦略が実に効果的だったと思います。

まとめ

フリーソフトウェアを開発したりノウハウを公開することが、フリーソフトウェアの開発やサポートを求めるお客様と出会うための有効な手段となりました。真に必要としてくれるお客様と取引できるので、しっかりとしたアウトプットを出すことができれば、信用の獲得と取引の継続につながりました。お客様と長期にわたる取引関係を築くことができたことによって、経営が安定し、より一層フリーソフトウェアに貢献できる案件を優先することができるようになりました。

創業当時にフリーソフトウェアでビジネスしたいと願っていましたが、現在では実現できています。一方で課題もあります。それはフリーソフトウェアを一緒に開発しようと相談していただく新規のお客様にお応えできていないことです。これはエンジニアの不足とエンジニアの育成が間に合っていないことが原因です。インターンシップやパッチ採用を通じた採用活動は、この課題を解決するための取り組みです。クリアコードで一緒に開発してみたいという方がいらっしゃいましたら、是非インターンシップやパッチ採用に応募してください。

この記事の続き

2013-07-24

milter manager 2.0.0 リリース

2013年7月29日にmilter managerの約2年ぶりのメジャーバージョンアップである2.0.0をリリースをしました。

前回ククログでmilter managerを紹介したのはmilter manager 1.6.9をリリースしたときである約2年前なので、milter managerとはどういったものなのかmilter managerのウェブサイトから引用します。

milter managerはmilterを使って効果的に迷惑メール対策（スパムメール対策・ウィルスメール対策）を行うフリーソフトウェアです。

milter managerはmilterをサポートしているSendmailやPostfixといったMTAと一緒に使うことができます。Ubuntu、CentOS、FreeBSDなどのプラットフォーム上で動作します。

メジャーバージョンアップですが、1.8系とは互換性があるため、設定ファイルを変更せずにそのまま簡単にアップデートすることができます。前回のリリースから大きな変更もないのにメジャーバージョンをあげて2.0.0にした理由は、開発が継続していることと動作が安定していることをアピールするためです。

milter managerの前回のメジャーアップデートは2011年6月10日でした。そこから、10回目のリリースが今回のメジャーバージョンアップです。リリースの間隔が6ヶ月あいてしまったこともありましたが、こつこつと改良を続けてきました。マイナーバージョンアップリリースはmilter managerのメーリングリストだけでアナウンスしていたため、メーリングリストに参加していない方々には開発の様子が見えづらいものでした。しかし、メジャーバージョンアップとなると大きなイベントですので、これを機に、メーリングリストに参加していない方々にも、開発が継続していること、milter managerがより便利になり、より安定したことをアピールします。

実際、動作実績が増え*1、ユーザーのみなさんが問題を報告してくださったおかげで、1.8.0の頃よりさらに動作が安定しました。milter manager本体はもちろんですが、Rubyでmilterを書くための機能であるRuby/milterもかなり安定しました。Rubyでmilterを実装する機会が増え、さまざまなノウハウが溜まりました。これらのノウハウがRuby/milterに反映されています。

2.0.0は1.8.0よりも確実によくなっていると自信を持って言えます。これまでmilter managerを使ったことがなかったみなさんもぜひ試してみてください！

milter manager 2.0.0 リリースに対する反応

リリースメールを以下のMLに流したところ、いくつか反応があったので紹介します。

日本語:

英語:

全て個人宛てに返信があったので、メールをくれた方の名前やメールアドレスは伏せます。

海外からの反応1:

I've noticed milter manager, now I will package it into Fedora.

Fedora にパッケージを追加するための作業をしてくれるそうです。いつかやりたいと思っていたことなので大変嬉しいご提案です。

海外からの反応2:

How about writing milters in Python, rather than just Ruby?

Ruby だけではなく Python で milter を書くのはどう？とのことですが、既に pymilter というプロジェクトがあるのでご紹介しておきました*2。

海外からの反応3:

Use milter in postfix will cause the performance drop about 20% due to the implement in Postfix compared to policyD(tested on Postfix 2.3.5, I am not sure if it have been improved in latest Postfix version). That's why I prefer to PolicyD (greylist, blacklist, whitelist, IP reputation/based detection, etc). Content-based scanning will cost a lot of time which may caused session time-out issue. My suggestion is to let MTA do the basic/fast checking and ask other back-end system/module to scan the content.

BTW, it's a great idea to consolidate those milters into one milter mgr. I will try it later.

自分が知っている情報を共有してくれています。PolicyDというプロダクトは知らなかったので、参考になりました。milter manager のアイデアをとても褒めてくれています。こういったコメントはとても励みになりますね！

test-mails プロジェクトを始めました

milter manager 2.0.0 リリースとは直接関係ないのですが、最近milter managerの関連プロジェクトとして始めた test-mails というプロジェクトがあるので紹介します。

test-mailsプロジェクト

test-mailsプロジェクトは、メールシステムのテストに必要なメールを共有することを目的としたプロジェクトです。共有したメールはオープンソースとして利用できるので、だれでも自分のメールシステムのテストに有効活用できます。

メールシステムの開発をしていると、テストのためにとても多くのパターンのメールが必要になります。そのようなメールを個人で集めたり作成したりするのは大変です。そんなとき、自由に再利用できるテストメール集があると便利だと思いませんか？このようなメール集を共有すると、自分で多くのテスト用メールを作成したり管理したりするコストが削減でき、網羅的なテストをしやすくなることが期待できます。

興味のある人はmilter-manager/test-mailsを参照してください。現在はまだ少しだけですが、テストで使用可能なメールを追加してあります。

*1 10万mails/day以上のメールを処理するシステムでも使われています

*2 もちろん、milter managerはPythonで書かれたmilterも組合せて使うことができます。