I’ve recently been pulled into a discussion about the effect of contracts in distributed systems both technically and regarding team communication. As usual, 140 characters are quite a limitation for reasonable discussion I thought I’d summarize my ideas here.
Recently, I stumbled over a blog post by Jonathan Channon explaining how he got to realize that hypermedia APIs are not some magical thing but rather a pragmatic approach to reduce coupling between services. Also, I’ve been traveling conferences with a talk on Domain-Driven Design and REST recently that covers the aspect of hypermedia as well and features an — as I think — rather nice example of how effective hypermedia can be when building distributed systems. I’ll come back to the example in a bit but let’s start with some fundamentals.
I’m quite frequently getting pulled into discussions on Twitter about the different flavors of Dependency Injection. Also, I’ve repeatedly expressed my distaste for field injection but as Twitter is not the right communication channel to give an in-depth rational about my opinion. So here we go.
Yesterday evening, a few tweets made it into my Tweetbot column listening to tweets related to Spring Data. The one raising my attention was pointing to a blog post creatively entitled “Spring Data MongoDB - A Mismatch Made In Hell”. As the title already suggests, it contains a rather rigid critique of the features and design approaches we chose for the MongoDB module in the Spring Data project. The post has a very harsh tone and is equipped with a whole bunch of either deep misconceptions or deliberate refusal to see facts, which I found quite surprising. Let me go through it bit by bit and clear the dust it created.
The process of turning code to solve a problem at hand that might look sufficient at the first glance into rock solid, quality assured, perfectly documented and extensible code. This process might consist of a complete rewrite of the code that originally made it into the process (Karma level 0) to only minor modifications (Karma level 10), usually depending on how often the author of the code to be jürgenized has made it through the process yet.
The term originates from Jürgen Höller, Spring framework lead developer, coining this kind process to deal with code contributions about to make it into the Spring framework. To get your code into the core codebase, you and the code get jürgenized.
Nowadays the term usually relates to the process of code quality assurance, in particular around Spring eco-system projects.