Hacker News 의견

• 리뷰 워크플로우를 PR 기반 설정에서 설명하고 개선 제안을 했지만, 상대방이 시도하지 않으려 했음. 협업 과정의 원활함과 효율성을 원했음
• 카피 에디터가 웹 기반 리뷰 도구보다 git 사용에 더 익숙한 것이 놀라웠음. 특히 Go 책을 리뷰하면서 Go에 대해 잘 모르는 것 같았음
• Manning의 카피 에디터가 있다는 것이 이상하게 느껴짐
• Manning과의 부정적인 경험을 공유함. 책을 쓰고 있으며 자가 출판 중인데, Manning에 두 번째 판을 신청할 가능성을 문의했음. 그들은 제안을 거절했다고 답장했음
• Google Docs만 문서 형식으로 언급했지만, 블로그 게시물에 따르면 AsciiDoc도 수용하는 것으로 보임
• sync.Pool과 관련된 문제를 언급하며, 관련 링크를 공유함
• Go의 표준 라이브러리에서 sync.Pool 사용을 살펴보면 다양한 크기의 tiered pools가 있으며, 큰 크기의 항목은 버리는 경우가 많음
• DocBook으로 Manning에서 책을 썼던 경험을 공유함. 카피 에디팅 후 모든 내용이 한 줄로 돌아와 실망했음. 자가 출판으로 전환했음
• O'Reilly와의 초기 접촉은 이메일로 시작했으며, 그들의 도구가 훌륭하다고 언급함. git 커밋에서 지원되는 형식의 전체 버전을 생성할 수 있음
• 책의 형식이 북클럽에 적합하다고 언급함. 실수들이 좋은 토론 주제가 되었고, 경험 많은 사람들은 실수를 피한 방법을 공유했음
• 책의 많은 "실수"가 Go의 일부 측면을 소개하는 것으로, "fuzzing 사용 안 함"과 "errgroup 사용 안 함"이 그 예임
• Tim의 리뷰가 매우 가치 있다고 언급했지만, 리뷰에 대한 구체적인 설명이 없어 실망스러웠음
• Manning의 다른 저자가 책을 칭찬하며, 실용적인 정보가 많다고 언급함. 새로운 Go 프로젝트를 시작하면서 다시 참조할 계획임
• goroutine 관련 예제에 대한 질문을 제기함. goroutine을 사용하지 않고 함수 클로저를 만들면 동일한 'i' 변수를 참조할지 궁금해함
• 저자가 피드백을 받고 의사소통 방법을 배우는 과정에 대해 존경을 표함. 문제 있는 카피 에디터에 대해 단호한 태도를 취한 점도 언급함
• 스위스에서 C++ 레거시 코드베이스를 리팩토링한 경험을 공유함. 새로운 스택을 시도하고, 어려우면 다른 것을 시도할 수 있는 환경이 좋았음
• Sensei's Library에서 Go에서 발생한 실수에 대한 페이지 모음을 언급함