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 環境構築 まず最初に、手元で実際にコードを動かすための環境を構築す
Next.js で始める GraphQL - 30歳からのプログラミング
この記事では、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
なぜ組織の透明性が大切なのか - 30歳からのプログラミング
個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし
Deno で 学ぶ React のサーバサイドレンダリング - 30歳からのプログラミング
Deno で React のサーバサイドレンダリング（以下、SSR）を実現する方法をハンズオン形式で書いていく。 自分が調べた範囲では、単に JSX で HTML を構築して終わり、という記事が多かった。それではあまり実用的ではないので、この記事ではハイドレーションまで行う。 また、React で SSR する方法を調べたところ、ほとんどの記事が Next.js を前提としていた。確かに Next.js を使わずに SSR するケースはあまりないだろうし、記事としても需要がないのだと思う。 しかし、Next.js のようなフレームワークが裏側で何をやってくれているのかを知ることで、SSR に対する理解を深めることができる。 事実、私は SSR をほとんど使ったことがなかったが、この記事を書くことでかなり考えを整理することができた。 Deno のバージョンは1.11.2で動作確認している。
フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
package.json の resolutions を使って依存パッケージのバージョンを指定する - 30歳からのプログラミング
package.jsonのresolutionsフィールドを使うことで、依存ツリーの深い部分にあるパッケージのバージョンを固定することが可能になる。 現在のところ Yarn でのみ使える機能だが、サードパーティが公開しているライブラリを使うことで npm でも使えるようになる。 動作確認に使った npm のバージョンは6.14.5。Yarn は1.22.4。 後述するnpm-force-resolutionsについては、0.0.3を使っている。 npm や Yarn でパッケージをインストールすると、指定したパッケージだけでなく、そのパッケージが依存しているパッケージもインストールされる。 そうしてインストールされたパッケージが他のパッケージに依存していれば、そのパッケージもインストールされ、それが繰り返されていく。 この仕組みについては、以下の記事で詳しく触れた。 numb86-tech
package.json やロックファイルによるパッケージの依存関係の管理 - 30歳からのプログラミング
この記事では、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
React の状態管理についての論点整理 - 30歳からのプログラミング
なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、
SPA フルリニューアル計画における技術選定や設計思想（2019年2月版） - 30歳からのプログラミング
SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか
async/awaitを使った非同期処理の書き方 - 30歳からのプログラミング
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
