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という文字の

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

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

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

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

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

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

現代の主要なブラウザでは、ES Modules（以下、ESM）を利用することができる。 つまり、import文やexport文を使った JavaScript ファイルを、トランスパイルすることなくそのまま使えるということである。 モジュールシステムをそのまま使えるので、複数のファイルをバンドルする必要もない。 この記事ではまず、ブラウザで ESM を使う方法について説明していく。 その後、処理の流れを詳しく確認していく。これを理解していないと、パフォーマンスが非常に悪いページになってしまう恐れがある。 動作確認は Google Chrome の84.0.4147.105で行っている。 ESM 利用の基本 まずは検証用にサーバを立てる。 以下のコードを Deno（バージョンは1.2.2）で実行する。 そうすると、http://localhost:8080/にアクセスしたときにindex.ht

「30歳からのプログラミング」と題したこのブログを書き始めたのが 2016 年 3 月。 そこから月日が立ち、立派なアラフォーとなったわけだが、私はこれまで 3 年以上継続して働いたことがない。プログラマに転身する前も含めて、である。一度もない。 3 年経つ前に、必ず無職になってしまう。労働して貯めた貯金を食い潰しながら無職生活を送り、カネが無くなりそうになってまた働く、ということを繰り返している。 だが、今の勤務先（株式会社HERP）に入社したのは 2021 年 10 月 1 日であり、入社してからもうすぐ 3 年になる。 つまり、 3 年以上労働を続けることになる可能性が高い。 仮にこの記事を投稿した直後に退職を決意したとしても、引き継ぎや有給休暇の消化などで、さすがに 9 月末までは在籍していると思う。そうなれば 3 年到達である。 今までの会社を辞めてきた理由は様々だ。同様に、今の

npm パッケージは基本的に、JavaScript ファイルで配布されている。TypeScript で開発しているパッケージであっても、JavaScript にビルドしたものを配布している。 そのため、型定義ファイルによって型付けしないと、インポートした際にモジュール全体がanyになってしまう。 これでは型システムの恩恵を受けることができないし、noImplicitAnyフラグをfalseにしていない場合はコンパイルエラーになってしまう。 npm パッケージをインポートした際、TypeScript は自動的に型定義ファイルを探索し、最初に見つかったものを使用する。 また、プロジェクト内にある JavaScript ファイルをインポートした際も、型定義ファイルの探索が行われる。 この記事では、TypeScript がどのように型定義ファイルを探索するのか、実際に検証して確認していく。 動作確

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

〜2020/7/8 追記〜 本記事に対して指摘を頂いた。 qiita.com 「余剰プロパティチェックの存在やそのルールによってorではないかのように見える（ことがある）というだけで、型システム的にはorである」と、私は解釈した。 特に「余剰プロパティチェックは、型システムに対する違反を検出するものではなく言わば追加の親切なチェック」という点が重要であり、確かにそこを無意識のうちに混同していた。 分かりやすく説明して頂いているので上記の記事を読めば十分かもしれないが、勉強も兼ねて、自分でも整理しておく。 共用体型は or である TypeScript では、オブジェクトに余計なプロパティがあっても問題にならない。 以下の例だと、string型のaというプロパティが存在していればAの条件を満たしていることになり、余計なプロパティが存在してもエラーにはならない。 type A = { a: s

「発生し得ない値」などのように説明される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

パフォーマンス・チューニングには、「こうすれば必ず上手くいく」という方法論や銀の弾丸はなく、地道に試行と計測を繰り返すしかない。 しかしだからこそ、基本的な考え方や仕組みを理解することが大切であり、それがなければ、どのように対処していけばいいのか見当をつけることすら出来ず、的外れな対応をすることにもなりかねない。 React.memoを使った処理の最適化は、React アプリのパフォーマンス改善のための、基本となるテクニックのひとつである。 この記事のコードは React のv16.10.2で動作確認している。 メモ化という概念 React アプリのパフォーマンス最適化を理解するためにはまず、メモ化（Memoization）という概念を把握しておく必要がある。 大雑把に言ってしまうとメモ化とは、何らかの計算によって得られた値を記録しておき、その値が再度必要になったときに、再計算することなく

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

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

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

今年の目標であった転職を果たしてしまいモチベーションが下がっているので、勉強会でも行ってみるかという気持ちになっている。 手始めに、このイベントに行った。 mixi.connpass.com 知っているサービスだし、年収800万円以上でプログラマを募集しているようなので、興味があった。 自分も年収800万円欲しい、そういう会社に入るにはどうすればいいのか、年収800万円の会社はどういうレベル感なのか知りたい、みたいな気持ちで行ってきた。 プロダクトオーナーである笠原氏の話と、4本のLTという構成。 笠原氏によるサービス紹介 みてねの概要と、サービスを始めた動機について。 子供が生まれたのがキッカケ。 生後1ヶ月で既に大量の写真や動画が生まれ、それをどうやって共有や整理するのかという課題が生まれた。 そこから、みてねが作られた。 人生を丸ごと残せる画像サービス、感動の振り返りが簡単に出来るサ