975 karma · joined May 19, 2014
The thing that always bugged me about node is the argument that using the same tools on the server as in the browser is somehow an advantage. That idea is not a given.
S: Each class can only do one thing, ever! Gotta do something else? Lets add more classes that all inherit from each other!
O: Heh, no one even remembers this one, like, ever.
L: Ya, thats how inheritance works! Right? Right...
I: Hey, I know how to create interfaces! Interface all the classes!
D: OK, just stick the DB connection into the constructer and we've got the D covered, yesssssh!
Really though, IMO SOLID is somewhat overblown in many cases. It is just a set of guidelines for good OO design not any kind of iron-clad rules.
Without any spelling mistakes.
Self-driving != Driverless
Self-driving cars is largely a technology problem, and one that we have made great advances in the last 5-10 years. Driverless cars are a legal/social/political problem that we have barely started to look at yet. Self-driving is a driving tool, like cruise-control, but the human driver is still ultimately responsible for the vehicle. Driverless on the other hand places the responsibility for the vehicle, and it's occupants, onto the vehicle itself. Driverless implies that you should be able to use it while you yourself are not capable of operating a vehicle. That is a massive step, and it is something that has never been done before. All other forms of transportation, despite advanced automation, still defers to a human in the end. I would say that true driverless cars is still a significant amount of time away, despite our advances in self-driving tech.
Yes, of course if you have great test coverage making changes to a monolith can be easier, but good test coverage and debt-riddled don't often apply to the same codebase! Lets be honest, if you are happy with your monolith codebase then there is no reason to rewrite for microservices. It is for those projects that you are not happy with the monolith code, where maintenance of the code IS scary, that the conversion makes sense.
And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.
To add to this: Very old custom software located on internal systems is one thing, imagine if you are relying on 15 year old web-based software from a vendor that no longer exists. How do you protect that?
Steve Furber on the creation of ARM, quite interesting.
ETA: yes it has debuggers for some languages as well, though none that I am using at the moment.
You will notice that I highlighted soap above, I do this because I believe it is the key factor often missed in discussions like this. You can argue that hand + water can make your anus appear cleaner than hand + paper, but without soap it is at best marginally more sanitary for your anus, and significantly less sanitary for your hand. There is a reason we clean our bodies with soap and water, not just water.