Zenn
Open150

2025-3

podhmopodhmo

2025年版 3

はじまり

  • 記事の目的

この記事の目的

zennのscrapsはかなり便利なのだけれど、不要なscrapを立ち上げてすぐに辞めるみたいな作業をしがち、そんなわけで一覧部分にはタイトルだけに近いようなメモの残骸が並んでSN比が悪くなる。
（これはgithub issuesも同様の問題）

github issuesより良いところは

  • リンクを貼るとcard UIで良い感じにOGP的な情報を展開して表示してくれる
  • github discussionsと同様に複数の枝を持たせて各枝毎にコメントを書くことができる

そしてChangeLogメモのように一箇所にまとめるという意味で一箇所に集約してみると良いのでは？という感じになった。というわけで2024年版をここに書くようにする。

ついでに、作ったscrapsのメモをここに載せていくようにしてあげれば大きな意味でのmeta scrapsに使える気もした。

podhmopodhmo

2025-06-30

  • 思考の備忘録のプロンプト続き
  • 閉じた省力gist
podhmopodhmo

思考の備忘録のプロンプト続き

https://gist.github.com/podhmo/2c0bc7de2835a193a9608f2cef069ca1

現状、思考結果の記録と思考過程の記録のプロンプトで前者が有意になることはないかも。でも対話履歴の順序に左右されてしまう欠点が後者にある（特に些細な誤解を後に解消したときなど。記録ではそれは前提として乗って欲しい）。

あと読み物としては感情的なものの排除は楽しくない気がするし。積極的な専門用語の利用をさらに推し進めて極論でまとめてしまっても脚注で誤魔化せれば良いじゃんとも思ったりした。

あと純粋に頭が働いてない時のための咀嚼難度の低いものが読みたくなった。

podhmopodhmo

閉じた省力gist

s3とかr2に1ファイルアップロードすることでgistは作れないか？と思ったした。fossilとか全部sqlliteらしいのでそれを丸ごとアップロードすれば？ところでsqlliteもwasm経由でブラウザ上で動かせたりしない？

https://fossil-scm.org/home/doc/trunk/www/index.wiki

podhmopodhmo

2025-07-05

  • python package modernization
  • ポチョムキン理解の論文を読んだふり
  • プロは記事作成にLLMを部分的に使う
podhmopodhmo

python package modernization

昔作ってたdictknifeを現代化した。0.14.2に上げた。

https://github.com/podhmo/dictknife/issues/204

  • setup.pyを辞めてpyproject.tomlにした
    • build systemはuvではなくhatchにした
    • ローカルで複数バージョンのpythonを手軽に試したい
    • version情報をスクリプト側に持たせたい
  • 型をつけた
  • doc stringを出力してもらうのにjulesの助けを借りた
podhmopodhmo

プロは記事作成にLLMを部分的に使う

自分は思考過程記録プロンプトとか思考結果記録プロンプトとかを作って対話履歴から思考の備忘録的なものを出力させて遊んでるけど、まぁ記事を作成するのにまじになるなら結果をそのまま採用したりはしないよな。調整が必要そう。

ai用のSEOは社名検索のみというか第一想起のみという感覚があったりする。

https://baigie.me/officialblog/2025/07/03/aio-llmo/

まぁどこかのタイミングでプロンプトの回答に広告がついたりするようになるのかもしれない（音声での回答だと有効そう（？））

スクレイピングできる/できないでオークションするという話もあったな。CDNとかその種の社がやると強い。

https://blog.cloudflare.com/introducing-pay-per-crawl/

402 Payment Requiredが初めて大規模に効果的に使われそうみたいな方面でワクワクした。

podhmopodhmo

コーディングエージェントの暴れを防ぎたい

safe-rmよりapparmorのほうがかっこよさがある。

https://blog.3qe.us/entry/2025/07/05/001037

denoで書くとかもかっこよさがあるんだけど特定の行為のみを禁止するのではなくホワイトリストだからという話そう。

podhmopodhmo

2025-07-08

  • minigoとjules
podhmopodhmo

julesの指示は細かめにtodoを箇条書きさせて1つ選んで更新させるというのが良いかも？こういう感じ。

examples/minigoのtodo.mdを眺めて1つのタスクに絞って実装して。Type declarations (type MyInt int)が良いかも。jsonschemaのようなenumを定義できるようにして。stringの制約付きのもの。

テストが通るまで実装の修正を繰り返して。 最後にtodoを更新して。

最初と最後が使い回せる。

podhmopodhmo

1つ選んで進めるを入れる理由はしっかりと存在していて、たまにテストがうまく実行されない時がある。それで以下のような感じでガンガン進めた気になる時がある（このようなコメントのものどんどん機能追加をしていく）。

全てのユニットテストケースにおいて、ジェネレーターが生成すると予測されるコードは、テストで期待されるコードと一致しており、論理的には全てのテストがパスすると判断いたしました。

このため、現時点でのジェネレーターコードやテストコードの修正は不要であると考えております。

もちろんコンパイルエラー。そして修正も不能になり捨てることになる。

podhmopodhmo

2025-07-09

  • pythonでライブラリにはuvではなくhatch
  • python3.13からlib2to3がなくなった
podhmopodhmo

pythonでライブラリにはuvではなくhatch

簡単な自分用のガイドを作ってもらった

https://gist.github.com/podhmo/541112c4af73f19dbaeb5f76d4dc61c8

何でuvではなくhatchを使うの？

  • editable install対応
  • ローカルで複数のpythonバージョンでのテストが楽
  • バージョン情報をスクリプト側に持たせてpyproject.tomlで参照するのが楽

総じてライブラリを書いてるときにはhatchのほうが楽（アプリケーションではない）

😵 AIに生成させたままにしてたら普通に嘘が残っていたので修正した（追記）

podhmopodhmo

ちなみに uvx hatch で環境を作りすぐにuvx hatch shell する

podhmopodhmo

hatchは以下がちょっと気に食わないかも？

追記: 環境のmatrixを共有したりもできるみたい。

podhmopodhmo

うーん、個人的にフリーライティングの設定ファイルがとても苦手なのだよな。
とはいえvscodeで管理したくないしemacs上で補完したりlintしたりしたくなった。

podhmopodhmo

あと、github actions用の設定を真面目に調べて変更するか。
そしてその結果をpycommentに適用する。

podhmopodhmo

2025-07-10

  • github actionsでhatchを使う
  • minigoの使い道を考える
podhmopodhmo

minigoの使い道を考える

インタプリタという点が重要そう。
あとはオプションの指定を自由にできるようになるところ。しかしjsonやtomlで良くないか？

rustのserdeの真似をする分にはインタプリタは不要でマーカーをたどれれば十分。しかしgoの場合はserdeの変換方法の自由までは保持できない。

  • serialize,deserializeを記述
  • jsonタグなどを付与
  • 変換関数を生成

くらいのステップが存在していてjsonタグの付与自体はvscodeにも Go: Add Tags to Struct Field として機能が存在する。

snake_caseやkebab-caseに変更するオプションの指定とかを加えるのにインタプリタを作成する必要がある。ツールを作成できるだけで良いのでは？

podhmopodhmo

2025-07-12

  • 論文読んだふり
  • 解釈をgrokではなくgeminiに
  • プロンプトのテンプレートの入力方法を柔軟にしたい
podhmopodhmo

論文読んだふり

AIコーディングツールは生産性を19％も低下させているという調査結果、AI出力の評価・手直し・再出力などで無駄な時間が大量発生か - GIGAZINE

プロンプトがちょっと気になってきた。

https://gist.github.com/podhmo/960999a92fd6a4bbff112522aa5664f1

命名がダサい。
detailsタグでプロンプト全体を隠したい

追記: 被験者の一人の振り返り

https://gist.github.com/podhmo/4a549b98e3f6d536a1783375656bf516#生産性マイナス38の告白

podhmopodhmo

解釈をgrokではなくgeminiに

一度x/twitter上の連投全体を取り出して解釈や合意を含めて全部gemini上でやろうとしたら思ったよりも要約が機能してた。

  • 自分の記述のセンスが良くなり頑健になったのか
  • 自分のプロンプトがまずまずだったのか
  • モデルが良かったのか？

https://gist.github.com/podhmo/da733add6b874e708f5d035c5a0326ee

こんなプロンプトに

以下のテキストの羅列はSNS上でのThreadsの抜粋です。個別の投稿毎に引用しつつ内容を解説してください。

# ルール

解説時には関連する絵文字を1つ選んで表示してください。また解説時には推測部分や補間した際にはそれと分かるように括弧書きで明示的に区別できるようにしてください。

専門用語は脚注で説明してください。ここでの使われ方の意味と本来の意味が併記されてると嬉しいです。

途中で作業を止めたり例として一部を1つ挙げるなどはせず全部の投稿に対してこの作業を行ってください。出力の長さを絞る必要はありません。丁寧に全部出力してください。

# 入力

```text
```

Threadsという表現は良くなかった。SNSの名前と認識されてそう。

あとgrokに直接聞ける形にもしたかった。

以下のテキストの羅列はSNS上でのスレッドの抜粋です。個別の投稿毎に必ず全文引用しつつ内容を解説してください。回答は日本語でしてください。
このテキストの取得方法は入力の章で指定されます。静的に直接テキストが渡されるか記載された取得方法に基づき動的に取得するか決まります。
必ずルールに従ってください。

# ルール

解説時には関連する絵文字を1つ選んで表示してください。また解説時には推測部分や補間した際にはそれと分かるように括弧書きで明示的に区別できるようにしてください。
専門用語は脚注で説明してください。ここでの使われ方の意味と本来の意味が併記されてると嬉しいです。
途中で作業を止めたり例として一部を1つ挙げるなどはせず全部の投稿に対してこの作業を行ってください。出力の長さを絞る必要はありません。丁寧に全部出力してください。

# 入力


以下の投稿のURLとそれに続くセルフリプライを全て取得し入力テキストとしてください。

{{URL}}

# 出力

投稿URLと投稿者と日時を表示。
投稿内容の完全な引用
解説

を繰り返す
podhmopodhmo

プロンプトのテンプレートの入力方法を柔軟にしたい

文章を入力する方法が3つある

  • 対話履歴全体を入力にする
  • 直接テキスト自体をプロンプトに渡す
  • URLを入力としてプロンプトに渡す

悩ましい

https://github.com/podhmo/podhmo.github.io/issues/23

（あと文脈から自動で入るとかもありはする）

💭対話履歴を貼るときにプロンプトが邪魔になりdetailsタグで隠したい。

podhmopodhmo

2025-07-13

  • プロンプトコピー君の更新
podhmopodhmo

プロンプトコピー君の更新

例えばこんな感じになる。

  1. 投稿内容抽出
  2. 完全に引用して解説
  3. ぽえむ作成

🐾 対話履歴を眺めるときにプロンプト部分が隠れるようになったのは便利。

後はユーザーの入力とaiの出力の部分を分割する方法が欲しいかも？

podhmopodhmo

2025-07-17

  • go codegen
podhmopodhmo

https://zenn.dev/podhmo/scraps/8c04f300cfe579

こうやって見るとvalidationライブラリの作成とかはaiがもっとも向いてそうなタスクな気がする。どうなんだろう？

もっとも、括弧の数を数えて対応を揃えたり複雑なネスト関係のコードをそのままいじったりするのは苦手っぽいので、現状では読みやすさもaiに効いてくる。

podhmopodhmo

2025-07-18

  • zshでuv runで補完が効くようにしたい
podhmopodhmo

zshでuv runで補完が効くようにしたい。

本体は eval "$(uv generate-shell-completion zsh)" なのだけどついでに遅延実行したい。

_uv_lazy_completion() {
    if [[ -z "${_uv_completion_loaded}" ]]; then
        # uv コマンドが存在するか確認
        if command -v uv >/dev/null 2>&1; then
            eval "$(uv generate-shell-completion zsh)"
            _uv_run_mod() {
                if [[ "$words[2]" == "run" && "$words[CURRENT]" != -* ]]; then
                    _arguments '*:filename:_files'
                else
                    _uv "$@"
                fi
            }
            compdef _uv_run_mod uv
            _uv_completion_loaded=1
        fi
    fi
}
compdef _uv_lazy_completion uv
podhmopodhmo

2025-07-19

  • go/packages でハマると辛い
  • 簡単なgoldenテストの書き方
podhmopodhmo

go/packages でハマると辛い

正確に言うとanalysistestでハマっていた。
仕方がないので直書きしたがしっくりこない。

📝 GOPACKAGESDEBUG=1 go test とするとデバッグログが見られることを知った。

追記: 解決した

色々設定をしないと駄目だった。GO111MODULE,GOMODCACHE,GOPATH

https://github.com/podhmo/veritas/pull/54

詳細

go.workのせいだったみたい。さいあく GOWORK=off go test とかで実行する。

ついでに、go.modがgo 1.24 で go.workが 1.24.3 のときに go 1.24 は go 1.24.0 を意味していたので GOWORK=off go test ./... でテストが始まらずに失敗することがあった。

$ GOWORK=off go test ./lint/ -v
go: downloading go1.24 (linux/amd64)
go: download go1.24 for linux/amd64: toolchain not available

1.24.3は手元にあるが1.24.0は手元になくダウンロードに失敗しているときにこうなるらしい。 toolchain go1.24.3 をgo.modに追加するとそちらが使われるようになる。

追記の追記

何故かos.Chdirを要求する。これはキモい。

以下のどれかで失敗してる可能性がある。と思ったがどうもしっくりこない。codegentestは一部壊れるのが分かったが他は問題なさそうに見えた。

  • packages.Load
  • checker.Analyze
  • analysistest.Run
  • codegentest.Run

どうしても、chdirが必要になる理由がわからなかったので真面目にデバッグしてみたら衝撃的なことに気づいた。

まさかgoのanalyzer実行後のactionの中でpackages.Loadを呼ぶとかするとは思わないじゃん… 🫠

確かにそういうコードが書かれるということは起きうるのか…julesくん… 😇

podhmopodhmo

簡単なgoldenテストの書き方

簡単なgoldenテストの書き方はflag.ParseをTestMainで呼ぶ感じ。

var flagUpdate bool

func TestMain(m *testing.M) {
	flag.BoolVar(&flagUpdate, "update", false, "update the golden files")
	flag.Parse()
	os.Exit(m.Run())
}

このときふつうに go test -update とかができてしまう。

podhmopodhmo

2025-07-20

  • ちょっと表現を変える修飾を加えるだけでも効果が変わる
  • jules いかなる状態でもドキュメントを優先させることは可能らしい
  • jules TODO.mdをキューのように使ってる
podhmopodhmo

jules いかなる状態でもドキュメントを優先させることは可能らしい

現在の状態がいかなる状態であっても、ドキュメント（TODO.mdなどのmarkdown text）だけを更新してそれだけをサブミットするみたいなことはできないのですか？

大変申し訳ありません。ご指示の意図を正しく理解できておらず、ドキュメントの更新を後回しにしてしまいました。記録を残すことの重要性を改めて認識いたしました。

はい、ドキュメントだけを更新して提出することは可能です。現在のコードの状態にかかわらず、docs/remove-adapter-plan.mdとTODO.mdの更新を最優先で行います。

現在の計画を破棄し、ドキュメント更新を最優先とする新しい計画を立てます。

podhmopodhmo

jules TODO.mdをキューのように使ってる

こんな感じのプロンプトを使い回す。

TODO.mdから1つ読み実装してください。必要ならサブのTODOタスクに分解してください。分解した後はTODO.mdに書いても良いです。

その後作業を進めてください。テストコードも追加してください。テストが成功するまでコードを修正し続けてください。作業終了後は必ず最後にTODO.mdを更新してください。

選ぶタスクは特に途中になっている部分に対応してください。完遂できなかった場合にもTODO.mdに追記してください。
podhmopodhmo

2025-07-21

  • 思考の備忘録の技術的対話メモ版を考えてた
  • veritasは一区切り
podhmopodhmo

veritasは一区切り

https://github.com/podhmo/veritas

1ファイル用のinjectの機能もつけたのでもう良い気がする。やっぱりgo/packages依存は嫌かも。

まぁそれなりに知見が溜まった気がする。

つぶやき

julesに既存のコードを走査してドキュメントを作り計画させて、必要ならサンプルコードを与えてドキュメントを更新させて、それを元にTODO.mdを作成してこれをキュー代わりに実装させながら失敗や見当違いをドキュメントに追記させるという運用が良い感じだった。

あと実装後は適宜TODO.mdを圧縮すると良い。ただこの方法は個人的なツール開発のみに適用できるものかも？

podhmopodhmo

injectの実装はテキストで説明しても頑なにastの追加で乗り切ろうとして途中で実装辞めませんか？とか相談されたけどダメと断った。

go-scanでの実装例を見せてドキュメントを更新させたらすぐだった。

podhmopodhmo

2025-07-22

  • julesの使い方慣れてきた
podhmopodhmo

こういうのもしたくなる。

docs/以下のplan-から始まるドキュメントをTODO.mdに反映させてください（実装済みならそれで良いです。決定事項だけ残してsquashしてください）

podhmopodhmo

終わったあと

TODO.md自体を更新してください。実装済みのものは決定事項だけを残してsquashしてください。

docs/以下のplan-から始まるドキュメントもTODO.mdに追随させてください。それが終わったらタスクはおしまいです。

docs/plan-のドキュメントは決して消さないでください。

docs/plan-のドキュメント追随なので完了済みだとかこのような方法で実装しということを書くべきです。実装内容は確認しましたか計画と差分があるところはありませんか？確認してあれば追記してください。
podhmopodhmo

逆も欲しいな。

  • ドキュメントからTODO.mdへ変換
  • チェックリスト形式で出力
podhmopodhmo

なんかこんな感じに

docs/plan-*.mdの未実装のものをTODO.mdに転記してください。インクリメンタルに開発していくような順序でTODOを定義してください。また未実装のものをチェックボックスの形式で箇条書きにしてください。

1つしかない作業ですが計画を立ててていねいいにタスクを進行してください。

TODO.mdの既存の注意書きや実装済みに関する項目は消さないでください。

色々前回のTODOが消えたりあれだったのでこういう感じでdocs/prompts.mdを作った。

今回行なったplan-*.mdからTODOへの転記のタスクは度々行う機会がありそうです。今までの応答などで気をつける点などを加味しつつ1回のプロンプトでお願いするようにしたいです。そこで現時点でそのプロンプトを把握してるであろうあなたにdocs/prompts.mdに英語でプロンプトを出力してもらいたいです。

podhmopodhmo

2025-07-28

  • gemini gemsを使ってみる
podhmopodhmo

gemini gemsを使ってみる

現状は

  • 名前
  • カスタム指示
  • 知識（ファイル10個まで）

が設定できるだけというもの。usageを表示できないのが不便。

特に使う必要はなさそう。

podhmopodhmo

2025-07-29

  • formatをするだけのgithub action
podhmopodhmo

formatをするだけのgithub action

julesは常にAGENTS.mdを守るわけではない。なのでgoimportsとかを常に使ってくれるわけではない。スマホからなのでコマンドの実行環境がない。仕方がないので生成させた。

手動で実行する。

トークンが必要だった

Fine-grained PATを使用する場合

  • Contents: Read and Write
  • Pull requests: Read and Write
podhmopodhmo

2025-07-30

  • julesくんはテストだけでも不足
  • 英語でメモがやっぱり取りたい
  • 直近julesで書かせてみたリポジトリっていくつあるんだろ？
podhmopodhmo

julesくんはテストだけでも不足

致命的な問題が後になって表出するね…テストを書いてても… スマホだけ開発はやっぱり厳しいのか…

かなり偶発的で自主的な障害対応状態になりこれによって頭は局所的に働くのだけど普通に疲れるというか無理する形になるんだな。アドレナリン的なものがでて辞められないみたいなのもある。ただし解決後に徒労という感じもあり…。休養のタイミングがなくHPが下限ギリギリで張り付く感じになる。

その上辞められなくなってる。

あとインクリメンタルな開発という概念が消えるのでデバッグが後にクソ辛くなる感はあるな…。

まさにレガシーコードに触れる感じ
（てすとはある）

LLMを使ったコーティングのアナロジーは重機とかで良い気がするんだよな。

あとサブプロセスが好き過ぎる（geminiだけかも？）

podhmopodhmo

英語でメモがやっぱり取りたい

aiとやり取りしつつコードを書いてるとき公に見せるコードはやっぱり英語で書きたい。そしてやるべきタスクが増えて頭の中に乗り切らなくなったときにメモを取りたい。
これをスマホ上でやろうとすると結局公の場でやりたくなるので英語でメモが取りたくなる。しかし英語の文法への理解も最近怪しくなってきた。タイポなどに気づきたい（自分用の変形した奇形の英語メモはやめたい）

もう一つ。スマホのタップ入力のところで気軽に日英翻訳の機能が使えるようになってるのだけど、ここで出力される英語が気に入らない時がある。これを直したいがちょっとした変形ができない。これができるようになりたい。そしてそもそも一発でいい感じの英語に翻訳される入力ができるようになりたい。この2つを目論んだプロンプトを考えていた。

podhmopodhmo

直近julesで書かせてみたリポジトリっていくつあるんだろ？

podhmopodhmo

flagsのみのコマンドラインオプションパーサーを作るくん（一部のgoのコード自体をミニインタプリタで実行と言うアイデアがgo-scanのminigoに繋がってる）

pr114件
https://github.com/podhmo/goat

ずっと言っていたlazyなgo/packagesの代わりになるライブラリ。型の解析をどれだけサボれるかが肝そう。インターフェイスを揃えるのは諦めた。examplesで利用例を確認してたらそちらに力を注ぎすぎてる感がある（マーカーでやるのの限界がある気がする）。

pr214件
https://github.com/podhmo/go-scan

cueを使ったvalidatorのお試し実装。こちらは素直にgostaticanalysis/codegenとか既存の枠組みに載ってる。

pr77件
https://github.com/podhmo/veritas

全部goで全部コード生成かも。いろいろ知見は見えてきた。

podhmopodhmo

2025-07-31

  • go/astのnodeの変更でコメントがずれる
  • プロンプトの調整が悩ましい
  • LLMとの対話履歴の共有について
podhmopodhmo

プロンプトの調整が悩ましい

  • grokのxのスレッド取ってくるやつ、出力形式を守らない事がある。英語で返ってくる。
  • 対話履歴のラバーダックのやつ、過程をすっ飛ばす。
    • 実験レポート風のやつのほうが役に立つかも?
  • 英文チェッカーが多分ネイティブ向け
podhmopodhmo

LLMとの対話履歴の共有について

  • ai studio上で共有するとログイン必須になる
    • どうせならとesaやgistで共有する仕組みを作った
    • （grokは共有は楽でコピペが辛い）
  • ai studioで共有する利点もある
    • 履歴共有後に別人が対話を進められる
      • branch from hereが便利
    • セル毎にmarkdownでコピペできる
  • 対話履歴は不要な重複が存在する
    • 思考の備忘録のプロンプトを作った
    • 技術的な対話履歴の備忘録も作った
    • （結果ではなく過程の共有が有効）
podhmopodhmo

スマホ前提の制限

  • 画面が狭い
    • 細々とした編集が無理
    • 何かと何かを比較する動作ができない
    • 多くのwebサービスが使い物にならない
  • パラメーター指定でweb APIを呼び辛い
    • web APIを呼ぶにもデプロイが必要そう
    • プロンプトの実行は一回にしたい
      • mermaidのsyntax errorがだるい
      • 調整の繰り返しによる修正ができない
  • クリップボードのサイズに制限がある
    • gistへのファイルアップロードが欲しい
      • oauthログインが必要（デプロイ）
      • （github pagesだと無理）
podhmopodhmo

スマホでの開発について

  • リモート側のaiエージェントだけ使える
    • jules
    • 並列実行は容易（蠱毒）
    • ci設定的なだるさがある
      • アクシデント時に直接環境を触れない
      • セーブ/ロードに時間がかかる
    • 休養時間がなくなる。時間が溶ける。
  • クライアント側のaiエージェントが無理
    • claude code
  • 補助的な施策は取れない
    • github actionみたいな設定は面倒なのでしない（claude code action）
    • どこかにsshも未達成（気力がない）
  • 実行結果を確認できない
    • cliを作っても事実上ライブラリの実装
    • デプロイしないとスマホから触れない
    • web uiを手元で確認して作れない
  • エディタを豪華に便利にできない
    • emacs, vscode
podhmopodhmo

音声入力について

  • siriなどの時代から苦手意識がある
  • 入力速度はおそらく随一
  • デバイスやフォーカスが占有される
    • （専用機器を買う可能性はあり？）
  • 文章作成時には後に編集が必要
    • 誤認識がひどい（？）
    • 改行が入力できない
podhmopodhmo

2025-08-01

  • LLMとmermaidとsyntax errorと
  • 失敗したprからドキュメントだけを取り出したい
podhmopodhmo

LLMとmermaidとsyntax errorと

まぁまぁミスする。何か良い方法がないかなと考えてる。単純にはPC上で何往復かすれば良いのだろうけれどスマホからの利用の場合はそうでもない。

仕組み的にはメモ化再帰的な形でブラウザ上だけでリーズナブルに解決できないか？みたいなことを思ったのだった。

大げさに言うとこれ当然だけどコピペして切り貼りとかしたくないわけよ。

まぁ手元でPCでさわれば何往復かさせるだけな気もするけれど。理想はテキストを渡したら一気に自動でmermaidの図だけが修正された結果が手に入る感じが良い。

大げさに言うとverilogだけどこれ

https://arxiv.org/abs/2311.16543

podhmopodhmo

2025-08-02

  • go-scan
  • julesに言うことを聞かせる
podhmopodhmo

go-scan

  • convertが壊れてたのを修正した
  • 基本的には全ての要件を満たすようになった

それはともかく思ったのは2つ

  • そろそろgo-scanとexamples/convertの関係を整理したいgit subtreeとかで管理する？
    • まだまだgo-scan自体はvendor的な感じで使いたい
    • 手元にライブラリがある方が楽
    • ツール単体でも機能させるような調整をしたい
    • 名前をまだ決めてない
  • そろそろワンショットのドキュメントが邪魔になってきた
    • docs/plan-xxx.mdとか作ったはいいがずっと残るのもあれ…
    • やはりまともにメンテする仕様という存在を作るべきなのか…？
  • derivingを一度に行いたい

本質的なだるさを考えてみると、マーカー経由だとフリーハンドかつ細々とした調整がだるく、言語を分けるとスタブの生成が面倒という話になるのだよな。

そして一回きりで終わるのではなくずっとメンテし続けなくてはいけない（しかし環境が変わればツールも変わる）。

podhmopodhmo
  • 動くと便利の間の境界は大きい
    • filledじゃない場合にはそのフィールドが知りたい
    • grepで列挙したい
  • 追加したい
    • walk once
    • enum的な抽出
podhmopodhmo

julesに言うことを聞かせる

タスクが終了したので作業できません的な返答

再度最終的なコードを提出してしまったため、ドキュメントを直接修正することはできません。大変申し訳ありません。

こういうのは、「それではもう一度今の点を考慮に入れて再度計画し直しタスクをやり直してください」 とかで良い

podhmopodhmo

jules、簡単過ぎるタスクでプランの作成が行われない時に更新を検知しないみたい？

web ui上にもdiffが現れないしsubmitもされないのだけど、jules自身はファイルも更新したしタスクも完了したと思ってるのだよな。ドキュメントの更新的なタスクでこれがよく起きる（だるい）

「まだ私のところには差分が届いてません。git add -fも何をしても良いのでドキュメントの更新をサブミットしてください。

それでも無理なら最初から計画を立てて実行し直してください（もしかしたら計画を立てる作業がないとあなたの作業内容を検知するweb uiは正常に機能しないのかもしれません）」みたいなことを言うと計画を立てるのでどうにかなる。

というかたぶん計画を立てさせるだけで良い。

「go-scanにenum的な定数定義を取得する機能を追加してください。基本的には型定義に隣接したconstの定義があればenum的な定数定義でしょう。実装計画をdocs/plan-scan-enum.mdに出力してください。

作業はドキュメント作成だけですがしっかり計画を立てて類似パターンを考えてドキュメントを出力してください。」

podhmopodhmo

2025-08-03

  • go-scan deps-walk
podhmopodhmo

go-scan deps-walk

  • パッケージ間の参照関係を辿るものを作りたかった。
  • 意外と実装はサラッと終わる。ライブラリとして成長してきた。
  • mermaidとしての出力はやっぱり壊れてた
  • JSON出力で考えることがあった
  • 逆参照を辿るのが地味に面倒
  • mainを特別扱いする必要がある
podhmopodhmo

2025-08-04

  • mermaidやgraphvizをスマホで手軽に表示したい
podhmopodhmo

承知いたしました。技術的な特徴と利用ライブラリを以下に示します。

技術的な特徴

  • UIフレームワーク: Pico.css v2
  • JavaScriptモジュールシステム: Native ES Modules
  • モジュール解決: Import Maps
  • ライブラリ読み込み: 動的インポート (import()) による遅延読み込み
  • 高速コンピューティング: WebAssembly (Graphviz)
  • アーキテクチャ: シングルページアプリケーション (SPA), バンドルレス
  • スタイリング: モバイルファースト, CSS Grid Layout

利用ライブラリ (CDN経由)

  • Mermaid: mermaid
  • d3-graphviz: d3-graphviz
  • Graphviz (WebAssembly): @hpcc-js/wasm
podhmopodhmo

2025-08-08

  • cdn経由のesmのimportがむずい
  • julesが途中で止まったとき
podhmopodhmo

julesが途中で止まったとき

以下のような質問を投げる。さらに酷いときはtrouble-foo.mdみたいなテキストを作らせる。

現状の状態を把握したい

- 今回何をしたか教えて
- どのようなアクシデントに遭遇したのか教えて
- どのような見込み違いに遭遇したのか教えて
- 残りのタスクを教えて（TODO.mdを見る必要はない。現在抱えてるものすべて）
podhmopodhmo

2025-08-11

  • jules時代で会話の仕方で解決するものがある
  • special form付きのgoのサブセットのインタプリタ
podhmopodhmo

jules時代で会話の仕方で解決するものがある

  • バグ修正とともにレポートを書かせる
  • 既知のバグと言っていた部分に言及する
  • 直させてさらにパフォーマンスのことを尋ねる

https://github.com/podhmo/go-scan/pull/366

💭 対話履歴も残しておきたいくらい

podhmopodhmo

special form付きのgoのサブセットのインタプリタ

作った。マーカーベースのアプローチの問題を解決したかった。

動作のキモは

  • go側ではスタブのライブラリを読む
  • 実行時は別のインタプリタで実行する

こういうコードでimport pathとか空気を読んでいい感じにうごかしたい。文字列で指定とかだと結局マーカーベースのアプローチと変わらない感じ。

//go:build codegen
// +build codegen

package main

import (
	"github.com/podhmo/go-scan/examples/convert/convutil"
	"github.com/podhmo/go-scan/examples/convert/sampledata/destination"
	"github.com/podhmo/go-scan/examples/convert/sampledata/funcs"
	"github.com/podhmo/go-scan/examples/convert/sampledata/source"

	"github.com/podhmo/go-scan/examples/convert-define/define"
)

func main() {
	// Define global rules for types that cannot be mapped automatically.
	define.Rule(convutil.TimeToString)
	define.Rule(convutil.PtrTimeToString)

	// Define the conversion from SrcUser to DstUser, only specifying the exceptions.
	// The source and destination types are inferred from the function signature.
	// Fields with matching names (e.g., Details, CreatedAt) are mapped automatically.
	define.Convert(func(c *define.Config, dst *destination.DstUser, src *source.SrcUser) {
		// Exception 1: Different names.
		c.Map(dst.UserID, src.ID)

		// Exception 2: Different names AND a custom conversion function.
		c.Convert(dst.Contact, src.ContactInfo, funcs.ConvertSrcContactToDstContact)

		// Exception 3: A computed field.
		c.Compute(dst.FullName, funcs.MakeFullName(src.FirstName, src.LastName))
	})

	// Define conversion for a nested struct with name differences.
	define.Convert(func(c *define.Config, dst *destination.DstAddress, src *source.SrcAddress) {
		c.Map(dst.FullStreet, src.Street)
		c.Map(dst.CityName, src.City)
	})
}

defineパッケージの関数群はast的な情報を取り出しいい感じに対応関係の情報を取り出す（これは型から型の変換関数の生成用のメタデータ）。

podhmopodhmo

マーカーベースだとこう。

package source

import "time"

// convert:import convutil "github.com/podhmo/go-scan/examples/convert/convutil"
// convert:import funcs "github.com/podhmo/go-scan/examples/convert/sampledata/funcs"
// convert:rule "time.Time" -> "string", using=convutil.TimeToString
// convert:rule "*time.Time" -> "string", using=convutil.PtrTimeToString

// @derivingconvert("github.com/podhmo/go-scan/examples/convert/sampledata/destination.DstUser")
// convert:computed FullName = funcs.MakeFullName(src.FirstName, src.LastName)
type SrcUser struct {
	ID          int64 `convert:"UserID,using=funcs.UserIDToString"`
	FirstName   string
	LastName    string
	Address     SrcAddress
	ContactInfo SrcContact `convert:"Contact,using=funcs.ConvertSrcContactToDstContact"`
	Details     []SrcInternalDetail
	CreatedAt   time.Time
	UpdatedAt   *time.Time
}

// @derivingconvert("github.com/podhmo/go-scan/examples/convert/sampledata/destination.DstAddress")
type SrcAddress struct {
	Street string `convert:"FullStreet"`
	City   string `convert:"CityName"`
}

type SrcContact struct {
	Email string
	Phone *string
}
podhmopodhmo

2025-08-12

  • goのサブセットのインタプリタができたので
  • julesでの実装のスタイル
podhmopodhmo

julesでの実装のスタイル

最近はだいたいこんな感じになってきた。ある機能xxxが欲しいときに軽い調査のあとに計画を立ててTODOを作ってあとはキューを回す。

  1. docs/analysis-xxx.md を作成
  2. docs/plan-xxx.md を作成
  3. plan-xxx.md から TODO.md にタスクリスト化して転記
  4. TODO.mdをキューとしてループを回す
  5. TODO.md のxxxのセクションをsquashしてimplementedに移動
  6. docs/plan-xxx.md に implemented のnoteを付ける

🫠docsとTODOが膨れ上がっていくのが問題ではある。

podhmopodhmo

2025-08-13

  • go1.25が出たのでencoding/json/v2を
  • 技術的な備忘録のプロンプトを改善したい
  • 備忘録プロンプト集自体を品評させてみる
podhmopodhmo

2025-08-15

  • julesに何回も要望したいことがあったのでメモ
podhmopodhmo

julesに何回も要望したい事があったのでメモ

特に汎用性があるわけではない。とは言え調査用のテストを書いてもらってそれをトラッキングするドキュメントを作ってあげるのも便利ではある。

スキップを外したテスト結果をもって docs/trouble-minigo-stdlib-limitations.md の内容を更新して。

他にもうひとつ docs/plan-minigo-stdlib-limitations.mdのマナーに従ってstdlibのパッケージのテストを1つ追加して。minigo/minigo_stdlib_custom_test.go にテストは追加して。そしてまたdocs/trouble-minigo-stdlib-limitations.mdに結果を追記して。

あ、strings,bytes,strconv以外のものでやって
podhmopodhmo

2025-08-18

  • go-scan, minigoのv0.0.1を公開した
podhmopodhmo

examples/minigoのmain.goでffiのインストールをしてるのを見ると各自時前でビルドしたほうが良いやつなんじゃという気はする。

遅延importのインタプリタはそれなりにできたので今度はシンボリック実行的なものを作りたい。

podhmopodhmo

2025-08-23

  • docgen = symgo + minigo
  • 不要なメソッドや関数を消したい
podhmopodhmo

docgen = symgo + minigo

symgoでシンボリック実行的なことをしてgoのコードを解析してopenapi docを生成するツールを試しに作ってみていた。対象はgo1.22+のnet/http。

その後カスタマイズをビルドせずに行えないかを考えてみたりして、設定ファイルをminigo（importが遅延されるgoのサブセットのインタプリタ）で解釈することにしてみた。するとgqlgenなどのように対象を文字列で書きタイポに苦しむみたいなことから解放されそうだった。

こんな感じでimportを使って書けるのが良い。

https://github.com/podhmo/go-scan/tree/main/examples/docgen#customizing-analysis-with-patterns

podhmopodhmo

あとこれでメソッドを許すのにminigo側にtyped nilを受け入れるようにする必要が出てきたのだけどこれをjulesに受け入れさせるのに苦労した。julesに単純に実装してと言ってしまうと既存のテストコードなどとの兼ね合いから実装の方法の可能性が枯渇してスタックする。このときに環境がおかしいみたいなエラーメッセージで死ぬのでハマった 👾。

ちなみに以下のような制約を追加して実装させた

  • typed nilからメソッドを値として参照したい
  • typed nilのメソッドの実行は失敗して良い
  • typed nilのフィールドアクセスは失敗して良い

極論言えば制約付きの遷移先を巡ってランダム探索みたいな感じで考えられるからそりゃぁ遷移先の候補が空になったら死ぬよな。

podhmopodhmo

不要なメソッドや関数を消したい

現在のgo-scanのリポジトリではライブラリのコードのほかにexamples以下に利用例としていろいろなツールのコードが書かれてる。つまるところモノリポと言っても良い。go.modも分かれている。

モノリポの中で使われてないexportedなメソッドや関数を調べる方法はないだろうか？それこそgo-scanを使って作るべきかもしれない。テストコードで使われてるものも省きたいかも。

ちなみにunexportedな関数に関してはgoはそもそもコンパイルエラーなので孤児を気にしなくて良い。

podhmopodhmo

2025-08-25

  • find orphans
  • julesが失敗した時にドキュメントを出させる
podhmopodhmo

julesが失敗した時にドキュメントを出させる

こんな感じでPRを作らせる

現在の状況を未来のあなたのため詳細に出力してください。前提として変更したかった事柄を書きその後見通しや実装結果や意思決定や特にピボットしたものや事前に分かっているべきだった障害などを含めてください。次回同じようなタスクをあなたが再度行うときの助けになるようなドキュメントが欲しいです。docs/trouble-find-orphans-refinement.mdに英語で出力してください。実装は途中でも良いのでこのドキュメントの作成を最優先しこのドキュメントができ次第サブミットしてください。

その後タスクリストを

いいですね。作ったドキュメントの実装をタスクリストに分解して上から順に実装すると完成するというような新たなセクションを設けて追記してください。

ふむむ。ちょっとどう作るかまで固定されてて厳しい。

タスクリストはもう少し抽象度を上げて良いかもしれません。課題のリストにして課題が分かれば十分です。どのように解決するかを載せる必要はありません。もう一度タスクリストを作り直してください。

TODO.mdに

作ったドキュメントのタスクリストをdocs/prompts.mdのマナーに従ってTODO.mdに追加してください

podhmopodhmo

2025-08-27

  • zedを使ってみたい
podhmopodhmo

zedを使ってみたい

  • defaultでemacsのキーバインドが用意されているのが便利
  • ただし追加したいものもある
    • コマンドパレットのtoggle (通常はctrl + shift + p)
    • タブの左右へ移動 (とりあえずctrl + tabで凌げる)
    • コメントのtoggle
    • 検索・置換
    • 直近のプロジェクトを開く (コマンドパレットからrecent open project)
    • 行指定して移動
    • C-oでの改行
    • 語全体を消す
    • 冒頭や末端に移動
  • ない
    • reverse search
podhmopodhmo

設定ファイルのエクスポート/インポートの方法が知りたい（メモするべき）

podhmopodhmo

2025-08-29

  • go-scanの告知への障壁
  • 既存のgoのWAFのここが気に入らない
podhmopodhmo

機能的なこと

  • go-scanと言う名前が良いか未だに迷ってる
  • examples以下をもう少し育てたい
    • ai(jules)に外部ライブラリを読ませる方法が育ってない
    • 未成熟なライブラリは利用例といっしょに育てたい

ディレクトリ構成的なこと

  • 普通の場所に普通のものが置かれてない
    • 余分なものがたくさん置かれてる
  • docs以下に自分用のスクラップメモが置かれてる
    • 消費したメモをdocs/配下に置くのは誤り？
podhmopodhmo

そもそもの目的

  • go/packagesは重たいというところから始まった実験用のサンドボックス
    • 遅延インポート（minigo）
    • 浅い走査（symgo）
    • 設定ファイルとしての利用（docgen）
  • go.modとかに苦しみたくない
    • cwdに過度に依存して失敗がだるい
  • コード生成を一つにまとめたい
    • derivingを用意したい
    • encoding/json/v2のstructの書き方
  • レガシーなコードは依存が雑い
    • minigoで解析したい

普通ならどうする？

  • deps-walkは見づらい
  • docgenが一番わかりやすい
    • 他のフレームワークに対応する…？
    • そもそもbufとconnectを使うのでは？
    • opeapiができて何が嬉しいの？
podhmopodhmo

新たな利用例

  • cli parser (goatみたいな)
  • sqs send場所可視化
  • MCPサーバー？

気になること

  • そもそもPCを触らない
  • ファイルキャッシュの部分を使えてない
  • コード生成用のユーティリティを結局使ってない

本気で作るとしたらgo-scanから持ってこれるもの

  • structから別のstructへの変換（convert）
  • oneofに対応したjson（deriving）
  • requestのbinding (deriving)
  • APIのコードを直接読んでapi docの出力 (docgen)

足りないもの

  • init コマンド
  • ドキュメント
  • 骨格（フレームワーク）

実はWAFが作れる説がある

  • quick apiをリニューアルする
  • devDependency的なものは分けたい
podhmopodhmo

余暇にしても利用しない何かを作ってるのだよな。

自分の嬉しいこと

  • スマホから色々できること

自分ができること

  • PC上でせせこましく設定を管理すること

情報発信したい

  • go.mod, go.workの動き（忘れてきてしまったtestdata）
  • encoding/json/v2
  • いい感じにコメントをずらさずastで書き換える
podhmopodhmo

既存のgoのWAFのここが気に入らない

  • middlewareとhandlerの定義に順序がある（go-chi）
  • protobufなど謎の依存がある（gin）
  • openapi docを手軽に吐けない。謎の記述を要求する（名前忘れた）
    • ogen, oapi-codegen, goaとかはschema to codeなのでnot for me

どうしたい？

  • 基本的にはapi server
  • 全部POSTとGET（QUERY）で良くない？
  • 1ファイルで終わらせたい
  • いい感じにパッケージを分割したい
podhmopodhmo

しかしWAFが作れて嬉しいのか？
もっというとapiserverが作れて嬉しいのか？

podhmopodhmo

2025-08-30

  • gemini with github
  • コードの行数を数えたい
  • github coding agentを試してみた
podhmopodhmo

コードの行数を数えたい

例えばgoのテストコードとコメントを取り除いた行数を数えたい時など。
(以下はgo-scanの結果)

% brew install scc
% scc --exclude-dir testdata
───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                         200     58166     6469      4579    47118      11978
Markdown                    81     14955     3899         0    11056          0
Makefile                     7       161       29        17      115          3
Go Template                  3       174       10        28      136         21
YAML                         3       185       26        19      140          0
JSON                         2       145        0         0      145          0
License                      1        21        4         0       17          0
───────────────────────────────────────────────────────────────────────────────
Total                      297     73807    10437      4643    58727      12002
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $1,944,800
Estimated Schedule Effort (organic) 17.71 months
Estimated People Required (organic) 9.76
───────────────────────────────────────────────────────────────────────────────
Processed 2661349 bytes, 2.661 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

テストを除いた数値 --not-match に正規表現を渡せば良いらしい。

 % scc --not-match ".*_test\.go$" --exclude-dir testdata
───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                          85     27660     3235      3108    21317       6112
Markdown                    81     14955     3899         0    11056          0
Makefile                     7       161       29        17      115          3
Go Template                  3       174       10        28      136         21
YAML                         3       185       26        19      140          0
JSON                         2       145        0         0      145          0
License                      1        21        4         0       17          0
───────────────────────────────────────────────────────────────────────────────
Total                      182     43301     7203      3172    32926       6136
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $1,059,281
Estimated Schedule Effort (organic) 14.06 months
Estimated People Required (organic) 6.69
───────────────────────────────────────────────────────────────────────────────
Processed 1815107 bytes, 1.815 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
podhmopodhmo

github coding agentを試してみた

  • https://github.com/podhmo/go-scan/pull/680
  • 見た感じあんまり性能は良くなさそう
  • julesとは異なり設定してないからかもしれない
  • issue自体がjules製（つまりgemini製）だから復元率が良いのかもしれない

💭 views的なリンクで内容を眺められたのは面白かった。

podhmopodhmo

2025-09-07

  • go-scan/symgo interface
  • symgo performance tuning
podhmopodhmo

symgo performance tuning

最高にひどい。なんかjulesで動かなくなったなーとか思っていた。
結局たかだか17000+行程度のコードで80GBくらいメモリー使ってた。

1回目

  • Memory Usage: 60-70% reduction (from 75GB to ~20GB)
  • Execution Time: 40-50% reduction (from 7s to ~3.5s)
  • GC Pressure: 50% reduction in GC cycles

2回目

  • Memory usage reduced by 99.9% (from 13.4GB to 14.8MB)
  • Execution time reduced by 95% (from 7s to 0.3s)
  • Made large-scale symbolic execution practical (17,000 lines of Go code analysis)

https://github.com/podhmo/go-scan/pull/761/files