Sort by - linked count
-
Gaspar Nagy
-
ファシリテーション#Team Organization Team Topologiesにて紹介される3つのチーム間インタラクションの内の1つ イネイブリングチームが行うような短期的な技術支援が該当し、チーム間の能力のギャップを最小化する
-
スタッフエンジニアWill Larsonがまとめたスタッフエンジニアに関する情報サイト https://staffeng.com/
-
Apache Iceberg#Data Engineering 分析データセット向けのオープンテーブルフォーマット(公式には "The open table format for analytic datasets")。オブジェクトストレージ上のデータファイルに SQL テーブルの信頼性とシンプルさをもたらす仕様で、Spark・Trino・Flink・Hive など複数のエンジンが同一テーブルへ同時アクセスできる スキーマ進化: 列の追加・リネーム・並べ替えを安全に行える(zombie data を発生させない) 隠蔽パーティショニング: 行からのパーティション値生成をテーブル側が担い、不要なパーティションの読み取りをスキップする タイムトラベル: 同一スナップショットを参照する再現可能なクエリ MERGE INTO / UPDATE / DELETE と、ファイルレイアウト最適化(コンパクション)に対応 https://iceberg.apache.org/
-
zizmor/unpinned-uses#Security zizmorの audit。uses: で third-party action を tag や branch 名(@v3、@main)で参照し、コミットSHAで pin していないケースを検出する 検出例 - uses: pypa/gh-action-pypi-publish@v1.12.4 - uses: docker://ubuntu なぜ危険か 上の @v1.12.4 (action tag) や docker://ubuntu (image tag 省略) は publisher 側で参照先を書き換え可能 — 過去に正当だったタグが後日マルウェア入りコミットを指すよう移動されると、CI を信用しているワークフロー全てが侵害される 近年の tj-actions/changed-files 事件はこのパターン: 同一 tag が遡及的に汚染されたコミットへ rebound された SHA は immutable なので、内容が変わらないことを暗号学的に保証できる 改善例 - uses: pypa/gh-action-pypi-publish@76f52bc884231f62b9a034ebfe128415bbaabdfc # v1.12.4 - uses: docker://ubuntu:24.04 https://docs.zizmor.sh/audits/#unpinned-uses
-
zizmor/dangerous-triggers#Security zizmorの audit。pull_request_target や workflow_run のような書き込み権限と secrets を持ったまま走るトリガーの使用を検出する 検出例 on: pull_request_target なぜ危険か 上の pull_request_target は fork PR からのトリガーでもベースリポジトリの context で実行され、secrets と書き込み token がジョブに渡る fork PR の内容(タイトル、ref、checkout した head のコード)を信頼して扱うと、攻撃者がリポジトリの secrets 窃取やコミット改竄できる workflow_run も同種の高権限トリガー 改善例 on: pull_request https://docs.zizmor.sh/audits/#dangerous-triggers
-
GitHub Enterprise Cloud#Continuous Integration GitHub の最上位プラン GitHub Enterprise を、GitHub がホスト(github.com 上の SaaS)する形態で提供するもの。略称 GHEC。もう一方の提供形態は self-hosted の GitHub Enterprise Server (GHES)。 複数 organization を束ねる「enterprise アカウント」を持ち、ポリシー・課金・ruleset を enterprise レベルで一元管理できる https://docs.github.com/en/get-started/learning-about-github/githubs-plans https://github.com/pricing
-
オブザーバビリティ成熟度モデル
-
Istio/VirtualService#API Architecture Istioにおいて、トラフィックルーティングルールを定義するカスタムリソース(CRD)。 DestinationRuleと組み合わせてSubset単位でルールを設定可能 以下のようなことが実現できる Subsetの切り替えによるブルーグリーン戦略 weightの設定によるカナリアリリース timeoutの設定によるタイムアウト https://istio.io/latest/docs/reference/config/networking/virtual-service/
-
Istio/Subset#API Architecture Istioにおいて、Labelを用いてPodのまとまりを定義する方法 https://istio.io/latest/docs/reference/config/networking/destination-rule/#Subset
-
Istio/AuthorizationPolicy#Security/Authorization Istioにおいてアプリケーション(L7)認可の役割を担うリソース KubernetesのCRDによって用意されており、Network policyに比べ柔軟でHTTP特有の設定が可能 Istio / Authorization Policy
-
Istio/DestinationRule#API Architecture Istioにおいて、トラフィックに対するポリシーを定義するカスタムリソース(CRD) 以下のようなことが実現できる Subsetの定義 サーキットブレーカーの設定 https://istio.io/latest/docs/reference/config/networking/destination-rule/
-
Istio/Gateway#API Architecture Istioにおいて、トラフィックの入り口または出口となるカスタムリソース(CRD) 入り口として受けたトラフィックはVirtualServiceに流す https://istio.io/latest/docs/reference/config/networking/gateway/
-
Four Keys/変更障害率Change Failure Rate DevOps
-
Four Keys/デプロイの頻度Deployment Frequency DevOps
-
Four Keys/サービス復元時間Time to Restore Services DevOps
-
newtype#Programming 既存型をラップする形で新たな型を定義する 型エイリアスのように使われることが多いが、型エイリアスと異なりあくまで別の型として扱う
-
tj-actions/changed-files#Continuous Integration GitHub Actions の workflow 内で、PR / push で変更されたファイルの一覧を出力する community action tj-actions/changed-files。後続 step は出力を参照し、変更パスに応じて処理を分岐できる https://github.com/tj-actions/changed-files
-
CSS#Programming Webページの見た目やレイアウトを定義するスタイルシート言語 HTMLの構造と表示を分離し、セレクタとプロパティでスタイルを適用 Tailwind CSS等のユーティリティファーストフレームワークの基盤
-
USM/ナラティブフロー#Agile #Product Management ストーリーマップを左から右に読んだときに、ユーザーの行動が一連の物語として自然につながるような並びの流れ。
-
Write the Docs#Documentation ドキュメンテーションに関心を持つ人たちを歓迎するコミュニティ https://www.writethedocs.org/
-
プロダクトバックログアイテム#Agile #Product Management プロダクトバックログ上で生まれるアイテム、要件、テストなどをまとめるハブになる
-
Dependency Injection#Software Design #Programming オブジェクトやコンポーネントの依存関係を外部から注入する設計パターン クラスが必要とする依存オブジェクトを自身で生成せず、外部のアセンブラ(DIコンテナなど)から提供される。これにより、クラス間の結合度が低下し、テスト容易性、柔軟性、再利用性が向上する
-
Dapr
-
ファインチューニング#LLM 事前トレーニング済みのGPTが特定のタスクを行う際に行う微調整
-
DevOps capabilities/Continuous delivery#Continuous Delivery DevOps capabilitiesの1つ、Fast Flowに分類される https://dora.dev/capabilities/continuous-delivery/
-
DevOps capabilities/Trunk-based development#Continuous Integration トランクベース開発。DevOps capabilitiesの1つで、Fast Flowに分類される Working in small batchesをベースに少なくとも1日に一回はトランクブランチにマージをする テストの自動化も重要な要素となる DORA | Capabilities: Trunk-based Development
-
DevOps capabilities/Work in process limits#Agile WIP制限(Work in Process limits)。DevOps capabilitiesの1つで、Fast Flowに分類される https://dora.dev/capabilities/work-in-process-limits/
-
DevOps capabilities/Visibility of work in the value streamDevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Visibility of work in the value stream
-
DevOps capabilities/Continuous integration#Continuous Integration DevOps capabilitiesの1つ、Fast Feedbackに分類される CIを実現するには次の要素が必要としている 自動化されたビルドプロセス 自動化されたテストスイート チェックイン毎の自動ビルドとテスト また次の2つも効果に繋がる Trunk-based development Working in small batches メンテナンス容易な自動化テストのためにはTDDを実践すると良い DORA | Capabilities: Continuous integration
-
DevOps capabilities/Loosely coupled teams#Software Design DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Loosely coupled teams
-
DevOps capabilities/Customer feedbackDevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Customer feedback
-
Cosign#Security Sigstore の CLI(client)。container image / blob / artifact の署名と 署名検証 を行う 署名のたびに ephemeral 鍵ペアを生成する keyless 方式に対応する(鍵を保管しない identity-based モデル) 自前鍵による key-based 署名もサポートする https://docs.sigstore.dev/cosign/signing/overview/
-
React Server ComponentsRSC #Programming React 19で安定版となったサーバー上で実行されるコンポーネントアーキテクチャ 主な特徴: サーバーでレンダリングされ、クライアントにJavaScriptを送信しない RSC Payloadとしてシリアライズされた形式でクライアントに送信 <Suspense>境界によるストリーミングレンダリングをサポート クライアントコンポーネントは"use client"ディレクティブで宣言 https://react.dev/reference/rsc/server-components
-
10+ Deploys Per Day: Dev and Ops Cooperation at FlickrSlideshare DevOps
-
ETLExtract transform load #Data Engineering ETL とは? - 抽出、変換、ロードの説明 - AWS
-
DevOpsトポロジー#Team Organization 2013年にMatthew Skeltonによって書かれたブログ、Team Topologiesの根底にある考えがまとまったような内容になっている 訳: 吉羽 龍太郎 https://www.ryuzee.com/contents/blog/14567 DevOps
-
単一責任の原則#Software Design SOLID原則の1つであり、オブジェクト指向プログラミングにおける一般的なプラクティス コードの部品は1つだけのことを行い、他のことは行ってはならないということ
-
Pwned Passwords#Security/Authentication 既知のデータ侵害で利用されたパスワードかどうかを検証できるサービス、API https://haveibeenpwned.com/Passwords
-
SOLID#Software Design Single responsibility principle Open/Closed principle Liskov substitution principle Interface segmentation principle Dependency inversion principle の頭文字を取った原則。オブジェクト指向プログラミングの文脈で語られる 2000年にRobert C. Martinによって原則群が発表された
-
gopls#Programming Goの公式Language Server。Goチームによって開発されている 主な特徴: コード補完、定義へのジャンプ、参照検索、フォーマット、リファクタリングなど多様なIDE機能を提供 LSP対応エディタと自動統合されるため直接操作は不要 Go module、multi-module、GOPATHモードのワークスペースをサポート https://go.dev/gopls/ https://github.com/golang/tools/tree/master/gopls
-
Renovate/minimumReleaseAge#Security Renovate の設定オプション。パッケージのリリースが公開されてから指定期間(例: "3 days" / "1 week")経過するまで、そのバージョンへの更新 PR を作らず待機させる(旧名 stabilityDays) security 文脈 公開直後の悪意あるバージョンを取り込むのを避けるサプライチェーン攻撃の緩和策。コミュニティが侵害パッケージを検知・撤回するまでの猶予を置いてから更新する automerge と併用すると、自動マージ前のクールダウン期間として機能する 設定例 renovate.json で全更新に 3 日のクールダウンを課す。 { "minimumReleaseAge": "3 days" } https://docs.renovatebot.com/configuration-options/#minimumreleaseage
-
Apache/Pekko#Programming Akka 2.6.xからフォークされたApache Software Foundation管理の並行・分散アプリケーションフレームワーク。Java/Scalaで利用可能 アクターモデルに基づき、軽量なアクターがメッセージパッシングで通信することでスレッド管理の複雑さを隠蔽する https://pekko.apache.org/
-
Apache/Kafka#Data Engineering イベントストリーミングプラットフォームのメッセージブローカーOSS イベントのPub/Sub、ストリーミングの保持を行う https://kafka.apache.org/documentation/#intro_streaming
-
コンプリケイテッド・サブシステムチーム#Team Organization #Security/Authentication #Security/Authorization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する
-
要件定義#Documentation 「何を作ればよいのか」を明確にするために行う
-
RUMReal User Monitoring #Observability 個々のユーザーのアクティビティをリアルタイムで可視化するもの JavaScriptのようなクライアントサイドの技術を用いて、ブラウザやアプリケーションから直接データを収集する
-
mise/Backendmise が tool を install するために用いる package manager / ecosystem。Dev Tools はこれを通じて tool を管理する mise は管理対象の tool に応じて使う backend を自動で判定する backend:tool の命名で明示参照できる(例 npm:prettier, pipx:black) https://mise.jdx.dev/dev-tools/backends/
-
エラーバジェットSREにおいてリリース可否を決めるための指標となるような考え方。 SLOを満たせない時間を名前の通り予算として管理する。 エラーバジェットが残っていればリリース可能、エラーバジェットを使い切っていればリリースはストップしシステムの改善を行うというような運用をする。 エラーバジェットによってプロダクト開発者とSREでイノベーションと信頼性のバランスを適切に扱う
-
Argo