Gradle daemon

The gradle daemon is a feature in gradle that is designed to speed up build times. A daemon process will run the builds, which reduces the startup time of the build. In an environment where you are running builds many times a day, this can be a significant time saver.

To enable the daemon, add the following property to your GRADLE_OPTS or gradle.properties:.

org.gradle.daemon=true

Gradle will automatically use the daemon process for the build. The daemon is killed off if it is not used for a while, but when that happens, the next build will spin up a new daemon. There are also additional options for not using the daemon, stopping it and running in the foreground that can be found in gradle's documentation http://www.gradle.org/docs/current/userguide/gradle_command_line.html.

People are not resources

It's very common for project managers to refer to employees as resources. The dictionary definition of resource is something that can be used for support or help. People are people, not things. A chair is a resource. A computer is a resource. A person is not a resource - a person is a person.

By using the term resource, the individuality of people and the value they provide are trivialized. You can swap one similar chair for another, but can you really swap one "similar person" for another?

This may seem like a small thing, but it's really a small thing to start calling people people, and it can make a big difference.

Keep methods short

I was reading some code recently, and saw the notation of marking the beginning and end of loops (not the first time I've seen this).

for ( int i = 0; i < someEndVal; i++ ) { // begin myProcessingLoop
  // long set of steps here
} // endMyProcessingLoop

Why is that information there? Usually because the processing loop is so long that it doesn't fit on a single screen, or because there are so many nested loops that it is hard to decipher. Instead of commenting on the loops like that, rewrite the loops so they are short. A common technique is to extract the loop body into its own method.

for ( int i = 0; i < someEndVal; i++ ) {
    dostuff(i);
}

It removes the unnecessary comments and makes the code generally easier to read.

NoSQL is not schemaless

NoSQL datastores give us a lot of flexibility when it comes to putting data in. They don't need a fixed schema to accept data, and they're pretty good about handling data with mixed attributes. Consider I insert the following data into a mongodb store (I'll use Mongo to illustrate my point, but this could apply to most NoSQL stores):

[ { "first_name" : "Jeff", "last_name" : "Storey" } , { "color" : "red", "a_number" : 50 } ]

Sure, I can do this, but imagine trying to query this data. Mongo will let me write a query that selects all documents whose "first_name" is "Jeff" or whose "color" is "red," but this doesn't make much sense at an application level. In order for the data to be easily processed, it needs to conform to some schema.

Where having this flexibility is really useful is with a schema that changes over time - and what schema doesn't? Rather than having to add new columns, new constraints, etc to the database, mongo will happily allow you to add new columns. Now consider an original schema that looks like:

first_name, last_name, age

Then I realize I want to start collecting income data, and I change it to

first_name, last_name, age, income

For records that have income, just insert it. No database changes necessary!

Technically, yes, NoSQL stores can be schemaless, but that doesn't mean you shouldn't have a schema.

Javascript Logging

When developing Javascript applications, we often need to do some logging and we usually resort to using console.log, which typically isn't a good thing to have in production code. I've been doing some research into Javascript logging frameworks, and there are quite a few of them.

log4javascript looks to be one of the more promising ones. It is still being actively updated, and the API is pretty straightforward, especially if you've used other logging frameworks like log4j. They even provide a default logger that requires no configuration to get running:

var logger = log4javascript.getDefaultLogger();
logger.debug("this is a debug message");

There are various types of appenders, including one that sends the log message through an ajax call to the server so the log message can be saved on the server.

If you're doing any sort of logging in your Javascript app, this is definitely worth a look.

Unstable builds in Jenkins

We use Jenkins for our continuous integration server, and I've never really seen the need for it to have an "unstable" build status. I actually think this build status does more harm than good. I've found that unstable can be treated in one of two ways - either it is treated like a build failure and fixed immediately or it is treated as not important and ignored. Either way, I think it loses its meaning.

It's also a bit unclear as to what "unstable" actually means. Some coverage plugins for example will set the build to unstable if the coverage level falls below a certain threshold. In this case, if coverage is too low, I wouldn't feel comfortable producing a build that is production ready, so I would fail the build. It's also possible to configure Jenkins to mark a build as unstable on test failures, instead of failing the build - I'm not even sure why that option exists.

I believe the build should only have two states - passed or failed. Whenever I start a new Jenkins project, I always configure any of the plugins I'm using to not use the unstable state (configuration varies from plugin to plugin). I've found keeping out the "unstable" state has led to healthier builds overall.

Why I switched to IntelliJ

For the last few years, I have been an Eclipse user. It's free, and for the most part, it worked pretty will with the occasional crash. However, I've found that it performs really poorly when it comes to dynamic languages. The groovy/grails autocomplete is mediocre, but where I really had issues is with Javascript. It got to a point where every time I tried to save a Javascript file, I was getting a NullPointerException.

So I decided to try out IntelliJ Ultimate based on a colleague's recommendation. Overall, I've been happy with the experience. It is very stable (I've only had one crash since I've been using it, and I was running a lot on my system at once). Deploying to Tomcat servers has been a breeze.

It's not without its quirks though. For example, things that just work in Eclipse, such as auto-wrapping long comment lines, don't work in IntelliJ. I've also found that the gradle support is still new and can be buggy at times (especially with auto-synchronizing Intelli's dependencies with the gradle build's dependencies - though I've heard that's in the works).

What I've been most impressed with is the support. Whether on the Jetbrains forums, bug tracker or stack overflow, the IntelliJ support team generally responds very quickly to posts.

Overall, it has been a pleasant experience. If you're fed up with Eclipse, I recommend giving IntelliJ a try.

Spring Profiles

Much of my web development over the past few years has been with Grails on the back end, and although Grails is built on Spring, it's still a good idea to keep up on the new Spring features - you never know when they'll come in handy.

I recently found myself creating a pure Spring app and missing a feature that I really like in Grails - environment based configuration. Fortunately, Spring 3.1 introduced the concepts of profiles, which is as simple as using the @Profile annotation.

First, configure an application context using the @Configuration annotation.

@Configuration
public class ProductionApplicationContext {
    public SomeBeanInterface myBean() {
        return new MyProductionImplementationOfSomeBean();
    }
}

@Configuration
public class TestApplicationContext {
    public SomeBeanInterface myBean() {
        return new MyTestImplementationOfSomeBean();
    }
}

Now we can specify which profile the context is associated with by adding the @Profile annotation

@Configuration
@Profile("production")
public class ProductionApplicationContext {
 // bean defs 
}

@Configuration
@Profile("development")
public class TestApplicationContext {
  // bean defs
}

Now when you start your app, provide the spring.profiles.active system property to specify the profile(s) to use. You can also specify the default profile to use in your web.xml file by adding the following block

<context-param>
    <param-name>spring.profiles.default</param-name>
    <param-value>production</param-value>
</context-param>