はてなブックマーク

去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。

2019 年の夏に前職を辞め、そのまま無職として過ごし今年の 10 月にようやく再就職して働き始めた。 何か事情があって働けなかったわけではなく、プログラミングの能力を伸ばすために敢えて就職しなかった。 自分にとってそれなりに重要な期間だったと思うので、記録を残しておく。 予め断っておくが、何か「すごいこと」を成し遂げたわけではない。「すごくないプログラマ」が少しでもすごくなりたくて勉強していた話に過ぎない。 「すごいプログラマ」が「すごいこと」をした話を読みたければ、以下の記事などがよいと思う。 会社をやめて約1年プログラミングの勉強に費やしたことに対する満足と後悔 | blog.ojisan.io 2年間の独学をふりかえって – Happy Coder 予防線を張ったところで、本題に入る。 背景や動機 プログラミングの勉強をするために前職を辞めたわけではなく、退職の理由は別にある。 そ

SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか

React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい

なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、

Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。 Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。 ひとつひとつの章がかなり短い（長いものでも 20 ページくらい、短いものだと 4 ページほど）ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。 技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。 無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。 本書に収録されているのは 2000 年から 2004 年に書かれた記事なので

この記事では、 JavaScript で文字コードを扱う際に知っておくべき概念である Code Point や Code Unit、サロゲートペア、といったものについて説明していく。 また、具体的にそれらの概念を使ってどのようにコードを書いていくのかについても扱う。 この記事に出てくるコードの動作確認は以下の環境で行った。 Deno 1.26.0 TypeScript 4.8.3 Code Point （符号位置） プログラムで文字を表現する方法は複数あるが、 JavaScript では Unicode という方法を採用している。 Unicode ではあらゆる文字に対して一意の値を割り振ることを目的としており、この値のことを Code Point （符号位置）という。 Code Point は 16 進数の非負整数で、文章中で表記するときは接頭辞としてU+をつける。 例えばAという文字の

Cookie とは、HTTP でステートフルなやり取りを実現するために、ブラウザとサーバ間で情報を送受信する仕組みである。 HTTP は本来ステートレスなプロトコルである。そのため、同一のユーザーが連続でリクエストを行っても、それぞれ独立したリクエストであり、「同じユーザーからのリクエストである」とサーバが認識することはできない。 これは例えば、ログイン状態の管理で問題となる。ID とパスワードで認証を行っている場合、リクエストの度に ID とパスワードを送信しなければならない。 Cookie を使うことで、このような事態を解決できる。 まず、サーバがブラウザに対して、Cookie としてどのような情報を保存するのか指示する。具体的には、レスポンスヘッダにSet-Cookieフィールドを含め、そこに Cookie として保存させたい情報を設定する。ログイン状態を管理したい場合は、セッション

Deno で React のサーバサイドレンダリング（以下、SSR）を実現する方法をハンズオン形式で書いていく。 自分が調べた範囲では、単に JSX で HTML を構築して終わり、という記事が多かった。それではあまり実用的ではないので、この記事ではハイドレーションまで行う。 また、React で SSR する方法を調べたところ、ほとんどの記事が Next.js を前提としていた。確かに Next.js を使わずに SSR するケースはあまりないだろうし、記事としても需要がないのだと思う。 しかし、Next.js のようなフレームワークが裏側で何をやってくれているのかを知ることで、SSR に対する理解を深めることができる。 事実、私は SSR をほとんど使ったことがなかったが、この記事を書くことでかなり考えを整理することができた。 Deno のバージョンは1.11.2で動作確認している。

2020/05/31 追記 勉強や経験を重ねた結果、この記事を執筆した時より知識が増え、コードの書き方にも変化があります。 サンプルアプリも同様で、以下のプロダクトのコードのほうが、今の自分の考えが反映されていると思います。 github.com 追記終わり 2019/07/14 追記 ディスカウント後の価格みたいな導出項目はselector (reselect)を使うとよいのでは https://redux.js.org/recipes/computing-derived-data - YonmanHasse のブックマーク / はてなブックマーク というコメントを頂き、確かに便利そうだったので導入した。 それに合わせてこの記事の内容もアップデートした。 追記終わり タイトルに書いた組み合わせで SPA を作るときにどのような設計にするのか、現時点での考えを記録しておく。 チュートリアル

個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし

2021/4/23 追記 Twitter にて指摘を頂いたので追記。 詳細は当該ツイートを読んで頂きたいが、プリフライトリクエストを CSRF 対策として用いるのは適切ではないという内容。 この記事に書いた仕組みや挙動そのものが間違っているわけではないのだが、プリフライトリクエストはそもそもセキュリティのための機能ではない。 そして、詳しくは記事の続きを読んでほしいが、プリフライトリクエストが発生するということは、HTTP メッセージのやり取りが 1 回増えるということなので、パフォーマンス上、望ましくない。 代替案がないならともかく、リクエストのオリジンをチェックすれば対応できるのだから、敢えてプリフライトリクエストを利用する必要はない。素朴に書けば以下のようになるだろうか。 const ALLOW_ORIGIN = `http://localhost:${constants.SPA_P

インフラについて調べていたので、その備忘録。 調べていく上で重視したのは、概念や概要を知ること。細かい知識はあとでいくらでも調べることが出来るが、土台となるものがなければ調べることすら出来ない。 「公式ガイドやハウツー記事に従って設定したけど、俺は今、一体何をしているんだ？」という状態から抜け出したかった。 具体的なコマンドよりも、そもそも何をしているのか、そしてそれは何のために行っているのかを、把握できるようになりたかった。 そもそもサーバーってなんだ 一口にサーバーといっても、多義的。 まずこれを区別していないのが、混乱の元だった。 初学者は「サーバー」と言っている時に具体的に何を指しているのか、意識したほうがいい。 まず最初に存在するのが、ハードウェアとしてのサーバー。 これはただのコンピュータであり、中身が入っていなければただの箱である。 VPSやクラウドなどで、本当に物理的にコン

「発生し得ない値」などのように説明されるnever型。 概念としては分かるのだが、実際にどのようなケースで使えばよいのかイメージできずにいた。 neverを使ったテクニックを調べていて多少のイメージは掴めてきたので、整理しておく。 動作確認は TypeScript のv3.7.5で行っている。 never 型の特性 まずはnever型がどういった型なのか、理解する。 決して発生し得ない値や型は、never型になる。 例えば以下のif文では、elseブロックは絶対に実行されないため、そのなかではfooはneverになる。 const foo = true; if (foo) { foo; // const foo: true } else { foo; // const foo: never } 「存在し得ない値」なので、どんな値も代入することはできない。 const foo: never

ES2017で仕様に入ったAsyncFunctionとawait単項演算子。 これらを使うと非同期処理を同期的に書くことができ、非同期処理のループもシンプルに書けるようになる。 この記事の内容は全てNode.jsのv8.6.0で動作確認している。 非同期処理の基礎はこちら。 AsyncFunction 関数定義の前にasyncとつけると、その関数はAsyncFunctionになる。 async function myFunc(){ return 'foo'; } console.log(myFunc); // [AsyncFunction: myFunc] console.log(myFunc()); // Promise { 'foo' } myFunc().then(res => console.log(res)); // foo 非同期処理をシンプルに書けていることが分かる。 Asy

この記事では、GraphQL を利用したアプリを Next.js で構築していきながら、GraphQL の初歩について書いていく。 GraphQL のクライアントもサーバも、Apollo を用いる。 また、できるだけ型安全に開発したいので、graphql-codegenで型定義ファイルを生成する方法も扱う。 利用しているライブラリのバージョンは以下の通り。 @apollo/client@3.5.10 @graphql-codegen/cli@2.6.2 @graphql-codegen/typed-document-node@2.2.7 @graphql-codegen/typescript-operations@2.3.4 @graphql-codegen/typescript-resolvers@2.5.4 @graphql-codegen/typescript@2.4.7 @type

UNIX やそのツールはどのような考えに基づいて作られているのか解説した本。 UNIX が開発されていくなかで培われていった文化や考え方について書かれている。 www.ohmsha.co.jp UNIX が具体的にどのように動いているのかではなく、 UNIX はなぜそのように動いているのか、ということが主題。 そのため、 UNIX に限らずソフトウェア開発全般に適用できるような内容になっている。ソフトウェアだけでなく「ものを作る」こと全般に応用できる内容も多いかもしれない。 私も、現時点では UNIX そのものに対する熱意や探究心はあまりないので、 UNIX について知るためではなく開発の参考になる考え方がないかと思って読んだ。 9 つの定理が紹介されているのだが、まず思ったのは、「言うは易く行うは難し」という感じの定理ばかりだなということ。 例えばシンプルに保て、小ささを維持しろ、という

この記事では、npm installやnpm ciを実行したときにどのようにパッケージがインストールされるのか、依存パッケージにバージョンのコンフリクトが発生した際にどのように処理されるのか、などを見ていく。必要に応じて Yarn での挙動にも触れる。 動作確認に使った npm のバージョンは6.14.5。Yarn は1.22.4。 特に npm はバージョンによって動作が大きく異なるので、注意する。 package-lock.json によるバージョンの固定 package.jsonだけではインストールするパッケージのバージョンを固定できず、package-lock.json（Yarn の場合はyarn.lock）によってバージョンを固定する。 多くの人が知っている話ではあるが、重要な機能なので改めて触れておく。 package.jsonのdependenciesやdevDependen

Node.js には Stream というインターフェイスが用意されており、これを使うことでデータをストリーミングできる。 Stream を使うことで、データの全てをメモリに保持するのではなく、少しずつ順番にデータを処理していくことが可能になる。 この記事では、Stream の基本的な使い方について説明していく。 WHATWG で定義している Stream はまた別の概念なので、注意する。この記事で扱っている Stream は、それとは別に以前から Node.js に実装されている Stream である。 以下の環境で動作確認している。 Node.js のバージョン 16.15.1 使っている npm ライブラリ @types/node@16.11.43 ts-node-dev@2.0.0 typescript@4.7.4 環境構築 まず最初に、手元で実際にコードを動かすための環境を構築す

プログラミングの型システムに関する記事を読んでいると、共変や反変といった用語が出てくることがある。 TypeScript や Flow についての記事でも、見かけることがある。 それらは TypeScript を使う上で必須の知識ではないが、把握しておくに越したことはない。 この記事では、TypeScript を題材にして、変性について説明していく。 TypeScript に関する議論を理解できるようになることがこの記事の目的であり、より詳細な、学術的、数学的な内容には踏み込まない。 この記事の内容は、TypeScript のv3.9.5で動作確認している。 変性 変性（variance）とは、任意の型Tに対してどのような性質を持つのか示したものであり、以下の 4 種類がある。 不変性（invariance） Tそのものが必要 共変性（covariance） Tそのものか、そのサブタイプが

JavaScript や TypeScript を使ってウェブアプリを提供する場合、開発時はimportやexportなどの ES Modules を使い、公開時はファイルをバンドルして公開することが多い。 以下の記事に書いたように、現在の主要なブラウザは ES Modules に対応してものの、バンドルせずに公開してしまうとパフォーマンスに悪影響を与える可能性がある。 numb86-tech.hatenablog.com ファイル数が増えれば増えるほど影響は深刻になるため、依存関係が深いライブラリを使っている場合などは、レイテンシが飛躍的に増加してしまう。 そのため、バンドルせずに公開するのは現実的ではない。 バンドルしてひとつのファイルにまとめてしまえば、JavaScript のダウンロードは一度で済む。 しかしそうすると今度は、バンドルファイルの肥大化という問題が発生する。 巨大なフ

TypeScript で書いたプログラムを npm パッケージとして配布する手順を書いていく。 まだ npm パッケージの配布をしたことがない人を、想定読者としている。 よりよい書き方、詳細な設定、は措いておき、まずは最低限の要件を満たすものを作り上げる。 今回の「最低限の要件」は以下。 npm installやyarn addでインストールできる importでもrequireでもインポートすることが出来る 型定義ファイルを同梱し、TypeScript アプリにもスムーズに導入できる require（CommonJS）にも対応させるかどうかはライブラリの性質によって異なると思うが、今回は対応する。 npm パッケージに限らず、粗削りでいいから最初から最後まで動くものをまずは作り、あとから必要に応じて勉強や調査をすればいいと思っている（セキュリティやコンプライアンスに関わることは除く）。今

この記事の内容は TypeScript のv4.1.3で、compilerOptions.noUncheckedIndexedAccessを有効にした状態で動作確認している。 参考: zenn.dev 恒等関数（Identity Function）とは、渡されたものを返す関数。 function identity<T>(arg: T) { return arg; } const x = identity(1); // const x: 1 const y = identity(() => 1); // const y: () => 1 引数をそのまま返しているため当然だが、値は変わらない。 このままだと何の意味もないが、extendsキーワードを使って型に制約を与えることができる。 例えば以下のidentityには、ReturnNumberかそのサブタイプしか渡せない。 type Retu

このエントリで紹介するBlobやFile、FileReaderはHTML5で利用可能になったAPIで、ECMAScriptで定義されているわけではない。 そのため、Node.jsには存在せず、ブラウザ環境でのみ利用できる。 Blob Blobは、バイナリデータを表すimmutableなオブジェクト。 const blob = new Blob(['<xml>foo</xml>'], {type: 'text/xml'}); console.log(blob); // Blob(14) {size: 14, type: "text/xml"} 第二引数で設定しているtypeで、MIMEを設定できる。 何も設定しなかった場合は空の文字列になる。 File Fileはその名の通りファイルを表すオブジェクトで、Blobを継承している。 const file = new File(['<xml>fo

サーバ・クライアント間の通信を gRPC で行う場合、インターフェイスを定義した共通のファイルから、サーバとクライアント双方のコードを生成することができる。 この記事では、インターフェイスの定義ファイルを作成するところから始めて、gRPC を利用した単純なウェブアプリを作っていく。 gRPC についての概念的な説明などは扱わず、実際に手元で動くウェブアプリを作ることで、gRPC を使った開発についてイメージしやすくなることを意図している。 Next.js では API Routes を使って API サーバを作ることができるが、それを gRPC クライアントとして実装する。 そのため、リクエストの流れは以下のようになる。 Frontend == (REST) ==> API Routes == (gRPC) ==> gRPC Server 動作確認は Node.js のv16.13.2で行

History API は、HTML5 で導入された API。 これを使うことで、JavaScript で URL の履歴を管理できるようになる。 多くの場合、そういった操作は React Router や Vue Router などのルーティングライブラリを通して行うことになる。そのため、History API を直接操作する機会は稀だと思う。 しかし、ルーティングライブラリを使いこなし、特殊なユースケースにも対応できるようになるためには、History API そのものについても理解しておきたい。 この記事では、ルーティング機能を持った React アプリを開発しながら、History API について学んでいく。 使用している React のバージョンは16.13.1。 動作確認は Google Chrome の81.0.4044.113で行っている。 コンテンツに対して URL を

JavaScriptの言語仕様を勉強していくことにした。 いい技術書に巡り合ったこともあり、それなりに理解できるようにはなったが、まだまだ身についてはいない。 あくまでも、技術書の説明を読めば理解できる、というレベルに過ぎない。 これでは実際のコーディングに役立てることは出来ないし、開発中に詰まる度に、調べ直さなきゃいけない。 「読めば分かる」と「理解している」は、かなり距離がある。この距離を埋めていく。 ES5に準拠した内容を学んでいく。 本当はES2015(ES6)を学んだほうがいいのかもしれないが、ES6を体系的にまとめた入門書はまだ見当たらない。 それに、ES2015についての様々な情報は、ES5の内容を理解していることを前提にしているものが多い。 基礎を疎かにしないためにも、背伸びせずES5から学ぶことにした。 そのほうが、スムーズにES2015に移行でき、結果的に早いと思う。歯