HBase論争に釣られてみる

HBaseコミッター達による、NoSQLの記事への反論が面白かったので翻訳してみました。

著者の許諾取得済み。Thanks Stack and the other authors!

本文

原題: Taking the Bait


Information Weekは先日、「HBase はNoSQL を支配するのか?」という記事を掲載した。MapR の Michael Hausenblas は HBase の事例に「賛成」の論陣を張っており、Apache Cassandra の Jonathan Ellis とベンダーである DataStax は「反対」の側だった。

この「ディベート」をベンダーのセールストークとして却下し、Apache HBase に立ち戻り、HBase を使用し、改善していくのは、簡単な話である。しかし、この記事は特別に問題のある例だった。記事では、「賛成」と「反対」の双方とも、HBase コミュニティの仕事にはほんの少ししか言及していない。ここでは誤りを訂正する目的で、いくつかの点に言及したい。

まず、Michael は、Hadoop が急速に成長しており、そして、HBase は Hadoop から出てきたのであり、緊密に結びついているのであるから、HBase は上向きの上向きだ、と論じていた。HBase コミュニティの積極的な参加者でなければ、このような仮定を立てるのは容易である (HBase によって Hadoop の採用を推進されているところでは、その逆に出くわすことにもなる)。
Michael は次に、古い一貫性対 eventual-consistency の戦いに話を焼き直し、飽き飽きする HBase 対 Cassandra の機能比較に切り替えた。そして、最後には、Cassandra の源泉である Facebook がデータ保存のために、大きなサイズのいくつかのアプリの代わりに HBase を使用することにしたというだけの理由で、HBase の方が良い、と結論づけた。我々はその種の論争などしない。Apache HBase か Apache Cassandra を活用すべきであるかどうかは、多くの要因によるのであり、多くの規模の問題と同様に攻撃的な言い争いに巻き込まれすぎているといえる。


その次に Michael は、「我々は企業向けの HBase の「次のバージョン」を作り上げた・・・。我々は2013年5月に M7 のラベルの下でその新しいバージョンをGAにもたらした」と語り、おとり商法を行った。この引用での「我々」というのは、Apache HBase コミュニティのことを述べているのではなく、Michael の雇用主であるMapR Technologies のことを指している。また、Michael が言及する「企業向けの HBase」というのは Apache HBase のことではない。M7 というのは、我々が知る限り、構造上 Apache HBase とは根本的に異なっている、プロプライエタリの製品である。その製品はソースが明らかにされていないのであり、我々はこれ以上は言及できない。この話は、Apache HBase コミュニティが長年にわたり、ハードワークと、Apache HBase 以外の商業的なクローズドソースの製品への寄与を通じて築き上げてきた信用と善意をいただいてしまおうとする試みと見えた。


次は、Jonathan の「反対」の論に言及してみたい。Jonathan の主張のいくつかは今はもう真実ではないか、大いに主観的である。真実でないというのは、「RegionServer のフェイルオーバーは10分ないし15分かかる」という箇所である (HDFS-3703 および HDFS-3912 を見てほしい)。主観的であるというのは、「HBase をもとに開発を行うのは苦痛だ」という箇所である (我々の意見では、我々のクライアントAPIは、一般的に使用されているCassandra クライアントライブラリよりも簡単で使いやすい)。これら以外のものについては、どれもメーリングリストから Quora に至るフォーラムで何年にもわたり論議・再論議してきたものばかりだった。Jonathan の論は大部分は、我々が Apache Hadoop の HDFS ファイルシステムと緊密に結びついていることと、 Google BigTable アーキテクチャの輪郭をなぞっていることから来るものを、列挙しているだけである。HBase は HDFS の多くの機能を利用し、BigTable からは着想を得ている。その結果として、Cassandra にとっては問題となるユースケースのいくつかを、我々は得意としている。逆もまた真である。我々のユーザーが使用するハードウェアは進化するのであり、あるいは、新たなユーザーが新しいユースケースをもとにした経験をもたらすのであり、我々も HDFS もじっとその場に立ち止まったままではいない。


彼は、アプローチの違いを強調している。


我々は協調させるために、Apache HDFS の採用、Apache Hadoop MapReduce の統合、および、Apache ZooKeeper の使用を選んだことを、健全な関心の分離と見なしている。HBase は歴戦のコンポーネントで構築されている。これは特徴であり、バグではない。


Jonathan が組み込まれたクエリ言語やセカンダリインデックス機能をコア Cassandra に必要な複雑化と見なすのに対し、我々は、Salesforce の Phoenix のようなプロジェクトを、Apache HBase を中心とするより大きなエコシステムの一部である見なし、支援する。Phoenix の人たちは問題のその部分にドメインの専門知識をもたらすことができるが、我々 (HBase) は、安定したパフォーマンスの高いストレージエンジンコアを提供することに焦点を当てることができる。Apache Hadoop をここまで成功させてきたものの一部は、プロジェクトを支援し豊かにするそのエコシステム、HBase を含むエコシステム、である。そのようなエコシステムが、HBase の周囲で発展してきた。


Jonathan が、HBase コミュニティのことを「リーダーシップ」が分散されているために「断片化」されていると評する方向へとそれていくのに対し、我々は、そこで言及されているのはたぶん、Apache HBase プロジェクトは「所有」されたプロジェクト、つまりたった1人のベンダーに導かれたプロジェクト、ではないという事実であるのだろうと考えている。むしろそれは、多くの組織、ほんの数例をあげれば、Cloudera、Hortonworks、SalesforceFacebook、Yahoo、IntelTwitter、および Taobao ということになるが、それらの多くの組織からの多くのチームがみな協力してそのプロジェクトを推進していこうとしている、そのようなプロジェクトなのである。Apache HBase コミュニティのほとんどは、2つのブランチでの共同作業に参加している。ブランチの1つは新規の0.96のリリースに関するものであり、もう1つは現在の安定したリリースである0.94に関するものである。Facebook もまた、共有されているソース管理リポジトリにおいて、Facebook 独自の Apache HBase のブランチをもっている。このブランチはインスピレーションの源泉になっており、ときに他のブランチへの直接的な寄与となっている。我々のコミュニティのニーズと要望に応じた便利で効率的な協力モデルを発見したことについて、我々は謝罪するつもりなどない。たった1人のベンダーに導かれた他のプロジェクトにとっては、このことは完全に最適化されていないか、場合によっては混沌 (「断片化」) とすら見えることだろう。


我々はこれはそのまま残しておく。

いつもと同じように、我々は、我々のコミュニティと Apache HBase プロジェクトへのあなたの参加と寄与を歓迎する。我々には、偉大な製品と、特定の商業体への恩義がなく、エゴのない、摩擦の少ない意思決定プロセスとがある。もしあなたがかかなければならない痒みがあって、Apache HBase が解決策ではないかと思うのなら、あるいは、あなたが Apache HBase を使用していて、もっといい改善案があるはずだと感じるのなら、我々のところにやってきて、大いに話をしましょう。

自分でお金を稼いで日本へ寄付した中学生の少女達の話

一応前回の記事を読んでない人のために説明しておくと、ただ今アメリカのパロアルトというところに仕事で来てます。


先日、Caltrain*1 の電車待ちをしていたとき、暇潰しにベンチに捨てられていた新聞を読んでいました。その中にあったのが、今回翻訳した記事です。

サンマテオ*2に住む中学1年生の女の子達が、$1200 ほど、つまり日本円にして 10 万円を寄付したという話です。それもただ寄付したのではなく、自分達でお金を稼いだというのですから驚きです。

「なんだ、ただのチャリティイベントじゃないか」

と思うかもしれませんが、私が感動したのは中学1年生の子供たちが、自分達で考えて行動し、自分達で価値を創造し、その価値を売った対価としてお金を得たという点です。ただ募金を募るだけじゃなく、小さな子供がこうやってわざわざ汗水流してお金を稼いで寄付してくれるなんて、すごいと思いませんか?

原文には代表の女の子の写真も載っていますので興味のある方はご覧ください。利発そうな顔立ちをしています。


というわけで、原著者と出版社に許可をとって翻訳してみました。翻訳で契約書かわしたの初めてです。

サンマテオの中学一年生のグループ、日本のために手作り菓子を販売

Original Title San Mateo seventh-grader's group sells baked goods for Japan
Author Alexis Terrazas
Japanese Translator Sho Shimauchi (@)
Original URL http://drupal.sfexaminer.com/local/3-minute-interview/2011/05/san-mateo-seventh-graders-group-sells-baked-goods-japan


Kate Huddleston さんは、サンマテオの Abbott Middle School に通う中学一年生で、東北地方太平洋沖地震の支援のために2回に渡るお菓子の販売で1,204ドルを稼いだ5人の12歳の少女達の一人です。今週水曜日、Huddleston さんと友人の Olivia Gingold さん、Michelle Wong さん、Adelle Buencamino さん、そして Arianna Richwood さん達はその売上を Burlingame's American Red Cross に寄付しました。

なぜあなた達はこのような慈善活動をしようと思ったのですか?


私達は皆、幸運にも現在のような生活を送ることができています。私達は、日本の皆さんがどれほど苦しんでいるかを目の当たりにしています。日本の皆さんが失ったものを取り戻すには何年もかかるでしょう。私達は少しでも日本の皆さんを手助けできればと思ったのです。

このアイデアはあなたの発案ですか?


私がこのアイデアを思いつきました。私は友達の元に駆け寄ると、みんなすぐに賛同してくれました。

今までこのようなことをしたことがありますか?


全くの新しい経験でしたが、とても楽しかったし少しでも助けになれたらうれしいです。

お菓子作りは好きですか?


お菓子作りは大好きです。毎週のように作っています。だからこのアイデアを思いついたのです。

あなた達は今後も困っている人を助ける活動をしますか?


She Is Safe*3という、インドネシアで奴隷にされている女の子達を助ける活動に取り組みたいです。来年中学2年生になったらやろうと思っています。


著作権表示

Copyright 2011 San Francisco Examiner. All Rights Reserved.

*1:サンフランシスコとサンノゼの間を走る電車

*2:サンフランシスコの南にある街

*3:http://www.sistersinservice.org/ 現在はまだ Sisters In Service という名前だが、近日中に She Is Safe に改名するらしい

CentOS6開発プロジェクトの現状

先週、CentOS 6 はいつ頃出るのかどうか、ふと気になりました。
リリース予定もニュースにならないし、どうしたのだろうと調べていたら、CentOSの開発MLが荒れていることを知りました。
不安を感じた私は調査を続けました。
すると、LWN.net の一つの記事に、CentOS の開発の現状について書かれたものがあることを発見しました。
それを読んでまず知ったのが、CentOS は単純に RHEL のソースをリビルドするだけではなく、かなりの労力を費やして作られるディストリビューションであるということです。
そして、開発コミュニティの運営に苦戦している CentOS 開発チームの姿がそこにはありました。
この記事は是非多くの人に読んでもらいたいと思い、何人かの人にレビューをお願いした上で翻訳してみました。

それでは本編をどうぞ。

CentOS 6 の困難、立ち向かう人々

Original Title CentOS grapples with its development process
Author Nathan Willis
Japanese Translator Sho Shimauchi (@)
Translation Reviewer nhoriguchi (@)
Shintaro Shirai (@)
Tomoyuki Okubo
Hiroki Ishikawa (@)
Original URL http://lwn.net/Articles/417849/

2010年12月1日

CentOS(コミュニティエンタープライズオペレーティングシステム community enterprise operating system) という Red Hat Enterprise Linux (RHEL) をソースパッケージからリビルドした OS は、最近次のリリースにあたる CentOS 6 の開発を始めた。しかしながら、パッケージリポジトリ構成やインストール用の提供物の再構築に関する開発チームの議論と、全ての重要パッケージのレビューやテストフェーズに新規ユーザを呼び込むことの困難ついての白熱した議論もあり、開発プロセスの序盤は順調ではなかった。

CentOS はコミュニティが開発したディストリビューションであるのだが、「RHEL とソースレベルで明確に互換性のある派生物」であるが故に例えば FedoraDebian とは大きく異なる QA*1 とリリースプロセスを取っている。Red HatGPL 遵守の一環として、それぞれの RHEL リリースに対してソース RPM を提供している。CentOS ボランティアは新しいリリースが落ちてくると、手分けして全てのパッケージに Red Hat の商標が含まれていない事をじっくりと調べる。CentOSが提供するパッケージから Red Hat の商標を取り除くか置き換えなくてはならないからだ。

これにはロゴ画像や文字列によるブランディング、加えてその他ユーザを「Red Hat と関係がある、あるいは Red Hat 製である」と思わせるようなものはなんでも含まれる。例えばアートワークパッケージなど、着手すべき明らかなものもいくつかあるが、メニューから RPM の spec ファイルに含まれる %description 行に至るまで全て除去・置換されなければならない。この修正は単純な検索置換だけで済むとは限らず、さらに自動バグレポートツール(ABRT)のような Red Hat Bugzilla に関数レベルでリンクしているものもパッチを当てなければならない。このプロセスを完了して初めて、開発チームは 最終的に DL 可能となる ISO インストールイメージに含まれるビルドとパッケージング QA の段階へと移る。

新しい upstream ソース

RHEL 6 のソースは、11/10 にリリースされた。これはその前のメジャーバージョンであるRHEL 5 から 3 年以上経っての事である。base ディストリビューションのサイズは大幅に増加し、現在は DVD サイズの ISO イメージ 2 枚に及んでいる。さらに、RHEL 6 は 4 つのバージョンをリリースしている。サーバ "Server"、ワークステーション "Workstation"、ハイパフォーマンスコンピューティング (HPC) コンピュートノード "ComputeNode"、そしてデスクトップクライアント "Client" である。RHEL 5 のときは 2 つだった(デスクトップ "Client" と サーバ "Server")。

この変更によって CentOS 開発者達は、管理者が数 GB のフルイメージをインストールすることなく機能的な最小サーバをセットアップできる「軽量な」インストールイメージと同じように、サーバやワークステーション版を分割する可能性を含めて再検証しなければならなくなった。過去には、一部の開発者はメーリングリスト上で一つのインストールプロファイルを異なるイメージに分け、RHEL の提供物との互換性をより重視したメンテナンス方法に関心を寄せていると表明したこともあったが、CentOS としては単一 ISO イメージにまとめるアプローチを続けていた。

現在、ワークステーションとサーバを単一プロファイルのままにし続けることでコンセンサスが取れているようだが、RHEL 全体のサイズによってはパッケージを "core" と "extra" DVD に分けざるを得なくなるかもしれない。最小インストールオプションはまだ議論中だが、おそらくそうなりそうである。ゴールはサイズを CD に入る程小さくして USB メディアや仮想マシンで利用したりネットワークに繋がれていない環境でもデプロイしたりできるイメージを提供することである。

いまだに解決していないのはパッケージの再構築問題である。CentOSRed Hatサブスクリプションベースの Red Hat Network 更新サービスを、ユーザに更新パッケージを提供するための yum リポジトリに置き換えている。CentOS はそれぞれのリリースに 7 年間の更新をサポートするので、リポジトリを適切に再構成することは重大な決定である。議論の要点はパッケージを "os" と "updates" リポジトリだけに分けるかどうか、あるいは一部の主要でないパッケージを "optional" と "optional-updates" リポジトリに分けるかどうかであるが、これらはインストールメディアを 2 つの DVD に分ける方法に酷似したものになるだろう。

Round 1 と新しいコントリビュータ

さらに異論が多かったのは「Round 1」パッケージ監査プロセスという第2 QA プロセスに関する活発な論戦だった。またそれは、開発に関わろうとする新規ユーザにとって高い参入障壁だと皆の目に映った。RHEL 6 がリリースされた直後の 11/11 に 主要開発者の Karanbir Singh が CentOS 開発メーリングリストに "step one" というタイトルで、助けを呼びかける投稿を行なった。そこで彼は興味のある人達に商標監査プロセスに参加してほしいと呼びかけた。

2週間以上経っても、事態はほとんど進展しなかった。これは今まで RHEL ソースコードが落ちてきてから 6-8 週間以内にリリースしてきた CentOS にとって特に厄介な問題である。多くの CentOS ユーザは Red HatRHEL 30 日無償トライアルをテストすることから始めるので、ソース互換性のある CentOS アップデートの数週間の遅れはそれらのユーザをとても不安にさせるのだ。

Singh と他のパッケージャーの激しい言い争い(控えめに言っても脱線)に苛立った開発者の Florian La Roche は、Singh が開発プロセスを十分オープンにしていないからだと非難した。Singh は再びメーリングリストに書いて、「なんか思い込みの強い人がいるようだな」と不満を述べた。つまり、彼は進んで取り組んでくれと頼んだのにほとんど誰もやってくれないから、結果として「いつものメンツ」がやることになり、それは理想のペースより遅いんだ、と不満を漏らしたのだ。

多くの人々がオープンソースの仕事とはそれをしたい人のやり方でやる、だからあなたは何をしてほしいか彼らに言うことはできないと主張するだろう、そして彼らは彼らのしたいときにしたいことをする。多くの人が想像する「したいこと」とはオープンソースの流儀で「楽しい」もののことである。幸か不幸か我々はそうした贅沢ができる(できない)。パイプから出てくるものは対処する必要がある。それは時には我々がやりたいと思うものだったり、目の前にあるからやらなければならないものだったりする。

メーリングリストの議論を解決するのはいつも扱いにくいものだが、この件はいくつかの要因が重なって関係者全員をいらだたせているようだ。第一に、Singh はボランティア達に進んで取り組むように頼んだが、だれも進んで取り組もうとしなかったと認識していることである。第二に、新規ユーザはどうやって取り組むのか、Singh が有意義な指示を提供しなかったと認識していることである。具体的に言うと、Singh はメーリングリストに作りかけの wiki ページを示し、監査プロセスのいくつかの重要なステップをドキュメント化しないままにしているのだ。例えば、幾つかの情報源となる URL は "coming soon" と書いてはあったが、空のまま。wiki やメーリングリストの投稿には監査/未監査パッケージ一覧がどこにあるのか、バグトラッカーに投稿するときはどんなフォーマットにすればいいのか、といったことも書いていない。

第三に、何人かの読者が Singh が議論において彼らの質問の要点への反応ではなく他の投稿者の文法や言葉の選択をこき下ろすので「細かいことにうるさい」と責め立てたことである。第四に、監査と QA プロセスが技術的に機能していたとしても、部外者である新規ユーザからすれば非常に不透明であり、彼らがその状況に苦しみを感じていたことである。Douglas McClendon は 適切に整形されたバグレポートの文書例が不足していること、作業の現在状況を追跡する全体の「プログレスバー」がないことを指摘した。

幸運にも、ようやく全員の頭は冷えてきて、新たにコントリビュータになろうとしている人達は彼らの必要としている文書形式の、より掘り下げた説明を投稿した。Singh もまた要望に応え、参加方法と必要な書式を明らかにし、また「建設的だ……我々は 2 週間前にこうした議論をすべきだったのだ」とも発言した。Round 1 において商標問題をチェックしたかどうかをトラックできる AuditStatus ページもできた。*2

ボランティア不足はもちろん CentOS に限った話ではないのだが、このディストリビューションの性質上、エンドユーザの中からマンパワーを持ってくるのはさらに大変である。デスクトップ用途のディストリビューションと違って、クライアントのためにシステムを展開する請負業者が CentOS ユーザーの多数を占める。彼らは確かに知識の塊であり、メーリングリストで活動する傾向にある。しかしインストールベースで見た時のもう一つの勢力は、RHEL や他のエンタープライズサーバディストリビューションの手堅い代替手段として環境を提供しているような商用 Web ホスティングサービス事業者である。残念なことに、多くのホスティングプロバイダは開発プロセスに参加していないようである。もし参加するのなら、パッケージ監査とテストだけでも、かなりの貢献を生み出すことだろう。

コミュニティ

全てのオープンソースプロジェクトはある種のこうした「開発プロセスの改善」問題に苦戦している。Singhにしてみれば、新たな開発者には過去の CentOS リリースのバグレポートを見て、どうやればいいか事前に準備してこないものもいるように見える。一方、より好ましい書式があると Singh がいうのなら、その書式を示すべきだったのは明らかだ。

同様に、wiki のドキュメンテーションとメーリングリストでの議論の間の隔たりは混乱を助長する一因になっている。Singh が送った最初のボランティア募集メールでは、wiki 上に存在しない「http://bugs.centos.org」について触れていた。彼にしてみれば、彼はそこに最新の情報を提供しようとししていたのだが、新しい開発者にとっては、更新されないままの wiki にリンクを貼った Singh の意図が全く分からなかった。

いい文書を書くことは決して易しくないのだが、オープンソースプロジェクトはもっぱら「ドキュメンテーション」を エンドユーザーマニュアルやチュートリアルという観点で考えすぎである。CentOS の例からも分かるように、開発プロセスのドキュメンテーションがプロジェクトの死活問題までも左右する。たった一年ちょっと前に CentOS がリーダーシップの危機に直面したことを考慮すると、ベテランのコントリビュータのリーダー無しに「よりよい作業方法」を得ること、またそれを一般に入手可能なリソースにすることは、今までいたコントリビュータが居なくなってしまった時のためだけではなく、単に次のレベルへのステップアップの求めに応えようと関心を持つユーザを開発に引き込むために、取り組む必要のあることである。

著作権表示

Copyright 2010 Nathan Willis. All Rights Reserved.

*1:品質保証

*2:しかしこのページは 2010/12/03 を最後に更新されていない(2011/01/23現在) http://wiki.centos.org/QaWiki/6/AuditStatus

お金の重要性

2007年Stanford大学で行われた、現Better Place社CEO、Shai Agassi氏の講演会のビデオが面白かったので翻訳してみました。

mp3版では45分とボリュームがありますが、今回訳したのは2分ほどのビデオ版です。

講演の一部ですので前後関係が分からないと完全に意味がとれないでしょうが、これだけ読んでも十分楽しめると思います。

それではどうぞ。

Original Title Importance of Money
Speaker Shai Agassi
Broadcaster Stanford University
Japanese Translator Sho Shimauchi
Original Video URL http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1712


お金の重要さについての話をしよう。今私が辞めると、みんな同じ質問をする。
「で、君にとってお金って何なんだよ?」
彼らに答えるのと同じように答えると、お金とは空気のようなものなんだ。

もし君達がお金を稼ぐためにビジネスをやるのなら、既に間違ったビジネスをやっている。でももしお金の意味について考えるのなら、君達は空気を感じることはない、今この瞬間にも大量の空気が私達の周りにあるんだ。空気を感じるのは本当に難しい。いつ空気を感じる? 空気がないときだ。真空中にいれば、空気のありがたみがわかるだろう。

同じことがお金にも起きる。お金を持ってないときに、お金を感じることになる。私達はその晩、初めてお金というものを感じた。私はその晩だけで2週間分の給料を使った。さんざん交渉した後、私は事実上有り金全てを会社に突っ込んだ。夜、私は父とこのままもう2週間やり続けたいという交渉をした。窓を開けバルコニーに出ると、そこには満月があった。私は自分に言い聞かせた。
「私は月を買えるだけのお金を手に入れた。月が沈めば、私も出て行くんだ」

そのときこそお金を勘定するときであって、それ以外の日はダメだ。後で問題になることはない。君達がたくさんのお金を稼いだとき、本当に本当に喜ぶのはたった一人、君達のプライベートバンカーだけだ。なぜならある程度の時間が経てば君達はお金をつぎ込めなくなるが、君達がもっと稼ぐときに必ず彼らももっと稼ぐからだ。

だから、お金を時間の尺度として考えるんだ。そして自身が砂漠を歩いているように考えるんだ。アントレプレナーは根っからの楽天主義者だ。私達は必要な水の半分しか持たずに歩いて砂漠を横断するけど、それは旅の途中のどこかでもっと水が見つかるということを知っているからだ。それは必ずしも正しいとは限らない。君達は常に、本当に必要な分よりも少ないお金で全てを成し遂げられるよう考えるんだ。

会場にいらっしゃる方でベンチャーキャピタルの人はどれくらいいますか? これが彼らのビジネスモデルだ。彼らは君達が楽観主義者だということを知っている。実際、彼らはそれに応えてくれる。彼らは君達の大切な友達だ。良くみなさい、彼らは水を持っている。そして君達は持っていない。



Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

API: 「使いやすさ」対「誤用しにくさ」

Linux カーネル開発者 Rusty Russell のブログより、API 設計・開発における考え方について書いた記事を翻訳しました。

Original Title APIs: "Easy to Use" vs "Hard to Misuse"
Author Rusty Russell
Japanese Translator Sho Shimauchi
Original Document URL http://ozlabs.org/~rusty/index.cgi/tech/2008-03-18.html


使いやすく作ることは、API の設計における基本的な目的である。自分に使いやすく、一年後の自分に使いやすく、他の人に使いやすくすることである。それを前提としよう。

いくつもの目的が「使いやすい」ことと対立するが、最も扱いが難しいのは誤用しにくいことという要件である。扱いの容易さはユーザを惹きつける、しかし誤用の困難さはユーザを生き残らせるのだ。

この概念をはっきりとさせるため、実生活における2つの例を挙げよう。一つ目は銃の安全装置である。誤用しにくさは使いやすさを駆逐する。

2つ目の例は Linux カーネルの kmalloc 動的メモリ割り当て関数である。この関数は2つの引数をとる。サイズとフラグである。最も一般的に使われるフラグ引数は GFP_KERNEL と GFP_ATOMIC だ。この例では他のフラグは考えないものとする。

このフラグは突然メモリが枯渇したときにアロケータがどうすべきかを示す。メモリが解放される、あるいはスワップアウトされるまで待つ(スリープする)べきか(GFP_KERNEL)、即座に NULL を返すかだ(GFP_ATOMIC)。しかしこのフラグは完全に冗長である。kmalloc() は自身でスリープ可能かどうか把握できるからだ。malloc() を実装するのに何も頭を使う必要はないし、カーネルコーダーにとっては普通は使いやすいだろう。ならなぜ使わないのか?(訂正:Jon Corbet が特定の設定においてはこれは全くの冗長というわけではないことを指摘してくれた。我々はもう数行余分な仕事をする必要がありそうだ。)

なぜならアトミックな割り当ては避けるべきだからだ。有限の領域から取り出すので、失敗しやすくなるか他のアトミックな割り当てを失敗させやすくなるだろう。こうした仕様を作者に明記させることで、我々はアトミックな割り当てを発見することが容易になり、そのため誤用しにくくなる。

そして我々が API を誤用しにくいように作りたいなら API の得点を測る必要があるが、それは次の記事のテーマとしよう。

Creative Commons License
This work is licensed under a Creative Commons Attribution 2.5 Australia License.

Linus Torvaldsインタビュー

1年と1ヶ月かかりましたがようやく公開。

本当は2月3日*1に公開するはずでしたが、私の不手際でちょっと遅れてしまいました。

http://www.linux.or.jp/JF/JFdocs/Open-Voices-Linus-Torvalds-Part-I.txt
http://www.linux.or.jp/JF/JFdocs/Open-Voices-Linus-Torvalds-Part-II.txt

2008年1月〜2月に The Linux Foundation で公開された Linus へのロングインタビューです。
ひたすら長い(A4で40枚ぐらいだったと思う)のでブログの1記事と思って読むとしんどいかもしれません。

時間に余裕のあるときに、お茶でも片手に読んでいただければ。



この翻訳は色々な人の協力があったからこそ完成しました。

レビューしてくれた人、アドバイスくれた人、ドラフト版を読んでくれた人、etc...。

皆さんの支えなしには完成しませんでした。

今一度、感謝の言葉を捧げます。

*1:インタビュー後編の公開日からちょうど一年

Google の面接を受けてみた

Google の面接について書かれたブログ記事が面白かったので翻訳してみました。
原著者の許可取得済み。(Thank you, Petris!)

本文


二週間ちょっと前、ぼくはカリフォルニアのマウンテンビューで Google の面接を受けてきたんだ! Google の面接が面白い体験だったから、ぼくはそのことを話したいんだ。(Google からはこの記事を出すゴーサインをもらった)

ぼくが面接を受けた職種は Google SRE だった。SRE というのはサイト信頼性エンジニアリング(Site Reliability Engineering)という意味だ。サイト信頼性エンジニア(SRE)はソフトウェアエンジニアでもあり、システム管理者でもあって、Google の製品サービスを端から端まで責任を持つんだ。

合計8回の面接があった。最初の3つは電話越しで(電話面接)、残りの5つは現地での面接だった。リクルーターとの最初の面接はそれほど技術的じゃなかったけど、残りの7つの面接はとても技術的な話だった。

どの面接もとてもうまくいったけど、ぼくは採用されなかったということを今知らされたんだ! 仕方ないか……。個人的にはぼくは本当にうまくやったと思う。ぼくは全ての質問に答えた、でも彼らは満足しなかったみたいだ! リクルーターはぼくに、ミッションクリティカルのチームで働くには経験不足だった、だからもっと経験を積んでから再挑戦してね、って教えてくれた。

これがその出来事の記録だ。

ぼくが「Google Chrome におけるコード再利用について(Code Reuse in Google Chrome)」を投稿した少し後、Google のリクルーターからコンタクトを受けた。メールによると、

私は Google で一流のソフトウェアエンジニアリングの才能を持つ方を募集しています。ワールドクラスのエンジニアと思われる方としてあなたのお名前をお見かけして興味を抱き、あなたのことをより詳しく知りたいと思っています。私達のことについて詳細な情報を交換する方がお互いにとっていいことであると断言いたします。

お話に興味がありますか? Google で影響力のあるプレイヤーになりたいですか? それならば現在のあなたの履歴書(英語)をお送りください、あなたにお電話差し上げて話し合いをいたします。


ぼくは最初ソフトウェア開発の職種に応募しようと思っていたんだけど、ぼくのスキルセットに目を通してから、SREの方が合っているとリクルーターは結論したんだ。ぼくは彼に同意した。この職種はぼくにとって完璧であるように見えたんだ。ぼくはプログラミングと同じくらいシステム管理が大好きなんだ。

一次面接(電話)


最初の面接は9月10日にリクルーターと実施した。彼は Google の採用プロセスについて説明し、それからぼく達はぼくのスキルセットについて話し合った。ぼくは自分自身について、一連の分野に 0-10 のランク付けをした。Cプログラミング、C++プログラミング、Python プログラミング、ネットワーク、アルゴリズム、データ構造、分散システム、Linux システム管理、などなど。

さっきも言ったけど、ぼくの回答をもとに、ぼく達は SRE がぼくにとってベストな職種だって結論づけた。SRE は基本的にあらゆることを知らなきゃいけない。アルゴリズム、データ構造、プログラミング、ネットワーク、分散システム、スケーラブルアーキテクチャ、トラブルシューティングなどだ。こいつはとんでもなくハッカー的な仕事なんだ!

こうした質問の後、彼はどこで働きたいかと訊いてきた。次のいずれかの Google オフィスだ。アイルランド、チューリッヒ、マウンテンビュー、オーストラリア。ぼくはマウンテンビューと言った、なんたって Googleplex(*)だからね! 彼はもし面接がOKなら、H-1Bビザという非米国市民が米国で働くためのビザをとらなきゃいけないと説明した。

(*訳注 Googleplex とは Google 本社の愛称のこと)

面接の後半はいくつかの基本的な技術的質問で、これは単にぼくがある程度のことは知っているということを確認するためだけのものだった。質問は Linux システム管理、アルゴリズム、コンピュータアーキテクチャ、そしてCプログラミングだった。秘密保持契約を結んでいるから詳細は書けない、それにぼくのリクルーターはご丁寧にも質問を投稿しないようにねとお願いしてきたんだ!

いくつかの事実誤認はあったけど、リクルーターは満足し、ぼく達は次の電話面接のスケジュールを決めた。彼は次の面接は非常に技術的で、事前に十分な準備をしておいた方がいいと忠告した。ぼくは準備に十分な時間が欲しいとお願いし、そして次の面接を9月22日と決めた。

また彼はいずれの電話面接も45分から1時間ほどの長さになるだろうと教えてくれた。

ぼくは狂ったように準備し始めた。ぼくは SRE とはどういうものか書かれている3つの発表資料を発見した。


次にぼくは Google の面接及び面接での質問について書かれている全ての他のブログ記事を見つけた。


ぼくは4編の Google の研究論文を印刷して読んだ。


またぼくは何冊かの本に目を通した。


特定のプログラミング言語に関する質問を受けるかどうかわからなかったから、ぼくは C++クックブックPythonクックブックPerlクックブックにあるいくつかのレシピに目を通した。


(訳注: 本のタイトル及びリンク先については訳本がある場合はそちらを用いている)

二次面接(電話)


二次の電話面接は Google のエンジニアと行われた。彼は広告チームという AdSenseAdWords、そして他の広告ツールを受け持っているチームで働いているとのことだった。

面接は非常に技術的で、コンピュータメモリに収まりきらない大きなデータに関するアルゴリズムの問題から始まった。ぼくは自分だったらどうやってこの問題を切り抜け、どのデータ構造とアルゴリズムを使うか正確に話した。彼はぼくに、考えてることを声に出してほしいとも言ってきた(*)。面接は次のような質問で続いた。データ構造、DNS、TCPプロトコル、TCPにおけるセキュリティの脆弱性、一般的なネットワーク、そして Google 自身について。申し訳ないけど、これ以上細かく公表することはできない。

(*訳注 思考の過程を説明してほしいと言っている?)

面接の後、そのエンジニアはぼくに結果を書く必要があった。それは好意的なもので、そしてぼくは次の面接にとりかかった。

三次面接(電話)


ぼくは更に多くの時間をかけて準備をした。三次面接は10月1日にあった。Googleトラフィックチームのエンジニアとの面接だった。

この面接では非常に簡単なプログラミングに関する質問を受けた。ぼくは電話越しにコーディングしなければならなかった。言語を選ぶ自由が与えられたので、ぼくは Perl を選んだ。一番好きなプログラミング言語だからね。Perl の文法を口で説明するのは無理だから(ドルマーク開き括弧データ閉じ括弧開き中括弧……閉じ中括弧)、ぼくはメールで Perl のプログラムを送った。

それから次の段階に進むために同じ問題がとりあげられた。ぼく達が扱っているデータサイズがギガバイトやテラバイトのとき、プログラムや解決策はどう変えていったらいいと思うか?

最後にぼくは再びDNSについての質問を受け、HTTPプロトコル、ルーティング、TCPデータ転送についての質問を受けた。

結果は好意的で、ぼくは現地での面接を受ける準備をすることができた。リクルーターとの話し合いで、現地での面接は5回あること、それぞれきっかり45分間あることを知った。一つはぼくの今までの実務経験、一つはアルゴリズムとデータ構造、一つはトラブルシューティングとネットワーク、二つはCとC++を中心としたソフトウェア開発とのことだ。

リクルーターはもういくつかのドキュメントを読むことを勧めた。


ぼくはラトビアを10月24日午後1時に出発してアメリカに飛び、午後8時にカリフォルニアに着いた。実質14時間かかったけど、時間の流れと同じ方向に飛んでたから快適だった。これは7時間の節約になった。現地での面接は10月27日に予定されていたから、面接の前に十分な休息をとることができた。さらにいいことに、ぼくの旅費、ホテル代、タクシー代及び食事代は Google が払ってくれた。ぼくは何も払わなかったんだ!

四次面接(現地)


四次面接はとうとう Googleplex で行われた! 10時にリクルーターと会い、面接について15分間の打ち合わせをした。彼はぼくに次のことを教えてくれた。今から2つのインタビューがあり、それから Google エンジニアの一人がぼくを Google のレストランに連れていってランチを食べ、その後3つの面接があるとのことだ。

10時15分、最初の面接が始まった。ぼくの今までの実務経験についてだった。過去に多くの実務経験があったので、ぼくが数年前に Linux 上で C でコーディングした物理的セキュリティ通報システムについて話すことにした。このシステムはシリアルポートからメッセージを受け取り、メールかSMSで送信するものだ。

面接の最後の数分で、彼は基本的な Unix ファイルシステムの質問をしてきた。

どの面接でもぼくは2つの大きなホワイトボードに文字を書いたり絵を描いたりしたんだ。 楽しかった!

五次面接(現地)


五次面接は11時に始まった。その面接はコーディングの時間で、現実のコーディングの問題ではなくひっかけ問題から始まった。ぼくはある問題の解決策を C で実装するように言われた。その解決策は1行の return 行がある数学的な式だった。大きなコーディングはなかった。それからぼくは非常に有名なデータ構造の実装を書くように言われた。コーディングのとき、ぼくはミスをしてしまって、malloc()したデータ構造の一部を初期化し忘れちゃった! プログラムは実際にはセグメント違反を起こし、ぼくはそのエラーに気づいたんだけど、Google のエンジニアはそのことを非常に深刻に受け止めたんだ! もし読者が面接を受けることがあったら、どんなミスも絶対にしないように!

この面接の後ぼくは二次(電話)面接の担当者だったエンジニアにランチに連れていってもらった。彼女は Google で2年間働いていて、とても楽しいと話してくれた。ぼく達はアジア料理レストラン(Googleplex 内にある)に行き、あらゆる種類のおいしい食べ物にありつけた。全部タダ!

その後彼女は Googleplex の中を色々と見せてくれた。何もかもが驚くことばかりだった。どこにでも無料の飲み物とキャンディがあり、アーケード機があったり、外ではビーチバレーができたり、他にもたくさんのびっくりするものがあった。

六次面接(現地)


六次面接は12時45分に始まった。トラブルシューティングとネットワークの面接だった。面接担当の人はネットワークダイアグラムをホワイトボードに描き、この図から読み取れる問題を考えるように言った。ぼくは問題を特定するために一連のネットワークに関する質問をする必要があった。彼は満足し、面接の最後の数分でネットワークデバイスに関する質問を投げかけた。

七次面接(現地)


七次面接は1時半に始まった。コーディングの時間だった。ぼくは単純な文字列操作サブルーチンを C か C++ で実装するように言われた。ぼくは C を選んだ。不幸にもぼくは off-by-one のミスをしてしまった。人類史上最もありふれたプログラミングミスだ。面接はこの一つの問題だけ行われた。

八次面接(現地)


最後の八次面接は2時15分に始まった。アルゴリズムとデータ構造の面接だった。ここで出された問題は二次面接の問題と似ていた。データが大きすぎてコンピュータメモリに収まりきらないというだけでなく、分散されていた。ぼくはあらゆる知略を用いて解く必要があった。面接は非常に自由な形で行われ、ぼく達はその問題についてあれこれと話した。ぼくは面接終了直前になって正解にたどり着いた。彼はそうやって正解にたどり着いた候補者はそうはいないと言った。ぼくはうれしかった。

面接の後、エンジニアはぼくをロビーの外まで送ってくれて、ぼくはタクシーで自分のホテルに戻ったんだ。以上! :)

終わり

全体的に Google の面接は純粋に楽しかった。面接の問題は技術的だったけどそれほど挑戦的でも難しくもなかった。

機会を与えてくれた Google に感謝! :)