Node.js における ES Modules を理解する - 30歳からのプログラミング
記事執筆時点での最新版の Node.js では、モジュールシステムとして ES Modules を使うことができる。 また、CommonJS で書かれたモジュールを ES Modules で読み込むこともできる。 Node.js のモジュールシステムは複雑すぎて苦手意識があったので、整理した。 この記事の内容は、Node.js のv14.7.0で動作確認している。 Node.js のモジュールシステムはバージョン毎に挙動が大きく変わるので、注意が必要。 そのファイルは CJS なのか ESM なのか Node.js で使えるモジュールシステムとして、ES Modules（以下、ESM）の他に CommonJS（以下、CJS）があり、CJS がデフォルトになっている。 Node.js におけるモジュールシステムを理解するためにはまず、Node.js が各ファイルをどのモジュールシステムとして
なぜ組織の透明性が大切なのか - 30歳からのプログラミング
個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし
TypeScript における変性（variance）について - 30歳からのプログラミング
プログラミングの型システムに関する記事を読んでいると、共変や反変といった用語が出てくることがある。 TypeScript や Flow についての記事でも、見かけることがある。 それらは TypeScript を使う上で必須の知識ではないが、把握しておくに越したことはない。 この記事では、TypeScript を題材にして、変性について説明していく。 TypeScript に関する議論を理解できるようになることがこの記事の目的であり、より詳細な、学術的、数学的な内容には踏み込まない。 この記事の内容は、TypeScript のv3.9.5で動作確認している。 変性 変性（variance）とは、任意の型Tに対してどのような性質を持つのか示したものであり、以下の 4 種類がある。 不変性（invariance） Tそのものが必要 共変性（covariance） Tそのものか、そのサブタイプが
プログラミングを勉強するために 30 代半ばの 2 年間を無職として過ごした話 - 30歳からのプログラミング
2019 年の夏に前職を辞め、そのまま無職として過ごし今年の 10 月にようやく再就職して働き始めた。 何か事情があって働けなかったわけではなく、プログラミングの能力を伸ばすために敢えて就職しなかった。 自分にとってそれなりに重要な期間だったと思うので、記録を残しておく。 予め断っておくが、何か「すごいこと」を成し遂げたわけではない。「すごくないプログラマ」が少しでもすごくなりたくて勉強していた話に過ぎない。 「すごいプログラマ」が「すごいこと」をした話を読みたければ、以下の記事などがよいと思う。 会社をやめて約1年プログラミングの勉強に費やしたことに対する満足と後悔 | blog.ojisan.io 2年間の独学をふりかえって – Happy Coder 予防線を張ったところで、本題に入る。 背景や動機 プログラミングの勉強をするために前職を辞めたわけではなく、退職の理由は別にある。 そ
Deno で 学ぶ React のサーバサイドレンダリング - 30歳からのプログラミング
Deno で React のサーバサイドレンダリング（以下、SSR）を実現する方法をハンズオン形式で書いていく。 自分が調べた範囲では、単に JSX で HTML を構築して終わり、という記事が多かった。それではあまり実用的ではないので、この記事ではハイドレーションまで行う。 また、React で SSR する方法を調べたところ、ほとんどの記事が Next.js を前提としていた。確かに Next.js を使わずに SSR するケースはあまりないだろうし、記事としても需要がないのだと思う。 しかし、Next.js のようなフレームワークが裏側で何をやってくれているのかを知ることで、SSR に対する理解を深めることができる。 事実、私は SSR をほとんど使ったことがなかったが、この記事を書くことでかなり考えを整理することができた。 Deno のバージョンは1.11.2で動作確認している。
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 Router v5.1 で導入された Hooks API について - 30歳からのプログラミング
React Router のv5.1で Hooks API が導入された。 reacttraining.com URL パラメータやhistoryオブジェクトなどを、より簡単に取得できるようになった。 これまでの書き方も使えるが、今後のバージョンアップで非推奨になる可能性が高いとのことなので、今のうちに Hooks を使った書き方に慣れておいたほうがいいかもしれない。 個人的にはwithRouterを使わなくてもよくなるのが便利だと感じた。 この記事の内容は以下のバージョンで動作確認している。 react@16.10.2 react-router-dom@5.1.2 今回導入された API は以下の4つ。 useParams useLocation useHistory useRouteMatch コードを見ると、どれもReact.useContextを使って実装している模様。 react
ルーティング機能を自作して学ぶ History API - 30歳からのプログラミング
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 を
堅牢性と変更容易性 - 30歳からのプログラミング
いろいろと考える機会があったので、備忘録としてまとめておく。 システムにおける堅牢性とは何か。 それは、壊れにくいこと、破綻しにくいことだと思う。 では、破綻しているとはどういう状態なのか。 システム全体の複雑さが増していって開発者がコントロールするのが難しくなること。 その結果として、いつの間にかバグが埋め込まれてしまって全く予期しない形でシステムが壊れてしまう、という現象が発生しやすい状態であること。 末期まで行くと、変更を加えること自体が困難になる。何かを修正すると別のところが壊れてしまうという状態になっており、身動きが取れない。 破綻を生み出す原因として何があるか。 頭のなかを整理しきれていないが、思いつくもの。主にフロントエンドの話。 考慮しなければならない要素が多すぎる 状態管理が難しく、複雑性を増している UI（コンポーネントなど）が状態を持っている 様々なコンポーネントが
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 を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、
forwardRef と useImperativeHandle - 30歳からのプログラミング
コンポーネント内の DOM 要素にRefオブジェクトを渡すための機能であるforwardRefと、コンポーネントにメソッドを生やす Hooks であるuseImperativeHandleについて、説明する。 どちらもRefオブジェクトやref属性を使った機能なので、それらを理解していることが前提になる。 理解が不十分な場合はまず Ref の基本を学ぶことをおすすめする。 numb86-tech.hatenablog.com この記事のコードは React のv16.10.2で動作確認している。 forwardRef forwardRefを学ぶための題材として、テキストボックスへのフォーカスを扱う。 以下のコードでは、focusボタンを押すとテキストボックスにフォーカスする。 import React, {useRef} from 'react'; const App = () => {
なぜ E2E テストを書くのか - 30歳からのプログラミング
あまりまとまってないし、大したことは書いていない。このへんの話について知見を持っている人は、いろいろ教えて欲しい。 前提として、フロントエンドエンジニアの立場から書いている。 E2Eテストは高コストだと言われる。書くのも大変だし、メンテナンスも大変。 私はSPAを開発することが多いが、SPAをE2Eテストする場合、APIサーバをどうするのかも考えないといけない。 ではなぜ、E2Eテストを書くのだろうか。なぜ、ユニットテストだけではダメなのだろうか。 どこまで投資するかはともかく、E2Eテストは書いたほうがいいと思う。書くに越したことはない。自然にそう思う。 でもその理由を、上手く言語化できない。 しかし高いコストをかけて導入する以上、ちゃんと理由を整理しておきたい。 手間のかかる手動テストをある程度代替できるから、だろうか。 UIのあるソフトウェアを作っている人は、必ず、手動でテストすると
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 を作るときにどのような設計にするのか、現時点での考えを記録しておく。 チュートリアル
TypeScript で npm パッケージを作る - 30歳からのプログラミング
TypeScript で書いたプログラムを npm パッケージとして配布する手順を書いていく。 まだ npm パッケージの配布をしたことがない人を、想定読者としている。 よりよい書き方、詳細な設定、は措いておき、まずは最低限の要件を満たすものを作り上げる。 今回の「最低限の要件」は以下。 npm installやyarn addでインストールできる importでもrequireでもインポートすることが出来る 型定義ファイルを同梱し、TypeScript アプリにもスムーズに導入できる require（CommonJS）にも対応させるかどうかはライブラリの性質によって異なると思うが、今回は対応する。 npm パッケージに限らず、粗削りでいいから最初から最後まで動くものをまずは作り、あとから必要に応じて勉強や調査をすればいいと思っている（セキュリティやコンプライアンスに関わることは除く）。今
SPA フルリニューアル計画における技術選定や設計思想（2019年2月版） - 30歳からのプログラミング
SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか
Node.jsのexportsについて - 30歳からのプログラミング
Node.jsにはモジュール機能があり、他のファイルの内容を読み込むことが出来る。 だが、何となくでしか使い方を理解していなかったので、調べてみた。 このエントリのコードは全て、v4.4.3で動かした。 基本 まず、呼び出される側のファイルで、モジュール化する値やオブジェクトをexportsしておく。 そうすることで、その値やオブジェクトに外部からアクセスすることが可能になる。 呼び出す側ではrequire()関数を使い、ファイルを読み込む。 読み込んだファイルから、exportsされている値やオブジェクトにアクセスできるようになる。 // parts.js var value = '値'; var foo = 'foo'; exports.value = value; // index.js var parts = require('./parts.js'); console.log(p
Promiseによる非同期処理の書き方 - 30歳からのプログラミング
JavaScriptは基本的に逐次処理、同期処理であり、上から順番にプログラムが実行されていく。 x行目の処理が終わってからx+1行目の処理を行う、という具合に、一つ一つ実行していく。 非同期処理を行うための方法も以前から用意されていたが、ES2015で導入されたPromiseによって、より簡便に実装できるようになった。 なお、ここに書かれているものは全て、v6.4.0のNode.jsで実行した結果である。他の環境だと、ログの内容が異なるかもしれない。 Promiseの基本 new Promise()でPromiseのインスタンスを作り、それを操作することで非同期処理を管理していく。 new Promiseの引数には関数を渡す。 そしてその関数の第一引数としてresolveを、第二引数としてrejectを設定し、処理が上手くいったら前者を、失敗したら後者を実行する。 不要であれば、reje
配列の最大値を取得する ES2015版 - 30歳からのプログラミング
JavaScriptで、配列の最大値を取得する方法について。 最初に答えを書いておくと、Math.max(...targetArray)。 旧来はapplyを使うのが主流だった？ Math.max()を使うと、数値の中から最大のものを取得できる。 Math.max(6, 8, 9, 7); // 9 しかしこれは、一つずつ数を渡す必要があり、配列を渡すことは出来ない。 配列でMath.max()を使うにはどうすればいいのか。 applyを使えば解決する。 const array = [3, 8, 7, 2, 5]; Math.max.apply(null, array); // 8 applyの第二引数には配列を渡して使うが、この配列の要素が1つずつ引数として渡される。 そのため、配列を展開してそれを引数として渡す手段として、applyが有用なのだ。 このテクニックは有名らしく、Math.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
