Microservices are the right solution for true Monoliths

I’ve come across many people who don’t like Microservices. They complain that it fragements the code and adds potential network failures. These people are not stupid and they are not wrong. They just haven’t worked with a true monolith (even if they claim they have).

Microservices do add network latency and there are more potential failures. It does make transactional operations less reliable. It does add serialisation overhead. It does divide teams or offer the chance to split the solution over too many technologies. It does mean you’re app has to cope with multiple different versions in production. It does mean that integration testing scope is limited to smaller individual pieces like unit tests and not true end-to-end tests. It adds overhead in terms of the beaurcracy of adding or changing contracts. It adds documentation and the need to use Swagger endpoints everywhere! It just fundamentally adds more code and therefore a greater chance of bugs.

However, all that overhead is worth it, if your app is so unmanageable it takes 6 hours for the test suite to run. It is worth it, if a series of breaks had made the business enforce some sort of bi-weekly release schedule on you. The knock on effect of that bad decision is that each bi-weekly release is now bigger, more risky, and potentially causing even more failures. You have a monolith if you branch to make a large refactor and by the time you come to merge it back to master, master has moved on by 50 commits by 10+ people that make you feel like you’re back at square one. You have go around to people and ask how to sensibly merge the changes because you don’t know anything about what their code does because they’re in a completely different business domain to you, the acronyms are completely foreign and you’ve never met the person. The project is so large that each Agile team have adopted their own coding guidelines within the same codebase.

In those situations, Microservices are a real way out. Having your system as a collection of smaller microservices means you can drop a lot of these troubles.

“Monolith” does not mean a shitty product, an unreliable product, a clunky slow product or an old product with a lot of technical debt. It means one so frought with edge cases, fear and uncertaintly that even small, isolated and obvious bug fixes are delayed or forced through tons of beaucracy for fear of breaking the critical paths of the application.

Roughly how Counterstrike Matchmaking Ranks work

I’m answering this question because it comes up often and many find this answer useful.

The algorithm behind Valve’s matchmaking for Counterstrike is closed source. It’s a secret and they don’t want you to know. They don’t want you to know how it works so you don’t cheat the system. If defusing the bomb helps your rank they don’t want you shooting team mates for it. It’s an intentional black box.

When people ask in forums how it works, others often say “no-ones so anyone who answers is lying” but those people are being ignorant. We don’t know how gravity works but we still don’t fly out into space. Valve have confirmed that the algorithm is based on a publicly known algorithm called “Glicko 2 [PDF]“. With that, and with experience of using the system as a community we have some understanding of how it works and this is generally useful enough to give you a picture.

Continue reading “Roughly how Counterstrike Matchmaking Ranks work”

Comparing PDF Binary Data

If you generate a PDF using iText5 twice you get different results. The creation date, modification date and ID are different. This means that it’s difficult to write a test that is repeatable. It’s also not ideal to mock out the whole PDF generation from a library that’s sole purpose is to manipulate PDF as it gives no confidence the code works.

I decided to read the PDF Reference which documents the PDF format on disk to figure out how to write a binary comparison function that ignores the differences.

Continue reading “Comparing PDF Binary Data”

Vim as a Scala IDE

I’ve been using VIM as my Scala IDE for the last year and I can report I’ve had a very positive experience with it. Below I have a short table of what IDE features I use and what plugins offer those features. Before you read that stuff however you need to align your perceptions and expectations with mine. I’ve used vim to write Python and Perl every workday for 8 years. I have put forth considerable effort to make vim work for me as a Scala IDE. It didn’t happen overnight. Python and Perl are weakly-typed. Many IDEs simply can’t offer “Jump to definition” in Perl code accurately as there’s no strict rules on where `$obj->$method` would even go without evaluating the program at runtime. My expectations for a productive environment are probably far less than those coming from IntelliJ or Visual Studio would hope for. You have been warned.

Continue reading “Vim as a Scala IDE”

Adding a “scrollmarks” feature to KDE’s Konsole

Most of them are successful but rarely see the light of day outside of my work machine. They only have to help me to be worth it. I’ve hacked Konsole in a number of ways, Bash, DWM and generally anything that gets in my way. My desktop setup is incredibly unique due to that fact that quite a lot of software I’ve compiled solely for myself now.

Continue reading “Adding a “scrollmarks” feature to KDE’s Konsole”

The Terminal with Jira Integration (A KDE Konsole Hack)

I believe the following statements:

  • I am a professional software engineer
  • I should be as efficient as possible
  • Modifying other peoples’ software is easy.

People often deride the benefit of Free and Open Source Software (FOSS) as futile with the argument that no one really reads, modifies or understands the software. I appear to be something of an exception.

Continue reading “The Terminal with Jira Integration (A KDE Konsole Hack)”

Why now is a good time to buy a NAS device

For this article I’m going to use the term Cloud and Cloud computing to mean “an awesome service” that is available from any computer and hassle free, which is super convenient. I understand why people use them. As I just said… they’re awesome. I’m going to point to two good ones. Gmail and Dropbox. Get your email or files anywhere you want. Very simple, very useful.

Continue reading “Why now is a good time to buy a NAS device”

Liberating myself from Google and others

I’m a developer, general do-it-myself IT guy and linux hacker-er. I hate the direction the Internet is taking. Free Email, as long as it can be used to profile your habits. Facebook, An intelligence agencys’ photo database and tracking system. Free photo sharing services but you don’t own the copyright. File sharing cloud services but you’re effectively locked in as you lazily upload 80GB over 10 years and can never get it out again. These things bother me as an average developer because they hinge on unnecessary sacrifices. I could host these services myself. I don’t mind paying someone else, I just wish my money were enough and they could actually be trusted. Anyway this blog post isn’t a rant about the evils of cloud computing, just a recent meandering experience I’ve had in making myself less dependent on certain services. I can do some of it myself, so I did.

Continue reading “Liberating myself from Google and others”

Making code reviews successful

Code Reviews are excellent and important. They increase the quality of the code, they help the team share ideas. They allow knowledge transfer and in some companies coding standards never evolve without them.

However, code reviews can be a little problematic at first in some companies and since they involve critical feedback the developers need to have the interpersonal communication skills to pull it off. They need to be diplomatic and tactful.

Here are my tips for pulling off good code reviews:

Continue reading “Making code reviews successful”

Agile breakdown impedance

Breakdown Impedance is the term I’ve just coined for a problem that I’ve complained about in my Agile retros. Impedance is a word most commonly known from other scenarios where, for example, the way your database implements a type isn’t the same as your programming language. Thus you have a small area of casting work to do or grey area you need to investigate. It could be the fact that your doubles can’t be as accurate as PostgreSQL’s unbounded numeric field or it could be the way that Dates in an XML file need subtle alteration before they can be safely used.

Breakdown Impedance are the pulling factors that complicate the task of breaking an Agile story in to smaller parts. It’s the blurry bit that slows the process down a little and involves everyone in the team having their own ideas. The motivators for breaking things down in Agile are..

Continue reading “Agile breakdown impedance”