Show HN: My Book, Hands-On Software Engineering with Golang(packtpub.com)
packtpub.com
Show HN: My Book, Hands-On Software Engineering with Golang
https://www.packtpub.com/gb/programming/hands-on-software-engineering-with-golang
23 comments
Thanks for writing this!
Disappointed that dependency management seems to be based on old vendoring technologies and not Go Modules... (caveat, I only looked at the toc and some previews... but still)
I find it disconcerting that you seem only to care about how dependencies are managed and that to me is superficial compared to the ideas and actions of the book and the code.
To be fair, I have included a section that extols the benefits of Go modules and hints that this is the way forward.
However, for the book source code, I opted to use dep to make sure it can be used by folks that use older Go compiler versions that lack support for Go modules. That being said, it should be trivial to convert the repo to use Go modules.
However, for the book source code, I opted to use dep to make sure it can be used by folks that use older Go compiler versions that lack support for Go modules. That being said, it should be trivial to convert the repo to use Go modules.
> folks that use older Go compiler versions
Why? (I don't mean that as snark; with the ease of installing and upgrading the go compiler compared to the olden days of acquiring a c compiler on a floppy disk - why not target the latest version? I[s] cgo trailing behind?)
Why? (I don't mean that as snark; with the ease of installing and upgrading the go compiler compared to the olden days of acquiring a c compiler on a floppy disk - why not target the latest version? I[s] cgo trailing behind?)
I'd say it's more of a personal preference really. I have hit some issues trying to use Go modules in the past (although support for Go modules has admittedly improved vastly since the last time I used them) and dep has always worked consistently for me so it seemed like a better choice for the book.
That seems like a myopic perspective for a book focused on software engineering. The creators of Go see the language as a tool of software engineering e.g. a tool of software development over time. It would be in the best interest of your readers to align with the creators and the community. Teaching people to use an unofficial dependency manager whose usage will only continue to decline in lieu of the official one will do a disservice to your readers and will not age well.
I totally get your point but dep was (for quite a bit) the official dependency manager experiment before the proposal for Go modules moved forward and is still hosted under the golang GitHub repo with no deprecation notice. As mentioned in a reply above, the book contains a section about Go modules and makes a case for them being the way forward.
Congratulations! Just got my hands on it recently so can't give too valuable feedback just yet. The contents promise to be a real good help with bootstrapping and scaling a product or an engineering project. A very broad spectrum of topics are reflected. It has a good balance of being hands-on and holistic at the same time. Pretty much at the first chapter though :) looking forward to read through the rest.
What was the experience like working with packt?
Apart than the fact that the editors were not native English speakers and I had to spend quite a bit of time reverting several of their editing changes, the whole process was generally smooth and distraction-free (although note I haven't really written a book before so I can't really compare to other publishers) with a few exceptions:
1) Depending on the editor team assigned to your book, they may introduce arbitrary content guidelines (e.g. no code blocks over 15 lines, no figure subtitles; had to press hard to get them restored etc.) after you have already submitted a couple of chapters. I don't really mind the guidelines but it would be great to know them in advance as I had to go back and revise the content.
2) My biggest gripe was their authoring workflow. Personally, I would prefer to write everything in Tex but unfortunately, you need to use their online editing environment (essentially, a wordpress installation with a heavily modified tinyMCE). As I do everything in vim nowadays, I had to setup my own workflow (write markdown + bibtex references, pass through pandoc to convert to html, run a sed script to inject the correct css styles and copy the result back to their system). It's a bit more effort but it allowed me to work offline and use git to track my changes. If anyone is interested in a similar setup, let me know and I can push a repo on GH with the Makefile/css scripts.
Also, there doesn't seem to be a way to get an estimate of the book sales unless you wait for their periodic royalties report. Not sure how it works yet because the book just got released but maybe someone else can comment on this.
1) Depending on the editor team assigned to your book, they may introduce arbitrary content guidelines (e.g. no code blocks over 15 lines, no figure subtitles; had to press hard to get them restored etc.) after you have already submitted a couple of chapters. I don't really mind the guidelines but it would be great to know them in advance as I had to go back and revise the content.
2) My biggest gripe was their authoring workflow. Personally, I would prefer to write everything in Tex but unfortunately, you need to use their online editing environment (essentially, a wordpress installation with a heavily modified tinyMCE). As I do everything in vim nowadays, I had to setup my own workflow (write markdown + bibtex references, pass through pandoc to convert to html, run a sed script to inject the correct css styles and copy the result back to their system). It's a bit more effort but it allowed me to work offline and use git to track my changes. If anyone is interested in a similar setup, let me know and I can push a repo on GH with the Makefile/css scripts.
Also, there doesn't seem to be a way to get an estimate of the book sales unless you wait for their periodic royalties report. Not sure how it works yet because the book just got released but maybe someone else can comment on this.
I wrote for them too. My book was published last May.
I made a similar workflow to you. I wrote using vim and markdown, then used pandoc to convert to HTML. I then wrote some scripts to mangle the HTML to something more compatible with Packt's system (adds some class names and the like).
Regarding sales, they send me royalty statements for each quarter about 3 months after the quarter's end. For example, my book was released in May. I didn't get my first statement until the end of September. My last statement is dated Dec 31st, and it covers July-September 2019.
You can also setup an Amazon author account and get Amazon sales numbers much more quickly. Just go to https://authorcentral.amazon.com/ and create an account. You'll then have to verify that you're the author of your book, but it's pretty straight forward.
I made a similar workflow to you. I wrote using vim and markdown, then used pandoc to convert to HTML. I then wrote some scripts to mangle the HTML to something more compatible with Packt's system (adds some class names and the like).
Regarding sales, they send me royalty statements for each quarter about 3 months after the quarter's end. For example, my book was released in May. I didn't get my first statement until the end of September. My last statement is dated Dec 31st, and it covers July-September 2019.
You can also setup an Amazon author account and get Amazon sales numbers much more quickly. Just go to https://authorcentral.amazon.com/ and create an account. You'll then have to verify that you're the author of your book, but it's pretty straight forward.
I had already set up an author-central account on amazon.co.uk but it seems like sales info (looks like it's US-only) is only available if you also sign up for an author-central account on amazon.com
Not OP, but I wrote a book for Packt.
1) They had very aggressive deadlines that I missed consistently without consequence.
2) Their editors were not native speakers of English, and introduced a ton of grammatical errors that people complained about to me.
3) They published the wrong version of a chapter.
4) They randomly decided one day to stop paying me royalties "because PayPal takes too much commission" or something.
It wasn't all bad, though. They did give me a pretty reasonable advance (at least compared to just writing documentation for free), and they did get good technical reviewers.
This was ~10 years ago, so things might have changed.
1) They had very aggressive deadlines that I missed consistently without consequence.
2) Their editors were not native speakers of English, and introduced a ton of grammatical errors that people complained about to me.
3) They published the wrong version of a chapter.
4) They randomly decided one day to stop paying me royalties "because PayPal takes too much commission" or something.
It wasn't all bad, though. They did give me a pretty reasonable advance (at least compared to just writing documentation for free), and they did get good technical reviewers.
This was ~10 years ago, so things might have changed.
> 4) They randomly decided one day to stop paying me royalties "because PayPal takes too much commission" or something.
Wow wouldn't that be illegal?
Wow wouldn't that be illegal?
It's not illegal, as I'm not their employee. It all depends on what's in your contract. Practically, it depends on what court is going to enforce the contract. They aren't in the US and I am, so... prohibitively expensive to go after the $20 they owe me.
Your Code in Action link[1] doesn't seem to work. It takes me to a youtube playlist that shows as unavailable.
[1] https://www.youtube.com/playlist?list=PLeLcvrwLe1849uRCrEOlQ...
[1] https://www.youtube.com/playlist?list=PLeLcvrwLe1849uRCrEOlQ...
Not sure how the code in action link is supposed to work. That is probably a general feature offered by Packt which is not used by this particular book.
Congratulations on publishing! I'm looking at picking up some Go best practices. What level of Go/coding experience do you feel your book is pitched at?
The first chapters focus exclusively on the SOLID design principles and best practices for testing and vendoring while the rest of the chapters get progressively more and more technical.
I think the material should be relatively easy to follow up to chapter 11 for anyone with a basic understanding of programming in Go. Chapter 12 is a bit more complex as it describes the implementation of a distributed graph processing system.
I would definitely recommend taking a look at the (heavily commented) code on GitHub to see for yourself.
I think the material should be relatively easy to follow up to chapter 11 for anyone with a basic understanding of programming in Go. Chapter 12 is a bit more complex as it describes the implementation of a distributed graph processing system.
I would definitely recommend taking a look at the (heavily commented) code on GitHub to see for yourself.
Mastering Go from the same publisher might work better for you.
Hello from a fellow Packt author
waves
waves
I tried to differentiate from other Go books out there by including things that align with my research interests. Inside the book and its accompanying code you can find lots of (hopefully) interesting concepts such as how to build from scratch data pipelines and a distributed graph processing system inspired by Pregel.
As simply discussing these concepts is not that interesting without some code, my main focus was to write a hands-on book. To this end, the book is kinda code-heavy and includes about 16.2k lines of Go code (52% Go code, 30% tests and 17% auto-generated mocks/gRPC stubs according to gocloc).
You can find the full source code for the book at https://github.com/PacktPublishing/Hands-On-Software-Enginee.... It comes with an MIT license so feel free to tinker with it and let me know what you think!