That's all. Just sharing that the methodology worked so well. I felt like I could legitimately jump right into a Go developer team.
I am going through this course- and it is fabulous. Covers tests, and even though the topic names might seem easy or trivial(I mean there is only so many ways you can write loops or define arrays), they include a lot of "extras" that make it fun- for example one of the topics might include details about how to write doctests and docs, another one might introduce table driven tests and provide advice on when to use them. Overall it is great.
I'd be very interested in seeing this approach applied to other language courses.
Coming from a background in scripting languages, Rust is still a lot more difficult to learn than Go, but I found that book very helpful.
What I like about the Go book is that it feels production-ready, even though it is simple. This is because it is following industry best practices. There's no "code in isolation", if that makes sense.
As an aside, there’s nothing like attending a training in person and I highly recommend it. NOT because I work for Ardan, but because the quality is top notch. And Bill is really entertaining to watch teach X-D
I can really vouch for Bill, he is one of the best teachers out there!
There's a list of his publicly-available talks on the Ardan Labs training repo:
Their schedule is public and shows them on most continents:
They're huge contributors to the Go community via their conference workshops, and I can't thank them enough for the knowledge that they've gathered, refined, and shared all these years. (I help organise GopherCon Singapore.)
That's why I wrote a book which teaches Go web dev example
Books for newbies are written by those with 15 30 yr experience. They write using their advanced understanding which is very difficult for newcomers to understand
It will fill all the gaps and answer all the questions one can have, especially after the Tour of Go or reading a book which only scratches the surface.
I can't express enough how amazing that course and how useful what Hoanh did.
Once you finish, I'd also suggest to take a look to the Ardan Lab's github account since there are tons of material for Go.
Bill's presentation also made me giggle a lot -which is a rare thing for tutorials- since he says things like
If I see an interface and it doesn't smell right,
and I'll be asking the developer, why are you
using an interface here? Now if the developer
gives me any one of these two answers, we're
gonna go take a walk.
We cannot "throw more developpers at the problem".
First because they are expensive. But also because that makes management exponentially expensive while necessarily helping with delivery (lump of work fallacy).
Or you are correct and this is appallingly bad drafting and formatting.