"Go की 100 गलती पैटर्न और समाधान" किताब की पीछे की कहानी

• यह Go भाषा से जुड़ने की शुरुआत और किताब लिखने तक की व्यक्तिगत यात्रा पर केंद्रित कहानी है
• एक सफल ब्लॉग पोस्ट से शुरुआत कर Manning के साथ अनुबंध करने और 3 साल में किताब पूरी करने का अनुभव साझा किया गया है
• कई ट्रायल-एंड-एरर, भावनात्मक उतार-चढ़ाव, और खासकर editing process के दौरान हुए टकराव को जीवंत रूप में बताया गया है

Go भाषा से पहली मुलाकात, और निर्णायक मोड़

• 2018 में स्विट्ज़रलैंड में Scala/Akka के साथ PoC पर काम करने के बाद Go भाषा की efficiency और simplicity से प्रभावित हुए
• नई कंपनी में Go का इस्तेमाल करते हुए व्यावहारिक अनुभव जमा किया, और साथियों को वही गलतियाँ दोहराते देख ब्लॉग लिखना शुरू किया
• Medium पर डाली गई ब्लॉग पोस्ट को उम्मीद से कहीं बड़ा रिस्पॉन्स मिला, जिससे लिखने को लेकर आत्मविश्वास बढ़ा

किताब की शुरुआत: आइडिया से अनुबंध तक

• ब्लॉग पोस्ट के विस्तार के रूप में Go की 100 गलतियों के उदाहरण इकट्ठा कर उन्हें किताब में बदलने की योजना बनाई
• केवल Manning को publication proposal भेजा, और एक साधारण email पर जल्दी ही सकारात्मक जवाब मिला
• 7 external reviewers से सकारात्मक feedback मिलने के बाद दिसंबर 2020 में आधिकारिक अनुबंध हुआ

लेखन प्रक्रिया और editors के साथ सहयोग

• ‘Minimum Qualified Reader (MQR)’ तय करने के बाद अनावश्यक बुनियादी सामग्री को साहसपूर्वक हटा दिया गया
• non-technical developmental editor (DE) के साथ काम करते हुए writing skills को बेहतर बनाने का अनुभव मिला
• बार-बार review और revision की प्रक्रिया में कुछ chapters को 10 बार से अधिक फिर से लिखा गया

बाहरी review और feedback को अपनाना

• किताब को 3 चरणों (1P, 2P, 3P) में बाँटकर external technical review कराया गया, और ratings लगातार बेहतर होती गईं
• 1P: 13 reviewers, औसत 4.10 अंक → 2P: 4.15 अंक → 3P: 4.6 अंक
• feedback को स्वीकार करने का सिद्धांत Bill Kennedy की इस सलाह से आया: “एक भी feedback को नज़रअंदाज़ मत करो”

editing process में बड़ा संकट

• शुरुआत में नियुक्त technical development editor (TDE) के पास Go की बुनियादी समझ भी पर्याप्त नहीं थी, जिससे असंतोष पैदा हुआ
• जटिल proofreading system और collaboration की अप्रभावी शैली, यहाँ तक कि editor द्वारा बड़ी संख्या में errors जोड़ दिए गए
• गहरी निराशा में काम रोकने की घोषणा की, लेकिन Manning ने जल्दी से नया editor नियुक्त कर समस्या सुलझाई

पूरा होने तक की यात्रा और प्रकाशन के बाद का खालीपन

• पूरी प्रक्रिया समाप्त होने के बाद “यह खत्म हो गया” जैसी राहत के बजाय खालीपन महसूस हुआ (post-publication depression)
• लगभग 3 साल तक डाली गई ऊर्जा और भावनाएँ मानो एक पल में गायब हो गईं
• बाद में धीरे-धीरे उबरते हुए, अपने बनाए गए content पर गर्व की भावना फिर लौट आई

किताब की सफलता और community की प्रतिक्रिया

• प्रकाशन के तुरंत बाद बिना लंबी promotion के Reddit, Twitter आदि पर लोगों ने स्वेच्छा से इसे शेयर किया
• 1 साल बाद open source साइट 100go.co के जरिए मुफ्त summary content उपलब्ध कराया गया
• Manning की ओर से भी अच्छा रिस्पॉन्स मिला, और आगे लेखक सहायता से जुड़ी भूमिका का प्रस्ताव भी मिला

royalty, कमाई, और उससे भी बड़ा अर्थ

• 2024 के अंत तक अंग्रेज़ी संस्करण की 11,452 प्रतियाँ बिकीं, और कुल लगभग $47,000 की आय हुई
• प्रति घंटा कमाई कम थी, लेकिन पैसे से ज़्यादा community contribution और व्यक्तिगत उपलब्धि को महत्व दिया गया
• इसका असर Java, C++, SQL Server जैसी अगली series पर भी पड़ा

समापन और व्यक्तिगत संकल्प

• Goodreads पर 4.66 rating के साथ लक्ष्य से भी बेहतर परिणाम मिला
• यह शायद सबसे बेहतरीन Go किताब न हो, लेकिन उस समय अपने हाथों से बनाई जा सकने वाली सबसे अच्छी किताब होने का विश्वास रहा
• दूसरे संस्करण का प्रस्ताव भी मिला है और पाठकों के feedback का इंतज़ार है

[zihado]

https://product.kyobobook.co.kr/detail/S000211704725
यह वही किताब है

[GN⁺]

Hacker News राय

• रिव्यू workflow को PR-आधारित सेटअप में समझाया गया और सुधार के सुझाव दिए गए, लेकिन सामने वाला इसे आज़माना नहीं चाहता था। सहयोग प्रक्रिया में सहजता और दक्षता चाहिए थी
• यह हैरानी की बात थी कि copy editor वेब-आधारित review tool की तुलना में git के उपयोग में अधिक सहज था। खासकर Go किताब की समीक्षा करते समय ऐसा लगा कि वह Go के बारे में ज़्यादा नहीं जानता था
• यह अजीब लगा कि Manning के पास copy editor है
• Manning के साथ नकारात्मक अनुभव साझा किया। एक किताब लिख रहे हैं और self-publishing कर रहे हैं, इसलिए पूछा कि क्या Manning में second edition के लिए आवेदन कर सकते हैं। उन्होंने जवाब दिया कि प्रस्ताव ठुकरा दिया गया है
• दस्तावेज़ फ़ॉर्मैट के रूप में सिर्फ Google Docs का ज़िक्र किया गया, लेकिन ब्लॉग पोस्ट के मुताबिक AsciiDoc भी स्वीकार किया जाता है
• sync.Pool से जुड़ी समस्या का ज़िक्र किया गया और संबंधित लिंक साझा किया गया
• Go की standard library में sync.Pool के उपयोग को देखें तो अलग-अलग आकार के tiered pools हैं, और बड़े आकार के items को अक्सर फेंक दिया जाता है
• DocBook के साथ Manning में किताब लिखने का अनुभव साझा किया। copy editing के बाद सारी सामग्री फिर से एक ही लाइन में लौट आई, जिससे निराशा हुई। इसके बाद self-publishing पर चले गए
• O'Reilly के साथ शुरुआती संपर्क email से शुरू हुआ था, और उनके tools को बेहतरीन बताया गया। git commit से समर्थित फ़ॉर्मैट का पूरा वर्ज़न बनाया जा सकता है
• कहा गया कि किताब का फ़ॉर्मैट book club के लिए उपयुक्त है। गलतियाँ अच्छे discussion topics बनीं, और अनुभवी लोगों ने बताया कि उन्होंने उन गलतियों से कैसे बचा
• किताब की कई "गलतियाँ" दरअसल Go के कुछ पहलुओं का परिचय कराती हैं, जैसे "fuzzing का उपयोग न करना" और "errgroup का उपयोग न करना"
• कहा गया कि Tim की review बहुत मूल्यवान थी, लेकिन review के बारे में ठोस विवरण न होने से निराशा हुई
• Manning के एक दूसरे लेखक ने किताब की तारीफ़ की और कहा कि इसमें बहुत-सी practical जानकारी है। नया Go project शुरू करते समय इसे फिर से देखने की योजना है
• goroutine से जुड़े उदाहरण पर सवाल उठाया गया। अगर goroutine का उपयोग किए बिना function closure बनाया जाए, तो क्या वह उसी 'i' variable को refer करेगा, यह पूछा गया
• लेखक के प्रति सम्मान जताया गया कि उन्होंने feedback लिया और संवाद करने का तरीका सीखा। समस्या पैदा करने वाले copy editor के प्रति उनके दृढ़ रवैये का भी ज़िक्र किया गया
• स्विट्ज़रलैंड में C++ legacy codebase को refactor करने का अनुभव साझा किया। नया stack आज़माने और मुश्किल होने पर कुछ और आज़माने वाला माहौल अच्छा लगा
• Sensei's Library में Go में हुई गलतियों पर पन्नों के संग्रह का ज़िक्र किया गया