Kush's Wiki

Sort by - linked count

• mise/

  aqua
  aqua を backend として使う形態。aqua:owner/repo で参照する（例 aqua:BurntSushi/ripgrep） aqua registry が mise binary に同梱され、別途 aqua 本体なしで利用できる（default は official registry） インストール時に mise が native に検証する: checksum（SHA256/SHA512/SHA1/MD5, 常時有効）に加え Cosign 署名 / SLSA provenance / GitHub Artifact Attestations。checksum を超えた 署名検証（由来検証）まで担える mise は plugin 不要・Windows 対応・上記セキュリティを理由に、新規 tool では aqua backend を推奨する https://mise.jdx.dev/dev-tools/backends/aqua.html
• mise/

  disable_tools
  mise の設定。特定の tool を名指しで無効化し、Dev Tools の管理対象から外す。主に mise 内蔵の core tools を off にする用途 mise.toml の [settings] に disable_tools = ['node']、環境変数 MISE_DISABLE_TOOLS、mise settings add disable_tools node（--env local でローカル限定）で指定 親 / 子ディレクトリの override に対応し、階層ごとに無効化する tool を変えられる 関連: auto_install_disable_tools は auto-install だけを tool 単位で無効化する env 変数経由だと無効化しても tool が PATH に残る場合がある https://github.com/jdx/mise/discussions/9822 https://mise.jdx.dev/configuration/settings.html#disable_tools
• mise/

  MCP
  #LLM mise 自身を MCP サーバーとして起動する mise mcp。stdio 上の JSON-RPC 2.0 で MCP クライアントに開発環境情報を公開する resource は読み取り専用で mise://tools（Dev Tools）、mise://tasks（Task）、mise://env（Environment）、mise://config の 4 つ。tool は run_task と未実装の install_tool v2026.7.16 追加の list_commands は各コマンドの declared effect（read / write / destructive / 未分類）を返す。未分類は安全ではなく不明として扱い、agent が実行前に副作用を判断できるようにする https://mise.jdx.dev/mcp.html
• mise/

  File Tasks
  miseにおいて、Taskを.mise.tomlではなく、Task単位のファイルに記述する機能 bashだけでなく、以下のような言語で記述可能 node Python deno powershell https://mise.jdx.dev/tasks/file-tasks.html
• mise/

  Lockfile
  mise の tool を exact version と checksum で固定する lockfile（mise.lock） mise.toml の [tools] はバージョン指定のままで、mise.lock が検証データを持つという役割分離 OS-arch ペア（linux-x64, macos-arm64 等）ごとに exact version / SHA256 または Blake3 hash / file size / 取得元 URL を記録する 有効化は [settings] の lockfile = true。自動生成はされず mise lock で生成する backend が対応すれば checksum で整合性を検証でき、commit すればチーム/CI で同一バージョンを再現（reproducible builds）できる。exact version を pin する点で サプライチェーン攻撃 の pinning 軸に対応する https://mise.jdx.dev/dev-tools/mise-lock.html
• DuckDB/

  MySQL extension
  #Data Engineering DuckDBから稼働中のMySQLインスタンスへ直接データを読み書きするための拡張。ATTACH に key-value 形式の接続文字列（host / user / port / database など）を渡して接続する INSERT / UPDATE / DELETE / CREATE TABLE などの書き込み操作に対応し、READ_ONLY オプションで読み取り専用にもできる CREATE TABLE ... AS FROM <db>.<table> で MySQL テーブルを DuckDB 側へ複製でき、COPY ステートメントでParquet形式へ直接エクスポートできる 認証情報は環境変数（MYSQL_HOST など）や secrets 機能で管理できる MySQL 側の DDL はトランザクション非対応。別接続でスキーマ変更した場合は mysql_clear_cache 関数でキャッシュを更新する https://duckdb.org/docs/current/core_extensions/mysql
• DuckDB/

  Iceberg extension
  #Data Engineering DuckDBにApache Icebergオープンテーブルフォーマットのサポートを実装する拡張。初回使用時に自動でインストール・ロードされる 2 つのモードを持つ: テーブルのメタデータを直接指す読み取り専用アクセス（カタログ不要）と、Iceberg REST catalog への ATTACH によるカタログ管理テーブルアクセス（フル機能） 対応カタログとして Amazon S3 Tables・AWS Glue・Cloudflare R2・Polaris・Lakekeeper・BigLake が挙げられ、オブジェクトストレージへは httpfs / azure 拡張と連携してアクセスする v1.5.3（2026-05）で MERGE INTO・ALTER TABLE・パーティション変換・Iceberg V3 サポートが追加された https://duckdb.org/docs/current/core_extensions/iceberg/overview
• DuckDB/

  Avro extension
  #Data Engineering DuckDBでApache Avroファイルの読み取りを可能にする拡張。2024 年後半にコミュニティ拡張として登場し、2025 年初頭にコア拡張へ昇格した read_avro 関数で読み取る。ローカル・HTTP・S3 系のソースや、glob・ファイルリストによる複数ファイル指定に対応する 再帰型定義を除くすべての Avro 型を DuckDB の型へ変換できる。union と null の組み合わせは非 null 型へ自動的に簡約される ドキュメント記載の制限として、単一ファイル内の並列読み取り、プロジェクション/フィルタのプッシュダウン、外部 Avro スキーマファイルの指定は未対応 https://duckdb.org/docs/current/core_extensions/avro
• PRD
  Product Requirements Document #Documentation #Product Management プロダクトに必要な機能・振る舞いを定義する文書。開発チームとステークホルダーの間で「何を作るか」の共通認識を形成する 主な構成要素として、目的・ゴール、ユーザーペルソナ、機能要件、非機能要件、成功指標を含む
• Connect
  
• Platform Engineeringの2つの「IDP」～Internal Developer Platformとは？
  Platform Engineering Internal Developer Platform Kubernetes RBAC Internal Developer Portal https://codezine.jp/article/detail/19376
• Knative Eventing
  Knativeにおいて、KubernetesのCRDによってイベント駆動アーキテクチャを実現するコンポーネント イベントはCloudEvents仕様に準拠し、標準のHTTP POSTリクエストで送受信される https://knative.dev/docs/eventing/
• opentelemetry-go
  #Observability #Programming OpenTelemetryのGo APIまたはSDK https://github.com/open-telemetry/opentelemetry-go https://opentelemetry.io/ja/docs/languages/go/
• LLM Wiki
  Large Language Model Wiki #LLM #Documentation Andrej Karpathyが提唱した、LLMが構造化されたmarkdown wikiを継続的に構築・保守する個人ナレッジベースのパターン。 3層構成: Raw Sources（不変の一次資料）、Wiki（LLMが生成・更新するmarkdown群）、Schema（構造と運用規約の設定ファイル） 3つのコアプリミティブ: Ingest（新規ソースを既存ページへ統合）、Query（wikiを検索して回答し、価値ある結果は新ページとしてfile back）、Lint（矛盾・古い記述・orphanページ・cross-reference欠落を定期検査） 動機は「ナレッジベース保守の面倒な部分は読むことや考えることではなく、bookkeeping」という洞察。人間はsource curationと問いに集中し、bookkeepingはLLMに委譲する https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• State of Scala 2025
  #Programming Scalac が Scala Days 主催者と共同で実施した Scala コミュニティ調査（世界の開発者 400+ 名、2025）。技術的満足度は高い一方で人材難と慎重な業界心理を抱える「成熟した niche 言語」という像を数値で示す Scala 3 採用: 92% が何らかの形で利用、48% が本番移行済み、Scala 2.x のみは 8%。2→3 移行の難易度は平均 3.16/5（中程度） ビルドツール: sbt が ~90% で依然デファクト。新興の Scala CLI 21%・Mill 13% が続く ライブラリ: Cats 56% が最多、http4s 45%・ZIO 31%・sttp 30%・Tapir 29%・Doobie 27% の Typelevel 系が主流。Akka 26%・Play 23% は現役だが非主流 用途: バックエンド/API 85%・データ処理 41%・分散システム 38% に集中、ML/AI は 6.5% と少数 市場感: 「成長」9% /「横ばい」37% /「衰退」44% と慎重。開発者シェアは ~2.6% だが、ステークホルダー説得と人材採用が最大の課題（各 ~43%）。金融・データ領域で "narrow but deep" https://scalac.io/wp-content/uploads/2025/10/State-of-Scala-2025-report.pdf
• Cookie/

  SameSite
  #Security Cookie属性の1つ 同一生成元ポリシーを許可するレベル Strict Lax None の3段階がある
• Cookie/

  HttpOnly
  #Security Cookieの属性の1つ JavaScriptのようなスクリプトからのCookieアクセスを無効にする
• Cookie/

  Secure
  #Security Cookie属性の1つ HTTPS通信を強制する
• Cookie/

  Expire
  Cookie属性の1つ Cookieに永続性を持たせる
• Cookie/

  Max-Age
  Cookie属性の1つ Cookieに永続性を持たせる
• Cookie/

  Path
  Cookie属性の1つ Domainに加えて、アプリケーションのパスレベルでCookieの対象範囲を指定する
• serde
  #Programming RustのSerializationライブラリ https://serde.rs/
• Hurl
  
• Write the Docs Newsletter – July 2025
  #Documentation Write the Docsコミュニティの2025年7月ニュースレター アニメーションGIF: 自動再生を避け、操作可能な短い動画や静止画+再生ボタンを推奨 ドキュメント監査: 目標の明確化、多様なレビューチーム編成、品質チェックリストの整備 ドキュメンタリアンのためのアジャイル: スプリントサイクルとの連携 AI/LLMの活用: オリジナルコンテンツ作成には不向きだが、テンプレート生成・スタイルガイドレビュー・要約・反復編集に有効。有効な場面を明確にした戦略策定が重要 https://www.writethedocs.org/blog/newsletter-july-2025/ ブログ
• HCP Terraform
  #Continuous Integration #Continuous Delivery HashiCorp が提供する Terraform のマネージド SaaS（旧称 Terraform Cloud、2024 に HCP 傘下へ改称）。リモート実行（run）・共有 state・VCS 連携の plan/apply・private module registry・Sentinel/OPA による policy as code を提供する。 CLI からは cloud {} ブロックで接続（旧 remote backend 相当）。料金は managed resource 数ベースで Free 枠あり。自社環境に置く self-hosted 版は Terraform Enterprise https://developer.hashicorp.com/terraform/cloud-docs
• Screenplay Pattern
  #Testing SerenityJSのコアとなるBDDデザインパターン E2Eテストにおいて、PageのようなオブジェクトではなくUserのようなアクターに焦点をあててテストを記述する 例としてバックエンドAPIのモックは、Abilitiesという概念でアクターに付与される https://serenity-js.org/handbook/design/screenplay-pattern/
• スクラムにおける技術的スパイクの進め方
  #Agile 吉羽 龍太郎による、スクラム開発で行う技術的スパイクについての解説 https://www.ryuzee.com/contents/blog/7121 ブログ
• OCSF
  Open Cybersecurity Schema Framework #Security #Observability サイバーセキュリティイベントのログ記録とデータ正規化のためのオープン標準スキーマフレームワーク AWS、Splunk、IBMなどが2022年に設立、2024年11月にLinux Foundationへ参画 ベンダー非依存のスキーマで異なるセキュリティツール間のデータ統合を簡素化 カテゴリ、イベントクラス、データ型、属性辞書で構成 https://ocsf.io/
• Schemathesis
  
• CloudNativePG/

  Cluster
  CloudNativePGでPostgreSQLクラスタを宣言的に定義するカスタムリソース インスタンス数、ストレージ、PostgreSQL設定をマニフェストで管理 Backup、ScheduledBackup、Poolerと連携して運用を構成 https://cloudnative-pg.io/docs/devel/cloudnative-pg.v1/#clusterspec
• Platform Engineeringの2つの「IDP」～Internal Developer Portalとその代表例Backstage
  Platform Engineering Internal Developer Portal Backstage https://codezine.jp/article/detail/19578
• What is a Minimum Viable Platform (MVP)?
  Minimum Viable Platform #Product Management Luca Galante による Minimum Viable Platform の解説記事。プラットフォームの失敗は技術選定ではなく文化・プロセス（価値実証の遅さ）が原因とし、2週間で主要ステークホルダーに価値を示す MVP を説く Representative: クラスタ/コンテナ/VCS/単一DB/DNS/CI/CD 等の典型リソースを最小構成で含む Repeatable: 他チームのクイックスタートになるテンプレート Iterative: スケールを前提に設計する Innovative: 先行チームが新技術を試せる余地を残す 先行採用チーム（lighthouse teams）の賛同を起点にフィードバックを反復し、予算を確保する 抽象度は Platform as a Product で調整し、開発者ポータルと混同しない https://platformengineering.org/blog/what-is-a-minimum-viable-platform-mvp
• スプリントプランニング Deep Dive
  #Agile 吉羽 龍太郎によるスクラムのスプリントプランニングの Deep Dive スライド スプリントプランニング スプリントゴール リファインメント ベロシティ SMART スプリントバックログ
• Kimi K3, and what we can still learn from the pelican benchmark
  #LLM Moonshot AI が2026年7月16日に発表した2.8兆パラメーター推論モデル Kimi K3 のレポートと、Simon Willison によるペリカンベンチマークの有効性と限界の考察。 Kimi K3: 2.8兆パラメーター、初の「open 3T-class モデル」（DeepSeek V4 Pro の1.6Tを超える）、open weight は2026-07-27予定 ベンチ: 4.8 max・GPT-5.5 high には勝るが、Claude Fable 5・GPT-5.6 Sol には負ける Artificial Analysis: 長期知識作業Elo 1547（Claude Fable 5に次ぐ2位）、Arena.ai Frontend Code arena 1位 価格: $3/$15 per Mトークン（中国AIラボ最高値、Anthropic Claude Sonnet シリーズと同水準） 推論effortは"max"の1段階のみ。ペリカン生成で推論トークン13,241消費・計25セント 隠し系統プロンプト約85トークン存在の可能性（"hi"で86トークン計上）、漏洩拒否 ペリカンベンチマーク: 21ヶ月経過し品質との相関はほぼ断絶。今も「実際に試した証明」「コスト・推論量の粗い推定」「SVG/空間認識確認」「同一ファミリー内進化比較」として価値を持つ https://simonwillison.net/2026/Jul/16/kimi-k3/ ブログ
• 一人SREが歩んだPlatform Engineeringスモールスタート実践録 ~ クラウドネイティブ会議版 ~
  Platform Engineering #Team Organization 井上翔太（MIXI）による、一人 SRE が小規模から Platform Engineering を実践した経験報告（クラウドネイティブ会議, 2026）。「Platform Engineering は大規模チームの専売特許ではない」と説く アプリエンジニア→SRE→PE と段階的に守備範囲を広げた実践録 Platform as Code（Terraform / IaC）、AI 付き Slack bot によるセルフサービス権限管理、Golden Path 改善、Workload Identity 導入 制約はリソース不足と設計の相談相手不在。AI が一人実践のイネーブラーになった https://speakerdeck.com/syossan27/ren-sregabu-ndaplatform-engineeringsumorusutatoshi-jian-lu-kuraudoneiteibuhui-yi-ban
• Betterleaks
  #Security #Continuous Integration Gitleaks の開発元が手がける、シークレット（API キー・トークン・認証情報）を検出するスキャナー。GitHub/GitLab などの Git リポジトリ（Organization 単位も可）、S3、ローカルディレクトリなど複数のソースに対応する DevSecOps のシフトレフトとして CI に組み込み、コードや成果物へのシークレット混入を検出する https://github.com/betterleaks/betterleaks
• ConfigCat
  #Continuous Delivery OpenFeature準拠のフィーチャーフラグ管理ツール ダッシュボードによってGUIのフラグ管理が可能 公式SDKがFeature Flag Trackingにも対応している https://configcat.com/docs/getting-started/
• LayerX コーポレートエンジニアリング室のサプライチェーンセキュリティ
  #Security #Continuous Integration LayerX のコーポレートエンジニアリング室（アプリケーショングループ）による、ソフトウェアサプライチェーン攻撃対策の運用事例（2026-02 の発表）。使う技術を絞り、少人数でもスケールする状態を目指す。 依存を pin する: lockfile（pnpm-lock.yaml・go.sum）に加え、GitHub Actions の pinning を CI で強制。org ruleset の require workflows で org 全体に共有 workflow を適用し、その共有 workflow で pinact を実行して未 pin の action を検知。Docker イメージは sha256、CI/CD ツールは aqua で checksum 検証 cooldown: リリースから N 日以内のパッケージを入れない（pnpm・Renovate の minimumReleaseAge、Dependabot の cooldown.default-days）。security fix のみ人間確認後に minimumReleaseAgeExclude で除外 まとめ: 迅速な修正・pinning・cooldown に加え、検知・遮断・影響範囲の局所化も併せて進める https://speakerdeck.com/yuyatakeyama/supply-chain-security-at-layerx-corporate-engineering
• テスト駆動開発の定義
  
• Cline
  VS Codeプラグインとして動作するAIアシスタント、ステップバイステップで会話型エージェントに近い形の体験となる LLMのAPIキーを設定に入力して利用できる https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev
• "Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス
  #Agile #Team Organization #Continuous Integration #Continuous Delivery Swarmingをコンセプトに掲げたアジャイルチームのベストプラクティスについての、XP祭り2024での自身の発表 関連Scrapは以下 自己組織化 ストラングラーフィグアプリケーション トランクベース モノリスからマイクロサービスへ 関数型ドメインモデリング
• cicd-sensor
  #Security #Cloud Native #Continuous Integration GitHub Actions / GitLab CI/CD のジョブをeBPFでカーネルレベルに監視し、実行時のサプライチェーン攻撃を検出するオープンソースのランタイムセキュリティセンサー（"Think EDR, but for CI/CD Pipelines"） CI/CD が握る認証情報・署名鍵・トークンを狙う攻撃に対し、汚染された依存がジョブ内で「何を実行したか」のランタイム可視性と事後調査の手段を与える 検出の仕組み: プロセス系譜分析 - 例として npm install から派生したプロセスによる認証情報アクセス シグナル相関 - 例として 1 ジョブ内での複数カテゴリの認証情報アクセス 構成要素: Sensor - eBPF ベースのランタイムモニタ Action - GitHub Actions 統合。run ごとにレポートと build attestation を生成 Manager - ログを S3 / GCS / Pub/Sub 等のクラウドシンクへルーティング（データはユーザー管理下） 2026 年時点で pre-release・活発に開発中 https://github.com/cicd-sensor/cicd-sensor
• SSL
  Secure Sockets Layer #Network #Security/Cryptography TLSの前身 基本的にはdeprecatedだが、デジタル証明書発行等の文脈で引き続き用いられている https://www.cloudflare.com/learning/ssl/what-is-ssl/
• ghtkn
  #Security/Authentication GitHub App の User Access Token をローカル開発向けに発行する CLI（@suzuki-shunsuke 製）。Device Flow で認証し、8 時間で失効する短命トークンを払い出すことで、長命トークン（PAT や gh auth login の OAuth トークン）が漏洩した際のリスクを抑える 特徴 発行するのは User Access Token で、操作は App ではなくユーザー本人の権限・名義で行われる GitHub App の Client ID のみで動作し secret は不要。失効後は ghtkn get が Device Flow で自動再発行する トークンは OS の資格情報ストア（macOS Keychain / Windows Credential Manager / GNOME Keyring）に保存し、期限まで再利用する https://github.com/suzuki-shunsuke/ghtkn
• 開発者とアーキテクトのためのコミュニケーションガイド
  
• 監視SaaSの運用におけるObservability改善の歩み
  #Observability キーワード Observability Primary Signals Unknown unknowns ログ/メトリクス/トレース OpenTelemetry オブザーバビリティ成熟度モデル
• 熊とワルツを
  
• AtlasとArgoCDでDBマイグレーションの仕組みを構築してみた
  #Data Engineering AtlasをベースとしてマイグレーションDockerイメージを、GitHub Actionsでビルド＆パブリッシュ、Kubernetes Job上のArgo CDでのマイグレーションリリースまでを自動化する記事 https://tech-blog.rakus.co.jp/entry/20250526/dbmigration
• Ent Joins the Linux Foundation
  2021年9月に公開された、entがLinux Foundationに参画した記事 https://entgo.io/ja/blog/2021/09/01/ent-joins-the-linux-foundation/
• 仮説キャンバスでプロダクトの仮説を立てよう
  市谷 聡啓が提唱した仮説キャンバスを使ってプロダクトの仮説を立てる方法を解説したブログ Blog