ブログ

Go の SQL ビルダー領域に gsql を出すにあたり、既存 OSS とどこで差を付けたか。型安全 × codegen 不要 × zero-value 問題への姿勢を実装ベースで整理する。

gpdf, gsql, renma を兼業で並走する nadai の運営構造。共通化する層と分離する層、集客動線の作者ハブ集約、1 プロダクト = 1 GitHub 組織の判断軸を整理する。

受託テックリード本業の業務外で、Pure Go OSS の gpdf と gsql を MIT で公開している。別途、gpdf 派生の SaaS 層 (gpdf-api ほか) と、別ジャンルの筋トレ Flutter アプリ renma も並走で開発中 (どれも未リリース)。なぜ最初を MIT にしたか、何を学んだか、次に何を変える予定か。

なぜ CGO 依存を避け、なぜ既存 OSS のフォークでなくゼロから書いたか。設計判断の連鎖と、それが結果として何を可能にしたか。

gpdf の API を chainable ではなく closure callback ベースの builder にした理由。Go の error 集約と PDF tree 構造に効く設計判断を実装ベースで残す。