Riak CS 1.5 がリリースされました

Riak CS 1.5.0 が米国時間で昨日、リリースされた。OSSになってから1年余りになる。このリリースは、1.4系に残っていた多くのバグをなおしつつ、いくつかのAPI追加を行ったものだ。相変わらず運用まわりの地味な機能追加が多い。また、コレは Riak 1.4系の上で動作する最後のRiak CSになるだろう。1系の集大成だと個人的には思う。思えば一年半、遠くにきたもんだ。いろいろ怒られたり、ちょっとだけ売れたり、ちょっと前には Riak CS上で今をときめくトレジャーデータのシステムが動き始めたりと…

なんでこんなことを書いているかというと、このリリースのために割といろいろ頑張ったからですね。こういう風にあちこちで使われている製品のソースコードに、技術的な難しさはほとんどないとはいえかなりの量をコミットしたのは私の人生では初めてのことなので、これはまたちょっと感慨深いのであった。1.3のときにつくった Bucket Policy もそれなりに使われているみたいなのだけど、あれは新機能の追加がほとんどなので、既存の部分をそこまで理解しなくても作れたのでよかった。それに、後に同僚いわく「あんな短いコードでどうして動くのかサッパリわからん」といわしめたゴルフ力もあって、ちょっと一人よがりなところはあったかなーと思う（今もあるけど）。

1.5.0 のみどころその1: Hadoop MapReduceがちゃんと動くようになった

むかし、Riak CSをHiveのデータソースにするという記事を書いたのだけども、いまいち歯切れの悪い記事であった。それは、PUT Copyが実装されていないせいで、Reduce完了後のファイルの移動に必ず失敗していたのだった。MixiではHadoopの方にパッチを当てて使っていたそうだが、さすがに世界中でそうしてくれというわけにもいかず、Javaを書けないのでHadoopにパッチをコントリビュートする力もなかった。で、今回そのPUT Copyを実装したのでHadoopが普通に動くようになったという話でした。

Yay! Hadoop MapReduce worked on top of Riak CS 1.5.0 beta without any modification!! pic.twitter.com/nwbSn2C5jy

— Not yet diet fat (@kuenishi) 2014, 6月 19

1.5.0 のみどころその2: 削除が速くなった

それまでのRiak CSでも、削除そのものは速いけれども、論理削除はバックグラウンドで動作するGCを待たないといけなかった。このGCが遅くて、シングルスレッドで動いていたり、Riakの新しい効率的なAPIを使っていなかったりでとても遅くて、ファイルの作成と削除があまり多いとディスク使用量が平衡できずに膨らんでいくという問題があったのだけど、とりあえずこのGCを並列動作できるようにして、Riakの新しいAPIを使うように修正していった。だいぶ速くなって、今度はディスクがボトルネックになるようになったのだけど、Riakの削除がこれまた曲者で…ネットワーク分断に耐えるように作るから仕方がないんだけどね。

1.5.0 のみどころその3: 今話題のSparkが普通に動く

http://qiita.com/kuenishi/items/71b3cda9bbd1a0bc4f9e

jets3tを使っているから当たり前なんだけども。

1.5.0 のみどころその4: バグが沢山なおっている（ぇっ

　
お後がよろしいようで。えっ。
　

それではみなさん、バグの報告やPull Requestをお待ちしています。

遅ればせながら「「特許庁業務・システム最適化計画」の改定について」について

Slashdotでみた56億円返還の件で興味が湧いて調べていたら、 「特許庁業務・システム最適化計画」の改定についてというやつを見つけたので目を通してみた。一度失敗したプロジェクトをどう再出発させるのかということと、実社会に直接影響を与えるこのシステムがどういう風になっていくかに興味があるからだ。

28枚という短い文書だが、短いだけに情報が凝縮されていてとても面白い。リンクされているPDFの文書は、平成25年3月という、一作年度末に書かれたものであることがわかる。この文書は、改定前の失敗とかそういったことには一切触れない。おそらく改定前のものと比べながら読んだら非常に味わい深いものになること請け合いであるが、ここではとりあえず措くこととする。

まず、特許庁の業務は大きく分けて、受付発送、方式審査、実体審査、登録、公報発行、審判の6種類があること、そのために平成2年に世界で初めて電子化されたシステムがあることが語られる。それは電子出願、事務（包袋事務処理システムと審査周辺システム）、検索システムに分けられるという。

で、オフコン2台を含むシステムが、とりあえずのペーパーレス化を実現したものの、個別システムの複雑化が起きていて、相互依存、手続きの遅延、データの重複が特に問題だと。で、それらを改善するためにシステムを10カ年計画で段階的刷新するといっている。

他に興味がわいた点としては、

• オフコンのオープン化（久しぶりに聞いたわ
• 多言語翻訳機能などグローバル化、ちゃんとした検索の提供
• 「音や色といった新たな権利客体を取り扱うことになる」
• 審査官が照会するDBとユーザーが照会するDBを一元化する、とかいてある
• 第二期に「ユーザーへの情報提供の迅速化やAPI(Application Programming Interface)の提供の検討を進める。」
• 「「クレジットカード決済」を利用した料金納付を可能とするシステムを整備する。」
• 「データセンタ・クラウドの活用」

個人的に最も興味深かった点はP15だ(以下、引用):

• 業務AP同士の通信を排除し、業務APを疎の関係とすることにより、システム全体の複雑性を低減させ、システム改修時のコスト低減を図る。
• 個別システムにおいて基盤機能とデータベースを分離した後、個別システム間で共通的な基盤機能を集約化することにより、制度改正・運用変更時の影響箇所数を削減し、システム改修時のコスト低減を図る。
• 個別システム間でデータベースを論理的に集約化することにより、システム全体として保持する情報量を低減させることで、システム全体のダウンサイジングを実施し、経常経費の削減を図る。

ぼくには、データベースの集約と個別サービスの粗結合化を進めると書いているように読めるのだが、それは不可能なのでシステムの完成図がちょっとイメージできない。P20には「特実出願系共有DB」なる言葉が登場しているので、それのことかもしれない。ときおり登場する「XML」という言葉がさらに不安を助長する。

クライマックスはP22の工程表だ。今日は2014年度だから、特実出願系DBの開発はテスト工程が4ヶ月目に入っていなければならない。果たしてどのようなDBがまさに今テストされているのだろうか。。。

さて、私の個人の感想を書いておきたい。ひとつは、変化に強いシステムを作る思想に欠けているようにみえるところが心配だ。それは政権が朝令暮改になっているから対応するという意味ではなく、これから技術をとりまく時間の流れは速くなっていく一方なのだから、必要に応じてシステムを迅速に変更できるようになっていてほしい。
もうひとつは、P23の経常経費の試算図が最高にいけてないところだ。要は「少しずつコストを圧縮していきます」と書いている。わたしはコスト構造を時代の流れに合わせて変えてほしいと思っていて、もっというと情報システムに払う金はコストではなくて投資になっていくべきだと思っている。つまり、ハードやネットワークのコストは当然下がっていくが、ソフトウェアや運用にかかる金額はもっと上がっていくということだ。一度に全部つくり直そうとして失敗したことに懲りて、「今度はちゃんとやるぞ」という意志を確かに感じるのだが、失った年月は戻らないしコンピュータ技術はその間に大きく進化してしまった。

さて、このシステムは10年かけて更改してしまったらそれでオシマイだろうか？特許のシステムは100年維持されるものにしなければならない。一度作ったら終わりといってたら未来永劫にわたって完成なぞしないのであって、システムの改善を内包するように設計した方がよいのではと…しかしソフトウェア保守費に15億円ってことは保守だけで150人も維持するのかと思うと、保守だけで終わるのかなぁと本当にドキドキする。

組織の発展段階におけるトレードオフの移行

なんか昔の下書きが放置してあったので、頑張らないでなんか形にしてみよう。

初期：人が少ない

1〜4人
スピード重要
分業なし
自分から仕事を見つけられる人
組織の目標、レゾンデートルをビジネスモデルと一緒に構築していく

中期：人はまだ少ない

5〜20人
発展段階
ある程度の分業役割分担が必要
自分から仕事を見つけられる人
ビジネスモデルはある程度確立される

中長期：人は足りない

20人〜
中期ほどの速度ではないが発展
役割分担が明確になってくる
あまり話したことない同僚がいる状態
上司・部下の関係が登場
　→自分から仕事を見つけられる＆上司による役割分担のマネジメント
マネジメントの間で息が合っていればうまく動く

成熟期：トータルでは人は余るが局所的には人は足りない

数百人〜？
完璧な役割分担
20%のエース
60%の中堅層
20%の遊び層
マネジメントも多様化してくるので、組織の目標がかなり明確でないとダイナミクスを維持できない
（明確でない目標であっても、実力以上の利益があると組織を維持できる）
80%の人間のベクトルが揃う（＝明確な目標）と、かなりのスピードとパワーを発揮する

各段階に共通するトレードオフ：

• 画一性 vs 多様性: あまりに画一性が強くて似たものばかりになると外の世界に関心が向かなくなり、自分たちの論理だけで動くようになる。似たもの同士なので、組織トータルでの馬力は非常に強くなりマネジメントのコストは非常に低いが、外界の変化に対応できにくくなる。ある程度の多様性があると組織としてのまとまりを維持する難易度が高いが、多彩なアイディアが出たり外界の変化に対応しやすい。
• 役割分担なし vs 役割分担と管理: これは全体把握と詳細特化のトレードオフと言い換えてもいい。分業の度合いが低いと、メンバーの流動性が強くリソースの集中投下がしやすくなる。反面、専門的な事柄に弱くなりがち。分業の度合いが高いと、専門性から生まれる競争力を得られる可能性がある。また、分業すると往々にして情報共有と管理が必要になる。
• 投資＋赤字 vs 自己資金＋黒字: 前者は高速なブートストラップを期待できる反面、市場がないところに誤ってブートストラップしてしまうような、フィードバックによる方向修正がしにくい。ターボエンジンを積んでグラベルを走るようなものだ。一方、後者はブートストラップは遅いが確実な進歩、方向修正をしやすい（外界からの干渉や注目も少ないだろう）。一方で自転車操業に陥るリスクもある。

中長期が、ベンチャー企業の死の谷といわれるところで、このトレードオフが揺れているところだからバランス舵取りを間違えると即死する。

「すごい Erlang ゆかいに学ぼう！」という本が7月に出ます

すごいErlangゆかいに学ぼう!

いままでいろんな観点からErlang/OTPに関する本が出てきたが、この本はそのErlangの技術の集大成といっていい本だ。コレ一冊読んでおけば間違いない。他の本は忘れてもいい。あえていうなら、これを読んだ後にもっと詳しい作者自身の哲学を知りたい場合だけ、戦闘機本を読めばよい。だが他の本は別にいらない。内容が古かったりツールを網羅していなかったりするためだ。

原著は Heroku のエンジニア Fred Hebert のWeb記事をもとにした本だ。

Learn You Some Erlang for Great Good!: A Beginner's Guide

このFred君というひとはとてもおもしろい人で、 Erlang Factory San Francisco で夜にネタプレゼンをかまして毎年爆笑をとっている人だ。

とにかく量が膨大で、訳者の山口くんの馬力には感服するしかない。レビューアーが10人ちかく集められたが、レビューアーは誰一人彼の仕事に追いつけずにいた。なにを隠そうこの私もレビューアーとして声をかけていただいて、遅々として進まないレビューで彼を待たせてしまって非常に申し訳なかった。レビューアーとして参加する報酬として本書を一冊いただけることになっているようなので、レビューで読めなかったところを改めて読み返して、知らなかった知識をコッソリ埋めることとしよう。

素晴らしい仕事だった（まだ終わってないかもしれないけど）。みなさん、ありがとう。

追記

出版記念パーティーが開催されることを失念していた。参加条件などいろいろあるが、訳者の山口君に会いたいというひとや、東京のErlang/OTPクラスタが集うので興味がある方はどうぞ。

カンファレンス行動規範 (Conference Code of Conduct)

Conference Code of Conductというものがある。邦訳では会議での行動規範となっているが、これだとちょっとサラリーマンの我々には分かりにくいから、今風の勉強会らしくカンファレンス行動規範と訳した。

詳しい内容はリンク先をみてもらいたい。これは、カンファレンス、勉強会、そのようなコミュニティの集まりにおいて全員が快適に時間を過ごすためのお約束だ。

外資の技術系の会社で働くようになってから分かったことだが、海外では参加者のプロファイルが多様なものになっており、それがコミュニティの多様性や活力になっていることが多い。大抵のカンファレンスではマイノリティが少なからず参加しており、それによって問題が起きたこともある。わずかな問題でもコミュニティの崩壊の可能性があり、全員が快適に時間を過ごすことに少なくない努力を払っている。これによって、多様なメンバーが安心してコミュニティに参加することができるようになる。目的を共有しつつも、バックグラウンドが様々に異なるメンバーが集まるのは、とてもすばらしいことだ。単に人数が多いだけでは駄目だ。

日本で、東京で、テクノロジー系のコミュニティにいると、人種、年齢、性別、年収、そういったプロファイルが極めて似たものになりやすく、気をつけないと同質な人間の閉鎖的な集まりになってしまいがちだ。そうなってしまって悪いということはないのだが、より多くの、多様なメンバーに参加してもらいたいと思うならこのカンファレンス行動規範（と、それへの支持を表明すること）は、初めて参加する側のひとつの安心材料になるのでカンファレンスを実施する側はこれの採用を是非考えてほしい。また、カンファレンスへ参加したり、発表する人間も、この行動規範を参考にすることでよりよい参加者になれるだろう。

米国で飲んだもの

Stranahan's

なんでも、コロラドの蒸溜所で人気がありすぎて予約とるだけで5年待ちらしい。で、5年後に樽や味の好みを知らせて10年寝かせて、そいでやっと手に入るという逸品。Stanley Hotelのバーに行くとホテル確保分が飲めます。

Beer Float

苦めのIPAにアイスクリームを投入するとあら不思議なんともいえない感じ。同僚に強く進められて日中から頂いていたのだけども、…。あとで調べたらギネスビールとかでやるのは一般的みたいですね。

Silk Stout

その名の通り絹のような舌触りなのだけど、わりとコクがあってよい。

映画をいくつか観たはなし

先日渡米する機会があって、往復の中で新幹線を死ぬほど観る時間があったのでとりあえず見れる限りの映画を観た。音質画質など知ったことか。787はやはり快適ですな。UAの食事そんなに悪くなかった。ANAとのコードシェア便だからかな。

アナと雪の女王 / Frozen

英語の勉強のためにまず吹き替え版を見てから英語版を観た。語彙が平易で非常にわかりやすいし、ストーリーも定番ぽく進みながら要所要所で意表を突く展開。有名な歌の "Let it go" はクライマックスで出るのかと思いきやこれまた以外なところで出てきて、実はちょっと悲しい歌でした。というか、わりと序盤で出てきてしまって今後どうなるの？と心配してしまった。

Ironman 3

ついに人類も超進化…

SHIELD Drama

いつのか分からないけど…これは英語で観たのでストーリーが半分くらいしか分からなかったのだけど、大企業で働いたことある身としてはなかなか身にしみる話であった。

ここまで往路の映画。ここから復路に観た映画。

X-Men First Class

Professer X. がなぜProfesserでXなのかがわかるいい話。ErikとCharlesの友情物語なのだけど、悪役の凄まじさが半端ない

300

筋肉侍の映画でしたね。これは修辞が多かったのでおそらく吹替版で観たのが正解。あと画がベルセルクっぽくて、そちら方面好きな人は見れるかも。

Captain America

王道映画。ヒロインのHeyley Atwellの色気が凄まじかった。

The Wolf of Wallstreet

こんなに f word が頻繁に登場する映画は初めてでいったいどうやって吹替とか字幕作るんだとかと心配になるが、やはり英語で観て正解だった。英語なのでストーリーは50%くらいしか分からなかったのだけど、登場人物の台詞を英語で聞けたのでおそらく2,3倍は楽しめている。

ヒロインのMargot Robbieの本物セレブ感を楽しむ映画でもある。

Chris Colfer "Struck by Lightning"

さすがに、立て続けに何本も観たので、これの最初の5分で疲れて寝てしまった。日本で観れる機会があるとよいのだが。

自宅でカルーアミルクっぽいものを作って飲む方法

1. コーヒーを300~400ccほど淹れてブラックで気が済むまで飲む
2. 100~200cc ほど残ったところで同量程度のミルクを注入
3. 写真左から三番目のVanilla Syrupを適当に入れる。おそらく大さじ1~2杯程度
4. 写真左から二番目のアップルブランデーを入れる。おそらく大さじ0.5~1.5杯程度

これでちょっとコップをまわすとあら不思議、かなり甘いカルーアミルクのような味になっておいしく飲める。ぼくはビールの蓄えが家になく、ウィスキーって気分じゃないよなあというときにこれを作る。

アップルブランデーはニッカの宮城峡の蒸留所で買ってきたもの。ネットで画像を探したんだけど見つからなかったので、おそらくは弘前が代わりになると思うけど、バニラシロップと合わさってなんともいえない香りを出してくれる。

Da Vinci フレーバーシロップ クラッシック バニラ 750ml

バニラシロップはこれを使っている。みんな大好きスターバックスでも使っているらしいやつで、妻によると100％ハワイ産の砂糖黍を使っているのだとか。たしかにメープルシロップのような独特の甘みがある（※個人の感想です）。

それではお楽しみあれ。