ASP.NET Core and Angular 2: understanding the differences between "broken code" and "compatibility issues"

It's been six months from the first release of my ASP.NET Core and Angular 2 book and I'm very happy about the positive comments & reviews it received worldwide: however, in this post I will mostly talk about the negative reviews collected by the book, trying to figure out the reasons why they were given and saying my point of view about them.

Let's start by looking at the numbers:

This summarizes the general consensus regarding the book in the top 4 Amazon stores where it sold the most. We can see how it scored a grand total of 21 five-stars, 2 four-stars, 2 three-stars, 4 two-stars and 5 one-star: we don't need to put these numbers in a chart to see that we have a big spike towards the top score, yet also a smaller spike near the bottom. There's nothing bad about it: it just means that most readers did really like the book, yet some didn't. It seems perfectly fine to me.

However, if we take a closer look on the mild-to-negative reviews (one to three stars) we can clearly see how most of these votes are due to the fact that "the source code is broken", "the samples doesn't work", "there are a lot of compile errors" and so on: some of them even tried to explain their bad experience implying that the author (hey, that's me!) probably wanted to hit the shelves as soon as possible, thus ending up in rushing things and releasing a messy code. It goes without saying that I can hardly confirm such an harsh hypotesis, especially considering the insane amount of time I spent writing, testing and refining the source code together with the technical reviewer, which is also a certified Microsoft MVP: on top of that, I also released - with the help of the editor - a GitHub project containing all the source code used within the book, which could be used to build and test the various samples without significative issues assuming that the reader will use the same development framework, third-party libraries, versions and builds adopted by the book.

I honestly felt - and still feel - that it would be something obvious when dealing with any development book: if you want to use a version of Visual Studio or a Typescript build which differs from the one used within the book, you will have to adapt the code accordingly to the changelogs. Most of the time we're talking about trivial stuff, expecially these days when you can Google out the issue and/or get the solution on StackOverflow: they changed the typings, then you need load the new typings; they moved the class, so just change the namespace; and so on. That's about it: nothing more, nothing less. The code reflects the passage of times, the developer just need to keep up with the flow performing minimum changes to it when required. I'm saying this with full belief because I did my best to help the readers to adapt the source code by answering to all the GitHub issues and e-mail sent to the publisher I received: nine times out of ten the required fix was about changing a few characters within a single line of code that anyone could easily find by reading a well-documented changelog or a known issue of a recently updated external library.

Does it mean that I'm not responsible for the source code of the book? I just said the exact opposite: I am responsible and that's why I'm still doing my best to answer to all the compatibility issues I'm receiving and try to keep the GitHub repo updated even after six months. Yet the reader should also take his very own level of responsability: more specifically, he should understand how things work for a development book and how the passage of time impacts on the source code. No matter how hard the author can work to mantain it, the patches would never be fast or comprehensive enough to make the code always working on any scenario. That's why the most important thing the reader needs to do is understand - even before the book topics - the most valuable concept in modern software development: being able to efficiently deal with the inevitable changes. If you refuse to understand that, you are doomed.

Let's take this review published on Amazon.com two days ago:

2.0 out of 5 stars

Take note
By John on April 20, 2017
Format: Paperback
Code on the publisher website packtpub is from September 2016 and not updated. Publisher does have a github repo but it isn't updated for Visual 2017 and breaks Visual Studio 2017 Build system. Even in Visual Studio 2015 I couldn't get it to build even after all packages were loaded. It seems the author just wanted to be first to publish a book or otherwise he would maintain the code. Without working code you can't follow a top down approach to learning.

Hello John and thank you for purchasing the book. The project can definitely run with VS2015 and VS2017, you just have to follow the GitHub repo (which is updated quite frequently) and change a single (different) line of code for both scenarios. In details:

• For Visual Studio 2015: you need to specify a version+build for the core-js typings because they changed/broke them with the latest versions: there is nothing I can do about that, except publishing the workaround, which I did as soon as a viable one was found within the official thread related to the issue.
• For Visual Studio 2017: a viable answer was given more than 1 month ago, just few days after the VS2017 GA, which we're about to push into the GitHub repo as well: I will admit that we could be faster on doing that, yet I feel like you missed a great chance to Google it, as you wouldn't have to wait.

In case you run into other issues, feel free to send them by using the Packt Publishing website: I am still answering first-hand to all of these after six months and I've never let a single reader down (yet!).

I really hope you can positively evaluate our committment and adjust your review accordingly, because I don't think that the book deserves such an harsh vote.

I gave a bunch similar answers to other similar reviews there as well, mostly because they don't seem to be fair to me: it's ok if you didn't like the book, yet there's no "broken code" out there, period.

In a few days I think I'll also publish a Video Tutorial for those who still think that the source code is broken, however... that's it, at least for now. Happy reading and thank you for purchasing the book (even if you didn't like it in the end)!

Print Friendly & PDF Download