Green Moon Software, LLC

Pretty Command Line Parameters in Groovy

It is no secret that I love the Groovy language. I believe it is a great language for application development. It is an even better language for writing script files. A halmark of a good script or command line executable is the quality of it’s help message. What happens when you run -h? Groovy has excellent support for reading and paring command line parameters via it’s CliBuilder class. The documentation is very through, but it doesn’t really showcase how easy it is to use.

I use Jekyll to build this site. I use a log of custom scripts to manage creating posts, drafts, publishing posts, etc. These scripts are all written in Groovy. I don’t use these scripts too often, so I forget all of the command line switches. Below is the first couple lines:

Line 1 creates the CliBuilder and initializes the usage attributes. Passing “this.class.simpleName” is a nice, copy-and-paste default setting that can be utalized in most every script. No longer will you have the wrong executable script name in your usage output.

The cli.with closure is a great shorthand for defining the various parameters for the script. It maintains readability, especially if the parameters are in alphabetical order.

The parameters are read into the opts variable via the parse command. A quick check to ensure that the opts were parsed correctly with a bail out if not.

The last two lines shows that reading the parameters is as simple as pulling them out of the parsed opts via their parameter names. It is easy to add default values using the Elvis Operator

Running the script from above without any of the required parameters produces the following:

Sometimes you do not want a short, one-letter argument. You indicate these parameters using the _ character in the with {...} closure. I have an example of this is in the Porpoise project’s script.

I hope this short introduction helps highlight how easy the CliBuilder is to use. Now you have no excuses not to include beautiful help output in your Groovy command line scripts.

Create Your Own Private Docker Registry

This is a post in a series discussing using spring-boot and docker for deployment. Refer to the end of the first post for a table of contents.

Shortly after you start building docker containers you will realize that you need some place to publish your images. You could push to the central docker registry. However, the central registry is public. Not a great idea if you are working on a private project.

If this is your case, you can simply run a local docker registry. To install and run your private registry run $ docker run -p 5000:5000 -d registry

Surprise!!! It is ran in a docker container.

You can now start pushing to your local repository. As an example, I will pull the latest postgres image and push version 9.4 to my local registry.


Looking at the current images, you will notice that the version tagged with localhost and the official images have the same information.

Notice that I had to retag the image with the location of the repository. I thought the requirement to put the location address as part of the image name was a little odd. However, after using docker longer, it makes sense. It ensures you know where the image was originally pulled.

Since docker tags are not permanent, and newer version of the postgres:9.4 image could be pushed to the public registry. When you self-host images, you are in control of when updates are pushed to any base image that you have extended. Someday I intend to learn how to build an image completely from scratch.

Docker-ize All the Things!

Spring Boot Microservices With Docker

Service oriented architecture (SOA) appears to be back in vogue. Luckily for most of us, it does not involve large, enterprise, vendor-backed “SOA servers”. This time around, microservices are the model.

A microservice is similiar to the “S” in the SOLID design principals. It is a service that has only one single responsibility. These small services are then composed together to make a cohesive system. The small services are independently deployable and distributable. In the new “cloud” world, elasticity is the game.

So how does Spring and Spring-Boot help in this new world? Prior to Spring-Boot, SpringSource (now aquired by Pivotal) had simply supplied the world with a lot of different tools. It had always been up to the development community to figure out how to best put these pieces together. Now with Spring-Boot, Pivotal has put together a project that helps guide the usage of Spring’s tools. By scanning the libraries on the classpath and configuring sensible defaults, it is almost trivial to start a new project.

Applications written with spring-boot can be packaged as traditional war files. These war files can be deployed to the old-style application servers. However, the heavy weight application servers are out of favor in microservice environments. Therefore, spring-boot applications can be packaged as an executable jar file that includes a server (either Tomcat or Jetty). The application can be ran as easily as typing java -jar application.jar.

That would be enough to get started. However, we will take it a step further and wrap the jar into a Docker container. With Docker, we are seeing the return of the “write once, run anywhere” saying that Java had promised. As long as our deployment server has a recent Linux kernel, we should be able to run our container. Additionally, Docker containers can be spun up and down as needed. Again, with deployments to the cloud, this elasticity is huge.

This article is part one in a series that will introduce microservices. In this series I intend to cover:

  • Hosting a private repository
  • Building/Linking Docker Containers
  • Securing the REST endpoints with OAuth
  • Separating the OAuth Authorization Server from the Resource Server (critical in a microservice environment)
  • Exposing Endpoints via RabbitMQ

If there is something else that you would like to see covered in this series, please leave me a message in the comments. I will try to include all of the questions or suggestions.

Hash Password with PBKDF2 and HMAC SHA

This is an example showing a proper hashing algorithm for hashing passwords for storage. Make sure that you store the salt for the password as well. Otherwise, there is no way to get it back. You can tweak the iterations and keylength variables as needed. As future CPU (and GPUs) get faster, you will have to change the iterations.

Java 8 Elvis Operator

DISCLAIMER: This post contains a rant. Reader discretion is advised.

Null pointers are the bane of software developers. The nefarious NullPointerException or NoReferenceException is know to all java or C# developers. At worst, they are a minor inconvenience. At worst, they can cost companies a lot of money. So when I heard about a new feature in Java 8 that was supposed to help mitigate these bugs, I was excited.

The feature is called “Optional”. There are a lot of existing examples in other languages of how nulls can be easily handled. Indeed, the documentation even cites some of the examples.
Elvis Simpson

What Alternatives to Null Are There?
Languages such as Groovy have a safe navigation operator represented by “?.” to safely navigate through potential null references. (Note that it is soon to be included in C#, too, and it was proposed for Java SE 7 but didn’t make it into that release.) It works as follows:

String version = computer?.getSoundcard()?.getUSB()?.getVersion();

In this case, the variable version will be assigned to null if computer is null, or getSoundcard() returns null, or getUSB() returns null. You don’t need to write complex nested conditions to check for null.

In addition, Groovy also includes the Elvis operator “?:” (if you look at it sideways, you’ll recognize Elvis’ famous hair), which can be used for simple cases when a default value is needed. In the following, if the expression that uses the safe navigation operator returns null, the default value “UNKNOWN” is returned; otherwise, the available version tag is returned.

String version = computer?.getSoundcard()?.getUSB()?.getVersion() ?: “UNKNOWN”;


OK, we diverged a bit and all this sounds fairly abstract. You might now wonder, “so, what about Java SE 8?”

After reading that section, I was momentarily excited. The “?” and “?:” operators in groovy are godsends. But, my enthusiasm was quickly halted. To use this new feature, variables have to be wrapped in Optional objects. For instance:

So what does the equivalent Elvis operator “?:” look like in Java 8?

What happened here? How can you tease me with the easy to use syntax and then throw this up? What the heck is flatMap and map? All I’m trying to do is get the version of the usb connected to the soundcard on my computer.

I can see where there are other use cases for Optional as I read through the rest of the documentation page. But I have to wonder if those other features could have somehow been tacked onto the language in a different manner. I fully admit that I am not a language creator, nor have any experience in it. But in APIs that I write, I try to hide away the ugly and leave a nice, easy-to-use front end. The above does not appear to hide the ugly.

To be fair, I have not had any practical experience with the new features in Java 8. So it is possible I do not fully understand how this particular feature will fit in with the new additions. I will keep an open mind and attempt to use the Optional feature when it makes sense. I tend to write mostly in groovy thesedays, so I will happily keep using the “?” an “?:” operators.

Thanks for reading my rant.