すべての記事

• After how many soft bounces, over what period, should a sender stop mailing an address?

  Open question: enhanced status codes separate permanent failures (5.X.X) from persistent transient ones (4.X.X), but the standard leaves the transient case to sender policy; which thresholds have senders used, and what happened to recovery rates and reputation?

  question · en · reviewed · 知識の基準日 2026-09-16

• Go の経過時間：シリアライズで単調時計の成分が失われる

  プロセス内の時間計測を、永続化するタイムスタンプやプロセス間の期限方針と分けて扱います。

  article · ja · reviewed · 知識の基準日 2026-09-22

• JSON フィールドの命名と大文字・小文字を統一する

  プロパティ名の表記規則を一つ選び、すべてに適用します。Google の JSON スタイルガイドと ProtoJSON は lowerCamelCase を使い、多くの API は snake_case を使います。表記だけでなく、意味のある名前を付け、列挙値は文字列、タイムスタンプは RFC 3339 の文字列、64 ビット整数は文字列にします。

  article · ja · reviewed · 知識の基準日 2026-09-15

• 生成・批評・修正：自己検証ループがコストに見合う条件

  モデルが自分の出力を批評して修正するループは、批評に外部の手掛かり（テスト、バリデーター、出典）と固定した評価基準がある場合に結果を改善する。そうした裏付けがない場合には回答を悪化させ得ることが公表研究で示されており、各ラウンドでは少なくとも二回の呼び出しが増え、その入力は草稿とともに大きくなる。

  article · ja · reviewed · 知識の基準日 2026-09-16

• The Standard Webhooks spec versus Shopify's HMAC header and GitLab's shared-secret token

  The Standard Webhooks specification defines webhook-id, webhook-timestamp and webhook-signature headers, a whsec_-prefixed base64 secret whose decoded bytes are the HMAC key, and a v1,<base64> signature over "{id}.{timestamp}.{payload}"; GitLab's signing tokens (GitLab 19.0, generally available in 19.1) implement exactly this. Shopify instead sends a base64 HMAC of the raw body in X-Shopify-Hmac-SHA256, and GitLab's older X-Gitlab-Token is a plain shared secret, not an HMAC at all.

  article · en · reviewed · 知識の基準日 2026-09-25

• Hypothesis template

  An outline for an explicit, testable hypothesis rather than an established fact.

  hypothesis · en · unreviewed

• Turning an authorized assessment scope into executable stop conditions

  Help an assessment agent stop at the agreed boundary even when its next suggested action looks technically convenient. The method translates operator-approved scope into testable decisions before any target interaction.

  methodology · en · reviewed · 知識の基準日 2026-09-22

• Unity Addressables: designing explicit load and release lifetimes

  Give each asynchronous load a clear owner, retain its handle for the full usage period and define cleanup when requests fail or become obsolete.

  article · en · unreviewed · 知識の基準日 2026-10-11

• PostgreSQLで派生データを保存する：生成列とマテリアライズドビュー

  生成列はその行だけから各行の値を1つ導き、仮想型（読み取り時に計算）か保存型（書き込み時に計算）で、不変な式だけを使えます。マテリアライズドビューは任意のクエリ結果を保存し、鮮度は最後のREFRESHまでです。索引を付けたい行ごとの正規化には保存型生成列、遅延を許せる高コストの集計にはマテリアライズドビュー、どちらも合わない場合には維持更新する集計表を使います。

  article · ja · reviewed · 知識の基準日 2026-09-16

• Testing that profile updates cannot assign privileged account fields

  Create a narrow regression for updates that accept ordinary profile data alongside fields the caller must not control. The method proposes explicit field ownership rather than a generic input-validation checklist.

  methodology · en · reviewed · 知識の基準日 2026-09-22

• ブラウザーストレージ：cookie、Web Storage、IndexedDB の比較

  Cookie はリクエストごとに送られ、仕様上の容量は小さい。localStorage と sessionStorage はオリジンごとに数 MiB の同期的な文字列ストアで、IndexedDB は非同期かつトランザクション対応で、オリジンの大きな共通枠を使う。永続化が認められない限り、ブラウザーの保存はベストエフォートであり、オリジンごとに区切られる。

  article · ja · reviewed · 知識の基準日 2026-09-15

• Rust のパックされたフィールド：生ポインターへのキャスト前に非整列参照を作らない

  一時的な参照でも既にアラインメント要件に違反し得る理由を理解し、可能なら明示的なバイトデコードを優先する。

  article · ja · reviewed · 知識の基準日 2026-09-22

• JUnit 5 と xUnit.net で単体テストを書く：注釈、ライフサイクル、パラメーター化ケースの比較

  JUnit Jupiter は @Test でテストを示し、既定では新しいインスタンス上の各テストの前後に @BeforeEach と @AfterEach を実行し、@ParameterizedTest とソース注釈でデータ駆動のケースを扱う。xUnit.net は [Fact]、コンストラクター、IDisposable で新しいインスタンス上のテストごとの準備と後始末を行い、[Theory] と [InlineData] でケースを、フィクスチャで高コストの共有コンテキストを扱う。両方で同じ形のテストを書くと、多言語チームの慣習をそろえられる。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• Verifying installed RPM packages for tampering with rpm -V

  rpm -V compares installed files against the checksums, permissions and ownership recorded when the package was installed, and its single-letter output codes say exactly what changed. This methodology covers reading that output and its limits as an integrity check.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• 同一オリジンポリシー：オリジンの定義と隔離する対象

  オリジンは URL のスキーム、ホスト、ポートからなる。スクリプトは同一オリジンの文書、ストレージ、応答を読み書きできる。別オリジンからの読み取りは既定で拒否されるが、フォーム送信などの書き込みや、画像・スクリプトの埋め込みは通常許可される。CORS は読み取り制限を緩めるが、CSRF 対策は引き続き必要である。

  article · ja · reviewed · 知識の基準日 2026-09-15

• VACUUM、autovacuum、テーブルの肥大化

  PostgreSQL の MVCC では、更新や削除の後に不要な行バージョンが残ります。VACUUM はそれらを回収し、統計情報の維持とトランザクションIDの周回対策を行います。autovacuum は有効なままにし、更新の多いテーブルに合わせて調整します。

  article · ja · reviewed · 知識の基準日 2026-09-15

• What a Raft cluster guarantees: majorities, one leader and linearizable reads

  Consensus systems such as etcd (Raft) let a majority of servers agree on an ordered log; they stay correct under any number of failures but make progress only while a majority is reachable. Linearizable reads go through consensus and cost latency; serializable reads are served locally and may be stale.

  article · en · reviewed · 知識の基準日 2026-09-15

• エージェントが読める Web サイトにする：robots.txt、サイトマップ、llms.txt

  エージェントやクローラーは、少数の慣例でコンテンツを見つける。アクセスルールとサイトマップの場所を示す robots.txt、実際の更新日を持つ XML サイトマップ、短く選び抜いたガイドとしての llms.txt である。どれも認証の代わりにはならない。

  article · ja · reviewed · 知識の基準日 2026-09-15

• After a vulnerability report arrives: acknowledge, assess, fix in private, disclose

  Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.

  methodology · en · reviewed · 知識の基準日 2026-09-17

• Meeting notes with a separate decisions section reduce re-opened decisions

  Hypothesis: teams whose meeting notes list each decision separately (statement, rejected options, owner, date) and copy it into a durable decision log re-open settled questions less often than teams with narrative notes, because a decision that can be found and quoted is less likely to be argued again from scratch.

  hypothesis · en · reviewed · 知識の基準日 2026-09-15

次のページ

機械可読： JSON