Developer-B

Shutting down Dropwizard programmatically turned out to be a bit tricky due to the way it's started. This in turn made it difficult to start and stop instances for integration testing without forking multiple JVM instances.

Vertx weekend experiment - Real time Dropwizard dashboard

This was just a weekend experiment to refresh my Javascript knowledge and try out some technologies I've been looking at for some time. Don't expect it to be of production quality or that I'll maintain it.

Dropwizard is a well instrumented and productive framework for building production ready restful web services. It exports a lot of statistics on a admin port. I thought it would be fun to create a proxy polling this endpoint and feeding the data to clients connected via web sockets. The proxy is implemented using the fairly new Vertx framework enabling highly concurrent polygot application development on the JVM.

While I was working on the client side of the dashboard I thought it would be fun to have a look at Knockout.js for data binding. I quite liked the declarative way it solves a lot of common problems related to data binding.

With wife and baby visiting grand parents this weekend I've had some time to look into Dropwizard. Dropwizard is a pretty productive framework for exposing restful web services.

It comes with awesome instrumentation capabilities out of the box, but only for Jersey resources, but it turns out to be ridiculously simple to add this capability to other beans by adding Google's Guice to the mix.

Relevant code at Github: https://gist.github.com/2623833

My informal definition of refactoring: The process of changing / re-organizing / re-structuring code without breaking public interfaces or changing runtime behavior.

So you’re at work busy refactoring some code, breaking the occasional test here and there in the process of doing so. Then my friend, you’re doing a refucktoring, not a refactoring! And, you know that you’re really refucktoring when the tests you’re breaking aren’t even related to the piece of code you’re working on.

Refucktoring tends to happen when the tests knows too much about the internals of the code that you're testing. The more you’re able to test through public interfaces the less are the chances of your well-meant (we all know what the road to hell is paved with...) refactoring efforts regressing into refucktoring. Try to avoid testing how a result is being produced when what you're really interested in testing is that the code under test produces the expected result for any given input! Doing this buys you the freedom to refactor the implementation or even swap it out for a completely different one without changing the tests!

I've been using Workflowy (loving it!) for a while now and I've learned a couple of lessons regarding how to best structure my life as lists and bullet points. Here are some of my conclusions so far:

Don't let lists grow without boundaries: Doing this makes it a lot harder to go back and look at the history of completed items. Tasks tends to be strongly associated to a period of time so consider organizing a large parts of your lists by topic > year > month. Organizing your lists by topics like personal, work project-x, work project-y will make the sharing feature a lot more useful. Grouping items by year / month below topics makes it a lot easier to go back and browse through completed items.

Use comments to track progress and result: Many tasks tends to involve getting in touch with other people, companies or organizations. Whenever I start working or close one of these tasks I use the log feature to write down who and when I've been in touch with and what we agreed upon. Having this information can be immensely useful later on!

Good talk about Unicode and encoding pain. Non python programmers might want to skip the middle part.

I've been using Workflowy for a few weeks now. It's a web based, keyboard driven tool making it very easy to keep track of large and nested todo-lists with very little overhead.

The only problem is that it's a lot of work to actually do all those things one would otherwise forget all together :-)

I’ve started in a new job so it’s been some time since the last time wrote a blog entry. The other day I realized that it’s been around three years since I started looking into Groovy. I’m mostly doing Java programming in my new job so this has been an opportunity for me to take a step back and have a look at Groovy in relation to Java.

The good stuff

 - In no particular order

Excellent support for writing DSL’s!

This makes it perfect for configuration, plumbing, wiring of various kinds. Think of it as the familiar Java builder pattern on steroids.

A meta object protocol and support for compile time AST transformations is the backbone behind these DSL’s.

http://www.slideshare.net/glaforge/practical-groovy-dsl

Gentle learning curve for Java developers

It’s very easy for Java programmers to get started with Groovy. Almost all Java code is already valid Groovy code so programmers used to writing Java can start out writing what they’re already used to and slowly start taking advantage of Groovy.

Important: Do note that even despite the familiar syntax, Groovy code often has very different runtime behavior! Groovy puts a lot more thought into picking what implementation to call during method invocation then Java.

http://groovy.codehaus.org/Differences+from+Java

Syntax support for lists and maps

Being able to initialize lists and maps directly saves a lot of boilerplate code. This is part of what makes Groovy particularly suited for writing tests.

Very good Java - Groovy interoperability

Calling back and forth between the two languages is fairly straight forward. This means that you can continue to use the Java libraries you already know and love. Just keep in mind that calling Groovy from Java bypasses the meta-programming protocol.

Closures!

Support for closures means that you can say a lot more with a lot less code. Code will often be more readable and can enjoy spending more time working on the actual problem instead of pleasing the Java type system.

When Java 8 is released in 2050* Java programmers will also be able to enjoy closures.

* Release date estimated based on previous releases

http://groovy.codehaus.org/Closures

Catching checked exceptions are optional

Groovy doesn’t force you to catch checked exceptions!

Extended JDK classes

Groovy extends many JDK classes with new utility methods. One of my personal favorites is probably the “getText” method on File and URL that turns reading a file or a web page into a string a one-liner!

These are the kind of features that actually makes me consider writing one-off scripts in a JVM language!

http://groovy.codehaus.org/groovy-jdk/

Backed by a large company

Spring Source acquired Groovy before being acquired itself by VMware . This is great! Groovy is as far as I know the only dynamic language on the JVM backed by a large company.

This point alone should make it easier to convince your manager that it’s safe to use.

IDE support is getting pretty good

Good IDE support in Eclipse (STS) and Idea. NetBeans has some support, but very slow and outdated unless something has happened since the last time I tried it.

Awesome community!

There is a lot of innovation going on in the world of Groovy! Projects like Spock, Grails and Gradle leverages Groovy for many of their innovative features. People on the mailing lists are very friendly and helpful. 

The bad stuff

 - Not all bad if you’re a pragmatic and disciplined developer

It requires more a lot more discipline

Meta-programming is cool, but makes it more difficult to read the code and write unit tests. Applying lot of magic behavior at runtime can make it very difficult to reason about the system.

Questions like where the **** is this functionality implemented / activated?! has come to mind during code review..

My advice: Try to limit the scope of meta-programming magic to avoid getting into a test / maintenance nightmare. It should be very clear to developers where meta-programming rules apply. Write tests first so you never find yourself implementing something that is a nightmare to test.

Makes it easier to leave dead code in the project

Better IDE support can remedy the situation slightly, but with all the options to go overboard with meta-programming combined with dynamic typing means that they will never be as good as what we’re spoiled with from Java.

This problem grows exponentially with the number of colleagues working on the same project because nobody dares to remove some code that just might be in use.

My advice: Limit the use of global meta-programming and be really disciplined when it comes to making sure that you don’t leave dead code behind during re-factoring. Agree on conventions with your team mates and do code reviews / buddy checking.

Performance(?)

I see quite a lot of people complaining about this. Personally, I don’t look at Groovy’s runtime performance as a problem. My biggest reason for using Groovy is the expressive power, not the performance. The good Groovy-Java interoperability means that it’s very simple to implement hot spots in Java should performance ever turn out to be a problem.

Start-up performance could be better though… Groovy does a lot of tricks involving classloaders, call site caching and byte code generation in order to allow the JIT to generate optimized code. This takes a bit of time...

Many larger Groovy projects like Gradle and Grails tries to work around this problem by keeping a daemon process running in the background to work around this.

Huge runtime dependency

The groovy-all jar file is closing in on 6mb as I’m writing this. Adding this dependency to a project is an absolute no-go if all I’m looking for is closures and a slightly nicer syntax.

Modularization of groovy-all is on the roadmap for Groovy 1.9 2.0. This is something that I’m really looking forward to, even though having the groovy-all option is very convenient in situations where you just want to script something and can’t be bothered to find all the right dependencies.

A modularized Groovy is very high on my wish list!

Outdated website

The web site has been looking quite outdated and unprofessional for quite some time, but they’ve given it a face lift after I started writing on this blog entry! Nice!

The only thing they have to do now is to come up with 10$ for a proper domain :-)

One might say that the looks of the website isn’t that important, but an outdated and unprofessional web page can make it a lot harder to convince management that this is a project we should start using!

A bit hard to find documentation

Documentation is spread across various wiki pages, web sites, mailing lists and java-doc. I’d love to see a more coherent system for documentation - Spring and Grails are good examples.

Update: Like with the web page, this has improved a lot since I started writing this post.

My advice: Buy a book! Not only will it provide you with lots and lots of Groovy knowledge, but you’ll also be supporting the project.

The ugly stuff

 - Things I’d rather see go away…

Enormously huge stacktraces!

Stack traces from Java EE applications with Hibernate and deployed on an “enterprise” container will look small and readable in comparison. I’ve seen Groovy stack traces several hundred lines long during Grails development.

Groovy will add a lot of small steps in between what looks as simple method invocations to you in order to support meta-programming and various dynamic features.

My advice: Look into options for filtering out at least some of the noise. A disturbingly large part of a Groovy stacktrace is often just noise distracting you from the real problem.

Backwards compatibility

Where Java in my opinion might be a bit too careful about not breaking backwards compatibility, Groovy is not that careful. This probably allows the project to move a lot faster, but growing pain / regressions between releases can be very annoying and frustrating.

Memory problems

Be mentally prepared to deal with and learn about various problems and bugs related to garbage collection, perm-gen and classloaders. I hope that some of these issues will go away when they start taking advantage of JSR 232 (invoke dynamic).

Summary

Even though I'm not using Groovy in my day-to-day programming I'm still very fond of the project and try to keep up with what's moving in the community. I do hope that they're able to remain relevant as more of Groovy's selling point features are becoming available in Java.

If you're considering adopting Groovy in your project I'd recommend starting out slowly, perhaps by writing some of your tests in Groovy and Spock instead of Java and Junit.

As you're familiarizing yourself with the language and get a better understanding of its runtime behavior you can start writing isolated parts of the production code in Groovy.

It’s been a while since the last time I wrote a blog post. Since then I’ve started a new job in Oslo and fathered my first son!