Kush's Wiki

Sort by - linked count

• Agile testing directions: tests and examples
  #Testing Agile Testingにおけるアジャイルテストの4象限の源流となったブログ記事 http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
• SCIM
  System for Cross-domain Identity Management #Security/Authentication ユーザーアイデンティティ情報を異なるシステム間で自動的にプロビジョニング・管理するための標準プロトコル 主な機能は以下の通り ユーザープロビジョニング（新規アカウント作成） デプロビジョニング（アカウント削除） 属性同期（ユーザー情報の更新） グループ管理 RESTful APIベースで、IdPとSP（Service Provider）間のユーザー情報同期を効率化する https://scimcloud.com/ https://datatracker.ietf.org/doc/html/rfc7644
• Testcontainers
  
• LLM/

  トークナイザー
  文字列をトークンを複数に分割するための役割。LLMによって用いるトークナイザーが異なる
• Manuel Pais
  
• Tailwind CSS
  #Programming HTMLから離れずにユーティリティクラスを組み合わせてデザインを構築するUtility-FirstのCSSフレームワーク flex、pt-4、text-center等のユーティリティクラスをマークアップに直接記述 未使用CSSを自動除去し、本番ビルドのCSSバンドルを最小化 v4からCSS-firstの設定方式に移行し、Lightning CSSベースの高性能エンジンを採用 https://tailwindcss.com/
• Daniel Avila
  
• 輻輳制御
  #Network TCPプロトコル等で行われるネットワークのリンク上でパケットが混線した際の制御 輻輳制御アルゴリズムは大きく以下の3つに分類される Loss-based Delay-based ハイブリッド型
• オポチュニティキャンバス
  #Product Management #Documentation Jeff Pattonが考案した、プロダクトの機会（オポチュニティ）を1枚で記述するためのキャンバス 仮説検証前のアイデア整理に用いられ、ユーザー価値とビジネス価値を並列に整理する https://jpattonassociates.com/opportunity-canvas/
• Principal Engineering Community Tenets
  Amazonのプリンシパルエンジニアグループによるコミュニティの信条 https://www.amazon.jobs/content/en/teams/principal-engineering/tenets
• SoE
  System of Engagement 顧客との関係性を重視するシステム、ECサイト等が該当する
• Basic認証
  #Security/Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う
• Introducing Example Mapping
  Matt Wynneによる実例マッピングのアイディアが生まれたブログ、以下は風間 裕也による翻訳記事 https://nihonbuson.hatenadiary.jp/entry/ExampleMapping
• キャズム理論
  購買層を以下の5つに分類する技術マーケティング手法 Innovators Early Adopters Early Majority Late Majority Laggards
• 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
• 無関心の谷
  #LLM プロンプトエンジニアリングにおいて、プロンプトの冒頭を過ぎたところから中盤にかけて形成されるゾーンが、コンテキストにおいて重視されずらい現象
• Trivy
  #Security #Cloud Native #Continuous Integration #Continuous Delivery Aqua Securityが開発するオープンソースの脆弱性・設定ミス・シークレットスキャナー。コンテナイメージ、Kubernetes、IaC、gitリポジトリを対象とする SASTツールの一種としてDevSecOpsのシフトレフトセキュリティを担い、CIパイプラインに統合できる DockerfileやTerraformの設定ミス検出、シークレット検出、SBOM生成にも対応する --format sarif で SARIF 出力に対応し GitHub Code Scanning に取り込める https://trivy.dev/ https://github.com/aquasecurity/trivy
• LeanとDevOpsの科学
  
• mise/

  Bootstrap Packages
  Bootstrap の1フェーズで、[bootstrap.packages] に宣言した OS パッケージをネイティブの package manager（apk / apt / brew 等）で導入する ledger で mise が入れたパッケージを追跡し、mise bootstrap packages apply（導入）/ import（既存環境から取り込み）/ prune（宣言から外れたものを削除）を提供、snapshot も持つ Homebrew では [bootstrap.brew.taps] で tap を管理し、bottle が無ければ source build。app bundle 直接導入用の brew-cask: backend も追加された https://mise.jdx.dev/bootstrap.html
• mise/

  macOS defaults
  Bootstrap の1フェーズで、macOS の user defaults（Dock / Finder / キーボード / トラックパッド等の挙動設定。通常は System Settings か defaults write で変える）を [bootstrap.macos.defaults] に宣言して収束させる 狙いは「新しい Mac を毎回手で設定し直す・秘伝の defaults write スクリプトを保守する」を、宣言的で冪等な設定に置き換えること。例: Dock の autohide/tilesize、Finder の show_pathbar、key_repeat、trackpad の tap_to_click、生キー指定の "com.apple.finder" = { AppleShowAllFiles = true } mise bootstrap macos defaults apply で適用（既に正しい値は skip）し、宣言と実機の差分（drift）を status や mise doctor で検知できる。設定が versioned な config に載るので再現・共有できる macos フェーズは LaunchAgents（launchd のユーザーサービス）も扱う https://mise.jdx.dev/bootstrap.html
• mise/

  Shell activation
  Bootstrap の1フェーズで、[bootstrap.mise_shell_activate] に基づき shell の rc ファイルに mise の activation スニペット（mise activate 相当）を marker 区切りで書き込む marker で囲まれたブロックのみを mise が管理するため、rc ファイルの他の記述を壊さず冪等に更新できる mise bootstrap shell apply（mise-shell-activate）で適用し、status で導入状態を確認する https://mise.jdx.dev/cli/bootstrap.html
• mise/

  Bootstrap Repos
  Bootstrap の1フェーズで、[bootstrap.repos] に宣言した git リポジトリを clone / 収束（更新）する path をキーに checkout 先を宣言し、各 repo に pre/post hook を挟める。mise bootstrap repos apply で適用、status（--missing で未取得のみ）で同期状態を確認する 適用時は dirty tree（未コミット変更）や origin mismatch を安全チェックし、意図しない上書きを防ぐ https://mise.jdx.dev/bootstrap.html
• mise/

  Bootstrap hooks
  Bootstrap の各フェーズ前後に任意コマンドを差し込む拡張点。[bootstrap.hooks.<point>] に run（文字列または配列）で宣言し、宣言的セクションに収まらない処理（認証フローや環境固有のセットアップ等）の逃げ道になる hook point は各フェーズの pre-* / post-*（packages / repos / dotfiles / defaults / user / tools）と、bootstrap task 後に走る final mise bootstrap 実行時のみ走り、失敗すると停止する。[tools] で入れたツールを使う後処理（例: post-tools で corepack enable）にも使える https://mise.jdx.dev/bootstrap.html
• mise/

  generate bootstrap
  mise 未導入の環境向けに、mise を DL して実行するブートストラップスクリプトを生成する mise generate bootstrap。contributor が mise を入れずともプロジェクトのセットアップを走らせられるようにする -w/--write <path> でファイルに書き出して実行権限を付与（例: bin/ に置いて commit）、-V/--version で DL する mise バージョンを固定 -l/--localize で MISE_DATA_DIR / MISE_CACHE_DIR を project 内の .mise（--localized-dir で変更可）に sandbox し、既存の mise と衝突させない 宣言的にマシンを収束させる mise bootstrap とは別機能（こちらは mise 自体を導入するスクリプトの生成） https://mise.jdx.dev/cli/generate/bootstrap.html
• mise/

  Dotfiles
  mise の [dotfiles] で dotfiles を宣言的に管理する機能。適用は mise dotfiles apply か Bootstrap 経由のみで暗黙には走らず、冪等（適用済みは skip） [settings] の dotfiles.root（保管場所, 例 ~/.dotfiles）と dotfiles.default_mode（既定 symlink）で挙動を決める whole-file エントリの mode: symlink / symlink-each（source ディレクトリ内の各ファイルを個別に symlink）/ copy / template（mise のテンプレートエンジンで描画）。source 省略時は target を dotfiles.root 配下にミラー、source path に glob 可 mise 非所有のファイルは edit エントリで一部だけ管理: block（# >>> mise:id >>> マーカー区切りの複数行）/ line（無ければ末尾追記の1行） mise dotfiles status（applied/missing/differs 等を報告）/ apply（--dry-run --force --yes）/ add（稼働中のファイルを取り込み）/ edit 未管理ファイルは既定で置換を拒否し、--force で明示置換する https://mise.jdx.dev/dotfiles.html
• Continuous Testing in DevOps
  
• featureファイル
  #Testing Cucumberによって形式づけられたテキストファイル Gherkin記法で記述する
• GM Weinberg
  人物
• DevOps capabilities/

  Monitoring and observability
  #Observability DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Monitoring and observability
• DevOps capabilities/

  Job satisfaction
  DevOps capabilitiesの1つ、Climate for Learningに分類される https://dora.dev/capabilities/job-satisfaction/
• DevOps capabilities/

  Test data management
  #Testing DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Test data management
• DevOps capabilities/

  Visual management
  DevOps capabilitiesの1つ、Fast Flowに分類される WIP制限と組み合わせると良い DORA | Capabilities: Visual management
• DevOps capabilities/

  Deployment automation
  #API Architecture DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Deployment Automation
• DevOps capabilities/

  Transformational leadership
  DevOps capabilitiesの1つ、Climate for Learningに分類される DORA | Capabilities: Transformational leadership
• DevOps capabilities/

  Pervasive security
  #Security DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Pervasive security
• DevOps capabilities/

  Version control
  DevOps capabilitiesの1つ、Fast Flowに分類される アプリケーションコードだけでなく、ビルドスクリプトやコンフィギュレーションに対しても管理を行うことが推奨され、継続的インテグレーションに寄与する DORA | Capabilities: Version Control
• DevOps capabilities/

  Streamlining change approval
  DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Streamlining change approval
• DevOps capabilities/

  Empowering teams to choose tools
  #Software Design DevOps capabilitiesの1つ、Climate for Learningに分類される 仕事の満足度に寄与し、ツールやテクノロジーをチームに強制するとチームによる実験が制限されてしまう DORA | Capabilities: Empowering teams to choose tools
• DevOps capabilities/

  Proactive failure notification
  #Observability DevOps capabilitiesの1つ、Fast Feedbackに分類される https://dora.dev/capabilities/proactive-failure-notification/
• Peer DID
  #Security/Authentication #Security/Authorization DIDにおいて自己証明自律型識別子を提供する did:peer DIDメソッド定義 DIDドキュメント相当の情報をパブリックに公開しないため、安価でありセキュリティ強化に繋がる authorization セクションによる認可制御が可能 https://identity.foundation/peer-did-method-spec/
• 認可/

  主体
  Principal #Security/Authorization 認可チェックを受ける対象 ログインユーザーやAPIトークンなどがある
• 認可/

  スコープ
  #Security/Authorization 保護対象のリソースに基づいて定める認可対象の機能範囲
• 認可/

  リソース
  #Security/Authorization 認可による保護対象
• CVE-2025-30066
  #Security changed-files action (≤ v45.0.7) が侵害されたサプライチェーン攻撃の脆弱性。全タグが malicious commit に retroactively 付け替えられ、汚染された action が GitHub Actions runner の secrets を workflow ログへ dump した (embedded malicious code)。 CWE-506 (Embedded Malicious Code) CVSS 3.1: 8.6 HIGH (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) 影響: tj-actions/changed-files ≤ v45.0.7、v46 で解消 https://www.cve.org/CVERecord?id=CVE-2025-30066 https://nvd.nist.gov/vuln/detail/CVE-2025-30066
• Cognition
  Microsoftと提携しているAI(LLM)企業 https://cognition.ai/
• MVPe
  Minimum Viable Product experiment #Agile #Product Management Jeff Pattonが、エリック・リースのMVPを「実験」として捉え直して呼んだ語。何かを学ぶために作れる最小のもので、ターゲット顧客にとって本当にViableなものは何かを理解するための実験を指す。
• Finite State Machine
  有限ステートマシーン #Programming 状態管理を有限にし、あり得ない状態を作らないという考え
• ゴールドスタンダード
  #Security/Authentication #Security/Authorization ゴールドスタンダード（Gold Standard）は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証（Authentication）: ユーザーが本人であることを証明 認可（Authorization）: 認証されたユーザーの行動の許可・拒否を決定 監査（Auditing）: システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/
• DNSラベル標準
  #Network RFC 1123で定義されているDNSに指定可能な文字列
• ダンバー数
  #Team Organization 組織の規模は150人までしか関係をうまく維持できないという理論 https://www.cambridge.org/core/journals/behavioral-and-brain-sciences/article/abs/coevolution-of-neocortical-size-group-size-and-language-in-humans/4290FF4D7362511136B9A15A96E74FEF