本を書くのにCIパイプラインを構築した話
How I Over-Engineered My Book
著者が本を書くのに、Git、Markdown、CIビルドパイプラインを使った経験を紹介。5,500以上の自動チェック、6つのリアルタイムリンター、重複検出、LLM監査など、ソフトウェア開発の手法を執筆に応用。GitHubでの勤務を現在形で書くとビルドが失敗するカスタムバリデータなど、ユニークな例も。
私は自分の本を、自分が毎日使っている開発者向けツールで書くことにした。
HNでの議論
44- hinkley
『Thinking in Java』がベストセラーになった後、ブルース・エッケルの講演を一度聞いたことがある。
彼がJavaについて、そしてその本を書くことで学んだ教訓について話すのかと思っていた（彼はJavaで始めたわけでも終えたわけでもなく、多くのプログラミング言語を記録していた）。
ところが実際に聞けたのは、彼がその本をいかに「過剰にエンジニアリングしたか」という話だった。彼はインターンたちに、ある問題を解決させていた：出版されたコード例が、エディタに転記されたときに実際に動くことをどうやって保証するか、という問題だ。
彼らは、ライブコードに抽出ポイントをマークアップして、原稿に自動的に抜粋するツールを作った。
約5年後、私はフォーチュン50の企業で働いていた。そこには、仕事をテキパキとこなし、周りの官僚的な組織単位を少し不安にさせるような、たくさんの契約社員がいた。誰かが、私たちの開発者向けドキュメントが、会社が考案した定義済みのドキュメント標準を満たしていないと文句を言うことで、弱点を見つけたと思ったようだ。彼らの言い分は間違っていなかったが、私たちが構築していたプラットフォームに慣れている人なら、私たちが提供したもので全く困ることはなかっただろう。
もし彼らの提案通りにやっていたら、リリースのたびにほぼ1週間の時間が追加されていただろう。そして私はすでに、自分がボトルネックにならないように仕事を委任するのに苦労していた。だから、その追加の1週間は私たちのベロシティを少し下げ、他の人たちと同じくらいのレベルにしていただろう。それは巧妙な策略だったが、ブルースが私を救ってくれた。
毎回のリリースでドキュメント更新に苦労する代わりに、ブルースの戦略がすでに…（原文のまま）
- sinab
デモをありがとうございます！コンセプトは気に入りました。ただ、個人的には、あなたがデザインした文体が、非常にAI生成的に読めると感じます。例えば、「Here's the irony: after automating everything up to this point,」や「Turning emoji into images solved the missing-font problem and created a subtler one.」のようなフレーズでセクションを始めるのは、どちらもAI生成の散文の強い特徴です。なぜそう感じるのかを明確に説明するのは驚くほど難しいのですが。あなたの文体がAI生成の散文に似てくるように進化したのか、それともAI生成の散文があなたに似てくるように進化したのか、気になりますね！
- t-kalinowski
自動化で使っているツールのリストを見て、これは気に入るだろうと思いました。追加のツールとしてどうぞ：https://t-kalinowski.github.io/yamark/
（開示：私が書きました）
- cadamsdotcom
カスタムlintはとても安価で簡単なので、やらない手はない！
> 「このリポジトリに、ハイフン付きの「open-source」という文字列が存在するすべてのファイル名と行番号を出力し、インスタンスが見つかった場合はゼロ以外の終了コードで終了するスクリプト形式のpre-commitフックを追加してください。そして、それを`.git/hooks`にインストールして、私またはエージェントがすべてのインスタンスを削除するまでコミットがブロックされるようにし、二度と「open-source」という文字列をコミットしないようにしてください。」
Enterキーを押してから1分後には、リポジトリに二度と「open-source」という文字列が現れないことを保証する仕組みができあがります。
- stephantul
この投稿が非常に読みにくいと感じるのは、皮肉なことかもしれません。内容にはとても興味があるのですが、生成されたように読めるのです。