Sort by - linked count
-
CognitionMicrosoftと提携しているAI(LLM)企業 https://cognition.ai/
-
Blog/Microservice Premium#Software Design Martin Fowlerが2015年に書いたブログ 当時過熱していたマイクロサービス化ブームに警鐘を鳴らす形で、全てのケースにマイクロサービスが適するわけではない点が示された https://martinfowler.com/bliki/MicroservicePremium.html
-
Cloud Native Maturity ModelCNMM #Cloud Nativeの成熟度に関して、各成熟度レベルをビジネスとテクノロジの双方で主要領域を定義するモデル モデルの取り組みは単なる技術的取り組みではなく以下の5つの主要領域の影響を受ける Business outcomes People Process Policy Technology FinOpsとも接続が強く、成熟初期はコストが増加するが成熟につれてコストを節約できる特徴について触れている。また、Platform Maturity Modelと連携しており、トップダウンとボトムアップの両方をカバーする 成熟度レベルは五段階で以下のようになっている Level 1 - Build Level 2 - Operate Level 3 - Scale Level 4 - Improve Level 5 - Adapt https://maturitymodel.cncf.io/
-
pinact#Security #Continuous Integration GitHub Actions の action / reusable workflow の参照を full-length commit SHA に pin する CLI(@suzuki-shunsuke 製)。タグは可変で改ざんの余地があり、SHA 固定だけが不変なリリース参照になる、というサプライチェーン攻撃対策。 pinact run で参照を SHA に pin(# v3.5.1 のバージョンコメント付き)。--update で更新、整合の検証にも対応 --no-api で API なしの構文チェック、--min-age でリリース直後の参照を弾く https://github.com/suzuki-shunsuke/pinact
-
テスト範囲#Testing ユニットテスト、インテグレーションテスト、E2Eテストのように、対象となる範囲でテストを分類する際に用いられる言葉
-
Dynamoスタイル#Data Engineering DynamoDBによって流行したリーダーレスレプリケーションを実装したデータストアに用いられるスタイル名
-
合成監視Synthetic Monitoring #Observability レスポンス内容が予測可能なリクエストを事前に定義し、定期的にシステムに送信し応答を監視するもの
-
輻輳制御#Network TCPプロトコル等で行われるネットワークのリンク上でパケットが混線した際の制御 輻輳制御アルゴリズムは大きく以下の3つに分類される Loss-based Delay-based ハイブリッド型
-
Bertrand Meyer
-
SCIMSystem for Cross-domain Identity Management #Security/Authentication ユーザーアイデンティティ情報を異なるシステム間で自動的にプロビジョニング・管理するための標準プロトコル 主な機能は以下の通り ユーザープロビジョニング(新規アカウント作成) デプロビジョニング(アカウント削除) 属性同期(ユーザー情報の更新) グループ管理 RESTful APIベースで、IdPとSP(Service Provider)間のユーザー情報同期を効率化する https://scimcloud.com/ https://datatracker.ietf.org/doc/html/rfc7644
-
LeanとDevOpsの科学
-
オポチュニティキャンバス#Product Management #Documentation Jeff Pattonが考案した、プロダクトの機会(オポチュニティ)を1枚で記述するためのキャンバス 仮説検証前のアイデア整理に用いられ、ユーザー価値とビジネス価値を並列に整理する 主な構成要素 Problems / Solution Ideas(課題と解決アイデア) Users & Customers(ユーザーと顧客) Solutions Today(既存の代替手段) User Value / Adoption Strategy(ユーザー価値と採用戦略) Business Problems / Benefits / Metrics(ビジネス課題・便益・指標) Budget(予算) https://jpattonassociates.com/opportunity-canvas/
-
マルチステージビルド#Continuous Delivery Dockerfile内で複数のビルドステージ(FROM命令)を定義し、最終的に必要なアーティファクトのみを抽出して軽量なコンテナイメージを作成する手法 メリット イメージサイズの大幅削減: ビルドツールを含まないため、最終イメージサイズを大幅に削減(例: 729MB → 26.2MB) セキュリティ向上: ビルドツールやソースコードが実行環境に残らない 効率的なCI/CDパイプライン: ビルド環境と実行環境の明確な分離により運用がシンプル化 https://docs.docker.jp/develop/develop-images/multistage-build.html
-
Working Agreement#Team Organization チームで決めたチームのルールのこと 価値観や行動規範を具体的に示す
-
KEDA
-
Datadog/RUMReal User Monitoring #Observability Datadog上でRUMを提供する機能 APMと紐づける(以下、詳細)ことでフロントエンドで収集したデータをバックエンドのトレースと相関づけて追跡できる Connect RUM and Traces RUM Explorerでは、ユーザーセッションを1レコードとした探索が可能 https://docs.datadoghq.com/ja/real_user_monitoring/
-
Datadog/Feature Flag Tracking#Observability DatadogのRUMの機能の一つとして提供されるフィーチャーフラグ可視化ツール フーチャーフラグ単位のグルーピングを行うことで機能リリースを安全に、迅速なトラブルシューティングが可能になる Flagsmithのようないくつかのツールで統合が容易になっている https://docs.datadoghq.com/real_user_monitoring/feature_flag_tracking/
-
Datadog/pup#Observability Datadogのメトリクス、Logs、APM等をターミナルから操作するためのCLIツール。AIエージェントからの利用にも対応している 認証はOAuth2 (PKCE) によるブラウザ認証。APIキー環境変数にも対応 https://github.com/datadog-labs/pup
-
HHHアラインメント#LLM ファインチューニングをする際、以下の3つの特性を満たすようにすること helpful(有用) honest(正直) harmless(無害)
-
Daniel Avila
-
DNSラベル標準#Network RFC 1123で定義されているDNSに指定可能な文字列
-
ゴールドスタンダード#Security/Authentication #Security/Authorization ゴールドスタンダード(Gold Standard)は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証(Authentication): ユーザーが本人であることを証明 認可(Authorization): 認証されたユーザーの行動の許可・拒否を決定 監査(Auditing): システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/
-
キャズム理論購買層を以下の5つに分類する技術マーケティング手法 Innovators Early Adopters Early Majority Late Majority Laggards
-
Cargo#Programming Rustの公式パッケージマネージャ兼ビルドシステム 依存関係の管理(crates.ioからのダウンロード) プロジェクトのビルド・テスト・実行 パッケージの公開(cargo publish) ビルドプロファイル(dev/release)による最適化制御 https://doc.rust-lang.org/cargo/
-
featureファイル#Testing Cucumberによって形式づけられたテキストファイル Gherkin記法で記述する
-
Renovate/GitHub Action#Continuous Integration Renovate を GitHub Actions 上でセルフホストする公式 Action renovatebot/github-action。ホスト型 Mend Renovate App を使わず、自前リポジトリの workflow から依存更新 PR を回す前提のセットアップ 設定 workflow の on.schedule(cron)で定期実行する(例: 0/15 * * * *) 設定ファイルは configurationFile で指定(JS / JSON)。RENOVATE_ 接頭辞の環境変数はそのままコンテナへ渡る renovate-version で実行する Renovate(Docker イメージ)のバージョンを固定できる https://github.com/renovatebot/github-action
-
SCQAフォーマット#Documentation 文書の冒頭に書く要約に用いるフォーマット (S)シチュエーション (C)コンプリケーション (Q)クエスチョン (A)アンサー の4つを用いる
-
アジャイルソフトウェアの12の原則#Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則
-
Devin Wiki#Documentation #LLM Devinと連携されたリポジトリの内容を説明するWikiを生成する機能 自動でインデックスされる
-
ORMObject-Relational Mapping #Data Engineering オブジェクト指向プログラミングアプリケーションとリレーショナルデータベース間のレイヤを抽象化するプロセス
-
ArchiMate#Documentation エンタープライズ・アーキテクチャーを記述するためのグラフィカルなオープンソース言語 https://www.archimatetool.com/
-
NINES don’t matter if USERS aren’t HAPPYSREの文脈でのCharity Majorsによる主張。ナインとは可用性のこと ユーザーが満足していなければ、ナインは重要ではない
-
USM/バックボーン#Agile #Product Management ユーザーストーリーマッピングの最上部に配置されるユーザーの主要なアクティビティの流れ アクティビティを時系列で左から右に並べ、プロダクト全体のユーザージャーニーを表現する 各アクティビティの下にユーザータスクをぶら下げ、さらにその下にストーリーを配置する
-
Terraform/github_organization_ruleset#Continuous Integration Terraform GitHub provider の resource で、org 単位の ruleset を宣言する。conditions の repository_name(include/exclude) または repository_id で対象 repo 群を絞る。 rules に各種ルールを宣言でき、特に org/enterprise 専用の required_workflows(require workflows)を扱えるのが repo 単位版との違い https://registry.terraform.io/providers/integrations/github/latest/docs/resources/organization_ruleset
-
MVSMinimum Viable Solution #Agile #Product Management 期待する成果を達成できる最小のリリース単位 MVPがProductという語で新規プロダクトを想起させるのに対し、Solutionに置き換えることで既存プロダクトへのリリースにも適用できるよう概念を広げている
-
gh auth login#Security/Authentication GitHub CLI (gh) の認証コマンド。OAuth でブラウザ認証し、以降の API / Git 操作に使う長命の OAuth トークン(gho_…)をローカルに保存する 特徴 発行されるのはユーザー本人の権限・名義で動く長命トークン(明示失効するまで切れない) gh 2.24.0(2023-02)以降、保存先は OS の資格情報ストア(macOS Keychain / Windows Credential Manager / GNOME Keyring)がデフォルト。平文 ~/.config/gh/hosts.yml への保存は --insecure-storage での opt-in https://github.com/cli/cli/discussions/7109
-
Cookie/DomainCookie属性の1つ Cookieの対象とするドメイン範囲、デフォルトはオリジンとなる
-
Agile testing directions: tests and examples#Testing Agile Testingにおけるアジャイルテストの4象限の源流となったブログ記事 http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
-
Flagsmith#Continuous Delivery フィーチャーフラグ管理を行うOSSツール https://docs.flagsmith.com/
-
マルチリーダーレプリケーション#Data Engineering レプリケーションの種別の一つ 複数のデータセンターにリーダーが存在する。リアルタイムの同時編集がイメージに近い。書き込みの衝突があった際に最終的に同じ値に収束させるような方法が取られる
-
OWASP Cheat Sheet Series/Session Management#Security/Authentication セッション管理の実装指針をまとめたOWASP Cheat Sheet Series HTTP Cookie https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
-
SoRSystem of Record データの記録を重視するシステム、企業の業務基幹システム等が該当する
-
Validated Learning#Agile #Product Management 実際に作って試した結果から得られる、実証された学び。想定や意見ではなく、ユーザーの反応など観測された事実にもとづいて仮説の正否を判断する。 「構築・計測・学習」のサイクルを回して得られる。 構築(Build) 計測(Measure) 学習(Learn)
-
Vaughn Vernon
-
リチャードソン成熟度モデル#API Architecture Leonard RechardsonによるREST APIの観点からAPI実装の成熟度をレベルに分類したもの 各レベルのタイトルは以下 レベル0 HTTP/RPC レベル1 リソース レベル2 動詞(メソッド) レベル3 ハイパーメディアコントロール QCon 2008での発表は以下 Justice Will Take Us Millions Of Intricate Moves
-
anyhow#Programming Rustにおけるエラー型の扱いを楽にするライブラリ パブリックなAPIでは利用を避けて標準のエラー型を用いるのが良い anyhow - Rust
-
チェーホフの銃の誤謬有用なコンテキストが埋もれないように不要な要素は削除すること 「第一幕で壁に銃銃掛けるのであれば、次の幕でそれを撃たなければならない。もしそうでないのなら、最初からそこに掛けるべきではない」 と劇作家のアントン・チェーホフによって述べられている
-
ETLExtract transform load #Data Engineering ETL とは? - 抽出、変換、ロードの説明 - AWS
-
技術的負債の4象限Technical Debt Quadrant Martin Fowlerが技術的負債が発生するケースを4象限で分類したもの。 Reckless(無謀) or Prudent(慎重) Deliberate(意図的) or Inadvertent(不注意) の2軸で分類する。 例えばリリース当初はクリーンなコードを書いていたつもりだが、1年後に本来正しかった設計が見つかった。のようなケースではPrudentかつInadvertentとなる Blog ブログ
-
Linux Capabilitiesrootユーザーが持つ特権を細分化したもの Non-root Userへ必要最小限のケイパビリティを割り当てる方法は、Dockerの#Securityベストプラクティスとして紹介されている Docker のセキュリティ — Docker-docs-ja 1.12.RC2 ドキュメント