A single database may be the right choice, even in a microservice environment.
If you have been reading about microservices and databases, most sources seem to (loudly) agree that each microservice should use its own database. This ensures that each service owns its own data, and helps keep the services decoupled. The services then typically communicate with one another using a service bus, with the messages being part of the services’ public API.
However, having separate databases is not a necessary requirement for achieving decoupling. Given some prudent design decisions, a single, shared database can alleviate a lot of the pain points of multiple databases while still allowing control over a service’s public/inter-service API.
What ensures a good separation between services is data ownership (data is only modified by one service) plus well-defined, contractual public APIs. A database can be just another inter-service API, not too different from service bus messages.
Beware weakly typed APIs when you are used to strong compile-time safety.
Weakly typed APIs can bite you, particularly when you’re using a language like F# where you’re for the most part blessed with strongly typed APIs. Thankfully, strongly typed wrappers are often one-liners.
Let F# types guide you to better user experiences and stopping terrorists.
Boolean logic is central to many business rules. But sometimes it’s not enough to know whether a chain of conditions evaluates to true or false; we might want to know which of the conditions failed. F#, unsurprisingly, lets us model this in a very succinct, composable, and completely type-safe way. But there are pitfalls – sometimes, a seemingly simple and pure function just won’t cut it.
Review of “The Mythical Man-Month” by Frederick P. Brooks, Jr.
One cannot venture far into the world of software engineering literature without hearing about The Mythical Man-Month by Frederick P. Brooks, Jr. The book is consistently hailed as a classic, so in my quest to grow as a software practitioner I decided to shell out and see what all the fuss was about. Unfortunately, being written in 1975 (re-issued in 1995 with minor changes to the original material), it seems so out of date now that I doubt it can have more than academic appeal.
Review of “Facts and Fallacies of Software Engineering” by Robert L. Glass.
Software changes at an accelerating pace. People, on the other hand, stay the same. That’s why some software engineering books are timeless classics: They speak to the human rather than the technical side of development. Robert Glass’s Facts and Fallacies of Software Engineering seems to be hailed as one such classic, and I too found this a highly rewarding read.
Review of “The Pragmatic Programmer” by Andrew Hunt and David Thomas.
The Pragmatic Programmer: From Journeyman to Master promises to make you a better programmer with around 70 concrete tips covering many different aspects of software engineering. But while I would have hoped for 70 deeply practical and thoughtful tips, many of them aren’t really that great. Pragmatic Programmer lacks depth, and its age (15 years) means that some of its tips are not nearly as helpful today.
Some thoughts on how to test the functionality of a WordPress widget.
I recently finished developing my very first WordPress widget. It’s called GR Progress, and it shows books from your Goodreads shelves together with their reading progress (which, to my knowledge, no other Goodreads or WordPress widgets can do). In this post I want to talk about how I went about “unit testing” the widget.
Review of “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.
One of my earlier functions was a true abomination.
It was 250 lines long, accepted 18 input parameters, and was nested up to 9 levels deep with highly complex conditions at all levels. It’s not only gross; it’s horrible, and I wish it would just go away. But it does its job, and I would need to put in significant effort in restructuring the whole program if I wanted to do something about it. And you can bet I’m not touching it now, not with a ten-foot stick.
The worst part? It’s the central cog in an equally abominable class (written entirely by yours truly) producing these plots, which are still used during scientific rocket launches from Andøya to determine the optimal moment for pressing the big red button.
Soon I’ll start working with Xamarin. I just have to learn C# first.
I’ve heard it said that you can’t get a job doing something you’ve never done. What a load of equine droppings.
What follows is mostly a personal story of how I switched careers from academia to software development without really knowing the relevant technologies. More specifically, it’s about how I got a job as a C#/VB.NET/Xamarin developer when I started toying with those technologies just before the interview.
Some edits I made to the Wordpress theme and plugins I’m using
When you’re into web design, of course you can’t simply install WordPress and be done with it. The current default WordPress theme, Twenty Sixteen, is nice and clean, but a few tweaks here and there made it look a bit better and even less noisy.