I think this article explains really well: https://martinfowler.com/articles/mocksArentStubs.html The article is long, but it has lots of interesting discussions. In particular these two: Design Style and Coupling Tests to Implementations which I felt first hand in the projects/companies I've worked for in the past Anyway, the main point for me in the discussion about Stubs vs Mocks is: there is a difference in how test results are verified: a distinction between state verification and behavior verification. I fit in what Fowler calls the classical approach I find it easier to just care about the final state of test (and not how this state was derived). He sums it pretty well: With mockist testing, writing the test makes you think about the implementation of the behavior - indeed mockist testers see this as an advantage. Classicists, however, think that it's important to only think about what happens from the external interface and to leave all consideration of implementation until after you're done writing the test. And in fact that is exactly what I do (think what happens from outside), it just happens to be natural for me to think that way.

I did. I had to reverse engineer a couple of things a long time ago. To understand how your computer you can write a toy OS (there's a lot of resources to help you). Here's mine: Toy Realmode OS IMHO, assembly is just a piece of the puzzle, you gotta understand how things work together. Some questions I had out of sheer curiosity in the past: How is the structure of an .elf or .exe file? How this for loop is implemented in the binary file, what sort of op codes the compiler use, how will it optmize the code? (Programs written in C ) How does the kernel handle memory management? If you want to take a look how everything fits together I recommend this book , it will teach you lots of interesting stuff.

Best testing library for me currently is avajs it doesn't get in your way, it's really simple conceptually and incentivates good practices (this is really basic, but I've had to deal with lots of code that the tests were a mess. IMHO it's really important to make your tests indepent and run them in parallel, because your test suite grows overtime). For end-to-end testing: Cypress is pretty amazing too (check the code ), really powerful and simple to use. Here's a real world project that uses it: Spectrum - Simple, powerful online communities But if you want to do things by hand, you can always use puppeteer

It depends. If you can, keep things simple. But if you have a more complicated scenario (hundreds of microservices, lots of different teams, etc), you probably should consider a couple of things when gluing your services together: How will the messages evolve over time? Are your microservices written in different languages? Is there good library support for all of them? How will you handle the messages flow? Retry on errors? Circuit-break? Tracing for debug purposes? What guarantees does your transport offer? Do you need to be concerned with duplicated messages? It's hard to isolate communication (transport channel and message format) from other challenges inerent to microservice architectures such as: Traceability, monitoring, circuit-break, load-balancing, etc. It's desirable that your tools play well together to solve these problems. Details: (1) Your services will change with time and when it happens how the services will handle it? The changes are backwards compatible, do you need to orchestrate the deployment? (i.e redeploy both services with the new message format?) Is there a possibility that your service will receive messages in the old format, if yes what happens? (is your service backwards-compatible?) Some communication schemes may help you with the questions, above: Avro, gRPC (protobuf), Thrift have their our evolution scheme. Here's a good article about the topic: Schema evolution in Avro, Protocol Buffers and Thrift (2) Why does it matter if your services are written in different languages? Well, if you need to write a library for each language to standardize the communication, that's a lot of effort. If everything is in the same language, you can share your communication library. For example: If you are in the JVM, you can use something like Finagle , if you have lots of teams writting stuff in different languages you could use something like Istio (3) If you have 200 microservices talking with each other in production, you need standards and order. For example: How do you handle errors? Is there a common error format? Retrying/resending messages is supported in the transport layer or you have to do that on the application side? Does it make sense to separate transport errors from application errors? (4) If you are using some sort of message broker or queue, how are the messages routed? Is there any need to add an deadletter queue? If the messages may be delivered more than once you need some sort of idempotency mechanism.

Running Linux on Windows I run Archlinux on Windows using VirtualBox, it works great. In particular it's really convenient to "Save State" instead of turn-off the machine, it let's me get back to work exactly where I stopped. Also I can change hardware (notebooks) without much fuss or overhead to install everything again. Why I choose Archlinux I like to know my machine: what is installed and why and where is everything; no-magic, no-bloat. Also, especially inside the VM, there's no need for lots of packages, for instance I do not have a sound driver. Also, arch's package system is neat for building stuff from source (which is something I often do because I like to peek at code in the wild and guess how stuff works) and keeping everything up-to-date (No outdated-packages)