The radar is basically the collective opinion of various ThoughtWorkers on the viability of a plethora of technology options, presumably gathered from the huge number of custom software projects they undertake each year. I found it very interesting and even started to read through a few of their older ones too.

They basically rate things on a 4 star scale:

• Adopt: Strongly recommend
• Trial: Worth pursuing
• Assess: Worth understanding
• Hold: Proceed with caution

Some of the things that jumped out at me from this years were:

Techniques

Tools

• Gradle and Rake both get a thumbs up (adopt) as build tools, while maven and ant continue to get a thumbs down (hold). I’ve been spending more time with Gradle recently, and am keen to move away from maven, so definitely agree.
• Splunk is a data index/search tool, e.g. for log files, that I have been using a lot recently and it continues to impress me. Although not mentioned in this issue of the radar, it has been favorably mentioned in past issues. It’s free version is more than feature rich enough for small to medium projects.
• D3: Data-Driven Documents. This is something that hasn’t been on my radar at all, but by the sounds of things, should be. It is an open source JavaScript library for displaying data in graphical form.

Platforms

• MongoDB gets a a thumbs up (adopt), Hadoop (2.0) gets a ‘trial’.
• AWS wasn’t explicitly mentioned, but has be been given an Adopt rating in the past, and I think is still what underpins many of the popular PAAS offerings out there.

Languages & Frameworks

• Scala and Clojure both get a thumbs up (adopt). I’m not too surprised by this as I have heard several ThoughtWorkers evangelize them in the past, and I am keen to continue playing with both more.
• Java has been flagged as ‘assess’ in previous editions and is not explicitly rated in the more recent one. It certainly seems to be increasingly viewed as a legacy technology. Still, I use it every day!
• HTML5 continues to get favorable reviews. For example HTML5 storage gets a ‘Trial’ rating.
• JavaScript frameworks
  • Interestingly, Node.js (server side JavaScript, using event driven async IO) gets a trial, but Node.js  with Jasmine (a BDD framework for testing JavaScript) gets a more positive thumbs up (adopt). I personally have been sceptical of Node.js. JavaScript on the server side sounds… weird, and I’ve heard that it can result in call-back hell, but I guess I need to reconsider!
  • The other JavaScript frameworks that seems to be viewed favorable were AngularJS (an open-source JavaScript framework from Google) with Knockout (JavaScript implementation of the Model-View-ViewModel pattern), and Require.js (a file and module loader for JavaScript). CoffeeScript (which compiles in to JavaScript) is also mentioned as one that continues to evolve well. Backbone.js gets a big old no (hold).
• Perhaps most interestingly of all to me was that component based frameworks (which, I think, in the Java world includes JSF, Wicket and Tapestry) get a big, unequivocal thumbs down (hold). GWT has also in the past (see July 2011 radar) been singled out as something to avoid. Presumably Vaadin falls in to the same ‘hold’ category. I’ve had limited exposure to these types of frameworks (I’ve worked more on the traditional request based ones, like Spring MVC), and it sounds like that is not a bad thing.

Overall, a thought provoking and insightful read from ThoughtWorks.

For me personally, my tech radar for the next few months includes getting more familiar with REST, exploring more of the JavaScript frameworks, and also looking more at Ruby on Rails. Clojure and Scala as language choice, and Gradle as a build tool also continue to interest me.

Feels like a good time to be a technologist…

Background to the Builder pattern

According to the GoF book, the builder design pattern is used to “Separate the construction of a complex object from its representation so that the same construction process can create different representations”. Like most of the GoF book, that is an accurate if dull description.

Josh Bloch, in his Effective Java book, suggests a more interesting use for builders. The problem his approach was trying to solve is when a class has “more than a handful” of parameters that would normally be set via a constructor, and many of them may be optional. Typical solutions are

• A telescoping constructor pattern, in which you provide a constructor with only the required parameters, as well as additional constructors with variations of the optional parameters, culminating in a constructor with all the optional parameters.
  This works, but makes for a fairly messy solution that has a potentially large number of constructors to cover all permutations
• A simpler constructor (e.g. for just the required parameters), backed up by setter methods for the optional parameters (the JavaBeans approach). However, this can leave an object in an inconsistent state during it construction and of course precludes immutability since fields can’t be made final.
• Use a Builder. This is the approach recommended by Bloch. The client creates a builder (often using a parameter-less constructor), then calls setter like methods for the values of interest (the rest assume default values), before finally calling a build method.

A few years back, I attended a talk in which Ted Young discussed taking the builder pattern a step further by using it for the construction of test objects, and it’s this approach that is discussed below.
[Update: see Ted's response to this post here]

Using the Builder pattern to construct test fixtures

Using a Builder allows test fixtures to be created more easily, and with clearer intent.

The type of test objects I typically use this Builder approach for are domain model objects, such as Account, User, Widget or whatever. I am a proponent of making such objects immutable.
For example:

public final class Account {
    private final Integer id;
    private final String name;
    private final AccountType type;
    private final BigDecimal balance;
    private final DateTime openDate;
    private final Status status;

    public Account(Integer id, String name, AccountType type,
                   BigDecimal balance, DateTime openDate, Status status) {
        this.id = id;
        this.name = name;
        this.type = type;
        this.balance = balance;
        this.openDate = openDate;
        this.status = status;
    }

    public Integer getId() {
        return id;
    }    

    //other getters, toString(), equals() and hashCode() omitted for brevity

    //no setters
}

With such a class, you often run into the problem Bloch discussed. In this example, we have a single constructor that forces you to set all values, but we could also have many variations where some values can be omitted to use default values.
So, creating an instance of such a class for tests can be somewhat painful, and more so if it has even more fields than this simple example. You are forced to provide values even for fields you may not care about for the test. That also makes it difficult to know which values are actually of interest for the test, and which are purely to make things compile.

A Builder can help.

Example

public class AccountBuilder {

    //account fields with default values
    Integer id = 1;
    String name = "default account name";
    AccountType type = AccountType.CHECKING;
    BigDecimal balance = new BigDecimal(0);
    DateTime openDate = new DateTime(2013, 01, 01, 0, 0, 0);
    Status status = Status.ACTIVE;

    public AccountBuilder() {}

    public AccountBuilder withId(Integer id) {
        this.id = id;
        return this;
    }

    public AccountBuilder withName(String name) {
        this.name = name;
        return this;
    }

    public AccountBuilder withType(AccountType type) {
        this.type = type;
        return this;
    }

    public AccountBuilder withBalance(BigDecimal balance) {
        this.balance = balance;
        return this;
    }

    public AccountBuilder withOpenDate(DateTime openDate) {
        this.openDate = openDate;
        return this;
    }

    public AccountBuilder withStatus(Status status) {
        this.status = status;
        return this;
    }

    public Account build() {
        return new Account(id, name, type, balance, openDate, status);
    }
}

Now you can create an Account object for testing much more easily.

Notes on using Builder for tests

• Default values

The default values used in a builder are a convenience to avoid exceptions. If your test needs specific values for a test, it is best to explicitly set them, rather than rely on any defaults. It makes the intent of your test clearer, plus minimizes the risk of inadvertently breaking tests if you ever need to change defaults (e.g. due to changing business requirements).

• Non-final fields

While the domain model class itself is immutable and hence has final fields. All fields in the Builder are, by design, non-final. Hence Builders are not thread-safe. So don’t reuse Builders; instead create a new instance for each test.

• Method order should not be significant

For the most part, the order that methods are called on a builder should not be significant, and the object will not be constructed until build() is called. This makes the builder easier to use and avoids unexpected surprises.
There are obvious and acceptable exceptions to this rule of thumb.
For example calling

Account account = new AccountBuilder()
            .withType(AccountType.SAVING)
            .withType(AccountType.CHECKING)
            .build();

is silly but allowed. It would just leave you with an account of type checking.
This is fine, but try to avoid more subtle causes of confusion, for example if you have a collection that can have something added, or the whole collection replaced (hence wiping out previous additions).

Advantages of using a Builder for tests

• Easy to read

The following declaration is not particularly clear:

    Account account = new Account(1, "test", 10, ...);

This declaration is much clearer:

Account account = new AccountBuilder()
                .withId(1)
                .withName("test")
                .withBalance(10)
                .build();

As Bloch puts it, “The Builder pattern simulates named optional parameters”.

• Only specify values that are actually relevant to your test

If your test is only concerned with account balance and status:

        Account account = new AccountBuilder()
                .withBalance(new BigDecimal(-100))
                .withStatus(Status.OVERDRAWN)
                .build();

As opposed to having to specify every value in the Accounts constructor.

• Ability to create invalid objects

The constructor of the domain model class will likely (hopefully!) force you to create valid objects. In your tests, you may want to deliberately create invalid objects for testing.

Further enhancements

Convenience methods

You can add convenience methods for common scenarios used in testing.
For example

    public AccountBuilder withNegativeBalance() {
        this.balance = new BigDecimal(-100);
        return this;
    }

Fixtures class

In addition to using a Builder class, I have also found it useful to have an associated fixtures class that provides pre-constructed instances for tests. These can make use of the Builder object for the construction (although there is nothing to stop you using the raw constructors too).
For example

public class AccountFixtures {

    //a shortcut to creating a basic Account object
    public final Account ACCOUNT = new AccountBuilder().build();

    public final Account OVERDRAWN_CHECKING_ACCOUNT = new AccountBuilder()
            .withType(AccountType.CHECKING)
            .withNegativeBalance()
            .build();

    public final Account CLOSED_SAVING_ACCOUNT = new AccountBuilder()
            .withType(AccountType.SAVING)
            .withZeroBalance()
            .withStatus(Status.CLOSED)
            .build();
}

• all fields being final and private
• no mutator (setter) methods
• class can’t be extended (e.g. make final) to avoid subclasses making things mutable
• provide exclusive access to any mutable components (e.g. getters provide defensive copies of collections)

See Item 15:Minimize mutability in Effective Java for more details.

mvn archetype:generate -DgroupId=com.shaunabram -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

This creates

my-app
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- com
    |           `-- shaunabram
    `-- test
        `-- java
            `-- com
                `-- shaunabram
                    `-- AppTest.java

Note this doesn’t create the (src/main/) resources folder. This posting suggests creating your own custom archetype. Creating the folder manually isn’t too big a deal though.

If you’re creating a web app, a better alternative to the quickstart archetype is to use the webapp archectype.

mvn archetype:generate -DgroupId=com.shaunabram -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

This creates

my-webapp
   |-src
   |---main
   |-----resources
   |-----webapp
   |-------index.jsp
   |-------WEB-INF
   |---------web.xml
   |-pom.xml

Software quality is critical to consistently and continually delivering new features to our users. This articles covers the importance of software quality and how to deliver it via unit testing, Test Driven Development and clean code in general.

Introduction

Unit testing has raised the quality of my code more than any other technique, approach or tool I have come across in the last 15 years. It helps you to write cleaner code, more quickly and with less bugs. It is also just feels good to write unit tests. That green bar in JUnit (or whatever testing tool you are using), gives you a warm fuzzy feeling. So, the bulk of this talk/article is about unit testing, and it’s smarter cousin, TDD.

There are however, many other steps you can take, outside of unit testing, to improve the quality of code; Simple things such as:
• good variable names
• short cohesive methods that are easy to understand at a glance
• avoiding code smells such as long nested if else if blocks
So, the final section of my talk will be on what some people call ‘Clean Code’.

But we’ll start by talking about why all this is important.
After all, design, clean code and unit tests are merely an means to an end.
And that end is: delivering value to users
And we should never forget that fact!

It is very important to be able to explain to project stakeholders, or indeed other developers, what the motivations and advantages are of unit testing and clean code, and how it ultimately results in value to users. And so, that is the basis for the introductory section called ‘The value of software design’.

1. The value of software design
2. Automated testing
3. Clean code

1. The value of software design

This section is largely based on a talk (key part starts around 45:00; see also the paper) I was fortunate enough to attend by a guy called Martin Fowler, the ‘Chief Scientist’ at a company called ThoughtWorks.
In the talk, Fowler did a great job of answering a question I had been thinking about a lot: Why should we care about ‘good’ design in software?

People may put forward questions and statements such as

• We need less focus on quality so we can add more features
• Do we really need unit tests?
• Refactoring doesn’t change what the code does, so why bother?

And it can be difficult to answer those questions, particularly when you are under pressure to deliver, and quickly.

On approach is to take the high moral ground.

For example, there are people who adopt the attitude that

1. Bad software design is a sin
2. If you are not writing unit tests, with 100% unit test code coverage, you are a BAD developer
3. Poorly named variables or methods will be branded on your flesh as you burn in the fiery pits of hell for your sins

Basically,  treat the issue as a moral one – you are a bad person (or at least a bad developer) if you are designing poor quality software.

However, most of us work for a living, and if we are going to take the time and effort to produce quality software, we need to have an economic reason for doing it – otherwise, why bother? If the software we are writing is not least providing significant benefit to our users and stakeholders, we probably shouldn’t be doing it.

Remember our goal: Deliver value to users

What does Quality even mean?

But before we get into what economic reasons for good software design are, let’s talk about what Quality even means when it comes to software?

Well, it could mean a few different things, including:

• Quality GUI (easy to use, looks good, intuitive)
• Few defects (bug free, no unintelligible error messages
• Good modular design

However, only the top two are actually apparent to users/customers/business sponsors. And yet this talk/article focuses almost exclusively on the last one – the one that users have no concept of!

And it’s not just users; Does your manager stay awake at night worrying about the quality of the code that you’re producing? Probably not. I bet your manager’s manager definitely doesn’t! And your CEO probably doesn’t even know what code is.

So if management and users don’t care about quality code, why should we, as developers care?

Fowler’s Design Stamina Hypothesis

Well Martin Fowler did a good job of describing why using what he calls the Design Stamina Hypothesis.

• The y axis represents how much new functionality you are adding to the app
• The x axis represents time
• The orange line represents a hypothetical scenario where you create an app with no design (and design definitely includes unit tests)
• The blue line represents a scenario where you create an app with good design

Without design

Fowler’s Design Stamina Hypothesis basically says that if you write code without a good design, you will be able to deliver code very quickly to start with, but your progress will become slower and slower over time and it becomes more and more difficult to add new features as you become bogged down

• in spaghetti code
• fixing bugs introduced when you inadvertently broke an piece of code you couldn’t understand
• spending hours trying to understand code before actually being able to change it (and still have little confidence that you’re not messing it up)

In the worst case sceanario (shown above by the blue line tapering off), it will become so slow to make changes that you will likely start to consider a complete rewrite of the application. Because rewriting the entire thing, and the months/years of effort and blood/sweat/tears that that will take is actually more attractive that dealing with the mess you have created.

So, how do we avoid that worst case scenario, and what economic benefits can we reap?

With good design

Well, the second part of Fowler’s Design Stamina Hypothesis is how cumulative functionality is affected by good design. Designing, writing tests, using TDD may take a little longer in the short term, but the benefit is that in the medium to longer term [the point on the graph at which the lines cross), it actually makes you much faster.

• Adding new features takes about as long as you’d expect it to
• Ever junior developers, or new team members, can add new features in a reasonable amount of time

And in many cases that point is after days or weeks rather than months or years.

Design Stamina Hypothesis summary

In agile software development, the term often used to describe the amount of new functionality added over a period of time is velocity. Fowler’s notion on good design increasing velocity is just an hypothesis because it can’t be (easily) proved, but it intuitively makes sense to most people involved in producing software.

Design Stamina Hypothesis: Design is what gives us the stamina to be able to continually add new features to an application, today, tomorrow and for months and years to come.

Technical debt

Basically what Fowler is talking about here is the concept of technical debt. Technical debt is a metaphor referring to the eventual consequences of poor design in a codebase. The debt can be thought of as extra work that needs to be done before or in addition to the real work that you need to do. For example, having to improve a design before you can actually add the new feature users have requested.

Under the technical debt metaphor, that extra work can be thought of as interest payments.

Interest payments can come in the form of

1. Bugs
2. Just understanding what the heck the current code does
3. Refactoring
4. Completing unfinished work

How to deal with technical debt

When you encounter technical debt in a project, you basically have 2 options open to you: Pay down or accept.
Paying down the debt involves spending extra time to clean, refactor and improve design.
The benefit is that it will ultimately speed you up since you’ll be able to add new features faster. The downside is that it will inevitably slow you down now.

Accepting the debt means doing the minimum required to add/change features and moving on. The interest you will pay going forward is the additional cost you incur above and beyond adding new features; Everything is slowed down and complicated by the extra complexity. In addition, it is also much more difficult for a new dev on the team to pick up. And last but by no means least, developer morale suffers! No developer enjoys working in an unmaintainable mess of code; And developer turnover is a very real cost.

So, when we come across code in our projects that is poorly designed, should we take action? Refactor, add tests, tidy up?

For a long time, I thought the answer to that question was simply Yes. Always. However, Fowler makes an excellent point that it is not always economically sensible to do so.

If it ain’t broken, don’t fix it

Even of a module is a bunch of crap; Badly written, with no tests and poor variable names etc;  If it

• (surprisingly) doesn’t have any bugs in it
• does what it is supposed to
• AND If you never need to change

Then why worry about it? In technical debt terms, it is not exerting very many interest payments.

Don’t build bad on top of bad

On the other hand, if that badly written code needs to be updated with functionality, or if you find yourself ‘in it’ all the time (even just to understand it), then it becomes important to pay down technical debt and to keep the code clean and easy to maintain & enhance

Summary of the value of software design

Good Design, tests and good coding practices  etc, are only a means to an end and that end is delivering value users. However, they are very useful in meeting that end. They give us the stamina to continually and consistently deliver functionality faster, with less bugs to our users and so have very real economic benefits

And with that, let’s look at what it means to actually use good design techniques via the use of automated tests for software…

2. Automated testing

Unit testing

A unit test is a piece of code that executes a specific functionality (‘unit’) in the code, and

• Confirms the behavior or result is as expected.
• Determines if code is ‘fit for use’

Unit testing example

    public int factorial(int n) {

        if (n == 1) return 1;

        return n * factorial(n-1);

    }

}

And being good developers, we add a test to make sure the code does what we expect:

public class MathTest {

    @Test

    public void factorial_positive_integer() {

        Math math = new Math();

        int result = math.factorial(3);

        assertThat(result).isEqualTo(6);

    }

}

And if we run the test, we will see it passes. Our code must be correct?

Well one good thing about tests is that they make you start to think about edge cases. Anobvious one here is zero. So we add a test for that. In mathematics, the factorial of zero is 1 (0! = 1), so we add a test for that:

public class MathTest {

…

    @Test

    public void factorial_zero() {

        Math math = new Math();

        int result = math.factorial(0);

        assertThat(result).isEqualTo(1);

    }

}

And when we run this test… we see that it fails. Specifically, it will result in some kind of stack overflow. We have found a bug!

The issue is our exit condition, or the first line in our algorithm:

if (n == 1) return 1;

This needs to be updated to check for zero:

if (n == 0) return 1;

With our algorithm updated, we re-run our tests and all pass. Order is restored to the universe!

What unit tests provide

Although our previous example demonstrated unit tests finding a bug, find bugs isn’t the unit tests primary benefit. Instead, unit tests:

• Drive design
• Act as safety buffers by finding regression bugs
• Provide documentation

Drive design

TDD can help drive design and tease the requirements out. The tests effectively act as the first user of the code, making you think about:

• what should this code do
• Border conditions (0, null, -ve, too big)

They can also push you to use good design, such as

• Short methods
  • difficult to unit test a methid that is 100 lines long, so unit esting forces you to write modular code (low coupling, high cohesion;
  • Test names can highlight violations of SRP; if you start writing a test name like addTwoNumbers_sets_customerID correctly, you are probably doing something very wrong
• Dependency Injection

Basically, writing a class is different from using a class and you need to be aware of that as you write code.

Act as safety buffers by finding regression bugs

Have you ever been in a bowling alley and seen those buffers or bumpers they put down the side of each lane for beginners or kids, to stop the ball running out? Well unit tests are kind of like that. They act as a safety net by allowing code to be refactored without fear of breaking existing functionality.

Having a high test coverage of your code allows you to continue developing features without having to perform lots of manual tests.  When a change introduces a fault, it can be quickly identified and fixed.

Regression testing (checking existing functionality to ensure it hasn’t been broken by later modifications to the code) is one of the biggest benefits to Unit Testing – especially when you’re working on a large project where developers don’t know the ins and outs of every piece of code and hence are likely to introduce bugs by incorrectly working with code written by other developers.

Unit tests are run frequently as the code base is developed, either as the code is changed or via an automated process with the build. If any of the unit tests fail, it is considered to be a bug either in the changed code or the tests themselves.

Documentation

Another benefit of unit testing is that it provides a form of living documentation about how the code operates. Unit test cases embody characteristics that are critical to the success of the unit. The test method names provide a succinct description of what a class does.

Unit testing limitations

Unit testing of course has its limitations:

• Can not prove the absence of bugs

While unit tests can prove the presence of bugs, they can never prove their absence (They can prove the absence of specific bugs, yes, but not all bugs). For example, unit tests test what you tell them too. If you don’t think of an edge case, you probably aren’t going to write either a test of the functionality to handle it! For reasons like this, unit tests should augment, never replace, manual testing.

• Lot’s of code (x3-5)

In the simple unit test example we saw earlier, the unit tests had about 3 times the amount of code as the actual code under test – and there were still other scenarios we hadn’t tested yet. In general, for every line of code written, programmers often need 3 to 5 lines of test code. For example, every boolean decision statement requires at least two tests. Test code quickly builds up and it all takes time to write, read and maintain, and run.

• Some things difficult to test

Some things are extremely difficult to test e.g. threading, GUI.

• Testing legacy code bases can be challenging

A common approach to adding unit testing to existing code is to start with one wrapper test, then simultaneously refactor and add tests as you go along. For example if you have a legacy method that has 200 lines of code, you might start by adding one test that, for a given set of parameters gives you a certain return value. This will not test all the side effects the method has (e.g. the effect of calls to other objects), but it is a starting point. You can then start refactoring the method down into smaller methods, adding unit tests as you do so. The initial ‘wrapper’ test will give you some degree of confidence that you have not fundamentally broken the original functionality and the new incremental tests you add as you go about refactoring will give you increased confidence, as well as allowing you to understand (and document) the code.

It is worth pointing out though that in some cases, the setup for objects not originally designed with unit testing in mind can be more trouble than it is worth. In these cases, you need to make the kind of decisions we discuss earlier in the technical debt section.

So, given all those limitations, should we unit test? Absolutely! In fact, not only should we unit test, we should let unit tests drive development and design, via Test Driven Development (TDD).

Test driven development

TDD Intro

Test-driven development is a set of techniques which encourages simple designs and test suites that inspire confidence.

The classic approach to TDD is Red – Green – Refactor

1. Red— Write a failing test, one that may not even compile at first
2. Green— Make the test pass quickly, committing whatever sins necessary in the process
3. Refactor— Eliminate all of the duplication created in merely getting the test to work

Red- green/refactor—the TDD mantra.

No new functionality without a failing test; no refactoring without passing tests.

TDD Example

As with straight unit testing, TDD is best explained via an example. However, this section is best viewed as code screen shots. See the presentation slides here.

A few points are worth noting from the TDD example:

• Writing the tests resulted in code that is clean and easy to understand; likely more so than if we had added tests after the fact (or not at all)
• The test names act as a good form of documentation
• Finally, there is about five times more test code than the code we were testing, as we predicted earlier. This emphasizes why it is so important to refactor the test code just as, it not more, aggressively than the actual code under test.

So far we have looked why we should be concerned with good design in the first place, and how we can use automated tests to drive and confirm our design.

Next, we are going to talk about how to spot issues with an existing code base by looking for code smells…

3. Clean code

One way to ensure clean code is by avoiding ‘code smells’.

What is a code smell?

“Certain structures in code that suggest (sometimes they scream for) the possibility of refactoring.” Martin Fowler. Refactoring: Improving the design of existing code

A ‘smell’ in code is a hint that something might be wrong with the code. To quote the Portland Pattern Repository’s Wiki, if something smells, it definitely needs to be checked out, but it may not actually need fixing or might have to just be tolerated. The code that smells may itself need fixing, or it may be a symptom of, or hiding, another issue. Either way, it is worth looking into.

We will look at the following code smells:

Jenkins builds via DEV@cloud

The first is the what CloudBees call DEV@cloud and what I simply think of as an online Jenkins instance. I am a big Jenkins fan (at home and work) and having a cloud based Jenkins instance is invaluable. The GitHub integration means I can check in code and have all tests run and a war file build automatically. I tend to use maven as the build tool for my projects, so with DEV@cloud’s ‘Poll SCM’ turned on, all I have to do is check in a change, and it builds. Nice.

Automatic deployment to the cloud via RUN@cloud

The second cool thing about CloudBees (and the deal winner for me) is the automatic deployment option. When I check in a new piece of code, not only will CloudBees do a maven build for me, it will also deploy it to the cloud. And all it takes is clicking a single checkbox. Literally. They couldn’t possibly have made it any easier. By default, it will be given a URL such as yourappid.youruserid.cloudbees.net, but this is configurable. The cloud deployment is what CloudBees call RUN@Cloud

And beyond…

At a certain point of course, you need to start being more specific about how to deploy an app than just saying ‘deploy it’. That is when the Cloudbees SDK comes into play. Download it and you can then start specifying details of the deployment such as a specific JVM/Java/JRE version, memory options, security, scalability etc.

So far, I’ve been using CloudBees for prototypes such as this Handsontable / SpringMVC example, a SpringMVC file download example, a SpringMVC HelloWorld template I use for bootstrapping projects, and a simple app for managing money called MyMoney. But everything I’ve seen suggests CloudBees as a viable solution for live, production cloud-based apps.

For the record, I have no relationship with CloudBees other than a happy user.

The code for the example is posted here on GitHub and has also been deployed here on CloudBees.

For this example, the server simply returns the data back to the client where it is displayed in a results section of the same JSP. The data is posted as JSON via a JQuery AJAX call.

The code follows the example posted in the accepted answer in this Stackoverflow question.

In addition to the usual SpringMVC setup, the key parts are:

• Adding a maven pom dependency on Jackson, to handle the Json to Java conversion (automatically detected by SpringMVC)
• Use the SpringMVC @ResponseBody and @RequestBody web binding annotations in your controller methods to ensure that Spring converts the Json to and from your java objects
• Making sure the JQuery Ajax call includes the correct headers and data type, as in:

  jQuery.ajax({
      type: "POST",
      headers: {
          'Accept': 'application/json',
          'Content-Type': 'application/json'
          },
      'dataType': 'json',
      ...
  });

Again, the full code of the working example is posted here on GitHub and deployed here on CloudBees. I use continuous deployment by using a Jenkins instance, also on Cloudbees.

    @RequestMapping(value = "/Excel", method = RequestMethod.GET)
    public void handleFileDownload(HttpServletResponse res) {
        try {
            String fn = "/Test.xls";
            URL url = getClass().getResource(fn);
            File f = new File(url.toURI());
            System.out.println("Loading file "+fn+"("+f.getAbsolutePath()+")");
            if (f.exists()) {
                res.setContentType("application/xls");
                res.setContentLength(new Long(f.length()).intValue());
                res.setHeader("Content-Disposition", "attachment; filename=Test.xls");
                FileCopyUtils.copy(new FileInputStream(f), res.getOutputStream());
            } else {
                System.out.println("File"+fn+"("+f.getAbsolutePath()+") does not exist");
            }
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }
    }

Where:

• “/Excel” is an arbitrary path name (can be anything)
• “Test.xls” resides in src/main/resources

The code uses Spring’s own FileCopyUtils for making the file available.
The complete maven project can be found here on github and the deployed project can be found here on cloudbees.

The app is running at http://mymoney.shaunabram.cloudbees.net and the sourecode is available via GitHub.

Similar to the simple HelloWorld SpringMVC app I posted a while ago, I created this as a way to get more familiar with certain technologies, rather than as a serious app. It uses JSP/CSS on the front end, Java & Spring MVC on the server with a MySQL database accessed via Hibernate (as well as the in-memory HSQLDB database for tests).

It also utilizes Continuous Deployment. Any new check-ins are automatically tested and built (using maven) and deployed using Jenkins and CloudBees.

There are a bunch of things I will do differently on the next pet project I undertake, such as using MyBatis instead of Hibernate (this post sums up my current feelings very well), utilizing Selenium and using Twitter Bootstrap instead of raw css, but for now, I am shelving this project in its current form and moving on.