JDriven Blog

Groovy Goodness: Use Custom Template Class with MarkupTemplateEngine

Posted on by  
Hubert Klein Ikkink

Since Groovy 2.3 we can use the new MarkupTemplateEngine to generate XML/HTML content. The engine compiles the template for better performance and optionally provides type checking on model attributes used in the template. We can configure the template engine to use a custom base template class instead of the default BaseTemplate. In our custom template class we can add new methods that can be invoked from our template content.

Let's create a new base template class with an icon method to output valid FontAwesome markup:

Continue reading →

Groovy Goodness: Relax... Groovy Will Parse Your Wicked JSON

Posted on by  
Hubert Klein Ikkink

Since Groovy 2.3 the JSON parser has improved and is really a performant parser for JSON payload. JSON must be formatted in a strict way, for example all keys must be enclosed in double quotes. But what if we have JSON which not applies to the strict specification? For example a configuration file written in JSON and we want to add comments to this file. Or use single quotes for keys, or just leave all the quotes out. We can now specify the type JsonParseType.LAX for our JSON parser and we can now parse JSON which doesn't apply to the strict specification.

import groovy.json.*
import static groovy.json.JsonParserType.LAX as RELAX

def jsonText = '''
{
    message: {

        /* Set header of message */
        header: {
            "from": 'mrhaki',
            'to': ["Groovy Users", "Java Users"]
        }

        # Include a little body for the message.
        'body': "Check out Groovy's gr8 JSON support."
    }
}
'''

def json = new JsonSlurper().setType(RELAX).parseText(jsonText)

def header = json.message.header
assert header.from == 'mrhaki'
assert header.to[0] == 'Groovy Users'
assert header.to[1] == 'Java Users'
assert json.message.body == "Check out Groovy's gr8 JSON support."

Continue reading →

Awesome Asciidoc: Using Conditional Directives

Posted on by  
Hubert Klein Ikkink

In Asciidoc markup we can include or exclude text based on the existence of document attributes or based on the value of a document attribute. Therefore we use the macros ifdef, ifndef and ifeval. If we want to include some content if the document attribute sample is set we can use the following syntax:

ifdef::sample[Content is shown when sample attribute is set]

ifdef::sample[]
Content is shown when sample attribute is set
endif::sample[]

Continue reading →

Awesome Asciidoc: Include Only Certain Lines from Included Files

Posted on by  
Hubert Klein Ikkink

In a previous post we learned how to include partial content from included files. We needed to enclose the content we want to include between start and end tags and reference those tags in our documentation markup. But Andres Almiray already mentioned in a tweet we can use line numbers as well:

@marcovermeulen @rfletcherew @mrhaki you can also use -1 in the include range, like this https://raw.githubusercontent.com/griffon/griffon/master/docs/griffon-guide/src/asciidoc/appendix-sample-applications.adoc

— Andres Almiray (@aalmiray) June 6, 2014

Continue reading →

Grails Goodness: Using Bintray JCenter as Repository

Posted on by  
Hubert Klein Ikkink

Bintray JCenter is the next generation (Maven) repository. The repository is already a superset of Maven Central, so it can be used as a drop-in replacement for Maven Central. To use Bintray JCenter we only use jcenter() in our repositories configuration block in BuildConfig.groovy. This is the same as we would use in a Gradle build.

// File: grails-app/conf/BuildConfig.groovy
...
repositories {
    ...
    // Configure Bintray JCenter as repo.
    jcenter()
    ...
}
...

Continue reading →

Grails Goodness: Conditionally Load Beans in Java Configuration Based on Grails Environment

Posted on by  
Hubert Klein Ikkink

In a previous post we saw that we can use Spring's Java configuration feature to load beans in our Grails application. We can use the @Profile annotation to conditionally load beans based on the currently active Spring profile. We can for example use the Java system property spring.profiles.active when we start the Grails application to make a profile active. But wouldn't it be nice if we could use the Grails environment setting to conditionally load beans from a Java configuration? As it turns out Grails already set the current Grails environment name as the active profile for the Grails application. So we can simply use @Profile in our configuration or component classes, like in a non-Grails Spring application.

We can use the @Profile annotation in a Spring Java configuration class. The following sample shows different values for the @Profile annotation. The annotation is applied to methods in the sample code, but can also be applied to a class.

Continue reading →

Grails Goodness: Use Spring Java Configuration

Posted on by  
Hubert Klein Ikkink

A Grails application uses Spring under the hood, which means we can also use all of Spring's features in a Grails application. For example we can use the Spring Java configuration feature with our Grails application. The Java configuration feature allows us to write a Java or Groovy class to define beans for our application. Of course in Grails we have the nice bean builder syntax when we define beans in the grails-app/conf/spring/resources.groovy file, but maybe we must include a Java configuration from an external library or we just want to write a configuration class ourselves.

This post is very much inspired by this blog post by Andres Steingress.

Continue reading →

Scrum Master Tip: Make it transparent!

Posted on by  
Arthur Arts

I am frequently asked by colleagues for advice on how to be a good Scrum Master. I will discuss some of the tips I share in a couple of blog posts. First of all I do like to state that I believe it's best to have a Scrum Master that is able to get his hands dirty in the activities of the team (i.e. coding, analyzing, designing, testing etc.). It will enable him/her to engage and coach at more levels than just overall process. In my opinion one of the most important things a Scrum Master has to do is to make things transparant for the whole team. Now this seems like very simple advice, and it is. However, when you are in the middle of a sprint and all kinds of (potential) impediments are making successfully reaching the sprint goal harder and harder, the danger of losing transparency always pops up. Here are three practical tips:

  • Is it clear for everybody what we as a team should  focus on right now?
  • Is everybody focussing on the things that we should focus on right now?
  • Are we going to reach our sprint goal?

Continue reading →

ngImprovedTesting: mock testing for AngularJS made easy

Posted on by  
Emil van Galen

NOTE: Just released version 0.3 of ngImprovedTesting with lots of bug fixes.
Check out this blog post or the README of the GitHub repo for more info.

Being able to easily test your application is one of the most powerful features that AngularJS offers. All the services, controllers, filters even directives you develop can be fully (unit) tested. However the learning curve for writing (proper) unit tests tends to be quite steep. This is mainly because AngularJS doesn't really offer any high level API's to ease the unit testing. Instead you are forced to use the same (low level) services that AngularJS uses internally. That means you have to gain in dept knowledge about the internals of $controller, when to $digest and how to use $provide in order to mock these services. Especially mocking out a dependency of controller, filter or another service is too cumbersome. This blog will show how you would normally create mocks in AngularJS, why its troublesome and finally introduces the new ngImprovedTesting library that makes mock testing much easier.

Continue reading →

Grails Goodness: Using Converter Named Configurations with Default Renderers

Posted on by  
Hubert Klein Ikkink

Sometimes we want to support in our RESTful API a different level of detail in the output for the same resource. For example a default output with the basic fields and a more detailed output with all fields for a resource. The client of our API can then choose if the default or detailed output is needed. One of the ways to implement this in Grails is using converter named configurations.

Grails converters, like JSON and XML, support named configurations. First we need to register a named configuration with the converter. Then we can invoke the use method of the converter with the name of the configuration and a closure with statements to generate output. The code in the closure is executed in the context of the named configuration.

Continue reading →

shadow-left