Sort by - linked count
-
Flagsmith#Continuous Delivery フィーチャーフラグ管理を行うOSSツール https://docs.flagsmith.com/
-
Getting in the roomWill Larsonによる、スタッフエンジニアの文脈で、ミーティングへの参加方法・心得等について話されているブログ https://lethain.com/getting-in-the-room/
-
The Laws of Identity#Security Kim Cameronが提唱したデジタルアイデンティティシステムの設計原則 アイデンティティメタシステムが満たすべき7つの法則: User Control and Consent(ユーザー制御と同意): ユーザーがアイデンティティ情報の開示を制御できる Minimal Disclosure for a Constrained Use(最小限の開示): 特定の目的に必要な最小限の情報のみを開示 Justifiable Parties(正当な当事者): アイデンティティ情報は正当な目的を持つ当事者にのみ開示 Directed Identity(指向性アイデンティティ): ユニバーサル識別子と方向性識別子の両方をサポート Pluralism of Operators and Technologies(多元性): 複数のアイデンティティ技術とプロバイダーの共存 Human Integration(人間との統合): ユーザーが理解し判断できるシステム設計 Consistent Experience Across Contexts(一貫した体験): コンテキスト間で一貫したユーザー体験を提供 https://www.identityblog.com/?p=352
-
NINES don’t matter if USERS aren’t HAPPYSREの文脈でのCharity Majorsによる主張。ナインとは可用性のこと ユーザーが満足していなければ、ナインは重要ではない
-
Working Agreement#Team Organization チームで決めたチームのルールのこと 価値観や行動規範を具体的に示す
-
アジャイルソフトウェアの12の原則#Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則
-
Devin Search#LLM Devinと連携されたリポジトリに対して回答を得るAsk特化のAIアシスタント 検索対象は自動でインデックスされる https://docs.devin.ai/work-with-devin/devin-search
-
SoRSystem of Record データの記録を重視するシステム、企業の業務基幹システム等が該当する
-
分散コンピューティングの8つの誤謬#Network 分散システムを扱い際、しばしば陥りがちなネットワークへの仮定を8つリストアップしたもの ネットワークは信頼性がある レイテンシはゼロ 帯域幅は無限 ネットワークは安全 トポロジは変わらない 管理者は1人だけ 転送コストはゼロ ネットワークは均質 https://nighthacks.com/jag/res/Fallacies.html
-
マルチステージビルド#Continuous Delivery Dockerfile内で複数のビルドステージ(FROM命令)を定義し、最終的に必要なアーティファクトのみを抽出して軽量なコンテナイメージを作成する手法 メリット イメージサイズの大幅削減: ビルドツールを含まないため、最終イメージサイズを大幅に削減(例: 729MB → 26.2MB) セキュリティ向上: ビルドツールやソースコードが実行環境に残らない 効率的なCI/CDパイプライン: ビルド環境と実行環境の明確な分離により運用がシンプル化 https://docs.docker.jp/develop/develop-images/multistage-build.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/
-
仮説検証型アジャイル開発#Agile #Product Management 市谷 聡啓による仮説検証型アジャイル開発の資料 https://drr.red/
-
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
-
llms.txt#Documentation WebサイトのコンテンツをLLMが効率的に利用するための提案標準。Jeremy Howard(Answer.AI)が2024年に提案 サイトルートにMarkdown形式で /llms.txt を配置しLLM向けの構造化された目次を提供する コンテキストウインドウの効率的な活用のためHTMLのノイズを排除する https://llmstxt.org/
-
Elastic Load Balancing#Cloud Native #API Architecture AWSが提供するロードバランシングコンポーネント リソースごとに以下のような種別がある Application Load Balancer Network Load Balancer Gateway Load Balancer What is Elastic Load Balancing? - Elastic Load Balancing
-
オブザーバビリティ・エンジニアリング
-
テスト範囲#Testing ユニットテスト、インテグレーションテスト、E2Eテストのように、対象となる範囲でテストを分類する際に用いられる言葉
-
スクラム/5つの価値基準スクラムのスクラムガイドで紹介されている5つの価値基準 確約(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage)
-
スクラム/インクリメント#Agile スクラムの成果物として、動作するプロダクトのこと
-
スクラム/経験主義の三本柱スクラムが経験主義をベースにスクラムガイドで紹介している三本柱 透明性 検査 適応
-
サービスの信頼性の階層
-
SerenityJS#Testing BDDフレンドリーなビジネスに重点を置いたテスト自動化を実現するTypeScript製のテストフレークワークライブラリ PlaywrightのようなE2Eテストライブラリを抽象化し統合できる https://serenity-js.org/
-
URNUniform Resourde name URIのサブセットであり、 urn:スキームから開始する
-
Devin Wiki#Documentation #LLM Devinと連携されたリポジトリの内容を説明するWikiを生成する機能 自動でインデックスされる
-
ドメインイベントドメイン駆動設計において、ドメイン内で起きた出来事をモデル化する構成要素。 ドメイン イベント: 設計と実装 - .NET Domain Events and Eventual Consistency
-
リチャードソン成熟度モデル#API Architecture Leonard RechardsonによるREST APIの観点からAPI実装の成熟度をレベルに分類したもの 各レベルのタイトルは以下 レベル0 HTTP/RPC レベル1 リソース レベル2 動詞(メソッド) レベル3 ハイパーメディアコントロール QCon 2008での発表は以下 Justice Will Take Us Millions Of Intricate Moves
-
USM/バックボーン#Agile #Product Management ユーザーストーリーマッピングの最上部に配置されるユーザーの主要なアクティビティの流れ アクティビティを時系列で左から右に並べ、プロダクト全体のユーザージャーニーを表現する 各アクティビティの下にユーザータスクをぶら下げ、さらにその下にストーリーを配置する
-
広木 大地
-
What Does Sponsorship Look Like?スポンサーシップについて論じているブログ https://larahogan.me/blog/what-sponsorship-looks-like/
-
ArchiMate#Documentation エンタープライズ・アーキテクチャーを記述するためのグラフィカルなオープンソース言語 https://www.archimatetool.com/
-
Spire#Programming #Security Scala言語の数値型ライブラリ。汎用的で高速かつ高精度な数値と、効率的な数値コードシンタックスを提供する。 Spire Introduction to Spire Numeric Programming in Scala with Spire JOTB19 - Numeric Programming with Spire by Lars Hupel
-
ORMObject-Relational Mapping #Data Engineering オブジェクト指向プログラミングアプリケーションとリレーショナルデータベース間のレイヤを抽象化するプロセス
-
成瀬 允宣
-
CloudEvents#Cloud Native イベントデータのフォーマットを定義するベンダーニュートラルな仕様 CNCF graduated project。サービス、プラットフォーム、システム間でのイベントの相互運用性を提供する https://cloudevents.io/
-
HelmfileHelmチャートをデプロイするための宣言的な仕様を提供するツール 複数のKubernetes向けHelmリリースをYAMLファイルで宣言的に管理し、環境ごとの値のオーバーライド、リリース間の依存関係定義、デプロイの差分確認(diff)を行える 宣言的な構成管理はInfrastructure as Codeの実践であり、GitOpsワークフローやDevOpsの文脈に適する https://helmfile.readthedocs.io/en/latest/
-
Knative ServingKnativeにおいて、KubernetesのCRDによって4種類のリソースを定義しアプリケーションの提供を行う Serviceの別APIのようなサービスディスカバリパターン Scale to zeroや自動スケーリングによるリソース効率の最適化が主な目的 https://github.com/knative/specs/blob/main/specs/serving/overview.md
-
Being GlueAuthor: Tanya Reilly Glue Workについて論じたブログ。コーディング以外の不可欠な仕事が昇進評価で軽視され、特に女性・少数派が引き受けがちでキャリアの罠になると指摘する 昇進制度は可視的な技術成果を評価し、関係性・組織的な労働を見落とす 対策: マネージャと昇進基準を会話する/Tech Lead 等の肩書きで正当化する/成果を可視化する/技術力も意図的に伸ばす(スタッフエンジニアの道 の IC パス) https://www.noidea.dog/glue/
-
テイルレイテンシp95, p99, p999のような極端に悪い外れ値を考慮外にする大きなパーセンタイル値のこと 信頼性の計測において用いられる
-
How GitHub used secret scanning to reach inbox zero#Security GitHub 社内の Secret Scanning 運用事例記事。15,000+ リポジトリで 20,000+ 件のアラートを 9 か月でゼロにするまでの段階的プロセスを公開している 初期アラートの 90%(18,000 件)はテストフィクスチャ由来のノイズ。5 リポジトリが全ノイズの大半を占めた 検出後の「ルーティング」が最大の課題。PAT などのクレデンシャル有効性確認・オーナーシップ特定・プレイブック整備の順で系統化した Push Protection を組織全体に強制適用(オプトアウト不可)することで再流入を防止 DevSecOps の実践例: 検出自動化に留まらず修復ワークフロー全体を自動化することが重要であると結論付けている 8 教訓: 生の件数を信用しない・組織横断で強制適用・クレデンシャル有効性確認を先行・メタデータ充実・永続的オーナーシップ基盤・検出後ワークフロー自動化・健全性メトリクス化・意思決定フレームワーク文書化 https://github.blog/security/application-security/how-github-used-secret-scanning-to-reach-inbox-zero/
-
Beyond the Twelve-Factor App#Software Design #Cloud Native #Security/Authentication #Security/Authorization #API Architecture #Observability The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している 追加された新要因は API First、Telemetry、Authentication and Authorization の3つ 既存要因にも Kubernetes ConfigMap/Secrets や Infrastructure as Code(IaC)による環境構築など、現代的なベストプラクティスを反映した注釈が加わる https://www.vmware.com/docs/ebook-beyond-the-12-factor-app
-
Known knowns意識をしており確認していること
-
SCQAフォーマット#Documentation 文書の冒頭に書く要約に用いるフォーマット (S)シチュエーション (C)コンプリケーション (Q)クエスチョン (A)アンサー の4つを用いる
-
CloudNativePG#Cloud Native #Data Engineering Kubernetes上でPostgreSQLクラスタのライフサイクルを管理するOperator プライマリ/スタンバイ構成によるストリーミングレプリケーションで高可用性を実現 外部HAツール(Patroni等)に依存せずKubernetes APIと直接統合 CNCF sandbox project https://cloudnative-pg.io/
-
Linux Capabilitiesrootユーザーが持つ特権を細分化したもの Non-root Userへ必要最小限のケイパビリティを割り当てる方法は、Dockerの#Securityベストプラクティスとして紹介されている Docker のセキュリティ — Docker-docs-ja 1.12.RC2 ドキュメント
-
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
-
MADRMarkdown Architectural Decision Records #Documentation ADRを記述するテンプレートカテゴリの一つ。マークダウンによって構造化された文書を提供する bare / minimal / full の3バリアントを持ち(現行 4.0.0)、決定の重さに応じて使い分けられる。共通の核は Context and Problem Statement / Considered Options / Decision Outcome で、full はこれに Decision Drivers / Pros and Cons of the Options / Confirmation 等を加える https://github.com/adr/madr/tree/develop/template About MADR | MADR
-
OWASP Security Champions/Trust your championsOWASP Security Champions の成功原則の1つ 自律と裁量を与えることで、チャンピオンのエンゲージメントとオーナーシップを引き出す https://securitychampions.owasp.org/principles/05_Trust_your_champions/
-
OWASP Security Champions/Secure management supportOWASP Security Champions の成功原則の1つ リーダーシップの支持とスポンサーシップが、必要なリソースと組織的な権限を確保する https://securitychampions.owasp.org/principles/03_Secure_management_support/
-
OWASP Security Champions/Anticipate personnel changesOWASP Security Champions の成功原則の1つ 人事異動を見越して計画し、プログラムの継続性と持続性を保つ https://securitychampions.owasp.org/principles/10_Anticipate_personnel_changes/