GIT & ZShell : Colorize your shell depending on your branch

Leave a reply

As announced in my last post I asked my colleague Tillman if I’m allowed to post his nice extension for the zshell (as you may have concluded he gives his OK ).

And here it is

# Required to have the colour names
autoload colors zsh/terminfo
if [[ "$terminfo[colors]" -ge 8 ]]; then
  colors
fi
for color in RED GREEN YELLOW BLUE MAGENTA CYAN WHITE; do
  eval PR_$color='%{$terminfo[bold]$fg[${(L)color}]%}'
  eval PR_LIGHT_$color='%{$fg[${(L)color}]%}'
  (( count = $count + 1 ))
done
PR_NO_COLOUR="%{$terminfo[sgr0]%}"

# Thanks Tillman
function get_color(){
 BRANCH=`git rev-parse --abbrev-ref HEAD`
 case "$BRANCH" in
 *master*) COLOR=${PR_RED} ;;
 *hotfix*) COLOR=${PR_MAGENTA} ;;
 *release-candidate*) COLOR=${PR_YELLOW} ;;
 *release*) COLOR=${PR_YELLOW} ;;
 *bugfix*) COLOR=${PR_CYAN} ;;
 *develop*) COLOR=${PR_BLUE} ;;
 *) COLOR=${PR_GREEN} ;;
 esac
 echo $COLOR
}

# Required to have the colour names

autoload colors zsh/terminfo

if [[ "$terminfo[colors]" -ge 8 ]]; then

colors

for color in RED GREEN YELLOW BLUE MAGENTA CYAN WHITE; do

eval PR_$color='%{$terminfo[bold]$fg[${(L)color}]%}'

eval PR_LIGHT_$color='%{$fg[${(L)color}]%}'

(( count = $count + 1 ))

done

PR_NO_COLOUR="%{$terminfo[sgr0]%}"

# Thanks Tillman

function get_color(){

BRANCH=`git rev-parse --abbrev-ref HEAD`

case "$BRANCH" in

*master*) COLOR=${PR_RED} ;;

*hotfix*) COLOR=${PR_MAGENTA} ;;

*release-candidate*) COLOR=${PR_YELLOW} ;;

*release*) COLOR=${PR_YELLOW} ;;

*bugfix*) COLOR=${PR_CYAN} ;;

*develop*) COLOR=${PR_BLUE} ;;

*) COLOR=${PR_GREEN} ;;

esac

echo $COLOR

}

The color mapping is the same as in these graphic

Branch to Environment / Profile mapping

Applying can be done, for example, when adding this git status helper and refine it with the get_color function.

function git_status () {
  local output
  gs=$(git status 2> /dev/null)
  if [[ $? == 128 ]]; then
    return
  fi
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  output=${$(get_color)}" "${ref#refs/heads/}
  if echo "$gs" | grep -q "Changes to be committed"; then
    output=${output}${PR_GREEN}+
  fi
  if echo "$gs" | grep -Eq "(Changes not staged for commit|Changed but not updated)"; then
    output=${output}${PR_RED}!
  fi
  if echo "$gs" | grep -q "Untracked files"; then
    output=${output}${PR_RED}?
  fi  
  echo "${output}${PR_NO_COLOUR}"
}

PROMPT=$'%(?,${PR_GREEN}+,${PR_RED}-)${PR_NO_COLOUR} %(4c,./%1~,%~) $(git_status) %(!.${PR_RED}#${PR_NO_COLOUR} .%% )'

function git_status () {

local output

gs=$(git status 2> /dev/null)

if [[ $? == 128 ]]; then

return

ref=$(git symbolic-ref HEAD 2> /dev/null) || return

output=${$(get_color)}" "${ref#refs/heads/}

if echo "$gs" | grep -q "Changes to be committed"; then

output=${output}${PR_GREEN}+

if echo "$gs" | grep -Eq "(Changes not staged for commit|Changed but not updated)"; then

output=${output}${PR_RED}!

if echo "$gs" | grep -q "Untracked files"; then

output=${output}${PR_RED}?

echo "${output}${PR_NO_COLOUR}"

}

PROMPT=$'%(?,${PR_GREEN}+,${PR_RED}-)${PR_NO_COLOUR} %(4c,./%1~,%~) $(git_status) %(!.${PR_RED}#${PR_NO_COLOUR} .%% )'

At least some examples

Gradle & GIT : How to map your branch to a deployment profile

Leave a reply

Today I would like to show you how easy you can create conventions on your branching model and map these conventions to deployment / environment profiles.

Where we come from

Usually a project needs to have different settings for different environments (production, testing, staging, etc. pp.). Maven provides for this a nice plugin, but Gradle lacks of this kind of plugin. But, to be honest, introducing something that fills this gap is quite easy. For an example see source code below

ext.environment = rootProject.hasProperty('env')? rootProject.getProperty('env'): 'developer'
logger.quiet "Assembling application for ${environment} environment."
ext.deploymentConfig = new ConfigSlurper(environment).parse(file("${rootProject.projectDir}/config/deployment/configuration.groovy").toURL())

ext.environment = rootProject.hasProperty('env')? rootProject.getProperty('env'): 'developer'

logger.quiet "Assembling application for ${environment} environment."

ext.deploymentConfig = new ConfigSlurper(environment).parse(file("${rootProject.projectDir}/config/deployment/configuration.groovy").toURL())

As you see, it checks if the property ‘env’ is set, if so it uses this value otherwise developer as environment. After this setup it reads a config file in groovy style with the config slurper.

It works fine, so what’s the issue?

Even if the default is ok (test environment) it annoys me that have to type every time something like -Penv=production . It happens often, that I forgot to explicitly set the branch to production or staging (our CI-Server remembers this for me, but I need to build the bugfix branches for example on my local machine). Starting from this point I discussed with a colleague of mine the usage of some conventions on our branch layout (mostly inspired by http://nvie.com/posts/a-successful-git-branching-model/; we just added explicite bugfix branches on top of the release branch). We came up with the observation that we could map all branches to different environments

Branch to Environment / Profile mapping

The dashed lines are alternative deployment environments whereas the filled lines are the default deployment environments from our perspective. As you see, we make a really simple and understandable mapping convention. After producing this mapping I started to investigate how complex it will be to check what’s my current branch in GIT is. This can be done fairly easy with

git rev-parse --abbrev-ref HEAD

1	git rev-parse --abbrev-ref HEAD

Side note: Getting information of your parent branch isn’t that easy and reliable in GIT (see here )

In gradle I introduced a closure for fetching the branch name and doing some simple assumptions about the related profile / environment

def defaultEnvironment() {
        def branch = ""
        def proc = "git rev-parse --abbrev-ref HEAD".execute()
        proc.in.eachLine { line -> branch = line }
        proc.err.eachLine { line -> println line }
        proc.waitFor()
        def defaultEnvironment='local'
        if(branch.startsWith('develop')) {
                defaultEnvironment='test'
        } else if (branch.startsWith('release') || 
                   branch.startsWith('bugfix') || 
                   branch.startsWith('hotfix')) {
                defaultEnvironment='staging'
        } else if(branch.startsWith('master')) {
                defaultEnvironment='production'
        }
        defaultEnvironment
}

def defaultEnvironment() {

def branch = ""

def proc = "git rev-parse --abbrev-ref HEAD".execute()

proc.in.eachLine { line -> branch = line }

proc.err.eachLine { line -> println line }

proc.waitFor()

def defaultEnvironment='local'

if(branch.startsWith('develop')) {

defaultEnvironment='test'

} else if (branch.startsWith('release') ||

branch.startsWith('bugfix') ||

branch.startsWith('hotfix')) {

defaultEnvironment='staging'

} else if(branch.startsWith('master')) {

defaultEnvironment='production'

}

defaultEnvironment

}

Last but not least I used the ConfigSlurper for reading the matching properties from a groovy config file and push them into a variable in the ext space.

ext.environment = rootProject.hasProperty('env')? rootProject.getProperty('env'): defaultEnvironment()
logger.quiet "Assembling application for ${environment} environment."
ext.deploymentConfig = new ConfigSlurper(environment).parse(file("${rootProject.projectDir}/config/deployment/configuration.groovy").toURL())

ext.environment = rootProject.hasProperty('env')? rootProject.getProperty('env'): defaultEnvironment()

logger.quiet "Assembling application for ${environment} environment."

ext.deploymentConfig = new ConfigSlurper(environment).parse(file("${rootProject.projectDir}/config/deployment/configuration.groovy").toURL())

This can now used in the processResources task of the Java plugin, to replace placeholders

processResources {
        filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: rootProject.ext.deploymentConfig)
}

processResources {

filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: rootProject.ext.deploymentConfig)

}

That’s all. It works very well and reduces the typed chars and frees my mind for the really important things.

I’ll prepare a simple example project and share it via git hub.

Update: Project at github (https://github.com/coders-kitchen/ConventionalBranchMapping)

At least some spoilers

At my employment we started implementing a profiler plugin for gradle, that will include this with a little bit more sugar and some additional conventions. We will share this plugin via oss-sonatype / github. Stay tuned!
My colleague created a nice extension for the zShell, I’ll ask him if we can share this here. If so I’ll put his script here during the next days.

Arquillian – Very first best practice

Leave a reply

During usage of Arquillian I figured out some things that could be a starting point for best practices when testing with Arquillian.

In my application I had some defaults that I have to do every time, when I would like to implement a new test.

Add logging
Add persistence.xml
For different domains, add all classes that belongs to the entity graph
Setting up the name of the web-archive properly
Introduces maven dependency lookup

In my opinion, it’s very handy to implement a helper class with the builder pattern, that creates

a ShrinkWrap of type WebArchive with the given name
has methods that fulfills the above requirements.

The impact on our testclasses was tremendous, we improved the readability and reduces the code duplication.

So long story short:

Introduce archive builder that encapsulates common patterns and combination of classes.

DataFX forked – @ContextResource added

Leave a reply

Some weeks ago, Hendrik Ebbers (http://guigarage.com) shared a beta version of DataFX with me.

DataFX is a cool framework that has several components.

Controller : removes the direct dependency between a fxml file and it’s controller within the fxml file. It also adds contextual objects and for three kinds of contexts (Application, View and FlowView).
Websocket : Adds support of websockets and restful interfaces to your JavaFX application
Cell : Provides a simpler approach for create TableViews
Core : DataProvider

I played around with the Controller component. It’s really nice and easy to use, but I stumbled upon a simple thing that was a little bit annoying.

Everytime I want to use a object from the context I had to

@FXMLViewContext
ViewContext context;

public void myMethod() {
  String myContextualObject = (String)context.get("MyContextualObject");
  System.out.println(myContextualObject);
}

@FXMLViewContext

ViewContext context;

public void myMethod() {

String myContextualObject = (String)context.get("MyContextualObject");

System.out.println(myContextualObject);

}

It’s ok, but I thought it will be much cooler, if I could do in this way

@ContextResource
@FXMLViewContext
String myContextualObject;

public void myMethod() {
  System.out.println(myContextualObject);
}

@ContextResource

@FXMLViewContext

String myContextualObject;

public void myMethod() {

System.out.println(myContextualObject);

}

So I forked DataFX in Bitbucket and started the implementation of this feature.
At the moment I can inject resources from the context with

a lookup in all context
specify a specific context from where the object should be retrieved.

I added also a feature that allows to specify the key of the object that should be injected from the context registry.

I discussed this already with Hendrik and he’s very interested in it.

Started JEE – Testing with Arquillian

Leave a reply

Some time ago I came to the point where I need to do integration tests for my JEE applications at work. In Spring this is fairly easy, just use the SpringJUnitRunner and most of the work is done by Spring. Possibly you have to choose the right profile or do some minor configuration setup. But it’s really easy.

In JEE6 I tried several testing frameworks two years ago, but none of them works very well, so we decided to skip this point and continue with end users tests and JUnit testing. One exception we made for our controller classes that instruments the database and did some complex calculations on the data. From this approach my JUnit rules framework starts from.

But I never gave up the search for an testing framework for JEE6. Before I (re-)stumbled upon Arquillian, I found http://jglue.org/cdi-unit/ which is a nice JUnitRunner for testing CDI applications. But it misses EJB and the container stuff.

A few weeks ago I came (again) across Arquillian and was again amazed about their promise and idea “Do real integration testing within the real runtime environment”.

The first steps were hard, especially figuring out how the ShrinkWrap works correct, but after these initial hirdles I became more and more familiar with Arquillian and I won’t miss it anymore in my toolbox.

My personal best of of the features of Arquillian are

it’s fast. If you don’t have a very complex structure or setup, testing with Arquillian feels like Unit Testing
100% IDE support (except of my special build setup )
coverage can be calculated via JaCoCo (a promising new kid on the block)
you don’t have to start your whole application. Just add the parts you need for this class of tests.
deployment of the tests is done in the “real” environment, not in an “like the real” environment.

But where light is is also shadow:

you must know the dependencies of your system under test. If one is missing the testclass will fail. But this is good, because after this you are very familiar with the dependencies.
when using a remote server, usually you must have a SSL-Connection and for this a java acceptable certificate or the certificate has to installed in the trust-store of java where the test runs.
gradle dependency resolution support is not available. But I found some ideas on github.

During this week I will prepare some examples and provide them to you.

CompileOnly plugin for Gradle released

Leave a reply

A few moments ago I released version 1 of a handy plugin for Gradle.

This plugin adds compileOnly as a new configuration to a java or groovy build. If either the java nor the groovy is applied, the plugin applies automatically the java plugin.
It takes care of adding this configuration to the standard source sets main and test.
And it is aware of Eclipse and IntellJ IDEA as IDEs and adds this configuration to the provided dependencies of them, if the plugins are applied.

How to apply

buildscript {
	repositories {
		mavenCentral()
	}
	dependencies {
		classpath group: 'com.coders-kitchen', name: 'compileonlyplugin', version: '1.0.0'
	}
}

apply plugin: 'compileOnly'

buildscript {

repositories {

mavenCentral()

}

dependencies {

classpath group: 'com.coders-kitchen', name: 'compileonlyplugin', version: '1.0.0'

}

apply plugin: 'compileOnly'

Usage

Like any other configuration

Creating a compileOnly dependency in Gradle

Leave a reply

Today I would like to show you, how to add a Maven-provided style configuration to a Gradle build.

Sometimes in a projects lifecycle you may encounter the situation, that you have a dependency that is only required during compile time, some annotations for example. But Gradles java plugin doesn’t supports this out of the box. The war plugin add’s this feature, but also additional tasks that aren’t required in a plain java project.

To add this feature to your build you must simply

Add a new configuration

Java

configurations { compileOnly }

1
2
3

configurations {
compileOnly
}
Add the dependencies from this configuration to the compileClasspath of your source sets (at least main and test )

Java

sourceSets { main { compileClasspath += configurations.compileOnly } test { compileClasspath += configurations.compileOnly } }

1
2
3
4
5
6
7
8

sourceSets {
  main {
    compileClasspath += configurations.compileOnly
  }
  test {
    compileClasspath += configurations.compileOnly
  }
}
Tell your IDE that their are additional dependencies

IDEA

Java

idea { module { scopes.PROVIDED.plus += configurations.compileOnly } }

1
2
3
4
5

idea {
  module {
    scopes.PROVIDED.plus += configurations.compileOnly
  }
}
Eclipse

Java

eclipse { classpath { plusConfigurations += configurations,compileOnly } }

1
2
3
4
5

eclipse {
  classpath {
    plusConfigurations += configurations,compileOnly
  }
}

Now you can use it like compile or test configuration in the dependencies section

dependencies {
  compileOnly 'org.jboss.spec:jboss-javaee-6.0:1.0.0.Final'
}

dependencies {

compileOnly 'org.jboss.spec:jboss-javaee-6.0:1.0.0.Final'

}

Serie : Choosing Names – 1. part : DTOs

Leave a reply

This article is the beginning of a small series about choosing names for classes (like DTOs, entities, enums …).

Every part of this serie is focused on a different type of class, the actual article, for example, deals with possible pattern, pre- and postfixing of names for DTOs.

Background

for this series is a discussion that came up during our last bigger refactoring:

The discussion begun with the simple question : ”How should we name this kind of classes?”. The goal of this question where classes, which intention is to transfer data between instances; the classic Data Transfer Object (DTO).

The first decision about structuring (at packet level) and how the names should look like, were very quick done. All classes of this kind, except of database entities for JPA, should be stored in the package dto of the according parent package of the business logic. Additionally all this kind of classes must be suffixed with DTO.

While we did the refactoring – pair programming rules – we asked ourselfs : “Does that really make sense?”

And this is the point where the series starts: With the

DTO

Definition

is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database. (Wikipedia)

This means, that a DTO is a class that defines which data – for an explicit case – can be transfered between different components of a system.

Fine. But one question is left: What’s a meaningful name for a class like this?

Let’s have a look on the environment where the DTO lives. It has no logic and is created, used and consumed by classes like beans, controller, managers, etc.;classes with a small portion of logic.

For the latter kind of classes we have more or less meaningful name patterns

EJB have the suffix Bean,
Classes that act as a controller, are usually suffixed with Controller and
manager classes, like a ConnectionPoolManager, uses Manager as suffix.

But, is their a reason against DTO as suffix for DTOs?

Yes, in my opinion.

From my point of view is difference between this “logic” classes and a DTO that, we can express with Bean, Controller, Manager … what the purpose of the class is. But a class suffixed with DTO will hide this initial purpose.

Let’s have a look on some examples:

CustomerAdministrationService
ConnectionPoolManager
CustomerManagementBean
SkyColorFactory
SkyColor
Mail

CustomerStatusResponseDTO
HealthStatusDTO
SubscriberModelDTO
ScreenResolutionDTO

The upper groups purpose is, due to the names, precisely expressed.

The purpose of the lower group is, on the other hand, much harder to understand. It’s clear, that this classes will transport some data, but to discover what kind of data for which purpose is much more difficult. We need to read backwards to capture things before this omnipresent DTO suffix. This means additional effort and the potential to misuse / misunderstand the class.

Let’s kick the suffix and see what will happen:

CustomerStatusResponse
HealthStatus
SubscriberModel
ScreenResolution

Cool, much better. Now it’s clear and easily captured what kind of data this classes will transport and, much more important, we have an idea what’s the direction of the data flow is and where this classes will be used.

Conclusion

The usage of DTO as postfix / prefix for a Data Transfer Object should be avoided, because

it’s much harder to catch where this object will be created, used or consumed
it’s much harder to understand what kind of data will be transfered
it can create new and unnecessary questions

In my opinion, meaningful names, should be preferred. Like

Model for moddeling classes
Response for objects that transfers an answer / response
Request for objects that transfers data for a request
Status for status objects

First release of JUnitRules accepted

Leave a reply

Good news: The first release of JUnitRules was accepted by OSS Sonatype.

The artifact coordinate for Gradle is

‘com.coders-kitchen:JUnitRules:1.0.1′

First release of JUnitRules at OSS Sonatype promoted

Leave a reply

I recently promoted the first release of JUnitRules at OSS Sonatype.

This release will include

EntityManagerRule for an easy setup of entity managers in Unit tests and
FilePrepareRule for an easy setup of directory and file structures for unit tests

I hope that my first release is accepted.

Coders Kitchen

Coding, Software Craftmanship and Cooking

GIT & ZShell : Colorize your shell depending on your branch

Gradle & GIT : How to map your branch to a deployment profile

Where we come from

It works fine, so what’s the issue?

Arquillian – Very first best practice

DataFX forked – @ContextResource added

Started JEE – Testing with Arquillian

CompileOnly plugin for Gradle released

How to apply

Usage

Creating a compileOnly dependency in Gradle

Serie : Choosing Names – 1. part : DTOs

Background

DTO

Definition

Conclusion

First release of JUnitRules accepted

First release of JUnitRules at OSS Sonatype promoted