2/28/2017

カルダシェフのタイプ3文明を発見することは可能か?

先週、NASAが39光年先に地球サイズの惑星を発見し、第二の地球を発見するのも近いと報じられた。ふと思ったのだが、カルダシェフは宇宙に存在する文明をエネルギー利用量によって3種類に分類した。いわゆるカルダシェフ・スケールと呼ばれるものだが、タイプ3文明になると、銀河規模のエネルギーを利用するようになる。もしも、タイプ3文明が存在するとしたら、それは観測によって分かるのだろうか...? 以前、タイプ2文明(ダイソン球)ではないかと報じれた恒星(KIC 8462852)が存在したが... ちなみに宇宙に存在する銀河の数は2兆個と言われている。

4年以内に月に戻る方法

Slashdotより

サイエンティフィック・アメリカンは、「月に到達し、永久にそこに滞在する方法... このプロセスをすぐに開始こと、4年以内に月面着陸を達成すること」を説明する。それは、NASAの高価なスペース・ローンチ・システムオリオンを放棄することから始まり、イーロン・マスクのSpaceXやロバート・ビゲロウのビゲロー・エアロスペースのような民間企業の努力で節約された資金を使うことである。schwit1はそれらのレポートを引用する:

マスクのロケット、ファルコンや間も無く打ち上げられるファルコンヘビーは、離陸して着陸するように作られている。これまでのところ、着陸能力は地球上で簡単に利用できる。しかし、同じ技術にいくつか微調整を加えれば、人間も月面に着陸させることができる。さらに、SpaceXの次回の7人乗りのドラゴン2カプセルは既に地球の表面上に緩やかに着地できることをデモしている。言い換えれば、ファルコンロケットとドラゴンカプセルはいくつかの変更と装備の追加で、月の準備ができる可能性がある。

宇宙コミュニティの主要セグメントは、将来の全ての着陸を上空の常設のインフラに加えることを望んでいる。ロバート・ビゲロウのおかげで我々は手中に収めつつある... 2016年の春から、ホテル王のビゲロウは頭上から220マイル離れた国際宇宙ステーションで予備室となるインフレータブルな居住地を持っている。そして、ビゲロウははるかに野心的な、3つの330立法メートルのB330モジュールを使って、インフレータブルな月面基地を開発している。

記事は、ジェフ・ベゾスのブルーオリジン・ロケットを「ワイルドカー」と呼び、月に乗客と貨物を着陸させ、NASAは月面給油所、月の建設機械、「氷をロケット燃料、飲料水、呼吸可能な酸素に変換する装置」のような施設で一層楽になるであろうと提案している。

更新: SpaceXが2018年末、2人の人間(ビリオネア)を月に送る計画と発表した。月面に着陸はせずに月を周回して戻る。(TechCrunch)

更新(2017.3.1): トランプ政権に近付きたい思惑もあるとか...

ストリーミング会社がハリウッドのスタジオに置き換わる?

Slashdotより

「映画館の入場者数は19年ぶりに低くなり、収入は100億ドルをわずかに上回る」とVanity Fairが報じ、従来のスタジオはNetflixやAmazonのような動きの速いストリーミング会社を脅威に感じている、と述べている。Amazonはアカデミー賞で6部門ノミネートされた映画『マンチェスター・バイ・ザ・シー』をプロデュースした。匿名の読者が伝える:

AmazonのCEOジェフ・ベゾスはアカデミー賞に主席し、ホストのジミー・キンメルから映画に勝ったら「オスカーが2〜5営業日以内に到着し、GrubHubの配達人によって盗まれる可能性がある」と冗句を言った。しかし、ハリウッドでの避けられない混乱の象徴である。「スタジオは現在、親会社の利益の10%未満を占めるに過ぎない。ある予想によれば、2020年までにそのシェアは約5%に落ちるだろう... 興行成績の70%は海外からのもので、スタジオは中国語に簡単に変換できる殴り合いのアクション映画やコミック本のスリラーみたいなものを売買しなければならなくなる。あるいは、既存の知的財産に依存するリブートや続編になる。」とVanity Fairが伝える。元パラマウントのCEO、バリー・ディラーは「私は今日、誰がなぜ映画会社を欲しいと思うのか分からない。彼らは映画を作っていない。彼らは帽子と笛を作っている(they make hats and whistles)。」とよく知られているように語った。

記事はハリウッドは「フランチャイズに過度に依存しており、有料テレビやHBOやShowtimeのようなOTTに刺激的なコンテンツの大部分を譲渡している。そして、NetflixやAmazonのようなデジタルネイティブ・プラットフォームがますます強くなっている。これらの企業はその無能さへのアレルギーからハリウッドが決して理解できない分析ツールも利用している。」と主張する。

記事は、AI、CGI、ビッグデータやイノベーションを持つ「シリコンバレーが既に勝利した」、そして「映画がソーシャル・メディアサイトでストリーミングされる前に、おそらく数年前には、時間の問題だったのだ」と述べている。

2/26/2017

ロールモデルの力

ロブ・パイクのブログより。コンピュータ関係でロールモデルになる女性が全くいないわけではないと思うが...

私はこの間、国の天文組織の理事会で数日過ごし、その場所の人々の特質に気付いた: 約40名のうち3名が女性だった。そして、教授、天文台所長など3人ともパワフルな女性だった。彼女らは壁の花ではない。会議への彼女らの貢献はその役割を上回っていた。

私の長いキャリアの中で、これまでそのような場所にいたことはなかったし、トーン、会話、尊敬、プロ意識の違いは、私が経験したことと違っていた。私はそれが違いを生み出した女性の存在だったとは証明できない。天文学者が全体的に素晴らしい人が多く、私が反論できない可能性はあるが、違いが年齢層(demographics)に由来すると私には見えた。

この会議は出席者の1/3が女性だったが、しかしやはりプライベートな会話で、私が話した女性はまだ平等ではないとことを訴えた。我々は基準点を持っている。

しかし、少し戻って、要点について考えてみたい: ハッブル宇宙望遠鏡のようなものを含む主な天文台の予算や運営の監督に関与する部屋では、女性が大きな役割を果たしていた。コンピュータ関係が殺風景なのと対照的である。

本当に私は考えさせられた。夕食会で、私は女性にどのように天文学会がどのように(相対的に)平等主義になったのか、話してもらうようお願いした。そして、一つの話題、ロールモデルが明確になった。天文学はその分野で女性が活躍する長い歴史があり、19世紀はじめのカロライン・ハーシェルに行き着く。女性はこの分野で大きな貢献をした。ダバ・ソーベルは、宇宙の膨張の発見の基礎を築いた女性に関するを書いたばかりだ。ちょうど数週間前、暗黒物質の証拠を発見した著名な天文学者ヴェラ・ルービンの死亡記事が出た。私はノーベル(sic)の顧問にしたパルサーの発見者ジョセリン・ベルを言及した。

私が出会った最も有名な天文学者は、我々が出先機関と呼ぶトロント外のデービッド・ダンラップ天文台にいたカナダ人天文学者ヘレン・ホッグだった。

この会議で女性たちは、女性がこの分野の大きな貢献ができた証拠を調査するためのロールモデル、女性の貢献の歴史について語った。

このことからコンピュータ界は何を学ぶことができるか?

我々が間違っているように見える。現場で女性の表現を改善するための最善の方法は彼女らを採用することではなく(重要だが)、そららを促進することだ。ロールモデルの力を作ること。影響力のある立場に押すこと。女性は上への道が見えない、あるいはカルチャーが歓迎されないため、大挙してコンピュータ関係を離れる。現場で優れた女性、有名な女性、輝かしい女性は活気付けるだろう。

男性はそれらの問題を正す力を持っている、彼らは頻繁に女性に舞台を譲る勇気を持ち、女性を現場で優位にならないようにする愚かな偏見と戦うべきだ。チームを成長する時に男性より女性を選ぶ、あるいは女性をより自由に昇格させるような積極的な行動をとることだ。

しかし、私が見ているように、女性のロールモデルを促進するために何かが行われないと、コンピュータ関係で行われている物事はまだ100年遅れている。

Hacker News

デヴィッド・ボウイの愛読書

Hacker Newsデヴィッド・ボウイの愛読書(推薦本)が出ていた。Ro69によると、デヴィッド・ボウイのキャリアを振り返る2013年開催の展覧会『David Bowie Is』(日本でも現在開催中)で、キュレーターがデヴィッドの勧める100冊の本を発表とある。Hacker Newsのコメントにトニー・ロビンスのMoneyはクラップだとあるが、このリストはボウイが選んだわけではなく、彼の蔵書が7万冊からキュレータが選んだものだからだろう。それにしても、彼は大変な読書家だったんだ。

  1. アンソニー・バージェス:『時計じかけのオレンジ』
  2. バンス・パッカード:『かくれた説得者』
  3. ギュスターヴ・フローベール:『ボヴァリー夫人』
  4. ミハイル・ブルガーコフ:『巨匠とマルガリータ』
  5. スーザン・ジェイコビー:『The Age of American Unreason』
  6. ジュノ・ディアズ:『オスカー・ワオの短く凄まじい人生』
  7. トム・ストッパード:『コースト・オブ・ユートピア』
  8. ジョン・サベージ:『Teenage』
  9. サラ・ウォーターズ:『荊の城』
  10. クリストファー・ヒッチェンズ:『アメリカの陰謀とヘンリー・キッシンジャー』
  11. ローレンス・ウェスクラー:『ウィルソン氏の驚異の陳列室』
  12. ルーパート・トムソン:『終わりなき闇』
  13. マイケル・シェイボン:『ワンダー・ボーイズ』
  14. ハワード・ノーマン:『バード・アーティスト』
  15. アナトール・ブロイヤード:『Kafka Was the Rage』
  16. アーサー・ダントー:『Beyond the Brillo Box』
  17. カミール・パーリア:『性のペルソナ』
  18. Mr. Richard Cork:『David Bomberg』
  19. ブルース・チャトウィン:『ソングライン』
  20. C・J・ボックス:『狼の領域』
  21. アンジェラ・カーター:『夜ごとのサーカス』
  22. トニー・ロビンズ:『Money』
  23. ドン・デリーロ:『ホワイト・ノイズ』
  24. ジュリアン・バーンズ:『フロベールの鸚鵡』
  25. Charles White:『The Life And Times Of Little Richard』
  26. ハワード・ジン:『民衆のアメリカ史』
  27. ジョン・ケネディ・トゥール:『A Confederacy of Dunces』
  28. デイビット・シルベスター:『回想フランシス・ベイコン』
  29. アーサー・ケストラー:『真昼の暗黒』
  30. アンソニー・バージェス:『Earthly Powers』
  31. エレーヌ・ペイゲルス:『ナグ・ハマディ写本 - 初期キリスト教の正統と異端』
  32. フラン・レボウィッツ:『嫌いなものは嫌い ― メトロポリタン・ライフ入門』
  33. イアン・マキューアン:『ベッドのなかで』
  34. ジュリアン・ジェインズ:『神々の沈黙 - 意識の誕生と文明の興亡』
  35. エド・サンダース:『Tales of Beatnik Glory』
  36. フランク・オハラ:『Selected Poems』
  37. オットー・フリードリク:『洪水の前 ― ベルリンの1920年代』
  38. ジョージ・スタイナー:『青ひげの城にて 文化の再定義への覚書』
  39. チャーリー・ジレット:『The Sound Of The City』
  40. クリスタ・ヴォルフ:『クリスタTの追想』
  41. ニック・コーン:『Awopbopaloobop Alopbamboom』
  42. Eugenia Ginzburg:『Journey into the Whirlwind』
  43. ヒューバート・セルビー・ジュニア:『ブルックリン最終出口』
  44. トルーマン・カポーティ:『冷血』
  45. John Rechy:『City of Night』
  46. ソール・ベロー:『ハーツォグ』
  47. スパイク・ミリガン:『Puckoon』
  48. ジェシカ・ミットフォード:『The American Way of Death』(アメリカ人の死に方)
  49. 三島由紀夫:『午後の曳航』
  50. ジェイムズ・ボールドウィン:『次は火だ』
  51. ジョージ・オーウェル:『鯨の腹の中で』、ほか
  52. ミュリエル・スパーク:『ミス・ブロウディの青春』
  53. ダグラス・ハーディング:『心眼を得る』
  54. ジョン・ケージ:『サイレンス』
  55. ロナルド・D・レイン:『ひき裂かれた自己』
  56. David Kidd:『All the Emperors Horses』
  57. キース・ウォーターハウス:『うそつきビリー』
  58. ジャック・ケルアック:『路上』
  59. ジョン・ブレイン:『年上の女』
  60. Alberto Denti di Pirajno:『A grave for a dolphin』
  61. フランク・ノリス:『死の谷 マクティーグ』
  62. エリファス・レヴィ:『高等魔術の教理と祭儀』
  63. コリン・ウィルソン:『アウトサイダー』
  64. ウラジーミル・ナボコフ:『ロリータ』
  65. ジョージ・オーウェル:『1984年』
  66. アン・ペトリー:『街路』
  67. リチャード・ライト:『ブラックボーイ』
  68. ドロシー・パーカー:『The Best of Dorothy Parker』
  69. S・E・ヒントン:『アウトサイダー』
  70. ナタニエル・ウェスト:『いなごの日』
  71. ジョージ・オーウェル:『ウィガン波止場への道』
  72. クリストファー・イシャーウッド:『Mr. Norris Changes Trains』
  73. ウォレス・サーマン:『Infants of the Spring』
  74. ハート・クレイン:『橋』
  75. イーヴリン・ウォー:『卑しい肉体』
  76. ウィリアム・フォークナー:『死の床に横たわりて』
  77. ジョン・ドス・パソス:『北緯四十二度線』
  78. ネラ・ラーセン:『白い黒人』
  79. D・H・ローレンス:『チャタレイ夫人の恋人』
  80. F・スコット・フィッツジェラルド:『グレート・ギャツビー』
  81. T・S・エリオット:『荒地』、ほか
  82. パーシー・ウインダム・ルイス:『ブラスト』

Swiftはどうなるのか? (Whither Swift?)

Underpassの開発者、ジェフ・ジョンソンのエッセイ。スターウォーズ・サーガをもじって。

私は次の疑問を自問している。AppleのSwiftObjective-Cの計画が何なのか? Swiftが2014年に公開されたとき、作者のクリス・ラットナーは、SwiftとObjective-Cは永久に共存すると主張しているように見えた。xcode-usersのメーリングリストの投稿より:

> On Jun 3, 2014, at 5:45 AM, McLaughlin, Michael P.  wrote:
> AppleがCとC++のサポートをやめるつもりかどうか、ご存知の方はいますか?
> そのように聞こえます。Fortranのコードがたくさんあるにも関わらず、既にFortranをサ
> ポートしていません。MultiNestのようにかなり新しいコードでさえサポートされません。
>
> そうではないと言って下さい。私たち全員、「パワーユーザ」は長編漫画を作るだけの人で
> はないと考えています。多くは科学者やエンジニアです。

やぁ、マイケル、

そういう計画はありません。Swiftはプラットフォーム上で開発するための新しいオプション
です。C、C++、Objective-Cをやめる計画はありません。あなたがそれらに満足しているな
ら、気兼ねしないで使い続けて下さい。

-クリス

問題は誰もこれを信じていないことだ。そしてもちろん、ラットナーはAppleを去ったので、彼の主張が間違っていたと分かっても批判を受けることはない。開発者間の大多数の意見は、Appleが最終的にObjective-Cを廃止し、SwiftはCocoaアプリ開発の唯一のファーストクラス言語になるだろうということだ。AppleがObjective-Cをサポートするコンパイラを非推奨にしたり削除したりする理由はないため、「ファーストクラス」を与える人物は重要である。コンパイラは多くのプログラム言語をサポートし、そのうちいくつかは非常に古くてほとんど使われていない。そのため、ラットナーの主張は専門事項に基づくと真実ではあるが、誰もが気にすることではない。彼らはiOSとmacOS上のCocoaアプリを作るための言語を使用することについて関心があるのだ。

開発者のコンセンサスがおそらく正しいのだろう。私はObjective-CとSwiftが永久に共存し続けられないというコンセンサスに同意する。しかし、Swiftが未来だと、私は他の開発者ほど確信は持てない。コンセンサスはおそらく正しいが、もし間違っていたらどうなるだろう? それが私がこの記事の中で探求したい可能性である。まず、SwiftとObjective-Cがなぜいつまでも平和的に共存できないのかを話そう。

新たなる希望? (A New Hope)

SwiftもObjective-Cもどちらも、Appleのプラットフォーム以外の開発にはほとんど使われない。それは将来変わるかも知れないが、今のところ事実である。Appleのプラットフォーム上でアプリを書きたいなら、どちらか一方、あるいは両方を学ばなければならない。新しい開発者の疑問は、どちらの言語を学べばいいのか? 一つの言語しか学ばないなら、標準的なアドバイスはSwiftを学ぶことである。標準的なアドバイスに必ずしも同意するわけではないが、それが標準的なアドバイスであることには同意する。賢い人の頭は、Objective-CとSwift両方を学ぶべきだと示唆している。しかし、その点に問題が潜んでいる。アプリを書くだけのために、二つの新しいプラットフォーム固有のプログラミング言語を学ばなければならないなら、Appleのプラットフォームは開発者にとってそれほど魅力的ではない。Swiftは、Objective-Cよりもモダンで親しみやすいため、新しい開発者にとって魅力的だと一般に言われている。しかし、Objective-Cをとにかく学ばなければならないとするなら、優位性はどこにあるのだろう?

サードパーティの開発者はSwiftを採用した... 素早く(swiftly)。Appleがジャンプと言ったら、彼らは飛び込んだ。アポロニアがミネトンカ湖へ。Swiftが非常に人気となり、取り敢えず、速かったと言っておこう。これはSwiftのリソースへのものすごい需要を生んだ。メーリングリスト、フォーラム、ブログ、Stack Overflow、Twitter、あちこちで開発者はSwiftについて知りたい、話したいと思った。Swiftは技術本出版業界に影響を与えた。労働市場にも影響を与えた。合理的であろうと、無知でブームであろうとなかろうと、多くの企業が今はSwift開発者だけを採用している。Appleのプラットフォームへの多くの新しい開発者は、Objective-Cを知らない。多くの元Objective-C開発者はSwiftのみを使うようになり、彼らはObjective-Cを忘れ、読んだり書いたりしなければならない時、頭を抱えている。開発者間のSwiftに対する熱意と要求は、Objective-Cを消し去ってしまう危険性がある。二つの言語はAppleの考えの中では公式には共存かも知れないが、他の人の考えの中は非公式に共存にできるだろうか? 全てのメール、ブログ投稿、ウィキページで2言語スタックが存在できるだろうか? オープンソース・プロジェクトではどうだろう? 彼らはObjective-CあるいはSwiftだろうか? 労働市場がほとんど独占的にSwiftに移行するなら、開発者は選択肢がなく、その方向に向かうしかない。

帝国の逆襲 (The Empire Strikes Back)

これまでの議論はObjective-Cが絶望的だということを示唆している。Swiftはサードパーティ開発者で優位に立ち始めている。サードパーティ開発者はAppleのプラットフォームを支配していないため、まだ全てが失われるわけではない。Swiftの支配が始まっていない一つの場所が、皮肉にもApple自身の中にある。Apple自身。AppleはSwiftを採用するのが非常に遅かった。この時点で、Appleは話にならないほど少ししかSwiftコードを出荷していない。このテーマの素晴らしい分析は、最近のブログ投稿の中で見つけることができる。言い訳になるかも知れないが、いくつかの説明は、この欠落を説明するつもりだ。例えば、Appleのフレームワークは、まだABI安定性を達成していないため、Swiftを使うことができない。(あるいは、そのことについて言えば、ソースの安定性も。) それを説明したいと思うが、Appleの内部Swiftコードベースは相対的にとても小さいという事実に変わりはない。Appleは世界で最も巨大な現存のObjective-Cコードベースを持っている可能性が最も高いのだ。

今日、Appleが二つの言語のうち一つを廃止する必要があるなら、どちらを廃止するだろうか? Swiftを廃止することはサードパーティ開発者には非常に辛いだろう。一方、Apple自身にとっては、Swiftを廃止することは比較的痛みはない。AppleはSwiftからObjective-Cに変換するコードがほとんどない。確かに、AppleはSwiftに、特にXcodeに関して多くの努力を払っている。しかし、それらはサンク・コスト(埋没費用)である。もし、Appleが合理的であれば、彼らは失敗したビジネスにさらにお金をつぎ込むべきではない。AppleはObjective-Cに、特にXcodeに関して多くの努力も払っている。そして、それらはサンク・コストでもあるが、Swiftのコストよりも過去にさらに沈んだだけである。重要なことは、すでに支払った対価ではなく、将来支払われるべき対価である。Appleはサンク・コストを回収不能と見なすことに反対していない。噂によれば、彼らは何も見るものがない自動運転プロジェクトに多くの資金を投入し、報道によればそのプロジェクトは大部分が棚上げにされている。

Appleはその気になればObjective-Cコードベース全体をSwiftに変換できる。彼らは確かにリソースを持っている。彼らが所有する流動資産の量は、歴史上前例のないくらいの大きさで圧倒的である。それにもかかわらず、現在の企業文化が彼らはこの変換を行うことができない、あるいはしないだろうと言うことを示唆している。いくつかの要因が障害になっている。まず、AppleはすべてのメジャーOSバージョンのリリースサイクルを毎年に変更した。確かに、彼らはアジャイル・ソフトウェア開発の考えを実行しているという報道がある。これにより、完全な書き直しのための余裕や時間はほとんどなくなっている。また、Appleがスクラッチでアプリやテクノロジーを書き直す時、品質が低下しがちで、機能が失われる傾向があったのをこれまでも見てきた。

第二に、Appleは最高のエンジニアを雇用することを誇りにしている。私は、Apple内部と外部のエンジニアを多数知っているが、これは神話だと考える。しかし、これが本当かどうかに関わらず、Appleが信じていることは事実であり、従って大量の新規採用を行うことはまずないし、Objective-Cコードを書き直す問題で多くの人を投入することもない。

第三に、私が最初に指摘したことに関連し、Objective-Cエンジニアのアベイラビリティは低下している。Appleがこの問題に多くの人を投入したいと思っているなら、その人たちをどこで見付けてくるのだろうか? Objective-CコードベースをSwiftに変換するには、両方を理解するエンジニアが確実に必要である。Objective-Cを知らないエンジニアがObjective-CのコードベースをSwiftに書き直そうとするのは、惨事を招く行為だろう。

Appleの内部計算は、ソフィーの選択を一つの言語にする必要があるなら、Swiftは斧を手にしなければならないことを示している。あなたが全面的にSwiftに投資しているサードパーティの開発者なら、この考えは少なくとも少しはあなたを驚かせる筈である。そして、自分自身に尋ねて欲しい。もし、今日振り子がそのように振れているなら、どのくらい変化し、どのくらい長く、他の方法で振れる振り子を巻き上げるか? 何時、何年、Objective-CよりSwiftを切り捨てるのはAppleにとってより痛いだろうか?

AppleがSwiftを捨てることで、開発者をひどく裏切る可能性がないわけではないことに、あなたはブツブツ言うかもしれない。どのくらいAppleの幹部は夜眠ることができるか? 私は現金で一杯のマットレスを信用しない。彼らは再考しなかった。彼らは勇気があると自画自賛するかも知れない。廃止、失望、苦しみ、約束の反故と長々続く経験に関連するApple開発者の歴史を振り返る必要がある。Objective-Cのガーベジ・コレクション、64ビットCarbon、Cocoa-Javaブリッジ、Windows向けYellow Box、Dylan、これ以上続ける必要はない? 私は続ける。Appleエバンジェリストは、Swiftはこれまでにない最高のプログラミング言語だと言い、その後、我々は常にSwiftと戦ってきたことを伝えて突き放すわけだ。

プリクエル (The Prequels)

AppleがSwiftを作ることを決めた時、オリジナルの計画は何だったのだろうか? 3つの可能性を考えてみる:

  1. 彼らは本当にObjective-CとSwift両方をいつまでもサポートするつもりだった。
  2. 開発者の大多数が信じている、Objective-Cを最終的に廃止し、Swiftに移行するつもりだった。
  3. 彼らはしっかりした計画が無く、Swiftが採用されるかどうかも分かっていなかった。

私が既に要点を述べた理由で、1は愚かな計画である。そして、Appleに対して疑わしきは罰せずとするが、1ではないと言える。

2が計画だったら、私はAppleがそれについて積極的になることを本当に期待する。ラットナーのメッセージはせいぜい誤解を招いたことだろう。Swiftが未来なら、なぜそのことを開発者に明確にしないのだろうし、それに応じて計画を立てるだろう。不確実さはこれの最悪な側面である。我々は選択肢が無ければ、まだSwiftが未来だと受け入れることができる。しかし、SwiftがAppleの選択であり、彼らは我々の選択肢を持てるという幻想をまだ我々に与えたなら、我々の一部が知らずに誤った選択をしており、これは皆にとって有害である。

私の考えは、3が真実だということだ。多くの人がAppleはいくつかの壮大で秘密の長期基本計画に準じて行動していると思い込んでいることは知っている。Appleは長期計画を持っているだろうか? 疑いの余地はない。それでは、計画は暫定的ではないのか? それは疑わしい。テック業界では、長期計画を立てることはできるが、長期計画を維持することは期待できない。テクノロジーは変化する...素早く(swifty)。あなたは機敏に動けるようにしておく必要がある(しかし、アジャイルでは無く)。競合先の行動に反応できなければならない。ラットナーの退職を考えてみる: Appleの計画の一部だったのか? 計画は変化する。彼らは変化しなけばならなかったのだ。サードパーティ開発者は即座にSwiftに飛び付いたが、AppleはSwiftが開発コミュニティで肩をすくめてしまう可能性を考慮しなければならなかった。うまくいくように願うが、最悪の自体に備えて計画を立てる必要がある。

ローグ・ワン (Rougue One)

誰に聞いても、SwiftプロジェクトはAppleの中でさえ秘密だった。少数の選択された人だけが知らされていた。AppleがSwiftを発表した時、サードパーティ開発者にとっても、ほとんどのAppleエンジニアにとってもとても驚きだった。Appleエンジニアやエンジニアリング・マネージャはそれに備えていなかった。これはSwiftプログラミングにとって最大の課題を示している: Appleのエンジニアリングチーム間の内部衝突である。幹部のサポートを得ているSwiftチームはAppleのアプリ開発の未来としてSwiftを提示する。しかし、Swiftチームはそこにあるものを単純に廃止できないし、未来を既成事実にはできない。Apple内の今はObjective-Cである。Objective-Cがたくさんある。AppleがNeXTを買収する前から累積されたObjective-Cの数十年がある。Objective-Cコードベースは希望的な考えで単純に消し去ることはできない。非常に時間が制約され、リソースが制約されているApple内の多くのチームにあなたがSwiftを紹介したとする、彼らはあなたに邪魔するなと言うだろう。彼らはSwiftのアイデアは好きかもしれないが、WWDCがすぐそこにあり、作業を完了する必要がある。おそらく来年も。いや、それ以降の年も。

Appleはこれらの競合する利害関係をどのように調停できるだろうか? 彼らはSwiftを未来にしたいと思っているが、大量のObjective-Cコードもあり、最高のエンジニアだけを採用しながら、アジャイルなソフトウェア開発を続けたいと思っている。そして、ソフトウェア品質を維持したい。(願わくは、彼らが品質について注意を配っていると仮定する。) いずれは何かを譲歩しなければならない。その一方、外部の開発者らはSwiftのリソースにAppleへの要求を増やすだろう。APIリファレンスはおそらくかなりの程度自動化されているので、デュアルスタックでも大きな問題はないだろうが、Swiftの開発者らはSwiftのドキュメントガイドやSwiftのサンプルコードを必要とする。公的立場がAppleがSwiftとObjective-Cの両方をサポートするということなら、全てのドキュメント、全てのサンプルコードをデュアルスタックで書くのだろうか? そして、非常に古いObjective-C指向のドキュメントを更新するためにどのくらいの努力を払うのだろうか?

この問題へのコンセンサスは何だろうか? AppleがObjective-Cを廃止するだろうと考える人は、Appleがどのように扱うと考えるだろうか? 一部の人々は、Appleが対外的にObjective-Cを廃止するだろうと考えているが、彼らはいつまでも内部的にObjective-Cの開発を続けるだろう。しかし、私はこれらの人たちが問題を過小評価していると思う。Appleが持つObjective-Cコードの量や、彼らが取り組んでいる制約を考えると、内部的にもゆっくりした道を歩み、実際にはSwiftの未来は非常にゆっくりした道となるだろう。Appleが内部のObjective-Cツールチェーンを維持する必要があると思われる期間はどのくらいだろうか? あなたが5年、10年と考えていないなら、10年もさることながら、私はあなたが問題の大きさを理解していると思わない。私には、Appleが内部専用のXcode、内部専用のObjective-CのAPI、内部専用のObjective-Cドキュメント(皆がドキュメントを必要とする)などを開発し維持するリソースを置くことはほとんど不可能に見える。再度、Appleが正式にObjective-Cを廃止するなら、Objective-Cの開発者の数は今ようりも急激に減少するだろう。そのため、AppleはObjective-Cコードベースをいつまでも維持し続けるため、世界中で人を見付け続ける事ができるだろうか?

エピソードC (Episode C)

ここで私の主張への考えられる異議に反論させてほしい。異議はAppleは以前からObjective-CとC、FoundationとCore Foundationのデュアル・ソフトウェア・スタックを持っていたいうもの。スタックにもう一つの言語を加えることは新しいことではない。この異議は一見説得力があるが、固有の欠陥がある。CとObjective-Cは別の言語と言うのは事実だが、CはObjective-Cのサブセットなので、Swiftでの類推はうまくいかない。あなたがObjective-Cを学習する場合、うまく習得できたとして、あなたはCも学習したことになる。多くの人はCを最初に学習し、Objective-Cは後になるのは重要ではない。確かに、それが私が学習した方法で、私がお勧めする教育ルートである。しかし、CとObjective-Cを学習することは、2つのプログラミング言語を学習するのと同じではない。事実上、それは単にObjective-Cを2段階で学習しているだけである。Cについて学習する全てが、Objective-Cに直接適用できる。いわば、学ぶだけ。それが、Swiftでは全く違う。もちろん、SwiftはObjective-Cを念頭に設計されているため、いくつか重複があるが、決して他のサブセットとは言えない。SwiftとObjective-Cは、ある意味で非常に近しいC++とCよりもはるかに互換性はない。

さらに、CだけではiOSやmacOSアプリを開発するファーストクラス言語では全くない。完全にCでアプリを作ることはできるか? おそらく、しかしもちろん簡単ではない。Cのアプリケーション開発環境はCocoaではなくCarbonであり、Carbonはほとんど廃止されている。Appleのプラットフォーム向けにかなりの数サポートされたC APIはあるが、Cはアプリ開発に関してObjective-CやSwiftと同じクラスにはない。

何々の復讐 (Revenge of the Something Something)

これは私の疑念であるが、AppleはSwiftがすぐに人気が出ると見込んでいたかどうか疑わしい。Swiftが長年掛けてゆっくりした成長をしていたら、全体の戦略は非常につじつまが合う。開発者ベースがほぼ均等に分かれていたら、デュアル・ソフトウェア・スタックは経済的である。Appleとサードパーティ双方が既存のコードベースをObjective-CからSwiftに移行するのに十分な時間がある。Swiftはまだ未来の可能性があったし、いずれは唯一のファーストクラス言語になっていたが、それは全く遠い未来である。Swiftが開発者のマインドシェアの中にObjective-Cを突然圧倒するという見立ての計画あるいは想像が不足していた。そして今、Appleは難しい選択に迫られている。Apple内部が単純にそのための準備がまだできていないので、彼らはAppleを除いてSwiftの予想外に人気にどのように対応するだろうか?

私はAppleがSwiftを撤回するとは思えない。とはいえ、ラットナーの退社は以前よりももう少しそれが起こりそうな可能性をあると考える。多くの開発者がSwiftに生活を賭けている。その当時は良い賭けのように思えたかもしれないし、おそらくそれは利益をもたらすだろう。しかし、もしそれがない場合はどうなるだろう? もし、大穴が勝ったならどうなるだろう? もし、今後経営者が変更になったら、あるいは単に経営陣の中に心変わりがあったらどうなるだろう? もし、Appleが彼ら自身の内部制約が予想よりも克服が難しく、言語の切り替えが有益ではないと判断したらどうなるだろう? あなたはその可能性を排除できるだろうか? 私は、ほとんどの人がその苦痛の世界(world of hurt)の覚悟ができないことを心配している。もし、それが起これば、多くの人が泣き叫ぶだろう。Objective-Cの開発者を除いて、1999のように笑ってパーティをする人はいないだろう。2001でもいいけど。

そういう事で、ハッピー・バレンタイン・デイ!

Hacker News

2/24/2017

Googleが実際にSHA-1を破ることに成功

Slashdotより

読者のArtem Tashkinovが書く:

SHA-1が初めて導入されてから10年後、GoogleはSHA-1衝突を生成するための初の実用的なテクニックを発表した。アムステルダムのCWI研究所とGoogleの間で2年の研究が必要だった。攻撃の立証として、Googleは内容は異なるが同じSHA-1ハッシュを持つ2つのPDFファイルをリリースした。第1段階の攻撃を完了するのに6500年のCPU計算を、第2段階を完了するのに110年のGPU計算を掛け、合計900京(9,223,372,036,854,775,808)回のSHA1計算と、攻撃を実行するために必要となる計算量は膨大である。

Googleは、皆がSHA-256やSHA-3のような新しいハッシュアルゴリズムに移行すべきと言うが、注目されるのは現時点でMD5とSHA-1ハッシュ両方の衝突を同時に見つける方法は存在しない。そして、我々は安全を期して古い実績のあるハードウェア・アクセラレーションされたハッシュ関数をまだ使うことができることを意味する。

Hacker NewsSchneier on Security

更新(2017.2.26)

GitでSHA1が使われていることから、リーナス・トーバルズがこの件についてメーリングリストやBlog(G+)で発言している。

SHA1衝突攻撃がニュースに目立ってきたので、gitとSHA1のアップデートを書こうと考えた。

はじめに概要を、その下により丁寧な説明:

(1) 最初に - 恐れる根拠は何もない。セキュリティ署名のための暗号ハッシュの利用と、gitのような連想記憶システムのために"コンテンツ識別"を生成に利用との間に大きな違いがある。

(2) 第二に、この特定のSHA1攻撃の性質は、実際に軽減するのはかなり簡単であることが重要で、その緩和のために2セットのパッチがすでに存在する。

(3) 最後に、破られたことがない他のハッシュ、あるいは古いgitリポジトリの合理的に単純な移行が実際に存在する。

Hacker NewsSlashdot

2/23/2017

ポリシー設定が無いEBGP経路伝搬のデフォルト動作の変更について

EBGPの経路広報のデフォルト動作を変更するInternet Draft

1. はじめに

BGP[RFC4271]スピーカはルーティング・エコシステムを改善する一環として再検討の必要のある多くのデフォルト設定がある。うまく機能しているインターネット・エコシステムのデフォルト動作をBGP実装者にアドバイスを提供する必要がある。ルーティング漏洩[RFC7908]はその問題の一つだが、ソフトウェアの欠陥とオペレータの設定ミスは、我々が取り組もうとしているインターネットの安定性へのほんの一握りの取り組みに過ぎない。

多くのデプロイ済みのBGPスピーカは、デフォルトでBGPネイバー間で全ての経路を送り、受け入れる。これの慣行はインターネット初期にまで遡り、オペレータはすべてのネットワークがお互いに到達できるようルーティング情報を送ることに寛容だった。インターネットがより密接に相互接続するようになり、BGPスピーカの正しくない動作のリスクはインターネット・ルーティングに重大なリスクをもたらしている。

この仕様は、顧客、ピア先、ベースルータのコンフェデレーション境界あるいはVPNインスタンスのような外部BGP(EBGP)セッションのBGP importとexportポリシーの明示的な設定を要求することで、この状況を改善することを目的とする。このソリューションが実装されれば、BGPスピーカはEBGPセッションで設定されたポリシー無しに経路の受け入れや送信はできない。

2. ソリューション要件

次の要件がこのドキュメントで説明されるソリューションに適用される:

  • EBGPピア向けに設定されたimportポリシーがない場合、ソフトウェアは経路選択(9.1.1 [RFC4271])に不適格な経路とみなさなければならない。

  • exportポリシーが設定されていないなら、ソフトウェアはEBGPピアに経路を広報してはならない。

  • ポリシーエンジンのような内部コンポーネントのの障害の後に、ソフトウェアは"import nothing"(何も受け入れず)と"export nothing"(何も広報せず)モードにフォールバックすべきである。

  • ソフトウェアはデフォルトでこのモードで運用しなければならない。

  • ソフトウェアはこのセキュリティ機能を無効にする設定オプションを提供しても良い。

更新(2017.7.8): RFC 8212になった。内容はRFC 4271の変更という形。

3. RFC 4271への変更

この節は、特定のBGPセッションに関連するインポートあるいはエクスポート・ポリシーがない場合に、BGPスピーカのデフォルトの動作を指定する[RFC4271]を更新する。BGPスピーカは、以下のアップデート挙動から逸脱する設定オプションを提供してもよい(MAY)。

次の段落が5段落後の9.1節(決定プロセス)に追加され、"経路集約と経路情報削減"で終わる:

明示的なインポート・ポリシが適用されない場合、EBGPピアに関連するAdj-RIB-Inに含まれる経路は、決定プロセスで適格とみなされないとする(SHALL NOT)。

次の段落は、第3段落後の9.1.3節(フェーズ3: 経路流布)に追加され、"UPDATEメッセージ(9.2参照)を用いて"で終わる。

明示的なエクスポート・ポリシーが適用されいない場合、経路はEBGPピアに関連するAdj-RIB-Outに追加しないものとする(SHALL NOT)。

TRAPPIST-1で、7つの地球サイズの惑星を発見

Slashdotより

水曜日の記者会見で、NASAの科学者らは小さくて冷たい恒星の周りを接近して周回する7つの地球サイズの惑星を発見したことを発表した。恒星は39光年離れている。ガーディアンのレポートより:
多くの地球サイズの惑星が同じ恒星の周りを周回するのを発見したのは初めてのことで、天の川がそのような世界で満ち溢れているかも知れないことを示唆する予想外の距離で、少なくともサイズと足元の硬さが我々の故郷と共通点がある。惑星は39光年離れたTrappist-1と名付けられた赤色矮星近くを周回しており、生命の兆しを探る主要な候補の恒星系となる。木星よりわずかに大きだけで、恒星は我々の太陽より約2000倍かすかで、弱い光で輝いている。ベルギーのリエージュ大学の天体物理学者マイケル・ギロンは、「恒星はとても小さく冷たいが、7つの惑星は温暖である。拡大解釈すれば表面上に液体の水があり、もしかしたら生命がいるかも知れない。」と語った。[...] 惑星は地球のような大きさだが、それらのサイズは25%小さいものから、10%大きいものまであり、他に大きく異なるものはない。最も際立ったものは、惑星の軌道がどれほどコンパクトかということだ。太陽系で最も内側にある惑星の水星は、Trappist-1から最も離れた7番目の惑星よりも、太陽から6倍離れている。

BoingBoingEngadget

2/21/2017

キアヌ・リーブス、マトリックスの次回作について答える

マトリックスの3作目『マトリックス・レボリューションズ』が公開されて14年になる。キアヌ・リーブスはYahoo Moviesとのインタビューで、マトリックス4の可能性について答えている(最新作の『ジョン・ウィック: チャプター2』で、キアヌとローレンス・フィッシュバーンが共演している)。マトリックスに参加するのに必要なことを彼に尋ねると:

ウォシャウスキー姉妹が参加する必要がある。彼らが脚本を書いて監督しなければならない。僕らがどんな話になるかを知るのはそれからだ。分からないけど、奇妙な話になるだろうね。でもいいじゃないか? 人が死んでも、物語は死なない。物語の登場人物も死なない。

2/20/2017

宇宙線によって深刻なコンピュータ障害が起こる可能性

Slashdotより

ロス・アラモス国立研究所が2012年に、「20年以上に渡り、軍事、商業宇宙産業、コンピュータ産業では、大気の中を通って高エネルギー中性子ストリーミングがコンピュータのエラーを引き起こす可能性があると知られている。匿名の読者がComputerworldを引用する:

あなたのコンピュータがクラッシュしたり、スマートフォンがフリーズしたりしたら、すぐにメーカを責めるべきではない。宇宙線やそれらが生成する電気的に荷電した粒子が本当の障害かも知れない。生きている生物には無害だが、これらの少数の粒子はパーソナル・デバイスの超小型電子回路の動作を妨げるのに十分なエネルギーを持っている... 粒子がチップのメモリの中に保持される個々のデータビットを変えてしまう。結論は、写真の中の1ピクセルを変えてしまうような些細なものでも、旅客機を落とすほどの深刻である。

かつて2003年にベルギーのスカールベークで、シングル・イベント・アップセット(SEU)が電子投票のエラーの原因とされた。電子投票機のビットフリップは、一人の候補者に4096の必要以上の票を追加した。機器が候補者にあり得る数よりも多くの票を与えたがばかりに問題が通知された。「これは本当に大きな問題ですが、一般にはほとんど見えません。」とBharat Bhuvaは語った。Bhuvaは、電子システムに対する放射線の影響を研究するため、1987年に設立されたヴァンダービルト大学の放射線影響研究グループのメンバーである。

Ciscoは2001年から宇宙放射線の研究をしており、9月には顧客がASR 9000ルータで体験した部分的なデータロスについて考えられる説明として、簡単に宇宙線を引き合いに出した

2/19/2017

テロリズムの根本原因の研究

シュナイアーのブログより。

急進的な考えの人がどのようにテロリストになるのかを実地調査(field research)した研究を考察するサイエンス誌の興味深い記事

既存の制約を克服できる研究の可能性は、最近の暴力的過激主義の理解の進展と部分的な抑止と予防の進歩に見ることができる。最も注目すべきは、なぜ個人が暴力的な過激主義者になるのか(例えば、貧困、教育不足、社会的疎外、外国からの侵略、宗教的情熱)、単純化した根本原因解明の探求が徐々に弱まっており、テロリズムを生み出すあるいは意味のある干渉を支援する状況の豊かさや多様性に対応できない。より扱いやすい一連の調査(line of inquiry)は、人がどのように実際にテロネットワークに関与するようになったのかである(例えば、どのように彼らが急進的になり、リクルートされ、行動に移し、理念や仲間を捨てるようになるのか)。

過激派研究国際センター(ICSR)のスーファン・グループやテロ対策センター(米陸軍士官学校)のレポートによると、イスラム国あるいはアルカイダに加わる人々の約3/4はグループでそうしている。これらのグループは、しばしば既存のソーシャルネットワークに関与し、通常は特定の町や地域に集中している。これは多くの人材募集がエージェントによる直接的な個人のアピール、あるいはソーシャルメディア(人材募集のパターンがより分散を伴う)への個人的な露出を必要としないものを示唆している。これらのプロセスが行動に移される特定の条件を確認するためには実地調査が必要がある。テロリスト・ネットワークの自然成長モデルは、抽象的なもので作られたというよりはむしろソーシャル・ネットワークにおける過激な思想の疫学に基づいており、暴力的過激主義への取り組みが厳密な犯罪というよりも公衆衛生を考慮に入れる必要がある。

そのような考えがテロリスト募集に対抗する意味を持つ。現在のUSGの焦点は、テロリストを動機づけると思われるイデオロギーの代替案になることを目的としたカウンターナラティブ(counternarratives)である。この戦略は、ソーシャルグループのアニメータとして人生を与えられ組み込まれているとする人間の状態から脱する方法を論じる。彼らの代わりに、研究や政策が個人向けのカウンターエンゲージメントに焦点を当てる方がいいだろう。彼らの代わりに、研究と政策は、ISISやアルカイダがしばしばするようなフェローシップ、情熱、特定の社会的状況の中の人の目的に取り組み、利用するパーソナライズされた"counterengagement"に焦点を当てる方が良い。この焦点は、積極的な信念と実りのある人生の進路を導くことを通じてではなく、罠や罰(米の法執行機関で利用される最も一般的な慣習)のために疑う若者をやめさせるために、ネガティブな大量メッセージやおとり捜査頼みにすることとは際立って対照的である。少なくとも、どの戦略が働いているか、失敗か、逆効果かを明らかにするための証拠を収集できるコミュニティへの実地調査が必要である。

Googleでのソフトウェア・エンジニアリング (5)

Googleでのソフトウェア・エンジニアリング」と題する論文。

5. 結び

我々は、Googleで利用されている主なソフトウェア・エンジニアリングの慣行(practices)のほとんどを簡単に説明した。もちろん、Googleは今は大きく多様な組織で、組織の一部は異なる慣行を持っている。しかし、ここで説明した慣行は、Googleではほとんどのチームが普通に従っている。

非常に様々なソフトウェア・エンジニアリングの慣行が関与しており、Google成功の他の多くの理由がソフトウェア・エンジニアリングの慣行に関係しているわけではないため、改善された成果を個々の慣行と結び付ける定量的あるいは客観的な証拠を提示するのは非常に困難である。しかし、これらの慣行は、Googleで時間をかけて証明されてきたもので、何千もの優秀なソフトウェア・エンジニアの全体による主観的判断を受けてきたものである。

この論文で説明されている特定の慣行の活用を主張する他の組織にとって、おそらく「Googleにとって十分に良いものである」と言えば助けになるだろう。


Googleでのソフトウェア・エンジニアリング (4.5)

Googleでのソフトウェア・エンジニアリング」と題する論文。

4.5. 勤務評定と報酬

フィードバックは強くGoogleで奨励されている。エンジニアは、"ピア・ボーナス"や"kudos"を通じて明白な正のフィードバックをお互いに与えることができる。従業員は、通常の職務要求(call of duty)を超えて仕事をした他の従業員を指名でき、年に2回までピア・ボーナス(100ドルのボーナス)が与えられる。指名はその理由を説明するウェブフォームに記入するだけである。チームメイトはピア・ボーナスが受け取ったら通知される。従業員は、良い仕事に明白な社会認識を提供する称賛の発言を明確にするため、"kudos"を与えることもできるが、金銭上の奨励金はない。"kudos"には、仕事が通常の職務要求を超える必要はなく、授けることができる回数に制限はない。

マネージャは、プロジェクト完了のようなスポットボーナスを含むボーナスを与えることもできる。また、多くの企業のように、Googleの従業員は業績をベースに年次業績ボーナスや株式報酬を受け取る。

Googleは、自己あるいはマネージャによる推薦、自己レビュー、ピア・レビュー、マネージャの評価を含む非常に慎重かつ詳細な昇進プロセスがある。実際の決定はその情報に基づいて推進委員会によって行われ、その結果は昇進アピール委員会によってさらなるレビューを受ける。ふさわしい人物が昇進するのを確実にすることは、従業員に適切なインセンティブを維持することにとって重要である。

その一方、能力不足は、マネージャのフィードバック、必要なら目標に向けての明示的で明確な能力目標の設定、および目標に向けての進捗評価を含む能力改善プランで対処される。それが失敗した場合、能力不足による解雇の可能性がある。しかし、実際にはGoogleではこれは非常に稀である。

マネージャの能力はフィードバック調査で評価される。全ての従業員は年に2回マネージャの能力に関して、アンケートを記入するよう求められ、その結果を匿名化して集計し、マネージャが利用できるようにする。このような部下からの評価(upward feedback)は 組織を通じて管理の質を維持し、改善するために非常に重要である。


Googleでのソフトウェア・エンジニアリング (4.2、4.3、4.4)

Googleでのソフトウェア・エンジニアリング」と題する論文。

4.2. 施設

Googleは滑り台、ボールプール、ゲームルームのような楽しい施設で有名である。それが素晴らしい才能を引きつけ、保つのに役立っている。Googleの絶品のカフェは従業員に無料で提供されており、Google社員(グーグラー)が職場にとどまるのをそれとなく働きかけている。空腹が退職の理由では決してない。従業員がスナックや飲み物を手に入れることができるマイクロキッチンを頻繁に配置換えすることで、同じ機能を果たすだけでなく、多くの会話がそこで始まり、日常のアイデアの交換が重要な情報源としての役目を果たす。ジム、スポーツ、マッサージが従業員の健康を保ち、元気で、幸せを保ち、生産性とリテンションを改善する。

Googleでは座席に間仕切りがなく、しばしば密集している。異論はあるものの[20]、時として個人の集中を犠牲にしてもコミュニケーションを促進し、効率的である。

従業員は個別の席が割り当てられるが、座席はかなり頻繁に再割り当てされ(例えば、6〜12ヶ月ごとで、しばしば組織の拡大の結果で)、隣り合うあるいはほとんど隣り合う人の間でコミュニケーションを促進することを推奨するため、座席はマネージャが選んでいる。

Googleの施設すべてに最先端のビデオ会議設備を備えた会議室があり、予定されているカレンダーへの招待は相手に接続するにはスクリーン上にタップするだけである。

4.3. トレーニング

Googleは多く方法で従業員の教育を奨励している:

  • 新しいグーグラー(ヌーグラー)は、初期のトレーニング・コースがある。
  • 技術スタッフ(SWEとリサーチ・サイエンティスト)はコードラボから始める: コーディング演習を含む個々の技術の短いオンライン・トレーニング・コース。
  • Googleは従業員に様々なオンラインと個人トレーニング・コースを提供している。
  • Googleは外部機関での学習の支援も提供している。

さらにヌーグラーは学習スピードを上げるのを手助けするため、ふつう「メンター(Mentor)」や別の「バディ(Buddy)」に任命される。内部の社内指導教育には、彼らのマネージャとの定期的なミーティング、チーム・ミーティング、コード・レビュー、デザイン・レビュー、普段の一連の行為を介して行われる。

4.4. 移動

社内の様々な部署間で知識と技術が広まるのを助け、組織間のコミュニケーションを改善するため移動が推奨されている。プロジェクトや仕事の間の移動は、優良な従業員にはその立場で12ヶ月経つと許される。ソフトウェア・エンジニアは他組織で一時的に業務を行うことも推奨されている。例えば、SRE(サイト信頼性エンジニアリング)の6ヶ月のローテーション(一時的な任務)である。


Googleでのソフトウェア・エンジニアリング (4.1)

Googleでのソフトウェア・エンジニアリング」と題する論文。

4. 人事管理


4.1. 役割

以下で詳細は説明するが、Googleはエンジニアリングとマネジメントのキャリアアップの職制を分け、テックリードの役割とマネジメントとを分け、エンジニアリング内に研究職を組み込み、プロダクト・マネージャ、プロジェクト・マネージャ、サイト信頼性エンジニア(SRE)というエンジニアをサポートしている。これらの慣習の少なくともいくつかは、Googleで開発された革新的な文化を維持するために重要と思われる。

Googleでは、エンジニアリングの中にも少数の異なる役割を持っている。各役割の中には、一連の段階でキャリアアップの可能性があり、次の段階で実績を評価して昇進(例えば給与のように報酬の改善に関連する)の可能性がある。

主な役割は次のとおり:

  • エンジニアリング・マネージャー

    このリストの中で唯一の人事管理を行う。ソフトウェア・エンジニアのような他の役割の人は人を管理することもあるが、エンジニアリング・マネージャは常に人を管理する。エンジニアリング・マネージャはしばしば元ソフトウェア・エンジニアで、必ず相当な技術的専門知識を持つ人と同じようなスキルを持っている。

    技術的リーダーシップと人事管理の間には差異がある。エンジニアリング・マネージャは、必ずしもプロジェクトを率いるわけではない。プロジェクトはエンジニアリング・マネージャなることはできるが、ソフトウェア・エンジニアであることが多いテック・リードによって率いられる。プロジェクトのテック・リードには、プロジェクトの技術的決断の最終決定権がある。

    マネージャーはテック・リードの選定、チームの実績に責任がある。彼らは指導やキャリア開発の支援を実行し、業績評価(水平評価から情報を使う、以下を参照)を行い、報酬のいくつかの側面に責任がある。彼らは採用プロセスの一部にも関与している。

    エンジニアリング・マネージャは通常3〜30人の間の範囲で直接管理するが、8〜12人が最も一般的である。

  • ソフトウェア・エンジニア (SWE)

    ソフトウェア開発を行うほとんどの人はこの役割を担っている。Googleでのソフトウェア・エンジニアの採用制約は非常に高い。群を抜いて素晴らしいソフトウェア・エンジニアだけを採用することで、他の組織を悩ます多くのソフトウェア問題は回避あるいは最小限にできる。

    Googleではエンジニアリングとマネジメントのためのキャリアアップの進路が分かれている。人の管理をソフトウェア・エンジニアが行ったり、ソフトウェア・マネージャの役割に移管することは可能だが、もっと高い段階でも人の管理は昇進の要件ではない。より高い段階で、リーダーシップを示すことが必要である。しかし、多くのタイプが提供される。例えば、非常に大きな影響があるとか、とても多くの他のエンジニアによって使われる素晴らしいソフトウェアを作るだけでも十分である。素晴らしい技術スキルを持つが、人を管理するスキルや熱意に欠ける人は、マネジメント・トラックを取る必要がない優れたキャリア・アップ・パスがまだあることを示すため、これは重要である。一部の組織では、社員が昇進のために管理職で終わることに悩んでいるが、チーム内の人事管理を無視するという問題を回避している。

  • リサーチ・サイエンティスト

    この役割の採用基準は非常に厳密で、制約は非常に高く、論文実績とコードを書く能力によって優れた研究能力を立証することが必要である。ソフトウェア・エンジニアの役割にふさわしい学術界の多くの天才たちは、Googleでのリサーチ・サインティストにふさわしくない。Googleでのほとんどの博士号を持つ人は、リサーチ・サインティストというよりソフトウェア・エンジニアである。リサーチ・サインティストは論文を含め研究成果で評価される。しかし、それと職名は別として、Googleではソフトウェア・エンジニアとリサーチ・サインティストの役割にそれほど大きな違いはない。どちらも未発表の研究を行い、論文を発表するが、 新しい製品のアイデアや新しい技術を開発することもでき、どちらもコードを書いたり製品を開発できる。Googleでのリサーチ・サインティストは、普通ソフトウェア・エンジニアと同じチームで働き、同じ製品や同じ研究に取り組んでいる。エンジニアリングの中に研究を取り込む慣習は、新しい研究を出荷中の製品の中に取り込みやすさに大きく貢献する。

  • サイト信頼性エンジニア(SRE)

    運用システムのメンテナンスは、従来のシステム管理者タイプよりもソフトウェア・エンジニアリング・チームによって行われる。しかし、SREの採用要件はソフトウェア・エンジニアリングの要件とはわずかに異なる(ソフトウェア・エンジニアリング・スキルの要件は、ネットワーキングやunixシステム内部などの他のスキルの専門知識の補償があるため、わずかに低くなっている)。SREの役割の本質と目的は、SRE本[7]の中で詳しく説明されているので、ここではこれ以上議論しない。

  • プロダクト・マネージャ

    プロダクト・マネージャは製品の管理に対して責任がある。製品利用者の代弁者として、ソフトウェア・エンジニアの仕事を調整し、ユーザに重要な機能を説き、他のチームと調整し、バグを追跡して予定を決め、高品質の製品を生産するために必要なすべてを保証する。プロダクトは通常、コード自体を書くのではないが、ソフトウェア・エンジニアと協力して正しいコードが書かれることを保証する。

  • プログラム・マネージャ/テクニカル・プログラム・マネージャ

    プログラム・マネジャは、製品を管理するよりプロダクト・マネージャとほぼ同じ役割を持ち、プロジェクト、プロセス、運用(例えば、データ収集)を管理する。テクニカル・プログラム・マネージャも同様だが、例えば音声データを扱う言語のような、仕事に関連する特定の技術的専門知識を必要とする。

    プロダクト・マネージャとプログラム・マネージャに対するソフトウェア・エンジニアの割合は組織全体で異なるが、一般的には高く、例えば4:1から30:1の範囲である。


2/18/2017

Googleでのソフトウェア・エンジニアリング (3.3、3.4)

Googleでのソフトウェア・エンジニアリング」と題する論文。

3.3. プロジェクト承認

ローンチ承認のプロセスは明確に定義されているが、Googleではプロジェクトの承認や取り消しは明確に定義されていない。Googleは会社ができて10年近く経つにも関わらず、今もマネージャ自身になっており、私はどのようにそのような決定になったのか完全に理解していない。一つには、これに対する取り組みが会社全体で統一されていないためである。全てのレベルでマネージャは、チームがどのようなプロジェクトを担当するか説明責任と結果責任があり、彼らが適切として裁量権を行使する。場合によっては、そのような決定は完全にボトムアップ方式で行われ、エンジニアがチームの範囲でどのプロジェクトを担当するか選択する自由を与えられる。他の場合では、そのような決定が経営者やマネージャがどのプロジェクトを先に進めるか、リソースの追加を行うか、キャンセルするかについての意思決定がトップダウン方式で行われる。

3.4. 会社の組織再編成

時々、経営判断で大きなプロジェクトを中止することがあり、その時、そのプロジェクトを担当する多くのエンジニアが新しいチームで新しいプロジェクトを見つけなければならない。同様に複数の地理的な場所にわたって分割されたプロジェクトが少数の場所に統合され、これを達成するために一部のエンジニアはチームやプロジェクトを変更する必要がある場合、「デフラグ(defragmentation)」の取り組みが行われる。そのような場合、エンジニアは一般的に、その地理的な場所で、可能な地位の範囲で新しいチームの役割を選ぶ自由が与えられる。あるいはデフラグのケースでは、別の場所に移動することで、同じチームとプロジェクトに残るオプションを与えられるかも知れない。

さらに、チームを統合・分割したり、レポーティング・チェーン(reporting chains)を変更するような会社の組織再編は、どのようにGoogleが他の大企業と比較すればいいか分からないが、かなり頻繁に行われるようだ。多くの場合、テクノロジー主導型の組織では、技術や要件が変化し、組織的な非効率性を回避するため、やや頻繁な再編が必要になる。


Googleでのソフトウェア・エンジニアリング (3.2)

Googleでのソフトウェア・エンジニアリング」と題する論文。

3.2. 目標と結果 (Objectives and Key Results: OKRs)

Googleでは、個人やチームは目標を明示的に文書化し、これらの目標を目指して進捗を評価することを必要とする。チームは、これらの目標の進捗を示す測定可能な結果(key results)を付けて、四半期と年次の目標を設定する。これは会社のあらゆるレベルで行われ、会社全体の目標が明確になる。個人と小規模チームの目標は、会社全体の目標の一部であるより幅広いチームのより高いレベルの目標と合わせるべきである。各四半期の終わりに、測定可能な結果の進捗が記録され、各目標に0.0(進捗なし)から1.0(100%完了)までの成績が与えられる。OKRとOKRの成績は、通常Google全体で明らかにされるが(機密性の高いプロジェクトなど特別慎重に扱うべき情報を除く)、個人の業績評価への材料として直接使われることは無い。

OKRは高く設定すべきである: 求められる目標全体の平均スコアは65%で、つまりチームは実際に達成する可能性がある目標よりも約50%多くタスクの目標を設定することが奨励されている。もし、チームがそれよりもかなり高い成績を付けた場合、次の四半期にはもっと野心的なOKRを設定することを奨励される(逆にそれよりもかなり低い場合、次の四半期にはOKRをより控えめに設定することが奨励される)。

OKRは会社の各部門が何に取り組んでいるかを伝える重要な仕組みを提供し、社会的インセンティブを介して従業員の業績を向上させる... エンジニアは、チームがOKRを採点する会議が行われていることを知っているが、OKRが業績評価や報酬に直接的な影響を与えないにも関わらず、成績を良くしようという自然な意欲を持つ。客観的で測定可能な結果を定義することは、良い成績を挙げようとする人間が共通の目標への進捗に実際に測定可能な影響を及ぼすことへ向かわせることを確実に手助けする。


Googleでのソフトウェア・エンジニアリング (3.1)

Googleでのソフトウェア・エンジニアリング」と題する論文。

3. プロジェクト管理


3.1. 20%時間

エンジニアは、マネージャや他の誰からの承認を必要とせずに、自分で選択したプロジェクトで働く時間の20%まで費やすことが許されている。いくつかの理由で、エンジニアに対する信頼は非常に有益である。第一に、良いアイデアを持っている人は、たとえ他の人がすぐに価値がある分からないようなアイデアを持っていたとしても、アイデアの価値を示すためにプロトタイプを開発し、デモ、プレゼンを行うための十分な時間を持つことができる。第二に、管理者に他に隠されているかも知れないアクティビティの可視性を提供する。20%時間を許可する公式なポリシーを持たない他の企業では、エンジニアは時々管理者に知らされることなく、スカンクワーク・プロジェクトに取り組むことがある。エンジニアがそのようなプロジェクトについてオープンにできるなら、管理者がプロジェクトの価値に同意できない場合でも、定期的な状況更新の中でそのようなプロジェクトに取り組んでいることを説明する方がはるかに優れている。それを支援する全社的な公式ポリシーや文化を持つことは、これを実現可能にする。第三に、エンジニアが自分の時間のほんの一部をもっと楽しいものに取り組む時間に費やすことを許可することで、自分がしていることにやる気を出させ、刺激を与え続け、とても詰まらない仕事に100%の時間取り組まなければいけないと感じることで簡単に起きてしまう燃え尽き症候群を止めることができる。熱中していて意欲のあるエンジニアと燃え尽きたエンジニアとの間の生産性の差は20%を超えている。第四に、イノベーションの文化を奨励する。楽しく仕事に取り組んでいる他のエンジニアを見ると、実験的な20%プロジェクトで同じことをすることを全ての人に奨励している。


2/17/2017

Googleでのソフトウェア・エンジニアリング (2.9、2.10、2.11)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.9. ローンチの承認

ユーザから見える変更、あるいは重要な設計変更のローンチには、変更を実装するコアエンジニア・チームの外の多くの人からの承認が必要である。特に、承認(しばしば詳細なレビューの対象となる)はコードが法的要件、プライバシー要件、信頼性要件(例えば、サーバの障害を検知する適切な自動監視を行い、適切なエンジニアに自動的に通知する)、ビジネス要件などに従うことを保証する必要がある。

ローンチ・プロセスは、重要な新製品や新機能が登場するたびに、社内の適切な人物に通知されるように設計されている。

Googleは、必要なレビュー、承認、各製品ごとに定義されたローンチ・プロセスが遵守されているかを追跡するのに使われる内部ローンチ承認ツールを持っている。このツールは簡単にカスタマイズでき、様々な製品あるいは製品分野で必要な様々なレビューや承認に対応できる。

ローンチ・プロセスの更なる情報は、SRE本の第27章を参照いただきたい[7]。

2.10. 事後分析 (Post-mortems)

我々のプロダクション・システムに重要な障害、あるいはそれに類する事故が発生した場合、関係者は事後分析のドキュメントを書く必要がある。このドキュメントは、タイトル、概要、影響、経過、根本的な原因、作業したもの/作業をしなかったもの、アクション・アイテムなどを含むインシデントを説明する。焦点は問題への取り組みにあり、今後回避する方法、人に責任を向けるのではなく分かち合うことにある。インパクト・セクションでは、障害の継続時間、失われたクエリの数(あるいは失敗したRPCなど)、および収益の観点から、インシデントの影響を定量化しようとする。タイムライン・セクションでは、障害につながるイベントのタイムラインと診断と、それを是正する手順を示す。何を実施して、何を実施しなかったのかの区分が、どの仕事が問題を迅速に検知して解決の手助けになったのか、何がうまくいかなかったのか、どの具体的な活動が(おそらく、特定の人に割り当てられるバグとして届けられた)将来の同様の問題の可能性や重度を減らすことができるかを学習する知識を類型化する。

2.11. 高頻度の書き直し (Frequent rewrites)

Googleのほとんどのソフトウェアは数年ごとに書き直される。これは信じられないほどコストが掛かると思われるかも知れない。確かに、Googleのリソースの大部分を使っている。しかし、Googleの敏捷性や長期的成功にとって鍵となる極めて重要な利点もある。数年で、製品要件は著しく変化し、周辺のソフトウェア環境や他のテクノロジも変化し、テクノロジあるいは市場の変化がユーザのニーズ、欲求、期待に影響を与える。数年前のソフトウェアは、より古い要件で設計されており、現行の要件に最適な方法で設計されていない。さらに多くの複雑さが積み重なっている。コードを書き直すことは、もはやそれほど重要ではない要件に対処していた不要で積み重なった複雑さを全て除去できる。加えて、コードの書き直しは、知識や当事者意識を新しいチームのメンバーに伝える方法でもある。この当事者意識は生産性にとって非常に重要である: エンジニアは機能を開発したり、コードの問題を自分のこととして感じて修正することに自然と努力を注いでいる。高頻度の書き直しは、様々なプロジェクト間のエンジニアの流動性を促し、アイデアの相互交流を促すのにも役立つ。高頻度な書き直しは、コードが最新のテクノロジーと技法を使って描き直されることにも確実に役立つ。


イーロン・マスクは本当に穴を掘るのか?

Slashdotより

時々、イーロン・マスクが語ることは本気なのか分からなくなる。しかし、彼の「ボーリングする」主張に関しては、それが本当に起こっている。ブルームバーグとの幅広いインタビューで、彼は新しいベンチャー「The Boring Company」についてさらに語った。そのアイデアは数週間前の土曜日の朝、マスクが「交通渋滞にはうんざりだ。トンネル掘削機を作って、穴を掘り始めるぞ...」とツイートした時に始まった。数時間後、マスクは次のように付け加えた。「社名は'The Boring Company'がいいな。それはやることが退屈だ(boring)。私は実際にこれをやるつもりだ。」記事から抜粋:
そして、1月の金曜の正午ごろ、作業員が掘削を開始した。「『日曜日の夕方までにできる巨大な穴は何だ?』みたいだった。[...]」マスクは言う。「私の別のアイデアは、Tunnels R Usと名付け、本質的にToys "R" Usをトロールして訴訟を提起する」彼は大声で、歯切れよく(well-articulated: よく整理統合されている)ハハハハと笑う。「今、代わりにAT&Tをトロールすることに決めたよ! 我々はAmerica Tubes and Tunnelsと名付けるつもりだ。」トンネル会社がSpaceXの子会社か独立会社になるのか彼に尋ねると、彼は曖昧に返事をした。「私のTwitterを読まないのかね? The Boring Companyだよ。またはTBC、続く(To Be Continued)だ。」側近が口を挟む: はい、The Boring Company、別名To Be Continued、別名Tunnels R Us、別名American Tubes and Tunnels、何でも、は本当に独立した会社になる。トンネル技術はロケットよりも古く、掘削速度は50年前とほとんど同じである。マスクは、最終的に非常に高速な掘削マシンを作って、数千マイル掘り進んで、ハイパーループなど高速鉄道や自動車のための30段もの数のトンネルを含む広大な地下ネットワークを作り出すことを望んでいる。便利で市の許可なく合法的に掘削することができるので、マスクは最初の掘削の場所としてSpaceXの駐車場を選んだ。計画は、現在の穴を大型のトンネル掘削マシン向けに設計された出入り口を拡張し、マシンが地下50フィート潜ると、水平に掘削を開始することで、ガスや下水道をクリアするのに十分低い位置になり、地表面で検知できなくなる。
大見出しのブルームバーグに100点、洞察力のある記事のようで馬鹿らしい記事だ。

Hacker NewsTechCrunch

2/16/2017

ブルース・シュナイアー、IoT規制のための新しい政府機関創設を呼びかけ

CircleIDより

セキュリティ専門家のブルース・シュナイアーはRSAカンファレンスでの公演で、何もしない事は「リスクは大きく、利害関係は非常に高い」と主張し、モノのインターネットの規制に焦点を当てた新しい政府機関の創設を呼びかけた。ロブ・ライトがTechTargetにレポートしている:「RSAカンファレンス2017でのモノのインターネットの規制とセキュリティに関する広範囲な話し合いの中で、IBM ResilientのCTOであるシュナイアー氏は、Miraiボットネットのような脅威に対処するために政府の介入が必要だと主張した。彼は、多くのデバイスを生産する製造業者は本質的に安全ではなく、効果的にパッチを当てることができない上、IoTマルウェアは実際のデバイス上にほとんど影響を与えないため、IoTセキュリティを独自の問題として説明した。セキュリティ侵害されたデバイスは第三者への攻撃に利用されるため、... ユーザの一部やデバイスメーカーにとって、行動を起こすインセンティブはほとんどない。」

Googleでのソフトウェア・エンジニアリング (2.8)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.8. リリース・エンジニアリング

いくつかのチームには専任のリリース・エンジニアがいるが、Googleのほとんどのチームでは、リリース・エンジニアリング作業は一般のソフトウェア・エンジニアによって行われる。

ほとんどのソフトウェアのリリースは頻繁に行われる: 毎週あるいは隔週でのリリースが共通目標で、いくつかのチームは毎日リリースを行なっている。これは通常のリリース・エンジニアリング・タスクのほとんどを自動化することで可能となっている。頻繁にリリースを行うと、エンジニアのモチベーションを維持するのに役に立つ(将来に向けて、数ヶ月とか数年とかリリースが無ければ、何かにワクワクするのは難しくなる)、そして一定期間での反復を増やすことで全体の速度を上げ、フィードバックの機会やフィードバックに応答するチャンスが増える。

通常、リリースは未使用のワークスペースで始まり、最新のグリーン・ビルド(例えば、全ての自動テストが合格した最後の変更)の変更番号に同期することで、リリース・ブランチが作られる。リリース・エンジニアはチェリーピックされる。言い換えるとメイン・ブランチからリリース・ブランチにマージされる追加変更を選択できる。その後、ソフトウェアが最初から再構築され、テストが実行される。もし、テストが失敗した場合、追加の変更が加えられて障害が修正され、追加の変更がリリース・ブランチにチェリーピックされる。その後、ソフトウェアが再構築され、テストが再実行される。テストが全て合格すると、ビルドされた実行ファイルやデータファイルがパッケージ化される。これら全ての手順が自動化されるため、リリース・エンジニアはシンプルなコマンドを実行するだけで済むし、メニュー・ドリブンのUIでいくつかの項目を選択して、チェリーピックする変更(もしあれば)を選択できる。

候補ビルドがパッケージ化されると、一般に少数のユーザ(時には開発チームのみ)によってさらなる統合テストのためにステージング・サーバにロードされる。

有用なテクニックは、本番トラフィックからのリクエスト(サブネットの)のコピーをステージング・サーバに送信することと、実際の処理のために現在運用中のサーバに同じリクエストを送信することである。ステージング・サーバからの応答は破棄され、稼働中の本番サーバからの応答はユーザに送り返される。これにより、サーバを本番にする前に、深刻な問題を引き起こすかもしれない問題を確実に検出するのに役に立つ。

次の段階は通常、稼働中の本番トラフィックの一部を処理する一台以上の"カナリア"サーバに公開することである。ステージング・サーバとは異なり、これらは実際のユーザ向けに処理し、応答する。

最後に、リリースが全てのデータセンターの全てのサーバに公開される。非常に高いトラフィック、高品質のサービス向けには、これまでの手順で捕えられなかったバグが新たに取り込まれたことが原因で発生した障害の影響を軽減するため、数日かけて徐々に公開される。

Googleのリリース・エンジニアリングの詳細は、SREブックの第8章を参照して欲しい[7]。[15]も参照して欲しい。


Googleの公然の秘密の新しいOS

Slashdotより

昨年末の報道によると、GoogleはAndromedaと呼ばれる新しいオペレーティングシステムに取り組んでいる。それについてまだよく分かっていないが、Googleがウェブサイト上に提供する文書によると、オペーレティングシステムの実際の名前はFuchsia、カーネルはMagentaと呼ばれていることがはっきりする。技術に詳しい人が文書を丹念に調べ、次のことを共有する:
私の素朴な目には、Chrome OSがAndroidに統合されるというよりも、AndroidとChrome OSの両方がFuchsiaにマージされるように見える。注目されるのは、これらのオペレーティングシステムは、例えばAndroidチームがChrome OSチームと一緒にアップデートエンジンをNougatに持ち込むために協力し、プラットフォームにA/Bアップデートを導入していたように、既にマージが始まっていたということだ。Googleは、驚くべきことに粗末なIntel NUCを含む多くのプラットフォームでAndromedaを育てている。ARM、x86、MIPSの立ち上げはまさにAndroidの後継に期待されるもので、このプラットフォームはインテルのノートPC上でも動作するのは明らかに見える。私の最も有力な説は、APIとランタイムとしてのAndroidは、Andromedaの中でレガシー環境として生き残るだろう。Androidの開発全てが直ちに止まるというわけではないが、極めてありそうもないように思える。しかし、Googleは長期に渡り同等のアプリフレームワークとして二つのUI APIを押し出すことはできない: Mojoは明確に未来である。でも、Mojoとは何だ? それはAndromedaアプリを書くための新しいAPIで、Chromiumから提供されている。Mojoはもともと「複数タイプのサンドボックス・コンテンツをサポートできるChromeのレンダラーとプラグイン・プロセスから共通プラットフォームを抜き出して」作られたものだ。

Hacker News 12Tech Specs Blogスラド

2/15/2017

Googleでのソフトウェア・エンジニアリング (2.6、2.7)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.6. プログラミング言語

Googleのソフトウェアエンジニアは、Googleで公式に認可された5つのプログラミング言語、C++、Java、Python、GoあるいはJavaScriptのうち一つでプログラムすることが強く推奨されている。使用されるプログラミング言語数を最小限に抑えることで、コードの再利用やプログラマのコラボレーションへの障害が少なくなる。

会社全体のコードが、スタイル、レイアウト、命名規則などが同じように記述されることを保証するため、各言語のGoogleスタイルガイドがある。さらに、コードの可読性(readability)について注意を払う経験豊かなエンジニアが、レビュー担当者が作者はその言語で可読なコードを書く方法が分かっていると確信するまで、変更あるいは一連の変更を十分にレビューすることで、特定の言語での可読で自然なコードを書く方法を他のエンジニアに訓練する全社的な可読性のトレーニングプロセスがある。特定の言語で重要な新しいコードを追加する変更は、それぞれその言語で可読性トレーニング・プロセスを合格した人によって承認されなければならない。

これらの4言語に加えて、特定な目的(例えば、ビルド・ターゲットや依存性を指定するために使われるビルド言語)のため、多くの専門のドメイン固有言語(DSL)が使われている。

これらの異なるプログラミング言語間の相互運用は、主にProtocol Buffersを使って行われている。Protocol Buffersは効率的だが拡張可能な方法で構造化データをエンコードする方法である。これらのオブジェクトの組み立て、アクセス、シリアライズ、デシリアライズのための記述を取り込み、C++、Java、Pythonでコードを生成するコンパイラと共に構造化データを規定するドメイン固有言語を含んでいる。GoogleのProtocol BuffersはGoogleのRPCライブラリに統合されており、RPCフレームワークによって自動的に処理される要求や応答のシリアライズやデシリアライズを行うことで、簡単に言語間のRPCを実現している。

プロセスの共通性は、コードベースが膨大で多様な言語であっても、開発を容易にするための鍵である: 通常のソフトウェア・エンジニアリング・タスク(例えば、チェックアウト、編集、ビルド、テスト、レビュー、コミット、バグ報告など)をすべて実行する単一のコマンドセットが存在する。そして、何のプロジェクトあるいは言語であろうと同じコマンドを使うことができる。開発者は、編集中のコードが異なるプロジェクトの一部であっても、異なる言語で書かれているというだけなので、開発者は新しい開発プロセスを習得する必要はない。

2.7. デバッグとプロファイル・ツール

Googleサーバは実行中のサーバをデバッグするための様々なツールを提供するライブラリにリンクされている。サーバがクラッシュした場合、シグナルハンドラが自動的にスタックトレースをログファイルにダンプすると同時にコアファイルを保存する。クラッシュがヒープメモリ不足によるものなら、サーバはライブ・ヒープ・オブジェクトのサンプリングされたサブセットの割り当てサイトのスタックトレースをダンプする。入力方向と出力方向のRPC(タイミング、エラー率、速度制限など)、コマンド行フラグ値の変更(例えば、特定のモジュールのロギングの詳細度を増すこと)、リソース消費、プロファイルなどを分析できるデバッグ用ウェブ・インタフェースも存在する。これらのツールは、gdbのような従来のデバッガを起動することが稀であるため、デバッグ全体としての容易さを大幅に向上させる。


Googleでのソフトウェア・エンジニアリング (2.4、2.5)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.4. テスト

Googleでは、ユニットテストが強く推奨され、広く実践されている。本番環境で使われる全てのコードにユニットテストを行うことを求めている。コード・レビュー・ツールはソースファイルが対応するテストをせずに追加された場合、強調表示される。コードのレビュー担当者は普通新しい機能を追加する変更には、その新しい機能をカバーする新しいテストを加える必要がある。モッキング・フレームワーク(大きなライブラリに依存するコードでさえ、軽量のユニットテストを作ることができる)は非常に人気である。

統合テストや回帰テストも広く実践されている。

前に「事前サブミット・チェック」で議論した通り、テストは自動的にコード・レビューとコミット・プロセスの一部として強制される。

Googleはテスト対象を評価するための自動化ツールがある。その結果はソースコード・ブラウザにオプションレイヤとして統合されている。

デプロイ前の負荷テストもGoogleでも必須である。チームは重要な数値指標、入力要求の割合によって変わる特にレイテンシーとエラー率がどのようになっているかを示す表やグラフを作成することを求めている。

2.5. バグ・トラッキング

Googleでは、バグ、機能要求、顧客が抱える問題、プロセス(例えば、リリース、クリーンアップ作業)のような問題の追跡にBuganizerと呼ばれるバグ・トラッキング・システムを使用している。バグは階層構造を持つコンポーネントに分類され、各コンポーネントはデフォルトの代理人(assignee)と、デフォルトのメーリングリストへのCCを持つことができる。レビューのためにソースの変更が送られると、エンジニアは変更と問題番号を結び付けるよう促される。

Googleではそれらのコンポーネント内の未解決問題を定期的に精査し、優先順位付けをし、特定のエンジニアへ適切に割り当てることがチームにとって一般的である(全員ではないが)。いくつかのチームはバグトリアージの責任を負う特定の個人がいて、他のチームでは定期的なチームミーティングでバグトリーアジを行う。Googleでは多くのチームが、バグに関するラベルを利用して、バグがトリアージされたかどうか、各バグの修正対象となるリリースが絞られる。


Googleでのソフトウェア・エンジニアリング (2.3)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.3. コード・レビュー

Googleはメールと統合された優れたウェブベースのコード・レビュー・ツールを持っており、作者がレビューを要求し、レビュー担当者は差分(うまく色分けされて)を並べて閲覧でき、それらのコメントできる。変更の作者がコード・レビューを開始すると、レビュー担当者は変更のウェブ・レビュー・ツールのページへのリンクがメールで通知される。レビュー担当者がレビュー・コメントを投稿すると、メール通知が送信される。さらに自動化ツールは例えば自動テストの結果や静的解析ツールの調査結果を含む通知を送信することができる。

メインのソースコード・リポジトリへの全ての変更は、少なくとも一人のエンジニアによってレビューされなければならない。変更の作者が修正されるファイルの所有者の一人でない場合、少なくとも所有者の一人がレビューと変更の承認を行わなければならない。

例外的なケースでは、サブツリーの所有者はレビュー前にそのサブツリーへの緊急変更をチェックイン(コミット)できるが、それでもレビュー担当者は任命されなければならないし、変更の作者やレビュー担当者は変更がレビュー・承認されるまで、それについて自動的に表示されるだろう。このような場合、レビューのコメントに対処するため、必要となるあらゆる修正は、元の変更が既にコミットされているため、別の変更で行う必要がある。

Googleは既知の変更のためにレビュー担当者を、修正されたコードの所有権やオーナーシップ、最新のレビュー担当者の履歴、潜在的なレビュー担当者毎のコードレビューのペンディング数を検索することで、自動的に提案するツールを持っている。影響を与える各サブツリーの所有者の少なくとも一人がレビューして変更を承認しなけばならない。しかし、それとは別に、作者が適切なレビュー担当者を自由に選択できる。

コードレビューに伴う潜在的な問題の一つは、レビュー担当者の応答が非常に遅い、あるいは変更の承認に過度に気乗りしない場合は、開発を減速させる可能性がある。コードの作者がそのような問題を避けるレビュー担当者を選択する事実は、エンジニアはコードについて過度に独占したがるレビュー担当者を避ける、あるいはレビュー担当者を通してより少ないシンプルな変更のレビューを送る、より経験のあるレビュー担当者あるいは数人のレビュー担当者により複雑な変更のレビューを送る。

各プロジェクトのコードレビューの議論はプロジェクトのメンテナーによって指定されたメーリングリストに自動的にコピーされる。その変更のレビュー担当者として任命されているかどうに関わらず、コミットされた変更の前でも後でも、誰でも変更にコメントを加えることができる。もし、バグが見付かったら、そのバグを導入した変更を突き止め、元の作者やレビュー担当者がそれを認識できるよう、元のコードレビュースレッド上に間違いを指摘するコメントを行うのが一般的である。

コードレビューを複数のレビュー担当者に送信し、他のレビュー担当者がコメントする前にフォローアップの変更で取り扱われる後続のレビューコメントと共に、そのうちの誰かを承認してすぐに変更をコミットしてもらうことも可能である(もちろん、作者あるいは最初に応答したレビュー担当者のどちらかが所有者に提供される)。これによりレビューの応答時間を短縮することができる。

リポジトリのメインセクションに加えて、通常のコードレビュー要求が強制されない実験的なリポジトリがある。しかし、本番環境(production)で実行されるコードはリポジトリのメインセクションになければならない。そして、エンジニアは実験的に開発してからメインセクションに移すよりはむしろリポジトリのメインセクションでコードを開発することを強く推奨している。コードレビューは後よりむしろコードが開発された時点の方が最も効果的である。実際に、エンジニアはしばしば実験中のコードでもコードレビューを要求する。

エンジニアは個々の変更を小さく保つよう推奨している。大きな変更はレビュー担当者が簡単に一気にレビューできるよう、できれば一連の小さな変更に分けることが推奨されている1。これにより、作者が各ピースのレビュー中に提案された大きな変更に容易に対応できるようになる。非常に大きな変更はしばしば柔軟性に欠けており、レビュー担当者が提案した変更に抵抗する。変更を小さく保つ一つの方法は、コードレビュー・ツールが変更サイズの説明を付け、各コードレビューをラベル付する。30-99行の変更を追加/削除/取り除く変更は"中規模サイズ"とレベル付し、300行を超える変更はさらに批判的な(disparaging)ラベルを付けて、例えば"大規模"(300-999)、"信じられないほど巨大"(1000-1999)などとラベル付する。(しかし、通常のGoogleの方法では、毎年数日間は海賊口調日(talk-like-a-pirate day)のように、別の言い回しで親しみのある説明に置き換えることによって楽しいものになる。)


1. これはここ数年で若干変更された。コードレビュー・ツールの最新版は大きなコードレビューに対してもはや軽蔑的なラベルを使わなくなっている。しかし、それらはまだサイズで、例えば"S"、"M"、"L"、"XL"とラベル付されている。


米モバイルアプリ領域でのCDNのシェア

StreamingMediaBlogより。PacketZoomの宣伝が入った記事だが、面白い記事。モバイル上のTCP通信に最適化したCDNソリューションが必要となっている。もう一つ、Google(Global Cache)やOpenConnectが無いのだが...

PacketZoomが、どのCDNソリューションが市場勢力図で優位に立っているか、そしてウェブとモバイルアプリの間でのCDN市場シェアがどのくらい変化しているかを見るため、最近トップ100のウェブサイトを解析し、トップ100のモバイルアプリと比較した。データは、Akamaiが35.3%の市場シェア(驚きはない)でリードしており、Fastly、Verizon、AmazonのようなベンダーがAkamaiの1/3で続いている。さらに、複数の小規模なプレイヤが、既に市場は成熟し飽和していることを示唆している。

Screen Shot 2017 02 13 at 11 28 08 PM

PacketZoomはNetflix、Uber、Snapshotなどのトップ100のモバイルアプリも解析し、CDN市場シェアによって見つかったものを分析し、支配的なプレイヤを探している。今回の結果は、おそらく強力な開発者の結びつきのためで、Amazonが40%の市場シェアでリードしていることを示している。Amazonのコンテンツ配信サービスCloudFrontは、他のAmazon Web Service製品と統合されているので、エンドユーザにコンテンツを配布する簡単な方法を開発者に提供する。従って、Amazonをトップに押し上げている。AkamaiとVerizonは市場シェアがそれぞれ14%と11%で続いており、小規模プレイヤが少ないことは進化する市場を意味している。

Screen Shot 2017 02 13 at 11 35 45 PM

このデータから得られる重要な点は、モバイルアプリ市場はコモディティ化されたCDN市場とは非常に異なる新しい世界であり、誰かが予測していたよりも急速に成長している。モバイルアプリはモバイル第一の世界を念頭に置いて設計された配信ソリューションを必要とし、多くのCDNがまだ適応に苦労している。

PacketZoomは、Amazon CloudFrontが両方のソリューションが同じデータセンタで動いているため、CDNエッジサーバへの余計なネットワークホップがなくなり、最適な結果を示している。既にAmazon CloudFrontの使いやすさに慣れている複数のモバイルアプリの開発者は、PacketZoomのMobile Expresslaneと組み合わせることでモバイルアプリのパフォーマンスを最大限に引き出す最も簡単かつ強力な方法だと教えてくれた。 CDN市場に来る新しいソリューションについての興味深いことは、従来のCDNを置き換えるのではなく、むしろCDNをより良くしようとしている点である。PacketZoomのアプリ内技術はCDNエンハンサーとしてユニークな立場にあり、CDNの代用品ではない。モバイルラストマイルで障害を取り除くことによって、PacketZoomはパフォーマンスを2倍から3倍に大幅に向上させ、TCP接続の劣化からセッションの80%を救済し、CDNのコストを削減する。

2/14/2017

Googleでのソフトウェア・エンジニアリング (2.2)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.2. ビルド・システム

Googleは、コンパイル、ソフトウェアのリンク、テストを行うBlaze*と知られる分散型ビルドシステムを使用している。これはリポジトリ全体を横断して働くソフトウェアのビルドとテストの標準コマンドを提供する。これらの標準コマンドや高度に最適化された実装が、Googleエンジニアにとって、リポジトリのソフトウェアをビルドやテストするのがとても単純で素早くなることを意味する。この一貫性が、エンジニアがプロジェクトの境界を横断して変更を行うことを実践すのに役立つ成功への鍵である。

* オープンソース化したものがBazel思われる

プログラマはBlazeがソフトウェアのビルド方法を決定するために使用する"BUILD"ファイルを書く。ライブラリ、プログラム、そしてテストのようなビルド・エンティティ(実体)は、各エンティティ、名前、ソースファイル、ライブラリあるいは依存する他のビルド・エンティティを指定する極めて高水準な宣言的ビルド仕様を使って宣言される。これらのビルド仕様は「ビルド・ルール(規約)」と呼ばれる宣言で構成される。各々が「ここに他のライブラリに依存するソースファイルを持つC++ライブラリがある」のような高水準なコンセプトを規定する。そして、一連のビルドステップに各ビルドルールをマッピングするのをビルドシステムに委ねられる。例えば、各ソースファイルをコンパイルするステップや、リンクのためのステップ、使用するコンパイラやコンパイルフラグを決定するためのステップである。

一部の例、特にGoプログラムは、(しばしば)BUILDファイルの依存情報がソースファイルの依存情報を抽象化しているので、ビルドファイルが自動的に生成(更新)できる。しかし、それでもリポジトリにチェックインされる。これにより、ビルドシステムはソースファイルよりむしろビルドファイルのみを分析することで依存関係を迅速に判断でき、サポートされる多くの様々なプログラミング言語のためのビルドシステム、コンパイラ、解析ツール間で過度な結合を回避することを保証する。

ビルドシステムの実装は、Googleの分散コンピューティング・インフラを使用している。各ビルドの作業は通常、数百あるいは数千のコンピュータに分散されている。これにより、非常に大きなプログラムを迅速にビルドし、並行して数千のテストを実行することを可能にしている。

個々のビルドステップは外部から影響されないよう(hermetic)にしなければならない: それらは宣言された入力にのみ依存する。全ての依存関係が正しく宣言されるようにすることは、ビルドの配布の結果である: 宣言された入力のみがビルドステップが実行されているコンピュータに送られる。その結果、ビルドシステムは真の依存関係を知る頼みにできる。ビルドシステムが呼び出すコンパイラは入力として扱われる。

個々のビルドステップは決定論的(deterministic)である。結果として、ビルドシステムはビルド結果をキャッシュできる。ソフトウェア・エンジニアはワークスペースを古い変更番号に同期させ再構築し、正確に同じバイナリを取得できるだろう。さらに、このキャッシュは様々なユーザ間で安全に共有できる。(この作業を適切に行うには、例えば生成された出力ファイルのタイムスタンプを取りやめるなど、ビルドによって呼び出されたツールの非決定性を取り除く必要がある。)

ビルドシステムは信頼性がある。ビルドシステムは、ビルド・ルール自体への変更の依存関係を追跡し、生産アクションが変更された場合、例えばコンパイラオプションのみが変更された場合など、たとえアクションへの入力が無かった場合でも、ターゲットを再ビルドすることができる。ビルド途中での中断、あるいはビルド中のソースファイルの修正でも、適切に処理を行う: そのような場合は、ビルドコマンドを再実行するだけで良い。"make clean"に相当するコマンドを実行する必要はない。

ビルド結果はクラウドにキャッシュされる。これには中間結果も含まれる。もし、別のビルド要求が同じ結果が必要な場合、ビルドシステムは要求が別のユーザからであっても、再ビルドではなく自動的に再利用を行う。

インクリメンタル再ビルドは高速である。ビルドシステムはメモリに常駐しているので、再ビルドには、最後のビルドから変更されたファイルだけをインクリメンタルに解析できる。

事前サブミット(Presubmit)・チェック。Googleはコードレビューを開始するあるいはリポジトリに変更をコミットする準備をする際、一連のテストを自動的に実行するツールを持っている。リポジトリの各サブツリーは、どのテストを実行するか、コードレビュー時あるいはサブミット前直ちに実行するか、あるいはその両方かを決定する設定ファイルを含むことができる。テストは同期的に、例えばレビューの変更を送る前、あるいはリポジトリに変更をコミットする前に実行する(高速な実行テストに適している)、あるいは非同期に行うことができる。そして、結果がレビュー・ディスカッション・スレッドにメールで送信される。[レビュー・スレッドは、コードレビューが行われるメールスレッドである; そのスレッド内の全情報がウェブベースのコードレビュー・ツールにも表示される。]


イーロン・マスク: 人間はマシンと融合する必要がある

Slashdotより

億万長者のイーロン・マスクは革新的なアイデアを出すことで知られている。月曜日、ドバイの世界政府サミットで驚かされるようなことはなかったが、彼は、時間とともに我々は生物学的知性とデジタル知性の密接な融合を経験するだろうと予想した。CNBCの報道を通じて彼は付け加えた:
「大部分は帯域幅、あなたの脳とあなた自身のデジタルバージョン間の接続、特に出力の速度についてです。」マスクは、コンピュータは1秒に1兆ビットで通信できるが、一方で人間の主な通信手法はモバイルデバイスで指を使ってタイプすることで、1秒で約10ビット行うことができる、と言うことで彼が意味することを説明した。マスクによると、AIが広く普及する恐れのある時代には、人間は役に立たなくなるので、マシンと融合する必要がある。「脳への広帯域幅のインタフェースは人間とマシンの知性間の共生を実現する助けとなるだろう、そして制御問題(control problem)と実用性問題(usefulness problem)は解決するかも知れない。」とマスクは説明した。

Hacker NewsTechCrunchEngadget

2/13/2017

Googleでのソフトウェア・エンジニアリング (2.1)

Googleでのソフトウェア・エンジニアリング」と題する論文の2.1節、ソース・リポジトリ。

2. ソフトウェア開発


2.1. ソース・リポジトリ

Googleのコードの大部分は一つにまとめられたソースコード・リポジトリに保存されており、Googleの全てのソフトウェア・エンジニアがアクセスできる。明らかな例外に、特別に独立したオープンソースのリポジトリを使用する2つの巨大なオープンソース・プロジェクトChromeとAndroidがある、分かれたオープンソース・リポジトリを使用し、読み取りアクセスがより緊密にロックされている高価値あるいはセキュリティ的に重要なコードの一部である。しかし、ほとんどのGoogleプロジェクトは同じレポジトリを共有している。2015年1月時点、10億のファイルを含む86テラバイトのレポジトリには、900万以上のソースコードファイル、合計20億行のソースコードが含まれており、3500万のコミット履歴と1日当たり4万コミットの変更がある[18]。リポジトリへの書き込みアクセス権は制御されている: リポジトリの各サブツリーのリストされている所有者のみがサブツリーへの変更を承認できる。しかし、一般的にどのエンジニアもコードの一部にアクセスでき、チェックアウトしてビルドでき、ローカルに変更でき、テストでき、コードの所有者によってレビューのための変更を送ることができる。文化的には、エンジニアはプロジェクトの境界を問わず、壊れたものを確認して修正し、修正方法を知ることが奨励されている。これはエンジニアに自信を持たせ、それを使用する人のニーズを満たす高品質のインフラにつながっている。

ほとんど全ての開発はブランチではなく、リポジトリのヘッドで行われている。これが、 統合の問題を初期に特定し、必要なマージ作業量を最小限に抑えるのに役立つ。セキュリティ修正をより簡単かつ迅速に行うこともできる。

これは常に実行されるわけではないが、しばしばテストの推移的依存関係(transitive dependencies)にあるファイルを変更した後で、自動化されたシステムは高い頻度でテストが実行される。これらのシステムは一般的に数分以内に、テストが失敗した変更の作成者やレビュアーに自動的に通知される。ほとんどのチームは、ビルドの現状を派手なディスプレイあるいは色分けされたライト(ビルドに成功して全てのテストを通過するとグリーン、いくつかのテストに失敗するとレッド、壊れたビルドはブラック)を持つスカルプチャーで人目につくようにする。これは、エンジニアにビルドグリーンを維持するよう集中させるのに役立つ。ほとんどの大規模チームは、ヘッドでテストを通過し続けることを確実にすることに対して責任のある「ビルドコップ(ビルドお巡り)」も置き(ビルドコップの役割は通常、チーム間あるいはより経験のあるメンバー間で持ち回りで担当する。)、問題を素早く修正する、あるいは問題となる変更をロールバックするため、問題のある変更の作成者と一緒に取り組んでいる。ビルドグリーンを維持することに集中することは、非常に大きなチームであっても実際に役立つ開発ができる。

コードの所有権。リポジトリの各サブツリーに、サブツリーの所有者のユーザIDを列挙するファイルを置くことができる。サブディレクトリは親ディレクトリから所有者を継承するが、任意で省略可能である。各サブツリーの所有者はサブツリーへの書き込みアクセス権を制御するが、後のコードレビュー節で説明する。各サブツリーは少なくとも2人の所有者が必要であるが、通常は、特に地理的に分散されたチームではそれ以上存在する。所有者ファイルに列挙されるのがチーム全体にとって一般的である。サブツリーの変更はGoogleの誰でも、所有者ではない人も行うことができるが、所有者によって承認されなければならない。これにより、全ての変更は、修正されたソフトウェアを理解しているエンジニアによってレビューされることを保証する。

Googleのソースコード・リポジトリの詳細については、[17, 18, 21]を調べて欲しい。また、他の大企業が同じ課題をどのように処理しているかについては[19]を調べて欲しい。


2/11/2017

Googleでのソフトウェア・エンジニアリング (1)

Googleのソフトウェアエンジニアが書いた「Googleでのソフトウェア・エンジニアリング」と題する論文。非常に興味深い内容。

1. はじめに

Googleは驚異的な成功を収めた企業である。Google検索とAdWordsの成功はもちろん、Googleは、Googleマップ、Googleニュース、Google翻訳、Google音声認識、Chrome、Androidなど、他にも多くの傑出した製品を提供している。GoogleはまたYouTubeなどの小規模な企業買収を行って得た多くの製品を大幅に改良・拡張し、オープンソース・プロジェクトにも幅広い重要な貢献を行っている。そして、Googleは自動運転のようなまだローンチしていない素晴らしい製品群をいくつかデモしている。

Googleが成功した理由は、賢明な統率力、偉大な人々、高い採用ハードル、非常に急速に成長する市場で始めのリードをうまく生かした財務力など、たくさんある。しかし、理由の一つは、Googleが優れたソフトウェア・エンジニアリング慣行(practices)を開発して成功したことである。これらの慣行は地球上で最も才能ある多くのソフトウェア・エンジニアらが長い期間をかけて積み重ねられ、精製された知恵に基づいて進化した。我々の慣行の知識を世界で共有したいし、これまでの失敗から学んだ教訓のいくつかを分かち合いたいと思っている。

この論文の目的は、Googleの主要なソフトウェア・エンジニアリング慣行をカタログ化して簡単に説明することだ。他の組織や個人が、これらを比較して対比し、これらの慣行自身のいくつかを適用するかどうかを検討することができる。

多くの著者(例[9], [10], [11])がGoogleの成功と歴史を分析した本あるいは記事を書いている。しかし、そのほとんどはビジネス、経営、カルチャーを中心に扱ってきた。それら(例 [1, 2, 3, 4, 5, 6, 7, 13, 14, 16, 21])の本の一部だけが、ソフトウェア工学の側面を研究しているが、ほとんどの研究が単一の側面だけだ。そして、この論文が目指している、Googleでのソフトウェア・エンジニアリング慣行の概要を全体として簡単に説明したものはない。

Hacker News


スティーブ・ジョブズがNeXTのIPOを考えていた話

コンピュータ歴史博物館のブログより。AppleがNeXTを買収せず、IPOをしていたらどうなっていたか...

2017年2月7日: 今日はAppleコンピュータによるNeXTソフトウェアの買収が正式に完了して20年を迎えた。スティーブ・ジョブズが最初に作った会社が、彼の2番目の会社を買収していなければ、歴史は非常に異なっていたものとなっていただろう。Appleは今日存在していなかったかも知れない。iPhoneも無かった。しかし、NeXTに何があったのだろうか? 元NeXTソフトウェアのリーダで、Appleのソフトウェア担当上級副社長だったアビー・テバニアンは、この歴史改変(alternate history)を示唆する文書をコンピュータ歴史博物館に寄贈した: 未完で提出も公表されなかった1996年11月のS1 SEC収支報告書の草案で、NeXTが500万の普通株を新規公開する計画していたという内容だった。

役員会のクーデターで会長を追われたスティーブ・ジョブズがAppleを辞任した後、1985年にジョブズとMacintoshとLisaのチームがNeXTを設立した。当初、統合化されたハードウェアとソフトウェア会社だったNeXTのコンピュータは、技術的には優れていたが、市場の失敗は高い価格が関係している可能性が高かった。それにもかかわらず、カーネギーメロンのアビー・テバニアンらによって開発されたUnixベースでMachカーネルのオペレーティングシステムNEXTSTEPは広く称賛された。NEXTSTEPのオブジェクト指向ソフトウェア開発環境はより簡単にアプリケーションを書くことができた。大雑把に言うと、オブジェクト指向ソフトウェアは基本的にモジュール化されている。アプリケーションは、ライブラリから組み立て済みのモジュールあるいはオブジェクトを再利用・拡張することで素早く作ることができる。

1992年の第4四半期まで、NeXTはNEXTSTEPをインテル・プロセッサに移植し、ハードウェアラインを廃止し、会社をソフトウェアのみに方向転換し、NEXTSTEPをAT&Tワイヤレス、メルリ・リンチ、米郵政公社、ファニー・メイ、米海軍などエンタープライズに販売していた。S-1によれば、NeXTは財務上の損失は継続しており、1994年に109万ドルの純利益を達成しただけで、3年連続の損失が4000万ドルから6600万ドルに悪化し(p. 24)、ワークステーション事業の撤退に結びついた。NeXTは、Sun、HP、Microsoftなどエンプタープライズ・プラットフォーム・ベンダーと競合するよりも、それらのプラットフォームにソフトウェアを移植する方が良いと気付いた。NEXTSTEPは、NeXT独自のモトローラベースのコンピュータ、Sun SPARC、HP PA-RISC、インテルベースのマシンと4つのプロセッサ・アーキテクチャで利用可能にだった。さらに、NeXTはMachからオブジェクト指向開発環境を分離し、MicrosoftのWindows NT、SunやHPのUnix OSの上で実行できるOPENSTEP環境と呼ばれるものを移植し、ソースコードをSunにライセンスすることさえして、それを支えた。初期のプロプライエタリで垂直統合された戦略から、幅広いプラットフォームで利用可能で、元の競争相手とのコラボレーションを採用するという180度の転換だった。同社は新しい目的を反映するため1995年にNeXTコンピュータからNeXTソフトウェアに社名を変えた。

しかし、これだけではIPOを保証するためには不十分だった。しかし、1995年にはNetscapeのIPOがドットコムブームに火を点けた。Netscapeをきっかけに、ジョブズはトイ・ストーリー成功後のPixarのIPOを、成功に導いた。NeXTにとって、ワールドワイドウェブへの積極的参加が明らかに見えた。ウェブはティム・バーナーズ=リーによってNeXTコンピュータ上で発明された。

NeXTは既に洗練されたエンタープライズ・ソフトウェア技術「エンタープライズ・オブジェクト・フレームワーク (EOF)」を持ち、開発者はサーバベースのデータベースに接続するデスクトップ・アプリケーションを書くことができた。OPENSTEPとEOFを外して、NeXTは当時支配的だった静的なページよりも動的にウェブコンテンツをオンザフライで出すことができるウェブサイト向けのオブジェクト指向開発環境「WebObjects」を作成した。(p. 39) WebObjectsはユーザインタフェースや基本的なデータソースからアプリケーションのビジネスロジックを分離し、高い柔軟性と変更を可能にした。同じようにメインフレームのようなレガシーなシステムと高い互換性があった。(pp. 40-41) WebObjectsはユーザが動的なウェブサイトを作ることを初めて可能にしたウェブのための初のアプリケーションサーバだった。1996年3月にリリースされたWebObjectsは、オープンインターネット/ウェブと企業のイントラネット両方で成長の機会を狙った。NeXTの顧客を現在それに依存する大規模機関から離れて多角化するのに役立った。1996年末までに、NeXTはプログラマがSunのオブジェクト指向Java言語を使ってWebObjectsアプリケーションを書くことを可能にした。(p. 26) 1年も経たないうちに、WebObjectsは重要な顧客を獲得した。とりわけ、デルは4週間で最新の価格、構成情報、オンラインでの注文機能を提供するオンラインストアを作成するために利用した。(p. 42) Appleは後でiTunes Music Storeを含む独自のオンラインストアでWebObjectsを利用する。NeXTは最終的にNeXTの二つの最新製品、WebObjectsとOPENSTEP for Windowsのソフトウェア収入が、1996年の9ヶ月間でNeXTの総ソフトウェア売上の45%、1,010万ドルに達していた。(p. 25)

アビー・テバニアンによって博物館に寄贈されたこれまで未公開だったS-1 SEC申告書は、NeXTはWebObjectsが特にポストNetscapeの投資環境でIPOを正当化するための十分な成長を生み出すと期待していたことが明確に分かる。NeXTの累積損失が2億7300万ドルだったにも関わらず(p. 23)、ドットコムブームは概して現在の収益性を完全に無視して、もっぱら成長の可能性にフォーカスしていた。NeXTは500万株を1株あたりの見積価格16ドルで提供し、推定7200万ドルを集めようとしていた。

NeXTをドットコムに変えることによって、NeXTの主要株主であるスティーブ・ジョブズは会社の債務を償還し、彼自身やキャノン、1992年の大統領候補ロス・ペロー氏など他の主要株主に返済することができた。1996年のNeXTの事業は既存のOPENSTEP事業とWebObjectsの間でほぼ均等に割れていたが、ジョブズとNeXT幹部は、WebObjects事業が着実に成長しているOPENSTEP事業よりももっと速く成長し、最終的には売上高の大部分を占めると考えていた。

これのどれも起きなかった。ジョブズはS-1の公開を進展させることによってNeXTのIPOを準備していたが、彼の初の会社Appleが沈んでいた。Macintoshのオペレーティングシステムは、特にMicrosoftのWindows 95と比較して見劣っていた。Appleの次世代オペレーティングシステム、Coplandは非常に複雑で扱いにくくなり、AppleのCEOギル・アメリオは中止を余儀なくされた。彼とAppleは会社の外で新しいOSを探すようになり、Windows NTカーネルのライセンスも考慮に入れた。

このOS探しで、AppleとNeXTは1996年11月に議論を始めた。Appleは、元Appleの幹部だったジャン=ルイ・ガセーが設立した別の会社Beとも交渉中で、こちらも独自のハードウェアを作っていたが、ソフトウェアに方向転換していた。BeOSとNeXT OSの競争力の比較コンテストの後、AppleはNeXTを現金4億2900万ドル、Appleの株式150万ドルで買収した。AppleはNEXTSTEP/OPENSTEPオペレーティングシステムとウェブ戦略であるWebObjectsを持つことになった。

NeXTのエンジニアリング副社長アビー・テバニアンは、Appleのソフトウェア担当上級副社長になり、NeXTのハードウェア副社長のジョナサン・ルービンシュタインはAppleのハードウェア担当上級副社長になった。もちろん、Appleは最初は顧問だった共同創設者のスティーブ・ジョブズも戻し、1997年7月までにしっかりと責任を任された。テバニアンのリーダーシップのもと、NEXTSTEPは2001年3月にリリースされたMac OS Xの基礎となった。同様に、OS Xは今年1月の10年前にジョブズによって発表されたiPhoneのオペレーティングシステムの基礎となった。

AppleがNeXTを買収したことで、NeXT IPOは決して起こらず、ドットコムにもならなかった。何が起こっていただろうか? WebObjectsはリリース時点で非常に賞賛され、実際にデルのオリジナルのオンラインストアをサポートしていた。WebObjectsは多くの競合する技術よりもはるかに柔軟性があり、一歩先を行っていた。しかし、Appleの買収によって、WebObjectsは徐々に衰えて、中止された。ポストIPOのNeXTは、WebObjectsで1990年代にウェブアプリケーション市場を支配していただろうか? 2001年のドットコムバブル崩壊を乗り越えていただろうか? 我々には決して分からないだろう。

Hacker News

iPadとMacの最初の7年間を比較する

ジョン・グルーバーのブログより。

なぜ、iPad持ちの人は一見したところ古いiPadを新しいiPadにアップグレードするのが遅いのか塾考しているドラング博士による素晴らしい意見:

私にとって驚くことは、iPadソフトウェアが導入以来7年間でどれほど進歩が遅くなったかということだ。私は常にコンピュータがどんなものであるべきかというスティーブ・ジョブズの構想の頂点としてiPadを、そしてハードウェアが入手できるならMacが1984年にどんなものであったかを考えてきた。しかし、Macが7歳の時に何ができたかを考えて見たい。

あなたはTHINK(別名 Lightspeed) CやPascalのようなサードパーティ製の開発ソフトウェアやAppleのMacintosh Programmer's Workshopのどちらでも正しいMacintoshのプログラムを書く事ができた。あなたはネイティブアプリを書くことを気にしないかもしれないが、それができれば、複数のソースからドキュメントをまとめるなど、関心を持つ他の多くの能力がもたらされる。

MultiFinderにはMac上で実行した全てのアプリケーションが動作する成熟したマルチタスク環境があった。

あなた(そして、全てのアプリケーション)は真の階層ファイルシステムにアクセスできた。

多くの人がHyperCardが最高の個人向けソフトウェア開発キットだとまだ考えている。

ドラングのリストは非常にプログラミング中心の考えで、iPadは1991年のMacの立ち位置と比べると特に弱いところだ。良い点は、本格的な汎用パーソナルコンピューティングプラットフォームは自分のことは自分でできるべきで、つまり、プラットフォーム自身でプラットフォーム向けのソフトウェアを書く事ができるべきである。

Macの極初期の時は、Lisaを使ってMacのアプリを書く必要があった。Macがたった2歳の1986年にはMPW 1.0が出荷された。言い換えれば、1984年から1986年までは、LisaがMacのためにあり、今はMacがiPadのためにある。Macで自足できることは、iPadにとっての今日よりも1980年代のAppleにとって優先順位が高くなっているのは理にかなっている。Lisaは失敗したプラットフォームだった。Macのアプリを開発するために数千ドルもするシット・サンドイッチのLisaを購入する事が開発者に求められていた。そして、Macがセルフホスティングすべきことは明らかだった。概念的には、どのようにシステムが動き、設計されていたかに基づき、MacのソフトウェアをMacの上で書く方法が必要だったということに疑問はなかった。

Apple TVの上でApple TVのアプリを開発し、あるいはさらに馬鹿げた、Apple Watchの上でApple Watchのアプリを開発する方法があるべきという主張をする人は誰もいない。それらは汎用的なパーソナルコンピューティングプラットフォームでは無い。さらには、iPhoneでiPhoneアプリの作成を可能にすることをAppleに求める理由があると誰も思わない。確かに技術的に実現可能であり、概念的には、iOSはUIの観点からそれを処理する事ができる。しかし、現実的な問題として、その努力をかけるにはディスプレイが小さ過ぎる。iPhoneを使ってiPhoneソフトを作成している開発者が所有する唯一のコンピューティングデバイスであれば、私が想像できる唯一の想像可能なシナリオである。1

一方、iPadは明らかにiPadアプリを開発するために完全にふさわしいプラットフォームになる可能性がある。しかし、私はそうすべきかどうか自信がない。あるいは、すでにあるものよりAppleにとって優先度が高くなるべきである(Swift Playgroundsは、Appleがこの方向に動いていることを示している。ゆっくりではあるが)。MacはLisaがなくなってしまったため、自身の開発ツールを必要とした。Macは明るい未来を持つ成長しているプラットフォームのままなので、自身の開発ツールを必要としていない。

しかし、ソフトウェア開発は脇に置いて欲しい。iPadにとっての大きな問題は、iPadがハードウェアに制約されている生産性が低く、時間も短い仕事しかないことだと私は考える。アルダスのPageMakerは1985年にMac向けに出荷された。1987あるいは1988年まで、Macは間違いなくグラフィックデザイナーやビジュアルアーティストにとってこれまでない最高のプラットフォームであると主張するの容易い。オリジナルMac登場の7年後の1991年まで、私は議論の余地はなかったと思う。そして、その間もMacのソフトウェアの改良で、ハードウェアの改善が求められていた。Photoshop、Illustrator、Freehand (今は亡き)、QuarkXpressなどのアプリケーションは当時のMacのハードウェアの限界を押し広げた。

それはiPadにはいえないだけのことだ。iPadはカジュアルな利用向けの素晴らしいプラットフォームである。私は読書をしたり、ビデオを見たりするためにはMacBookよりも良いと思う。カジュアルなゲームをするのにも優れている。私は書き物のためのツールとしてiPadを好む多くの人がいるのも知っている。iPadでアプリを書くのは強力でからではなく、むしろシンプルで、気が散らず、集中しやすいからだ。古いiPadより新しくより強力なiPadにアップグレードする説得力のある理由は何もない。実際、それらがなぜ古いiPadを持つ人(特に2012年のiPad 4から始まる)がアップグレードしないかの理由の良い説明になる。

Apple Pencilはこれを変える。Apple Pencilが使えるiPad Proは、世界で最高のポータブル・ドローイング・プラットフォームである。しかし、あなたが何らかの絵やスケッチをしないなら、魅力があるわけでは無いため、それを試す必要さえない。ほとんどの人々は絵を描かないからだ。2

私は、皆が5、6年使ってからリプレイスを考えるようなプラットフォームであるiPadにとって、それが本質的に悪いことだとは思わない。しかし、もしAppleは皆が頻繁にリプレイスしたくなるようなプラットフォームにしたいのなら、ソフトウェア・ストーリーを変える必要があると思う。それが起こるためには、iPadの体験はビッグiPhoneのようではなく、むしろタッチベースMacのようにする必要がある。

それがiPadにとってのAppleのゴールになるように見えないという事実が、私は他の多くと違い、Macの将来に自信があり続ける理由である。

iPadが登場してまだ1年も経たない2010年12月に、私がMacworldに書いたMac悲観論の記事は、まるで昨日書かれたもののように感じる。ここに私が書いたものがある:

典型的な企業では、レガシーテクノロジーは前進させる方法を考え出す重要なものである。Appleのレガシーテクノロジーは取り除く方法を考え出すものである。問題はiOSがMacよりも明るい未来があるかどうかでは無い。疑問の余地がなく、それはある。問題は、Macがレガシー(遺産)になるかどうかある。MacがiOSを減速させるのだろうか、あるいは何らかの形で妨げになるのかだろうか?

私はいいえと言える。実際に、全く反対だ。一方、Mac OS Xの開発はAppleがiOSにシフトしたエンジニアリング・リソースによって遅れており、その逆ではない。Mac OS X 10.5が2007年に遅れたとき、Appleはそれを認め、はっきりとそう言った。Appleの説明: オリジナルiPhoneの予定通り出荷するため重要なエンジニアリングリソースをシフトしなければならなかった。

しかし、もっと大きな理由は、Macの存在と継続的な成長がiOSをより少なくやり遂げることを可能にすることだ。iPadの中心となる思い付きは、やるべきことを減らすポータブルコンピュータであるということだ。そして、それがやるべきことを少なくし、するべきことを、より良く、より簡単に、よりエレガントになる。Appleが、iOSをMacでできる全てのことをできるようにするため拡張するなら、Macを段階的に廃止することができる。iOSの軽さを維持できるのはMacの重さである。

iOSは悩みがないと言うと、それは障害がないためではない。それは、それを運ぶためにそこにMacがあるからだ。長期的に、仮に10年後、楽しいのことは必ず終わりが来る。しかし、短期的には、Mac OS XはiOS世界の中で不可欠な役割を果たしている: 複雑でリソース集約のタスク向けのプラットフォームとして機能している。

6年後のここでは、iOSの世界でのMacの役割はその時よりも今の方がわずかだが重要性が少なくなっている。


  1. スマートフォンが唯一のコンピュータデバイスとして持つことはアジアや世界中の低所得者の人にとって一般的だと私は認識ている。iPhoneアプリを開発するために、iPhoneを使うことができる人が多少いたとしても、たくさんいるとは思えない。

  2. あなたは1990年代初期のほとんとの人はグラフィックデザインをしないと主張することもできる。私が言っていることは、「はい、まさにそうだ」。だからこそ、Appleは通常は四半期で遥かに少ない100万台を少し下回る数を販売していた。Macの販売数は1995年の1年間で450万台がピークだった。Apple Pencil対応のiPadは、1年で何万という単位ではなく、何百万台と言う単位だと今日も同様にニッチだと思う。

2/10/2017

OSPFv3とOSPFv2を比較する (1)

Cisco Support CommunityにあるOSPFv3とOSPFv2の比較

はじめに

このドキュメントはルーティングプロトコルOSPFv3とOSPFv2を比較した結果を説明する。OSPFv3はIPv4向けのOSPFv2とパケットタイプ、インタフェースタイプ、ネイバー発見パターン、LSAフラッド、エイジングのようにいくつか共通点を持っている。

OSPFv3とv2の違い


サブネット毎ではなく、リンク毎のプロトコル処理

IPv6はリンク層でノート間の通信に使われるメディアを定義するのに、サブネットあるいはネットワークの代わりにリンクという用語を使用する。複数のIPサブネットを一つのリンクに割り当てることができ、2台のノードを共通のIPサブネットを共有していなくても、お互いに通信できる。

OSPFv3のパケット/インタフェースタイプ


OSPFv3パケットタイプ OSPFv3インタフェースタイプ
タイプ1 - Hello P2P
タイプ2 - Database Description P2MP
タイプ3 - Link State Request ブロードキャスト
タイプ4 - Link State Update NBMA
タイプ5 - Link State Acknowledgement 仮想リンク

ヘッダ比較


フィールド OSPFv3 OSPFv2
ヘッダサイズ 16バイト 24バイト
ルータとエリアID 32ビット 32ビット
インスタンスID Yes No
認証 IPsec インタフェース毎、エリア全体

注意: OSPFv3で、リンク毎に複数のOSPFプロセス持つために使われるインスタンスIDは新しいフィールドである。デフォルトでは0で、インスタンスの追加で増やされ、インスタンスIDはローカルリンク的な意味を持つ。OSPFv3ルータはインスタンスIDが一致する場合にのみネイバーとなる。従って、ブロードキャストドメイン上で複数ルータを持つことが可能である。全てOSPFv3が動作していても、全てネイバーになるとは限らない。

OSPFv3 Helloパケットと機能


86931 V3 Hello Packet

注意: インタフェースIDはインタフェースをユニークに識別する32ビット番号で、仮想リンクは自身のインタフェースIDを得る。

  • 比較として、OSPFv3は隣接関係形成の成立にネットマスクを必要としない。隣接関係はサブネット毎ではなく、リンク毎にv6ではリンクローカル上に形成される
  • OSPFv2のオプションフィールドは8ビットだが、OSPFv3は24ビットである
  • Dead intervalsフィールドは32から16ビットに縮小された
  • マルチキャストアドレス
  • マルチキャストアドレス OSPFv3 OSPFv2
    All-SPF Routers FF02::5 224.0.0.5
    All-DR Routers FF02::6 224.0.0.6

LSAタイプ


OSPFv3 LSA OSPFv2 LSA
LSタイプコード 名前 タイプ 名前
0x2001 ルータLSA 1 ルータLSA
0x2002 ネットワークLSA 2 ネットワークLSA
0x2003 エリア内プレフィックスLSA 3 ネットワークサマリLSA
0x2004 エリア内ルータLSA 4 ASBRサマリLSA
0x4005 AS外部LSA 5 AS外部LSA
0x2006 グループメンバーシップLSA 6 グループメンバーシップLSA
0x2007 タイプ7 LSA 7 NSSA外部LSA
0x0008 リンクLSA
0x2009 エリア間プレフィックスLSA

  • LSAタイプあるいは機能コードはOSPFv2と同じLSAタイプと一致する
  • タイプ3は今はエリア内プレフィックスLSAと呼ばれる
  • タイプ4は今はエリア内ルータLSAと呼ばれる
  • 二つの新しいLSAタイプが加わった(リンクLSAとエリア間プレフィックスLSA)

注意: Intra-Area Prefix LSAはOSPFv3の新しいLSAで、複数のIPv6プレフィックスを広報するために使われる。OSPFv2ではintera-areaプレフィックス情報はルータとネットワークLSA(タイプ1と2)で運ばれる。

リンク毎に複数インスタンスをサポート

インスタンスIDはリンク毎に複数のOSPFプロセスインスタンスを持つために使われる新しいフィールドである。2つのインスタンスがお互いに通信するには、同じインスタンスIDを持つ必要がある。デフォルトでは値は0で、インスタンスを追加すると値を増やす。インスタンスIDはローカルリンク的な意味のみを持つ。

認証手法の変更

OSPFv2の認証は共有秘密鍵とMD5 HMACが実装されており、OSPFv2プロトコルの一部としてサポートされる。OSPFv3は認証を自身でサポートするのを全くやめ、IPv6で勧められているより柔軟なIPsecフレームワークに依存している。

追記: 最新のOSPFv3の仕様はRFC5340である。RFC5340の第3節にあるRFC2740との違いを記載する。

3. RFC 2740との違い

RFC 2740に基づくOSPFv3の実装は、この仕様に基づく実装と完全互換である。しかし、いくつかプロトコルの追加と変更がある(全て後方互換を持つ)。

3.1. 同一リンク上の複数インタフェースをサポート

このプロトコルの機能はRFC 2740で部分的に明記されているだけだった。仕様のレベルはこの機能を実装するには不十分だった。4.9節は実装に必要な追加説明を明記している。それらはRFC 2740と完全互換である。

3.2. IPv6向けMOSPFの廃止

このプロトコルの機能はRFC 2740で部分的に明記されているだけだった。仕様のレベルはこの機能を実装するには不十分だった。既知の実装は存在しない。OSPFのマルチキャスト拡張(MOSPF)のサポート、その付随するプロトコルフィールドはOSPFv3から廃止された。4.4.3.2節、4.4.3.4節、4.4.3.6節、4.4.3.7節、付録A.2、付録A.4.2.1、付録A.4.3、付録A.4.1.1.、7.1節を参照して欲しい。

3.3. NSSAの仕様

このプロトコルの機能はRFC 2740で部分的に明記されているだけだった。仕様のレベルはこの機能を実装するには不十分だった。このドキュメントはOSPFv3に特有のNSSA仕様を含んでいる。[NSSA]に関連するこの仕様は、実装に十分な仕様を提供する。4.8.5節、付録A.4.3と[NSSA]を参照して欲しい。

3.4. スタブエリアの不明なLSAフラッド制限の廃止

RFC 2740 [OSPFV3]では、不明なLSAのフラッディングはスタブやNSSAエリアの中では制限されていた。この制限を説明する文は以下の通りである。

しかし、IPv6はIPv4とは異なり、認識されないLSタイプでも、"あたかもタイプを理解しているようにLSAを保存してフラッドする"とラベル付けされる(付録A.4.2.1のUビットを参照)。そのようなLSAの制御されない導入により、スタブエリアのリンク状態データベースがルータの容量よりも大きくなってしまう可能性がある。

これを防止するために、スタブエリアに関連する次のルールが確立された: a) LSAがエリアあるいはリンクローカルフラッディングスコープを持つ、b) LSAはUビットが0にセットされている、ともある場合にのみ、LSタイプが認識されないLSAはスタブエリアの中/通してフラッドされる。詳細は3.5節を参照。

この制限は廃止されている。OSPFv3ルータは、LSタイプが認識されない、Uビットが1に設定されているリンクとエリアスコープLSAをスタブとNSSAエリア全体にフラッドする。OSPFv3ルータがまだその制限をサポートする以外は後方互換はないので、新しく定義されたLSAタイプを広報しないかも知れない。

3.5. リンクLSA抑制

LinkLSASuppressionというインタフェース設定パラメータが追加された。もし、LinkLSASuppressionがインタフェースに設定され、インタフェースタイプがブロードキャストあるいはNBMAでないなら、リンクLSAの開始は抑制されるかも知れない。LinkLSASuppressionインタフェース設定パラメータは付録C.3で説明されている。4.8.2節と4.4.3.8節はパラメータの利用法を反映して更新された。

3.6. LSAオプションとプレフィックスオプションの更新

LSAオプションとプレフィックスオプションフィールドは先のプロトコル追加を反映するために更新されている。具体的には、MOSPFに関連するビットは廃止されている。OSPFv2と同じようにオプションフィールドビットは予約され、DNビットはプレフィクスオプションを追加している。付録A.2と付録A.4.1.1を参照して欲しい。

3.7. IPv6サイトローカルアドレス

IPv6サイトローカルアドレスへの全3章は削除されている。