もうすぐ 40 歳になるが労働を 3 年以上続けられたことがない IT エンジニアの話 - 30歳からのプログラミング
「30歳からのプログラミング」と題したこのブログを書き始めたのが 2016 年 3 月。 そこから月日が立ち、立派なアラフォーとなったわけだが、私はこれまで 3 年以上継続して働いたことがない。プログラマに転身する前も含めて、である。一度もない。 3 年経つ前に、必ず無職になってしまう。労働して貯めた貯金を食い潰しながら無職生活を送り、カネが無くなりそうになってまた働く、ということを繰り返している。 だが、今の勤務先（株式会社HERP）に入社したのは 2021 年 10 月 1 日であり、入社してからもうすぐ 3 年になる。 つまり、 3 年以上労働を続けることになる可能性が高い。 仮にこの記事を投稿した直後に退職を決意したとしても、引き継ぎや有給休暇の消化などで、さすがに 9 月末までは在籍していると思う。そうなれば 3 年到達である。 今までの会社を辞めてきた理由は様々だ。同様に、今の
Node.js Stream の初歩 - 30歳からのプログラミング
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 環境構築 まず最初に、手元で実際にコードを動かすための環境を構築す
React の新しい概念「トランジション」で React アプリの応答性を改善する - 30歳からのプログラミング
React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい
Deno で 学ぶ React のサーバサイドレンダリング - 30歳からのプログラミング
Deno で React のサーバサイドレンダリング（以下、SSR）を実現する方法をハンズオン形式で書いていく。 自分が調べた範囲では、単に JSX で HTML を構築して終わり、という記事が多かった。それではあまり実用的ではないので、この記事ではハイドレーションまで行う。 また、React で SSR する方法を調べたところ、ほとんどの記事が Next.js を前提としていた。確かに Next.js を使わずに SSR するケースはあまりないだろうし、記事としても需要がないのだと思う。 しかし、Next.js のようなフレームワークが裏側で何をやってくれているのかを知ることで、SSR に対する理解を深めることができる。 事実、私は SSR をほとんど使ったことがなかったが、この記事を書くことでかなり考えを整理することができた。 Deno のバージョンは1.11.2で動作確認している。
フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
never 型を使った TypeScript のテクニック - 30歳からのプログラミング
「発生し得ない値」などのように説明される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 の状態管理についての論点整理 - 30歳からのプログラミング
なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、
React Hooks + Redux Hooks + TypeScript で SPA を構築する（追記あり） - 30歳からのプログラミング
2020/05/31 追記 勉強や経験を重ねた結果、この記事を執筆した時より知識が増え、コードの書き方にも変化があります。 サンプルアプリも同様で、以下のプロダクトのコードのほうが、今の自分の考えが反映されていると思います。 github.com 追記終わり 2019/07/14 追記 ディスカウント後の価格みたいな導出項目はselector (reselect)を使うとよいのでは https://redux.js.org/recipes/computing-derived-data - YonmanHasse のブックマーク / はてなブックマーク というコメントを頂き、確かに便利そうだったので導入した。 それに合わせてこの記事の内容もアップデートした。 追記終わり タイトルに書いた組み合わせで SPA を作るときにどのような設計にするのか、現時点での考えを記録しておく。 チュートリアル
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
