achilleasa

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.

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

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.

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.

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.

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.

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.

Hi HN! After several months of intense writing and code debugging I have finally published my first book: Hands-on Software Engineering with Golang (link in title).

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!

Yes, the talk will be recorded and posted online with the slides and some getting started code.

I take a slightly different approach for my implementation that allows me to use the standard go toolchain. I use nasm for the early ASM code and patch the go build tool's output (see: https://github.com/achilleasa/gopher-os/blob/master/Makefile...) to bypass the link step and replace it with a manual call to ld that links the go object files with the output from nasm.

I will be talking about this approach in more detail in GolangUK '17.

Hi, I am the author of gopher-os. It started as a fun research project to learn more about the Go runtime internals and I didn't really expect it making it to HN.

If you take a look at the Go runtime sources you will notice that all the low-level arch/os-related bits have been split into separate files which usually invoke some syscalls (e.g. the memory allocator eventually calls mmap)

The idea I am currently investigating is to first provide an implementation for things such as physical memory allocation and virtual memory mapping which would ultimately allow me to bootstrap the Go allocator. From that point onwards the plan is to incrementally add more features and gradually initialize the rest of the runtime.

This is much more difficult than it sounds as all code must be written in such a way to prevent the compiler from calling the runtime allocator (no variables allowed to escape to the heap).