OSS を運営する上でのルールについて

最近 Accord という ZooKeeper like な OSS をリリースした．その中で，「OSS として守るべきルール」を学んだのでまとめておく．以下の内容は他の人に使われることを目標とした Linux 的な開発に話が偏っているかもしれないので，注意されたし．

学んだことは，以下の3つ．

1. 基本，議論は ML ですべき．
2. コミッタであろうとなかろうと，変更はすべて ML に投げる．
3. ターゲットとしている層の自然言語でドキュメントを記述する．

1, 2 について．

本当の OSS なら，開発がオープンであることをアピールする必要がある．ソースが github に上がっていても，開発プロセス，議論が不透明な場合はコミュニティから不満が出るだろう．Eucalyptus が良い例だ．

また，コミッタのあなたにとって都合が良い変更でも，他のデベロッパにとって都合の悪い変更もあるかもしれない．都合が悪い変更を見たデベロッパは思うだろう...「言ってくれれば良かったのに」，と．あなたがコミッタであっても，議論，変更を隠したままコミットしたら，それは職権乱用であり，信頼を失ってしまうだろう．

"気にくわないなら fork してコードを改変すれば良い．それが OSS" というスタンスの人も居るかもしれないが，fork されたコードのメンテナンスは fork した本人で行う必要がある．もし似たようなプロジェクトがあれば，皆はfork するよりも，よりオープンな競合プロジェクトに移る方を選ぶだろう．

もっとも，競合のプロジェクトが存在せず，独占状態であるのであれば話は別だ．でも，それならプロプライエタリソフトウェアとして商売した方が成功する可能性は高いように思う．

3. について．

当然だが，英語圏の人に使ってもらいたいのに ML やドキュメントが日本語のみだったら使ってもらえない．まずは，狙っている層で ML/ドキュメントを整備すべきだ．

まだまだ自分も配慮しきれていない点も多いので，気をつけたい．その他に気づいた点があったら，追記していく予定．

Thunderbird で受信したメールに対して git am する

git am を用いることで，git format-patch で作成された Singed-off-by (署名)付きのメールをパッチを直接現在のブランチにマージできる[注1]．Mew などターミナルベースのブラウザを使っている場合は問題ないが，ローカルの Thunderbird でメールを管理している場合，パッチをどう Export したら良いのか不明だったので調査した．

結論から言うと，

1. git-format-patch スタイルのメール( [PATCH 0/5] )のソースをThunderbird で表示し，0000.patch - 0005.patchとして保存する．

2. git am 000[1,2,3,4,5].patch 

とすれば良い．もう少し格好の良い方法があれば良いのだが．

[注1] git merge コマンドや git apply コマンドはお手軽ではあるが，パッチを書いてくれた人の署名が消えてしまうので著作権上よろしくない．

スケーラビリティ自体に魅せられちゃいけない

自戒を込めた日記．

IT システムというのは何らかの問題を解決するために存在している．しかし，技術的な面白さから，システム自体にとりつかれていしまう人々が存在する．多くの場合，それは "hacker" と呼ばれている人々に多いように思う．それ自体はすばらしいことだ…仕事にさえしなければ．

仕事の場合，ユーザはITシステムを問題を解決するために導入している．中身がどうなっているかは知ったこっちゃない．言い換えると，ユーザがシステムにお金を払ってくれるのは「実際にある問題を解決しているから」である．「決して技術的に楽しそうだから」ではない．

さて，ここ1-2年で NoSQL という技術が流行している．RDBMSの提供しているセマンティクスのうち一部を弱めて，RDBMS では得ることが難しかった利点を得られる技術と心得ている．例えば，Cassandra は一貫性を犠牲として可用性を高め，さらに数百インスタンスまで書き込み性能がスケールするという．ここで一つ考えてほしいのは，そんなスケーラビリティが必要なサービスがどの程度存在するか，である．

最も分かりやすい例は，MapReduce 2.0 である．彼らは次世代 Hadoop で1万台のスケーラビリティを目標としているが，それを利用するユーザはどこに居るのだろう．恐らく，そのユーザは彼ら自身以外には存在しないのではないだろうか．技術的には面白いし，楽しいかもしれないが，その恩恵を預かるユーザは限りなく少ないであろう．

言い換えると，次世代 Hadoop (のうち，特にスケーラビリティの部分)は，プロダクトとしてのインパクトはさほど大きくない，むしろ小さいのではないだろうか．

• 何のためのスケーラビリティなのか．
• 何のための可用性なのか．
• 何のための機能なのか．

研究をする上で，これらを自身に問い続けなければならない．さもなければ，使えない研究成果が世に出てしまうだろう．これを心に留めて，研究をしていきたいと思う．

P.S システムの話を主にまとめてみたが，これはエンドユーザ向けのサービスにもいえることだと思う．つまり，「これまでのサービスで解決されていなかった問題を新しいサービスで解く」というものでなければユーザはつかないだろう，ということだ．

fluent-logger-scala について

fluent-logger-scala の設計についてまとめておく．
概要図は以下の通り．
|fluent-logger-scala| <-- |Serialized JSON over TCP| --> |fluend|

検討事項

1. 通信部分のシリアライズ方式について
   MessagePack-Scala は以前試したところインストールに失敗したため，JSON を用いる．ライブラリは com.twitter.util.JSON を用いる．
2. スレッド構成について
   fluentd への書き込みは，ネットワークを介するためブロックする可能性がある．ログをとる部分でブロックしてしまうと，アプリケーション性能に大きなインパクトを与えてしまう．この問題を解決するため，送信用 Actor を用意する．fluent-logger-scala をセットアップすると，送信用 Actor(スレッド) が立ち上がる．
3.  バッファ管理について
   自前で管理するのはしんどいので，com.twitter.util のリングバッファ(com.twitter.util.RingBuffer.scala)を採用する．
4. エラー処理について
   今のところは指数的にリトライの時間を増やしていく方式をとる．
5. API
   初期バージョンでは， Log.setup, Log.log，Log.close のみを実装する．

後は，実装が終わったらここに追記する予定．

RabbitMQ のクライアント

RabbitMQ  のクライアントについて調査したので，主観をまじえてまとめておく．
まずは python．

1. pika : 一番枯れている RabbitMQ クライアント．ドキュメントを見る感じだとbasic_publish() が非同期に呼べなさそうであった．
2. puka : 操作をすべて非同期で処理を行えるために pika を再設計したクライアント．しかし，まだまだ安定していない．

次に Ruby．

1. amqp : AMQP 0.91準拠のクライアント．AMQP の仕様がそのまま実装されており，高機能な分学習コストが高い．
2. carrot, bunny : 同期操作のみを行える AMQP クライアント．bunny の方が開発が盛んなようである．同期操作しか実装されていないため，シンプルで安定している．

コードを含めた解説は後で書く．pika が安定しているが，非同期呼び出しができなさそうなので悩ましい．現在 ML に問い合わせ中なので，判明し次第追記していく．

#include <stdio.h>
int main(void)
{
    // Hello World!
    printf("Hello World !");
}