Kush's Wiki

Sort by - linked count

• 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
• mise/

  Config Environment
  development や production のような環境別に参照する .mise.toml を切り替えることができる機能 MISE_ENV 環境変数を引数に受け取ることで分岐する https://mise.jdx.dev/configuration/environments.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/

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

  Secrets
  #Security miseのEnvironment機能における機密情報管理について、mise開発元のfnoxまたはsops, ageを用いて解決する方法 https://mise.jdx.dev/environments/secrets/
• Pekko Actor
  #Programming Pekkoのコアモジュール。Java/Scalaでアクターモデルに基づく並行・分散処理の基盤を提供する アクターは状態・振る舞い・メールボックスをカプセル化し、メッセージパッシングで通信する Typed APIにより受信可能なメッセージ型を型システムで強制できる アクターはツリー状の階層構造を形成し、親アクターが子アクターを監督する https://pekko.apache.org/docs/pekko/current/typed/actors.html
• Datadog Agent
  #Observability Datadogへホストのログを送信するソフトウェア。 各ホストの環境別にいくつかのインストール手段が用意されている 例としてKubernetesへのインストール方法は以下 Kubernetes に Datadog Agent をインストールする https://docs.datadoghq.com/ja/agent/?tab=Linux
• opentelemetry-go
  #Observability #Programming OpenTelemetryのGo APIまたはSDK https://github.com/open-telemetry/opentelemetry-go https://opentelemetry.io/ja/docs/languages/go/
• cargo-llvm-cov
  #Testing RustのLLVMソースベースコードカバレッジ（-C instrument-coverage）を簡単に利用するためのCargoサブコマンド https://github.com/taiki-e/cargo-llvm-cov
• XState
  #Programming Finite State MachineをコンセプトとしたJavaScript/TypeScriptライブラリ 実装を元にStatechartsの出力が可能。Actor Modelにも対応している https://xstate.js.org/docs/
• ハーネスエンジニアリング
  #Programming #Software Design AIエージェントが正しく・安全に動ける実行環境と検証の仕組みを設計・構築するエンジニアリング手法。Mitchell Hashimoto（HashiCorp共同創業者）が提唱。 CodexなどのAIコーディングエージェントが誤りを犯した際、プロンプト修正ではなく環境側を改善する AGENTS.md整備：エージェント向け指示書を継続的に更新 カスタムツール構築：エージェント専用ツールの用意 CI/テストによる品質担保 https://openai.com/ja-JP/index/harness-engineering/
• Issue fields
  GitHubの organization レベルで定義する Issue のメタデータフィールド（2026 public preview）。org 内の全リポジトリの Issue に自動適用される フィールド型は single select / text / number / date の4種で、issue type ごとに表示を pin できる 値は Issue 自体に保存され、organization 全体で一貫したメタデータを与える REST / GraphQL / webhook で検索・フィルタ・自動化できる 設定は organization Settings → Planning → Issue fields。リポジトリ単位の定義は不可 https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-fields-in-your-organization
• BSR
  Buf Schema Registory #Continuous Integration #Continuous Delivery Bufが提供するProtocol Buffersツール群のうちの一つ Protobufファイル群をモジュールとしてバージョン管理することができる。 モジュールとしてのドキュメンテーションをサポートし依存関係管理も可能 Overview - Buf Docs
• Inversion of Control Containers and the Dependency Injection pattern
  #Software Design Martin FowlerによるDependency Injectionの概念を定義した記念碑的な記事（2004年1月23日公開） 背景 それまで軽量コンテナフレームワークは「Inversion of Control（IoC）」という用語で説明されていたが、Fowlerは「IoCはフレームワークの一般的な特性であり包括的すぎて混乱を招く」と指摘。IoC推進者との議論を経て、より具体的な「Dependency Injection」という用語を作成した 主な内容 DIの定義：別のオブジェクト（アセンブラ）が、クラスのフィールドに適切な実装を注入するアプローチ。サービス構成の責任と使用の責任を分離する 3つの実装パターン： Constructor Injection（コンストラクタ注入）：PicoContainerで採用。オブジェクト生成時に依存関係を明示 Setter Injection（セッター注入）：Spring Frameworkで採用。初期化後に依存関係を設定 Interface Injection（インターフェース注入）：Avalonで使用。注入用インターフェースを実装 影響 この記事により「Dependency Injection」という用語が確立され、以降のフレームワーク設計やソフトウェアアーキテクチャに大きな影響を与えた。Spring Frameworkも当初は「IoC」を使用していたが、後に「DI」という用語を採用 https://martinfowler.com/articles/injection.html 日本語訳：https://kakutani.com/trans/fowler/injection.html
• オブジェクト指向入門 第2版 原則・コンセプト
  
• go-oidc
  #Programming #Security/Authentication Go用のOIDCライブラリ、golang.org/x/oauth2パッケージと統合される プロバイダーのDiscoveryエンドポイントから自動設定 IDトークン（JWT）の署名検証とクレーム抽出 リモートのJWKS取得とキャッシュ管理 https://github.com/coreos/go-oidc
• create-github-app-token
  #Continuous Integration GitHub Actions の workflow 内で GitHub App のインストールアクセストークンを発行する公式 Action actions/create-github-app-token。App の ID と private key を渡すと、対象を絞ったトークンを払い出す 特徴 発行されるインストールトークンは 1 時間で失効する短命トークン。post step で自動 revoke され、明示しない限り他 job へは渡らない owner / repositories でアクセス先リポジトリを限定し、権限を細かく絞れる デフォルトの GITHUB_TOKEN（権限が制限的で後続 CI をトリガできない）や PAT の代替として使い、GitHub App の bot 名義で commit / comment できる https://github.com/actions/create-github-app-token
• SQLパフォーマンス詳解
  
• 良いコードとは何か
  #Software Design 特に結合度と凝集度について参考になる研修資料 キーワード 技術的負債 クリーンアーキテクチャ
• Amazon/

  EKS
  Elastic Kubernetes Service #Cloud Native AWSクラウド上でKubernetesを実行するマネージドサービス、Kubernetes準拠であるため既存のKubernetesアプリケーションと互換性がある Kubernetes Serviceでのロードバランシングに加え、Elastic Load Balancingの使用をサポートしている What is Amazon EKS? - Amazon EKS
• Amazon/

  Athena
  #Data Engineering AWSのサーバーレスのインタラクティブな分析サービス、S3を中心に様々なデータソースを元にSQLでデータを抽出可能にする Amazon Athena とは - Amazon Athena
• あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢
  Author: 草間 一人 SRE/SRE サイトリライアビリティエンジニアリング エレガントパズル Four Keys/DevOps Platform Engineering Team Topologies Building Effective AI Agents
• Cursor
  #Programming LLMに特化したIDE。VS CodeのフォークでありGitHub Copilotに代わってCursor独自のAIアシスタントが搭載されている https://www.cursor.com/ja
• DeepWiki
  #LLM #Documentation Devinの一つの機能であるDevin WikiをPublicなリポジトリに絞って利用できるOSS Devin Searchに相当するAsk機能も備えている https://docs.devin.ai/work-with-devin/deepwiki
• Platform Engineeringの2つの「IDP」～Internal Developer Portalとその代表例Backstage
  Platform Engineering Internal Developer Portal Backstage https://codezine.jp/article/detail/19578
• protovalidate
  #API Architecture Bufが提供するProtocol Buffers向けのセマンティックバリデーションライブラリ。.protoファイル上のアノテーションでフィールド制約を表現し、protoc-gen-validateの次世代として位置付けられている。 標準アノテーション (uuid = true / email = true / max_len = 64 等) で一般的な制約を宣言 カスタムルールはCEL (Common Expression Language) で記述 サポート言語: Go / TypeScript / Java / Python / C++ https://buf.build/docs/protovalidate/
• アジャイル開発はWhyから始まる
  #Agile #Product Management 市谷 聡啓によるアジャイル開発はWhyから始まるというスライド Docswell ゴールデンサークル ユーザーストーリー
• Valkey
  #Data Engineering Redis OSSからフォークしたBSDライセンスのキーバリュー型インメモリデータストア Redis OSSとの互換性を維持 Linux Foundationがホストする https://valkey.io/
• Screenplay Pattern
  #Testing SerenityJSのコアとなるBDDデザインパターン E2Eテストにおいて、PageのようなオブジェクトではなくUserのようなアクターに焦点をあててテストを記述する 例としてバックエンドAPIのモックは、Abilitiesという概念でアクターに付与される https://serenity-js.org/handbook/design/screenplay-pattern/
• スワーミングがアジャイルチームを助ける
  #Agile アジャイルチームにおけるSwarmingについて述べた記事 https://www.infoq.com/jp/news/2013/03/swarming-agile-teams-deliver/
• Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた
  Eric EvansがDDD（ドメイン駆動設計）は未完成だと述べたという記事 InfoQ
• "Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス
  #Agile #Team Organization #Continuous Integration #Continuous Delivery Swarmingをコンセプトに掲げたアジャイルチームのベストプラクティスについての、XP祭り2024での自身の発表 関連Scrapは以下 自己組織化 ストラングラーフィグアプリケーション トランクベース モノリスからマイクロサービスへ 関数型ドメインモデリング
• lefthook
  #Continuous Integration Git hooks マネージャ。Go 製単一バイナリで lefthook.yml に hook 定義を書き、lefthook install で .git/hooks/ に展開する。Evil Martians がメンテナンス pre-commit / pre-push / commit-msg 等の hook 種別をサポートし、カスタムタスクグループも作れる ジョブを並列実行でき、glob / regex によるファイル絞り込み、tag でグループ単位の実行制御 ローカル上書き用に lefthook-local.yml を分離可能 https://lefthook.dev/ https://github.com/evilmartians/lefthook
• When to start a platform team
  Platform Engineering #Team Organization Rebecca Murphey（Swarmia）による、専任 プラットフォームチーム をいつ作るべきかを組織規模から論じた記事 目安は約100エンジニア（Peter Seibel のモデル）。それ未満は専任チームのオーバーヘッドが便益を上回る 「2〜3チームを超えた時点で、未文書で脆くても既に Internal Developer Platform は存在する」。4チーム以上が検討の目安 早すぎ（20人規模）は機能開発リソースの浪費、遅すぎ（100人超で不在）は複数ペア＋専任マネジメントが必要になる 「Minimum Viable Platform Team」＝最小構成のチーム（自走リード1＋伸びしろ1＋兼任EM）から始める。チーム版の Minimum Viable Platform とも言える発想で、IDP をプロダクトとして利用者の声と指標で測る（Platform as a Product） https://www.swarmia.com/blog/when-to-start-a-platform-team/
• Nix/

  Flakes
  Nix のコードを共有するための entrypoint flake.nix を中心とした仕組み。inputs（依存の宣言）と outputs（提供する成果物）から成る nix コマンド実行時に flake.lock が生成され、inputs を exact version に pin する（依存側の inputs も再帰的に lock）。同一バージョンでの再現を容易にし、サプライチェーン攻撃 の pinning 軸に効く default で pure mode（host 環境から隔離）で評価され再現性を促す。ただし pure mode でも再現性が保証されるわけではない 実験的機能（Nix 2.4 以降）。experimental-features = [ "nix-command" "flakes" ] 等で有効化する https://nix.dev/concepts/flakes
• 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
• 組織を芯からアジャイルにする「インセプションデッキ」
  #Agile #Product Management 市谷 聡啓によるインセプションデッキを活用して組織を芯からアジャイルにするスライド https://www.docswell.com/s/papanda/ZYR1L5-shin-agile-deck
• BDDと共通言語
  Authors Greg Young, 和智 右桂 DDDのユビキタス言語とBDDの共通言語の違いを論じている Digital Romanticism
• ライト、ついてますか
  
• Platform Engineeringの2つの「IDP」～Internal Developer Platformとは？
  Platform Engineering Internal Developer Platform Kubernetes RBAC Internal Developer Portal https://codezine.jp/article/detail/19376
• プレモーテム
  スクラムチームのプラクティスとして実践されるリスク発見手法 Blog
• コンウェイの法則と逆コンウェイの法則から組織構造を考える
  #Team Organization 石垣 雅人による、コンウェイの法則と逆コンウェイの法則から組織構造を考える記事 Masato Ishigaki | Medium
• 実践クリーンアーキテクチャ
  #Software Design 成瀬 允宣による、クリーンアーキテクチャを実装レベルで実践するドキュメント 実践クリーンアーキテクチャ │ nrslib
• デジタルアイデンティティのすべて
  
• 一人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
• Claude is a space to think
  AnthropicがClaudeを広告フリーに保つ方針を表明した記事 AIアシスタントとの会話はセンシティブな情報を含むため、広告モデルとは根本的に相容れない 広告はユーザー支援よりも収益化への誘導というインセンティブの歪みを生む 収益はエンタープライズ契約と有料サブスクリプションから得て、Claudeの改善に再投資 60カ国以上の教育者プログラム、政府パートナーシップ、非営利割引でアクセスを拡大 ユーザー主導のアクション（調査・比較・購入の支援）を通じた商取引は支援する https://www.anthropic.com/news/claude-is-a-space-to-think
• DevGuard
  #Security OWASP Incubating Project の開発者向け統合セキュリティプラットフォーム。AGPL-3.0、Go + PostgreSQL 実装 シークレットスキャン / SAST / SCA / IaC / コンテナスキャン / ライセンスチェックを単一 CLI に統合し、サプライチェーン攻撃 対策まで含めて開発ワークフローに組み込む 主な機能 標準準拠スキャナ（Trivy / Grype / Semgrep）の出力を取り込み CVSS + EPSS + component depth に基づくリスク優先順位付け SBOM / VEX のライブ管理、依存パッケージの Dependency Firewall（npm / Go / Python） OPA/Rego によるポリシー強制、GitHub / GitLab / Jira との双方向同期 オープン標準（SBOM / VEX / SARIF / SLSA / in-toto）を中核に据える https://devguard.org/ https://github.com/l3montree-dev/devguard
• GraphQL Foundation
  GraphQLの仕様をオープンソース化するコミュニティ Linux Foundation傘下である https://graphql.org/community/foundation/
• ダイナミックリチーミング