Gr8Conf 2014 in Copenhagen has been great. Three days filled with very informative talks, learning the latest from the Groovy community and mostly meeting all the people involved with the Groovy community, both project leads, members and users.

As always the first day of the conference is a university day with workshops that take 3 hours. This format is more of a hands-on experience. The day started with a Getting Groovy workshop to learn Groovy and play around with the language given by myself (Hubert Klein Ikkink).  Notes and the presentation can be found at Github. The following session we attended was Creating RESTful API's with Grails and Spring Security by Alvaro Sanchez-Mariscal.  After some startup problems, we were running out of time, so he did a live coding session. Where a rest service was created and login functionality added. I got some good ideas for our upcoming rest workshop. The final session of the day was really about playing: Getting Groovy With Lego Mindstorms EV3 by Ryan Vanderwerf. Ryan gave a small introduction about leJOS as an operating system for the Mindstorm computers, capable of running Java code. But we can also use Groovy and run the compiled classes on a Mindstorm computer. It is good to use the @CompileStatic annotation, because otherwise the application will be to slow to run. After the introduction Ryan had five Mindstorm sets we could play with. It was fun to write little code snippets with actions for the Mindstorm 'robot' to execute and then upload them to the Mindstorm computer and see the results. This was really fun and the Groovy support can be even extended by including builders for instruction. The project is open source and we can all contribute. Code from the talk is available at Github. At the same time the workshop about Unleashing the power of AST transformations by Cédric Champeau started.  The great thing about AST transformations is that you can change the bytecode, so non-groovy languages can use it. There are multiple phases where you can use your transformation, depending on what you want. These were some hard exercises. Homework! The workshop is also available online.

Continue reading →

Groovy adds a lot of extra methods to the File object to work with the contents or find and filter files in a directory. These methods are now also added to the java.nio.file.Path class since Groovy 2.3.

import java.nio.file.*

final Path newFile = Paths.get('output.txt')
if (Files.exists(newFile)) {
    Files.delete(newFile)
}


// Different ways to add content.
newFile.write 'START'
newFile.write System.getProperty('line.separator')
newFile << 'Just a line of text'
newFile.withWriterAppend { writer ->
    writer.println()
    writer.println 'END'
}


// Read contents.
final Path readFilePath = Paths.get('output.txt')

assert readFilePath.readLines().join(';') == 'START;Just a line of text;END'
assert readFilePath.filterLine { it.contains('text') }.toString().normalize() == 'Just a line of text\n'


// Work with Path objects,
// like with File GDK extensions with
// eachFile, eachDir, eachFileRecursive...
final Path root = Paths.get('.')
def paths = root.eachFileMatch(~/.*\.txt$/) {
    assert it.toFile().name == 'output.txt'
}

Continue reading →

Writing documentation with Asciidoc is such a treat. We can add markers to our code where we want to explain something in our code. The markers have numbers and are enclosed in < and > brackets. The explanation for the markers follows a code listing in a callout list. Here we use the same marker and add extra text to explain the code. We can put the markers in comments in our code so we can use the markers in existing code.

Suppose we have the following piece of documentation where we add two markers (in comments) to some Groovy source code:

Continue reading →

Writing technical documentation with Asciidoc and Asciidoctor is so much fun. Especially the include macro makes inserting changing content, like source files, a breeze. We only need to maintain the original source file and changes will automatically appear in the generated documentation. We can include only a part of source file using tags. In the source file we add a comment with the following format tag::_tagName_[] to start the section. We end the section with end::_tagName_[]. Now in our Asciidoc document we can indicatie the tags we want to include with include::_sourceFile_[tags=_tagName_].

Suppose we have the following Groovy source file Sample.groovy. We want to include the method hello() in our technical documentation:

Continue reading →

Since Groovy 2.1 we can use a nice builder syntax to define customizers for a CompileConfiguration instance. We must use the static withConfig method of the class CompilerCustomizationBuilder in the package org.codehaus.groovy.control.customizers.builder. We pass a closure with the code to define and register the customizers. For all the different customizers like ImportCustomizer, SecureASTCustomizers and ASTTransformationCustomizer there is a nice compact syntax.

In the following sample we use this builder syntax to define different customizers for a CompileConfiguration instance:

Continue reading →

Lately I've been doing some development of a turn based browser game using node.js and Redis. Being intended to run on multiple node.js instances and each instance also being able to "autoplay" for afk users, it was clearly lacking a semaphore of some sort to make sure only one action at the time would be processed per game across all nodes. With Redis being my central persistence component I figured this was a good time to dive a bit deeper in the capabilities of Redis when it comes to locking. As it turns out locking makes a great use-case to learn about the true power of some of the most basic Redis commands. So while this blog post is definitely about locking with Redis, its actually more about how common Redis commands can be used to solve some pretty complex issues. Generally locking patterns can be divided into pessimistic and optimistic. In this blog I'm focusing on the creation of a general purpose (pessimistic) lock/semaphore that could be used for anything that requires limiting access to a resource or piece of code really. The third example also uses the build-in optimistic locking capabilities of Redis to solve to a race condition issue. Keep in mind though, that in either case it is the client that is responsible for maintaining the relation between "the lock" and "the resource". Lets start with the oldest and most common locking pattern and work our way through from there.   1. SETNX/GETSET based locking The commands of choice for the first example (works on all Redis versions): SETNX only sets a key to a value if it does Not eXists yet. GETSET gets an old value and sets it to a new value atomically!

var redis = require('redis');
var nameOfKeyToLock = 'the_lock';
var timeout = 10000;
var retry_time = 500;

var doLocked = function(client, nameOfKeyToLock, callback){
  var lock = function() {

    var newLockValue = Date.now() + timeout;

    //SETNX command
    client.setnx(nameOfKeyToLock, newLockValue, function(err, result){
      if(result === 0){
        client.get(nameOfKeyToLock, function(err, currentValue){
          currentValue = parseFloat(currentValue);
          if(currentValue > Date.now()){
            //lock still valid, retry later
            return retry();
          }

          newLockValue = Date.now() + timeout;
          //GETSET command
          client.getset(nameOfKeyToLock, newLockValue, function(err, check){
            if(currentValue == check){
              //old value was still the same, so now the lock is ours
              return callback(unlock);
            }
            retry();
          });
        });
      } else {
        //no lock was present, we now got it
        callback(unlock);
      }
    });

    var unlock = function(after){
      if(newLockValue > Date.now()){
        client.del(nameOfKeyToLock, function(){
          console.log('released lock');
          after();
        });
      } else {
        after();
      }
    };
  };
  var retry = function() {
    console.log('scheduling retry');
    setTimeout(lock, retry_time);
  }
  lock();
};

Continue reading →

For many years now it has been good practice to write unit tests for your source-code. And also to use test coverage reporting to see how much of your code is covered by tests. Although line + branch coverage reporting is quite useful, it doesn't tell you how good your unit tests actually are. Hence it's even possibly to achieve 100% coverage without even a single assert in your tests. Being interested in better ways of testing I attended the "Mutation testing" workshop during this years Joy of Coding conference. Mutation testing is a radical different approach of executing and analyzing the result and coverage of your unit tests. Instead of measuring how much of your code is "accessed from" your unit tests it determines how much of your code is actually "tested by" your unit tests.

The basic idea behind mutation testing is to make a small change (a mutation) to the (byte) code and then execute your tests to see if it is detected by the unit tests. Possible mutations are altering a ">" into ">=", replacing "++" with "--" and removing "void" method invocations. Each mutation therefor creates an altered version of your code called a "mutant". Prior to the actual mutation testing our unit tests first need to be executed against the original code to see if no tests are failing. Then the unit tests will be run for each "mutant" (making it possibly very time consuming) the see if:

Continue reading →

NOTE: this post updates an earlier blog post written for version 0.8 of the Karma test runner.

For my current project we are using Maven to build our AngularJS application. Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage. In this blog post we describe how to integrate version 0.10 of the the Karma test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.

Continue reading →

When we convert data to JSON or XML (or any other format actually) in our Grails application we can register custom marshallers. These marshallers must contain the logic to convert an input object to a given format. For example we could have a book class and we want to convert it to our own JSON format. We have different options in Grails to achieve this, but for now we will create a custom marshaller class CustomBookMarshaller. This class must implement the ObjectMarshaller<C> interface. The generic type is the converter the marshaller is for and is in most cases either grails.converters.XML or grails.converters.JSON. Next we must make sure Grails uses our custom marshaller and we must register it. In the Grails documentation is explained how to do this via grails-app/conf/Bootstrap.groovy where we invoke for example JSON.registerMarshaller(new CustomBookMarshaller()). Or via grails-app/conf/spring/resources.groovy where we must write an extra component with a method annotated @PostConstruct where JSON.registerMarshaller(new CustomBookMarshaller()) is invoked.

But there is also another way using org.codehaus.groovy.grails.web.converters.configuration.ObjectMarshallerRegisterer. This is a Spring bean just for configuring extra marshallers. The bean has a priority property we can use to define the priority for this marshaller. Grails will use a marshaller with the highest priority if for the same class multiple marshallers are defined. We can assign a marshaller to the marshaller property. And finally we must set the converter class, for example grails.converters.XML or grails.converters.JSON with the converter property.

Continue reading →

We can include the version property of domain classes in rendered JSON or XML output. By default the version property is not included in generated XML and JSON. To enable inclusion of the version property we can set the configuration property grails.converters.domain.include.version with the value true. With this property for both XML and JSON the version property is included in the output. To only enable this for XML we use the property grails.converters.xml.domain.include.version and for JSON we use the property grails.converters.json.domain.include.version.

The following snippet is from grails-app/conf/Config.groovy where the properties are defined:

Continue reading →

Since Grails 2.3 all ${} expression output is automatically escaped on GSPs. This is very useful, because user input is now escaped and any HTML or JavaScript in the input value is escaped and not interpreted by the browser as HTML or JavaScript. This is done so our Grails application is protected from Cross Site Scripting (XSS) attacks.

But sometimes we do want to output unescaped HTML content in the web browser. For example we generate the value ourselves and we know the value is safe and cannot be misused for XSS attacks. In Grails 2.3 we can use a new raw() method in our GSPs, tag libraries or controllers. The method will leave the content unchanged and return the unescaped value to be displayed. Alternatively we can use encodeAsRaw() on the content we want to leave unescaped. Finally the encodeAs tag accepts Raw or None as values for the attribute codec and will return the unescaped value.

Continue reading →

Since Grails 2.3 it is very easy to define RESTful URL mappings for a controller. We can use the resources and resource attribute and use a controller name as the value. Grails will then automatically create a couple of URL mappings. Suppose we use the following mapping in grails-app/conf/UrlMappings.groovy: "/api/users"(resources: 'user'), then the following mappings are automatically created:

"/api/users/create"(controller: 'user', action: 'create', method: 'GET')
"/api/users/(*)/edit"(controller: 'user', action: 'edit', method: 'GET')
"/api/users(.(*))?"(controller: 'user', action: 'save', method: 'POST')
"/api/users(.(*))?"(controller: 'user', action: 'index', method: 'GET')
"/api/users/(*)(.(*))?"(controller: 'user', action: 'delete', method: 'DELETE')
"/api/users/(*)(.(*))?"(controller: 'user', action: 'update', method: 'PUT')
"/api/users/(*)(.(*))?"(controller: 'user', action: 'show', method: 'GET')

Continue reading →