Articles on Dev TLDRLSS

SQLiteの気まぐれに騙されるな！動的型の罠とは？なぜ ALTER TABLE は不完全なのか？Node.jsで防御的プログラミングを行いスムーズなテーブル移行を実現する方法

Tue, 19 May 2026 18:10:00 +0800

リサイクルボックスに「ペットボトル専用」と書かれたラベルが貼ってあるのに、誰かが紙くずを投げ入れても、一言の抗議もなく静かに受け入れている様子を想像してみてください。

これが、開発者が初めて SQLite の型システムに出会ったときの背筋の凍るような体験です。

型が正しくなければ入国を即座に拒否する PostgreSQL のような厳格な税関スタイルに慣れていると、SQLite の気まぐれさ（ルーズさ）に人生を疑いたくなるかもしれません。

さらに恐ろしいことに、テーブル構造を変更 しようとすると、こう告げられます。

「テーブルを直接変更することはできません。新しい家を建て、家具を移動させてから、古い家を爆破してください。」

SQLiteの内部には5つのストレージクラスしかない

CREATE TABLE でどれほど華やかな型名（VARCHAR(255)、BIGINT、DECIMAL）を宣言しても、SQLite の内部が認識するのは以下の 5つのストレージクラス だけです。

ストレージクラス	説明
NULL	空値
INTEGER	整数（数値の大きさに応じて自動的に1〜8バイトを占有）
REAL	浮動小数点数（固定8バイト）
TEXT	文字列（デフォルトはUTF-8エンコーディング）
BLOB	バイナリデータ（入力されたまま保存）

カラムに設定する型は、SQLite にとって 単なる「推奨」であり、「強制ルール」ではありません。

これを 「型アフィニティ（Type Affinity）」 と呼びます。SQLite はデータを推奨される型に変換しようと試みますが、変換できない場合はエラーを吐かずに元のデータをそのまま挿入します。

カラムに設定する型は、SQLite にとって 単なる「推奨」であり、「強制ルール」ではありません。

最も陥りやすい3つの型の罠

罠1：ネイティブのBooleanがない

SQLite にには Boolean型がありません。True と False は整数 1 と 0 でしか表現できません。

Node.js を使って SQLite からデータを取得すると、true や false ではなく、数値の 1 または 0 が返ってきます。

if (user.is_admin === true) のようなチェックを直接行うと、永遠に真になりません。

罠2：Date/Time型がない

SQLite には 日付時刻型がありません。時間は以下のように保存するしかありません。

保存方法	例	メリット・デメリット
TEXT（ISO-8601 文字列）	`'2026-05-19T18:00:00Z'`	最も推奨。視認性が高く、将来 PostgreSQL に移行する際もスムーズに変換可能
INTEGER（Unixタイムスタンプ）	`1747656000`	フットプリントは小さいが、人間には読めない

日付を 2026/5/19 午後6時 のような独自のカスタム形式で保存してはいけません。将来のデータマイグレーションで悲劇が起こります。

罠3：INTEGERカラムに文字列を挿入してもエラーにならない

PostgreSQL では INTEGER カラムに文字列を挿入すると即座にエラーになります。しかし SQLite は静かに変換を試み、失敗した場合はそのまま受け入れます。

これは、汚いデータが静かにデータベースに紛れ込む 可能性を意味します。ある日、プログラムが予期しない型を受け取ってクラッシュしたときに初めて、問題に気づくことになります。

防御的プログラミング：気まぐれなデータベースに厳格な態度で臨む

SQLite のルーズさに直面したとき、Node.js 開発では 厳格な防御メカニズム を構築しなければなりません。

防御レベル	ツール	役割
コンパイル時のガード	TypeScript	コード記述段階で誤った型をキャッチする
API入口での検証	Zod	受信するデータを厳格に検証する（ageが必ず数値であることを保証する）
内部的な型キャスト	Prisma / Drizzle ORM	SQLiteとPostgreSQL間の型の違いを自動的に処理する

「データ検証の門番」 をデータベース層から Node.js アプリケーション層に移動させることが、SQLite の開発スピードを活かしつつ、将来の拡張性を確保するための重要な戦略です。

ORM を使用する場合、コード内で type: 'boolean' と宣言しておけば、ORMが SQLite への保存時に自動的に 1/0 に変換し、読み込み時には true/false に自動変換してくれるため、底層の型の違いを完璧に隠蔽できます。

ALTER TABLEは不完全：何が変更できて、何ができないのか

SQLite がサポートするテーブル構造の変更は非常に限定的です。

操作	サポート状況
カラムの追加（`ADD COLUMN`）	はい
カラム名の変更（`RENAME COLUMN`）	はい
カラムの削除（`DROP COLUMN`）	はい（比較的新しいバージョンのみ）
テーブル名の変更（`RENAME TO`）	はい
カラム型の変更	いいえ
`UNIQUE`、`NOT NULL` 制約の追加/削除	いいえ
プライマリキーの変更	いいえ
外部キーの変更	いいえ

「サポートされていない」変更を行う必要がある場合、SQLite は 「再作成して移行する」 戦略を実行するよう要求します。

再作成＆移行の4ステップ：SQLite流のテーブルアップグレード方法

直接変更できないため、公式ドキュメントが推奨する標準的なアプローチは、新しい家を建て、家具を移動し、古い家を爆破し、新しい表札を掲げる ことです。

ステップ	アクション	説明
1	新しいテーブルの作成	`CREATE TABLE users_new (...)` を正しい構造で作成
2	データのコピー	`INSERT INTO users_new SELECT ... FROM users`
3	古いテーブルの削除	`DROP TABLE users`
4	テーブル名の変更	`ALTER TABLE users_new RENAME TO users`

これら4つのステップは 一気に行う 必要があり、途中で停電やアプリケーションのクラッシュが発生するとデータ損失につながります。

アップグレードでデータを失わないための確保：2つの安全防衛線

防衛線1：物理的な防衛、ファイルを直接コピーする

SQLite は本質的に単なるファイルです。スキーマ変更を実行する前に、単純に .db ファイルをバックアップとしてコピーしておくだけで十分です。

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

万が一失敗した場合は、ファイルを元に戻すだけで一瞬で復元できます。これは他の巨大なデータベースにはない強みです。

防衛線2：トランザクションによるカプセル化、データベースのタイムマシン

すべての移行ステップを単一の Transaction 内でカプセル化します。いずれかのステップが失敗した場合、プロセス全体が 自動的にロールバック され、何事もなかったかのように復元されます。

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('テーブルのアップグレードに成功しました');
} catch (error) {
  console.error('アップグレードに失敗しました。データは安全に復元されました：', error.message);
}

「バックアップファイル＋トランザクションバインド」 が、データベースマイグレーションのエアバッグとなります。

厳格な態度でルーズな SQLite を乗りこなす

気まぐれな SQLite を 厳格なアプリケーション層アーキテクチャ で制御することで、将来の技術的負債を回避しながら、その超高速な開発スピードを存分に享受できます。

SQLiteの型システムは非常にルーズであり、ALTER TABLE にも多くの制限があります。

しかし、Node.js 側で TypeScript の型チェック＋ Zod のバリデーション＋ ORM の抽象化 をしっかりと行い、物理バックアップ＋トランザクション の安全戦略と組み合わせることで、SQLite がもたらす開発効率を安心して享受しつつ、将来 PostgreSQL に移行するための道筋を整えることができます。

Reference

すべてに PostgreSQL を使うのはやめよう！SQLite の組み込み型アーキテクチャとゼロ設定のメリットとは？SQLite の限界はどこにある？SQLite と PostgreSQL、どちらを選ぶべき？

Tue, 19 May 2026 18:00:00 +0800

毎日開くブラウザ、スマホのメッセージアプリ、あるいはデスクトップ上のメモツールの中に、すべて同じ軽量データベースが隠されていると考えたことはありますか？

サーバーソフトウェアのインストールは不要で、アカウントやパスワードの設定も要らず、インターネット接続すら必要ありません。それは単なる ファイル であり、ハードディスクに静かに横たわり、いつでもサービスを提供する準備ができています。

この控えめな存在こそが、SQLite です。

SQLite とは？世界で最も広く導入されているデータベース

SQLite は、C 言語で書かれた 組み込み型関係データベースエンジン です。

独立したサーバープロセスを持たず、アプリケーションに直接組み込まれて動作します。

これは、お馴染みの PostgreSQL や MySQL とはまったく異なります。従来のデータベースは 独立して動作するサーバー であり、プログラムは ネットワークプロトコル（TCP/IP） を介してそれと「通信」する必要があります。

しかし、SQLite は違います。それは単なるコードのブロックであり、アプリケーションの内部で直接実行され、ハードディスク上の .db ファイルを読み書きします。

比較基準	SQLite（組み込み型）	PostgreSQL（クライアント・サーバー型）
動作モード	アプリケーションに直接組み込み、独立サーバーなし	独立したサーバープロセス、ネットワーク接続経由
設定要件	ゼロ設定、インストール不要、認証情報不要	インストール、アカウント/パスワード設定、ファイアウォールが必要
データ保存	単一のクロスプラットフォームファイル	サーバーディレクトリ配下の複数ファイル
バックアップ方法	そのファイルを直接コピーするだけ	pg_dump などの専用ツールが必要

まさにこの 「プラグアンドプレイ」 の特性により、SQLite は世界で最も広く導入されているデータベースエンジンとなりました。

Android や iOS オペレーティングシステム、Chrome や Firefox ブラウザから、Adobe Lightroom、WhatsApp、さらには Airbus A350 の飛行システムに至るまで、いたるところに存在しています。

Node.js での SQLite の使用

Node.js 開発者であれば、SQLite の使用は非常に簡単です。コンピューターにデータベースサーバーソフトウェアをインストールする必要はなく、npm パッケージをインストールするだけで開始できます。

現在、業界で最も一般的に使用されている選択肢：

パッケージ名	特徴	推奨されるシナリオ
`sqlite3`	最も老舗、非同期 API をサポート	多数 of 非同期タスクを同時に処理する必要がある場合
`better-sqlite3`	優れたパフォーマンス、直感的な API 設計、極めて高速	第一推奨、開発効率と実行速度を追求する場合

better-sqlite3 を使ってデータベースを作成し、クエリを実行するのに 5 分もかかりません：

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

ファイルが存在しない場合、better-sqlite3 が 自動的に作成します。

SQLite は想像以上に強力な SQL 構文をサポートしている

多くの人は SQLite が非常にシンプルだと思っていますが、実際には以下のような高度な機能を含む、標準的な SQL 構文の大部分をサポートしています：

構文カテゴリ	サポート項目
基本操作	`SELECT`、`INSERT`、`UPDATE`、`DELETE`
データ定義	`CREATE TABLE`、`CREATE INDEX`、`CREATE VIEW`
高度なクエリ	`WITH`（再帰的 CTE）、ウィンドウ関数（Window Functions）
衝突処理	`UPSERT`（`INSERT ... ON CONFLICT DO UPDATE`）
JSON 処理	`json_extract`、`json_array`、`json_object` などの組み込み関数
トランザクション制御	`BEGIN`、`COMMIT`、`ROLLBACK`、`SAVEPOINT`
結合クエリ	`INNER JOIN`、`LEFT JOIN`、`RIGHT JOIN`、`FULL OUTER JOIN`

SQLite のコア哲学は「スモール・イズ・ビューティフル」 です。日々必要な SQL 機能の大部分をサポートしつつ、極限まで軽量さを維持しています。

SQLite の限界はどこにある？

軽量さには代償が伴います。もし SQLite を レジが 1 つしかない個人経営の雑貨店 に例えるなら、PostgreSQL は 50 個のレジを備えたコストコ です。

1. 書き込みの渋滞

SQLite はデータを書き込む際、データベースファイル全体を ロック します。

トイレが 1 つしかないレストラン を想像してみてください。100 人が外で同時にメニューを見る（読み取り）ことはできますが、誰か 1 人が入ってドアに鍵をかける（書き込み）と、他の全員は並んで待つしかありません。

WAL モード（Write-Ahead Logging） を有効にすれば、同時読み書きのパフォーマンスは向上しますが、本質的に複数のスレッドが異なるデータ行に同時に書き込むことはできません。

2. 複数サーバー間での共有不可

SQLite の本質は物理ファイルです。システムを複数のサーバーにデプロイする場合（水平スケーリング）、これらのサーバーで 同じファイルを安全に共有することはできません。

3. きめ細かな権限管理の欠如

SQLite には「ユーザーアカウント」という概念がありません。OS レベルでその .db ファイルを読み取れる人であれば、誰でもすべてのデータを閲覧・変更できます。

厳格な個人情報監査が必要なビジネスシステム において、这是無法接受的。

SQLite vs. PostgreSQL：技術選定の意思決定

ツールに優劣はなく、適しているかどうかがすべてです。判断を助けるための究極のチェックリストを紹介します：

質問	回答が「はい」 → SQLite を選択	回答が「いいえ」 → PostgreSQL を選択
バックエンドサーバーは 1 台だけ、またはローカルのみで動作していますか？	はい	いいえ（水平スケーリング、複数マシンが必要）
システムの動作は読み取りが圧倒的に多く、高頻度の同時書き込みはありませんか？	はい	いいえ（同時書き込みが多発する）
きめ細かな権限管理や、高度なインデックス機能は不要ですか？	はい	いいえ（高度な機能に強く依存している）

より具体的なシナリオ比較：

シナリオ	推奨される選択肢	理由
デスクトップソフト、スマホアプリ、IoT 機器	SQLite	データがデバイスに追従し、インストール不要
個人ブログ、紹介用ホームページ	SQLite	参照が多く書き込みが少ないため、サーバー維持費を削減可能
迅速なプロトタイプ開発、デモ	SQLite	ファイルを作成するだけで即座に開始可能
コミュニティフォーラム、EC サイト	PostgreSQL	高い同時書き込みが発生し、行レベルのロックが必要
複数サーバーへの分散デプロイ	PostgreSQL	複数マシン間でデータソースを共有する必要がある
医療、金融などの機密システム	PostgreSQL	ロールベースの厳格な権限管理が必要

あなたのデータベースはポケットのメモ帳か、それとも中央交換手か

データが 「シングルマシン、静的、単一の所有者」 であるなら、SQLite を選んで究極の軽快さと自由を享受しましょう。

データが 「クラウド、動的、高度なインタラクティブ」 であるなら、PostgreSQL に任せましょう。

SQLite のコア哲学は 「アプリケーション of 内部コンポーネント」 であるのに対し、PostgreSQL は 「システムアーキテクチャ of 独立した中心」 として位置づけられています。

次回、アーキテクチャの意思決定を行う際は、急いで PostgreSQL を持ち出す前に、まず自分自身に問いかけてみてください：

「私のデータベースは、ポケットのメモ帳ですか、それとも中央交換手ですか？」

答えがはっきりすれば、選択は自然と明らかになります。

Reference

ビジネスソフトウェアのオープンソースパッケージはどのように選ぶべきか？ MIT、BSDからApache 2.0までのライセンスリスク軽減とアーキテクチャガイド

Fri, 27 Feb 2026 08:26:00 +0800

ソフトウェアエンジニアやアーキテクトとして、私たちは開発時に効率を優先することがよくあります。GitHubで星が多く、ドキュメントが美しい強力なオープンソースパッケージを見ると、無意識のうちにpnpm addやnpm installを叩いてしまうことがよくあります。

しかし、これらの表面的には 「無料」 で 「自由」 なツールが、会社を特許侵害のリスクに陥れる可能性のある時限爆弾を隠しているかもしれないと考えたことはありますか？

商用ソフトウェアの開発において、技術的な機能以外に、これらのオープンソースプロトコル（ライセンス）の背後にあるニュアンスをどのように理解すべきでしょうか？

「商業的フレンドリー」の境界を理解する

オープンソースの世界では、すべての「無料」が平等に作られているわけではありません。通常、一般的なライセンスは2つの主要な陣営に分けられます：

1. 商業的に非常にフレンドリー（Permissive Licenses）

この種のライセンスの核となる精神は：「持って行って自由に使ってね。ただし私が書いたことだけは覚えておいて。何か問題が起きても私のところに来ないで。」 というものです。製品を開発して販売する企業にとって、これらは道端で配られる「無料のチラシ」のようなもので、弁当のランチョンマットにしたり、紙飛行機にしたり、さらには絶妙な製品に再パッケージしたりできます。

ライセンス	説明
MIT	最もシンプルで、最大限の自由（例：React、Vue）。
BSD (2/3-Clause)	MITの兄弟のようなものですが、法的な免責をより強調しています。
Apache 2.0	ビジネス向けの第一候補であり、追加の「特許ライセンス」保護を含んでいるためです。

2. 商業利用には注意が必要（Copyleft Licenses）

これらのライセンスは 「ウイルス性（伝染性）」 を持っています。最も有名なのは GPL シリーズです。

これは「血の誓い」に参加するようなものです。コードベースでこの種のコードを参照または変更する限り、規則に従って、製品全体が彼らの「姓」を採用しなければならない可能性があります。つまり、ソースコードのオープンソース化を強制されることを意味します。

ミニマリストライセンスの「特許の罠」：なぜMITとBSDは十分に安全ではないのか？

多くの人がこう考えています：「MITはとても自由だから、商業利用でも絶対に安全だろう？」しかし、

「著作権（Copyright）」は「特許権（Patent）」とイコールではありません。

MITやBSDのライセンスは非常に簡潔です。これらは主に テキストコードのコピーを許可 しています。しかし、法的な空白部分では、原作者は実際に次のように主張する可能性があります：

「コードテキストをコピーすることは許可したが、コードに含まれる技術特許を自由に使用できるとは言っていない！」

対照的に、Apache 2.0 には「休戦協定の贈り物」が付いています。2つの最強の防御メカニズムが組み込まれています：

項目	内容
明確な特許付与	原作者がコードをリリースする際、彼らの技術特許もあなたに与えられることに署名し、誓約します。
特許報復条項（核抑止力）	誰かがこのコードを使用して特許侵害で原作者を訴えた場合、そのソフトウェアに対するすべての特許付与を自動的に失います。これにより全員の間に暗黙の「特許停戦」が確立され、大企業（Google、Amazonなど）に特に好まれています。

クラウドの巨人がオープンソースのクリエイターと衝突する時

MongoDBやElasticsearchがライセンスを変更したというニュースを聞いたことがあるかもしれません。それはクラウドの巨人（AWSなど）が「フリーライド」に長けすぎていたからです。

これらの巨人は、オープンソースパッケージを利用してホスト型サービスを構築し、大金を稼いでいるにもかかわらず、原作者にはほとんど還元していません。そこでクリエイターたちは、SSPLのような条項で反撃に出ました：

使用することはできますが、私のソフトウェアをサービス（SaaS）として他人に販売したい場合は、クラウドインフラストラクチャ全体のコードもオープンソース化する必要があります。

これにより、巨人が最新の機能を直接転売することを効果的に防ぎ、ユーザーにクリエイターのプロフェッショナルなSaaSへの移行を強制しました。

アーキテクトの防御戦略：「ファイアウォール」の構築

要求により、高リスクのパッケージや特許紛争のあるパッケージを使用せざるを得ない場合、アーキテクトとして何をすべきでしょうか？

選び方を知るだけでなく、「ファイアウォール」の構築方法も知る必要があります。最も典型的なアプローチは、「アダプターデザインパターン（Adapter Pattern）」 を利用することです。

簡単に言えば、ビジネス処理ロジック内でそのパッケージを直接呼び出さないでください。まず、抽象層のインターフェースを定義します。これは壁にコンセントの穴を開けるようなものです。コンセントの裏が国の送電網からの電力（パッケージA）なのか、発電機（パッケージB）なのかは、電気を消費する機器（ビジネスロジック）にとっては透明なままです。

依存関係の逆転 を使用してビジネスロジックをオープンソースの依存関係から切り離すことで、将来ライセンスの問題が発生したり価格交渉が決裂したりしても、パッケージを素早く交換するために アダプター層（Adapter）を再実装 するだけで済み、「素早く逃げる」能力を得ることができます。

結論：摩天楼を建てるには安定した基礎が必要

適切なオープンソースライセンスを選ぶことは、適切な基礎を敷くようなものです。安定した基礎があってこそ、安心して高層ビルを建てることができます。

次回、見慣れないパッケージを導入する前に、立ち止まってLICENSEファイルを一瞥し、それがどのタイプのライセンスであるかを確認し、潜在的な特許リスクを評価することを忘れないでください。「ソフトウェアアーキテクト」が持つべきこの防御的な意識と切り離しの戦略を養うことによってのみ、私たちは反復の速いソフトウェア開発の道を、より着実に、そしてさらに遠くまで歩むことができるのです。

Reference

データベースの金額保存：DECIMALとBIGINTのどちらを使うべきか？

Wed, 25 Feb 2026 13:35:00 +0800

決済やEコマースシステムを開発中、データベースの金額フィールドを設計する際に、「金額は FLOAT や DOUBLE で保存しよう」と考えたことはありませんか？

もしそうなら、すぐに手を止めてください！システムが密かにお金を漏らしているかもしれません。

金融システムで浮動小数点数が禁止されているのはなぜでしょうか？一見取るに足らない精度誤差でも、膨大な取引量と時間の蓄積により、取り返しのつかない大惨事になる可能性があります。

では、お金を保存するには何を使うべきでしょうか？

なぜ FLOAT は財務システムの毒なのか？

コンピュータの世界では、数字は2進数で表されます。FLOAT（浮動小数点数）は、特定の10進数の小数を表すとき、実際には「近似値」になります。これは、粗いチェーンソーで繊細なケーキを切ろうとするようなもので、いくら注意しても必ず端から削りかすが落ちてしまいます。

典型的な例がこれです：0.1 + 0.2 はコンピュータ内では 0.3 にならないことがよくあります。数百万件もの取引を処理する場合、これら「0.00000000000000004」の微小な誤差が蓄積し、帳簿が決して合わなくなります。覚えておいてください：

お金に関して、いかなる「近似値」も大惨事を招きます。

会計士の精密な帳簿：DECIMAL のメリット

「見たままの正確な値」を求める精緻なソリューションが必要なら、DECIMAL がデータベースのネイティブな固定小数点数であり、業界標準の手法です。

DECIMAL は会計士の持つ精密な帳簿のようなもので、整数と小数を正確に分けて保存し、0.1 + 0.2 が絶対に 0.3 になることを保証します。

業界の黄金比：DECIMAL(19, 4)

通常、DECIMAL(19, 4) の使用を推奨します：

19：合計で19桁（精度）を保存できることを表します。
4：小数点以下に4桁を保持することを意味します。

なぜ小数点以下を4桁残すのでしょうか？利息、税率、為替レートの計算中の中間ステップでは、しばしば2桁以上の小数点が発生するためです。2桁のバッファを追加で確保することで計算の精度が高まり、ビジネスの要件に応じて最後に四捨五入するだけで済みます。

この容量なら、地球全体のGDPの合計をいくつか買えるほどです！

実際の金融シナリオで十分か？

DECIMAL(19, 4) を例に挙げます：

整数桁：15桁
最大金額：999,999,999,999,999
USD換算：約 999 兆ドル

参考値	金額
米国 GDP	約 27兆ドル
世界の GDP 合計	約 105兆ドル
世界の富の合計	約 454兆ドル

DECIMAL(19, 4) は、世界の富の合計をはるかに超える数値を収容でき、大多数の金融システムにとって完全に十分です。

主要データベースがサポートする最大 DECIMAL 精度上限

データベース	最大精度 (Precision)
MySQL / MariaDB	65
PostgreSQL	131072 (整数桁) + 16383 (小数桁)
SQL Server	38
Oracle	38

アーケードのトークン機：BIGINT 最小単位法

究極のパフォーマンスを追求している場合、またはStripeやAlipayのような超高並行処理が求められるシステムの場合、BIGINT（整数保存法） が最適な選択肢となるかもしれません。

このアプローチはアーケードのトークン機のようなものです：いくらお金を入れても、機械はそれを「最小単位」に換算して保存します。例えば：

100.50 米ドル → 10050（セント）として保存
100 台湾ドル → 100（元）として保存

なぜ BIGINT を選ぶのか？

理由	説明
超高速	整数の加減算はCPUの得意分野であり、計算性能は通常 `DECIMAL` よりはるかに高速です。
スペース効率	常に8バイトを占有し、超大規模なデータベースに非常に適しています。

ただし、欠点として可読性が悪いことが挙げられます。データベースを開いて 10050 を見たとき、頭の中（またはコード内）で自動的に100で割る必要があります。

究極の対決：どう選ぶべきか？

どちらを使用するかを決定するには、**「クエリ頻度」と「システム規模」**を考慮することができます：

比較項目	DECIMAL	BIGINT
可読性	非常に良い（数字を直接読める）	悪い（手動での換算が必要）
計算速度	普通	超高速
適用シナリオ	ERP、内部財務システム、一般的なEコマース	高頻度取引、超大規模マイクロサービス、StripeスタイルのAPI

実用的なアドバイス

適用シナリオ	推奨フィールド
一般的なEコマース、企業内部のレポートシステムで、会計士が監査のために直接SQLを実行する必要がある場合	`DECIMAL(19, 4)`
高頻度取引システム、または究極の拡張性が求められる場合	`BIGINT`

まとめ

一言で言えば、どちらを選ぶにせよ、金額を保存するのに FLOAT を使用することは絶対に、永久に禁止されています！ 正しいフィールドタイプを選択することで、システムが財務計算において盤石であることが保証されます。

MIT、ISC、Apache、GPLの違いとは？Vibe Codingでライセンスの落とし穴を避けるガイド

Mon, 23 Feb 2026 17:26:04 +0800

Vibe Coding中に開発をスピードアップするためにGitHubのオープンソースパッケージを使おうとして、たくさんのライセンスの略語に圧倒されていませんか？

もし「伝染性」のあるコードを会社の商用プロジェクトに誤って混ぜてしまうと、明日法務部からお茶に誘われるかもしれません。

主要なオープンソースライセンスの分かりやすい例え

1. MIT と ISC：屋台のおじさんのお気に入り

これらの2つのライセンスは、最も気楽な代表格と言えます。

簡単に言うと、自由に使え、変更でき、お金を稼ぐために商用ソフトウェアにすることさえできます。唯一すべきことは、原作者の名前や著作権表示を保持することだけです。

項目	説明
代表的なソフトウェア	ReactやVue.jsはどちらもこのタイプのライセンスを使用しています。
ISCとの違い	基本的に、ISCはMITのミニマリスト版であり、条項がより短くシンプルで、npmツールで非常に人気があります。

パッケージを開発して、素早く広め、みんなに使ってもらいたい場合は、この2つを選んでください！

2. Apache 2.0：特許保護付きのチェーン店

このライセンスもMITと同様に非常に寛容ですが、非常に強力な機能があります。それは特許保護の傘です。

大企業はこれを好みます！なぜなら特許のライセンスを明示的に規定しており、あなたが私のオープンソースコードを使用したなら、関連する特許のライセンスを自動的に取得し、特許の問題で私を勝手に訴えることはできないからです。

項目	説明
代表的なソフトウェア	TensorFlowやKubernetesのような大規模プロジェクト。

プロジェクトが比較的複雑で、将来の特許紛争を避けたい場合、Apache 2.0は非常に商用フレンドリーで安全な選択です。

3. GPL：原則を重んじる宣教師

ここに注意してください！GPLは恐ろしい「伝染性」を持っています！

もしプロジェクトがGPLパッケージを使用し、そのソフトウェアを外部に「リリース」した場合、プロジェクト全体もオープンソースにしなければならず、これにはコアコードも含まれます。

項目	説明
代表的なソフトウェア	Linux Kernel

クローズドソースの商用製品を開発する場合、GPLは絶対に避けるべきです！そうしないと、すべての企業秘密を公開しなければならなくなります。

4. LGPL と AGPL：特殊なシナリオ向けの変種

これら2つはGPLの親戚であり、異なる状況に適用されます：

項目	簡単な紹介	説明
LGPL	基盤コンポーネント向けの妥協版	これは通常、基盤となるライブラリに使用されます。「動的リンク（Dynamic Link）」経由で呼び出す限り、メインプログラムは感染せず、クローズドソースのままにできます。ただし、ライブラリ自体を変更した場合、変更された部分は依然としてオープンソースにする必要があります。
AGPL	クラウドサービス向けの特化版	これはクラウドSaaSサービス専用に設計されています。過去には、一部の企業が「ソフトウェアを『リリース』したわけではなく、サービスを提供するためにサーバーに置いただけだ」と言ってGPLの抜け穴を悪用していました。AGPLはこの抜け穴を塞ぎました。ネットワーク経由でサービスを提供する限り、それは使用とみなされ、オープンソースにしなければなりません！

商用プロジェクトにおける伝染性ライセンスの取り扱い

「もしGPLのものをどうしても使わなければならない場合、商用プロジェクトはどうすればいいですか？」

ここで、ソフトウェアエンジニアやアーキテクトの知恵を活用する時が来ます：

物理的隔離法

伝染性のあるオープンソースパッケージを、独立した「マイクロサービス（Microservice）」またはサイドカー（Sidecar）コンテナとしてラップすることができます。

メインプログラムが**それと直接一緒にコンパイルされない（つまり、静的リンク（Static Link）を行わない）**ようにし、APIまたはネットワークプロトコルを介してのみ通信するようにしてください。

これにより、コアの企業秘密が感染するのを防ぐための「法的ファイアウォール」を効果的に構築できます。

開発における落とし穴を避けるためのガイド

Vibe CodingやAI生成コードが飛び交う今日の世界では、コードを書く速度は上がりましたが、誤って有害なライセンスを混ぜてしまうリスクも急増しています。

CI/CDプロセスにおいて、デプロイ時に企業秘密を保護できないライセンスが含まれるのを避けるために、ソフトウェアライセンススキャンメカニズムを絶対に確立することを強くお勧めします。

また、非常に重要なことを1つ思い出させてください：オープンソースプロジェクトのLICENSEファイルを絶対に適当に削除しないでください！

ライセンスの使用シナリオの決定

シナリオ	推奨される選択肢
影響力を急速に広めることを目的とした個人開発	MIT または ISC
特許紛争を避けるために安定性を求める企業プロジェクト	Apache 2.0
クローズドソースの商用製品の開発	GPL を見たら逃げる

適切なライセンスを選択することで、安心してコードを書き、自信を持ってお金を稼ぐことができます！

Reference

Licenses - Open Source Initiative

Git Worktree と Git Branch の開発の違いとは？どんな状況で Git Worktree での開発が適しているのか？

Sun, 22 Feb 2026 09:30:00 +0800

新機能の開発を半分進めたところで、上司が突然急ぎのバグ修正を求めてきたら、どうしますか？

ほとんどの人は git stash を使って書きかけのコードを引き出しに押し込み、ブランチを切り替えてバグを修正するでしょう。

しかし、変更内容に大規模な環境設定が含まれていたり、ブランチの切り替えによって node_modules や ビルド成果物 (Build Artifacts) が相互に汚染されるような場合は、キーボードを叩き割りたくなるかもしれません。

そんなときこそ、Git Worktree が救世主となります！

Git Worktree とは？

Git の動きは「家のリフォーム」によく似ています。

従来の git branch では、ブランチを切り替えると部屋の家具が一瞬にして目の前から消え、別のタスクに合った配置に自動的に変わります。

スペースの節約にはなりますが、デメリットは**「環境汚染」**です。洗っていない食器を棚に片付けないと切り替えられませんし、切り替えた後も、前回の作業の油臭さが空気中に残っているかもしれません。

一方、Git Worktree は、隣の空き地に全く同じ家を建てるようなものです。

簡単に言えば、Git の根底にある原理は次のようになります：

「1つの魂 (.git データベース) と複数の肉体 (作業ディレクトリ)」。

「機能開発の支店」と「緊急修理の支店」を同時に持つことができます。左手でウィンドウAの AI ロジックを書きながら、右手でウィンドウBのバグを修正する。両者は互いに干渉しません。これこそが真の並行開発です。

Worktree 実践ガイド

開発中にフロー状態を維持するには、ディレクトリ構造と環境設定が鍵となります。

1. 並行ディレクトリ管理：本社の敷地内に支店を建てない

初めて Worktree を使う人の多くは、元のプロジェクトフォルダ内に新しいディレクトリを作ってしまいます。絶対にやってはいけません！Git が無限ループの混乱に陥ります。Git Worktree の正しい作り方は以下の通りです：

本店 (main) とタスク支店 (feature) は並行して配置する。

# 本店で Worktree の作成を実行しますが、Worktree のディレクトリは元のプロジェクトディレクトリの外に配置します
git worktree add ../my-app-feat-ai dev-branch

ディレクトリ構造は次のようになるはずです：

- my-project/       # 大きなパッケージ
  - main-repo/      # 安定した本店
  - feat-ai-search/ # 建設中の新しい支店

2. 環境設定の分離：各支店に独自の魂を与える

プロジェクトディレクトリが別々なので、.env 設定ファイルも分けることができます。

main では元の開発データベースを維持しながら、feat-ai-search ではテスト用データベースに接続することができます。こうすることで、ウィンドウを切り替える際に接続情報を変更する必要すらありません。

Worktree ディレクトリに入った後、その特定の Worktree ディレクトリの環境変数をそのまま使って開発を進めることができます。環境の切り替えや再構築は一切不要です。**「足を踏み入れた瞬間に仕事が始められる」**という感覚は、本当に素晴らしいものです。

Worktree のマージワークフロー

Worktree での開発を終えた後のワークフローは、従来のブランチと全く同じで、最後に「解体」というアクションが1つ追加されるだけです。

ワークフローステップ	説明
1. 支店でのコミット (Commit & Push)	承認するためには、物理的に支店に行く必要があります。
2. 本店の検査 (Merge)	`main` に戻ってマージするか、直接 Pull Request (PR) を開くことができます。
3. エレガントな解体 (Remove)	タスクが完了したら、フォルダを直接削除しないでください。Git コマンドを使って解体します：`git worktree remove ../feat-ai-search`

ドカーン！ 仮設の Worktree 小屋は撤去され、ディスクスペースは回収され、あなたの本店はピカピカのままです。

Worktree トラブル回避ガイド

Worktree は非常に便利ですが、注意すべき落とし穴がいくつかあります：

項目	説明
無闇に本店を移動しない	Worktree は絶対パスを記録しているからです。本店のディレクトリ名を変更すると、Worktree 支店は「魂」を見つけられずに死んでしまいます。
二重ブランチの禁止	同じブランチを2つの Worktree で同時にチェックアウトすることはできません。
お掃除ロボット `prune`	誤って `rm -rf` でフォルダを削除してしまった場合は、忘れずに `git worktree prune` を実行して `.git` に残っている記録を消去してください。

結論：Git Branch の使用をやめるべきか？

シナリオが異なれば、適した開発手法も異なります。どちらかが代わりになるという問題ではなく、どちらが適しているかという問題です。

シナリオ	説明
日常の小さな変更	引き続き `branch` を使ってください。軽快で高速です。
大規模なタスク	例えば、大規模なリファクタリング、複数の環境変数にまたがる調整、AIとの長期的な連携が必要なタスクなどには、Worktree を立ち上げるのが間違いなく最善の選択です。

Git Worktree は単なるコマンドではなく、私たちの開発のフロー状態を維持するための強力なツールです。次回、面倒で大規模なタスクに直面したときは、独立した 「Git Worktree 支店」 を開いて、これまでにないスムーズな開発プロセスを体験してみてください！

Reference

Git - git-worktree Documentation

pnpmがStoreディレクトリを見つけられない？外付けHDD開発でのstore-dirの変更方法

Thu, 19 Feb 2026 21:40:00 +0800

こんな状況に遭遇したことはありませんか？コンピュータの容量を節約するために、pnpmのstoreを外付けHDDに設定していたのに、ある日HDDを持ってくるのを忘れたり、保存場所を変えようとしたら、pnpmがディレクトリが見つからないというエラーを吐き始めたことは？HDDを挿し直しても何かおかしい？

これは実はpnpm独自の動作原理に関連しています。今日はpnpmの「Store」メカニズムと、それが「接続不能」になったときの救出方法についてお話ししましょう！

そもそもpnpmはどうやってスペースを節約しているの？

修正を始める前に、pnpmのスペース節約の魔法を簡単に復習しておきましょう。

各プロジェクトの node_modules にパッケージの完全なセットをコピーするnpmとは異なり、pnpmは Content-addressable store (コンテンツアドレス指定ストレージ) と Hard Links (ハードリンク) を使用します。

pnpmの仕組みは、すべてのパッケージファイルが実際にはコンピュータ内の 「巨大な倉庫」 にのみ存在し、プロジェクトディレクトリはこの倉庫へのリンクを持っているだけということです。これにより、ハードディスク容量を節約できるだけでなく、インストールも驚くほど高速になります。

項目	pnpm	npm
保存方法	グローバルストア + ハードリンク	プロジェクトごとに独立してコピー
容量使用	非常に低い (バージョンごとに1つのコピーのみ)	高い (重複コピー)
インストール速度	速い (リンクを作成するだけ)	遅い (解凍と書き込みが必要)

なぜ外付けHDDがpnpmのエラーを引き起こすのか？

ローカルSSDの容量を節約するためにpnpm storeを外付けHDDに設定すると、潜在的な落とし穴が現れます：

状況	説明
パス無効	HDDが接続されていない場合、pnpmは元々設定されていた `store-dir` を見つけられず、インストール時に直接エラーを報告して終了します。
ハードリンククラッシュ	ハードリンクはパーティションをまたぐことができないため、プロジェクトがドライブAにあり、ストアがドライブBにある場合、pnpmはコピーを使用することを余儀なくされ、これでは本来の利点が失われるだけでなく、キャッシュパスの乱れにより実行エラーが発生することさえあります。

このような状況に遭遇した場合、手動で「校正」する必要があります。

解決策1：校正し、Storeパスを再設定する

ストアの場所を変更することにした場合、最も直接的な方法は、新しいストアがどこにあるかをpnpmに伝えることです。次のコマンドを使用できます：

pnpm config set store-dir <新しいディレクトリパス>

例えば、pnpm storeをユーザーのホームディレクトリ下の ~/.pnpm-store に設定する場合：

pnpm config set store-dir ~/.pnpm-store

現在のストア設定がどこかわからない場合は、まず照会できます：

pnpm store path

設定が完了すると、pnpmは今後どこからパッケージを取得すればよいかがわかります。

解決策2：最初からやり直し、リンクを再構築する

パスを変更した後でも、プロジェクトに古い残留エラーが残っている場合があります。このとき、「最初からやり直す」のが通常最も効果的な治療法です：

手順	説明
1	プロジェクト内の `node_modules` フォルダを削除します。
2	`pnpm-lock.yaml` を削除します（パスに起因する奇妙なエラーの場合は、ロックファイルも再生成することをお勧めします）。
3	`pnpm install` を実行してリンクを再構築します。

これにより、最新の設定に基づいて、pnpmがストアからプロジェクトへ正しいリンクを強制的に引き直します。

どう配置するのが最もスムーズか？

異なる環境を行き来することが多かったり、外付けHDDの不安定さが心配な場合、理想的な構成はこれです：pnpm storeはローカルSSDに置き、プロジェクトコードを外付けHDDに置くことができます。

なぜでしょうか？ストアは通常それほど頻繁に変更されず、容量はあるものの、各プロジェクトに分散した総和はnpmよりはるかに小さいからです。ストアを安定したローカルパス（例：macOSのデフォルト ~/Library/pnpm/store）に保つことで、外付けHDDがなくても他の場所で新しいプロジェクトをスムーズに初期化できます。

この Stateless（ステートレス） な開発コンセプトにより、開発環境がより柔軟になります！

結論：Storeを安定させることが手間を省く

pnpm store管理の鍵は「安定性」という言葉にあります。パスの問題に遭遇した場合は、次のように対処できます：

手順	説明
1	まず `store-dir` 設定を確認し変更します。
2	古いパッケージをクリーンアップします：`pnpm store prune`（誰にも使用されていないパッケージファイルを削除し、HDDをスリム化するのに役立ちます）
3	パッケージを再インストールします `pnpm install`

この記事が、皆さんがpnpmのパスの落とし穴から抜け出し、高速開発の楽しさを享受する助けになれば幸いです！

Reference

Configuring | pnpm

EARSとBDDとは？Vibe CodingでAIに要件を即座に理解させるSpec-Driven Development (SDD)

Fri, 13 Feb 2026 15:55:00 +0800

Vibe Codingの開発プロセス中に、AIが生成したコードが論理的な抜け穴だらけで、修正しながら人生に疑問を感じたことはありませんか？

従来の開発では、仕様（Spec）が正義です。しかし、AIと協働する場合、私たちはより「監督」に近い存在です。

あの才能はあるけれど時々「暴走」するAI俳優に良い演技をさせるには、2つの強力なツールが必要です：EARS（脚本ロジック） と BDD（受け入れスチル） です。

EARS：要件を「論理ブロック」に変える

「システムをもっと使いやすくしてほしい」「処理速度を速くしてほしい」といった要件を書くPMに会ったことがあるでしょう。これはコードを書く際には災害です。

EARS (Easy Approach to Requirements Syntax) とは、簡単に言えば、これらの「曖昧な形容詞」を「正確な命令」に変換することです。

EARSはトップクラスのPrompt Engineeringのようなもので、閉じた論理で話すことを強制します。主要な5つの文型により、いつでも要件の境界を「ロック」できます：

タイプ	説明
Ubiquitous (普遍型)	`システムは...しなければならない`（呼吸のように、常に遵守する必要がある）。
Event-driven (イベント駆動型)	`[イベントが発生]したとき、システムは...しなければならない`。
Unwanted Behavior (望ましくない振る舞い)	`もし[悪いこと]が起きたら、システムは...しなければならない`（これがエラー処理の魂です）。
State-driven (状態駆動型)	`[特定の状態]の間、システムは...しなければならない`。
Optional Feature (オプション機能)	`[機能が含まれる]場合、システムは...しなければならない`。

EARSは厳格なルールを設定するのに役立ちます

AIが論理的に「真顔でナンセンスを話す」ことを不可能にします。

BDD：テストを「映画の脚本」に変える

EARSが厳格な契約書なら、BDD (Behavior Driven Development) は「血の通った物語」です。それは a == b をテストするのではなく、「ユーザーが何が起こったと感じるか」をテストします。

BDDで使用される構文は Gherkin（ピクルス、パリッとして爽やかであるべき！）と呼ばれ、核心となる三部作は以下の通りです：

構文	説明
🎬 Given (背景)	撮影前のシーン設定（例：ポケットに100ドル持っている）。
⚡ When (アクション)	監督がアクションと叫ぶ瞬間（例：激辛イカを注文した）。
✅ Then (結果)	観客が見る結末（例：香りの良いイカを受け取り、財布が60ドル減った）。

この「物語を語る」方法を通じて、エンジニアでなくても私たちとコミュニケーションがとれ、AIもこれらの「実例」を通してあなたの真の意図を理解できます。

EARS vs BDD の違いは何ですか？

これら2つはそれぞれの義務を果たし、組み合わせることで真に「無敵」になります。

特徴	EARS (要件構文)	BDD (振る舞い駆動)
核心精神	正確な定義 (曖昧さの排除)	合意と検証 (物語を語る)
書く感覚…	法的条項	映画の脚本
主な聴衆	PM、アーキテクト、ルール作成者	エンジニア、QA、AIアシスタント
解決する課題	「作ったものが思っていたものと違う！」	「ロジックは正しいが、使い物にならない！」

簡単に言えば：EARSはルールの設定を助け、BDDは結果の確認を助けます。

EARS 高度な応用：Vibe Coding 実践

私たちはEARSのルールとBDDの脚本を直接プロンプトに詰め込み、AIに開発させます。

「電子ウォレットの引き落とし」を開発する際、次のような指示を出してみてください：

# タスク：引き落としAPIの実装を手伝ってください

## EARS ロジック (厳密に遵守してください):
- [Event-driven]: リクエストを受信したとき、残高を検証しなければならない。
- [Unwanted]: 残高不足の場合、400エラーコード 'INSUFFICIENT_FUNDS' を返さなければならない。
- [State-driven]: ウォレットが 'Frozen' 状態の間、すべての引き落としを拒否しなければならない。

## BDD 受け入れスクリプト (Jestテスト用):
Scenario: 残高不足による引き落とし失敗
  Given ユーザー残高は 50 ドル
  When 100 ドルの引き落としリクエストを受信
  Then API は HTTP 400 を返すべき
  And エラーコードは 'INSUFFICIENT_FUNDS' であるべき

これをAIに投げてみてください。生成されるコードは目標から大きく外れることはありません！

結論

日常の開発であれVibe Codingであれ、EARSとBDDは効率を向上させるための神器です。

EARSは厳格なルールを設定するのを助け、BDDは演技の結果を確認するのを助けます。

GitLab Private NPM Registryの設定方法は？マルチパッケージと権限管理のベストプラクティス

Tue, 10 Feb 2026 15:40:00 +0800

会社のプロジェクトでプライベートパッケージ（Private Package）を使用する必要があるのに、.npmrcの設定で行き詰まっていませんか？

なぜTokenを設定したのに、まだ404 Not Foundが表示されるのでしょうか？

会社に複数のチーム、複数のパッケージ（例：@frontend、@backend）がある場合、.npmrcをどのように優雅に管理すればよいでしょうか？

.npmrcの2つの迷信を解き明かす

.npmrcを理解するには、まずそれがどのように機能するかを理解する必要があります。

簡単に言えば、その核心的なロジックは2つのことだけです：スコープマッピング（Scope Mapping）と認証（Authentication）。

1. スコープマッピング（Scope Mapping）

これはnpmに伝えています：@companyで始まるパッケージを見つけた場合、公式のnpmjs.orgを探さず、指定されたGitLab Registryを探しに行きます。

@company:registry=https://gitlab.com/api/v4/groups/100/-/packages/npm/

2. 認証（Authentication）

アドレスがあっても、鍵が必要です。鍵はあなたのAuthTokenです。

ここに非常に重要なルールがあります：Registry URLとAuthTokenのパスは「完全に一致」しなければなりません。

# ✅ 正しい：パスは上で定義されたregistryと完全に同じです
//gitlab.com/api/v4/groups/100/-/packages/npm/:_authToken=${GITLAB_TOKEN}

# ❌ 間違い：パスが一致しないため、権限エラーが発生します
//gitlab.com/api/v4/:_authToken=${GITLAB_TOKEN}

多くの人が設定に失敗するのは、パスにスラッシュが多かったり、階層が少なかったりするためです。

依存関係地獄と404エラー

最も頭の痛い状況はこれです：パッケージAをインストールした結果、それがパッケージB（これもプライベート）に依存しており、npmが404 Not Foundを吐き出す場合です。

なぜこうなるのでしょうか？それは、正しい対応関係がない場合、npmは依存関係を解決する際に迷子になるからです。

特に、異なるGitLab Groupに2つの異なるスコープ（例：@team-aと@team-b）がある場合、.npmrcは非常に複雑で保守が難しくなります。さらに、異なるRegistryには異なるTokenが必要な場合があり、これらの環境変数を管理するだけで手一杯になります。

もっと賢い方法はあるのでしょうか？

推奨ソリューション：統一ダウンロードGroup Registry & 独立公開Project Registry

Registry	説明
Group Registry	すべてのパッケージのダウンロードを統一するために、Group Registryを設定して、このGitLab Group配下のすべてのパッケージをダウンロードします。
Project Registry	公開時に権限を持つために、各プロジェクトは独自のProject Registryを設定して公開できます。

なぜそうするのか？

理由	説明
インストールが簡単	同じグループ内のすべてのパッケージを簡単にインストールしてダウンロードできます。
公開が簡単	パッケージをそれぞれのプロジェクトに簡単に公開でき、異なるパッケージが同じRegistryに公開されるのを避け、各プロジェクトが独自のRegistryを持ちます。
Token管理が容易	開発者のコンピュータでもCI/CD環境でも、`GITLAB_NPM_TOKEN`の1セットを維持するだけで済みます。
依存関係エラーの回避	すべてのプライベートパッケージが同じ場所にあるため、npmが見つけられないことは絶対にありません。

設定の実践

このテンプレートを直接コピーできます：

Tokenを保護する作業は環境変数に任せ、絶対にコードに直接Tokenを書かないように覚えておいてください！

# .npmrc
# 汎用ドメインレベルのauth token（すべてのgroupおよびprojectレベルのインストールリクエストをカバー）
//gitlab.com/:_authToken=${GITLAB_NPM_TOKEN}

# 公開用：project-level auth token（npm publishは正確なパス一致が必要）
//gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/:_authToken=${GITLAB_NPM_TOKEN}

# @company scopeはgroupレベルのregistryを使用
# すべての @company/* パッケージはこのregistryからインストールされます
@company:registry=https://gitlab.com/api/v4/groups/YOUR_GROUP_ID/-/packages/npm/

# その他の公開パッケージは公式ライブラリに行きます
registry=https://registry.npmjs.org/

package.jsonでpublishConfigを設定し、パッケージを対応するGitLab Project Registryに公開します。

{
  "name": "@company/my-package",
  "publishConfig": {
    "@company:registry": "https://gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/"
  }
}

結論

**「統一ダウンロードGroup Registry」と「独立公開Project Registry」**の戦略を通じて、保守コストを大幅に削減し、開発プロセスをスムーズにすることができます。

目標	説明
正確なマッチング	ScopeマッピングとTokenパスは完全に一致していなければなりません
安全第一	環境変数`${GITLAB_NPM_TOKEN}`を活用してプライベート情報を管理します
集中管理	統一されたGitLab Groupを優先的に使用して、会社のすべてのプライベートパッケージを`ダウンロード`します
独立公開	独立したGitLab Projectを優先的に使用して、それぞれのプライベートパッケージを`公開`し、混乱を避けるためにそれぞれのパッケージを独立して管理します

これらのロジックを習得すれば、GitLab NPM Registryは会社の開発プロセスにおける強力な助っ人になります！

npxとは？なぜインストールせずにパッケージを実行できるのか？

Sun, 08 Feb 2026 14:45:00 +0800

ツール（create-next-appやeslintなど）を実行するためだけに、npm install -gを使ってインストールしなければならなかったことはありませんか？時間が経つにつれ、いつインストールしたかわからない古いバージョンのグローバルパッケージが積み重なり、環境が散らかってしまいます。

もし、以下のような方法でパッケージ機能を実行できるとしたらどうでしょう。

目標	説明
最新バージョンの使用	必要な時だけツールの最新バージョンを呼び出す
容量を取らない	使い終わったら捨てる、不要な時は全く容量を取らない

これこそが、npxの登場する場面です。

npxの核心概念：プログラミング界の「フラッシュモブ」

今日、火鍋を食べたいと想像してください。

モード	説明
`npm install`	鍋、フライパン、コンロ、スープの素をセットで購入（ローカルまたはグローバルに保存）。食べたい時はいつでも使えますが、キッチンのスペースを占領し、長く洗わずに放置するとカビが生えます（バージョンが古くなる）。
`npx`	「フラッシュシェフ」に電話して道具を持って家に直接来てもらい、この食事を作って、鍋を洗って、撤退してもらいます。キッチンは綺麗なままで、毎回シェフが最新のスープの素を持ってくることが保証されています。

この「レンタルのみ」のモードは、まさにVibe Codingの精神を体現しています：

環境をミニマルに保ち、常に最新バージョンを使用し、散らかった環境の維持ではなく、価値の創造にエネルギーを集中する。

検索ロジック：単なるダウンロードと実行ではない

npx <パッケージ名>と入力すると、「実行可能プログラムの検索」プロセスロジックが開始されます：

プロセス	説明
1. まず家の中を確認	プロジェクトローカルの`node_modules/.bin`またはグローバル環境にそのコマンドが既に存在するか確認します。
2. なければ取得	見つからない場合、自動的にnpmレジストリに行って「一時バージョン」を取得します。
3. 実行後は廃棄	コマンド実行後、このパッケージはコンピュータに残って場所を取りません。

これはローカルプロジェクトパッケージを実行する時に特に顕著です。以前は./node_modules/.bin/tailwind-cliを実行しなければならず、パスが長すぎて泣きたくなるほどでしたが、今はプロジェクトルートで颯爽とタイプするだけです：

npx tailwind-cli build

それはあなたがプロジェクトに何をインストールしたかを知っていて、実行のためにパスを直接合わせてくれる気が利く執事のようです。

npxはどうやってどのパッケージコマンドを実行するかを知るのか？

npx skills add vercel-labs/agent-skillsのようなコマンドで、npxがどうやって単語一つからクラウドコードを見つけるのか不思議に思うかもしれません。

これはパッケージ内のpackage.jsonという身分証明書のおかげです。パッケージ設定で、開発者はbinフィールドを定義します：

{
  "name": "skills",
  "bin": {
    "skills": "./bin/cli.mjs",
    "add-skill": "./bin/cli.mjs"
  }
}

これはパッケージの「外部ウィンドウ」として機能します。あなたがnpx skillsを呼び出すと、以下のことが起こります：

ステップ	説明
1	`npx`はnpmレジストリに行って`skills`という名前のパッケージを探します
2	その`bin`に登録されたスクリプトを実行します。

「どうやって家を建てるか（addパッケージインストール）」については、このパッケージ（skillsパッケージ）の専門技術です。

上級テクニック：名前とコマンドが一致しない？

パッケージ名がtools-packageなのに、コマンドがrun-meという名前だったらどうしますか？あるいは、テストのために特定の古いバージョンを指定したい場合は？

この時点では自動操縦に頼るのをやめ、「パッケージ指定」の方法に切り替えます：

npx -p tools-package@1.5.0 run-me "Show me the way"

コマンド	説明
`-p tools-package@1.5.0`	`npx`にこの特定のパッケージを取得してくるように伝えます。
`run-me`	これが実行したいコマンドです。

結論

npxは私たちがCLIツールを使う習慣を完全に変えました。開発者がより軽量で柔軟な方法でツールを管理でき、複雑な環境設定に縛られることがなくなります。

この「どこにでもあり、いつでも呼び出せる」エレガントなプロセスにより、Vibe Codingのリズムで迅速、正確、かつ容赦なくタスクを完了することができます！

Reference

OpenClaw 創設者 Peter Steinberger インタビュー：アプリが融解するとき、「ロブスター」はどのように個人の AI エージェント革命を巻き起こすのか？

Sat, 31 Jan 2026 17:44:20 +0800

Full Interview: Clawdbot’s Peter Steinberger Makes First Public Appearance Since Launch

「世界で最も高価な目覚まし時計」 から始めましょう：あなたは自分の AI に 「私を驚かせて (Surprise me)」 とあえて言えますか？

OpenClaw の創設者 Peter Steinberger はそれを試しました。その結果、彼の AI エージェントは

真夜中に勝手に彼のコンピュータに SSH でログインし、音量を最大にして彼を起こしました。

失敗した SF 映画のプロットのように聞こえますが、これは燃え尽き症候群から復帰した元エンジニアの身に起こったことです。

これは単なるいたずらの話ではありません。私たちがどのように 「ソフトウェア」を再定義しているか という物語です。

このプロジェクトはわずか数ヶ月の間に3回名前を変えました。最初は Claude に敬意を表した Clawdbot、次にロブスターの脱皮と成長を象徴する Maltbot、そして最後に開放性とコミュニティを象徴する OpenClaw です。マスコットのロブスターのように、このプロジェクトは脱皮と成長を続け、最終的に GitHub で最も注目される「AI Agent」プロジェクトの一つ となりました。

アプリは融解する (Apps will melt away)

スマートフォンにいくつのアプリが入っているか数えたことはありますか？レストランの予約、配車、家計簿、天気の確認など、私たちは無数のインターフェースを切り替える必要があります。

Peter は核となる哲学を提唱しています：

アプリの融解 (Apps will melt away)

簡単に言えば、将来の AI 時代には、問題を解決するために特定のアプリを必要としなくなります。API と強力な AI Agent を通じて、ニーズを伝えるだけで、AI Agent がすべてを処理してくれます。

例えば、食べ物の写真を撮ると、AI Agent が自動的にカロリーを調べ、健康データベースに記録してくれます。カロリー記録アプリを開く必要は全くありません。

AI エージェントは実は Unix をよく知っている

あなたがエンジニアなら、現在の AI ツールがしばしば派手なグラフィカルユーザーインターフェース (GUI) を備えていることに気づくかもしれません。

しかし Peter は、AI が実は最高のシステム管理者であることに気づきました。彼らにきれいなボタンは必要ありません。必要なのは：

黒地に白文字のターミナル (CLI)
明確なヘルプメニュー

これが OpenClaw が異なる道を選んだ理由です：

エージェントは Unix を知っている (Agents know Unix)

既存の Unix ツールと CLI コマンドを活用することで、AI エージェントはより柔軟に機能を組み合わせることができ、どの GUI ツールよりも強力で拡張性が高くなります。

午前3時にコーディングのときめきを取り戻す

Peter はこの開発スタイルを 「Vibe Coding」 または 「VIP Coding」 と呼んでいます。

彼は午前3時に AI と協業することがどのような感じか説明しています：

もはや苦痛なデバッグではなく、純粋な創造です。

AI 生成コードを受け入れることで、彼はコーディングの本来の喜び (Mojo) を取り戻しました。ここでは、AI が実装の詳細を処理してくれるため、コードそのものよりもアイデアが重要になります。

OpenClaw は 「ローカルファースト (Local-first)」 を強調しています。個人データのプライバシーが重視される今日、自分のハードウェア（Mac Mini など） 上で AI エージェントを実行できるということは、自分のデータを完全に管理できることを意味します。

大手テック企業の形式主義 (Red Tape) を回避し、真の個人データ主権を取り戻すのです。

これはスタートアップではなく、「ハッカーの遊び場」です

OpenClaw がバズった後、無数の VC (ベンチャーキャピタリスト) が小切手を持って投資を申し出ました。しかし Peter は拒否しました。なぜでしょうか？

彼はすでに経済的自由を得ているからです。このベンチャーは金のためではなく、「楽しさ」と「インスピレーション」 のためのものです。

彼は非営利財団を設立し、たった一つの目標を掲げました。このプロジェクトが 「彼よりも長生きする (Outlive him)」 ことです。

彼は OpenClaw が、商業的利益に乗っ取られたツールではなく、Linux のような公共財になることを望んでいます。

セキュリティに対して正直であること

セキュリティ問題を隠そうとする商業企業とは異なり、Peter は 「プロンプトインジェクション (Prompt Injection)」 が AI エージェント分野における未解決の謎であることを公然と認めています。

彼は OpenClaw を 「ハッカーの遊び場」 と位置づけ、世界中のセキュリティ専門家にそれを「解体」し、攻撃するよう呼びかけています。この極端な透明性とコミュニティの協力によってのみ、私たちは真のセキュリティへの道を見つけることができるのです。

さらに興味深いのは、商業化に対する彼の戦略です：

「極限の品質」で「商業化」に対抗する

オープンソースプロジェクトが悪意を持って転売されるのを防ぐ最善の方法は、

無料のオープンソース版をあまりにも良くしすぎて、誰もパッケージ化して金を稼げないようにすること

です。これは非営利の精神だけが成し得る圧倒的な態度です。

結論：私たちはソフトウェア開発のパラダイムシフトを目撃している

OpenClaw は単なるツールではありません。それは 「誰もが開発者になる」 未来を予示しています。

自然言語を通じて、私たちは皆、独自の問題を解決するための自分専用のソフトウェアツールを構築できます。

このロブスター (OpenClaw) は脱皮を終え、アプリの融解と個人データの自律という新しい時代へ私たちを導く準備ができています。

Peter のビジョンは、未来のソフトウェア世界が少数の大企業によって定義されるのではなく、私たちユーザー一人一人によって手作りされるべきだと教えてくれています。

あなたは あなた自身の「カスタマイズされた」AI エージェント を育てる準備はできていますか？

Reference

Full Interview: Clawdbot’s Peter Steinberger Makes First Public Appearance Since Launch

LSP (Language Server Protocol) とは？AI時代の開発フローをよりスムーズにする「万能翻訳官」

Wed, 14 Jan 2026 10:48:28 +0800

VS Code から Cursor に切り替えたばかりの時、環境が変わることで「脳」まで入れ替わったような感覚になり、様々な構文プロンプトに再び適応しなければならなかった経験はありませんか？あるいは、最新の AI コーディングツールを試している時に、AI は強力だけれど「開発のリズム」が足りないと感じることはないでしょうか？

実は、これらすべての裏側には、現代の開発環境を統一した神秘的な功労者が隠れています。それが —— LSP (Language Server Protocol) です。

想像してみてください：翻訳官と各国の厨房 👨‍🍳

以前私たちがコードを書いていた頃、IDE を変更する（Eclipse から VS Code に切り替えるなど）ことは、中華料理の厨房からフランス料理の厨房に引っ越すようなものでした。中華料理の厨房の副料理長（構文プロンプト）は中国語しか理解できず、フランス料理の厨房の副料理長はフランス語しか理解できませんでした。もしフランス料理の厨房で「豚の角煮」を作りたければ、その副料理長に醤油の識別方法から教え直さなければなりませんでした。

これが従来のアプローチでした：すべてのエディタが、すべてのプログラミング言語のために専用の「脳」を構築しなければならなかったのです。これは開発者にとってもツール制作者にとっても、非常に大きな負担でした。

LSP (Language Server Protocol) は、この問題を解決するための「万能翻訳プロトコル」として誕生しました。

想像してみてください。今ではすべての厨房（エディタ）が独自の副料理長を抱えるのをやめました。代わりに、「中央コンサルティングセンター」（Language Server）に電話をかけるようになったのです：

VS Code で user. と入力すると、VS Code はセンターにメッセージを送ります：「ねえ、これは User オブジェクトだけど、次は何が続くかな？」
コンサルティングセンターはデータを確認して返事を出します：「ああ！それは .getName() か .getEmail() が続くよ。」

VS Code、Vim、あるいは現在最も注目されている AI エディタ Cursor を使っていても、全員が「同じ電話用語セット」（LSP）を話してさえいれば、すべてのエディタが一瞬にして非常にスマートになります。

LSP の仕組み：エディタ界の分散型アーキテクチャ

技術の専門家であるあなたなら、多くのマイクロサービス API の統合を扱ったことがあるでしょう。実は、LSP はエディタ界の分散型アーキテクチャのようなもので、「表示インターフェース」を「構文解析」から完全に切り離しています：

コンポーネント	役割	説明
クライアント (フロントエンド)	エディタ / IDE	画面の表示、キーボードイベントの受信、ユーザーインターフェースの処理を担当します。
サーバー (バックエンド)	Language Server	構文解析、論理演算、型チェックを担当します。
通信ブリッジ	JSON-RPC	双方が対話できるようにするための標準的な通信プロトコルです。

このアーキテクチャにより、開発ツールのメンテナンスは非常にシンプルになります。以前は $M$ 個のエディタと $N$ 個の言語があれば $M \times N$ 個の実装が必要でしたが、今では各言語に 1 つのサーバーを書くだけで、何千ものクライアントをサポートできます。

Vibe Coding にとって、LSP とは何か？ 🎸

Vibe Coding（感覚でコーディングする）というトレンドの中で、私たちはインスピレーションの流動性を追求しています。あなたは AI にこう言っているかもしれません：「検証機能付きの注文処理 API の作成を手伝って。」

この時、LSP の役割はむしろプロの「カメラアシスタント」に近いものとなります：

リアルタイムのエラー修正（赤い波線）：AI がコード生成を手伝ってくれる際、LSP はバックグラウンドですぐに構文エラーをキャッチします。それはまるで、あなたがシーンを演出（Vibe Coding）している最中に、全体の「雰囲気」だけを気にしているときでも、LSP が「監督、このランプ（変数）のコンセントが抜けていますよ！」と教えてくれるようなものです。
定義へ移動 (Go to Definition)：関数の動作が「感覚的に」おかしいと感じたとき、ワンクリックでそこへ飛ぶことができます。これにより、ディレクトリツリーを何時間も手動で探すことなく、異なるファイル間を素早く飛び回り、開発のリズムを維持できます。

結論：開発をツールのなすがままにさせない

簡単に言えば、LSP は開発ツール界の「大統一理論」です。開発者が単一のツールに縛られることから解放し、AI 支援による開発をより安定させ、リズムのあるものにします。

次に新しいツールに切り替えて、あのおなじみの赤い波線や正確な構文補完を目にしたときは、バックグラウンドで黙々と働いているこの 万能翻訳官 に感謝することを忘れないでください！

会社のプライベートNPMパッケージをGitLabに公開する方法は？pnpm完全設定ガイド

Sun, 11 Jan 2026 21:15:00 +0800

想像してみてください。あなたは一流のシェフです。チェーン展開するすべてのレストランで同じ美味しい料理を提供するために、一連の「秘密のソース」を開発しました。これらのソースを各店舗に届けたいと考えていますが、通りすがりの人に勝手に持ち去られるわけにはいきません。

コンピュータソフトウェア開発の世界では、これらの秘密のソースは**社内の「プライベートパッケージ」**にあたります。

プロジェクトが増えるにつれ、次のような不満を感じたことがあるはずです。同じUIコンポーネントやユーティリティ関数をすべてのプロジェクトでコピー＆ペーストしたり、Git Submoduleで人生の選択を疑うほど苦労したりすることです。実際、必要なのは「プライベートパントリー（プライベートNPMレジストリ）」だけです。今日は、pnpmを使用してパッケージをGitLabに公開する方法について説明します。これにより、チームメンバーはオープンソースパッケージと同じように、コマンド一つでこれらをインストールできるようになります。

なぜプライベートパッケージとスコープが必要なのですか？

Node.jsの世界では、プライベートパッケージには「苗字」が必要です。これがスコープ（Scope）です。

例えば、会社の名前が @my-company の場合、パッケージ名は @my-company/ui-kit のようになります。この苗字があれば、pnpm はあてもなく npmjs.org を探すことはありません。代わりに、指定された会社の座標へ直接向かいます。

重要な決定：グループレベル vs プロジェクトレベル

GitLabでは、これは調味料をどこに保管するかを決めるようなものです。

レベル	説明
プロジェクトレベル	シェフの個人的な金庫のようなもので、特定の料理にのみ使用できます。各パッケージに独立した設定が必要なため、設定が面倒です。
グループレベル	これは「セントラルキッチン」のコンセプトであり、強くお勧めします！一度設定すれば、同じグループ内の数十、あるいは数百のパッケージが同じ設定と認証情報を共有できます。

「パスポート」の設定：アクセストークンと環境変数

地下の食料庫に入るには、まず「入室カード」を取得する必要があります。

GitLabの Settings > Access Tokens に移動します。
トークンを申請し、read_api（ダウンロード用）と write_package_registry（公開用）の権限にチェックを入れます。
重要： トークンを取得したら、コードや .npmrc ファイルに直接ハードコードしないでください！それは金庫の鍵をドアに差しっぱなしにするようなものです。

最もプロフェッショナルな方法は、それを「環境変数」に隠すことです。MacまたはLinuxのターミナル（例：~/.zshrc）に次の行を追加します。

export GITLAB_TOKEN="あなたのGitLabトークン"

これにより、システムが自動的に認証情報を付加してくれるため、安全で便利です。

ナビゲーション設定：`.npmrc` の極意

次に、プロジェクトのルートにナビゲーションマップである .npmrc を作成し、pnpmにどこへ行くべきかを伝えます。

# @my-company で始まるものはすべて GitLab に送信します
@my-company:registry=https://gitlab.com/api/v4/groups/<YOUR_GROUP_ID>/-/packages/npm/

# 入室カードの認証を設定します（先ほど設定した環境変数を読み取ります）
//gitlab.com/api/v4/groups/<YOUR_GROUP_ID>/-/packages/npm/:_authToken="${GITLAB_TOKEN}"

会社のグループIDを入れ替えるだけで、道が開けます！

公開前の最後の1マイル：パッケージングの芸術

接続を設定した後、急いで公開して、誤ってテストファイルや秘密の設定までアップロードしてしまう人が少なくありません。ここで package.json の files フィールド が役に立ちます。

これは「ホワイトリスト」の考え方です。

{
  "name": "@my-company/lib-1",
  "files": [
    "dist"
  ],
  "publishConfig": {
    "registry": "https://gitlab.com/api/v4/projects/<YOUR_PROJECT_ID>/packages/npm/"
  }
}

設定	説明
`files`	システムに対し、`dist` 内のコンパイルされた要点のみを公開し、他の不要なものはすべて残すように明示的に伝えます。
`publishConfig`	これは二重の保険であり、このパッケージが誤って公海（npmjs.org）に公開されないようにします。

公開する前に、pnpm pack コマンドを使用してローカルで内容を確認することをお勧めします。すべて問題なければ、自信を持って pnpm publish を実行しましょう！

まとめ

プライベートパントリーを作成するのは難しくありません。鍵となるのは以下の点です。

トークンを申請し、環境変数で保護する。
正しい .npmrc ナビゲーションマップを設定する。
package.json の files フィールドを使用して正確に出荷する。

このワークフローをマスターすることで、会社のコードの再利用をプロフェッショナルかつ安全でエレガントなものにできます。さあ、あなた自身のセントラルキッチンを作りに行きましょう！

Reference

パッケージバージョン管理とSemVer完全ガイド：package.jsonのバージョン番号は何を意味するのか？

Sat, 10 Jan 2026 22:50:00 +0800

package.jsonに^0.0.3と書いたのに、pnpm updateを実行しても、最新版が0.1.0なのにパッケージが全く動かない、という経験はありませんか？pnpmが壊れているのか、それとも「現状維持」ごっこをしているのでしょうか？心配しないでください、あなたは一人ではありません。これは実はソフトウェアの世界における「安全保険メカニズム」なのです。

X.Y.Zの暗号を解読する：改造車のスペック

車のパーツを交換することを想像してみてください。バージョン番号X.Y.Z（例：1.2.3）は、この車の更新リストのようなものです：

フィールド	概要	説明
X	メジャー変更	これはエンジンの交換のようなものです。交換後、以前の運転習慣を完全に変える必要があったり、ハンドルの位置さえ変わるかもしれません。これが「破壊的変更（Breaking Changes）」と呼ばれるものです。
Y	新機能	これはバックモニターの取り付けのようなものです。機能は強化され、物も増えましたが、元の運転方法には全く影響しません。痛みを伴わないアップグレードです。
Z	修正	これは単なるタイヤのパンク修理やワイパーの交換です。純粋なバグ修正です。バージョン番号を見なければ、更新されたことに気づかないかもしれません。

記号の契約精神：保険代理店の「安全契約」

package.jsonに書く記号は、コードが時代についていくか、その場で爆発するかを決定します。このルールセットをリフォーム契約として想像してみましょう：

記号	例 (`1.2.3`)	アップグレード範囲	ベテランの平易な言葉
記号なし	`1.2.3`	固定 1.2.3	一途：この特定のバージョンが欲しい、ネジ一本も変えてはならない。
チルダ `~`	`~1.2.3`	< 1.3.0	微調整：バグ修正（Z）のみ許可、新機能は許可しない。
キャレット `^`	`^1.2.3`	< 2.0.0	機能解禁：機能追加（Y）は可能だが、エンジン（X）は変えないで。

特別な注意：なぜ `0.x.x` はpnpmを保守的にさせるのか？

これが、あなたの^0.0.3が上がらない理由です！バージョン番号が1.0.0に跳ね上がる前、これは開発界では「草創期」と呼ばれます。

保険代理店（pnpm）は非常に保守的になります：彼は0.0.xのすべての更新が大刷新になる可能性があると考えています！ だから^0.0.3は0.0.4への更新しかあえてせず、0.1.0へ越えることさえしません。アップグレードしたい場合は、手動でpackage.jsonを修正するか、強制的な手段を使う必要があります。

ベテランの追い越しテクニック：強制アップグレード

自動更新が失敗した場合、または最新版へ「突っ走りたい」と確信している場合は、これら2つの手を使えます：

方法	内容
直接指名法	`pnpm add some-package@latest`と入力します。これは監督が直接「最新のあの俳優を連れてこい！」と命令するようなものです。
対話的選択法	`pnpm update --interactive`（または `pnpm up -i`）と入力します。これは更新可能なすべてのパッケージをリストアップし、メニューを見るように選ばせてくれます。

ただのレシピではなく、冷凍食品パック：pnpm-lock.yaml

チーム開発において、pnpm-lock.yamlはあの**「変更してはならない家伝の秘法」**です：

ファイル	内容
`package.json` (レシピ)	「小麦粉、卵が必要」と書いてあります。しかし、ブランドや産地は書いてありません。みんなが作った味（環境）はずれてしまうでしょう。
`pnpm-lock.yaml` (冷凍食品パック)	すべての食材の産地と重量を正確に記録しています。チームメイトが`pnpm install`を実行すると、全く同じ冷凍食品パックを開けるようなもので、「雰囲気（Vibe）」が完全に一致することを保証します。

「玉突き事故」（Lockファイル競合）に遭遇した時

競合マーカーを手動で修正してはいけません！それは機械が読み取るハッシュ値でいっぱいです。最も優雅な方法は、直接これを実行することです：

pnpm install

pnpmは自動的に両側の要件を読み取り、完璧で真新しい契約を再計算します。

結語

バージョン番号をマスターするのは試験のためではなく、開発環境を「盤石」にするためです。次回バージョンが上がらないときは、人生を疑うのではなく、あなたはもう免許を持ったベテランなのだと思い出してください！

Agent Skills とは？『マトリックス』のように、AI エージェントが専門能力を瞬時に「ダウンロード」できる拡張パック

Sat, 10 Jan 2026 17:02:54 +0800

映画『マトリックス』で、主人公のネオが「カンフー」のスキルを瞬時にダウンロードするシーンを覚えていますか？あるいは、自分の AI アシスタントがアプリをインストールするように、さまざまな専門能力をプラグアンドプレイで使用できたら、どれほど便利か想像してみてください。

これこそが、Agent Skills が解決しようとしている課題です。

それはどのような見た目ですか？

端的に言えば、それはフォルダです。

このフォルダの魂は SKILL.md ファイルであり、人間と AI の両方が理解できる Markdown 形式で書かれています。中には、AI が理解するための指示だけでなく、コードスクリプト (scripts/)、参照ドキュメント (references/)、および各種テンプレートリソース (assets/) を含めることもできます。

この一連の標準は、Anthropic によって開始され、維持されているオープンな形式であり、AI エージェントの能力を「モジュール化」および「標準化」することを目的としています。

それはどのように動作しますか？（段階的開示の知恵）

AI がこれほど多くのスキルを背負い込むと、コンテキスト (Context) が爆発してしまうのではないか、という疑問を持たれるかもしれません。

これが Agent Skills の優れた点であり、「段階的開示」という戦略を採用しています。

戦略	説明
発見 (Discovery)	起動した直後、AI はスキルの「名称」と「概要」のみを読み取ります。メニューを見るのと同様に、その料理があることは知っていますが、すぐに完全なレシピを知る必要はありません。
有効化 (Activation)	関連する質問をすると、AI は特定のスキルがニーズに合致していることを発見し、そこで初めて詳細な `SKILL.md` の指示を読み取ります。
実行 (Execution)	詳細な指示を読み終えた後、AI は説明書を持っているかのように、一歩ずつタスクを実行し、困難な問題を解決するために付属の Python スクリプトを呼び出すことさえあります。

なぜ Agent Skills が必要なのですか？

従来の AI への指示は、通常、ハードコードされていたり、ランダムに配置されたりしていました。Agent Skills は、2 つの核となる利点をもたらします。

利点	説明
汎用性 (Write once, use everywhere)	「PDF 処理スキル」を一度作成すれば、Claude Code で使用でき、この標準をサポートする他のエージェントでも動作します。
ポータビリティ	企業にとって、これは非常に価値のあるものです。会社の専門知識（例：経費精算規定、休暇申請手順）をスキルとしてパッケージ化できます。新任の AI アシスタントは、このスキルを読み込むだけですぐに業務を開始でき、的外れな回答をすることはありません。

これは従来の Tools や Functions と何が違うのですか？

これは最も頻繁に受ける質問です。

一般的なツールは、AI にドライバー (API) を渡すようなものです。それはネジの回し方は知っていますが、いつ回すべきか、あるいは何回転させるべきかは知りません。

しかし、Agent Skills は、「施工ガイド」と一式揃った「工具箱」の組み合わせに近いものです。単にツールを提供するだけでなく、「手続き的知識 (Procedural Knowledge)」――つまり、複雑なタスクを完了するために、AI がこれらのツールを論理的に使用する方法を教える SOP が含まれています。

生活に即した例を挙げましょう

「コーヒーマスター」スキルを作成したい場合、フォルダ構造は次のようになります。

SKILL.md：「ラテなら、手順は A -> B。ハンドドリップなら、水温 C に注意」と書かれています。
scripts/timer.py：AI がハンドドリップの秒数を計測するためのスクリプト。
references/beans.md：さまざまなコーヒー豆の産地と風味の対照表。

このスキルパックがあれば、あなたの AI アシスタントは、コーヒーを学んだことがなくても、瞬時にコーヒーの達人になれます！

まとめると

Agent Skills は、標準を確立しようとしています。それにより、オープンソースソフトウェアのように、AI の能力が共有され、流通できるようになります。

役割	利点
開発者	開発者にとって：一度書けばどこでも使え、車輪の再発明をする必要がありません。
企業	企業にとって：知的資産を資本化し、AI の回答の正確性を確保できます。
ユーザー	ユーザーにとって：あなたの AI はますます賢くなり、さらに「あなたのニーズに合わせて」カスタマイズされた賢さを手に入れます。

これは完全にオープンソースの標準です。今すぐ GitHub をチェックして、最初のスキルの構築を始めましょう！

参照 (Reference)

Node.js パッケージマネージャー：npm, yarn, pnpm, bun どれを選ぶべき？それぞれのメリット・デメリット、違いとは？

Wed, 07 Jan 2026 20:30:00 +0800

前書き

Node.js エコシステムに足を踏み入れると、一瞬で「戦国時代」のような混乱に陥るかもしれません。npm, yarn, pnpm、そして最近話題の bun……一体何が起きているのでしょうか？なぜこれほど多くのパッケージマネージャーが必要なのでしょうか？

これは、チェーン展開するファストフード店を開くようなものです。プロジェクトの開発は新しいメニューの研究であり、パッケージマネージャーはあなたの調達・物流システムです。初期の Node.js はあまりにも早く発展しすぎたため、元祖の npm は荷物を運ぶことはできても、配送が遅く、倉庫（node_modules）は乱雑で、しばしばストレージを圧迫していました。

この「物流大戦争」を整理するために、最適な「物流プロバイダー」を見つけるための決定ガイドをまとめました。

4つの物流巨人：あなたのベストなエクスプレスはどれ？

まずは 4 人の選手の個性を一目で把握できるよう、対決表を見てみましょう。

ツール	正体と個性	必殺技 (Pros)	弱点 (Cons)
npm	元祖村長。どこの家にもある。	Node.js に標準搭載。インストール不要。	旧バージョンは遅い。倉庫の構造が迷路のよう。
Yarn	エリート配送員。npm の遅さを解消するために誕生。	速度が速い。並列ダウンロード。厳格な `yarn.lock`。	優位性が徐々に追いつかれ、立ち位置がやや微妙に。
pnpm	空間の魔術師。ディスク容量の救世主！	ディスク容量を大幅に節約。非常に高速。	シンボリックリンク構造。極一部の古いパッケージで問題が出ることも。
Bun	テスラを乗りこなす配達員。万能型のアスリート。	驚くほど速い。ネイティブ TS サポート。	新参者。本番環境での互換性の課題がまだある。

pnpm の空間黒魔術：ディスク容量を救う

これは Node.js 開発者にとって最大の悩みです。底なし沼のような node_modules のブラックホールです。従来の npm の世界では、10 個のプロジェクトで lodash を使っている場合、ディスクには 10 個の実体ファイルが保存されます。

pnpm (Performant npm) は、「グローバルストア (Central Warehouse)」という概念を使ってこの問題を直接解決しました：

従来 (npm/Yarn v1)：実体コピー。各部屋に同じ家具のセットを無理やり詰め込み、空間を重複して浪費。
pnpm：魔法の転送門 (Hard Link)。家具はすべて中央倉庫に保管され、あなたの部屋には倉庫につながる「転送門」があるだけ。

これは、どれほど何百ものプロジェクトで同じバージョンの React を使っていたとしても、PC の物理的な占有容量は常に 1 つ分であることを意味します。さらに、インストール速度は電光石火です。なぜなら、ほとんどの部品を他のプロジェクトからすでに「覚えている」からです！

共有倉庫は互いに干渉しませんか？

ベテランの方はこう聞くでしょう。「プロジェクト A の node_modules を変更したら、プロジェクト B まで壊れてしまいませんか？」心配いりません。pnpm には読み取り専用 (Read-only) メカニズムがあり、中央倉庫のファイルは簡単には変更できません。どうしてもパッケージをカスタマイズする必要がある場合は、pnpm の pnpm patch メカニズムが安全に処理してくれます。

Bun の極速伝説：パッケージ管理だけでなく、実行環境でもある

pnpm が倉庫整理の達人だとしたら、Bun は全速力で走るレーシングカーです。

Bun の速さは、文字通り「一から作り直した」ことに由来します：

ハイパーエンジンに乗せ換え：Chrome の V8 ではなく、Safari の JavaScriptCore を採用しました。
低級言語 (Zig) で記述：ファイルの読み書きやネットワーク転送において、無駄な動きがほとんどありません。
万能工具箱 (All-in-one)：Bun には bun install、bun run (実行環境)、bun test (テストフレームワーク)、bun build (ビルドツール) が内蔵されています。

「Vibe Coding（ノリの良いコーディング）」のレスポンスを求める開発者にとって、Bun は保存から実行結果が出るまでの時間を「瞬きする間」に短縮し、開発のリズムを全く崩しません。

実戦での選択：本番環境ではどれを使うべき？

もし「実際に大量のユーザーがアクセスする」サービスを運営しようとしており、99.9% の安定性と最強の互換性を求めているなら、ベテランの個人的な推奨は以下の通りです：

Node.js (LTS バージョン) + pnpm

これは現在、Vercel や Meta などの大手企業が Next.js プロジェクトを扱う際の主流の組み合わせです。

理由	説明
互換性が無敵	Next.js は Vercel 製であり、Vercel のインフラは Node.js を基準にしています。
厳格な依存関係ツリー	pnpm は「ゴースト依存」（`package.json` に宣言されていないパッケージの使用）を許しません。これにより「自分の PC では動くのにサーバーで落ちる」という悲劇を防げます。
CI/CD の強力な味方	pnpm の `pnpm-lock.yaml` は非常に安定しており、本番環境にインストールされる部品が開発時と全く同じであることを保証します。

結論

目標	推奨ツール
一般的な新規プロジェクトやディスク効率の追求	pnpm
開発時の極速体験や実験的なプロジェクト	Bun
非常に古いプロジェクトのメンテナンス	npm または Yarn v1

Reference

Claude Skillとは？AIエージェントを賢くする秘密兵器：Claude Skillとクロスプラットフォーム統合の徹底解説

Mon, 05 Jan 2026 22:50:00 +0800

はじめに

こんな経験はありませんか？プロジェクトの特定のタスクをAIに手伝ってもらいたいのに、背景知識、コーディング規約、APIドキュメントをすべてプロンプトに詰め込んだ結果、AIのコンテキストウィンドウがパンクしてしまったり、情報過多でAIが意味不明なことを言い出したりしたことは？

それはまるで、ミシュランのシェフを雇ったのに、毎回横に立って「ほら、今タマネギを切って、次は卵を炒めて、塩を忘れずに……」と小言を言うようなものです。シェフは優秀ですが、毎回これを繰り返すのはあなたも疲れますし、シェフも聞き逃してしまうかもしれません。

この問題を解決するために、Claude (Anthropic) は Claude Skill (Agent Skill) という強力な概念を導入しました。この記事では、この「ブラックテクノロジー」とは何か、そしてそれをどのようにプロジェクトに統合し、すべてのAIエージェントを即戦力に変えるかについて詳しく解説します。

Claude Skillとは？（日常的な例え：キッチンの秘密のレシピ）

Claude Skillを最も簡単に説明するなら、「高級レストランのキッチンの棚に置かれたレシピカード (Recipe Cards)」 と想像できます。

一般的なプロンプティング (General Prompting)：シェフ (AI) の横に立って口頭で指示を出すようなもの。
Claude Skills (Agent Skills)：標準作業手順書 (SOP) をレシピカードとして書き出したもの。

これらのカードは通常、フォルダー（ファイルシステム）に保管されており、シェフは百科事典全体を暗記する必要はありません （コンテキストウィンドウの節約）。「ビーフ・ウェリントンを作って」と叫んだときだけ、シェフは棚に行き、その特定のレシピカードを取り出し、手順に従って一つひとつ調理します。

Skillのコア構造

Skillの構造は実は非常にシンプルです。それは単なるフォルダであり、通常は次の3つの部分で構成されています：

SKILL.md：これがレシピ本体です。「PDFを処理したい場合は、まずこうして、次にこうして……」と書かれています。
scripts/（オプション）：キッチンの専用ピーラーのようなものです。これはAIが自分でコードを捏造することなく直接実行できる、特定のPythonまたはBashスクリプトです。
Metadata (YAML)：レシピ本の背表紙にあるラベル（名前、説明）で、AIがそのレシピが何のためのものかを素早くスキャンできるようにします。

なぜこれでエージェントが賢くなるのか？（アーキテクチャの利点）

これは 「段階的開示 (Progressive Disclosure)」 と呼ばれる心理学/技術的な概念を利用しています。

Skillを使用する前：プロジェクトのルール、コーディング規約、APIドキュメントをすべてAIに詰め込みます。AIの脳容量（コンテキストウィンドウ）は瞬時に爆発します。
Skillを使用した後：AIは「これらのツールリスト (Metadata) を持っている」ことだけを知っている状態でスタートします。特定のタスクに直面したときだけ、その特定の SKILL.md を脳に「読み込み」ます。

これにより、AIエージェントは「図書館全体を暗記しようとするガリ勉」ではなく、「マニュアルの調べ方を知っているシニアエンジニア」 のようになります。

徹底解説：Skillの仕組みとフォーマット

Claude Skillの動作ロジックは情報を3つのレベルに分割し、AIが 「必要な時に、必要なものだけを取り出す」 ことを可能にします。

レベル	コンテンツ (Content)	いつ読み込まれるか (When Loaded)	トークン消費	日常的な例え
Level 1	Metadata (メタデータ) YAMLタグ：名前、説明	常時 (Always) 起動時にSystem Promptに入れる	極小 (~100 tokens)	レストランのメニューメニューを見てその料理があることはわかりますが、まだキッチンに入る必要はありません。
Level 2	Instructions (指示書) `SKILL.md` 内の教育内容	トリガー時 (Triggered) AIが必要だと感じた時にBashを使ってファイルを読み込む	中程度 (<5k tokens)	レシピカードこの料理を作ることが決まったら、このカードを取り出して手順を確認します。
Level 3	Resources & Code スクリプト (`.py`) や参考資料	必要時 (As needed) スクリプトの実行や特定ドキュメントの参照	ほぼゼロ実行結果のみを返す	専用調理器具卵を泡立てるためにミキサーを取り出します。結果だけが必要で、機械ごと飲み込む必要はありません。

`SKILL.md` フォーマット例

標準的なSkillファイルは、YAMLヘッダーとMarkdownコンテンツで構成されています：

---
name: data-analyzer           # 規範：小文字、数字、ハイフン
description: Analyze data from CSV files and generate charts. Use when the user asks for insights from spreadsheets. # 規範：「何をするか」と「いつ使うか」を明確に記述
---

# Data Analyzer Skill

## Instructions
1.  まず、ユーザーから提供されたCSVファイルパスを確認します。
2.  `scripts/analyze.py` スクリプトを使用してデータを読み込みます。
3.  分析が成功したら、繁体字中国語でデータの傾向を要約してください。

## Examples
User: "この売上レポートを分析して"
Assistant: (executes python scripts/analyze.py sales.csv)

「クロスモデル」な汎用アーキテクチャをどう構築するか？

多くの人の悩みはこれです：「Claudeに縛られたくない！他のAI（Gemini, Cursor, VS Code Copilotなど）はどうなるの？」

Claude Codeが自動的にスキャンできるのは、そのランタイムに .claude/skills を走査するロジックがハードコードされているからです。他のエージェントは、検索システムのない図書館に入ってくる読者のようなものです。

これを解決するために、「スキル総目録 (Master Index)」 を作成することができます。

解決策1：`SKILLS_INDEX.md` を作成する

プロジェクトのルートに SKILLS_INDEX.md または AGENTS_README.md を作成し、以下のような構成にします：

# AI Agent Skills Index
(注意：このプロジェクトにはモジュール化されたAgent Skillsが含まれています。以下のタスクに遭遇した場合は、対応するSKILL.mdファイルを読み込んで操作基準を取得してください。)

## Available Skills

| スキル名 (Skill Name) | フォルダパス (Path) | 機能説明とトリガータイミング (Description & When to use) |
| :--- | :--- | :--- |
| PDF Processing | `skills/pdf-processing/SKILL.md` | ユーザーが「PDFを読む」、「表を抽出する」、または「ファイルをマージする」ように求めた場合に使用します。 |
| Code Review | `skills/code-review/SKILL.md` | ユーザーが「コードレビュー」、「PRのチェック」、または「コードの最適化」を求めた場合に使用します。 |

## How to use
1. まず上のリストを読んでください。
2. ユーザーのプロンプトに基づいて、どのSkillが最も関連性が高いかを判断します。
3. そのパスの下にある `SKILL.md` の内容をコンテキストに能動的に読み込んで (Read) ください。

これはレストランの入り口にある「メニュー」のようなものです。GeminiやCursorがプロジェクトに入ってこのファイルを読み込むとすぐに、「おっ！使える技はこれか」とわかります。

解決策2：Cursor向けの特化した解決策 (`.cursorrules`)

もし Cursor を使っているなら、.cursorrules という強力な機能があります。上記のインデックスロジックを直接書き込むことで、CursorにSkillを自動的にマウントさせることができます。

You are an advanced AI coding assistant. This project utilizes a standardized "Agent Skills" architecture located in the `skills/` directory.

Before executing complex tasks, verify if a relevant skill exists:

[Skill List]
- name: pdf-processing
- path: skills/pdf-processing/SKILL.md
- description: Extract text and tables from PDF files.

Instruction:
If the user's request matches a skill's description, you MUST read the content of the corresponding `SKILL.md` file before proceeding.

解決策3：自動生成スクリプト

手動で目録を管理する手間を省くために、簡単な update_skills_index.py スクリプトを書いて、すべての SKILL.md のYAMLヘッダーを自動的にスキャンし、SKILLS_INDEX.md を生成することができます。

どうやって素早くSkillを作るか？

YAMLやMarkdownを手書きしたくないですか？それなら 「AI Skill」を使って「AI Skill」を生成 しましょう！

Anthropic公式は skill-creator Skillを提供しています。これは実質的に 「対話型ウィザード」 です。

インストール：skill-creator フォルダをskillsディレクトリに入れます。
召喚：AIに「ねえ、新しいSkillを作りたいんだけど、skill-creatorを使って手伝って」と言います。
対話：「どんなツールを作りたい？」「Pythonスクリプトを書く必要がある？」と聞いてきます。
生成：対話が終わると、標準フォーマットの SKILL.md とフォルダ構成を自動的に吐き出してくれます。

これは、自分で設計図を描く必要がなく、「設計図生成ロボット」に描いてもらうようなものです。

結論

Claude Skills (Agent Skills) はClaude専用の機能でなく、オープンなAgent協調の標準です。標準化されたファイル構造 と 明確なインデックスメカニズム を通じて、この強力なアーキテクチャはモデルの壁を越え、あらゆるAI開発環境に適用できます。

この「デジタル従業員操作マニュアル」があれば、あなたのエージェントはもはや意味不明なことしか言えない新人ではなく、いつでもSOPを参照して正確にタスクを実行できるシニアエキスパートになります。今すぐあなたのSkill Standard Libraryの構築を始めましょう！

Reference

Tutorials

Skills

Git はなぜ空のフォルダを追跡しないのか？.gitkeep と .gitignore の役割とは？

Sun, 04 Jan 2026 00:00:37 +0800

簡単に言うと、.gitkeep は慣習的なダミーファイルです。その存在目的はただ一つ、本来空であるはずのフォルダを Git に強制的に追跡させることです。

なぜ必要なのか？

Git の設計思想は 「ファイルの変更を追跡すること」 であり、「フォルダを追跡すること」 ではありません。もしプロジェクトに空のフォルダがある場合、Git はそれを完全に無視し、GitHub やサーバーにアップロードしません。

これは問題を引き起こすことがあります。コードが実行されるために特定のディレクトリが存在する必要があるが、テストデータや一時ファイルをアップロードしたくない場合などです。もしディレクトリが存在しなければ、プログラムはクラッシュするかもしれません。

よくあるフォルダ例：

logs/：ログファイル用
uploads/：ユーザーがアップロードしたファイル
tmp/：一時ファイル
cache/：キャッシュデータ

これらのディレクトリは実行時に必要で、中身はコミットすべきではありませんが、フォルダ自体は存在しなければなりません。

仕組み

Git を「騙して」このフォルダを維持させるために、機能を持たない隠しファイルを中に入れ、Git に「おっ！ここに何かあるぞ、記録しなきゃ」と思わせるのです。

実務的な例え：

家を建てている（プロジェクトを書いている）と想像してください：

ファイル	説明
`.gitignore`	「ゴミ捨て禁止ラベル」のようなものです。清掃員（Git）に、どのアイテム（期限切れの食品や紙くずなど）を新居に持ち込んではいけないかを伝えます。
`.gitkeep`	「場所取り用の段ボール箱」のようなものです。新居にはまだ家具がありませんが、物置のスペースを確保しておく必要があります。そこで段ボール箱を置いておき、引越し業者に「このエリアも家の一部だから取り壊さないで」と知らせるのです。

使い方は？

空のフォルダ内に .gitkeep という名前のファイルを作成します。
ファイルの中身は空でもいいですし、“Keep this directory” と書いても構いません。
このファイルを git add して commit します。

`.gitkeep` と `.gitignore` の比較

特徴	`.gitkeep`	`.gitignore`
公式ステータス	非公式（単なるコミュニティの慣習）	公式（Git の組み込み機能）
主な機能	フォルダを保持し、Git に忘れられないようにする	ファイルを除外し、Git に追跡されないようにする
よくある状況	空のログフォルダ、キャッシュフォルダ	パスワードファイル、`node_modules`、一時ファイル

実用的なアドバイス：発想の転換

.gitkeep は一般的によく使われますが、実は Git の公式な部分ではありません。実際、README.md や .placeholder を使っても同じ効果が得られます。では、なぜみんな .gitkeep を使うのでしょうか？それは説明不要だからです：「このファイルは何もしないけど、Git がこのフォルダを削除しないようにしているだけ」 ということが一目瞭然だからです。

もう少しプロフェッショナルに見せたいなら、単に .gitkeep を使うよりも機能的でクリエイティブなアプローチがあります：

空のフォルダに以下の内容の .gitignore を配置します：

# このディレクトリ内のすべてを無視
*
# でも私（この .gitignore ファイル自体）は無視しないで
!.gitignore

これなら、フォルダを保持しつつ、中のゴミファイルが誤ってコミットされることも防げます。これぞ真の「フールプルーフ（誤操作防止）」メソッドです。

まとめ

.gitkeep は Git の設計論理に対する人間側の妥協です。
公式仕様ではありませんが、開発者の事実上の標準となっています。
本当に重要なのは .gitignore の仕組みを理解することです。.gitkeep は Git が空のフォルダを「理解」するのを助けるための小さな道具に過ぎません。

Reference

Git - gitignore Documentation

Laravelのbind()、singleton()、scoped()、instance()の論理的な違いは何ですか？どのようなシナリオで使用できますか？

Mon, 11 Nov 2024 00:00:37 +0800

Laravelサービスコンテナにおけるオブジェクトバインディング方法の比較

方法	`bind()`	`singleton()`	`scoped()`	`instance()`
説明	解決されるたびに新しいインスタンスを作成します。	インスタンスを1つだけ作成し、後続のリクエストでは同じインスタンスを返します。	各リクエスト/ジョブのライフサイクル内でインスタンスを1つだけ作成し、リクエスト終了後にクリアされます。	既存のインスタンスをコンテナにバインドし、解決されるたびにそのインスタンスを返します。
メリット	- リクエストごとに新しいインスタンスが作成されるため、状態共有の問題がない - メモリ使用がクリーン - 独立した状態を必要とするロジックに適している - リクエストごとに独自の構成を提供できる	- インスタンスを1回作成するだけで済むため、システムリソースを節約できる - 状態の一貫性を確保できる - 構成やリソースの共有に適している - 高同時実行性の場合にパフォーマンスが向上する	- メモリ使用量と状態共有のバランスが取れている - リクエスト内では状態を共有し、リクエスト間では分離される - Webリクエストのシナリオに適している	- インスタンス作成のタイミングを完全に制御できる - インスタンスの状態を事前に構成できる - 特定の構成を必要とするサービスに適している
デメリット	- インスタンスを繰り返し作成するために多くのシステムリソースが必要 - 高同時実行下ではパフォーマンスに影響を与える可能性がある - 状態共有が必要なシナリオには適さない - 毎回新しいインスタンスを作成するため、パフォーマンスの問題を引き起こす可能性がある。	- 状態の共有は、追跡が難しいバグにつながる可能性がある - 独立した状態が必要なシナリオには適さない - プログラム終了までメモリ使用が継続する - テストでは状態のリセットに特別な注意が必要 - そのインスタンスが状態を保持している場合、予期しない動作を引き起こす可能性がある。	- 長時間実行されるタスクで問題が発生する可能性がある - リクエストのライフサイクルを理解する必要がある - CLIコマンドには適さない	- 柔軟性が低い - インスタンス構成を動的に調整できない - 起動時にメモリを占有する可能性がある - 遅延読み込みや複数のインスタンスが必要な場合には適さない。
使用例	短期間使用するサービスや、独立した状態が必要なクラスに使用します。	ロガーや構成マネージャーなど、グローバルに共有されるサービスに使用します。	データベース接続など、リクエスト内で状態を維持する必要があるがリクエスト間では維持したくないサービスに使用します。	共有構成オブジェクトなど、すでにインスタンスがあり、それを再利用したい場合に使用します。
例	`Product`クラスがあり、異なる製品データが要求されるたびに新しい`Product`インスタンスを作成したい場合。	`Logger`クラスがあり、一貫性を保つためにすべてのログ書き込み操作で同じインスタンスを使用したい場合。	`ShoppingCart`クラスがあり、同じリクエスト内でショッピングカートの状態を共有する必要がある場合。	`DatabaseConfig`クラスがあり、アプリケーションの起動時に接続パラメーターを設定する必要がある場合。

例

`bind()` の使用

$this->app->bind('Product', function () {
 return new Product();
});

app('Product') が呼び出されるたびに、新しい Product インスタンスが返されます。

`singleton()` の使用

$this->app->singleton('Logger', function () {
 return new Logger();
});

app('Logger') が呼び出されるたびに、同じ Logger インスタンスが返されます。

`scoped()` の使用

$this->app->scoped(Transistor::class, function (Application $app) {
    return new Transistor($app->make(PodcastParser::class));
});

同じリクエストライフサイクル内で同じインスタンスを共有し、異なるリクエストでは新しいインスタンスを作成します。

`instance()` の使用


$service = new Transistor(new PodcastParser);
 
$this->app->instance(Transistor::class, $service);

既存のインスタンスをコンテナに直接バインドします。

まとめ

Laravelは現在、Webリクエスト、CLIコマンド、Queueジョブ、Consoleコマンドなど、さまざまなタイプのシナリオに適用できます。

そのため、どのバインディング方法を使用するかを選択する際には、さまざまなシナリオでのサービスのニーズ、および状態や構成を共有する必要があるかどうかを考慮する必要があります。

Reference

Service Container - Laravel 11.x - The PHP Framework For Web Artisans

LaravelのServiceProviderにおけるregister()とboot()メソッドの違いは何ですか？どのようなシナリオで使用できますか？

Sun, 10 Nov 2024 00:00:37 +0800

`register()` と `boot()` メソッドの比較

LaravelのServiceProviderにおいて、register() と boot() メソッドの主な違いは、その実行タイミングと目的にあります。

	`register()`	`boot()`
説明	サービスコンテナにサービスをバインドするために使用されます。	登録済みのサービスに依存する操作を実行するために使用されます。
実行タイミング	すべてのサービスプロバイダが登録される前に実行されます。	すべてのサービスプロバイダの登録が完了した後に実行されます。
主な用途	バインディング、シングルトン、サービスなどの登録。	イベントリスナー、ルート、Bladeディレクティブなどの登録。
注意点	他のサービスプロバイダのサービスを使用すべきではありません。まだ登録されていない可能性があるためです。	他のサービスプロバイダのサービスを安全に使用できます。

使用シナリオの例

`register()` の使用

public function register()
{
 $this->app->bind('App\Contracts\SomeService', 'App\Services\SomeService');
}

この例では、インターフェースを具体的な実装にバインドし、アプリケーション全体で使用できるようにしています。

`boot()` の使用

public function boot()
{
 \Event::listen('event.name', function ($data) {
 // イベントを処理する
 });
}

ここでは、boot() メソッドでイベントリスナーを登録し、必要なすべての依存関係が利用可能であることを保証しています。

結論

register() メソッドはバインディングに焦点を当てていますが、boot() メソッドは他の登録済みサービスに依存する操作を実行するために使用されます。

Laravelアプリケーションを開発する際、これら2つのメソッドを正しく使用することで、コードの保守性と安定性を向上させることができます。

Reference

Service Providers - Laravel 11.x - The PHP Framework For Web Artisans

Laravel Octane 実行時の「Undefined constant "Laravel\Octane\Commands\Concerns\SIGINT"」エラー解決方法

Sat, 02 Nov 2024 00:00:37 +0800

実行コマンドエラーメッセージ

php artisan octane:frankenphp --port=443 --https --workers=1 --max-requests=1

Undefined constant "Laravel\Octane\Commands\Concerns\SIGINT"

at vendor/laravel/octane/src/Commands/Concerns/InteractsWithServers.php:174
  170▕      * Returns the list of signals to subscribe.
  171▕      */
  172▕     public function getSubscribedSignals(): array
  173▕     {
➜ 174▕         return [SIGINT, SIGTERM, SIGHUP];
  175▕     }
  176▕
  177▕     /**
  178▕      * The method will be called when the application is signaled.

    +5 vendor frames

6   artisan:13
    Illuminate\Foundation\Application::handleCommand(Object(Symfony\Component\Console\Input\ArgvInput))

解決方法

これは php pcntl 拡張機能がインストールされていないために発生します。したがって、ext-pcntl 拡張機能をインストールするだけで解決します。

RUN install-php-extensions pcntl
RUN docker-php-ext-install pcntl

Reference

laravel: roadrunner: Undefined constant “Laravel\Octane\Commands\Concerns\SIGINT” - zhe.ink 在线工具箱

Docker install-php-extensions Imagick "imagick-3.7.0 install failed" 問題の修正

Fri, 01 Nov 2024 00:00:37 +0800

Photo by Ben Griffiths on Unsplash

Docker Imagick インストールエラー

RUN install-php-extensions imagick

エラーメッセージ

22.24 Saved /tmp/pear/temp/imagick/ImagickPixel_arginfo.h
22.25 In /tmp/pear/temp/imagick/Imagick.stub.php:
22.25 Unterminated preprocessor conditions
22.26 make: *** [Makefile:196: /tmp/pear/temp/imagick/Imagick_arginfo.h] Error 1
22.26 ERROR: `make -j10 INSTALL_ROOT="/tmp/pear/temp/pear-build-defaultuserAdMKLn/install-imagick-3.7.0" install' failed

解決策

Imagick をインストールする際、正しいバージョン master 28f27044e435a2b203e32675e942eb8de620ee58 を指定してください。

# https://github.com/Imagick/imagick/commits/master/
# RUN install-php-extensions imagick/imagick@master
RUN install-php-extensions imagick/imagick@28f27044e435a2b203e32675e942eb8de620ee58

現在の master バージョンは正常に動作しますが、master がいつでも変更され、本番環境が破損するリスクを避けるため、現在の master バージョンのコミットハッシュ 28f27044e435a2b203e32675e942eb8de620ee58 を指定します。

Imagick バージョン番号: https://github.com/Imagick/imagick/commits/master/

Reference

PostgreSQL – CTEを使用した再帰クエリ

Tue, 14 Mar 2023 00:00:37 +0800

厳密に言えば、このプロセスは反復（iteration）であり、再帰（recursion）ではありませんが、RECURSIVE は SQL 標準委員会によって選ばれた用語です。

Postgres 再帰クエリの一般的な構造は次のようになります：

非再帰的な select ステートメント
Union または union all
再帰的な select ステートメント

WITH RECURSIVE name_cte AS (
  SELECT statement  /* non-recursive statement */
  UNION [ALL]
  SELECT statement  /*recursive statement referencing the above select statement */
)
SELECT * FROM name_cte;

Postgres 再帰クエリの仕組み

非再帰的なステートメントを評価し、一時テーブルを作成します
再帰項を評価し、それらを一時テーブルに追加します
作業テーブルが空になるまでステップ 2 を繰り返します

Union と union all の違いは、union all は重複を許可するのに対し、union は重複を一切許可しないことです。

例

最初の 10 個の自然数

WITH RECURSIVE tens AS (
   SELECT 1 as n
 UNION ALL
   SELECT n+1 FROM tens
)
SELECT n FROM tens limit 10;

これは Postgres 再帰クエリの基本的な例で、最初の 10 個の自然数を出力します。

自然数の階乗を求める Postgres 再帰クエリ：

WITH RECURSIVE fact (n, factorial)
AS (
    SELECT 1 as n, 5 as factorial
union all
    SELECT n+1, factorial*n FROM fact where n < 5
)
SELECT * FROM fact;

このクエリは 2 つのテーブルを出力します。1 つは最初の 5 つの自然数を含み、もう 1 つのテーブルには階乗を求めるために実行された計算が含まれます。

最後の行だけを出力することもできますが、ここでは反復と計算がどのように行われるかを見ることができます。

フィボナッチ数列を出力する Postgres 再帰クエリ：

WITH RECURSIVE fibb
AS (
    SELECT 1::bigint as n, 0::bigint as a, 1::bigint as b
UNION ALL
    SELECT n+1, b as a, (a+b) as b FROM fibb
)
SELECT b FROM fibb limit 10;

これはフィボナッチ数列を 10 まで出力します。

組織階層

Postgres 再帰クエリの助けを借りて、組織階層を見つけることができます：

テーブルを作成するには：

INSERT INTO employees (
  employee_id,
  full_name,
  manager_id
)
VALUES
(1, 'Abhi', NULL),
(2, 'Bhargav', 1),
(3, 'Chay', 1),
(4, 'Dravid', 1),
(5, 'Erin', 1),
(6, 'Ford', 2),
(7, 'Gagan', 2),
(8, 'Harry', 3),
(9, 'Isaac', 3),
(10, 'Jack', 4),
(11, 'Kiran', 5);

Abhi はボスであり、最初のレベルになります。Bhargav、Chay、Dravid、Erin は次のレベルになり、残りの人々は最後のレベルになります。

クエリ：

WITH RECURSIVE subordinates AS (
  SELECT employee_id, manager_id, full_name, 0 as level
  FROM employees
  WHERE manager_id IS NULL

  UNION ALL

  SELECT e.employee_id, e.manager_id, e.full_name, level+1
  FROM employees e
  INNER JOIN subordinates s ON s.employee_id = e.manager_id
)  
SELECT * FROM subordinates;

出力は次のようになります：

Reference

PostgreSQL - Recursive Query Using CTEs - GeeksforGeeks

最適なデータベースページネーション手法

Tue, 14 Mar 2023 00:00:37 +0800

Photo by Tobias Fischer on Unsplash

👋 はじめに

データベースは、あらゆるアプリケーションの礎の一つです。アプリケーションが記憶し、後で計算し、他のオンラインユーザーに表示するために必要なすべてのものを保存する場所です。データベースが大きくなり、一度に1,000件の投稿を取得してレンダリングしようとしてアプリケーションが遅延し始めるまでは、すべてが順調です。さて、あなたは賢いエンジニアですよね？あなたはすぐに「もっと見る」ボタンでそれを修正します。数週間後、新しいタイムアウトエラーが発生しました！あなたは Stack Overflow に向かいますが、すぐに Ctrl と V が使いすぎで機能しなくなっていることに気づきます 🤦 他に選択肢がなく、実際にデバッグを開始すると、ユーザーがアプリを開くたびにデータベースが50,000件以上の投稿を返していることに気づきます！どうすればいいでしょうか？

このような恐ろしいシナリオを防ぐために、最初からリスクを認識しておく必要があります。準備の整った開発者は決してリスクを冒す必要がないからです。この記事では、offset（オフセット） と cursor pagination（カーソルページネーション） を使用して、データベース関連のパフォーマンスの問題に対処する準備を整えます。

“予防は治療に勝る。” - ベンジャミン・フランクリン

📚 ページネーションとは？

ページネーションは、数百件以上のレコードを保持するデータセットをクエリする際に採用される戦略です。ページネーションのおかげで、大規模なデータセット を チャンク（またはページ） に分割し、徐々に取得してユーザーに表示することで、データベースへの負荷を軽減できます。ページネーションは、クライアント側とサーバー側の両方で多くのパフォーマンスの問題も解決します！ページネーションがなければ、あなたに送信された最新のメッセージを読むためだけに、チャット履歴全体をロードする必要があります。

最近では、すべてのアプリケーションが 大量のデータ を扱う可能性が高いため、ページネーションはほぼ必須になっています。このデータは、ユーザー生成コンテンツ、管理者や編集者が追加したコンテンツ、自動生成された監査ログなど、あらゆるものが考えられます。リストが数千項目を超えて増えるとすぐに、データベースは各リクエストの解決に時間がかかりすぎ、フロントエンドの速度とアクセシビリティが低下します。ユーザーにとって、彼らの体験はこのようになります。

ページネーションとは何かがわかったところで、実際にどのように使用するのでしょうか？そして、なぜそれが必要なのでしょうか？

🔍 ページネーションの種類

広く使用されている2つのページネーション戦略、offset と cursor があります。深く掘り下げてそれらについてすべてを学ぶ前に、それらを使用しているいくつかのウェブサイトを見てみましょう。

まず、GitHub の Stargazer ページにアクセスして、タブに絶対数ではなく 5,000+ と表示されていることに注目してください。また、標準的なページ番号 の代わりに Previous（前へ） と Next（次へ） ボタンを使用しています。

次に、Amazon の製品リストに切り替えて、正確な結果数 364 と、クリックできる 1 2 3 … 20 の すべてのページ番号 がある 標準的なページネーション に注目してください。

2つのハイテク巨人がどちらのソリューションが優れているかについて合意できなかったことは明らかです！なぜでしょうか？まあ、開発者が嫌う答え、つまり「場合による」を使う必要があります。両方の方法を探求し、それぞれの利点、制限、パフォーマンスへの影響を理解しましょう。

Offset pagination（オフセットページネーション）

ほとんどのウェブサイトは、その シンプルさ とユーザーにとってページネーションがいかに 直感的 であるかという理由から、オフセットページネーションを使用しています。オフセットページネーションを実装するには、通常2つの情報が必要です。

limit - データベースから取得 する行数
offset - スキップ する行数。オフセットはページ番号のようなものですが、少し計算が必要です (offset = (page-1) * limit)

データの最初のページを取得するには、limit を 10 に設定し（ページに10個の項目が必要なため）、offset を 0 に設定します（0番目の項目から10個の項目をカウントしたいため）。結果として、10行が取得されます。

2ページ目を取得するには、limit を 10 のままにし（各ページに10行を含めたいため変更しません）、offset を 10 に設定します（10行目以降の結果を返します）。このアプローチを継続することで、エンドユーザーは結果をページ送りし、すべてのコンテンツを見ることができます。

SQL の世界では、このようなクエリは SELECT * FROM posts OFFSET 10 LIMIT 10 と記述されます。

オフセットページネーションを実装している一部のウェブサイトでは、最後のページのページ番号も表示されます。どうやっているのでしょうか？各ページの結果とともに、合計で何行あるかを示す sum 属性も返す傾向があります。limit、sum、少しの計算を使用して、lastPage = ceil(sum / limit) で最後のページ番号を計算できます。

この機能はユーザーにとって便利ですが、開発者はこのタイプのページネーションをスケーリングするのに苦労しています。sum 属性を見ると、データベース内のすべての行を正確な数までカウントするのにかなりの時間がかかることがわかります。さらに、データベースのオフセットは、何行スキップすべきかを知るために行をループする 方法で実装されています。つまり、オフセットが高いほど、データベースクエリにかかる時間が長くなります。

オフセットページネーションのもう一つの欠点は、リアルタイムデータ や 頻繁に変更されるデータ と相性が 良くない ことです。オフセットは 何行スキップしたいか を指定しますが、行の削除 や新しい 行の作成 を考慮 していません。そのようなオフセットは、データの重複 や一部の データの欠落 を表示する結果になる可能性があります。

Cursor pagination（カーソルページネーション）

カーソルはオフセットの後継であり、オフセットページネーションのように 行の相対的な順序 に依存しないため、パフォーマンス、データの欠落、データの重複 というオフセットページネーションのすべての問題を解決します。代わりに、データベースによって 作成および管理 されるインデックスに依存しています。カーソルページネーションを実装するには、以下の情報が必要です。

limit - 前と同じく、1ページに表示したい行数
cursor - リスト内の 参照要素 の ID。前のページ をクエリしている場合は 最初の項目、次のページ をクエリしている場合は 最後の項目 になります。
cursorDirection - ユーザーが Next または Previous（その後、またはその前） をクリックしたかどうか

最初のページ をリクエストするときは、何も提供する必要はなく、取得したい行数を示す limit 10 だけで十分です。結果として、10行が得られます。

次のページを取得するには、最後の行 の ID を cursor として使用し、cursorDirection を after に設定します。

同様に、前のページ に移動したい場合は、最初の行 の ID を cursor として使用し、direction を before に設定します。

比較のために、SQL の世界では、クエリを SELECT * FROM posts WHERE id > 10 LIMIT 10 ORDER BY id DESC と書くことができます。

offset の代わりに cursor を使用するクエリは、WHERE クエリが 不要な行をスキップ するのに役立つため、パフォーマンスが向上します。一方、OFFSET は それらを反復処理 する必要があり、フルテーブルスキャン になります。ID に適切なインデックスを設定している場合、WHERE を使用して行をスキップすると さらに高速 になります。主キーの場合、インデックスはデフォルトで作成されます。

それだけでなく、行が 挿入 されたり 削除 されたりすることを 心配する必要はもうありません。オフセット10を使用していた場合、現在のページの前に正確に10行が存在すると予想されます。この条件が満たされない場合、クエリは 一貫性のない結果 を返し、データの 重複 や 行の欠落 につながります。これは、現在のページの前の 任意の行が 削除 されたり、新しい行が追加 されたりした場合に発生する可能性があります。カーソルページネーションは、取得した 最後の行のインデックス を使用することでこれを解決し、さらにリクエストしたときにどこから探し始めればよいか正確に知っています。

すべてが良いことばかりではありません。カーソルページネーション をバックエンドで独自に実装する必要がある場合、それは非常に複雑な問題です。カーソルページネーションを実装するには、クエリに WHERE 句と ORDER BY 句が必要です。さらに、必要な条件でフィルタリングするための WHERE 句も必要です。これはすぐに非常に複雑になり、巨大なネストされたクエリになる可能性があります。それに加えて、クエリする必要があるすべての列に対してインデックスを作成する必要もあります。

素晴らしい！カーソルページネーション に切り替えることで、重複と データの欠落 を排除しました！しかし、まだ1つの問題が残っています。絶対に ユーザーに 増分数値 ID を公開してはならないため（セキュリティ上の理由から）、各 ID のハッシュ化されたバージョン を維持する必要があります。データベースをクエリする必要があるたびに、これらのペアを保持するテーブルを参照して、この文字列 ID を数値 ID に変換します。この 行が見つからない 場合はどうなりますか？ Next ボタンをクリックし、最後の行の ID を取得して次のページをリクエストしたが、データベースがその ID を見つけられない場合はどうなりますか？

これは非常にまれな状態であり、カーソルとして使用しようとしている行の ID が削除されたばかりの場合にのみ発生します。この問題は、前の行を試す か、以前のリクエストのデータを再取得 して最後の行を新しい ID で更新することで解決できますが、これらすべてはまったく新しいレベルの複雑さをもたらし、開発者は 再帰 や 適切な状態管理 などの多くの新しい概念を理解する必要があります。幸いなことに、Appwrite などのサービスがこれを処理するため、カーソルページネーションを機能として単純に使用できます。

🚀 Appwrite におけるページネーション

Appwrite はオープンソースの Backend-as-a-Service であり、コアバックエンドのニーズに対応する一連の REST API を提供することで、最新のアプリケーション構築に伴うすべての複雑さを抽象化します。Appwrite は、ユーザー認証と認可、データベース、ファイルストレージ、クラウド関数、Webhook などを処理します！足りないものがあれば、お気に入りのバックエンド言語を使用して Appwrite を拡張できます。

Appwrite Database を使用すると、ユーザー間で共有する必要があるテキストベースのデータを保存できます。Appwrite のデータベースでは、複数のコレクション（テーブル）を作成し、その中に複数のドキュメント（行）を保存できます。各コレクションには、データセットに適切なスキーマを与えるように構成された属性（列）があります。検索クエリのパフォーマンスを高めるためにインデックスを構成することもできます。データを読み取るときは、強力なクエリのホストを使用し、フィルタリング、並べ替え、結果数の制限、およびページネーションを行うことができます。そして、これらすべてがすぐに使用できます！

Appwrite Database をさらに良くしているのは、オフセットページネーションとカーソルページネーションの両方をサポートしている Appwrite のページネーションサポートです！ID が articles のコレクションがあると想像してみましょう。オフセットまたはカーソルページネーションを使用して、このコレクションからドキュメントを取得できます。

// Setup
import { Appwrite, Query } from "appwrite";
const sdk = new Appwrite();

sdk
    .setEndpoint('https://demo.appwrite.io/v1') // Your API Endpoint
    .setProject('articles-demo') // Your project ID
;

// Offset pagination
sdk.database.listDocuments(
    'articles', // Collection ID
    [ Query.equal('status', 'published') ], // Filters
    10, // Limit
    500, // Offset, amount of documents to skip
).then((response) => {
    console.log(response);
});

// Cursor pagination
sdk.database.listDocuments(
    'articles', // Collection ID
    [ Query.equal('status', 'published') ], // Filters
    10, // Limit
    undefined, // Not using offset
    '61d6eb2281fce3650c2c' // ID of document I want to paginate after
).then((response) => {
    console.log(response);
});

まず、Appwrite SDK ライブラリをインポートし、特定の Appwrite インスタンスと特定のプロジェクトに接続するインスタンスをセットアップします。次に、オフセットページネーションを使用して10個のドキュメントを一覧表示し、公開されているもののみを表示するフィルターを使用します。直後に、まったく同じドキュメント一覧クエリを記述しますが、今回は offset の代わりに cursor ページネーションを使用します。

📊 ベンチマーク

この記事ではパフォーマンスという言葉を頻繁に使用しましたが、実際の数値は提供していません。そこで、一緒にベンチマークを作成しましょう！Appwrite はオフセットページネーションとカーソルページネーションの両方をサポートしているため、バックエンドサーバーとして Appwrite を使用し、Node.JS を使用してベンチマークスクリプトを記述します。結局のところ、Javascript は非常にわかりやすいです。

完全なソースコードは GitHub リポジトリにあります。

まず、Appwrite を設定し、ユーザーを登録し、プロジェクトを作成し、コレクションレベルの権限と読み取り権限を role:all に設定した posts というコレクションを作成します。このプロセスの詳細については、Appwrite ドキュメントをご覧ください。これで Appwrite を使用する準備が整ったはずです。

データベースが空なので、まだベンチマークを行うことはできません！テーブルにデータを入力しましょう。次のスクリプトを使用して、MariaDB データベースにデータをロードし、ベンチマークの準備をします。

const config = {};
// Don't forget to fill config variable with secret information

console.log("🤖 Connecting to database ...");

const connection = await mysql.createConnection({
    host: config.mariadbHost,
    port: config.mariadbPost,
    user: config.mariadbUser,
    password: config.mariadbPassword,
    database: `appwrite`,
});

const promises = [];

console.log("🤖 Database connection established");
console.log("🤖 Preparing database queries ...");

let index = 1;
for(let i = 0; i < 100; i++) {
    const queryValues = [];

    for(let l = 0; l < 10000; l++) {
        queryValues.push(`('id${index}', '[]', '[]')`);
        index++;
    }

    const query = `INSERT INTO _project_${config.projectId}_collection_posts (_uid, _read, _write) VALUES ${queryValues.join(", ")}`;
    promises.push(connection.execute(query));
}

console.log("🤖 Pushing data. Get ready, this will take quite some time ...");

await Promise.all(promises);

console.error(`🌟 Successfully finished`);

スクリプトの速度を上げるために、2層の for ループを使用しました。最初の for ループは待機する必要があるクエリ実行を作成し、2番目のループは複数の挿入リクエストを保持する長いクエリを作成します。理想的には、すべてを1つのリクエストに入れたいところですが、MySQL の構成上不可能なため、100回のリクエストに分割しました。

1分未満で 100万件のドキュメント が挿入され、ベンチマークを開始する準備が整いました。このデモには k6 負荷テストライブラリを使用します。

まず、よく知られており広く使用されている オフセットページネーション のベンチマークを行いましょう。各テストシナリオでは、データセットのさまざまな部分から 10個のドキュメントを含むページを取得 しようとします。オフセット0から開始し、100kずつ増やしてオフセット900kまで行います。ベンチマークは、可能な限り正確に保つために、一度に1つのリクエストのみを行うように記述されています。また、同じベンチマークを10回実行し、平均応答時間を測定して統計的有意性を確保します。k6 の HTTP クライアントを使用して、Appwrite の REST API にリクエストを送信します。

// script_offset.sh

import http from 'k6/http';

// Before running, make sure to run setup.js
export const options = {
    iterations: 10,
    summaryTimeUnit: "ms",
    summaryTrendStats: ["avg"]
};

const config = JSON.parse(open("config.json"));

export default function () {
    http.get(`${config.endpoint}/database/collections/posts/documents?offset=${__ENV.OFFSET}&limit=10`, {
        headers: {
            'content-type': 'application/json',
            'X-Appwrite-Project': config.projectId
        }
    });
}

さまざまなオフセット構成でベンチマークを実行し、出力を CSV ファイルに保存するために、単純な bash スクリプトを作成しました。このスクリプトは k6 を10回実行し、毎回異なるオフセット構成 を使用します。出力はコンソール出力として提供されます。

#!/bin/bash
# benchmark_offset.sh

k6 -e OFFSET=0 run script.js
k6 -e OFFSET=100000 run script.js
k6 -e OFFSET=200000 run script.js
k6 -e OFFSET=300000 run script.js
k6 -e OFFSET=400000 run script.js
k6 -e OFFSET=500000 run script.js
k6 -e OFFSET=600000 run script.js
k6 -e OFFSET=700000 run script.js
k6 -e OFFSET=800000 run script.js
k6 -e OFFSET=900000 run script.js

1分以内にすべてのベンチマークが終了し、各オフセット構成の 平均応答時間 が得られました。結果は予想通りでしたが、まったく満足のいくものではありませんでした。

	Offset pagination (ms)
0% offset	3.73
10% offset	52.39
20% offset	96.83
30% offset	144.13
40% offset	216.06
50% offset	257.71
60% offset	313.06
70% offset	371.03
80% offset	424.63
90% offset	482.71

ご覧のとおり、offset 0 は非常に高速で、4ms 未満で応答しました。最初のジャンプは offset 100k で、変化は劇的で、応答時間は 52ms に増加しました。オフセットが増えるたびに所要時間が増加し、900kドキュメントのオフセット後に10個のドキュメントを取得するのにほぼ 500ms かかりました。これはクレイジーです！

次に、スクリプトを更新して カーソルページネーション を使用するようにしましょう。スクリプトを更新して オフセットの代わりにカーソル を使用し、bash スクリプトを更新してオフセット番号の代わりにカーソル（ドキュメント ID）を提供するようにします。

// script_cursor.js
import http from 'k6/http';

// Before running, make sure to run setup.js
export const options = {
    iterations: 10,
    summaryTimeUnit: "ms",
    summaryTrendStats: ["avg"]
};

const config = JSON.parse(open("config.json"));

export default function () {
    http.get(`${config.endpoint}/database/collections/posts/documents?cursor=${__ENV.CURSOR}&cursorDirection=after&limit=10`, {
        headers: {
            'content-type': 'application/json',
            'X-Appwrite-Project': config.projectId
        }
    });
}

#!/bin/bash
# benchmark_cursor.sh

k6 -e CURSOR=id1 run script_cursor.js
k6 -e CURSOR=id100000 run script_cursor.js
k6 -e CURSOR=id200000 run script_cursor.js
k6 -e CURSOR=id300000 run script_cursor.js
k6 -e CURSOR=id400000 run script_cursor.js
k6 -e CURSOR=id500000 run script_cursor.js
k6 -e CURSOR=id600000 run script_cursor.js
k6 -e CURSOR=id700000 run script_cursor.js
k6 -e CURSOR=id800000 run script_cursor.js
k6 -e CURSOR=id900000 run script_cursor.js

スクリプトを実行すると、応答時間に顕著な違いがあったため、すでにパフォーマンスが向上していることがわかりました。結果を表に入れて、これら2つの方法を並べて比較しました。

	Offset pagination (ms)	Cursor pagination (ms)
0% offset	3.73	6.27
10% offset	52.39	4.07
20% offset	96.83	5.15
30% offset	144.13	5.29
40% offset	216.06	6.65
50% offset	257.71	7.26
60% offset	313.06	4.61
70% offset	371.03	6.00
80% offset	424.63	5.60
90% offset	482.71	5.05

わあ！カーソルページネーション は最高です！グラフは、カーソルページネーションが オフセットサイズ を 気にしない ことを示しており、すべてのクエリが最初または最後のクエリと同じくらいパフォーマンスが高いことを示しています。巨大なリストの最後のページを繰り返しロードすることでどれだけの害が発生するか想像できますか？ 😬

自分のマシンでテストを実行することに興味がある場合は、GitHub リポジトリとして完全なソースコードを見つけることができます。リポジトリには、インストールとスクリプトの実行のプロセス全体を説明する README.md が含まれています。

👨‍🎓 まとめ

オフセットページネーション は、ページ番号が表示され、それをクリックできる、よく知られたページネーション方法を提供します。この直感的な方法には、高いオフセットでのひどいパフォーマンス や、データの重複 や データの欠落 の可能性など、多くの欠点が伴います。

カーソルページネーション はこれらすべての問題を解決し、高速で リアルタイム（頻繁に変更される）データ を処理できる信頼性の高いページネーションシステムをもたらします。カーソルページネーションの欠点は、ページ番号 を 表示しない こと、実装が複雑であること、カーソル ID の欠落などの克服すべき新しい課題があることです。

最初の質問に戻りましょう。なぜ GitHub は カーソルページネーション を使用しているのに、Amazon はオフセットページネーションを採用することにしたのでしょうか？パフォーマンスが常に鍵であるとは限りません… ユーザーエクスペリエンスは、ビジネスが支払わなければならないサーバーの数よりもはるかに価値があります。

Amazon がオフセットを採用したのは、UX を向上させる ためだと信じていますが、それはまた別の研究テーマです。amazon.com にアクセスしてペンを検索すると、正確に 10,000 件の結果があると表示されますが、最初の7ページ（350件の結果）しか表示できないことにすでに気付くことができます。

第一に、結果は10kをはるかに超えていますが、Amazon はそれを制限しています。第二に、とにかく最初の7ページにアクセスできます。8ページ目にアクセスしようとすると、404エラーが表示されます。ご覧のとおり、Amazon は オフセットページネーションのパフォーマンス を認識していますが、ユーザーベースがページ番号を見ることを好むため、それを維持することにしました。彼らは いくつかの制限を含める 必要がありましたが、検索結果の100ページ目に行く人は誰ですか？ 🤷

ページネーションについて読むよりも良いことは何か知っていますか？試してみることです！直接体験するのが一番なので、両方の方法を試してみることをお勧めします。Appwrite の設定には数分もかかりません。両方のページネーション方法をいじり始めることができます。ご質問がある場合は、Discord サーバーでお問い合わせください。

Reference

The best database pagination technique is … - DEV Community

Cookies - SameSite Attribute

Mon, 27 Feb 2023 00:00:37 +0800

Photo by Mohammad Rahmani on Unsplash

Chromeはバージョン84からCookieのSameSite属性のデフォルトをLaxにしました。Third-party cookiesを使用するサービスでSameSiteを設定していない場合は影響を受ける可能性があります。

概要

CookieはWebサービスにおいて状態を保存するための仕組みで、ログイン状態の維持、ショッピングカート、広告トラッキングなどによく使用されます。しかし、Cookieの広範な使用に伴い、プライバシーやセキュリティの懸念も生じており、それらの問題を解決するためにSameSiteが登場しました。

First-Party and Third-Party

Cookieのソース（Set-Cookie）に基づいて、各Cookieには固有のドメインがあります。ユーザーのブラウザの現在のURLを見て、Cookieのドメインが現在のURLと一致する場合はFirst-Party、そうでない場合はThird-Partyとなります。

Third-party

例えば、a.comを閲覧しているときにthird-party.comへリクエストを送信し、third-party.comからCookieを受け取ったとします。ブラウザはリクエスト時に同じドメインのCookieを自動的に含めるため、その後b.comのような他のサイトを閲覧した際にthird-party.comへリクエストが送信されると、サーバーはCookieを受け取ります。これら2つのサイトにとって、third-party.comのCookieはThird-partyとなります。

First-party

もしthird-party.comドメインに一致するWebサイトを閲覧した場合もCookieが送信されます。この場合、このCookieはFirst-partyと呼ばれます。

Same-Origin and Same-Site

先ほどの例ではドメインが一致するかどうかでCookieの種類を判定していましたが、より正確にはSiteが同じかどうかで判定すべきです。これはよく見かけるSame-originと関係があるのでしょうか？

Origin

OriginはScheme、Host、Portで構成されます。判定方法は非常にシンプルで、2つのURLのScheme、Host、Portがすべて同じであればSame-origin、そうでなければCross-originです。

Site

Same-Siteの判定にはEffective top-level domains（eTLDs）が関わってきます。すべてのeTLDsはPublic Suffix Listで定義されており、SiteはeTLDにプレフィックスを加えたもので構成されます。

例えば： github.ioはPublic Suffix Listに存在します。これにプレフィックス（例：a.github.io）を加えるとSiteになります。したがって、a.github.ioとb.github.ioは2つの異なるSite（Cross-site）です。

example.comはPublic Suffix Listに存在しませんが、.comは存在するため、example.comはSiteであり、a.example.comとb.example.comは同じSite（Same-site）となります。

SiteにはPortが含まれないため、Portが異なっていてもSame-siteになることに注意してください。

Why SameSite?

「リクエストには必ずそのドメインのCookieを含める」という仕組みは、同時にセキュリティやその他の問題をもたらしました。その中で最も重要なのがCross-site request forgery（CSRF）です。

CSRF

ユーザーがexample.comにログインしてCookieを取得したと仮定します。ユーザーが悪意のあるサイトevil.comを閲覧すると、そのサイト内のJavaScriptがexample.com/pay?amount=1000に対してPOSTリクエストを送信する可能性があります。ブラウザは自動的にexample.comのCookieを含めるため、ユーザーは知らないうちに1000ドルを支払ってしまうことになります。サーバーはこのリクエストがどこから来たのかを判断できません。

制限

Cookie自体にはFirst-party環境でのみ送信するように設定する機能がないため、リクエストはどのような環境でもCookieを含んでしまいます。サーバーはリクエストの送信元を識別できず、通常通り応答するしかありません。同時に、クライアントは無駄なCookieを送信して帯域を浪費することになります。

解決策

SameSite属性があれば、異なる環境でのCookieの送信条件を個別に設定できます。

SameSite

SameSite属性には3つの値があります。StrictまたはLaxに設定すると、Same-SiteリクエストでのみCookieを含めるように制限できます。空欄のままにした場合の動作はブラウザによって異なりますが、Chromeの場合はデフォルトでLaxです。

Strict

First-party環境でのみCookieを含めます。しかし、これには問題があります。例えば、ユーザーがexample.comでFacebookの投稿リンク（fb.comと仮定）を見たとします。ユーザーがfb.comにログインしてCookieを持っていたとしても、リンクをクリックした後、2つのサイトはCross-siteであるためCookieは送信されず、ログインページが表示されるだけになります。

そのため、Strictは投稿の削除や支払いなどの操作に適しています。

Lax

Strictの厳しすぎる制限を解決するために、Laxは以下の場合、Cross-siteであってもCookieを送信します：

アドレスバーへのURL入力
リンク<a href="...">のクリック
フォーム<form method="GET">の送信
プリレンダリング<link rel="prerender" href="...">

これらの状況には2つの共通点があります。すべてGETリクエストであり、トップレベルナビゲーション（Top-level Navigation）をトリガーすることです。これにより、Strictのように毎回再ログインが必要になる問題を回避しつつ、他のWebサイトを閲覧しているときに知らないうちにCookieを送信してしまうことも防げます。

Lax + POST

しかし、既存の一部のログインフローを壊さないように、Chromeは現在SameSite=Laxの制限を少し緩和し、開発者に猶予を与えています。

Cookieが設定されてから2分以内であれば、リクエストメソッドに関係なく、トップレベルのページ遷移をトリガーする限りCookieが送信されます。つまり、フォーム送信<form method="POST">などでブラウザがページを移動する場合です。

詳細はLax + POSTに関するスレッドをご覧ください。

None

Third-party cookieを送信したい場合は、SameSite=None; Secureを設定する必要があります。そうです、これからはテスト環境でThird-party cookieを送信したい場合は、https://localhostを準備してください。

また、XHR/FetchでCross-Origin Requestを送信する場合、Cookieを含め、レスポンスヘッダーのSet-Cookieを有効にするには、別途withCredentials: trueを設定する必要があります。そしてサーバー側はレスポンスヘッダーにAccess-Control-Allow-Credentials: trueを設定しなければ、JavaScriptはレスポンスの内容にアクセスできません。

非対応ブラウザ

すべてのブラウザが最新のSameSiteルールに対応しているわけではないため、サーバー側でいくつかの一時的な回避策（Workaround）を追加して、複数のブラウザをサポートすることができます：

両方のCookieを設定する

この方法はほぼすべてのブラウザの問題を解決できますが、欠点はCookieが2つになることです：

Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure

サーバー側のコード：

if (req.cookies['name']) {
  // 新しいものがあれば新しいものを使う
  cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
  // なければ古いものを使う
  cookieVal = req.cookies['name-legacy'];
}

User Agent

リクエストのUser agentからブラウザを判断してSet-Cookieの内容を決定します。この方法はCookieを設定するコードを修正するだけで済み、パース部分を変更する必要はありませんが、この判定方法は変数が多く、誤ったCookieを設定してしまう可能性が高くなります。

振り返り

SameSite属性が設定されていないCookieはSameSite=Laxとなり、Cross-site環境では送信できません。
Cross-siteでCookieを送信したい場合は、SameSite=None; Secureを設定する必要があります。
SameSite sandboxを使用して、現在使用しているブラウザが最新のSameSiteルールに準拠しているかどうかをテストできます。

Reference

Airbnb JavaScript スタイルガイド

Fri, 10 Feb 2023 00:00:37 +0800

Photo by Pankaj Patel on Unsplash

https://github.com/jigsawye/javascript

Airbnb JavaScript スタイルガイド()

JavaScript に対する、ほぼ妥当なアプローチ

その他のスタイルガイド

Airbnb JavaScript Style Guide から翻訳されました。

型

1.1 プリミティブ: プリミティブには直接アクセスします。

string
number
boolean
null
undefined

const foo = 1;
let bar = foo;

bar = 9;

console.log(foo, bar); // => 1, 9

1.2 複合: 複合型には参照でアクセスします。

object
array
function

const foo = [1, 2];
const bar = foo;

bar[0] = 9;

console.log(foo[0], bar[0]); // => 9, 9

参照

2.1 全ての参照には const を使用してください。var の使用は避けてください。eslint: prefer-const, no-const-assign

なぜなら、参照を再割り当てできないようにすることで、バグを減らし、コードを理解しやすくするためです。

// bad
var a = 1;
var b = 2;

// good
const a = 1;
const b = 2;

2.2 もし参照を再割り当てする必要がある場合は、var の代わりに let を使用してください。eslint: no-var jscs: disallowVar

なぜなら、let は var のような関数スコープではなく、ブロックスコープだからです。

// bad
var count = 1;
if (true) {
    count += 1;
}

// good, use the let.
let count = 1;
if (true) {
    count += 1;
}

2.3 let と const はどちらもブロックスコープであることに注意してください。

// const と let は、それらが定義されたブロック内でのみ存在します。
{
    let a = 1;
    const b = 1;
}
console.log(a); // ReferenceError
console.log(b); // ReferenceError

オブジェクト

3.1 オブジェクトを作成するときはリテラル構文を使用してください。eslint rules: no-new-object.

// bad
const item = new Object();

// good
const item = {};

3.2 キーに予約語を使用しないでください。IE8 では動作しません。詳細はこちら。ES6 モジュールやサーバーサイドのコードで使用するのは問題ありません。jscs: disallowIdentifierNames

// bad
const superman = {
    default: { clark: 'kent' },
    private: true,
};

// good
const superman = {
    defaults: { clark: 'kent' },
    hidden: true,
};

3.3 予約語の代わりに、読みやすい同義語を使用してください。jscs: disallowIdentifierNames

// bad
const superman = {
    class: 'alien',
};

// bad
const superman = {
    klass: 'alien',
};

// good
const superman = {
    type: 'alien',
};

3.4 動的なプロパティ名でオブジェクトを作成する場合は、計算されたプロパティ名（computed property names）を使用してください。

なぜなら、オブジェクトのすべてのプロパティを1か所で定義できるからです。


function getKey(k) {
    return `a key named ${k}`;
}

// bad
const obj = {
    id: 5,
    name: 'San Francisco',
};
obj[getKey('enabled')] = true;

// good
const obj = {
    id: 5,
    name: 'San Francisco',
    [getKey('enabled')]: true,
};

3.5 オブジェクトメソッドの短縮表記を使用してください。eslint: object-shorthand jscs: requireEnhancedObjectLiterals

// bad
const atom = {
    value: 1,

    addValue: function (value) {
    return atom.value + value;
    },
};

// good
const atom = {
    value: 1,

    addValue(value) {
    return atom.value + value;
    },
};

3.6 プロパティ値の短縮表記を使用してください。eslint: object-shorthand jscs: requireEnhancedObjectLiterals

なぜなら、より短く記述でき、明確だからです。

const lukeSkywalker = 'Luke Skywalker';

// bad
const obj = {
    lukeSkywalker: lukeSkywalker,
};

// good
const obj = {
    lukeSkywalker,
};

3.7 短縮表記のプロパティは、オブジェクト宣言の先頭にグループ化してください。

なぜなら、どのプロパティが短縮表記を使用しているかが分かりやすくなるからです。

const anakinSkywalker = 'Anakin Skywalker';
const lukeSkywalker = 'Luke Skywalker';

// bad
const obj = {
    episodeOne: 1,
    twoJediWalkIntoACantina: 2,
    lukeSkywalker,
    episodeThree: 3,
    mayTheFourth: 4,
    anakinSkywalker,
};

// good
const obj = {
    lukeSkywalker,
    anakinSkywalker,
    episodeOne: 1,
    twoJediWalkIntoACantina: 2,
    episodeThree: 3,
    mayTheFourth: 4,
};

3.8 無効な識別子であるプロパティのみクォートで囲んでください。eslint: quote-props jscs: disallowQuotedKeysInObjects

なぜなら、一般的に主観的に読みやすいと考えられているからです。また、シンタックスハイライトが向上し、多くの JS エンジンで最適化されやすくなります。

// bad
const bad = {
    'foo': 3,
    'bar': 4,
    'data-blah': 5,
};

// good
const good = {
    foo: 3,
    bar: 4,
    'data-blah': 5,
};

配列

4.1 配列を作成するときはリテラル構文を使用してください。eslint: no-array-constructor

// bad
const items = new Array();

// good
const items = [];

4.2 配列にアイテムを追加するときは、直接代入するのではなく Array#push を使用してください。

const someStack = [];

// bad
someStack[someStack.length] = 'abracadabra';

// good
someStack.push('abracadabra');

4.3 配列をコピーするには、スプレッド演算子 ... を使用してください。

// bad
const len = items.length;
const itemsCopy = [];
let i;

for (i = 0; i < len; i++) {
    itemsCopy[i] = items[i];
}

// good
const itemsCopy = [...items];

4.4 配列のようなオブジェクトを配列に変換するには、Array#from を使用してください。

const foo = document.querySelectorAll('.foo');
const nodes = Array.from(foo);

4.5 配列メソッドのコールバックでは return 文を使用してください。ただし、関数本体が単一の文で構成されている場合（8.2 を参照）は、return を省略しても構いません。eslint: array-callback-return

// good
[1, 2, 3].map((x) => {
    const y = x + 1;
    return x * y;
});

// good
[1, 2, 3].map(x => x + 1);

// bad
const flat = {};
[[0, 1], [2, 3], [4, 5]].reduce((memo, item, index) => {
    const flatten = memo.concat(item);
    flat[index] = memo.concat(item);
});

// good
const flat = {};
[[0, 1], [2, 3], [4, 5]].reduce((memo, item, index) => {
    const flatten = memo.concat(item);
    flat[index] = flatten;
    return flatten;
});

// bad
inbox.filter((msg) => {
    const { subject, author } = msg;
    if (subject === 'Mockingbird') {
    return author === 'Harper Lee';
    } else {
    return false;
    }
});

// good
inbox.filter((msg) => {
    const { subject, author } = msg;
    if (subject === 'Mockingbird') {
    return author === 'Harper Lee';
    }

    return false;
});

分割代入

5.1 オブジェクトの複数のプロパティにアクセスして使用する場合は、オブジェクトの分割代入を使用してください。jscs: requireObjectDestructuring

なぜなら、プロパティのための一時的な参照を作成せずに済むからです。

// bad
function getFullName(user) {
    const firstName = user.firstName;
    const lastName = user.lastName;

    return `${firstName} ${lastName}`;
}

// good
function getFullName(user) {
    const { firstName, lastName } = user;
    return `${firstName} ${lastName}`;
}

// best
function getFullName({ firstName, lastName }) {
    return `${firstName} ${lastName}`;
}

5.2 配列の分割代入を使用してください。jscs: requireArrayDestructuring

const arr = [1, 2, 3, 4];

// bad
const first = arr[0];
const second = arr[1];

// good
const [first, second] = arr;

5.3 複数の値を返す場合は、配列の分割代入ではなく、オブジェクトの分割代入を使用してください。

なぜなら、呼び出し元を壊すことなく、新しいプロパティを追加したり、順序を変更したりできるからです。

// bad
function processInput(input) {
    // then a miracle occurs
    return [left, right, top, bottom];
}

// the caller needs to think about the order of return data
const [left, __, top] = processInput(input);

// good
function processInput(input) {
    // then a miracle occurs
    return { left, right, top, bottom };
}

// the caller selects only the data they need
const { left, right } = processInput(input);

文字列

6.1 文字列にはシングルクォート '' を使用してください。eslint: quotes jscs: validateQuoteMarks

// bad
const name = "Capt. Janeway";

// good
const name = 'Capt. Janeway';

6.2 1行が100文字を超えるような文字列は、文字列連結を使って複数行に分けて書くべきではありません。
6.3 注意: 長い文字列の連結を過度に使用すると、パフォーマンスに影響を与える可能性があります。jsPerf & Discussion.

// bad
const errorMessage = 'This is a super long error that was thrown because of Batman. When you stop to think about how Batman had anything to do with this, you would get nowhere fast.';

// bad
const errorMessage = 'This is a super long error that was thrown because \
of Batman. When you stop to think about how Batman had anything to do \
with this, you would get nowhere \
fast.';

// good
const errorMessage = 'This is a super long error that was thrown because ' +
    'of Batman. When you stop to think about how Batman had anything to do ' +
    'with this, you would get nowhere fast.';

6.4 プログラムで文字列を作成する場合は、連結ではなくテンプレート文字列を使用してください。eslint: prefer-template template-curly-spacing jscs: requireTemplateStrings

なぜなら、テンプレート文字列は、適切な改行や文字列補間機能を備えた、読みやすく簡潔な構文を提供するからです。

// bad
function sayHi(name) {
    return 'How are you, ' + name + '?';
}

// bad
function sayHi(name) {
    return ['How are you, ', name, '?'].join();
}

// bad
function sayHi(name) {
    return `How are you, ${ name }?`;
}

// good
function sayHi(name) {
    return `How are you, ${name}?`;
}

6.5 文字列に対して eval() を決して使用しないでください。脆弱性が多すぎます。

関数

7.1 関数式ではなく関数宣言を使用してください。jscs: requireFunctionDeclarations

なぜなら、関数宣言には名前が付いているため、スタックトレースで識別しやすくなるからです。また、関数宣言はホイスティング（巻き上げ）されますが、関数式はされません。このルールにより、アロー関数が関数式を完全に置き換えることができます。

// bad
const foo = function () {
};

// good
function foo() {
}

7.2 IIFE (即時実行関数式): eslint: wrap-iife jscs: requireParenthesesAroundIIFE

なぜなら、IIFE は単一のユニットだからです。関数とその呼び出しの両方を括弧で囲むことで、これが明確になります。モジュールの世界では、通常 IIFE はもう必要ないことに注意してください。

// immediately-invoked function expression (IIFE)
(function () {
    console.log('Welcome to the Internet. Please follow me.');
}());

7.3 関数以外のブロック（if、while など）の中で関数を宣言しないでください。代わりに関数を変数に割り当ててください。ブラウザでは許可されていますが、それぞれの解釈が異なります。eslint: no-loop-func
7.4 注意: ECMA-262 では block を文のリストとして定義しています。関数宣言は文ではありません。この問題に関する ECMA-262 の注記を読んでください。

// bad
if (currentUser) {
    function test() {
    console.log('Nope.');
    }
}

// good
let test;
if (currentUser) {
    test = () => {
    console.log('Yup.');
    };
}

7.5 パラメータに arguments という名前を付けないでください。これは、すべての関数スコープに与えられる arguments オブジェクトよりも優先されてしまいます。

// bad
function nope(name, options, arguments) {
    // ...stuff...
}

// good
function yup(name, options, args) {
    // ...stuff...
}

7.6 arguments を使用せず、代わりに rest 構文 ... を使用してください。prefer-rest-params

なぜなら、... はどの引数を取り出すかを明示できるからです。さらに、rest 引数は arguments のような「配列のようなオブジェクト」ではなく、本物の配列です。

// bad
function concatenateAll() {
    const args = Array.prototype.slice.call(arguments);
    return args.join('');
}

// good
function concatenateAll(...args) {
    return args.join('');
}

7.7 関数の引数を変更するのではなく、デフォルトパラメータ構文を使用してください。

// really bad
function handleThings(opts) {
    // No! We shouldn't mutate function arguments.
    // Double bad: if opts is false it will be set to an object which may
    // be what you want but it can cause subtle bugs.
    opts = opts || {};
    // ...
}

// still bad
function handleThings(opts) {
    if (opts === void 0) {
    opts = {};
    }
    // ...
}

// good
function handleThings(opts = {}) {
    // ...
}

7.8 デフォルトパラメータでの副作用は避けてください。

なぜなら、動作を理解するのが混乱するからです。

var b = 1;
// bad
function count(a = b++) {
    console.log(a);
}
count();  // 1
count();  // 2
count(3); // 3
count();  // 3

7.9 デフォルトパラメータは常に最後に置いてください。

// bad
function handleThings(opts = {}, name) {
    // ...
}

// good
function handleThings(name, opts = {}) {
    // ...
}

7.10 新しい関数を作成するために Function コンストラクタを使用しないでください。

なぜなら、この方法で関数を作成すると、eval() と同様に文字列が評価され、脆弱性を引き起こす可能性があるからです。

// bad
var add = new Function('a', 'b', 'return a + b');

// still bad
var subtract = Function('a', 'b', 'return a - b');

7.11 関数シグネチャの空白。

なぜなら、一貫性は良いことですし、名前を追加または削除するときにスペースを追加または削除する必要がないからです。

// bad
const f = function(){};
const g = function (){};
const h = function() {};

// good
const x = function () {};
const y = function a() {};

7.12 パラメータを決して変更（mutate）しないでください。eslint: no-param-reassign

なぜなら、パラメータとして渡されたオブジェクトを操作すると、呼び出し元で予期しない変数の副作用が発生する可能性があるからです。

// bad
function f1(obj) {
    obj.key = 1;
};

// good
function f2(obj) {
    const key = Object.prototype.hasOwnProperty.call(obj, 'key') ? obj.key : 1;
};

7.13 パラメータに再代入しないでください。eslint: no-param-reassign

なぜなら、パラメータへの再代入は、特に arguments オブジェクトにアクセスする場合に予期しない動作を引き起こす可能性があるからです。また、特に V8 エンジンでは最適化の問題を引き起こす可能性もあります。

```javascript
// bad
function f1(a) {
a = 1;
}

function f2(a) {
if (!a) { a = 1; }
}

// good
function f3(a) {
const b = a || 1;
}

function f4(a = 1) {
}
```

アロー関数

8.1 関数式を使用する必要がある場合（匿名関数を渡す場合など）は、アロー関数記法を使用してください。eslint: prefer-arrow-callback, arrow-spacing jscs: requireArrowFunctions

なぜなら、これは this のコンテキストで実行されるバージョンの関数を作成し（通常はこれが望ましい動作です）、構文もより簡潔だからです。

なぜダメなのか？かなり複雑な関数の場合は、そのロジックを独自の関数宣言に移動した方がよいかもしれません。

// bad
[1, 2, 3].map(function (x) {
    const y = x + 1;
    return x * y;
});

// good
[1, 2, 3].map((x) => {
    const y = x + 1;
    return x * y;
});

8.2 関数本体が副作用のない式を返す単一の文で構成されている場合は、中括弧を省略し、暗黙の return を使用してください。それ以外の場合は、中括弧を保持し、return 文を使用してください。eslint: arrow-parens, arrow-body-style jscs: disallowParenthesesAroundArrowParam, requireShorthandArrowFunctions

なぜなら、シンタックスシュガーだからです。複数の関数を連鎖させる場合に読みやすくなります。

なぜダメなのか？オブジェクトを返す予定がある場合。

// bad
[1, 2, 3].map(number => {
    const nextNumber = number + 1;
    `A string containing the ${nextNumber}.`;
});

// good
[1, 2, 3].map(number => `A string containing the ${number}.`);

// good
[1, 2, 3].map((number) => {
    const nextNumber = number + 1;
    return `A string containing the ${nextNumber}.`;
});

8.3 式が複数行にまたがる場合は、読みやすくするために括弧で囲んでください。

なぜなら、関数の開始と終了が明確になるからです。

// bad
[1, 2, 3].map(number => 'As time went by, the string containing the ' +
    `${number} became much longer. So we needed to break it over multiple ` +
    'lines.'
);

// good
[1, 2, 3].map(number => (
    `As time went by, the string containing the ${number} became much ` +
    'longer. So we needed to break it over multiple lines.'
));

8.4 関数が単一の引数を取り、中括弧を使用しない場合は、括弧を省略してください。それ以外の場合は、常に引数を括弧で囲んでください。eslint: arrow-parens jscs: disallowParenthesesAroundArrowParam

なぜなら、見た目がすっきりするからです。

// bad
[1, 2, 3].map((x) => x * x);

// good
[1, 2, 3].map(x => x * x);

```javascript
// good
[1, 2, 3].map(number => (
    `A long string with the ${number}. It’s so long that we’ve broken it ` +
    'over multiple lines!'
));

// bad
[1, 2, 3].map(x => {
    const y = x + 1;
    return x * y;
});

// good
[1, 2, 3].map((x) => {
    const y = x + 1;
    return x * y;
});

8.5 アロー関数構文 (=>) と比較演算子 (<=, >=) を混同しないようにしてください。eslint: no-confusing-arrow

// bad
const itemHeight = item => item.height > 256 ? item.largeSize : item.smallSize;

// bad
const itemHeight = (item) => item.height > 256 ? item.largeSize : item.smallSize;

// good
const itemHeight = item => { return item.height > 256 ? item.largeSize : item.smallSize; }

クラス

9.1 常に class を使用してください。prototype を直接操作することは避けてください。

なぜなら、class 構文の方が簡潔で、論理的に理解しやすいからです。

// bad
function Queue(contents = []) {
    this._queue = [...contents];
}
Queue.prototype.pop = function () {
    const value = this._queue[0];
    this._queue.splice(0, 1);
    return value;
}


// good
class Queue {
    constructor(contents = []) {
    this._queue = [...contents];
    }
    pop() {
    const value = this._queue[0];
    this._queue.splice(0, 1);
    return value;
    }
}

9.2 継承には extends を使用してください。

なぜなら、これは instanceof を破壊することなくプロトタイプから機能を継承する組み込みの方法だからです。

// bad
const inherits = require('inherits');
function PeekableQueue(contents) {
    Queue.apply(this, contents);
}
inherits(PeekableQueue, Queue);
PeekableQueue.prototype.peek = function () {
    return this._queue[0];
}

// good
class PeekableQueue extends Queue {
    peek() {
    return this._queue[0];
    }
}

9.3 メソッドチェーンを助けるために、メソッド内で this を返すことができます。

// bad
Jedi.prototype.jump = function () {
    this.jumping = true;
    return true;
};

Jedi.prototype.setHeight = function (height) {
    this.height = height;
};

const luke = new Jedi();
luke.jump(); // => true
luke.setHeight(20); // => undefined

// good
class Jedi {
    jump() {
    this.jumping = true;
    return this;
    }

    setHeight(height) {
    this.height = height;
    return this;
    }
}

const luke = new Jedi();

luke.jump()
    .setHeight(20);

9.4 カスタムの toString() メソッドを作成しても構いませんが、正しく動作し、副作用がないことを確認してください。

class Jedi {
    constructor(options = {}) {
    this.name = options.name || 'no name';
    }

    getName() {
    return this.name;
    }

    toString() {
    return `Jedi - ${this.getName()}`;
    }
}

9.5 指定されていない場合、クラスにはデフォルトのコンストラクタがあります。空のコンストラクタや、単に親クラスに委譲するだけのコンストラクタは不要です。no-useless-constructor

// bad
class Jedi {
    constructor() {}

    getName() {
    return this.name;
    }
}

// bad
class Rey extends Jedi {
    constructor(...args) {
    super(...args);
    }
}

// good
class Rey extends Jedi {
    constructor(...args) {
    super(...args);
    this.name = 'Rey';
    }
}

モジュール

10.1 非標準のモジュールシステムよりも、常にモジュール (import/export) を使用してください。いつでも好みのモジュールシステムにトランスパイルできます。

なぜなら、モジュールは未来の標準であり、今から未来を使い始めるべきだからです。

// bad
const AirbnbStyleGuide = require('./AirbnbStyleGuide');
module.exports = AirbnbStyleGuide.es6;

// ok
import AirbnbStyleGuide from './AirbnbStyleGuide';
export default AirbnbStyleGuide.es6;

// best
import { es6 } from './AirbnbStyleGuide';
export default es6;

10.2 ワイルドカードインポートは使用しないでください。

なぜなら、これにより単一のデフォルトエクスポートを持つことが保証されるからです。

// bad
import * as AirbnbStyleGuide from './AirbnbStyleGuide';

// good
import AirbnbStyleGuide from './AirbnbStyleGuide';

10.3 また、インポートから直接エクスポートしないでください。

なぜなら、一行で書けるのは簡潔ですが、インポートとエクスポートを明確に分けることで一貫性が保たれるからです。

// bad
// filename es6.js
export { es6 as default } from './airbnbStyleGuide';

// good
// filename es6.js
import { es6 } from './AirbnbStyleGuide';
export default es6;

イテレータとジェネレータ

11.1 イテレータを使用しないでください。for-of ループの代わりに、map() や reduce() のような JavaScript の高階関数を使用してください。eslint: no-iterator

なぜなら、これは不変性のルールを強制するためです。副作用を扱うよりも、値を返す純粋関数を扱う方が論理的に理解しやすいからです。

eslint rules: no-iterator.

const numbers = [1, 2, 3, 4, 5];

// bad
let sum = 0;
for (let num of numbers) {
    sum += num;
}

sum === 15;

// good
let sum = 0;
numbers.forEach(num => sum += num);
sum === 15;

// best (use the functional force)
const sum = numbers.reduce((total, num) => total + num, 0);
sum === 15;

11.2 ジェネレータは今のところ使用しないでください。

なぜなら、まだ ES5 へのトランスパイルが完全ではないからです。

プロパティ

12.1 プロパティにアクセスするときはドット記法を使用してください。eslint: dot-notation jscs: requireDotNotation

const luke = {
    jedi: true,
    age: 28,
};

// bad
const isJedi = luke['jedi'];

// good
const isJedi = luke.jedi;

12.2 変数を使ってプロパティにアクセスするときはブラケット記法 [] を使用してください。

const luke = {
    jedi: true,
    age: 28,
};

function getProp(prop) {
    return luke[prop];
}

const isJedi = getProp('jedi');

変数

13.1 変数を宣言するときは常に const または let を使用してください。そうしないとグローバル変数になってしまいます。グローバル名前空間の汚染は避けたいものです。キャプテン・プラネットもそう警告していました。

// bad
superPower = new SuperPower();

// good
const superPower = new SuperPower();

13.2 変数ごとに const または let 宣言を1つ使用してください。eslint: one-var jscs: disallowMultipleVarDecl

なぜなら、この方が新しい変数の宣言を追加しやすく、; を , に置き換えたり、句読点だけの差分が発生したりする心配がないからです。

// bad
const items = getItems(),
    goSportsTeam = true,
    dragonball = 'z';

// bad
// (compare to above, notice the error)
const items = getItems(),
    goSportsTeam = true;
    dragonball = 'z';

// good
const items = getItems();
const goSportsTeam = true;
const dragonball = 'z';

13.3 すべての const をグループ化し、次にすべての let をグループ化してください。

なぜなら、後になって以前に割り当てられた変数に基づいて変数を割り当てる必要がある場合に役立つからです。

// bad
let i, len, dragonball,
    items = getItems(),
    goSportsTeam = true;

// bad
let i;
const items = getItems();
let dragonball;
const goSportsTeam = true;
let len;

// good
const goSportsTeam = true;
const items = getItems();
let dragonball;
let i;
let length;

13.4 変数は必要な場所で割り当てますが、妥当な場所に配置してください。

なぜなら、let と const は関数スコープではなくブロックスコープだからです。

// bad - unnecessary function call
function checkName(hasName) {
    const name = getName();

    if (hasName === 'test') {
    return false;
    }

    if (name === 'test') {
    this.setName('');
    return false;
    }

    return name;
}

// good
function checkName(hasName) {
    if (hasName === 'test') {
    return false;
    }

    const name = getName();

    if (name === 'test') {
    this.setName('');
    return false;
    }

    return name;
}

ホイスティング

14.1 var 宣言はスコープの先頭に巻き上げられますが、その代入は巻き上げられません。const と let 宣言には、Temporal Dead Zones (TDZ) と呼ばれる新しい概念があります。なぜ typeof がもはや安全ではないのかを知ることは重要です。

// we know this wouldn't work (assuming there
// is no notDefined global variable)
function example() {
    console.log(notDefined); // => throws a ReferenceError
}

// creating a variable declaration after you
// reference the variable will work due to
// variable hoisting. Note: the assignment
// value of `true` is not hoisted.
function example() {
    console.log(declaredButNotAssigned); // => undefined
    var declaredButNotAssigned = true;
}

// The interpreter is hoisting the variable
// declaration to the top of the scope,
// which means our example could be rewritten as:
function example() {
    let declaredButNotAssigned;
    console.log(declaredButNotAssigned); // => undefined
    declaredButNotAssigned = true;
}

// using const and let
function example() {
    console.log(declaredButNotAssigned); // => throws a ReferenceError
    console.log(typeof declaredButNotAssigned); // => throws a ReferenceError
    const declaredButNotAssigned = true;
}

14.2 匿名関数式は変数名を巻き上げますが、関数の代入は巻き上げません。

function example() {
    console.log(anonymous); // => undefined

    anonymous(); // => TypeError anonymous is not a function

    var anonymous = function () {
    console.log('anonymous function expression');
    };
}

14.3 名前付き関数式は変数名を巻き上げますが、関数名や関数本体は巻き上げません。

function example() {
    console.log(named); // => undefined

    named(); // => TypeError named is not a function

    superPower(); // => ReferenceError superPower is not defined

    var named = function superPower() {
    console.log('Flying');
    };
}

// the same is true when the function name
// is the same as the variable name.
function example() {
    console.log(named); // => undefined

    named(); // => TypeError named is not a function

    var named = function named() {
    console.log('named');
    }
}

14.4 関数宣言は、その名前と関数本体を巻き上げます。

function example() {
    superPower(); // => Flying

    function superPower() {
    console.log('Flying');
    }
}

詳細については、Ben Cherry による JavaScript Scoping & Hoisting を参照してください。

比較演算子と等価性

15.1 == や != よりも === と !== を使用してください。eslint: eqeqeq
15.2 if 文などの条件文は、ToBoolean 抽象メソッドによる強制型変換を使用して式を評価し、常に以下の単純なルールに従います：

オブジェクト は true と評価されます
Undefined は false と評価されます
Null は false と評価されます
ブール値 は そのブール値 と評価されます
数値は +0, -0, NaN の場合は false、それ以外は true と評価されます
文字列 は空文字 '' の場合は false、それ以外は true と評価されます

if ([0] && []) {
    // true
    // an array (even an empty one) is an object, objects will evaluate to true
}

15.3 ショートカットを使用してください。

// bad
if (name !== '') {
    // ...stuff...
}

// good
if (name) {
    // ...stuff...
}

// bad
if (collection.length > 0) {
    // ...stuff...
}

// good
if (collection.length) {
    // ...stuff...
}

15.4 詳細については、Angus Croll による Truth Equality and JavaScript を参照してください。
15.5 レキシカル宣言（let、const、function、class など）を含む case や default 節では、ブロックを作成するために中括弧を使用してください。

なぜなら、レキシカル宣言は switch ブロック全体で可視ですが、初期化されるのは割り当て時のみであり、それはその case に到達したときだけだからです。複数の case 節が同じものを定義しようとすると問題が発生します。

eslint rules: no-case-declarations.

// bad
switch (foo) {
    case 1:
    let x = 1;
    break;
    case 2:
    const y = 2;
    break;
    case 3:
    function f() {}
    break;
    default:
    class C {}
}

// good
switch (foo) {
    case 1: {
    let x = 1;
    break;
    }
    case 2: {
    const y = 2;
    break;
    }
    case 3: {
    function f() {}
    break;
    }
    case 4:
    bar();
    break;
    default: {
    class C {}
    }
}

15.7 三項演算子はネストすべきではなく、通常は1行の式にするべきです。

eslint rules: no-nested-ternary.

// bad
const foo = maybe1 > maybe2
    ? "bar"
    : value1 > value2 ? "baz" : null;

// better
const maybeNull = value1 > value2 ? 'baz' : null;

const foo = maybe1 > maybe2
    ? 'bar'
    : maybeNull;

// best
const maybeNull = value1 > value2 ? 'baz' : null;

const foo = maybe1 > maybe2 ? 'bar' : maybeNull;

15.8 不要な三項演算子は避けてください。

eslint rules: no-unneeded-ternary.

// bad
const foo = a ? a : b;
const bar = c ? true : false;
const baz = c ? false : true;

// good
const foo = a || b;
const bar = !!c;
const baz = !c;

ブロック

16.1 すべての複数行ブロックには中括弧を使用してください。

// bad
if (test)
    return false;

// good
if (test) return false;

// good
if (test) {
    return false;
}

// bad
function foo() { return false; }

// good
function bar() {
    return false;
}

16.2 if と else を使った複数行ブロックを使用する場合は、else を if ブロックの閉じ括弧と同じ行に置いてください。eslint: brace-style jscs: disallowNewlineBeforeBlockStatements

// bad
if (test) {
    thing1();
    thing2();
}
else {
    thing3();
}

// good
if (test) {
    thing1();
    thing2();
} else {
    thing3();
}

制御文

17.1 制御文（if, while など）が長くなりすぎたり、最大行長を超える場合は、各（グループ化された）条件を新しい行に置くことができます。論理演算子は行の先頭に置くべきです。

なぜなら、演算子を行頭に置くことで演算子の位置が揃い、メソッドチェーンと同様のパターンに従うことができるからです。また、複雑なロジックを視覚的に把握しやすくなり、可読性が向上します。

// bad
if ((foo === 123 || bar === 'abc') && doesItLookGoodWhenItBecomesThatLong() && isThisReallyHappening()) {
    thing1();
}

// bad
if (foo === 123 &&
    bar === 'abc') {
    thing1();
}

// bad
if (foo === 123
    && bar === 'abc') {
    thing1();
}

// bad
if (
    foo === 123 &&
    bar === 'abc'
) {
    thing1();
}

// good
if (
    foo === 123
    && bar === 'abc'
) {
    thing1();
}

// good
if (
    (foo === 123 || bar === 'abc')
    && doesItLookGoodWhenItBecomesThatLong()
    && isThisReallyHappening()
) {
    thing1();
}

// good
if (foo === 123 && bar === 'abc') {
    thing1();
}

17.2 制御文の代わりに選択演算子を使用しないでください。

// bad
!isRunning && startRunning();

// good
if (!isRunning) {
    startRunning();
}

18.1 複数行のコメントには /** ... */ を使用してください。説明を含め、すべてのパラメータと戻り値の型と値を指定してください。

// bad
// make() returns a new element
// based on the passed in tag name
//
// @param {String} tag
// @return {Element} element
function make(tag) {

    // ...stuff...

    return element;
}

// good
/**
 * make() returns a new element
 * based on the passed in tag name
 *
 * @param {String} tag
 * @return {Element} element
 */
function make(tag) {

    // ...stuff...

    return element;
}

18.2 1行コメントには // を使用してください。1行コメントは、コメントの対象となる行の上に新しい行で配置してください。ブロックの最初の行でない限り、コメントの前には空行を入れてください。

// bad
const active = true;  // is current tab

// good
// is current tab
const active = true;

// bad
function getType() {
    console.log('fetching type...');
    // set the default type to 'no type'
    const type = this._type || 'no type';

    return type;
}

// good
function getType() {
    console.log('fetching type...');

    // set the default type to 'no type'
    const type = this._type || 'no type';

    return type;
}

// also good
function getType() {
    // set the default type to 'no type'
    const type = this._type || 'no type';

    return type;
}

18.3 コメントの先頭に FIXME や TODO を付けると、他の開発者が、再検討が必要な問題を指摘しているのか、実装が必要な解決策を提案しているのかを素早く理解するのに役立ちます。これらは通常のコメントとは異なり、実行可能（actionable）です。アクションは FIXME: -- これを解決する必要がある または TODO: -- これを実装する必要がある です。
18.4 問題を注釈するには // FIXME: を使用してください。

class Calculator extends Abacus {
    constructor() {
    super();

    // FIXME: shouldn't use a global here
    total = 0;
    }
}

18.5 問題の解決策を注釈するには // TODO: を使用してください。

class Calculator extends Abacus {
    constructor() {
    super();

    // TODO: total should be configurable by an options param
    this.total = 0;
    }
}

空白

19.1 ソフトタブ（スペース文字）を使用し、2スペースに設定してください。eslint: indent jscs: validateIndentation

// bad
function foo() {
∙∙∙∙const name;
}

// bad
function bar() {
∙const name;
}

// good
function baz() {
∙∙const name;
}

19.2 開始中括弧の前にスペースを1つ置いてください。eslint: space-before-blocks jscs: requireSpaceBeforeBlockStatements

// bad
function test(){
    console.log('test');
}

// good
function test() {
    console.log('test');
}

// bad
dog.set('attr',{
    age: '1 year',
    breed: 'Bernese Mountain Dog',
});

// good
dog.set('attr', {
    age: '1 year',
    breed: 'Bernese Mountain Dog',
});

19.3 制御文（if, while など）の開き括弧の前にはスペースを1つ置いてください。関数呼び出しや各宣言の引数リストと関数名の間にはスペースを入れないでください。eslint: space-after-keywords, space-before-keywords jscs: requireSpaceAfterKeywords

// bad
if(isJedi) {
    fight ();
}

// good
if (isJedi) {
    fight();
}

// bad
function fight () {
    console.log ('Swooosh!');
}

// good
function fight() {
    console.log('Swooosh!');
}

19.4 演算子の間にはスペースを入れてください。eslint: space-infix-ops jscs: requireSpaceBeforeBinaryOperators, requireSpaceAfterBinaryOperators

// bad
const x=y+5;

// good
const x = y + 5;

19.5 ファイルの末尾は単一の改行文字で終了してください。

// bad
(function (global) {
    // ...stuff...
})(this);

// bad
(function (global) {
    // ...stuff...
})(this);↵
↵

// good
(function (global) {
    // ...stuff...
})(this);↵

19.6 長いメソッドチェーン（2つ以上のメソッドチェーン）を作成する場合は、インデントを使用してください。先頭にドットを使用することで、その行が新しい文ではなくメソッド呼び出しであることを強調します。eslint: newline-per-chained-call no-whitespace-before-property

// bad
$('#items').find('.selected').highlight().end().find('.open').updateCount();

// bad
$('#items').
    find('.selected').
    highlight().
    end().
    find('.open').
    updateCount();

// good
$('#items')
    .find('.selected')
    .highlight()
    .end()
    .find('.open')
    .updateCount();

// bad
const leds = stage.selectAll('.led').data(data).enter().append('svg:svg').classed('led', true)
    .attr('width', (radius + margin) * 2).append('svg:g')
    .attr('transform', 'translate(' + (radius + margin) + ',' + (radius + margin) + ')')
    .call(tron.led);

// good
const leds = stage.selectAll('.led')
    .data(data)
    .enter().append('svg:svg')
    .classed('led', true)
    .attr('width', (radius + margin) * 2)
    .append('svg:g')
    .attr('transform', 'translate(' + (radius + margin) + ',' + (radius + margin) + ')')
    .call(tron.led);

// good
const leds = stage.selectAll('.led').data(data);

19.7 ブロックの後、次の文の前には空行を入れてください。jscs: requirePaddingNewLinesAfterBlocks

// bad
if (foo) {
    return bar;
}
return baz;

// good
if (foo) {
    return bar;
}

return baz;

// bad
const obj = {
    foo() {
    },
    bar() {
    },
};
return obj;

// good
const obj = {
    foo() {
    },

    bar() {
    },
};

return obj;

// bad
const arr = [
    function foo() {
    },
    function bar() {
    },
];
return arr;

// good
const arr = [
    function foo() {
    },

    function bar() {
    },
];

return arr;

19.8 ブロック内を空行でパディングしないでください。eslint: padded-blocks jscs: disallowPaddingNewlinesInBlocks

// bad
function bar() {

    console.log(foo);

}

// also bad
if (baz) {

    console.log(qux);
} else {
    console.log(foo);

}

// good
function bar() {
    console.log(foo);
}

// good
if (baz) {
    console.log(qux);
} else {
    console.log(foo);
}

19.9 括弧の内側に空白を追加しないでください。eslint: space-in-parens jscs: disallowSpacesInsideParentheses

// bad
function bar( foo ) {
    return foo;
}

// good
function bar(foo) {
    return foo;
}

// bad
if ( foo ) {
    console.log(foo);
}

// good
if (foo) {
    console.log(foo);
}

19.10 ブラケット（角括弧）の内側に空白を追加しないでください。eslint: array-bracket-spacing jscs: disallowSpacesInsideArrayBrackets

// bad
const foo = [ 1, 2, 3 ];
console.log(foo[ 0 ]);

// good
const foo = [1, 2, 3];
console.log(foo[0]);

19.11 波括弧の内側には空白を追加してください。eslint: object-curly-spacing jscs: [disallowSpacesInsideObjectBrackets](http://jscs.info/rule/

// bad
const foo = {clark: 'kent'};

// good
const foo = { clark: 'kent' };

19.12 行の長さは100文字（空白を含む）を超えないようにしてください。eslint: max-len jscs: maximumLineLength

なぜなら、可読性と保守性が確保されるからです。

// bad
const foo = 'Whatever national crop flips the window. The cartoon reverts within the screw. Whatever wizard constrains a helpful ally. The counterpart ascends!';

// bad
$.ajax({ method: 'POST', url: 'https://airbnb.com/', data: { name: 'John' } }).done(() => console.log('Congratulations!')).fail(() => console.log('You have failed this city.'));

// good
const foo = 'Whatever national crop flips the window. The cartoon reverts within the screw. ' +
    'Whatever wizard constrains a helpful ally. The counterpart ascends!';

// good
$.ajax({
    method: 'POST',
    url: 'https://airbnb.com/',
    data: { name: 'John' },
})
    .done(() => console.log('Congratulations!'))
    .fail(() => console.log('You have failed this city.'));

カンマ

20.1 先頭のカンマ: **ダメです。**eslint: comma-style jscs: requireCommaBeforeLineBreak

// bad
const story = [
    once
    , upon
    , aTime
];

// good
const story = [
    once,
    upon,
    aTime,
];

// bad
const hero = {
    firstName: 'Ada'
    , lastName: 'Lovelace'
    , birthYear: 1815
    , superPower: 'computers'
};

// good
const hero = {
    firstName: 'Ada',
    lastName: 'Lovelace',
    birthYear: 1815,
    superPower: 'computers',
};

20.2 末尾のカンマの追加: **いいですね。**eslint: comma-dangle jscs: requireTrailingComma

なぜなら、これにより Git の差分がきれいになるからです。また、Babel などのトランスパイラはトランスパイル後のコードで余分な末尾のカンマを削除するため、レガシーブラウザにおける末尾のカンマの問題を心配する必要がありません。

// bad - git diff without trailing comma
const hero = {
        firstName: 'Florence',
    lastName: 'Nightingale'
+    lastName: 'Nightingale',
+    inventorOf: ['coxcomb graph', 'modern nursing']
};

// good - git diff with trailing comma
const hero = {
        firstName: 'Florence',
        lastName: 'Nightingale',
+    inventorOf: ['coxcomb chart', 'modern nursing'],
};

// bad
const hero = {
    firstName: 'Dana',
    lastName: 'Scully'
};

const heroes = [
    'Batman',
    'Superman'
];

// good
const hero = {
    firstName: 'Dana',
    lastName: 'Scully',
};

const heroes = [
    'Batman',
    'Superman',
];

セミコロン

21.1 **はい。**eslint: semi jscs: requireSemicolons

// bad
(function () {
    const name = 'Skywalker'
    return name
})()

// good
(() => {
    const name = 'Skywalker';
    return name;
}());

// good (guards against the function becoming an argument when two files with IIFEs are concatenated)
;(() => {
    const name = 'Skywalker';
    return name;
}());

詳細はこちら。

型変換と強制

22.1 文の先頭で型強制を行ってください。
22.2 文字列:

// => this.reviewScore = 9;

// bad
const totalScore = this.reviewScore + '';

// good
const totalScore = String(this.reviewScore);

22.3 数値: 型キャストには Number を使用し、文字列の解析には常に基数（radix）を指定して parseInt を使用してください。eslint: radix

const inputValue = '4';

// bad
const val = new Number(inputValue);

// bad
const val = +inputValue;

// bad
const val = inputValue >> 0;

// bad
const val = parseInt(inputValue);

// good
const val = Number(inputValue);

// good
const val = parseInt(inputValue, 10);

22.4 何らかの理由でクレイジーなことをしていて parseInt がボトルネックになっており、パフォーマンス上の理由でビットシフトを使用する必要がある場合は、その理由と行っている内容を説明するコメントを残してください。

// good
/**
 * parseInt was the reason my code was slow.
 * Bitshifting the String to coerce it to a
 * Number made it a lot faster.
 */
const val = inputValue >> 0;

22.5 注意: ビットシフト操作を使用する場合は注意してください。数値は 64ビット値として表現されますが、ビットシフト操作は常に32ビット整数を返します (source)。ビットシフトは、32ビットを超える整数値に対して予期しない動作を引き起こす可能性があります。Discussion。符号付き32ビット整数の最大値は 2,147,483,647 です：

2147483647 >> 0 //=> 2147483647
2147483648 >> 0 //=> -2147483648
2147483649 >> 0 //=> -2147483647

22.6 ブール値:

const age = 0;

// bad
const hasAge = new Boolean(age);

// good
const hasAge = Boolean(age);

// good
const hasAge = !!age;

命名規則

23.1 1文字の名前は避けてください。名前は説明的にしてください。

// bad
function q() {
    // ...stuff...
}

// good
function query() {
    // ..stuff..
}

23.2 オブジェクト、関数、インスタンスの名前にはキャメルケース（camelCase）を使用してください。eslint: camelcase jscs: requireCamelCaseOrUpperCaseIdentifiers

// bad
const OBJEcttsssss = {};
const this_is_my_object = {};
function c() {}

// good
const thisIsMyObject = {};
function thisIsMyFunction() {}

23.3 コンストラクタやクラスの名前にのみパスカルケース（PascalCase）を使用してください。eslint: new-cap jscs: requireCapitalizedConstructors

// bad
function user(options) {
    this.name = options.name;
}

const bad = new user({
    name: 'nope',
});

// good
class User {
    constructor(options) {
    this.name = options.name;
    }
}

const good = new User({
    name: 'yup',
});

23.4 プライベートプロパティに名前を付けるときは、先頭にアンダースコア _ を使用してください。eslint: no-underscore-dangle jscs: disallowDanglingUnderscores

// bad
this.__firstName__ = 'Panda';
this.firstName_ = 'Panda';

// good
this._firstName = 'Panda';

23.5 this への参照を保存しないでください。アロー関数または Function#bind を使用してください。jscs: disallowNodeTypes

// bad
function foo() {
    const self = this;
    return function () {
    console.log(self);
    };
}

// bad
function foo() {
    const that = this;
    return function () {
    console.log(that);
    };
}

// good
function foo() {
    return () => {
    console.log(this);
    };
}

23.6 ファイルが単一のクラスをエクスポートする場合は、ファイル名はクラス名と完全に一致させてください。

// file contents
class CheckBox {
    // ...
}
export default CheckBox;

// in some other file
// bad
import CheckBox from './checkBox';

// bad
import CheckBox from './check_box';

// good
import CheckBox from './CheckBox';

23.7 デフォルトの関数をエクスポートする場合はキャメルケースを使用してください。ファイル名は関数名と同じにしてください。

function makeStyleGuide() {
}

export default makeStyleGuide;

23.8 シングルトン / 関数ライブラリ / 空のオブジェクトをエクスポートする場合はパスカルケースを使用してください。

const AirbnbStyleGuide = {
    es6: {
    }
};

export default AirbnbStyleGuide;

アクセサ

24.1 プロパティのアクセサ関数は必須ではありません。
24.2 JavaScript のゲッター/セッターは使用しないでください。これらは予期しない副作用を引き起こし、テストや保守、推論が難しくなるためです。代わりに、アクセサ関数を作成する場合は、getVal() や setVal(‘hello’) を使用してください。

// bad
dragon.age();

// good
dragon.getAge();

// bad
dragon.age(25);

// good
dragon.setAge(25);

24.3 プロパティがブール値の場合は、isVal() または hasVal() を使用してください。

// bad
if (!dragon.age()) {
    return false;
}

// good
if (!dragon.hasAge()) {
    return false;
}

24.4 get() および set() 関数を作成しても構いませんが、一貫性を持たせてください。

class Jedi {
    constructor(options = {}) {
    const lightsaber = options.lightsaber || 'blue';
    this.set('lightsaber', lightsaber);
    }

    set(key, val) {
    this[key] = val;
    }

    get(key) {
    return this[key];
    }
}

イベント

25.1 イベントにデータペイロードを添付する場合（DOM イベントであれ、Backbone イベントのような独自のイベントであれ）、生の値ではなくハッシュ（オブジェクト）を渡してください。これにより、後の貢献者がイベントのすべてのハンドラを見つけて更新することなく、イベントペイロードにデータを追加できます。例えば、次のような書き方ではなく：

// bad
$(this).trigger('listingUpdated', listing.id);

...

$(this).on('listingUpdated', (e, listingId) => {
    // do something with listingId
});

次のように書いてください：

// good
$(this).trigger('listingUpdated', { listingId: listing.id });

...

$(this).on('listingUpdated', (e, data) => {
    // do something with data.listingId
});

jQuery

26.1 jQuery オブジェクト変数の先頭には $ を付けてください。jscs: requireDollarBeforejQueryAssignment

// bad
const sidebar = $('.sidebar');

// good
const $sidebar = $('.sidebar');

// good
const $sidebarBtn = $('.sidebar-btn');

26.2 jQuery の検索結果をキャッシュしてください。

// bad
function setSidebar() {
    $('.sidebar').hide();

    // ...stuff...

    $('.sidebar').css({
    'background-color': 'pink'
    });
}

// good
function setSidebar() {
    const $sidebar = $('.sidebar');
    $sidebar.hide();

    // ...stuff...

    $sidebar.css({
    'background-color': 'pink'
    });
}

26.3 DOM クエリには、カスケード $('.sidebar ul') または親 > 子 $('.sidebar > ul') を使用してください。jsPerf
26.4 スコープ付き jQuery オブジェクトクエリで find を使用してください。

// bad
$('ul', '.sidebar').hide();

// bad
$('.sidebar').find('ul').hide();

// good
$('.sidebar ul').hide();

// good
$('.sidebar > ul').hide();

// good
$sidebar.find('ul').hide();

ECMAscript 5 互換性

27.1 Kangax の ES5 互換性テーブルを参照してください。

ECMAScript 6 スタイル

28.1 以下は、様々な ES6 機能へのリンク集です。

標準ライブラリ

標準ライブラリには、機能が壊れているものの、レガシーな理由で残されている機能的ユーティリティがいくつか含まれています。

29.1 isNaN の代わりに Number.isNaN を使用してください。

なぜなら、isNaN は非数値を数値に強制変換し、NaN に変換されるものすべてに対して true を返すからです。もしこの動作が望ましい場合は、明示的に行ってください。

// bad
isNaN('1.2'); // false
isNaN('1.2.3'); // true

// good
Number.isNaN('1.2.3'); // false
Number.isNaN(Number('1.2.3')); // true

29.2 isFinite の代わりに Number.isFinite を使用してください。

なぜなら、isFinite は非数値を数値に強制変換し、有限数に変換されるものすべてに対して true を返すからです。もしこの動作が望ましい場合は、明示的に行ってください。

// bad
isFinite('2e3'); // true

// good
Number.isFinite('2e3'); // false
Number.isFinite(parseInt('2e3', 10)); // true

テスト

30.1 はい。

function foo() {
    return true;
}

30.2 冗談はさておき:
どのテストフレームワークを使用するにしても、テストを書くべきです！
多くの小さな純粋関数を書くように努め、変更（mutation）が発生する場所を最小限に抑えてください。
スタブやモックには注意してください - テストが脆くなる可能性があります。
Airbnb では主に mocha を使用しています。tape も小さな独立したモジュールで時々使用されます。
100% のテストカバレッジを目指すことは良い目標ですが、常にそれが現実的であるとは限りません。
バグを修正するたびに、回帰テストを書いてください。回帰テストなしで修正されたバグは、将来ほぼ確実に再び発生します。

パフォーマンス

リソース

Learning ES6

Read This

Standard ECMA-262

Tools

Code Style Linters

Other Style Guides

Other Styles

Naming this in nested functions - Christian Johansen
Conditional Callbacks - Ross Allen
Popular JavaScript Coding Conventions on Github - JeongHoon Byun
Multiple var statements in JavaScript, not superfluous - Ben Alman

Further Reading

Understanding JavaScript Closures - Angus Croll
Basic JavaScript for the impatient programmer - Dr. Axel Rauschmayer
You Might Not Need jQuery - Zack Bloom & Adam Schwartz
ES6 Features - Luke Hoban
Frontend Guidelines - Benjamin De Cock

Books

JavaScript: The Good Parts - Douglas Crockford
JavaScript Patterns - Stoyan Stefanov
Pro JavaScript Design Patterns - Ross Harmes and Dustin Diaz
High Performance Web Sites: Essential Knowledge for Front-End Engineers - Steve Souders
Maintainable JavaScript - Nicholas C. Zakas
JavaScript Web Applications - Alex MacCaw
Pro JavaScript Techniques - John Resig
Smashing Node.js: JavaScript Everywhere - Guillermo Rauch
Secrets of the JavaScript Ninja - John Resig and Bear Bibeault
Human JavaScript - Henrik Joreteg
Superhero.js - Kim Joar Bekkelund, Mads Mobæk, & Olav Bjorkoy
JSBooks - Julien Bouquillon
Third Party JavaScript - Ben Vinegar and Anton Kovalyov
Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript - David Herman
Eloquent JavaScript - Marijn Haverbeke
You Don’t Know JS: ES6 & Beyond - Kyle Simpson

Blogs

Podcasts

JavaScript Jabber

採用企業

これは、このスタイルガイドを使用している企業のリストです。もし使用している場合は、プルリクエストを送って追加してください。

Aan Zee: AanZee/javascript
Adult Swim: adult-swim/javascript
Airbnb: airbnb/javascript
Apartmint: apartmint/javascript
Avalara: avalara/javascript
Avant: avantcredit/javascript
Billabong: billabong/javascript
Bisk: bisk/javascript
Blendle: blendle/javascript
Brainshark: brainshark/javascript
ComparaOnline: comparaonline/javascript
Compass Learning: compasslearning/javascript-style-guide
DailyMotion: dailymotion/javascript
Digitpaint digitpaint/javascript
Ecosia: ecosia/javascript
Evernote: evernote/javascript-style-guide
Evolution Gaming: evolution-gaming/javascript
ExactTarget: ExactTarget/javascript
Expensify Expensify/Style-Guide
Flexberry: Flexberry/javascript-style-guide
Gawker Media: gawkermedia/javascript
General Electric: GeneralElectric/javascript
GoodData: gooddata/gdc-js-style
Grooveshark: grooveshark/javascript
How About We: howaboutwe/javascript
Huballin: huballin/javascript
HubSpot: HubSpot/javascript
Hyper: hyperoslo/javascript-playbook
InfoJobs: InfoJobs/JavaScript-Style-Guide
Intent Media: intentmedia/javascript
Jam3: Jam3/Javascript-Code-Conventions
JeopardyBot: kesne/jeopardy-bot
JSSolutions: JSSolutions/javascript
Kinetica Solutions: kinetica/javascript
Mighty Spring: mightyspring/javascript
MinnPost: MinnPost/javascript
MitocGroup: MitocGroup/javascript
ModCloth: modcloth/javascript
Money Advice Service: moneyadviceservice/javascript
Muber: muber/javascript
National Geographic: natgeo/javascript
National Park Service: nationalparkservice/javascript
Nimbl3: nimbl3/javascript
Orion Health: orionhealth/javascript
OutBoxSoft: OutBoxSoft/javascript
Peerby: Peerby/javascript
Razorfish: razorfish/javascript-style-guide
reddit: reddit/styleguide/javascript
React: /facebook/react/blob/master/CONTRIBUTING.md#style-guide
REI: reidev/js-style-guide
Ripple: ripple/javascript-style-guide
SeekingAlpha: seekingalpha/javascript-style-guide
Shutterfly: shutterfly/javascript
Springload: springload/javascript
StudentSphere: studentsphere/javascript
Target: target/javascript
TheLadders: TheLadders/javascript
T4R Technology: T4R-Technology/javascript
VoxFeed: VoxFeed/javascript-style-guide
WeBox Studio: weboxstudio/javascript
Weggo: Weggo/javascript
Zillow: zillow/javascript
ZocDoc: ZocDoc/javascript

翻訳

このスタイルガイドは他の言語でも利用可能です：

Brazilian Portuguese: armoucar/javascript-style-guide
Bulgarian: borislavvv/javascript
Catalan: fpmweb/javascript-style-guide
Chinese (Simplified): sivan/javascript-style-guide
Chinese (Traditional): jigsawye/javascript
French: nmussy/javascript-style-guide
German: timofurrer/javascript-style-guide
Italian: sinkswim/javascript-style-guide
Japanese: mitsuruog/javacript-style-guide
Korean: tipjs/javascript-style-guide
Polish: mjurczyk/javascript
Russian: uprock/javascript
Spanish: paolocarrasco/javascript-style-guide
Thai: lvarayut/javascript-style-guide

JavaScript スタイルガイドガイド

リファレンス

JavaScript についてチャットする

Find us on gitter.

コントリビューター

View Contributors

License

(The MIT License)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘Software’), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ‘AS IS’, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Amendments

We encourage you to fork this guide and change the rules to fit your team’s style guide. Below, you may list some amendments to the style guide. This allows you to periodically update your style guide without having to deal with merge conflicts.

Reference

GitHub - jigsawye/javascript: Airbnb JavaScript Style Guide 正體中文版

ターミナルからVSCodeでファイルやフォルダを開く方法

Thu, 09 Feb 2023 00:00:37 +0800

VSCodeのショートカットコマンドをインストールする

まず、ショートカット CMD + SHIFT + P（Windowsの場合は CTRL + SHIFT + P）を使用し、code path と入力します。すると、次の結果が表示されるはずです。

最初のオプションを選択すると、コンピュータが管理者権限を求めてくるはずです。これは問題ありません！

今すぐ新しいターミナルを開いて新しいパスを有効にし、次のコマンドを入力してください。 code -h

コマンドが機能しているのがわかるはずです。

ターミナルからファイルやフォルダを開く

# 現在のフォルダを開く
code .

# 特定のファイルを開く
code some-specific-file.js

Reference

ターミナルからVSCodeでファイルやフォルダを開く | Bits and Pieces

Next.js: SSG、SSR、CSR、ISRとは何ですか？

Wed, 08 Feb 2023 00:00:37 +0800

Photo by Lautaro Andreani on Unsplash

皆さん、こんにちは！連休の初日はいかがお過ごしでしたか？今日は、Webの様々なレンダリングモード、具体的にはSSG、SSR、CSR、ISRの概念について共有したいと思います。これらは似ているように見えますが、細かい部分が異なります。どれを使うか決める前に、以下の紹介を見てみましょう！

Static Site Generation (SSG)

SSG、または静的生成（Static Generation）とは、プロジェクト全体をビルドする際にHTMLファイルを生成することを意味します。これらのHTMLファイルには、表示に必要なデータがすでに含まれています。このレンダリングモードは、プリレンダリング（pre-rendering）の一種です。SSGは、すべてのデータがビルド時に取得されるため、コンテンツが変化しない静的Webサイトに非常に適しています。これらのHTMLファイルはCDNに配置してキャッシュすることで、Webサイトのパフォーマンスを向上させることができます。これに加えて、SSGレンダリングモードを採用することはSEOにも有益です。

Server-side Rendering (SSR)

SSR、またはサーバーサイドレンダリング（Server-side Rendering）とは、ブラウザ（クライアントサイド）がリクエストを送信するたびに、サーバーがHTMLファイルを生成してブラウザに送り返し、表示することを意味します。このレンダリングモードは、頻繁に変更されるデータに非常に適しています。ただし、サーバーがHTMLファイルを生成するのに時間がかかるため、Webサイトの応答時間が長くなり、ユーザーは待機中に白い画面を見ることになります。SSRもプリレンダリングの一種と見なされるため、SEOにはかなり優しいです～ただし、この方法はサーバーが常にユーザーのリクエストを処理する必要があることに注意してください。

Client-side Rendering (CSR)

CSR、またはクライアントサイドレンダリング（Client-side Rendering）は、名前の通りほぼそのままの意味です。サーバーからブラウザに送信されるHTMLファイルは、コンテンツがないと見なすことができます。ブラウザは、サーバーからデータを取得した後にのみ画面にレンダリングできます。SPA（ReactやVueのようなSingle Page Application）で使用されるレンダリングモードはCSRです。このモードの最大の利点は、ページを切り替えるときにサーバーからファイルを再度取得する必要がないため、ユーザーに白い画面が表示されず、非常に優れたユーザー体験と見なされることです。ただし、レンダリング時間はクライアントの環境に依存します。また、このため、サーバーの負担はかなり軽減されます。

Incremental Static Regeneration (ISR)

ISR、またはインクリメンタル静的再生成（Incremental Static Regeneration）は、あまり耳にしないレンダリングモードであり、これもプリレンダリングの一種と見なされます。ISRは、プロジェクトのビルド時にすべて（または一部）のHTMLファイルを生成します。新しいリクエストがあり、所定の時間が経過している場合、サーバーは最初にブラウザに古いファイルを提供しつつ、バックグラウンドで最新のファイルを再生成し、生成が完了した後にブラウザに送信して表示します。ユーザーがまだ生成されていないページにアクセスした場合、サーバーはその場でそのファイルを生成してキャッシュするため、次にこのページにアクセスするユーザーはキャッシュから直接ファイルを取得できます。ISRはSSGとよく似ていますが、SSGがデータコンテンツを更新できないという問題を解決しており、HTMLファイルもCDNにキャッシュされるため、SSRに比べてサーバーへの負担も軽減されます。

どれを使うべきですか？

各レンダリングモードには長所と短所があり、どれを選択するかはプロジェクトによって異なります。明確な勝者はいません。

データが常に変化し、SEOが必要ない内部システムのダッシュボードなどは、CSRの使用が非常に適しています。
データの変更率は低くないがSEOが必要な場合は、SSRの使用を検討できます。
イベントやマーケティングサイトのようにデータをほとんど更新する必要がなく、SEOも重要な場合は、SSGの使用が非常に適しています。
データがあまり更新されない場合、または商品ページのようにページ数が多すぎてSEOが必要な場合は、ISRが良い選択です。

私も表を描いてみました（英語ですが XD）、見てみてください～

Next.jsでのプリレンダリング

Next.jsは、上記のレンダリングモードを組み込みでサポートしており、データを取得（fetch）する必要のないWebページをレンダリングするためにデフォルトでSSGを使用します。サーバーからデータを取得する必要がある場合は、CSRと混在（ハイブリッド）されます。他のレンダリングモードを使用したい場合は、Next.jsが提供する以下の関数を使用できます：

Function	Description
getStaticProps (Static Generation)	ビルド時に必要なデータを取得し、HTMLファイルに埋め込みます
getStaticPaths (Static Generation)	ビルド時にどの動的（dynamic）ルートをHTMLファイルとして生成する必要があるかを決定します
getServerSideProps (Server-side Rendering)	必要なデータを取得するためにブラウザがリクエストを送信するたびに実行される関数

まとめ

今日はここまでです。明日また続きをやりましょう～明日は、これら3つの関数を使用して、さまざまなレンダリングモードでWebサイトを実装する方法を共有します！今日学んだレンダリングモードについてどう思いましたか？