<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Open Source on Jaehyeon Kim</title><link>https://jaehyeon.me/categories/open-source/</link><description>Recent content in Open Source on Jaehyeon Kim</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Copyright © 2023-2026 Jaehyeon Kim. All Rights Reserved.</copyright><lastBuildDate>Sat, 18 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jaehyeon.me/categories/open-source/index.xml" rel="self" type="application/rss+xml"/><item><title>Building an Agentic Analytics System over an Iceberg Lakehouse</title><link>https://jaehyeon.me/blog/2026-07-18-agentic-analytics-system/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-07-18-agentic-analytics-system/</guid><description><![CDATA[<p>Generative AI has made conversational analytics feel within reach, yet direct text-to-SQL systems remain hard to operate reliably. A database schema tells you the tables, columns, and types, but it says nothing about which datasets are canonical, which join paths are approved, how a governed metric is calculated, or what the business actually means by &ldquo;revenue&rdquo; or &ldquo;active customer&rdquo;. Ask a language model to infer all of that from raw tables and, sooner or later, it will confidently invent an answer.</p>
<p>I built a proof of concept to explore a more disciplined approach: put a semantic layer between the model and the data, and let the agent reason over governed business concepts instead of guessing at raw schemas. It runs entirely locally on an open-source stack, and it happens to tie together two of my other projects along the way.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-07-18-agentic-analytics-system/featured.png" length="158787" type="image/png"/></item><item><title>Dynamic DES v0.11.1: A Declarative API with Postgres and Redis Connectors</title><link>https://jaehyeon.me/blog/2026-07-17-dynamic-des-declarative-connectors/</link><pubDate>Fri, 17 Jul 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-07-17-dynamic-des-declarative-connectors/</guid><description><![CDATA[<p>A while back I wrote about <a href="/blog/2026-05-25-dynamic-des-parquet-support/">Dynamic DES v0.8.1</a> and its native Data Lake integration, using one SimPy codebase for both batch training and live inference. Several releases later, the project has grown in two directions that matter for anyone building event-driven digital twins: a cleaner authoring experience, and more places to send and receive data.</p>
<p>Here is what changed on the way to <strong>v0.11.1</strong>.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-07-17-dynamic-des-declarative-connectors/featured.png" length="212473" type="image/png"/></item><item><title>Introducing odctl: One CLI for a Local Open Data Stack</title><link>https://jaehyeon.me/blog/2026-07-16-odctl-open-data-stack/</link><pubDate>Thu, 16 Jul 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-07-16-odctl-open-data-stack/</guid><description><![CDATA[<p>Anyone who has tried to stand up a realistic data platform on their laptop knows the pain. You want Kafka talking to Flink, Spark writing to Iceberg, Trino querying the result, and maybe a catalog and a lineage tool watching over all of it. What you actually get is an afternoon lost to dependency conflicts, port clashes, and a Docker Compose file that grows a new bug every time you touch it.</p>
<p>I built <code>odctl</code> to make that afternoon disappear. It is a curated collection of open-source data technologies wrapped in a small CLI, and it is now available on PyPI.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-07-16-odctl-open-data-stack/featured.png" length="271859" type="image/png"/></item><item><title>One Simulation, Two Pipelines: Batch Training and Live Inference with Dynamic DES v0.8.1</title><link>https://jaehyeon.me/blog/2026-05-25-dynamic-des-parquet-support/</link><pubDate>Mon, 25 May 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-05-25-dynamic-des-parquet-support/</guid><description>Training a machine learning model on simulated data is straightforward until you try to deploy it. The disconnect usually happens at the pipeline level: training requires massive, historical batch data (like Parquet files in an S3 bucket), but production inference requires real-time, event-driven streams (like Kafka or Redis).
Maintaining two separate simulation codebases, one for generating training data and another for streaming live events, introduces friction, schema mismatches, and duplicated engineering effort.</description><enclosure url="https://jaehyeon.me/blog/2026-05-25-dynamic-des-parquet-support/featured.png" length="168665" type="image/png"/></item><item><title>Building an Event-Driven Hybrid Digital Twin with dynamic-des</title><link>https://jaehyeon.me/blog/2026-04-28-digital-twin-dynamic-des/</link><pubDate>Wed, 29 Apr 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-04-28-digital-twin-dynamic-des/</guid><description>Asynchronous Gap In Part 1, we established that a true Hybrid Digital Twin does more than just mirror reality. It actively forecasts the future by running a simulation against live operational states.
If you have ever tried to build one of these systems from scratch, you immediately hit a fundamental architectural clash.
Standard simulation clocks (like those in traditional SimPy implementations) are logically synchronous and not designed to handle high-frequency asynchronous I/O without explicit decoupling.</description><enclosure url="https://jaehyeon.me/blog/2026-04-28-digital-twin-dynamic-des/featured.png" length="177036" type="image/png"/></item><item><title>Why Digital Twins Are Rewiring Industry 4.0</title><link>https://jaehyeon.me/blog/2026-04-23-digital-twin-industry-4-0/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-04-23-digital-twin-industry-4-0/</guid><description>Beyond CAD Models There is a project by Dassault Systèmes called the Living Heart that illustrates the trajectory of this technology. Instead of relying on standard 2D scans, surgeons can pull up a high-fidelity 3D model of a patient&amp;rsquo;s heart that simulates blood flow, mechanics, and electricity based on imaging-derived reconstructions and population-based physiological calibration.
While the Living Heart is closer to a personalized, highly-parameterized simulation than a continuously streaming IoT system, it highlights the core philosophy of a modern digital twin: moving past static CAD files to create models that are fundamentally aligned with a specific, real-world physical instance.</description><enclosure url="https://jaehyeon.me/blog/2026-04-23-digital-twin-industry-4-0/featured.png" length="73776" type="image/png"/></item><item><title>Building a Real-Time Industrial Digital Twin with Apache Flink and Online Machine Learning</title><link>https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/</link><pubDate>Tue, 21 Apr 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/</guid><description>Overview Imagine using a rolling pin to flatten out a thick piece of dough. A Hot Strip Mill does the exact same thing, but with glowing red-hot steel slabs (often heated over 1000°C) and massive mechanical rollers. The steel is passed through a series of these rollers, crushing it down from a thick block into a long, thin sheet.
Calculating the exact Rolling Force required to crush the steel is critical.</description><enclosure url="https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/featured.png" length="130846" type="image/png"/></item></channel></rss>