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

システムや機能の「非推奨」と「廃止」について議論します。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

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/mainBoil the Ocean (Garry Tan のブログ記事): https://garryslist.org/posts/boil-the-ocean

データベース向けMCP (Model Context Protocol)サーバーについて読み解く2回エピソードの後編となる今回は、PostgreSQLエンジニアのShinyaが自作した「PostgreSQL開発補助用MCPサーバー」のアーキテクチャや設計思想について深掘りします。PostgreSQLの開発はメーリングリスト（pgsql-hackers）で行われており、情報の検索性やAIエージェントからのアクセスに課題がありました。この課題を解決するため、Claudeと壁打ちしながら設計を進めたプロセスを紹介します。pg_trgm（3文字区切り）やtsvector（単語区切り）といったPostgreSQLの組み込み・拡張機能を用いた強力な全文検索インデックスの活用方法について、データベースエンジニアの視点から解説します。また、長大な引用メールによるトークン消費問題などの課題や、MCPサーバー実装での学びについても議論します。PostgreSQL開発とメーリングリスト / 自作MCPサーバー / Claudeとの壁打ち設計 / FastMCP / pg_trgmとtsvectorによる全文検索 / 長大な引用とトークン消費問題

DBHub が公開したテックブログを元に、PostgreSQL 向け MCP (Model Context Protocol) サーバーの現状について読み解きます。2回に分けたエピソードの前編となる今回は、Google のToolBox for Databases、Supabase、そして DBHub の3つの MCP サーバーの実装と特徴を比較します。各サーバーにおけるコンテキストウィンドウ（トークン消費量）節約の工夫や、OIDC 認証と RLS (Row-Level Security) を連携させたアクセス制御について解説します。さらに、MCP を経由した SQL インジェクションやプロンプトインジェクションの実例を挙げ、AI エージェントにおける最小権限の原則などセキュリティ対策の重要性について議論します。なお、冒頭では番組の隔週配信化とクオリティ向上への取り組みについても報告しています。番組の隔週配信化 / MCP (Model Context Protocol) とデータベース / Google ToolBox for Databases / OIDC 認証と RLS (Row-Level Security) / Supabase MCP サーバー / DBHub とトークン消費の最適化 / MCP 経由の SQL インジェクション / プロンプトインジェクションと AI エージェントの権限管理参考リンクThe State of Postgres MCP Servers in 2025googleapis/genai-toolboxsupabase-community/supabase-mcpMCP vulnerability case study: SQL injection in the Postgres MCP serverSupabase MCP can leak your entire SQL database

今回も引き続きポッドキャストバー「雑談」での対面収録。対面での収録はリモートと比べて話しやすく、アイコンタクトや目配せができるなど、コミュニケーションの違いを実感しました。キャリアの深掘りとして、お互いが情報系・物理系に進んだきっかけや、 Shinya がデータベースを選んだ理由について語り合いました。また、開発環境やガジェット、エディター、便利ツール、仕事での英語使用、最近ハマっていることなど、幅広いトピックについて雑談しました。対面収録の感想 / キャリアの原点(情報系・物理系を選んだ理由) / ガジェット紹介(キーボード・ディスプレイ・椅子) / VS CodeとVim / Coding agent (Claude Code・Gemini CLI・CodeX) / 仕事での英語 / 最近ハマっているもの

今回は初の対面収録をポッドキャストバー「雑談」から配信。広木大地さんの著書『AIエージェント 人類と協働する機械』を紹介し、AIがソフトウェア開発に与える影響について3つの視点から議論しました。ソフトウェアエンジニアの需要は増えるのか減るのか、解くべき課題がどう変わるのか、そしてマクロとミクロの視点をどう持つべきかを深掘りしています。初の対面収録 / ポッドキャストバー「雑談」 / 25回収録の振り返り / AIエージェント書籍紹介 / ジェヴォンズのパラドックス / System of Knowledge Generation (SOK) / Forward Deployed Engineer (FDE) / 暗黙知の結晶化 / マクロとミクロの視点参考リンク「AIエージェント 人類と協働する機械」: https://amzn.asia/d/0btG9SKJ

今回はSQLiteの公式ドキュメント「Why is SQLite coded in C」を紹介。2000年に誕生したSQLiteがなぜC言語で書かれているのか、その理由を3つの観点から深掘りしました。パフォーマンス、互換性、安定性などC言語のメリットから、オブジェクト指向言語や新しい言語（Rust、Go）を採用しない理由まで、データベース開発における言語選択の考え方を議論しています。リスナーコメント紹介 / SQLiteの概要と特徴 / Small, Fast, Reliableの設計思想 / C言語がベストな理由 / オブジェクト指向への見解 / RustやGoで書き直さない理由 / 100%ブランチカバレッジテスト / パブリックドメインライセンス訂正エピソード内で「CREATE DATABASE コマンドを打つとデータベースファイルが作成される」と説明していますが、正しくは CREATE TABLE コマンドです。参考リンクWhy Is SQLite Coded In C: https://sqlite.org/whyc.html

OpenAI が公開したテックブログ「Scaling PostgreSQL to Power 800 Million ChatGPT Users」を、大規模サービス開発経験のある Lon と PostgreSQL エンジニアの Shinya の2人で読み解きます。後編となる今回は、Azure PostgreSQL のコネクション上限に対処するための PgBouncer の活用、キャッシュミス時の DB 負荷急増（Thundering Herd）を防ぐロック機構、50台のリードレプリカ運用におけるネットワーク負荷とカスケーディングレプリケーション、ORM レベルでのレートリミット、そしてサービス停止を防ぐための慎重なスキーマ管理とデータバックフィル戦略 など、ブログ後半の具体的な技術トピックについて議論します。PgBouncer とコネクションプーリング / キャッシュミス対策とロック機構 / カスケーディングレプリケーション / ネットワーク帯域とプライマリー負荷 / アプリケーション・ORM層でのレートリミット / スキーマ管理とフルテーブルリライト回避 / データのバックフィル戦略 / 基本的な設計の重要性参考リンクScaling PostgreSQL to power 800 million ChatGPT users: ⁠https://openai.com/index/scaling-postgresql/

OpenAI が公開したテックブログ「Scaling PostgreSQL to Power 800 Million ChatGPT Users」を、大規模サービス開発経験のある Lon と PostgreSQL エンジニアの Shinya の2人で読み解きます。シングルプライマリー + 50台の read replica という構成で8億ユーザーをさばく ChatGPT のアーキテクチャと、プライマリーの負荷軽減、クエリ最適化、フェイルオーバー戦略、ワークロード分離といった具体的な戦略について、ブログ前半の内容を前編として紹介します。OpenAI PostgreSQL スケーリング / シングルプライマリー + read replica 構成 / MVCC と write-heavy ワークロード / Azure Cosmos DB へのオフロード / クエリ最適化とスロークエリ対策 / idle_in_transaction_session_timeout / フェイルオーバーと高可用性 / ワークロード分離と noisy neighbor 問題参考リンクScaling PostgreSQL to power 800 million ChatGPT users: https://openai.com/index/scaling-postgresql/

2018年に話題になった Hacker News の Oracle Database に関するスレッドをもとに、大規模なコードベースを扱う際の難しさについて雑談しました。大規模ソフトウェア開発のあるある話を PostgreSQL の話も交えながら話しています。なお、エピソードの最後に述べているように、 Hacker News の投稿内容をもとにした雑談であり、その真偽も定かではありません。エピソード内で言及している数値や内部事情（コード行数、フラグ数、テスト時間など）は Hacker News コメントに基づくものであり、公式情報ではありません。その前提で、噂半分に一般的なソフトウェア開発のあるある話として楽しんでいただければ幸いです。日報の継続 / Oracle Database / PostgreSQL・MySQL・SQLite との比較 / 採用面接と実業務のギャップ参考リンクHacker News - Oracle Database スレッド: https://news.ycombinator.com/item?id=18442941

AI時代の個人開発・サイドプロジェクトの意味について、いくつかの海外ブログをきっかけに雑談しました。※一部、Medium の有料会員向け記事を含みます。詳細はぜひ原文をご覧ください。紹介したブログYour Side Project Won’t Save You Anymore: https://medium.com/@iamalvisng/your-side-project-wont-save-you-anymore-ca997028227eI Thought I Was Lazy or Had ADHD. Then, AI Explained: I Have a Builder Brain: https://medium.com/swlh/i-thought-i-was-lazy-or-had-adhd-then-ai-explained-i-have-a-builder-brain-8c2836413a36The blissful zen of a good side project: https://joshcollinsworth.com/blog/the-blissful-zen-of-a-good-side-project

カーネギーメロン大学のデータベース研究者 Andy Pavlo 先生によるブログ “Databases in 2025: A Year in Review” の内容を紹介し、2025年のデータベース業界を振り返りました。PostgreSQLの支配的地位と関連する買収・新プロジェクト / MCP (Model Context Protocol) 対応が広がるデータベースの現状 / MongoDB と FerretDB を巡る動き / Parquet以降のファイルフォーマット競争 / データベース業界の買収・資金調達ニュース / Oracle 創業者 Larry Ellison に関する話題参考リンクDatabases in 2025: A Year in Review: https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html 

今回のエピソードでは、生成AIが人間のモチベーションにどのような影響を与えるのかについて、個人の体験談と、関連する学術研究をもとに話しました。前半では、AIの普及によって生産性が向上する一方で、技術的ストレス（technostress）も増加しうる、という研究を紹介します。AIは仕事を楽にしたり、仕事への満足度を向上する側面がある一方で、仕事量や期待値の変化によって別の負荷が生まれる可能性が示されています。後半では人間と生成AIが協働した後に、再び人間だけでタスクを行うと内発的モチベーションが低下する傾向が観察された、という実験結果を取り上げました。AIありの状態が基準になり、その後の作業が相対的に難しく感じられたり、退屈さが増加する傾向にある、という点が示唆されています。AI時代に働くエンジニアとして、モチベーションやストレスをどう捉えるかを考えるきっかけになれば幸いです。なお、話者は社会学や心理学など、今回取り上げた論文やその関連分野の専門家ではないです。万が一間違いなどがあった場合はコメントや概要欄の Google Form からご指摘をいただけますと幸いです。参考リンク牛尾さんのブログ “AI が来て自分が壊れそうになった話”:  https://note.com/simplearchitect/n/nb5fd3f0447a5“Insights from the Job Demands–Resources Model: AI’s dual impact on employees’ work and life well-being”: https://www.sciencedirect.com/science/article/pii/S0268401225000192 “Human–Generative AI Collaboration Enhances Task Performance But Undermines Human’s Intrinsic Motivation”: https://www.nature.com/articles/s41598-025-98385-2

新年一発目として、 2025年の振り返りと、2026年の目標について Shinya と Lon がそれぞれの視点で語り合っています。

DORA (DevOps Research and Assessment) が 2025年9月に出した、 “State of AI-assisted Software Development Report” というレポートと、 「生成AIでスクラムによる開発はどう変わるか」という Ryutaro YOSHIBA さんによるブログを参照しながら、AI時代のソフトウェア開発を「組織・プロセス (スクラム開発)」の観点から整理し、2025年の総括として議論しました。特に以下の観点を Lon、 Shinya それぞれの体験や感想も交えながら、資料を元に深掘りしています。テクノロジー関連職の人々の生成AIの活用状況生成AIを“うまく使える”組織には、どのような性質 (capability) が求められるのか生成AIは、スクラムという開発手法の前提や重心をどのように変えつつあるのか。これからは何が重要になるのか参考リンク2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状 (summary blog): https://cloud.google.com/blog/ja/products/ai-machine-learning/announcing-the-2025-dora-report?hl=ja2025 DORA State of AI-assisted Software Development Report (full report): https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report 生成AIでスクラムによる開発はどう変わるか: https://www.ryuzee.com/contents/blog/14605

PostgreSQL Advent Calendar 2025 に投稿された Shinya の記事 「2025年に自分が開発した PostgreSQL の新機能」 を題材に、 Shinya の PostgreSQL へのコントリビューション内容と、その背景を掘り下げました。取り上げた新機能は以下です。詳細はぜひ元のブログをご参照ください。バックアップ進捗表示の改善COPY FROM の利便性向上Autovacuum ログ制御の改善WAL 圧縮率の表示の改善参考リンクPostgreSQL Advent Calendar 2025Shinya のブログ 「2025年に自分が開発したPostgreSQLの新機能」: https://zenn.dev/shinyakato/articles/f15e1c06bc343aお便り・感想は概要欄の Google Form またはハッシュタグ #ttlog でお待ちしています。

Shinya が PostgreSQL Conference Japan 2025 参加レポートとして、 keynote や印象的だったセッション、その他の学びなどについて共有しています。また冒頭では、第11回で紹介した Whisper / faster-whisper の性能比較ベンチマークの誤りについて振り返り、 faster-whisper の transcribe メソッドが generator（遅延評価）を返す実装であることに起因する測定ミスだったことに言及しています。まだお聴きでない方は第11回もあわせてぜひお聞き下さい。参考リンク (本エピソードで紹介した講演内容の資料などです)PostgreSQL Conference Japan 2025Pg_lakeWhat I learned interviewing the PostgreSQL Communitypgstats in PostgreSQL 18PostgreSQL で列データ”ファイル”を利用する ～Arrow/Parquet を統合したデータベースの作成～

Lon が近年注目されている AI4Science をテーマに、創薬・材料科学・気候といった分野の市場規模や成長性について調査した内容を共有しています。※ ChatGPT の DeepResearch を使って調査した結果のため、細かい数字はズレなどがあるかもしれません。参考リンクSam Altman: The Future of OpenAI, ChatGPT's Origins, and Building AI Hardware: https://www.youtube.com/watch?v=V979Wd1gmTUBlog ”Venture Capital is Subsidizing U.S. Material Science Research”: https://ml4sci.substack.com/p/venture-capital-is-subsidizing-usUpdated Practice for Review Articles and Position Papers in arXiv CS Category: https://blog.arxiv.org/2025/10/31/attention-authors-updated-practice-for-review-articles-and-position-papers-in-arxiv-cs-category/

Shinya が最近読んでいる書籍 『詳解 システム・パフォーマンス (第2版)』 の第2章「メソドロジ」で紹介されている問題解決のアンチメソッドからいくつかを取り上げ、それぞれの経験や過去の反省を交えながら語っています。PyTorch でのパフォーマンス計測の注意点や、 PostgreSQL のパフォーマンスチューニングで実際に遭遇した問題などにも言及しています。扱った主なアンチメソッドは以下です。街灯のアンチメソッド: “明るい場所＝自分が知っているツール” ばかりを見ることで、問題の本質を見落とす罠ランダム変更アンチメソッド: 理解なくパラメータを上げ下げすることで、本番で再現しない「謎チューニング」を生むリスク誰か他人のせいにするアンチメソッド: 十分なデータを持たずに他チームに責任を押し付ける構造的アンチパターン参考リンク詳解 システム・パフォーマンス 第2版: https://www.oreilly.co.jp/books/9784814400072/

Lon が「Let’s reproduce GPT-2 (124M)」という YouTube 動画を通じて、GPT-2 のアーキテクチャや事前学習（pre-training）の実際を (今さら) 学んだ経験について話しています。この動画では、AI界隈で著名な Andrej Karpathy 氏が、論文や公開実装を参照しながら 124Mパラメータ版 GPT-2 を再現する手順を丁寧に解説しており、これから LLM の理解を深めたい方にとって非常に有益な内容になっています。今回のエピソードでは、動画を視聴して得られた気づきや、実際に手を動かして学んだ点、そして GPT-2 の構造が現在の LLM にどのように繋がっているのかについて議論しています。参考リンクLet’s reproduce GPT-2 (124M): https://youtu.be/l8pRSuU81PU?si=uwQLaSuFrFdVUuWYTransformer 解説動画: https://youtu.be/50XvMaWhiTY?si=bKAs5wH5dxGnOqI0From GPT-2 to gpt-oss: Analyzing the Architectural Advances: https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the

【訂正 2025/11/24】当初アップロードした音声内で紹介した、文字起こしに要した時間の計測方法に誤りがあることが分かりました。音声では、30秒のオーディオデータを文字起こしした際の時間 (whisper large v3 model 使用) としてfaster-whisper: 約11.8秒Pytorch版 whisper (OpenAI公式): 約94秒と紹介していましたが、 faster-whisper の計測コードに誤りがありました。正しくはfaster-whisper: 約47秒であり、 PyTorch版の約2倍程度速い、というのが計測結果です。誤解を生む発言となったことをお詫びいたします。(エピソード内でも訂正の文言を入れています。)以下、通常の show notes です。Lonが文字起こし (speech-to-text) の技術を調査し、実際に検証した学びについて共有しています。Open AI が開発したモデルである whisper と、それを CTranslate2 ラインタイムで高速化した faster-whisper について、その概要と実際にこのPodcastのエピソードで文字起こしをした結果について共有しています。文字起こしの技術について深く議論をしているのは 15:20 ごろからです。そこまでは文字起こしの技術を調べようと思った背景や、今後このポッドキャストで挑戦したい内容について雑談をしています。参考リンクOpen AI whisper Github repository: https://github.com/openai/whisperfaster-whisper Github repository: https://github.com/SYSTRAN/faster-whisperCTranslate2 Github repository: https://github.com/OpenNMT/CTranslate2

Shinya が PostgreSQL の開発コミュニテイや開発フローについて、過去の登壇資料をもとに紹介しています。参考リンクOSSデータベースの開発コミュニティに参加しよう！ (DEIM2024 発表資料)PostgreSQL Git RepositoryCommitfests

雑談回です。エンジニアとして働く中で「何が楽しいか」「モチベーションの源泉はどこにあるか」、そして「どう工夫して生産性を高めているか」などを、超絶ゆるく語っています。ストレングスファインダーの話も交えながら、Shinyaの志向性の変化などにも言及しています。Lon がエピソードで言及した書籍「ビジネスの未来 エコノミーにヒューマニティを取り戻す」: https://amzn.asia/d/f52TD7y

Shinya が気になった論文 "Supporting Our AI Overlords:Redesigning Data Systems to be Agent-First" について紹介しています。この論文は Agent-first なデータシステムをどのように構築すべきか、という問題について論じたカリフォルニア大学バークレー校によるビジョンペーパーです。Agent-first なデータシステムが備えるべき性質や、それを実現するために必要な要素技術について議論されており、エピソードではこの論文をもとに、二人が気になった点について語っています。参考リンク論文: https://arxiv.org/pdf/2509.00997VLDB keynote 資料: https://vldb.org/2025/files/keynote/vldb25-keynote3.pdf

2025年10月7日にリリースされた Python 3.14 では free-threaded python が公式にサポートされました。この機能に密接に関係する CPython の Global Interpreter Lock (GIL) について、その基本的な説明から Python で導入された歴史的背景、そして Python 3.13, 3.14 にかけて進められた GIL なし Python の段階的サポート の流れを、 Lon が調べた内容を共有しています。参考リンクPython 3.14 リリースノート: https://www.python.org/downloads/release/python-3140/PEP 703: https://peps.python.org/pep-0703/PEP 779: https://peps.python.org/pep-0779/エピソードで触れた具体的なコード例: https://realpython.com/python-gil/ Shugo Manabe さんの PyCon 2025 での登壇資料、GILの歴史から実装の詳細まで触れられている: https://speakerdeck.com/curekoshimizu/pythonsuretudotohajie-ju-he-nanoka-cpythonshi-zhuang-karajian-runogilshi-dai-nobian-huaRubyの方針に関するまつもとゆきひろさんのインタビュー記事: https://active.nikkeibp.co.jp/atcl/act/19/00484/080100015/

Lonが気になった Google DeepMind の論文 "On the Theoretical Limitations of Embedding-Based Retrieval" について、その内容と学びを共有しています。この論文では、 embedding を用いた情報検索の理論的な限界を指摘し、その限界をわかりやすく検証できる LIMIT データセットも作成・公開されています。LLM を活用した RAG システムや検索応用を設計する際にヒントとなる情報があるかもしれないので、これらの技術領域に興味がある方はぜひ聞いてみてください。内容に誤りや補足があれば、コメントなどでぜひ教えていただけると嬉しいです。参考リンクhttps://www.alphaxiv.org/Qiita: 英語論文をさくっと日本語ブログ化してくれるalphaXivが便利紹介した論文: https://arxiv.org/pdf/2508.21038LIMITデータセットなどのソース: https://github.com/google-deepmind/limitembeddingの評価でよく用いられるベンチマーク: https://huggingface.co/mteb/spaces

Shinyaが UUID（Universally Unique Identifier）の仕組みや歴史、そして各バージョン間の違いについて解説しています。UUID はエンジニアの皆さんにとってお馴染みの仕組みですが、「そもそもどんな経緯で作られ、どんな変化を遂げてきたのか？」までは意外と知られていないのではないでしょうか。（何を隠そう、Lonも「ユニークなIDを作るためのもの」程度の理解でした）今回のエピソードでは、1980年代に始まるUUIDの歴史から、標準化の流れ、そしてv4での乱数生成による特性とそれに起因するPostgreSQLにおける性能問題、さらにそれを改善したv7の登場までを、Shinyaがわかりやすく紹介しています。豆知識としても面白く、日常的にUUIDを使っている方なら「知らなかった！」となるポイントがきっとあるはず。UUIDを一度でも使ったことがある方は、ぜひ聞いてみてください！関連リンクA brief history of the UUIDRFC 4122RFC 9562PostgreSQL 18がUUIDv7をサポートstateless-me/uuidv47

Lon がオーディオブックへの愛とおすすめの本をいくつか紹介し、それにまつわる雑談をしています。エピソード内で言及した書籍は以下です。(日本語版の書籍へのリンクです。)Lonは「ハッカーと画家」、「The Nvidia Way」は英語版をAudibleで聞いたため、日本語版はAudibleにはない可能性があります。ＢＵＩＬＤ 真に価値あるものをつくる型破りなガイドブックPLG プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ世界一流エンジニアの思考法ハッカーと画家 コンピュータ時代の創造者たちThe Nvidia Way エヌビディアの流儀フォン・ノイマンの哲学 人間のフリをした悪魔

OSSの coding agent “opencode” について簡単に調査した内容をLonが共有しています。Claude Code と比較したブログの紹介やベンチマークの結果、コンテキスト管理の工夫、Edit/Write ツールが LSP (Language Server Protocol) の結果を利用していること、などを話しています。※ 収録時点でのコードをざっと読んで理解した内容のため、誤りやその後コードベースが修正されている可能性もあります。修正点などはコメントで頂けると嬉しいです。opencodeTypescript の coding benchmark: エピソード中に言及した、 Coding Agentの性能を測るためのTypeScriptベンチマークDaniel Miessler さんの Claude Code との比較ブログエピソード内では「ブログのバグ修正」を実施したと表現しましたが、より正確には「ブログ記事の新規作成」のタスクでした

#1でほぼ我々という人間について触れていなかったため、自己紹介をしてみよう、という回です。Shinyaは自分の仕事内容を紹介し、Lonは趣味の合気道について熱弁しています。Lonがグローバルチームで働く時に気をつけていることや、ShinyaがPostgreSQLのカンファレンスで行った場所なども話しています。

PostgreSQL ContributorのShinyaさんに最新のPostgreSQL 18のアップデート内容について教えてもらいました。参考リンク: PostgreSQL 18 リリースノートpganalyze社の非同期IOに関するブログ