Welcome to The TEK Blog

Hello and welcome to the TEK blog.
This is my blog for anything I find remotely useful and want to share with the world.

Working software over comprehensive documentation

The agile principle of working software over comprehensive documentation is one which I feel very strongly about.

when moving in a quick paced agile environment, keeping documentation up to date can quickly become a burden on developers.

Let’s be honest, any developer worth his salt would rather write software and not documentation. If you’ve got developers that love writing documentation then you should be asking serious questions as to why.

Documentation should relevant and live as close to working software as possible.

What does relevant mean? When is documentation useful?
Documentation goes right back to how you are building your system the tech you are using and the code you are writing.

Self-documenting code should be a must. This doesn’t mean Java-doc. This means APIs that are simple, stateless and readable.

Tests should become a vital part of how your system is documented. If I want to understand how part of a system works I should be able to look at the unit tests and have a understanding of what has been developed.
Do not spend time writing docs/Wikis/whatever when the you should be spending time making sure you code is readable.

When developing I’ve found that short lived documentation which answers a specific need is where you get the most benefit. For example, if you our developing a API with a third party developing to a agreed API contract before hand can be a very good way to unblock both parties. Once the API is developed your can then look at the following;

I’ve recently introduced Swagger into a project which involves a number of micro-services based on Java 8 and Spring boot. We’ve used Swagger (http://swagger.io/) and the Spring Fox (http://springfox.github.io/springfox/).

We’ve found the foot print is extremely low (dependencies and a config file) but the benefits of having this automated means our our documentation lives right next to our working software with minimal intervention.

Problems with Grails Testing

Here’s a repost of a question I put on Stackover Flow

I’m trying to use test support classes within my tests. I want these classes to be available for all different test types.

My directory structure is as follows;


I have test helper classes within the /test/support folder that I would like to be available to each of the different test types.

I’m using GGTS and I’ve added the support folder to the classpath. But whenever I run my integration tests running ‘test-app’ I get a compiler ‘unable to resolve class mypackage.support.MyClass

When I run my unit tests from within GGTS the support classes are found and used. I presume this is because the integration tests run my app in its own JVM.

Is there any way of telling grails to include my support package when running any of my tests? I don’t want my test support classes to be in my application source folders.

Update: Now been answered.

Grails Remote

When setting up my test data for a functionally test I found I was getting errors when trying to save a domain object.

def setup() {
  person.save (flush:true, failOnError: true)

This is because i’m trying to have a domain object outside of the Grails application. Which you cannot do.
There is a plugin which provides a solution to this. The Grails remote plugin can be used to remote control a Grails application, usually when functional testing.

I’m using Grails 2.4.3 and Grails Remote-control 0.5.

Add the plugin using:

compile ":remote-control:1.5"

then in your test you can do this;

PersonFunctionalSpec extends GebReportingSpec {
	def remote = new RemoteControl()
	def setup() {
		def person = remote {
			def Person person = new Person(name:"JohnJoe")
			person.save(flush:true, failOnError: true)			

The closure passed to remote will be executed within your grails application. But only when running test-app unless you explicitly tell it to run for different targets.

If your using Grails security make sure you have the following in your Config.groovy

grails.plugin.springsecurity.controllerAnnotations.staticRules = [
	'/grails-remote-control': 		  ['permitAll']

Joda DateTime and Grails Persistence

When using joda DateTime objects in your domain classes there are a few things to note if using Hibernate 4.

After following the steps in this documentation you may still get the following exception:

org.springframework.dao.DataIntegrityViolationException: Hibernate operation: could not execute statement; SQL [n/a]; Value too long for column "DATE_CREATED BINARY(255) NOT NULL":

The Joda grails plugin states the following

There is a version 2.0 of the Usertype library but it requires Hibernate 4 so is not currently compatible with Grails.

Of course, this is out of date with Grails 2.4.3. So upgrading using

runtime "org.jadira.usertype:usertype.jodatime:2.0.1"

solved my problem.

Grails Joda plugin

The Grails Joda plugin (http://grails.org/plugin/joda-time) is easy to include in your project.
Just add

compile ":joda-time:1.5"

to your BuildConfig.groovy.

However, try using DateTime within your domain classes and you’ll run into problems. Using GGTS it will not import DateTime for you (annoyingly only finding java.util.Formatter.DateTime)

In order to use Joda classes in our domain add the following dependency.

compile "org.jadira.usertype:usertype.jodatime:1.9"
1 2 3 16