サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
インタビュー
nhiroki.jp
Chromium では Prefetch や Prerender といった投機的なリソースローディング機能を総称して Preloading と呼んでいました。しかし、Preloading という名称は既に広く使われており、特に具体的な API である <link rel=preload> や Service Worker の Navigation Preload などと被ってしまうため、評判がよくありませんでした。 I've complained before that "preload" is a heavily overused term in frontend/#webperf, with many conflicting meanings and nuances. Now Google will make it even worse by using "preloading" fo
「課題解決を人に任せるが、課題理解を人任せにはしない」というのを今年のスローガンにしていきたい。実行権限は委譲するが、理解することを丸投げしない。 たくさんの課題に取り組んでいると、そのすべてを完璧に処理するのが難しくなり、自分で対処しきれない課題を他の人にお願いすることになる。組織の練度が上がるにつれ、お願いする課題の抽象度も上がり、ついには自分でも詳しく把握できていない課題をそのまま他の人にお願いすることになる。これは組織的としては正しい進化かもしれないが、個人の成長としてはあまり健全ではないと思っている。細部の理解が曖昧になると、適切なディレクションができなくなるし、壁打ち相手としても頼りなくなる。実際昨年はそれが原因でテックリードとして有意義な議論ができないこともあった。 人にタスクを丸投げしたからといって、丸投げしたタスクに対する解像度が低いままで良いわけじゃないんだよな。自分で
『新規事業を成功させる PMF の教科書』を読みました。 リクルーティングメールや採用媒体を眺めていると PMF (Product Market Fit) という言葉をよく見ます。文字通り「プロダクトがマーケットに受け入れられている状態」だろうと理解していましたが、PMF の定義は何なのか、PMF したかどうかはどのように判断するのか、もう少し詳しく知りたくて読みました。 新規プロダクト開発というと「市場調査をしながら人気の出そうなプロダクトを作り、SNS や動画配信サービスで様々なキャンペーンを実施してバズらせる」というとても雑な理解しかありませんでした。しかし、本書を読むと、フィットジャーニーのようなフレームワークがあり、それを順番に進めていくことが PMF を目指す上での定石であること、宣伝やプロダクトのスケールを意識する前にまずは PMF を優先すべきであること、PMF を実現する
一年半ほど TLM (Tech Lead Manager) として、TL (Tech Lead) と EM (Engineering Manager) をやりながら IC (Individual Contributor) としてプログラミングもする、いわゆる「プレイングマネージャー」をしていたんですが、つい先日マネージャーを辞して TL / IC 業に専念することにしました。チームは変わりません。 TL / EM / IC のすべてを一人でこなすのは非常に大変でしたが、初めてのマネージャー業ではエンジニアリングとは違った実に様々なことが学べたし、プロジェクトの計画・実行と人員管理の両方に権限を持っていたため、自分の判断でチームを運営することができて、とてもやりがいがありました。 一方で、マネージャーとしての経験を積み、スタッフメンバーとしてより高い視座や成果が求められるにつれて、再び「ソフ
何か相談事があるときに真っ先に話をしに行く相手のことを go-to person と呼ぶ。要するに「頼りになる人」のことである。本記事ではミドルレベルのソフトウェアエンジニアが go-to person として頼りにされるためにはどう振る舞えばよいか私見を紹介する。職種や立場が違えば目指すべき go-to person のあり方もまた違ったものになることはご留意ください。 Go-to person の役割 Go-to person は相談者が抱える課題を分解・整理するのを手伝い、自身の知識や経験に基づいた適切なアドバイスを提供する。相談者は go-to person と話すことで暗中模索する時間を節約し、最終的な判断に自信を持つことができる。シニアソフトウェアエンジニアやテックリードになる要件として、何らかの分野で go-to person として認知されていることを求めている場合も多いだ
興味があってやってみたいことはさっさと手をつけてみるべきという話。 「今は忙しいしやり始めたとしてもきっと中途半端になるから暇になったらやろう」なんて言っていると、気づいた頃には「やりたいことリスト」は管理できないほど膨れ上がり、どれから手を付けたらいいか分からなくなっていたりする。「やりたいことリスト」は「やれていないことリスト」に姿を変え、まるで怠惰な自分を映す鏡のようになる。そんな自分から目をそらすようにリストをそっと閉じ、気分転換に SNS を開いてみる。どこかの誰かが面白そうなことをやっている様子が次々と流れてくる。「自分も時間があればやれるのに・・・」なんて境遇を呪いながらさらに気分が落ち込んでいく。 時間がなくて全力で取り組めないのは本当のことだししょうがない。でも「中途半端になるかも？」なんて始める前から気にする必要はない。たいていのモノゴトはほんのちょっと体験すれば「ふー
本記事では Speculation Rules API を使ったプリレンダリングの性能評価を行うためのメトリクスについて紹介します。 はじめに ウェブページの読み込みは本質的に時間のかかる処理です。ウェブブラウザは HTML ファイルを解析することでページ表示に必要なリソースを特定・収集・処理し、それらを組み合わせてページの描画（レンダリング）を行います。 ページ読み込みを高速化するアプローチの一つとして投機実行が知られています。投機実行はページ読み込みに必要な処理をあらかじめ実行しておくことで、実際にページを描画するときの処理を減らします。ウェブブラウザにはこのような投機実行を行うための API が多数実装されています。若干情報が古くなっていますが「リソースの読み込みを助けるウェブブラウザ API の世界」という記事に投機実行のための API をまとめたので詳しくはそちらを見てください。
家族が増えたり社会的な役割が大きくなるにつれて、たとえ休日であっても丸々一日暇になることはほとんどなくなっていく。「まとまった時間さえあれば何でもできるのに・・・」と、家事や子どもの世話をしながら考えてしまうこともある。しかし、いざ丸一日自由に使える時間ができて勉強や作業を進められたとしても、期待していたほどの達成感は得られなくて何だかがっくりしてしまうことも多い。自分の無能さに幻滅してしまうが、冷静に考えるとこれは当たり前なんじゃないだろうか。 仮に毎日 1 時間勉強している人がいるとする。この人が一週間に確保する勉強時間は 60 mins × 7 days = 420 mins となる。もしこの人に一日の自由が与えられてそのうちの 7 時間を勉強に充てたとすると、7 hours = 420 mins となり、一週間毎日 1 時間勉強するのと総勉強時間は変わらない1。客観的には一週間分を
『A Philosophy of Software Design』を読みました。 概要 本書はソフトウェアデザインの複雑さ (complexity) をテーマにした本です。ソフトウェアデザインの複雑さとは何が原因でどのように表れるのか？複雑さを抑えるための考え方やテクニックにはどんなものがあるのか？著者がソフトウェア（Tcl スクリプト言語やストレージシステム）の開発やソフトウェアデザインに関する大学講義を通して得た知見が余すことなく紹介されています。 著者曰く、ソフトウェアの複雑さとはシステムの理解や変更を難しくする要素を指し、これは些細な変更が広範な修正を必要とする状態 (change amplification)、利用者や開発者の認知負荷 (cognitive load) の増加、認識するのが難しく最も厄介な「未知の未知 (unknown unknowns)」といった症状によって顕在
fetch() はリクエストが data URL にリダイレクトした場合はネットワークエラーを返す。これが仕様でどのように定まっているのか調べたのでメモとして残す。なお、参照している仕様は 2022 年 11 月 12 日現在のものであり、その後変更されている可能性があるので注意されたし。 Fetch アルゴリズム fetch() の仕様は Fetch Standard で規定されている。fetch() のエントリーポイントは fetch(input, init) (#dom-global-fetch) アルゴリズムである。このアルゴリズムでは request をセットアップし、ステップ 12 で fetch (#concept-fetch) を呼ぶ。 The fetch(input, init) method steps are: 12. Set controller to the re
「「強いエンジニアは結局休日に勉強してるじゃん」って思うけど」という記事を読みました。強いソフトウェアエンジニアになるには、自分が得意な領域だったり楽しめるやり方で日々研鑽するしかないというのはその通りだと思います。また人生を思い切って他のことに費やすのも素晴らしい選択だと思います。私自身「コンピュータにばかり時間を割いていて良いのか」と日々思い悩みながら過ごしています。 （TL に上がってきた定年話を見て）定年とはちょっと違うけど、人生の大半の時間をコンピュータに向かって過ごすことに対する危機感みたいなものはある。人生一度きりだし、もっと違うことに時間を使ってみたい気もする。 — nhiroki (@nhiroki_) February 14, 2022 一方で、そもそも「強いソフトウェアエンジニア」と「自分」を比較することに、もっと一般化すると「自分よりも何かに秀でた人」と「自分」を比
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な
以前、情報系の学科で学ぶ大学生から「大学の授業は大切ですか？」という質問を受けました。もしかしたら同様のことで悩まれている方がいるかもしれないので私なりの回答をここに記しておきます。予め強調しておきたいこととして、これは私見に過ぎず、私が経験したことや見聞きした事柄に強く依存しています。色々な人に同様の質問をしてより客観的な判断をしていただければと思います。 元の質問者の方は少し込み入った状況にあってこの質問をしてくれたんですが、記事にまとめるにあたってそのあたりを端折って一般化しています。 私の回答 学士としての専門性を獲得する上で大学の授業は重要ですし、そこに異論はないでしょう。それを前提として、私はさらに (1) 単位の取得、(2) 共通言語の獲得、という二つの点から大学の授業は大切だと考えています。 (1) について、単位の取得や良い成績を収めることは、海外留学や就職といった成績表
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
Message Passing での話題を契機に、色々な人が自身の Design Docs 観を共有していて、とても興味深く読ませてもらいました。普段「仕事を進める上で当たり前に必要なもの」として書いている自分に気づき、これを機に自分の Design Docs 観も言語化してみようと思ったのが本記事です。実践の一例を付け加えることが狙いであり、「Design Docs はかくあるべき」と主張するものではないです。 はじめに 「人によって思い浮かべる Design Docs 観が全然違う！多様で面白い！！」というのが話の出発点ですが、さすがに想定しているものが違いすぎると話が発散してしまうので、本記事では Design Docs を「ソフトウェアエンジニア (私) が何らかのプロジェクトやタスクを進める上で書く文書」としておきます。 次に私の立場を明確にしておきます。私はオープンソースのウェ
『Web ブラウザセキュリティ ― Web アプリケーションの安全性を支える仕組みを整理する』の読書メモです。 感想 私は Chromium ブラウザの開発に携わっており、本書で紹介されている機能の一部の実装者の立場で読みました。 ブラウザの持つセキュリティ機能が体系立てて紹介されており、機能間の関係性が分かりやすくまとめられている。特に最新のブラウザセキュリティ機能はブラウザの内部構成 (例えばプロセス分離) に強く依存しているので、ブラウザが何をどう守りたいのか抽象的なところから理解していかないと各機能の必要性が分かりにくいが、この本はその抽象的なところからしっかり整理してくれているのが良かった。 プロセス分離に関して恐らく日本語で最も詳しく整理された資料だと思います。過去の研究実装から最新の仕様までしっかり言及されていて、ここまで調べてまとめあげるのは大変だったと思います。これからウ
本記事では HTML タグに指定可能な crossorigin 属性について仕様を参照しながら詳しく解説します。crossorigin 属性は複数の意味を表しており、またそれを指定するタグの他の属性値によって振る舞いが変わってしまうことから、その挙動を正確に理解するのがなかなか難しい属性です。 HTML 仕様は日々進化しています。本記事で説明している内容は記事執筆時点のものであり、閲覧時点では古くなっている可能性があります。正確な情報を知りたい方は必ず最新の仕様を確認するようお願いします。 要点だけを知りたい方は最後の「まとめ」を読んでください。 目次 crossorigin 属性はどこで使われている？ crossorigin 属性は何を意味するのか？ request mode credentials mode crossorigin 属性の意味のまとめ crossorigin 属性の振る
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます！次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね！ ウェブ以前のハイパーテキストの歴史も取り入れるべきでは？ ありがとうございます！おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
要約：Resource Timing の定義する responseStart イベントは informational response (1xx) をレスポンスの開始点として扱うので、1xx を返すアプリケーションで responseStart を記録する場合は注意が必要。 Resource Timing Resource Timing 仕様はリソース読み込みに関する様々なイベントのタイムスタンプを取得するための JavaScript API を定義している。本記事執筆時点では以下のイベントが定義されている。各イベントの詳細は MDN などを見てください。 [Exposed=(Window,Worker)] interface PerformanceResourceTiming : PerformanceEntry { readonly attribute DOMString initia
『伝わる短い英語 ― 新しい世界基準 Plain English』を読んだ読書メモです。Twitter で紹介されているのを見て知りました。仕事で日常的に英文を書くのでそのヒントになればと思い読みました。 感想 既に知っていたり心がけているものが多かったです。仕事などで日常的に英文を書いてる人には目新しさがないかもしれませんが refresher にはなると思います。これから英文を書いていくぞって人は本書を読んでおくとショートカットできて良いと思います。 読書メモ Twitter でのメモ書き 第 1 章：世界で認められるプレイン・イングリッシュ Plain English の生まれた背景、各国での導入、アメリカ歴代大統領スピーチや SDGs における実例、など。Plain English は速く効率的で理解しやすい伝達法で、決して赤ちゃん言葉のようなものではない、とのこと。 第 2 章：
コンピュータサイエンスに関連した論文をもっと読むべく新しい試みを始めてみました。本記事ではなぜ始めたのか、どのようにやるのか言語化してみます。 はじめに 論文を読むのは一般的に労力のかかる作業です。労力のかかる部分は人によって違うと思いますが、私の場合は徹底的に内容を理解しようと論文の枝葉末節まで精読し、それを詳細に記録に残そうとして膨大な時間がかかっていました。これを意識レベルで直すことが難しかったので、論文を全文精読しないようにする仕組みを作ることにしました。 問題意識 好奇心から論文を読むようにしています。例えば、昨年は以下の論文を読んで記事にしました。 Reconsidering Custom Memory Allocation (OOPSLA 2002) (07/22) snmalloc: A Message Passing Allocator (ISMM 2019) (07/0
iframe や worker といった実行コンテキスト (environment settings object) が持つ origin がどのように決められるのか仕様を調べたメモです。長文でかつ難解なので、結論だけ知りたい方はまとめを読んでください。 この記事は 2020 年 2 月 16 日時点の各種仕様を元に記述しており、現時点では参照している仕様が更新されていたり、リンクが切れている可能性があります。ご了承ください。 目次 はじめに iframe の場合 (about:blank) iframe の場合 (navigate) Web Worker (Dedicated Worker / Shared Worker) の場合 Service Worker の場合 Worklet の場合 まとめと雑感 はじめに HTML standard では iframe や worker といっ
Chrome 80 から Web Worker (Dedicated Worker) で ES Modules が使えるようになります。本記事はその宣伝です。 前提知識 ES Modules って何？ ざっくりいうとスクリプトファイルをモジューラブルに読み込む仕組みです。 他の方が解説した記事がいっぱいあるのでそっちを見てください。 Web Worker って何？ ざっくりいうと Web でスレッドを使うための API です。 MDN の解説（これとかこれ）を読むか、詳しく知りたい人は「JavaScript のスレッド並列実行環境」を読んでください。 スクリプトファイルの読み込みについては以前「JavaScript のスクリプトインポートを正しく使い分けようという話」に詳しくまとめたのでそちらも併せて読んでください。 使い方 Dedicated Worker で ES Modules (M
「snmalloc: A Message Passing Allocator」という論文を読んだのでその紹介です。本論文は ISMM (International Symposium on Memory Management) 2019 に採択されており、論文とソースコードは GitHub (microsoft/snmalloc) で公開されています。リポジトリ名から分かる通り、著者の多くが Microsoft Research に所属しています。 免責 読み間違えている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue や Twitter へお願いします。 更新履歴 2019/07/08 bump pointer と free list の next entry pointer を判定する方法について追記 2019/0
Hiroki Nakagawa (nhiroki) Staff Software Engineer @ Google。ウェブブラウザ Chrome (Chromium) 開発者。情報理工学修士。2 児の父親。 Bluesky(nhiroki.bsky.social) Twitter(nhiroki_) GitHub(nhiroki) このブログで述べられている内容はすべて私の個人的な意見に基づくものであり、所属する組織、団体とは一切関係ありません。 振り返り 大学入学から大学院卒業までの話: 「新卒のソフトウェアエンジニアになるまで」 グーグルに新卒入社してから 6 年間の話: 「就職して 6 年過ぎた」 興味のあること 世の中の色々なシステムの仕組みを知ることに興味があります。 コンピュータサイエンス ウェブブラウザ / 仕事で作っているので。 システムソフトウェア（オペレーティングシス
流れに便乗して私がソフトウェアエンジニアになるまでにやってきたことを書いてみます。学生を想定読者にしています。進路を考える時の参考になると嬉しいです。 私は修士一年の 2010 年に Google Japan の Chrome OS チームでインターンし、 2012 年に新卒のソフトウェアエンジニアとして入社しました。現在は東京オフィスの Chrome ブラウザの開発チームにいます。インターン中や入社後の仕事については以前「就職して 6 年過ぎた」という記事に書いたのでそちらも是非見てください。 本記事では学生時代に何を学び、それがどのように現在へと繋がっていったのか紹介します。ソフトウェアエンジニアとしての能力や経験をどのように磨いてきたかが中心です。面接を含む Google 固有の話題は他の記事で十分語られているのであまり書きません。 長文です。結論だけ読みたい人は『最後に』を読んでく
「MESH: Compacting Memory Management for C/C++ Applications」という論文を読んだのでその紹介です。arXiv.org で公開されています。PLDI 2019 で採択されている論文のドラフトだそうです。私は v2 を読みました。ソースコードが GitHub (plasma-umass/Mesh) で公開されています。 免責 読み間違えている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue や Twitter へお願いします。 読んだ動機 C/C++ でリロケーションせずにコンパクションを行う手法に興味があった。 Speedmetor 2.0 benchmark を走らせた Firefox でメモリ消費量が減ったと報告されており、ブラウザ開発者として気になった。 Ch
私は「何かを習慣化してやり続けてそこそこのレベルまで持っていく」のがわりと得意な方だと思っています。本記事はその辺りのことを言語化してみようという試みです。 大体いつも二つのことを意識しています。一つは「毎日前に進む」、もう一つは「当たり前のレベルを上げる」です。 毎日前に進む 身も蓋もない話ですが、やらないと進捗は出ません。一方、少しでもやり続けていればいつか絶対にゴールに到達できるはずです。眠くても疲れていても毎日ちょっとずつ前に進むべきです1。ここで大事なのは「量はどうでもいい」ということです。「毎日やり続ける」ことが重要で「毎日 15 ページ本を読む」のように決まった分量をこなすことをルールにしてはいけません。破綻します。 さて「いつか絶対にゴールに到達できるはず」と言いましたが、ゴールがあやふやだといつまでも到達できません。ゴールは到達判定可能で少しずつ近づけるものにし、進捗もざ
次のページ
このページを最初にブックマークしてみませんか？
『nhiroki’s weblog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く