January 17, 2017

New Book: Secure by Design - now in early access program

The blog posts have been sparse but I've still been writing a lot lately.

After years of thoughts, discussions, and trying out ideas in real projects, we decided to formalize our views on software security in the form of a book. A privilege to write a book together with such great co-authors as Dan Bergh-Johnsson and Daniel Deogun.

Today is a big day because the first early drafts of the book is now released to the public through the Manning ”early access program” (MEAP). We still have a long way to go, and a lot of hard work ahead of us, but I'm confident it'll turn out just as good as we hope - or better.

If you’re interested in reading a book in-the-making, or just want to ’pre-order’ the finished book, you can get it for 50% off until January 24 (2017) if you use the discount code "mljohnsson" (all formats)

June 26, 2015

Continuous Delivery and Conway's Law

The challenges of continuous delivery

Continuous Delivery is more and more becoming a mainstream practice in how to create and deliver software. The reason for this are the numerous benefits this practice will have on the business as a whole. But as with most other things there is no free lunch and these benefits do not come without a price. An example of this is the fact that there are many challenges you may face when trying to implement continuous delivery in an existing organization. My colleague Daniel Deogun and I have spent quite a lot of time working with implementing continuous delivery practices within organizations. And in doing so we started to notice some reoccurring patterns among the challenges that organizations run into when moving towards continuous delivery.

March 25, 2015

Custom accessors with IntelliJ's new code generation features

The problem with getters

If you know your Java history, you will also be familiar with the naming conventions for accessors and mutators that was introduced, and defined, by the JavaBeans specification. (i.e. the good ol' getters and setters) This naming convention became more or less a de facto convention for accessor and mutator methods in Java. Even for objects that had no intentions whatsoever to be a java bean.
And because it was such a widespread naming convention many frameworks and libraries started to rely on that convention in order to provide useful features. Luckily, many of the popular frameworks and libraries that are used today no longer require these naming conventions in order to function.

That means that today it is perfectly fine to write code like person.name() if it makes more sense to you and you will not be forced to write person.getName() just in order to get your tooling to work.

April 17, 2014

Clean code - why it matters

Well designed and thought through code is something every software professional should take seriously as it is an enabler for so many important properties of software design. It will help you in areas such as testability, maintainability, modularity, sustainability, readability, security, time-to-market and so on. The list of positive side effects of creating well designed code is neverending.

If you are new to the term clean code, then Bob Martin's book Clean Code is a good place to start to get an inroduction to what it means. In his book, Bob Martin shows many examples of what clean code can look like and you may not agree with all of them but the importance is to understand the overall concept and purpose of the term. Other areas to explore in terms of code design is domain driven design (DDD) and test driven development (TDD).

In my view, well designed code is the foundation of everything that we do as software professionals. All contemporary best practices that we apply daily are dependent of well designed and expressive code. Whether it be TDD, DDD, domain driven security, continuous integration, scalability and so on. A poorly designed code base that is nothing more than a big mess of code will never enable you to succeed in any best-practice, at all. Period. This may sound a bit harsh but in the long run I really do believe that well designed code is the base for everything else.

June 11, 2013

MapReduce made simple with Akka

As you probably already know, Akka can make your life a lot easier when it comes to things like concurrency and scalability. A very typical use case for starting to use Akka is when you have a computation or algorithm of some sort that lends itself to parallelizing. Implementing that with just core Java is cumbersome, error prone and it will feel like you are reinventing the wheel every time you do it. Akka will, for example, enable you to take advantage of all the cores in your CPU, or maybe even the CPUs of several machines, without having to worry about the evils of things like threads, lock, semaphores etc., and not to mention the hassle of trying to distribute the computations.

February 12, 2013

Java-based configuration in Spring - An introduction

If you have not started using Java-based configuration in your Spring projects you really should take a look at it since it is a very valuable tool to master. Java-based configuration has been supported right out of the box since Spring 3.0 so it has become quite complete by now. (with the stable release being 3.2.x at the time of writing this post)
Personally, I have found that I hardly ever use any XML configuration files in Spring projects that I create nowadays. And as a side note, if I am also able to use an application server that supports Servlet 3.0 I can even get rid of my web.xml file. Thus eliminating a big part of the XML-based configuration usually needed.

Ok, but why? You might ask. Well, if you think about it there are a lot of benefits of having your configuration in code instead of in XML.

September 6, 2012

Not using Spring Data yet? Well, you should, and here's why.

In pretty much every single project you will ever work in there will be a need to persist data. Typically you will use things like JPA, Hibernate, and similar APIs. Using these APIs is a huge step forward compared to the good ol' days when we didn't have things like O/R mappings and nice transactional APIs but had to fiddle around with JDBC connections, rolling back transactions, reading from result sets and whatnot.1 But still, pretty much all of the work you do every time you create a repository class for your entities is plumbing. You are creating nothing but boiler plate code. And time spent on boilerplate code is time wasted, because you are writing code that adds no real value but still needs to be tested and maintained.

July 3, 2012

Mockito: Default values and how to get more out of them

The problem

A while ago I had an interesting discussion with two of my colleagues, Dan Bergh Johnsson and Daniel Deogun, about how to change the default return value of unstubbed methods in Mockito. The background for the discussion was that by default, Mockito returns default values for unstubbed methods and these default values are usually good enough. In some cases that default value will be null and if the code being tested tries to use the returned null value it will cause a nullpointer exception. The stack trace of that exception will quite easily give away that the cause was an unstubbed method.

However, if the tested code calls an unstubbed method and, instead of using the null value directly, stores it and uses it later. Then the stack trace of the nullpointer exception will no longer reveal that the cause was an unstubbed method but will point to some random code line that can be far away from where the unstubbed call actually took place. When this happens it usually takes some time to figure out what the root cause was. Lets take a look at how we would approach this situation and how we can get a more informative error when it occurs.