『Goの100の失敗パターンと解決策』本の舞台裏

• Go言語に夢中になったきっかけと、本を書くことになった個人的な歩みを中心にした話
• ブログ記事の成功をきっかけにManningと契約し、3年かけて本を完成させた体験談
• 数多くの試行錯誤と感情の浮き沈み、特に編集プロセスでの対立が生々しく描かれた文章

Go言語との最初の出会い、そして転機

• 2018年にスイスでScala/AkkaによるPoC作業を行った後、Go言語の効率性と簡潔さに魅了される
• 新しい会社でGoを活用しながら実務経験を積み、同僚たちが同じミスを繰り返すのを見てブログ記事を書き始める
• Mediumに掲載したブログ記事が予想外に大きな反響を呼び、文章を書くことへの自信を得る

本の出版の始まり: アイデアから契約まで

• ブログ記事の延長線として、100個のGoの失敗事例を集めて本へと拡張する計画を立てる
• Manningの1社のみに出版企画書を送り、簡単なメールで素早く前向きな返答を受け取る
• 7人の外部レビューアーから肯定的なフィードバックを受け、2020年12月に正式契約を締結

執筆プロセスと編集者との協業

• 「最低限の想定読者（MQR）」を設定した後、不要な基本内容を思い切って削除
• 非技術系の編集者である開発編集者（DE）と協業しながら、文章力の向上を経験
• 繰り返しのレビューと修正を通じて、10回以上書き直した章も存在する

外部レビューとフィードバックの受け入れ

• 本は3段階（1P、2P、3P）に分かれて外部技術レビューが行われ、評価が徐々に向上
• 1P: レビュアー13人、平均4.10点 → 2P: 4.15点 → 3P: 4.6点を達成
• フィードバック受け入れの原則は、「たった1つのフィードバックも無視しない」というBill Kennedyの助言に由来する

編集プロセスでの大きな危機

• 当初指名された技術編集者（TDE）はGoに関する基本知識さえ不足しており、不満が生じる
• 複雑な校正システムと非効率な協業方式に加え、編集者が大量の誤りを挿入してしまう事態まで発生
• 大きな挫折感から作業中断を宣言するが、Manningが素早く新しい編集者を割り当てて問題を解決

完成までの道のりと出版後の憂うつ

• すべての過程が終わった後、「終わった」という感情よりも空虚さが押し寄せる（出版後うつ）
• 3年近い時間のあいだ注ぎ込んだエネルギーと感情が、一瞬で消えてしまったように感じる
• その後は徐々に回復し、自分が作り上げたコンテンツへの誇りを取り戻す

本の成功とコミュニティの反応

• 出版直後、長い宣伝をしなくてもRedditやTwitterなどで自発的な共有が起こる
• 1年後、オープンソースサイト 100go.co を通じて無料の要約コンテンツを提供
• Manning側からも良い反応があり、今後は著者支援の役割の提案まで受ける

印税、収益、そしてそれ以上の意味

• 2024年末時点で英語版は11,452部を販売し、総収益は約$47,000
• 時間あたりの収益は低いが、お金ではなくコミュニティへの貢献と個人的な達成により大きな意味を見いだしている
• Java、C++、SQL Serverなどの後続シリーズにも影響を与える

結びと個人的な決意

• Goodreads評価は4.66で、目標を上回って達成
• 最高のGo本ではないかもしれないが、当時の自分に作れた最高の本だという確信がある
• 第2版の提案も受けており、読者からのフィードバックを待っている

[zihado]

https://product.kyobobook.co.kr/detail/S000211704725
この本ですね

[GN⁺]

Hacker Newsのコメント

• レビューワークフローをPRベースの設定で説明し、改善提案も行ったが、相手は試そうとしなかった。協業の円滑さと効率性を求めていた
• コピーエディターがWebベースのレビューツールよりもgitの利用に慣れていたのは驚きだった。特にGoの本をレビューしながら、Goについてあまり詳しくないように見えた
• Manningにコピーエディターがいることが奇妙に感じられる
• Manningとの否定的な経験を共有している。本を書いていてセルフ出版中だが、Manningに第2版を提案できる可能性について問い合わせたところ、提案は却下したと返信された
• 文書形式としてはGoogle Docsしか言及されていなかったが、ブログ記事によるとAsciiDocも受け入れているようだ
• sync.Poolに関する問題に触れ、関連リンクを共有している
• Goの標準ライブラリでのsync.Poolの使われ方を見ると、さまざまなサイズの段階的なプールがあり、大きなサイズの項目は捨てられることが多い
• DocBookでManning向けに本を書いた経験を共有している。コピーエディット後、すべての内容が1行に戻ってきてがっかりした。セルフ出版に切り替えた
• O'Reillyとの最初の接触はメールで始まり、彼らのツールは素晴らしいと言っている。gitコミットからサポートされている形式の完全版を生成できる
• 本の形式は読書会に向いていると言及している。失敗例が良い議論の題材となり、経験豊富な人たちはどうやってその失敗を避けてきたかを共有していた
• 本にある多くの「失敗」はGoのいくつかの側面を紹介するもので、「fuzzingを使わない」や「errgroupを使わない」がその例だ
• Timのレビューは非常に価値があると述べつつも、レビューの具体的な説明がないのは残念だった
• Manningの別の著者がその本を称賛し、実用的な情報が多いと述べている。新しいGoプロジェクトを始めるにあたって、また参照するつもりだ
• goroutineに関する例について疑問を呈している。goroutineを使わずに関数クロージャを作った場合でも、同じi変数を参照するのか気にしている
• 著者がフィードバックを受け取り、コミュニケーションの方法を学んでいく過程に敬意を示している。問題のあるコピーエディターに対して毅然とした態度を取った点にも触れている
• スイスでC++のレガシーコードベースをリファクタリングした経験を共有している。新しいスタックを試し、難しければ別のものを試せる環境が良かった
• Sensei's Libraryにある、Goで起きた失敗に関するページのまとめに言及している