Tech Table Log: 同期エンジニアの雑談・勉強ログ

Lon, Shinya
  • 5.0（1）
  • テクノロジー
  • アップデート：毎週

社会人7年目の同期ソフトウェアエンジニアの二人が、お互いの近況や気になる技術トピックをゆるく雑談しながら、リスナーと一緒に学ぶPodcastです。 隔週水曜の朝に配信しています。 Shinya: PostgreSQL エンジニア (X: https://x.com/ShinyaKato_ ) Lon: ソフトウェア / 機械学習 エンジニア お便りはこちらから: https://forms.gle/n1ft3Pjdeuk4qznS6 以下のプラットフォームで配信しています。 Spotify: https://x.gd/KGYhE Apple Podcasts: https://x.gd/A6dh7 Amazon Music: https://x.gd/qwgID YouTube Music: https://x.gd/f9AeY 本Podcastでの発言は全て出演者個人の見解であり、所属する組織とは一切関係がありません。 内容は可能な範囲で精査してお届けしていますが、誤りやお気づきの点があれば、上記の Google Form などからご指摘を頂けますと幸いです。

  1. 8時間前

    #37: AI エージェント時代の大規模リファクタリング - Rewriting Bun in Rust ブログの紹介

    Anthropic に買収された JavaScript ランタイムの Bun が、Zig で書かれていた部分を Rust で書き直したブログを紹介します。Claude Code を使って 11 日間で約 50 万行のコードをリライトした事例で、Dynamic Workflows の活用方法、敵対的レビューを行うエージェント構成、ワークツリーの分割戦略など、大規模リファクタリングの具体的な進め方が詳しく解説されています。 ※ エピソード内で Bun を「フレームワーク」と呼んでいる箇所がありますが、正しくは JavaScript ランタイム(およびパッケージマネージャ等を含むツールキット)です。 PostgreSQL 非推奨機能の提案結果報告 / Bun の概要 / Zig から Rust への移行理由 / Claude Code の Dynamic Workflows / 敵対的レビューエージェントの構成 / ファイル単位・crate 単位・サブコマンド単位での段階的修正 / 64 個の Claude インスタンス並列実行 / API コスト約 2600 万円 / pg_rust プロジェクト 参考リンク Rewriting Bun in Rust (公式ブログ): https://bun.com/blog/bun-in-rust Zig 作者によるブログ: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

  2. 7月7日

    #36: AI時代の開発エコシステムはどう変わる？Googleに学ぶソフトウェアエンジニアリングの転換点

    Google I/O 2026でのAdam Bender氏の講演「Software engineering at the tipping point」を元に、AIがソフトウェア開発のエコシステム全体に与える影響について議論します。 本編では、AIによってコード生成速度が10倍になった際に生じるシステム的な歪みについて解説します。コード量の爆発的な増加がもたらすコンパイル時間の長期化やバイナリサイズの肥大化、Gitなどバージョン管理システムの負荷増大、そして人間によるコードレビューが完全にボトルネックとなる問題を取り上げます。さらに、従来の「全テストパス」を前提としたリリースフローの限界や、コストが下がるほどトークン消費が増大していく「ジェボンズのパラドックス」について考えます。 これらへの対応策として、「AIは方向を示すものではなく、組織の強みも弱みも増幅させる増幅器（Amplifier）である」という原則を紹介します。計算リソースやトークン消費の把握、インテグレーションテストの拡充といった基礎の重要性に触れつつ、個別のコード（葉）だけでなくシステム全体（森）を俯瞰する視点が今後のエンジニアに求められることについて、実務における葛藤を交えながら議論します。 Google I/O / ソフトウェア生態学 / コード生成の高速化と副作用 / コンパイルとバイナリ肥大化 / コードレビューのボトルネック / CI/CDとテスト戦略 / ジェボンズのパラドックス / AIは増幅器 (Amplifier) 参考リンク Software engineering at the tipping point#8: AI時代における新たなデータシステムを考える -論文紹介-#17: AI時代に組織に求められる性質やソフトウェア開発プロセスとは？#26: 初の対面収録！書籍『AIエージェント 人類と協働する機械』を読んで考えるソフトウェアエンジニアリングの未来#31: システムや機能の「非推奨と廃止」はどう進める？Google/Kubernetes/SQL Server/PostgreSQLに学ぶコードの終活

  3. 6月23日

    #35: PDFをAIに効率的に読ませるには？ドキュメント変換ツール Docling を紹介

    今回は PDF などのドキュメントを AI フレンドリーな形式に変換するツール Docling と、それがサポートする規格の一つである DocLang について紹介しました。PDF がなぜ AI にとって読みにくいのか、その課題と Doclingがどのようにレイアウト分析や VLM を活用して変換を行っているかを解説しています。 注: エピソード内で Docling に関する technical paper が 2024年12月に出ていると言及しましたが、初版は2024年8月でした。 リスナーコメント紹介 / PDF が AI フレンドリーでない理由 / Docling の変換パイプライン / レイアウト分析と VLM の活用 / DocLang の XML ベース形式 / 位置情報の量子化 / Claude Code での PDF 読み込み 参考リンク Docling (GitHub): https://github.com/docling-project/docling DocLang (GitHub): https://github.com/doclang-project/doclang LF AI & Data Projects: https://lfaidata.foundation/projects/ Anthropic API の PDF サポート: https://platform.claude.com/docs/en/build-with-claude/pdf-support

  4. 6月9日

    #34: PostgreSQLのロック：アプリ開発の「はまりどころ」から内部実装まで（後編）

    PostgreSQLのロックの仕組みについて、データベース内部実装（SpinlockやLWLockなど）のディープな世界を深掘りする2回エピソードの後編です。 今回は、DBAやデータベース開発者、並行プログラミングに関心がある方向けに、PostgreSQLの内部的な排他制御を解説します。CPUのアトミック命令であるCAS (Compare-and-Swap) を前提知識として、WAL (Write-Ahead Logging)の書き込みなどで使われ競合時にスリープする「Lightweight Lock (LWLock)」と、スリープせずにCPUを回し続けてロック獲得を待つ「Spinlock」の仕組みや用途の違いを整理します。 さらに、Linux 7.0環境で話題になったPostgreSQLの性能劣化問題の真相に迫ります。カーネルのスケジューラ変更（プリエンプションの挙動変化）がSpinlockに与えた影響や、PostgreSQLコミッタが指摘する、Spinlockをfutexに置き換えることの構造的な難しさを紹介します。また、この性能劣化報告の根本的な原因が「Huge Pages」の未設定によるTLBミスとページテーブル探索のオーバーヘッドにあったことを挙げ、OS・CPUレベルの適切なパラメータ設定がいかに重要であるかを議論します。 PostgreSQL内部実装 / CAS命令 (Compare-and-Swap) / Lightweight Lock (LWLock) / Spinlock / WAL書き込み / Linux 7.0性能劣化問題 / プリエンプション / futex / Huge Pages / パラメータチューニング 参考リンク ⁠PostgreSQLのロックでハマりがちな挙動5選⁠⁠AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy⁠⁠I really dislike the use of spinlocks in postgres

  5. 5月26日

    #33: PostgreSQLのロック：アプリ開発の「はまりどころ」から内部実装まで（前編）

    PostgreSQLのロックの仕組みについて、アプリケーション開発者向けの視点から、データベース内部実装（SpinlockやLWLockなど）のディープな世界までを2回に分けて深掘りします。 前編となる今回は、アプリケーション開発者が気を付けるべき「はまりどころ」を解説します。複数トランザクションの同時更新や本番環境でのDDL（ALTER TABLEなど）実行時など、ロックの理解が不可欠なケースを取り上げ、4種類のテーブルロックと行ロック（FOR UPDATE）の基本を整理します。 さらに、実践的な5つのトラブルケースとその対策を紹介します。長時間のSELECTとALTER TABLEが引き起こす連鎖的なブロックや、外部キー・ユニーク制約の暗黙的ロックによるINSERT同士のデッドロックを解説します。また、例外的に自動キャンセルされない「トランザクションID周回防止バキューム」や、テーブルファイル末尾のページ切り詰め処理に潜む罠など、予期せぬサービス停止を防ぐための知識を議論します。 PostgreSQLのロック / MVCC / テーブルロックと行ロック / FOR UPDATE / Access Exclusive / デッドロック / ALTER TABLEの連鎖ブロック / 外部キー・ユニーク制約の暗黙的ロック / トランザクションID周回防止バキューム / ページ切り詰め 参考リンク PostgreSQLのロックでハマりがちな挙動5選AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be EasyI really dislike the use of spinlocks in postgres

  6. 5月12日

    #32: AIエージェントのためのサンドボックス入門！ Boundary、Policy、Lifecycleの3軸と Claude Code / Codex Sandbox の裏側や設定上の注意について

    Lonが「A Field Guide to Sandboxes for AI」というMistral AIのエンジニア Luisさんが書いたブログを紹介しながら、AIエージェントを安全に実行するためのサンドボックス環境について勉強した内容を共有しています。サンドボックスを正しく理解するための3つの軸（Boundary、Policy、Lifecycle）と、4種類のBoundary（コンテナ、gVisor、microVM、Wasm）の違いを学びます。また、Claude CodeやCodexが採用しているSeatbelt（Mac）やBubblewrap（Linux）についても紹介しています。 配信プラットフォーム追加のお知らせ / サンドボックスとは何か / Boundaryの4種類 / コンテナの仕組み（namespaces、capabilities、cgroups、seccomp） / gVisorとSentry / microVMとゲストカーネル / WebAssembly / Policyの重要性 / Lifecycle / Claude CodeのサンドボックスとSeatbelt・Bubblewrap / Credentialの安全な扱い方 / Proxyパターン 補足・訂正 Wasm の説明で「ランタイムで定義されたシステムコールだけがホストカーネルを呼ぶ」と表現しましたが、正確には Wasm モジュール自体は system call を行えず、WASI (WebAssembly System Interface) API を介してランタイムが host system call に翻訳する形になります。 参考リンク A Field Guide to Sandboxes for AI: https://www.luiscardoso.dev/blog/sandboxes-for-ai Claude Code Sandboxing: https://code.claude.com/docs/en/sandboxing Securely Deploying AI Agents (Claude Code): https://code.claude.com/docs/en/agent-sdk/secure-deployment#containers WebAssembly System Interface (WASI): https://wasi.dev/

  7. 4月28日

    #31: システムや機能の「非推奨と廃止」はどう進める？Google/Kubernetes/SQL Server/PostgreSQLに学ぶコードの終活

    システムや機能の「非推奨」と「廃止」について議論します。PostgreSQLに20年以上前から残る古いCOPY構文を削除したいという課題意識から出発し、様々なプロダクトの機能廃止ポリシーを比較します。O'Reilly『Googleのソフトウェアエンジニアリング』で語られる「コードは資産ではなく債務である」という考え方や、廃止を難しくする3つの要因、そして勧告的廃止と強制的廃止の違いについて解説します。さらに、Kubernetesにおける厳格なAPI・メトリクスの廃止ルールとそれを活用したGKEの自動アップグレードの仕組み、SQL Serverの非推奨機能のトラッキング機能などを紹介します。最後に、明確な廃止ルールのないPostgreSQLの現状に触れ、今後の「非推奨機能の使用統計を取る機能」の提案に向けた展望について語ります。 システム・機能の非推奨と廃止 / Googleのソフトウェアエンジニアリング / コードは資産ではなく債務 / 勧告的廃止と強制的廃止 / KubernetesのAPI Deprecation Policy / GKEの自動アップグレード機能 / SQL Serverの非推奨機能メトリクス / PostgreSQLの廃止ポリシー 参考リンク GoogleのソフトウェアエンジニアリングKubernetes Deprecation PolicyGoogle Kubernetes Engine (GKE) | Feature and API deprecationsSQL Server, Deprecated Features objectPostgreSQL: A deprecation policy

  8. 4月14日

    #30: Claude Code を活用するためのスキルパック gstack - その思想と哲学を読み解く

    Y Combinator CEO の Garry Tan が公開した Claude Code 向けスキルパック「gstack」について紹介します。gstack は think, plan, build, review, test, ship, reflect というスプリントを回すためのプロセスを定義したものです。ETHOS.md に書かれた「Boil the Lake」「Search Before Building」「User Sovereignty」という3つの哲学や、CEO レビュー・エンジニアレビューなど様々な役割を持つスキルの設計思想について深掘りしました。 gstack / ETHOS.md / Boil the Lake / Claude Code スキルパック / Y Combinator / Garry Tan / AI エージェント / User Sovereignty 参考リンク gstack GitHub リポジトリ: https://github.com/garrytan/gstack/tree/main Boil the Ocean (Garry Tan のブログ記事): https://garryslist.org/posts/boil-the-ocean

すべて見る（37）

番組について

社会人7年目の同期ソフトウェアエンジニアの二人が、お互いの近況や気になる技術トピックをゆるく雑談しながら、リスナーと一緒に学ぶPodcastです。 隔週水曜の朝に配信しています。 Shinya: PostgreSQL エンジニア (X: https://x.com/ShinyaKato_ ) Lon: ソフトウェア / 機械学習 エンジニア お便りはこちらから: https://forms.gle/n1ft3Pjdeuk4qznS6 以下のプラットフォームで配信しています。 Spotify: https://x.gd/KGYhE Apple Podcasts: https://x.gd/A6dh7 Amazon Music: https://x.gd/qwgID YouTube Music: https://x.gd/f9AeY 本Podcastでの発言は全て出演者個人の見解であり、所属する組織とは一切関係がありません。 内容は可能な範囲で精査してお届けしていますが、誤りやお気づきの点があれば、上記の Google Form などからご指摘を頂けますと幸いです。

情報

その他のおすすめ