在宅勤務環境を整備した

2年前に一念発起して組んだマシンがあって、Core i7と32GBものRAMを節操無く積んでいたもののファンの音が気になるとか子供が邪魔をするとか、ディスプレイが小さいとか理由であまり使っていなかった。引越を機会に自分の仕事場がつくれそうなので、これを機会にデスクトップ環境をもう一度整備した。

ディスプレイ

やはりこれが一番大切だろう。必須条件は解像度がいわゆる4Kあること。MacBook Proを使ってRetinaの美しさに慣れてしまった今、これまでの普通の液晶モニタでは何インチあっても意味がない。もともと液晶のサイズそのものではなく、解像度に興味があったので必然だ。本当は海のむこうだと$500とかそういうレベルで変えるらしいのだが、日本に住んでいるのでなんか出てるかなーと思ったらASUSからPB287QIODATAからM4K281XBがそれぞれ出ていた。ぼくは海よりも深い理由からASUSを選んだ。

と、それだけではいけない。なぜならこのディスプレイ、DisplayPort経由じゃないとフル解像度じゃないと表示できないのだそうだ。HDMI規格が悪いのかディスプレイが悪いのかはわからないが、とにかくグラフィックボードも買うことにした。

ビデオカード

@moriyoshit とかいう人によると、LinuxのドライバはGeForceの方がそれなりに動くそうなので、AMD党としては残念だがGTX750あたりを目指して探してみることにする。MacBook Proの最上位モデルはこのボードが入っているそうだからというだけの理由である。もともとゲームはやらないので、そんなに強力な3D性能が必要になるわけでもない。と思っていろいろ探していたが、DisplayPortを持っているボードはELSAだとGTX760からのものしかないらしい。というわけでこれにした。

ELSAにしたのは積極的な理由はないのだが。。。本当はマザーボードと同じメーカーにしたかったのだが、ASRockのZ77 Extreme4という、グラフィックボードを出していないメーカーのマザーボードを使っていたので、逆に、GIGABYTEなどのマザーボードも作っているところはあえて避けてみた。非常に消極的で根拠のないことなのだが。

そういうわけで4Kになった。すばらしい

ちなみに、ドスパラでは、間違った機種をWeb経由で注文しても他社のようにキャンセルはできないので注意。キャンセルの代わりに返品か、同額以上のものに追加で支払って交換してもらおう。

キーボード

人間の両手は、ふつうのキーボードを叩くと両手首が極端に曲がってしまう構造になっている。ふつうのキーボードではもう手首が痛いのでKinesisのエルゴノミクスキーボードを買うことにした。日本だと代理店のエジクン総研から買うのが一番安かった。配達も早かったのでオススメ。この画像のときはまだ全部環境揃ってなかったからMBPで最初に試してたのかな。今はふつうに4Kのディスプレイの前で使っている。

ちなみにこのキーボード、いちおうUS配列を謳ってはいるが、通常のUS配列とは全くの別物で慣れるまでに1週間以上かかると覚悟したほうがよい。仕事で使う場合は、少なくとも3日ほどは練習期間に充てた方がよいだろう。いきなり仕事で使おうとすると、Typoばかりで(自分が)使い物にならないので注意が必要だ。しかし10年以上も使い慣れたものとは全く異なる配列に挑戦するのは、脳の普段使ってない神経をこじ開けていくような気分がしてとても新鮮だった。人間慣れすぎてしまうのもよくない。

マウス

G700sってかいてある。まあこれはあまり使わないので別に何でもよい。スワイプとかXfceにねーし。

椅子

まだ買ってないが、なんかいいやーつがほしい。

まとめ

ちなみに電話会議とかパワポやるときはふつうにMBP使うよ。さて、これでバリバリとErlangを書く!はず…

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が普通に動くようになったという話でした。


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ゆかいに学ぼう!

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

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

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

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

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