Darkseal
commented
4 years ago Hello FunkMonkey33 and thank you for purchasing the book.
Sorry if my answer comes up that late, I remember reading your comment a long while back and I was pretty sure I did answer it properly back then. It definitely seems like I didn't - my mistake. Nonetheless, I'll try to do it now - hoping you won't mind :)
As a matter of fact, the whole "Broken Code Myth" paragraph - and the overall concept - is all about understanding that having to (occasionally) deal with such typos and/or errors using GitHub is part of the practice; in my humble opinion that would be a required thing to do before talking about broken code, just like upgrading a OS (or any software) to its latest version before saying it has a bug, a defect and/or a security issue.
I've read a lot of programming books, most of them being without a live GitHub repository since they were mostly printed when platforms like GitHub didn't exist: I've experienced a massive load of typos and coding error, which are kind of inevitable in 500+ pages coding books. When stuff like GitHub finally appeared I was very happy, because I could finally:
A) test the code without having to type it, thus increasing its level of trust ("it's not the book, it's me").
B) check my manually-copied-from-book code against the real thing and therefore find & fix the occasional typos made by me OR throughout the printed book editing process ("oh yeah it was just a typo, the source code works and therefore its overall logic stands").
This, at least in my humble opinion, is the correct approach. You're saying that you would rather "not type everything in, then have it break, only to then chase down the corrected code on GitHub" you're basically doing the opposite, at least from my point of view: it makes me think that you see the fact that the books come with a GitHub repo as a nuisance to deal with, instead of a great addition that was unthinkable until few years ago.
Conversely, the presence of GitHub is the proof that the code is not broken and that the book is able to support you, even with some occasional typos/errors in the printed source code - which are kind of inevitable in a 500+ pages book. And whenever it happens, thanks to GitHub, you can chase down the correct code in a matter of seconds using WinMerge or any other code-compare tool.
Rest assured, I'm not saying I don't want to take responsability for the printed version of the book, and I'm really sorry for those typos/errors: but I sincerely think that writing a testable & buildable GitHub repo and offering it to the readers is definitely the best thing I can do about them.
As for the "GitHub code differences" list you're asking for, I can assure you that it would be very difficult for me to properly maintain a living delta of the various required changes (printed typos, outdated NPM packages, security issues, logical issues, and so on) and fixing them at the same time. Not to mention the fact that these books, after their release date, experience various reprints that periodically "fixes" some of the known typos/errors on the printed versions (and sometimes even create new ones!). Since GitHub is also able to keep track of all these code changes (thanks to the "compare" and "history" features), I think that using it is the proper way to deal with such scenarios as well.
Well, that's it :) I really hope you've enjoyed the book and got my point of view on this "delicate" topic!
This is a great book, very readable. But the code in the book isn't the same as what's on github. For example, I'm in Chapter 3, page 116: Testing it up. The wrong controller method was being hit. Get, and not Latest.
So I compare the code I typed in from the book, with what's on github.
The route for Latest in the book: [HttpGet("Latest/{num}")]
The route for Latest on github: [HttpGet("Latest/{num:int?}")]
And sure enough that's enough to break the code.
So, it's no myth. The code is broken. Thank you for fixing it in github, but I would rather not type everything in, then have it break, only to then chase down the corrected code on github.
Could you maybe publish a list, chapter by chapter, of code that diverges from what's in the book?
Thanks, and sorry if I'm being a jerk. I really do love the book so far, and I'm learning a ton.
Aaron