Hayato Ito is a Software Engineer @ Google.
グーグルではたらくソフトウェアエンジニアです。

ご意見や質問は、GitHub Issues にお願いします。答えられる範囲でできるだけ答えますね。

連絡先 (Contact Info)

テックリード (Tech Lead for Web Components)

Google における Tech Lead (テックリード) とはどのようなお仕事ですか？

Google では、チームやプロジェクト内でのリードエンジニアのことを Tech Lead と呼びます。数人から10名ほどのチームに、Tech Lead が１人います。私は Web Components プロジェクトの Tech Lead です。

普段、何をしていますか？

主に Google Chrome で使用されているレンダリングエンジン Blink の開発です。

普段、どれくらいコードを書いていますか？

Blink はオープンソースです。Commits は公開されています:

Hayato's Commits for Google Chrome / Blink。

DOM / Shadow DOM / Events / CSS あたりを触っていることが多いです。

普段、どのようなコードを書いてますか？

たとえば以下のパッチは、Google Chrome の Event Dispatching を400倍速くしたパッチです。

Lazy evaluation of event.path by numbering TreeScopes in DFS order for later O(1) queries

このパッチは、Chrome の Speed Hall of Fame を受賞しました。

3/12/2014 - Improvement of the Week

Last week Hayato Ito reduced checking if a DOM tree is a descendent of another from O(N) in the height of the tree of trees to O(1). In smaller trees this produces 2-3x faster event dispatching, but in the deeply nested trees Hayato created he saw more than a 400x improvement! I'd also like to thank Hayato for the fantastic description of the patch and its effects in the CL description. Great work!

Web Standard / Spec Editor

Spec Editor とはどのようなお仕事ですか？

Web の仕様書を書いて、Web Standard をつくる仕事です。私は Shadow DOM の Spec Editor です。

その他、DOM / HTML などのコアな部分の標準を決める Web Platform Working Group のメンバーです。

Shadow DOM は現在、DOM / HTML Standard にマージ中です。

DOM is getting Shadow DOM. I am happy to have this epic moment in the history of the Web.https://t.co/qsE4fbUPQS
— Hayato (Shadow DOM) (@shadow_hayato) March 15, 2016

Shadow DOM とは？

毎回、説明にとても苦労します。簡単に言うと:

Web は DOM Node という基本的単位から成り立ちます。
複数の Node があつまり Tree を形成して Node Tree になります。みなさんがみている Web ページは（おおまかにいうと）この Node Tree ひとつからできています。
Web の根本的な問題点のひとつとして、「他の Web ページの特定の部分を再利用することは本質的に困難である」というのがあげられます:
- 他の Web ページの Node Tree の Subtree を、自分の Node Tree に「混ぜて」使用した場合、なにが起きるかを事前に予期するのは非常に困難です。
- つまり、これまでの Web は「混ぜるな危険」でした。少し混ぜただけで、ページ全体が容易に壊れてしまいます。
Shadow DOM は Node Tree 自体を Shadow Tree として、他に干渉することなく再利用することを可能にします。Node Tree 自体を、コンポーネントの単位とすることが可能になります。
- これにより、抽象化の概念がなかった、DOM に抽象化の概念をもたらします。C に Class の概念を持ち込んだのが C++ であるのと同様に、DOM に抽象化の概念をもたらすのが Shadow DOM です。
- これまでの Web ページがひとつの Node Tree から成り立っていたのに対して、Shadow DOM の世界では Web ページは Node Tree の Tree から成り立ちます。 Tree だった Web がこれからは Tree of Trees となります。

Web Component とは?

(Shadow DOMからの続き) Shadow DOM と Custom Elemenets と HTML Imports を組み合わせることによって、Web 開発者は、自分のつくった世界そのものを Web Component として簡単に再利用可能な形で公開することができるようになります。

コンポーネントの利用者は、タグを書くだけで、他の人がつくったコンポーネントを再利用できます。ひとつの Web Component は、その内部ではさらに複数の Web Component を使用しているかもしれませんが、利用者はそれは気にしなくてよいです。

...とここまで聞くと、とても複雑なことをしているように思えますが、実は目指している世界は、むしろその逆です。

複雑高度になり一部の技術者だけのものになりつつある現在の Web を、HTML の"タグ" を手書きするだけで良かった誰もが楽しめる Web に戻します:

Web プラットフォームは進化を続けています。もはやタグを手書きして HTML を書くだけでは、とてもユーザーを満足させるサイトは作成できなくなりました。「きちんとした」サイトをつくるには、多くのことを学習する必要があります。

どうして多くのことを覚えなければいけないのでしょうか？それは Web プラットフォームの根幹である DOM に抽象化の仕組みがないのが大きな理由のひとつです。適切な抽象化レイヤーがあれば、本来、知らなくてよいことは「隠す」ことができるはずです。

Web Components の世界では、「タグ」を書くだけで、他の人が書いた Web Components をレゴブロックのように組み合わせて利用できます。コンポーネントの内部がどのようになっているかは知る必要はありません。そう、古き良きタグを手書きするだけでよかったあの時代に戻ります。
ブラウザが本来もつパワーを Web 開発者に開放します:

たとえば HTML に標準で用意されている <video> タグは、誰でもタグを書くだけで、動画を再生することができます。 <video> タグの内部がどのように実装されているかは気にしませんよね？実は <video> タグは Google Chrome では Shadow DOM を内部で使用しています。ある意味、これはひとつの Web Components です。

現在の Web では、<video> タグと同じようなものを、Web開発者は自分ではつくれません。 Web Components の世界では、Web 開発者に Shadow DOM のもつ力を開放します。私は、Web 開発者の情熱・想像力を信じています。

誰もが Web Components を作れるようになり、そしてそれを公開し誰もが再利用できたら、ステキですよね。 Shadow DOM や Web Components はそのような世界を目指しています。

Web Components は 2014 の The Best New Web Technology new Award を受賞しました。

出張は多いですか？

Web Standard に関わると、他のブラウザベンダ(Apple, Mozilla, Microsoft 等)と直接話をする必要があります。旅行が好きなら、Web Standard のお仕事はオススメです。

2015:
1. [Jan] Sydney (Midnight Train)
2. [Apr] San Francisco, Mountain View (Shadow DOM F2F)
3. [May] Sydney (BlinkOn4)
4. [Jul] Mountain View (Custom Elements F2F)
5. [Oct] San Francisco (BlinkOn5)
6. [Nov] Sapporo (W3C TPAC)
2016:
1. [Jan] Mountain View / Cupertino (Custom Elements F2F)
2. (Plan) Jun: Munich (BlinkOn6)
3. (Plan) Nov: Lisbon (W3C TPAC)

漫画「王様達のヴァイキング」漫画の技術監修

「王様達のヴァイキング」って？

「王様達のヴァイキング」は、小学館の週刊スピリッツで連載中の漫画です。ハッカーと投資家が主人公です。単行本は9巻まで発売されています。

Twitter 公式アカウントは、@kingsviking です。

漫画の監修とは具体的にはどのようなことをするのでしょうか？

私は技術監修としてこの漫画に関わっています。主に次のようなことを担当しています。

ストーリー構成を技術面からサポート。技術的に納得できる形まで設定をつめます。
是枝くんをはじめとする登場人物たちのソースコードや、その他のプログラミング環境の素材の提供。
この業界やプログラマの心理などのネタ提供。
毎週のネームやゲラのチェック。技術的に不自然な箇所やセリフについてアドバイス。
単行本のカバー下のアイデア出しと巻末用語解説の執筆。

つまり、一般の読者からは「難しいところはわからないです（けれど面白いです！）」と言われ、詳しい人からは「この設定気にいらない」と石を投げられる側の役割です...。なお、技術的正確さと漫画としての面白さが衝突しそうなときは、漫画としての面白さを常に優先するということでスタッフの意見は一致しています。

漫画にかかわる方（漫画家さん、担当編集さん、ライターさん等）、みなさん本当に漫画を面白くするプロ・よい文章を書くプロで、いつもその仕事のプロフェッショナルっぷりに感心しきっています。

プログラミングの素晴らしさが、漫画のもつ偉大な力を通じて、多くの読者に伝わればよいなと思ってお手伝いしています。

単行本発売にあたって何かコメントを！

Google+ での単行本発売の私からのひとことコメントです。

1巻, 2巻, 3巻, 4巻, 5巻, 6巻, 8巻, 9巻, その他 1

是枝くんのモデルですか？

違います。是枝くんが使用するプログラミング言語・ソースコードは私にとてもよく似てますが、あくまで偶然です。

坂井さんのモデルですか？

違います。パンイチになったりしません。

笑い猫のモデルですか？

違います。裸になったりしません。

ヴァルキリアのモデルですか？

違います。ワイン頭からかけたりしません。

256 の中の人ですか？

わん (・∀・)

漫画では、これまでどのようなプログラミング言語が登場しましたか？

これまで、C, C++, Python 3, アセンブリ (Power PC)、Scala 等が登場しています。すべて登場シーンに合わせて意味のあるコードを書いていますので、興味のあるかたはコードも読んでみてください。

今後、どのようなプログラミング言語が漫画で登場しますか？

チャンスがあれば、OCaml, Haskell, Rust を出したいです。是枝くんは Emacs 使いなので、Emacs Lisp も一度は登場させてあげたいです。

Google ソフトウェアエンジニアの採用

今まで何人、Googleでソフトウェアエンジニアの面接（インタビュー）をしましたか？

100人以上です。すべて 1 : 1 での面接です。

インタビューではどのようなことを聞くのでしょうか？

Q. 「バスにゴルフボールはいくつ入るでしょうか？」

A. 「そんな問題はもはや聞いていないです。いまはゴルフボールにバスが何台はいるかを聞いています。」

...といった、変な情報に振り回されないでください。

Google にソフトウェアエンジニアとして入るにはどのような勉強・経験をしておけばよいでしょうか?

「何をすればよいのか」を挙げるのは難しいです...。 (TODO: いつかちゃんと書く)

その反対、「特にやる必要はないこと」を挙げるなら簡単にできます。たとえば、以下の項目はプログラマとしての能力とはいっさい関係がないことは、みんな理解していますので、安心してください。

Twitter での発言数やフォロワー数
ブログの記事数・ブックマーク数
本や雑誌の記事の執筆
勉強会やハッカソンの出席回数・登壇数
イベントの主催

これらの活動を特にしていなくても、気にしないでください。プログラマ・ソフトウェアエンジニアとして濃密な時間を過ごした人が正しく報われるインタビューをいつも心がけています。

ソフトウェアエンジニアとしてはたらくにあたって Google のよいところって?

ソフトウェアエンジニアリング的に正しいことを正しく行っている

「正しいことをやりたいのに」技術レベルが下の人に合わせざるを得ずに断念せざるを得ない...ということはまずありません。その逆で、「技術が上」の人にみんなが合わせるように努力している。
ソフトウェアエンジニアの採用が一貫して実力主義

採用において、実力のみがものをいう仕組みを制度として持っている・その制度を維持しようとしているところ。これを続けている限り、Google は強いと思います。
みんなコードを書く

コードを書くのがソフトウェアエンジニアのお仕事です。
無駄なプロジェクトはわりとあっさり切り捨てる。その判断が早い。

エンジニアのリソースが限られている以上、意識的に切り捨てていかないと、前には進めません。

Google でのインターンについて

今まで何人、Googleでインターンのホストをしましたか？

6人です。すべて学部生です。

Google でのソフトウェアエンジニア・インターンはどのようなことをするのでしょうか？応募したいのですが、スキル的に不安です...。

TODO: 書きます。

競技プログラミング / レッドコーダー

レッドコーダーになると Google からお誘いがくると聞きました。

Google から誘いがくるというのは、「よかったら面接をうけてみませんか？」くらいの意味しかありません。

誘いが来て面接を受ける場合
自ら応募して面接を受ける場合

1 と 2 で採用プロセスは基本変わらないです。

私は今はインタビューする側ですが、インタビュー中は両者の違いを意識していません。

Google の採用担当の人が何度も熱心に声をかけた結果、ようやく面接にきていただいたとしても、エンジニアがインタビューした結果、思うような評価が得られなかった場合は、普通にお断りされてしまいます。

Goolge に入るにあたって、競技プログラミングの勉強をしておいたほうがよいでしょうか？

これはよく聞かれる質問です。Google のソフトウェアエンジニアになるにあたって、レッドコーダーになることは必須ではありません。競技プログラミングは、システムの制限上、限定的な条件を前提にした知識しか身につかない可能性が高いです。競技プログラミングで必要となる「アルゴリズムとデータ構造」は、ソフトウェアエンジニアにとって必要な経験・知識のほんの一部です。

いろんなことを経験しておいたほうが長い目でみてお得です。おすすめは学生なら Google Summer of Code などに参加することです。

学生じゃないとしても、Summer of Code で記載されているプロジェクトの一覧を見てみましょう。この世の中は解決を待っている素敵な問題たちであふれています。

競技プログラミングのレートが Resume に書いてあったとしても、その事実自体はインタビューの評価には影響しないです。最後に頼れるのは、ソフトウェアエンジニアとしての自分の実力だけです。レートは気にしないでください。

プログラミング

どのようなプログラミング言語を普段使用していますか？その用途は？

C++: Google Chrome が使用しているレンダリングエンジン Blink の開発。
Python: Chrome の開発で使用する Tool や個人の Tool 等を書くとき。100 行以下くらいまでは Python で書くことが多いです。
Scala: 1,000 行以上のある程度大きなものを書くとき。footprint をあまり気にしなくてよいとき。ICFPC (関数型言語の国際学会が毎年開催しているプログラミング大会)に参加するとき。
Haskell: まともな型システムが欲しくなったとき。Scala の型システムに絶望したとき。
Rust: CPU Intensive なコードを書く必要があるけど、安全に書きたいとき。JVM に絶望したとき。
JavaScript: Web。
Shell Script: シェル環境に直接作用するものを書くとき。zsh の Line Editor 用の function など。
Emacs Lisp: 趣味と実益。

プログラミング言語がひとつだけしか選べないとしたら何を選びますか？

Rust。

Rust のよいところを教えてください。

C++ の良いところと危険なところを理解している人には、とてもオススメできるプログラミング言語だと思います。控えめにいっても画期的です。

Ownership, Borrowing, Lifetimes の仕組み。メモリ、ネットワークコネクションなどのリソース管理にまつわるバグをコンパイル時に発見します。JVM のようなランタイムは不要です。
安全性を保ちながらも、Zero-Cost Abstractions について妥協していません。安全性のチェックはコンパイル時に解決済みなので、実行時に余分なオーバーヘッドはありません。C++ と同等に速いです。
モダンなプログラミング言語なら当然あってほしい機能（Pattern Matching, Algebraic data type, Traits 等）をちゃんと備えています。十分に高い抽象化レベルでコードを書けます。
Macro や Compiler Plugins があります。Macro のおかげで、テンプレートメタプログラミングなどの黒魔術に手を染める必要はありません。
C などの他のプログラミング言語との相互呼び出し (FFI) が容易です。
System Programming Language です。必要に応じて unsafe なコードを書けます。OS が書けます。
全体的なデザインセンス。「どうしてこんな仕様にしちゃったの？」と思えるところが少ないです。ほとんどの部分が自分のフィーリングにマッチしています。
Type System。あらゆるところにきちんと Type をつけようという強い意志があります。そのため他のプログラミング言語ならランタイム時に行わざるをえないこともコンパイル時に解決・最適化できます。

十分に賢い Type Inference。

例:

extern crate xxx;
use xxx::parse();

let (i, s, f): (i32, String, f64) = parse("123 hello 2.4");
assert_eq!(i, 123);
assert_eq!(s, "hello");
assert_eq!(f, 2.4);

let (i, s, vi): (i32, String, Vec<i32>) = parse("1 world 2 3 4");
assert_eq!(i, 1;
assert_eq!(s, "world");
assert_eq!(vi, vec![2, 3, 4]);

エディタは何を使用してますか？

Emacs

Emacs で使用しているパッケージは？

TODO: 書きます

Emacs の設定ファイルが1万行くらいあると聞いたのですがほんとうですか？

一時期そういう噂が流れましたが、いまはぐっと減っていると思います。安心してください。

Emacs の設定ファイルを公開する予定はありますか？

ありません。

Python の開発環境は?

Emacs (python-mode, jedi-mode, company-mode)
mypy, ipython, pyenv, flake8

HTML / CSS / JavaScript の開発環境は?

Emacs (web-mode, nxml-mode, js2-mode, tern-mode)

C++ の開発環境は?

Emacs (cc-mode, rtags)
Eclipse CDT
Build: waf / make / gn + ninja

Rust の開発環境は?

Emacs (rust-mode, racer, flycheck-rust)
multirust

Scala の開発環境は?

sbt
Scala IDE (+ Emacs+ Eclipse plugin)

ICFP Programming Contest には何を使用して参加してますか？

毎年、Scala で参加しています。

2009, 2010, 2011, 2012 (感想), 2013, 2014, and 2015 (感想)

2016 は Rust で参加する予定です。

メモはどのようにとってますか？

Emacs (org-mode, org-babel)

オススメの本や勉強方法

オススメの本は？

比較的普遍的な知識が身につくものだけとりあげます。

SICP: Structure and Interpretation of Computer Programs: ★★★★★★★

名著です。カバーする範囲はとても多岐に渡ります。内容の薄いいろんなものに手を出すなら、これを一冊きちんとやるのが、後々きいてくると思います。オススメです。大好きな本です。
Introduction to the Theory of Computation: ★★★★★

実用性はあまりないのかもしれませんが、とても面白いです。「計算するとはいったいどういうことか？」ということを、「証明の力」で鮮やかに切っていきます。計算理論に興味があるかたにはオススメ。そうでなくても、常識としてもオススメです。
Concreate Mathematics: ★★★★

Knuth 先生の隠れた名著。Knuth 先生のファンで、離散数学好きなら読みましょう。
The C++ Programming Language, 4th Edition: ★★★★

C++ 11 に関しての知識が足りないな―と思って、読んだ本です。なんといっても、著者は、C++ の作者である Stroustrup さんです。古い仕様にとらわれず、最初から C++ 11 の機能をきっちり使っていきます。最初のほうは、チュートリアル形式で解説していくので、C++ の初学書にも実はよいのかもしれません。そのあまりのボリュームのため、オススメしずらいのですが、C++ にちゃんと向かい合いたいならやはりこれくらいは一度は読む必要があるので、他に代替案がないのならこれがオススメです。
The Design and Evolution of C++: ★★★★

これも Stroustrup さんの本です。技術書というより歴史的な読み物です。C++ 使いなら、涙なしでは読むことのできないノン・フィクションです。とても共感できます。
API Design for C++: ★★

楽しみにしていたものの、わりと当たり前のことしか書いてなかった気がします。そのため、ほとんど内容を覚えていないです...。ごめんなさい。
Code Complete (Developer Best Practices): ★★★

これも当たり前のことしか書いてなかった気がします。そのため、あまり印象にのこっていないです...。当たり前のことを当たり前に身につけるにはとてもいいショートカットになるのかも。
Programming in Scala: A Comprehensive Step-by-Step Guide: ★★★★

Scala をはじめたときに一通りの知識を身につけるため読みました。他によい本がまったく思い浮かばないので、Scala ならとりあえずこれは一通り読みましょう。
Hacking: The Art of the Exploitation ★★★★

ハッキングは芸術です。「こんな本、他に誰が読むんだろう」と思っていたら、以外に Amazon.com などでの順位が高くて、びっくりした覚えがあります...。前半部分がとてもよいです。特に3章。1章、2章でつくったプログラムには実は脆弱性があって、3章ではそこをついて、特権を奪っていく過程がとてもエキサイティングです。
Types and Programming Languages: ★★★★★

型理論というのは、コンピュータ・サイエンスの中でも理論が実際にとても役立っている貴重な分野のひとつだと思います。 TAPL では、OCaml が使用されていますが、自分の好きな言語ですべての演習をやってみるというのも、ありだと思います。
Functional Programming in Scala: ★★★★

「関数型プログラミングとは！」とは頭の中で理解するものではなく体得するものです。この本はまさにそれに応えてくれます。前半、いろいろなものを自作させられます。そして、後半で、「ほーら、いままで作ってきたものは、全部、同じような類似点があったでしょ。それが、モ・ナ・ド♡」と優しく教えてくれます。モナドを理論ではなく、実感として理解するにはオススメです。

Coursera や Udacity でのおすすめのオンラインのコースは？

Intro to Artificial Intelligence: ★

いまとなってはあんまりオススメしないです。感想
Compilers: ★★★★

COOL という Mini Object Oriented Language のコンパイラをつくるコースです。一度もコンパイラをつくったことがないのなら、とても楽しいと思います。
Discreate Optimization: ★★★

離散最適化に関する数々の理論とテクニックを学べます。なんといっても、講師の先生がノリノリです。
TODO: 他のコースを追加。

Python のオススメの勉強方法は?

The Python Tutorial : ★★★★★

Python は公式のチュートリアルがとてもよいので、これだけ読めば最初は十分です。

Haskell のオススメの勉強方法は?

Learn You a Haskell for Great Good!: ★★★★★

圧倒的にこれがオススメです。

Scala のオススメの勉強方法は?

TODO: 書きます。

Rust のオススメの勉強方法は?

TODO: 落ち着いたら書きます。