tech

結論：RedoclyでOpenAPI Specをタグで分割できる Redocly CLIのfilter-in/filter-outデコレーターを使えば、1つのOpenAPI定義を複数のドキュメントに分割できる。 公開API用と管理API用でSwagger UIを分けたい場合など、タグベースでAPI仕様を分離できる。 背景：なぜ分割が必要か 単一のGo APIで複数のクライアント向けにエンドポイントを提供する場合、全エンドポイントを1つのSwagger UIに表示すると見づらい。 例： 公開API: ユーザー機能、コンテンツ表示 管理API: データ管理、レポート取得、設定変更 → それぞれ専用のSwagger UIを生成したい 解決方法：Redocly CLI + filter デコレーター 1. swagでOpenAPI定義を生成 swag: @echo "==> Running swag init" >&2 @swag init -g cmd/your-api/main.go -o docs @npx -y @redocly/cli@latest bundle docs/swagger.yaml --config docs/redocly-public.yaml -o docs/swagger_public.yaml @npx -y @redocly/cli@latest bundle docs/swagger.yaml --config docs/redocly-admin.yaml -o docs/swagger_admin.yaml && \ sed -i -e 's,API for Public,API for Admin,g' docs/swagger_admin.yaml 2. 公開API用設定：管理タグを除外 docs/redocly-public.yaml:...

結論：13,000+ Skillsが7つのマーケットプレイスで公開中 Claude Skillsは複数のマーケットプレイスとリポジトリで公開されており、目的に応じて使い分けられる。 公式・コミュニティ合わせて13,000以上のSkillsが利用可能。 主要マーケットプレイス一覧 1. SkillsMP（最大級のコレクション） 13,000+ Skillsを検索・閲覧できる最大級のGitHubコレクション 特徴: 星数2以上でフィルタ、品質指標（低品質排除）、カテゴリ検索 形式: マーケットプレイス形式で一括インストール 例: PDF生成、データ分析ワークフロー リンク: skillsmp.com 2. Anthropic Skills Repo（公式） Anthropic公式のSkill例リポジトリ。ドキュメント処理中心 特徴: マーケットプレイス登録可能。人気Skillを/plugin installで追加 規模: 公式Skill数十種 例: document-skills（Excel/PPT/PDF、ブランドガイド適用） リンク: github.com/anthropics/skills 3. Awesome Claude Skills（コミュニティ） コミュニティキュレーションのリスト。リソース・ツールも含む 特徴: GitHub星数ベースのランキング。カテゴリ（開発/デザイン/自動化）でソート 規模: 数百のSkill/Agent 例: prompt-engineering、テスト自動化 リンク: github.com/travisvn/awesome-claude-skills Composio版 4. Claude Code Marketplace（生産性向け） プラグイン/Agent中心のマーケットプレイス。生産性向上ツール多め 特徴: 人気度ソート（リサーチベース）。85+ Agent、47 Skill 規模: 63プラグイン 例: kubernetes-architect、code-reviewer リンク: claudecodemarketplace.com GitHub版 5. Claude Skills Hub（ドメイン別） サードパーティのキュレートマーケットプレイス。ドメイン別整理 特徴: フィーチャー/最新リストでランキング。GitHubリンクから詳細・インストール 規模: 数百の拡張 例: ドキュメント処理、コミュニケーションSkill、デザイン自動化 リンク: toolify....

結論：「..」は片方、「…」は両方の差分 git logの..（ドット2つ）と...（ドット3つ）は、ブランチ間のコミット比較方法が異なる。 ..（2ドット）: 一方のブランチにのみ存在するコミット ...（3ドット）: 両方のブランチで異なるコミット全て 使い分け ..（2ドット）- 未マージのコミットを確認 developにあってmainにないコミット（未マージ分のみ） git log origin/main..origin/develop 用途： PR前の差分確認 マージ漏れチェック リリース対象の確認 結果： developにしかないコミットのみ表示（mainには既にあるコミットは除外） ...（3ドット）- 分岐後の全差分 mainとdevelopの差分（どちらか一方にしかないコミット全て） git log origin/main...origin/develop 用途： ブランチの分岐点以降の変更全体を確認 両ブランチの独立した開発内容を比較 結果： mainにのみあるコミット + developにのみあるコミット 視覚的に確認 # グラフで分岐を表示 git log --oneline --graph origin/main...origin/develop --graphオプション: コミットの分岐・マージをビジュアル化 どちらのブランチに属するか一目で分かる 具体例 状況 main: A - B - C - D \ develop: E - F - G ..（2ドット）の結果 git log main..develop # 結果: E, F, G（developにのみ存在） git log develop....

結論：アプリ構造とレンダリング方式は別概念 Next.jsでは「ページ遷移の方法（SPA/MPA）」と「HTMLを生成するタイミング（SSG/SSR/CSR）」は独立した概念。 両者を正しく理解することで、最適な構成を選択できる。 アプリケーション構造（ページ遷移の方法） 構造 ルーティング ページ遷移 SPA クライアントサイド JavaScriptで画面切り替え（リロードなし） MPA サーバーサイド フルページリロード Next.jsはデフォルトでSPA（クライアントサイドルーティング）。 レンダリング方式（いつ・どこでHTMLを生成するか） 1. SSG（Static Site Generation）- ビルド時に生成 Pure SSG（完全静的）: Static Export（output: 'export'） サーバー不要（Netlify、GitHub Pagesにデプロイ可能） 完全静的ファイルのみ生成 // next.config.js module.exports = { output: 'export', } Standard SSG Node.jsサーバー使用 API Routes、画像最適化、middleware、rewrites、redirects などを併用 2. ISR（Incremental Static Regeneration） SSG + 更新機能 export async function generateStaticParams() { return [{ id: '1' }, { id: '2' }] } export const revalidate = 60 // 60秒ごとに再生成 3....

結論：orderByは指定フィールドの存在でもフィルタリングする FirestoreのorderBy()句は、指定したフィールドが存在しないドキュメントを自動的に除外する。 並べ替えだけでなく、暗黙的にフィルタリングも行うため、予期しないデータ欠落が発生する可能性がある。 問題：orderByで結果が減る // 「createdAt」フィールドでソート query := client.Collection("users").OrderBy("createdAt", firestore.Asc) このクエリでは、createdAtフィールドが存在しないドキュメントは結果に含まれない。 例： ✅ {id: 1, name: "Alice", createdAt: "2025-01-01"} → 結果に含まれる ❌ {id: 2, name: "Bob"} → 結果から除外される（createdAtがない） 公式ドキュメントの記載 orderBy() 句は、指定したフィールドの有無によるフィルタも行います。指定したフィールドがないドキュメントは結果セットには含まれません。 Cloud Firestore でデータを並べ替えたり制限する | Firebase 範囲比較との組み合わせ制約 範囲比較（<, <=, >, >=）のフィルタがある場合、最初のorderBy()は同じフィールドで行う必要がある。 // ❌ NG: 範囲比較（age）と異なるフィールド（name）で最初にorderBy query := client.Collection("users"). Where("age", ">", 20). OrderBy("name", firestore.Asc) // エラー: 最初のorderByはageにする必要がある // ✅ OK: 範囲比較と同じフィールド（age）で最初にorderBy query := client.Collection("users"). Where("age", ">", 20). OrderBy("age", firestore.Asc). OrderBy("name", firestore.Asc) 対策：フィールド存在を意識する 1....