サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
nhiroki.jp
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます!次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね! ウェブ以前のハイパーテキストの歴史も取り入れるべきでは? ありがとうございます!おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか? 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
これは Chromium Browser アドベントカレンダーの一日目の記事です。初日ということで、本記事では Chromium のソースコードを読む上で役に立つであろう、プロジェクトのディレクトリ構成やファイル構成を紹介します。 (2018/04/09) “The Great Blink mv”1 プロジェクトによってついに WebKit ディレクトリが blink ディレクトリにリネームされました。それに伴い本記事の内容を更新しました。差分は以下の通りです。 third_party/WebKit/Source を third_party/blink/renderer に置換。 blink/ 内のファイル名の命名規約を Bar.{cpp,h} から bar.{cc,h} に置換。 置換に伴う説明文の修正。 (2017/12/01) ディレクトリ構成について追記しました。 Chromium
私は「何かを習慣化してやり続けてそこそこのレベルまで持っていく」のがわりと得意な方だと思っています。本記事はその辺りのことを言語化してみようという試みです。 大体いつも二つのことを意識しています。一つは「毎日前に進む」、もう一つは「当たり前のレベルを上げる」です。 毎日前に進む 身も蓋もない話ですが、やらないと進捗は出ません。一方、少しでもやり続けていればいつか絶対にゴールに到達できるはずです。眠くても疲れていても毎日ちょっとずつ前に進むべきです1。ここで大事なのは「量はどうでもいい」ということです。「毎日やり続ける」ことが重要で「毎日 15 ページ本を読む」のように決まった分量をこなすことをルールにしてはいけません。破綻します。 さて「いつか絶対にゴールに到達できるはず」と言いましたが、ゴールがあやふやだといつまでも到達できません。ゴールは到達判定可能で少しずつ近づけるものにし、進捗もざ
新卒のソフトウェアエンジニアとして Google に入社して丸 6 年が過ぎました。「若者は 3 年で辞める」という話があるけど、その二倍も働いていることになります。当時の気持ちを忘れないうちに今までの振り返りをしてみようと思います。 (2019/04/04 追記) 入社までの話を「新卒のソフトウェアエンジニアになるまで」という記事に書きました。 なお、すべて個人的な体験談であって会社の見解等を表しているわけではありません。 きっかけ Google を意識したきっかけは大学一年生の頃に読んだ梅田望夫さんの『ウェブ進化論』でした。多分同世代の多くの人がこの本に影響を受けたんじゃないかと思います。私も「これからネットの世界はどんどん変わっていくんだ!」と興奮し、その中心的な会社だった Google に憧れを持ったことを覚えています1 。 直接的なきっかけは修士一年生の頃。そろそろ就活に向けて動
Service Worker の実装が主要ブラウザで揃い始めて盛り上がってきましたね。その流れに便乗して久しぶりに Service Worker の仕様や実装に関する記事を書いてみました。今回は Service Worker スクリプトのインストールと更新処理についてです。 この記事は Service Worker スクリプトを少しでも手書きして動かしたことがある人を想定読者にしています。Service Worker について全く知らない人はまず別の入門記事を参照してください。また、細かいことを気にせずに Service Worker を使いたい人は Workbox といったライブラリやフレームワークの利用をおすすめします。 更新履歴 2019/09/24: Chrome 78 から importScripts() も更新対象になりました。それについて加筆しました。 2018/06/07:
これは Chromium Browser アドベントカレンダーの十日目の記事です。本記事では Chromium における JavaScript のスレッド並列実行環境について仕様・実装・API の面から包括的に紹介します。ブラウザの内部実装に興味がある人を対象に、各機能の使い方ではなく実行モデルに焦点を当てて説明しているため、難易度は高いです。使い方を知りたい人は MDN などの記事を読んでください。この記事をきっかけに実装解読に挑戦してみる人が一人でも増えると幸いです。 本記事を書くにあたり、yuki3 さんに多くのコメントをいただき、議論に付き合っていただきました。ありがとうございました。なお、文責はすべて私 (nhiroki) にあります。誤りや補足、質問などは気軽に GitHub Issue もしくは Twitter へお寄せください。 更新履歴 2018/01/15 Layout
Message Passing での話題を契機に、色々な人が自身の Design Docs 観を共有していて、とても興味深く読ませてもらいました。普段「仕事を進める上で当たり前に必要なもの」として書いている自分に気づき、これを機に自分の Design Docs 観も言語化してみようと思ったのが本記事です。実践の一例を付け加えることが狙いであり、「Design Docs はかくあるべき」と主張するものではないです。 はじめに 「人によって思い浮かべる Design Docs 観が全然違う!多様で面白い!!」というのが話の出発点ですが、さすがに想定しているものが違いすぎると話が発散してしまうので、本記事では Design Docs を「ソフトウェアエンジニア (私) が何らかのプロジェクトやタスクを進める上で書く文書」としておきます。 次に私の立場を明確にしておきます。私はオープンソースのウェ
「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
JavaScript の文脈で「スクリプトをインポートする」といった場合、色々な可能性が考えられます。現場での混乱を避けるためにも用語を正しく使い分ける必要があります。そこで本記事では JavaScript のスクリプトインポートについて整理します。 更新履歴 2019/12/05 Dedicated Worker の ES Modules サポートについて追記しました。 2018/09/08 Worklet の type とその上での dynamic import について追記しました。 Service Worker 上での importScripts について追記しました。 Classic Script と Module Script スクリプトインポートを理解するには、スクリプトについて正確に理解する必要があります。HTML の仕様では、スクリプトには Classic Script
「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
ウェブブラウザにおいてメインスレッドはとても重要なリソースです。なるべくメインスレッドを使える状態にしておくことが滑らかな UI/UX を実現する上で重要になります。しかし、実際には多くの処理が実装上の理由やブラウザ仕様の不足によりメインスレッドでしか動かせないため、メインスレッドは忙しくなりがちです。特にページロード時は JavaScript の実行やリソース読み込みなどでとても忙しくなります。 とあるページの perf プロファイル。メインスレッドでせわしなく処理が行われている様子が分かる。 これを解消するために、ブラウザの処理をメインスレッド以外 (off-the-main-thread) でも実行できるようにする試みが行われています。 1. Off-the-main-thread とは メインスレッド以外のスレッドに処理を委譲することを off-the-main-thread と呼
何か相談事があるときに真っ先に話をしに行く相手のことを go-to person と呼ぶ。要するに「頼りになる人」のことである。本記事ではミドルレベルのソフトウェアエンジニアが go-to person として頼りにされるためにはどう振る舞えばよいか私見を紹介する。職種や立場が違えば目指すべき go-to person のあり方もまた違ったものになることはご留意ください。 Go-to person の役割 Go-to person は相談者が抱える課題を分解・整理するのを手伝い、自身の知識や経験に基づいた適切なアドバイスを提供する。相談者は go-to person と話すことで暗中模索する時間を節約し、最終的な判断に自信を持つことができる。シニアソフトウェアエンジニアやテックリードになる要件として、何らかの分野で go-to person として認知されていることを求めている場合も多いだ
流れに便乗して私がソフトウェアエンジニアになるまでにやってきたことを書いてみます。学生を想定読者にしています。進路を考える時の参考になると嬉しいです。 私は修士一年の 2010 年に Google Japan の Chrome OS チームでインターンし、 2012 年に新卒のソフトウェアエンジニアとして入社しました。現在は東京オフィスの Chrome ブラウザの開発チームにいます。インターン中や入社後の仕事については以前「就職して 6 年過ぎた」という記事に書いたのでそちらも是非見てください。 本記事では学生時代に何を学び、それがどのように現在へと繋がっていったのか紹介します。ソフトウェアエンジニアとしての能力や経験をどのように磨いてきたかが中心です。面接を含む Google 固有の話題は他の記事で十分語られているのであまり書きません。 長文です。結論だけ読みたい人は『最後に』を読んでく
興味があってやってみたいことはさっさと手をつけてみるべきという話。 「今は忙しいしやり始めたとしてもきっと中途半端になるから暇になったらやろう」なんて言っていると、気づいた頃には「やりたいことリスト」は管理できないほど膨れ上がり、どれから手を付けたらいいか分からなくなっていたりする。「やりたいことリスト」は「やれていないことリスト」に姿を変え、まるで怠惰な自分を映す鏡のようになる。そんな自分から目をそらすようにリストをそっと閉じ、気分転換に SNS を開いてみる。どこかの誰かが面白そうなことをやっている様子が次々と流れてくる。「自分も時間があればやれるのに・・・」なんて境遇を呪いながらさらに気分が落ち込んでいく。 時間がなくて全力で取り組めないのは本当のことだししょうがない。でも「中途半端になるかも?」なんて始める前から気にする必要はない。たいていのモノゴトはほんのちょっと体験すれば「ふー
本記事では HTML タグに指定可能な crossorigin 属性について仕様を参照しながら詳しく解説します。crossorigin 属性は複数の意味を表しており、またそれを指定するタグの他の属性値によって振る舞いが変わってしまうことから、その挙動を正確に理解するのがなかなか難しい属性です。 HTML 仕様は日々進化しています。本記事で説明している内容は記事執筆時点のものであり、閲覧時点では古くなっている可能性があります。正確な情報を知りたい方は必ず最新の仕様を確認するようお願いします。 要点だけを知りたい方は最後の「まとめ」を読んでください。 目次 crossorigin 属性はどこで使われている? crossorigin 属性は何を意味するのか? request mode credentials mode crossorigin 属性の意味のまとめ crossorigin 属性の振る
以前、情報系の学科で学ぶ大学生から「大学の授業は大切ですか?」という質問を受けました。もしかしたら同様のことで悩まれている方がいるかもしれないので私なりの回答をここに記しておきます。予め強調しておきたいこととして、これは私見に過ぎず、私が経験したことや見聞きした事柄に強く依存しています。色々な人に同様の質問をしてより客観的な判断をしていただければと思います。 元の質問者の方は少し込み入った状況にあってこの質問をしてくれたんですが、記事にまとめるにあたってそのあたりを端折って一般化しています。 私の回答 学士としての専門性を獲得する上で大学の授業は重要ですし、そこに異論はないでしょう。それを前提として、私はさらに (1) 単位の取得、(2) 共通言語の獲得、という二つの点から大学の授業は大切だと考えています。 (1) について、単位の取得や良い成績を収めることは、海外留学や就職といった成績表
Chrome 80 から Web Worker (Dedicated Worker) で ES Modules が使えるようになります。本記事はその宣伝です。 前提知識 ES Modules って何? ざっくりいうとスクリプトファイルをモジューラブルに読み込む仕組みです。 他の方が解説した記事がいっぱいあるのでそっちを見てください。 Web Worker って何? ざっくりいうと Web でスレッドを使うための API です。 MDN の解説(これとかこれ)を読むか、詳しく知りたい人は「JavaScript のスレッド並列実行環境」を読んでください。 スクリプトファイルの読み込みについては以前「JavaScript のスクリプトインポートを正しく使い分けようという話」に詳しくまとめたのでそちらも併せて読んでください。 使い方 Dedicated Worker で ES Modules (M
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
本記事では Speculation Rules API を使ったプリレンダリングの性能評価を行うためのメトリクスについて紹介します。 はじめに ウェブページの読み込みは本質的に時間のかかる処理です。ウェブブラウザは HTML ファイルを解析することでページ表示に必要なリソースを特定・収集・処理し、それらを組み合わせてページの描画(レンダリング)を行います。 ページ読み込みを高速化するアプローチの一つとして投機実行が知られています。投機実行はページ読み込みに必要な処理をあらかじめ実行しておくことで、実際にページを描画するときの処理を減らします。ウェブブラウザにはこのような投機実行を行うための API が多数実装されています。若干情報が古くなっていますが「リソースの読み込みを助けるウェブブラウザ API の世界」という記事に投機実行のための API をまとめたので詳しくはそちらを見てください。
少し前のバージョンですが、Chrome 69 より Web Worker から Web Worker を作れるようになりました。この機能は Nested Workers とも呼ばれています。 Nested Dedicated Workers - Chrome Platform Status Intent to Implement and Ship: Nested dedicated workers - blink-dev 使用方法とユースケース 使い方は Window 上で Worker を作る場合と同じです。次のコードでは、Window から Parent Worker、Parent Worker から Child Worker を作り、postMessage() で Child Worker から Window までメッセージを送信します。 // index.html const wo
一年半ほど TLM (Tech Lead Manager) として、TL (Tech Lead) と EM (Engineering Manager) をやりながら IC (Individual Contributor) としてプログラミングもする、いわゆる「プレイングマネージャー」をしていたんですが、つい先日マネージャーを辞して TL / IC 業に専念することにしました。チームは変わりません。 TL / EM / IC のすべてを一人でこなすのは非常に大変でしたが、初めてのマネージャー業ではエンジニアリングとは違った実に様々なことが学べたし、プロジェクトの計画・実行と人員管理の両方に権限を持っていたため、自分の判断でチームを運営することができて、とてもやりがいがありました。 一方で、マネージャーとしての経験を積み、スタッフメンバーとしてより高い視座や成果が求められるにつれて、再び「ソフ
コンピュータサイエンスに関連した論文をもっと読むべく新しい試みを始めてみました。本記事ではなぜ始めたのか、どのようにやるのか言語化してみます。 はじめに 論文を読むのは一般的に労力のかかる作業です。労力のかかる部分は人によって違うと思いますが、私の場合は徹底的に内容を理解しようと論文の枝葉末節まで精読し、それを詳細に記録に残そうとして膨大な時間がかかっていました。これを意識レベルで直すことが難しかったので、論文を全文精読しないようにする仕組みを作ることにしました。 問題意識 好奇心から論文を読むようにしています。例えば、昨年は以下の論文を読んで記事にしました。 Reconsidering Custom Memory Allocation (OOPSLA 2002) (07/22) snmalloc: A Message Passing Allocator (ISMM 2019) (07/0
2023-10-15 『新規事業を成功させる PMF の教科書』を読んだ 2023-10-08 『プロダクトマネジメント ― ビルドトラップを避け顧客に価値を届ける』を読んだ 2023-09-22 Tech Lead Manager から Tech Lead に戻った話 2023-09-18 『地磁気逆転と「チバニアン」 ― 地球の磁場は、なぜ逆転するのか』を読んだ 2023-09-04 『日経サイエンス 2023 年 10 月号』を読んだ 2023-08-21 『ChatGPT 攻略』を読んだ 2023-08-13 『宇宙検閲官仮説 「裸の特異点」は隠されるか』を読んだ 2023-08-10 『発達障害の人が見ている世界』を読んだ 2023-08-09 『分析者のためのデータ解釈学入門』を読んだ 2023-07-30 『FINAL FANTASY XVI』をクリアした 2023-07-2
「「強いエンジニアは結局休日に勉強してるじゃん」って思うけど」という記事を読みました。強いソフトウェアエンジニアになるには、自分が得意な領域だったり楽しめるやり方で日々研鑽するしかないというのはその通りだと思います。また人生を思い切って他のことに費やすのも素晴らしい選択だと思います。私自身「コンピュータにばかり時間を割いていて良いのか」と日々思い悩みながら過ごしています。 (TL に上がってきた定年話を見て)定年とはちょっと違うけど、人生の大半の時間をコンピュータに向かって過ごすことに対する危機感みたいなものはある。人生一度きりだし、もっと違うことに時間を使ってみたい気もする。 — nhiroki (@nhiroki_) February 14, 2022 一方で、そもそも「強いソフトウェアエンジニア」と「自分」を比較することに、もっと一般化すると「自分よりも何かに秀でた人」と「自分」を比
『プリンシプル オブ プログラミング ― 3 年目までに身につけたい 一生役立つ 101 の原理原則』を読み終わったのでその感想とメモです。 読書メモ on Twitter 読んだ動機 「コードは書けるがクラスや関数の設計スキルがまだまだ未熟な新人ソフトウェアエンジニアが、設計について体系的に学べる本はないか」と聞かれて思い浮かんだうちの一冊が本書でした (この時点では未読)。書評サイト等での評価が高いのと目次をさらっと眺めた感じではきっとお薦めできるだろうと思いましたが、人に薦める以上はまずは自分が読まなくてはと思い、読み始めました。 コード設計に関する本は、他にもデザインパターンやリファクタリングの本なども思い浮かんだのですが、デザインパターンは具体的な課題があって、それを解決するために見るカタログのようなものだと思っていて、適用範囲が限定的だと感じています。そして何よりデザインパター
『Real World HTTP ― 歴史とコードに学ぶインターネットとウェブ技術』を読み終わった。 感想 本のサブタイトルにある通り、HTTP や関連する仕様の策定の歴史と Go 言語によるミニマムな実装例をもとにインターネットとウェブの技術について学べる本。日本語で読める HTTP に関する書籍としては最も網羅的だと思うし、まえがきによると著者の方もそれを意図して書かれたようです。 仕様の変更や新しい仕様が策定された経緯は最新の仕様を読むだけではなかなか知ることができないけど、本書はしっかりとサーベイした上で歴史的経緯が書かれていて、史料的な価値も高いと感じました。 本書とは全く関係ない話ですが、史料的な価値を生み出すことを念頭に記事や本を書くのは歴史的経緯を知っている人の重要な任務じゃないかと思っていて、そういったことをしてくれる人が増えるといいな、と思っています (特に私が興味のあ
次のページ
このページを最初にブックマークしてみませんか?
『nhiroki’s weblog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く