Everyday Software Development
Everyday Software Development
Whenever you have a domain object, data transfer object, parameter object or any other object that can’t be instantiated with constructor parameters only, you need to create a builder for its class.
The great thing about Java is that it is statically typed so a builder can give you compiler errors if you forget to set the compulsory parameters. If you use the builder in this pattern, you also get a very fluent interface that imposes order on the parameters. When using the builder, your IDE will suggest the next parameter to set.
Most of you have a relational database involved in your persistence. As soon as your first version has been set in use, you can’t change the database schema as easy anymore or you might lose valuable production data.
At the same time, continuous delivery demands that there should be as few manual steps as possible. See here for motivation on continuous delivery.
You no longer have a few database instance, there are numerous for different levels of testing and every developer nowadays run a personal database. To keep track of all database instances and keep them updated becomes a steep task.
To tackle this, we started using Flyway as a tool to manage our database scripts. Our applications migrates the database automatically on startup so we get a hands-free solution that will guarantee that the code and database schema is in sync.
Yesterday we ended our second two-week sprint and on the demo, besides showing the system, we could do some bragging about test coverage using our Sonar dashboard. We also could show Fitnesse tests at system level that implements the specification by example technique, or like some say, executable requirements.
What is the purpose of the @Ignore annotation in unit testing?
Either a test will be green and everything is fine or it is red so you fix it before commit. So if there is an ignored test, it is the same thing as dead code and we know what to do with that: delete it! Keep the code clean! read more »
I had taken on to facilitate a retrospective for my colleagues’ team. They wanted a different retrospective than the usual. So we borrowed Crisp’s office and used Jimmy Cards!
The group was around 15 persons from two teams. They all knew each other well which I believe is crucial as the questions on the cards can be challenging.
In this post I’ll give you the recipe which Jimmy and I came up with for this particular retrospective.
Have not all of us been in a spot where we feel an urgent need to fix some quality such as performance or availability, which takes a change in the architecture for effect? And yet we are pushed to work on new features instead?
There is a chasm between the tech side and business side that has to be bridged before a sound dialogue about system architecture can take place.
Today I decided to update my canned wicket test examples to the latest version of Wicket.
I still think Wicket is a really nice web framework for the following reasons, primarly.