サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
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 一方で、そもそも「強いソフトウェアエンジニア」と「自分」を比較することに、もっと一般化すると「自分よりも何かに秀でた人」と「自分」を比
Prerender API (Speculation Rules API) については Origin Trial を始めました。2021 年も引き続きトライアルを続けつつ、prerendering の可能性を広げていきたいと思っています。興味がある方はご連絡ください。 今まで Filesystem API とか Worker API とか、非ソフトウェアエンジニアな家族に見せても「ふーん」って言われがちな機能ばかり作ってたけど、Prerendering は目に見えて違いが分かる(ページ遷移が瞬時に起こる)ので家族に見せたら「すごいね」と言われてちょっと嬉しい😊 — nhiroki (@nhiroki_) November 11, 2021 そのほかにも自分が code ownership を持っている Worker / Worklet APIs や Loading 周りのメンテナンスや技
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか? 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
プログラミングおよびプログラミング言語ワークショップ(PPL)が開催したサマースクール「JavaScript 処理系と Chrome ブラウザの実装技術」にて、JavaScript 処理系 V8 とレンダリングエンジン Blink のアーキテクチャについて話をしてきました。 本発表では、主にブラウザ JavaScript に関する歴史や最新動向に関する概説と、ウェブ特有の実行モデルをどのようにブラウザアーキテクチャへ落とし込んでいるか紹介しました(スライドへのリンク) Chrome ブラウザでは JavaScript 処理系として V8 を、そしてそれを駆動するレンダリングエンジンとして Blink を組み込んでいます。本発表では Chrome がウェブ特有の実行モデルやセキュリティモデルを守りながらどのように V8 と Blink を協調させているのか、そのアーキテクチャを紹介します。
ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な
以前、情報系の学科で学ぶ大学生から「大学の授業は大切ですか?」という質問を受けました。もしかしたら同様のことで悩まれている方がいるかもしれないので私なりの回答をここに記しておきます。予め強調しておきたいこととして、これは私見に過ぎず、私が経験したことや見聞きした事柄に強く依存しています。色々な人に同様の質問をしてより客観的な判断をしていただければと思います。 元の質問者の方は少し込み入った状況にあってこの質問をしてくれたんですが、記事にまとめるにあたってそのあたりを端折って一般化しています。 私の回答 学士としての専門性を獲得する上で大学の授業は重要ですし、そこに異論はないでしょう。それを前提として、私はさらに (1) 単位の取得、(2) 共通言語の獲得、という二つの点から大学の授業は大切だと考えています。 (1) について、単位の取得や良い成績を収めることは、海外留学や就職といった成績表
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
Message Passing での話題を契機に、色々な人が自身の Design Docs 観を共有していて、とても興味深く読ませてもらいました。普段「仕事を進める上で当たり前に必要なもの」として書いている自分に気づき、これを機に自分の Design Docs 観も言語化してみようと思ったのが本記事です。実践の一例を付け加えることが狙いであり、「Design Docs はかくあるべき」と主張するものではないです。 はじめに 「人によって思い浮かべる Design Docs 観が全然違う!多様で面白い!!」というのが話の出発点ですが、さすがに想定しているものが違いすぎると話が発散してしまうので、本記事では Design Docs を「ソフトウェアエンジニア (私) が何らかのプロジェクトやタスクを進める上で書く文書」としておきます。 次に私の立場を明確にしておきます。私はオープンソースのウェ
『Web ブラウザセキュリティ ― Web アプリケーションの安全性を支える仕組みを整理する』の読書メモです。 感想 私は Chromium ブラウザの開発に携わっており、本書で紹介されている機能の一部の実装者の立場で読みました。 ブラウザの持つセキュリティ機能が体系立てて紹介されており、機能間の関係性が分かりやすくまとめられている。特に最新のブラウザセキュリティ機能はブラウザの内部構成 (例えばプロセス分離) に強く依存しているので、ブラウザが何をどう守りたいのか抽象的なところから理解していかないと各機能の必要性が分かりにくいが、この本はその抽象的なところからしっかり整理してくれているのが良かった。 プロセス分離に関して恐らく日本語で最も詳しく整理された資料だと思います。過去の研究実装から最新の仕様までしっかり言及されていて、ここまで調べてまとめあげるのは大変だったと思います。これからウ
Message Passing の「ブックマークのはなし」のスレッドを読んで感化され、自分のログ取りのやり方について書いてみた。件のスレッドでは読書記録が話題の中心ですが、ここでは読書に限らず日々の色々なアクティビティログについて紹介する。 ちなみに使っているサービスは以下の通り。依存は少ないほうが良いと思ってるので、なるべく少なくしている。 Twitter:パブリックなログの記録 Slack:プライベートなログの記録と全ログの直列化 esa:ログの保管庫 ブログ:整理した情報を公開する場所 Google Docs:整理した情報を記録する場所 ロギング 情報はどこからでも自由にアクセスできる方が便利だと思っているので、公開しても害がなさそうなことはなるべくパブリックな場に記録するようにしている。アクティビティログのような時系列情報の記録先には主に Twitter を使っている。 アクティビ
本記事では HTML タグに指定可能な crossorigin 属性について仕様を参照しながら詳しく解説します。crossorigin 属性は複数の意味を表しており、またそれを指定するタグの他の属性値によって振る舞いが変わってしまうことから、その挙動を正確に理解するのがなかなか難しい属性です。 HTML 仕様は日々進化しています。本記事で説明している内容は記事執筆時点のものであり、閲覧時点では古くなっている可能性があります。正確な情報を知りたい方は必ず最新の仕様を確認するようお願いします。 要点だけを知りたい方は最後の「まとめ」を読んでください。 目次 crossorigin 属性はどこで使われている? crossorigin 属性は何を意味するのか? request mode credentials mode crossorigin 属性の意味のまとめ crossorigin 属性の振る
Chromium のコードが Space X の宇宙船で使われたり、GitHub の Arctic Code Vault プロジェクトによって北極圏に埋められたりしました。次はどんなところで使われるのか、考えるだけで楽しいです😁 書いたコードが北極に行ったし宇宙にも行ったので、次は別の惑星にでも行ってほしいな。今度火星に行く探査機辺りに Chromium 載ってたりしませんか?? pic.twitter.com/llPwa34EeO — nhiroki (@nhiroki_) July 17, 2020 技術記事の執筆 ウェブの何となく理解している挙動について仕様を読み解いてそれを裏付けていく作業が好きでよくやっているんですが、こういう仕様の細かい知見はすぐに忘れるわりに後々必要になることが多いので、いくつかブログ記事にまとめたり、Twitter に #nhspec というタグを付けてつ
学部 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
Chromium の net スタックにある HttpStreamParser というクラスの挙動についてのメモです。Chromium のネットワーキング周りの開発に関わっていない人には全く役に立たない知識です・・・ Chromium の実装に関するメモをなるべく外出ししていきたいと思っていて、本記事はその一環です。自分用メモなので細かいことは説明しません。ブログ記事が最近読書メモばかりなので、こういうニッチなメモを小出ししていくことでソフトウェア関係の記事の比重を高めていきたい・・・ はじめに 最近 Chromium の net スタック周りのコード、特に HTTP の header parsing 周りのコードを眺めている。それで今回は HTTP/1.1 で使われている HttpStreamParser というクラスの挙動を調べた。net スタックのコードは Chromium リポジト
『法助動詞の底力』の読書メモです。法助動詞 (特に could や would) を使って自分が伝えたかったニュアンスがちゃんと相手に伝わっているのか、相手が法助動詞を使って意図していることをちゃんと読み取れているのかずっと気になってたんですが、まさにそれについての本がたまたまレコメンドされてきたので読みました。 読んでみて、どうやら自分が could や would から得ていた感覚は正しかったことが分かって自信がつきました。一方で「未来の確定した予定を表す現在進行形」や「will による現在の推量」といった今まで意識していなかった感覚や、細かな用法などを学ぶことができて、法助動詞に対する認識が一段階レベルアップした気がします。 読書メモ Twitter でのメモ書き 法助動詞とは? 法助動詞は、助動詞全体から be, have, do を除外したものの集合で(〜中略〜)「可能性や意思や
『伝わる短い英語 ― 新しい世界基準 Plain English』を読んだ読書メモです。Twitter で紹介されているのを見て知りました。仕事で日常的に英文を書くのでそのヒントになればと思い読みました。 感想 既に知っていたり心がけているものが多かったです。仕事などで日常的に英文を書いてる人には目新しさがないかもしれませんが refresher にはなると思います。これから英文を書いていくぞって人は本書を読んでおくとショートカットできて良いと思います。 読書メモ Twitter でのメモ書き 第 1 章:世界で認められるプレイン・イングリッシュ Plain English の生まれた背景、各国での導入、アメリカ歴代大統領スピーチや SDGs における実例、など。Plain English は速く効率的で理解しやすい伝達法で、決して赤ちゃん言葉のようなものではない、とのこと。 第 2 章:
次のページ
このページを最初にブックマークしてみませんか?
『nhiroki’s weblog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く