Frank Carver's Punch Barrel

The JavaZone conference has a reputation for the quality and cleverness of its promotional videos, but this year’s takes it to a whole new level.

Don’t watch this if you are offended by some (OK, quite a lot of) swearing. It may be coarse, but it’s very much in keeping with the style they have chosen.

4 minutes of pure movie deliciousness.

JavaZone 2012: The Java Heist

I originally chose to work in Ruby for its ease of deployment to low-cost shared hosting services, but as time has progressed I have become more comfortable with the language and a selection of tools and libraries. One that I like a lot is the Sinatra web framework. Interestingly it now appears that if I wanted, I could run Sinatra applications in a Java web container such as Tomcat, Resin, or Jetty using Warbler, which bundles JRuby and an application into a standard war file for drop-in deployment.

This is an interesting challenge to my own pure-Java Mojasef framework, which offers several similarities with the approach taken by Sinatra. Sinatra wins on documentation, though

A good guide to getting started with Sinatra and Warbler can be found at Sinatra on Java | Coreguardian.

A “workflow engine” is becoming the new must-have for enterprise system development. In days gone by it might have been an automatic choice to go for an expert system, Enterprise Service Bus, messaging infrastructure or big-ticket database, but those now seem a little bit passé.

There are several commercial workflow engines available, and a whole bunch of open source ones. Here’s a list of workflow engines written in Java, for example.

Boris Lublinsky has written an article at InfoQ expressing the strong opinion that writing your own workflow engine should not be an option.

I’m not sure I completely agree. For me the most telling part of the article appears near the end:

People today rarely implement their own database or O/R mapper or application server. Why is it often that people think that they should write their own workflow engine?

As it happens, I have implemented my own database, O/R mapper and application server, and found the experience invaluable in understanding the challenges and important features of such software. Writing a workflow engine would presumably be a similarly valuable lesson.

A few months ago I made the decision to move the Stringtree and Mojasef code-bases on from their requirement to support older Java versions. I tagged a particular version of the code as “1.4 final” and proceeded to work through the trunk code in the repository to bring it in line with key Java 5 features such as generics, varargs and the enhanced for loop.

Since then I have progressively realized that I may have been a bit optimistic. A few odd bugs have been found in the 1.4 code, and a few key improvements have been made to the Java 5 code which by rights should also be implemented for 1.4. So I have decided to try and fix the situation.

As of today, the tag “1.4-final” in both Stringtree and Mojasef should be considered as deprecated, and any code which used to use that tagged version should instead use the branches (“Stringtree for Java 1.4″ and “Mojasef for Java 1.4″) I have just created. Initially, the code is identical, but the plan is to go through and apply known bug fixes and fully-backward-compatible internal improvements to the branched versions.

The news was pointed out to me by a friend before I could blog about it, but Google App Engine supporting Java and servlets is a massive move forward for server side Java.

I’m currently experimenting with my own evaluation of this, but in the meanwhile, here’s Michael Yuan’s take on it.

Michael Yuan » Blog Archive » Google App Engine for Java — First Impressions

Like many teams, I’m sure, we are trying to squeeze every drop of effectiveness out of our time. Manual build and deployment not only takes up valuable time, but also acts as a drag on the development process. Anything which pulls developers out of “the zone” is a bad thing for productivity.

We usually use the familiar “ant” build tool for building deployable artefacts, but have found it increasingly fiddly as our expectations have grown. And ant is hardly useful at all for real-world deployment tasks.

It may be the time to re-consider other build and deployment options.

Thread.current.to_s: Let’s use real languages for builds

I use Test-Driven Development (TDD) every day, and find it very helpful. It can be hard to get to grips with, though. I was pleased to read that acceptance-testing pundit Gojko Adzic had fun with some very strict TDD rules.

Gojko Adzic » Thought-provoking TDD exercise at the Software Craftsmanship conference.

My approach to TDD is really quite similar to these strict rules. I’ll admit that I do (sometmes) cut a few corners. The biggest aid to getting the most from TDD is definately good refactoring tools. Without that the whole thing becomes so much more clumsy.

TDD is very comfortable with Java and Eclipse. Recently I have moved out of that comfort zone into some fairly deep JavaScript work, and really miss the ability to automatically extract or move methods etc.

I have always liked the Resin application container. I often use it to develop servlet and J2EE applications, even ones which are eventually deployed on another server. Resin is fast, clean, and easy to manage. Its cool ability to run PHP as well as java is a bonus.

Now it’s even cleverer, and it includes a bit more trendiness.  Resin 4.0 supports a git repository as the underlying storage for web applications, with all the versioning and updating benefits which that implies.

Read more at Caucho Technology » Blog Archive » reliable deployment using .git.

In my dark moments I worry about the security of cloud computing. I used to be pretty upbeat about security, until some servers I was using to run a small specialist java hosting business were hacked. This resulted in the collapse of that business and the loss of several customer sites. Since then I have been painfully aware of the need to keep any public system scrupulously up-to-date with security patches and suchlike.

My security worries give me concerns about launching a business based on Amazon’s EC2, as I cannot see at the moment how the fiddly details of keeping the virtual system images patched an up to date will happen. Please feel free to reassure me!

When I read the title of this article from the Java Developer’s Journal, this was my immediate thought. The article does not address this particular issue, but instead covers some of the problems of protecting data in transit between distributed systems.

I’ve still not got fully up to speed on using Amazon’s cloud services, but this looks useful. A whole bunch of code examples and libraries for a variety of languages

Amazon Web Services Developer Community : Amazon SimpleDB.

For some time I have beem mulling over the posibilities of deploying applications to low-cost wireless routers to provide hyper-local services to wi-fi surfers. One thing which has always put me off is the apparent need to dig deep into low-level Linux hacking. It’s a *long* time since I last did any significant C development.

However, it seems that there are ways to support a small footprint Java virtual machine on some of this class of devices. This in turn opens up opportunities for deploying some of my own small-footprint java software here.

Wolf Paulus’ Web Journal:PhoneME, a JavaVM for the Fonera FON Router.

Mobile application development is certainly a hot topic at the moment. People seem to be climbing over one another to produce iPhone apps, and Google’s Android is never far from the tech news. But there are also other players, and several want to enable a more familiar web development experience on mobile devices.

SitePen Blog » PhoneGap, Palm Pre, and the State of Mobile Apps

An interesting proposal to solve some of the common, and tedious, issues around Java nulls. Particularly comforting is that I have already separately implemented ?: with very similar semantics in my Stringtree template language.

Stephen Colebourne’s Weblog

Test-Driven Development (TDD) of HTTP and REST interfaces can be tricky. This post contains some examples of how to do it using the open source Mojasef toolkit. I was prompted to write this post after recently finding and fixing an irritating bug using just this technique.

First, let’s set the scene. In TDD the rules are very simple: No production code is written without a failing test; just enough code is written to satisfy the current set of tests; duplication is mercilessly refactored. TDD is a very powerful and effective technique which can improve both the quality and delivery time of software. HTTP and REST interfaces provide access to a system or component using the HTTP protocol. This access may be by fetching HTML or WML pages, for example, or it may be by sending, receiving and updating resources in some other format such as XML or JSON.

For a first scenario imagine we have an existing HTTP interface for which we want to write a client using TDD. This service is relatively simple to start with. To send a message requires a POST request to a particular URL with two parameters “destination” and “text”. If the destination is valid, the text message is sent to the destination and a “200″ status code is returned. If the destination is not recognized, a “404″ status code is returned. This interface is so simple that it is tempting to just write the client, test it manually and move on. But if we were to do that, then we might not think of all the test case possibilities, and there would be no regression tests to help protect the software from unexpected side-effects later. So we opt to do the right thing, and use TDD.

For the sake of simplicity, I will assume we are using the Stringtree HTTPClient as described in an earlier post. So let’s start with a simple test to make sure the code compiles and the test libraries and stuff are in place:

import org.stringtree.http.*;
 
public class MessageSendingTest extends junit.framework.TestCase {
  public void testExceptionFromUnknownURL() {
    Form form = new Form();
    form.put("destination", "name@example.com");
    form.put("text", "hello from HTTP");
    HTTPClient client = new HTTPClient();
    try {
      client.post("http://localhost:9999/send", form);
      fail("should throw an exception");
    } catch (Exception e) {}
  }
}

This test serves two purposes. First, compiling it helps drive the structure of the test case, what classes need to be imported and so on. Second it documents the expected behaviour of our client if the server is not running or not where it is expected to be. I always like to start with this sort of “null” test case wherever possible. Once we get this test working we are ready to move on to the next step, testing against an actual server.

It might be possible to test against a real server, perhaps by manually examining log files, or checking the actual receipt of a message. Feel free to do that, but understand that that is really integration testing rather than unit testing, and neither helps us design and debug the client, nor document and enforce the proper behaviour of our code once we move on to other work. To gain these benefits we need a server which may be started, examined and stopped quickly and under the control of a simple unit test. This is where Mojasef comes in.

Mojasef is a server and web application framework designed for efficient test-driven development of web applications. Although usually used for building applications, it is just as suitable for building test harnesses. In this case we will build a simple application which implements the HTTP interface described above. And yes, we will do it using TDD, so we leave the MessageSendingTest for the moment and start a new one to drive our test harness without requiring HTTP. As usual, I start with a “null” test to get started:

public class MessageHarnessTest extends junit.framework.TestCase {
  MessageHarness harness;
 
  public void setUp() {
    harness = new MessageHarness();
  }
 
  public void testNoAction() {
    assertFalse(harness.wasCalled());
  }
}

This won’t compile without a MessageHarness class, so let’s make the minimum necessary.

public class MessageHarness {
  public boolean wasCalled() {
    return false;
  }
}

Good, our test now runs, so let’s add some behaviour. First another test:

  public void testCalledWithoutArguments() {
    harness.send();
    assertTrue(harness.wasCalled());
  }

To make this compile we need to add another method to MessageHarness

  public void send() {
  }

Our new test fails, so we need to make it work.

public class MessageHarness {
  private boolean called = false;
 
  public boolean wasCalled() {
    return called;
  }
 
  public void send() {
    called = true;
  }
}

That seems enough to start with. Now back to the main test case. Add a new test to call the application we have just built over HTTP and check that all the communication stuff works. With a bit of refactoring to keep the tests clean and duplication low.

import org.stringtree.http.*;
import org.stringtree.mojasef.standalone.InlineServer;
 
public class MessageSendingTest extends junit.framework.TestCase {
  HTTPClient client;
  Form form;
  InlineServer server;
  MessageHarness app;
 
  public void setUp() throws Exception {
    client = new HTTPClient();
    form = new Form();
    app = new MessageHarness();
    server = new InlineServer(app, "9998");
    server.start();
  }
 
  public void tearDown() {
	server.halt();
  }
 
  public void testExceptionFromUnknownURL() {
    form.put("destination", "name@example.com");
    form.put("text", "hello from HTTP");
    try {
      client.post("http://localhost:9999/send", form);
      fail("should throw an exception");
    } catch (Exception e) {}
  }
 
  public void testHarnessWiring() throws Exception {
    form.put("destination", "unknown@example.com");
    form.put("text", "hello from HTTP");
    assertFalse(app.wasCalled());
    client.post("http://localhost:9998/send", form);
    assertTrue(app.wasCalled());
  }
}

This probably needs a bit of explanation. The MessageHarness class we produced above is a Mojasef web application. Really, without any other configuration, base classes or nonsense. It’s just a “plain old Java object” (POJO). The job of the Mojasef code is to take an object of that class and make its methods available as HTTP URLs.

To serve it over HTTP we could use a MojasefServlet and run it in any Servlet Container, but for this test we want an ultra-light server which can be started and stopped in a test. So we use the InlineServer provided in the Mojasef jar. It’s a real HTTP server which you can use from a regular web browser, but it’s mainly designed for streamlined use in tests.

This server is configured to serve the MessageHarness application on port 9998. Having configured the server we start it in startUp and stop it in tearDown to ensure that nothing is left behind between tests.

The new test makes a HTTP request to the freshly started server, then checks (by calling the MessageHarness method we created earlier) that the test harness application was successfully called. This verifies that the server has been correctly started and called.

It’s still not really testing the message API. To do that we need more tests.

Now, we know from the introduction above that our resource should return a HTTP 404 (“not found”) error if we try to send to an unrecognised address.

  public void test404FromUnknownDestination() throws Exception {
    form.put("destination", "unknown@example.com");
    form.put("text", "hello from HTTP");
    Document result = client.post("http://localhost:9998/send", form);
    assertEquals("404", result.getHeader(HTTPClient.HTTP_RESPONSE_CODE));
  }

Making this test work is pretty simple, especially as we have no other tests which say anything about the HTTP Response code. The only “cleverness” is that we now need to use some slightly smarter features of the Mojasef code.

import org.stringtree.finder.StringKeeper;
import org.stringtree.mojasef.HTTPConstants;
 
public class MessageHarness {
  private boolean called = false;
 
  public boolean wasCalled() {
    return called;
  }
 
  public void send(StringKeeper context) {
    called = true;
    context.put(HTTPConstants.RESPONSE_CODE, "404");
  }
}

Mojasef will try a variety of ways to call a public method. We have seen the basic one – a method with no parameters mapped directly to a URL. This is another one – a method taking a “context” as an argument. This context will be pre-loaded with any POST or URL parameters, as well as any request headers and plenty of other stuff which is not of interest right now. This context also provides a way of setting information to be sent back to the client.

Now, our application code is passing all its tests, but it does so by returning a “404″ error code for all requests. This is not really desirable behaviour, so we need another test:

  public void test200FromKnownDestination() throws Exception {
    form.put("destination", "known@example.com");
    form.put("text", "hello from HTTP");
    Document result = client.post("http://localhost:9998/send", form);
    assertEquals("200", result.getHeader(HTTPClient.HTTP_RESPONSE_CODE));
  }

This test fails, so we need to modify the application to add some understanding of the supplied form data.

import org.stringtree.finder.StringKeeper;
import org.stringtree.mojasef.HTTPConstants;
 
public class MessageHarness {
  private boolean called = false;
 
  public boolean wasCalled() {
    return called;
  }
 
  public void send(StringKeeper context) {
    called = true;
    String destination = context.get("destination");
    if ("known@example.com".equals(destination)) {
        context.put(HTTPConstants.RESPONSE_CODE, "200");
    } else {
        context.put(HTTPConstants.RESPONSE_CODE, "404");
    }
  }
}

Now we reach an interesting point in the development process. It is perfectly feasible to continue in this vein, step-by-step bringing the application into existence. However, even the streamlined InlineServer still needs to set itself up, bind and unbind ports, deal with network traffic and so on. This is considerably slower than a regular method call, and as more tests are added the test case will continue to slow down.

The advantages of the Mojasef approach to web applications really begin to pay off at this point. The tests we already have prove the basics of HTTP Communication are working, so further tests do not really need to bother with HTTP, provided the tests are testing exactly the same code. Luckily (as pointed out earlier) a Mojasef application is just a regular Java class, which needs no modification to be tested using regular JUnit tests. Here are the same tests as above, but implemented as simple method calls:

import org.stringtree.finder.StringKeeper;
import org.stringtree.mojasef.HTTPConstants;
import org.stringtree.mojasef.HTTPConstants;
 
public class MessageProcessingTest extends junit.framework.TestCase {
  StringKeeper context;
  MessageHarness app;
 
  public void setUp() {
    context = new MapStringKeeper();
    app = new MessageHarness();
  }
 
  public void test404FromUnknownDestination() throws Exception {
    context.put("destination", "unknown@example.com");
    context.put("text", "hello from HTTP");
    app.send(context);
    assertEquals("404", context.get(HTTPConstants.RESPONSE_CODE));
  }
 
  public void test200FromKnownDestination() throws Exception {
    context.put("destination", "known@example.com");
    context.put("text", "hello from HTTP");
    app.send(context);
    assertEquals("200", context.get(HTTPConstants.RESPONSE_CODE));
  }

I shall stop there, leaving the development of the rest of the application to interested readers.

From the above steps, I hope you can see that the normal process of Test-Driven Development is quite possible for both web applications, and web-application clients. When using a framework which gets all the fiddly stuff out of the way it can even be as simple, quick and productive as in-process development.

I was excited to read that the Grizzly Java server framework has had an update as I am currently trying to evaluate embeddable HTTP servers for several projects.

I downloaded the grizzly http server jar and clicked through to the associated “Getting Started!” page of example code.

It seemed so simple: knock together a fresh Eclipse project, and create a new test class containing the example code:

package test;
 
import java.io.IOException;
 
import junit.framework.TestCase;
 
import com.sun.grizzly.http.embed.GrizzlyWebServer;
import com.sun.grizzly.tcp.http11.GrizzlyAdapter;
import com.sun.grizzly.tcp.http11.GrizzlyRequest;
import com.sun.grizzly.tcp.http11.GrizzlyResponse;
 
public class GrizzlyHTTPTest extends TestCase {
  public void testServer() {
    GrizzlyWebServer ws = new GrizzlyWebServer("/var/www");
    try{
      ws.addGrizzlyAdapter(new GrizzlyAdapter(){  
        public void service(GrizzlyRequest request, GrizzlyResponse response){
          try {
            response.getWriter().println("Grizzly is soon cool");
          } catch (IOException ex) {            
          }
        }
      });
      ws.start();
    } catch (IOException ex){
      ex.printStackTrace();
    }
  }
}

Once I had found the right includes etc. it compiled happily. Although I was a little worried that the “addGrizzlyAdapter” method appears as deprecated. So I ran it.

It ran. Or more to the point, it ran and finished. My test gave a me a green bar, when I was expecting a hung process while it waited to serve pages. When I tested it with a browser (trying several common ports) I got no response.

I am now thoroughly puzzled, This is completely different behaviour to any server framework I have tried so far, and the “Getting Started!” page offers no help.

Does anyone know how I could start a Grizzly HTTP server and have it run for long enough to actually serve some pages?

At work I have three monitors on my desk – one 20″ wide-screen and two 17″ regular monitors. At home I have just two somewhat mismatched 17″ monitors. Admittedly, in both cases all the monitors are attached to different computers, but using Synergy they respond to the same mouse and keyboard.

I do a lot of programming using Eclipse, for example, and I have found that the widescreen monitor is considerably more effective than the old 4×3 style. The extra width gives room for a variety of toolbars and navigation panels at the side of the screen. I have tried using multiple monitors on a single computer but have never found a satisfactory way to use them. Splitting a single desktop always seems to result in windows with a big opaque bar down the middle, which I hate, and makes the “full screen” window button effectively useless. So far I have not found any desktop settings which support the option of “full screen” filling the display the window is currently displayed on. Perhaps I should try harder!

It’s sometimes more difficult to justify getting a bigger monitor for home development, than for one used at work for paying customers, though.

Coding Horror: Does More Than One Monitor Improve Productivity?

As I was driving home from work yesterday it occurred to me that Sun seemed to somehow have missed a golden opportunity a few years ago. Their motto for ages was/is “The Network is the Computer” but the names everyone thinks of for “cloud” technology do not include Sun. What is most saddening is that several years ago Sun had some incredibly cool technology which, looking back, seems a perfect fit for the new cloud-based world. I’m referring to Jini, Sun’s auto-scaling, auto-provisioning, mobile code, service-discovering network thingamabob.

I loved the idea of Jini when it was first released (I still have half a dozen Jini books around my office), but it had some significant problems. Most important was the general fiddliness of getting anything working. Even a simple “hello world” demonstration required messing with class paths and running several picky and fragile command line scripts. A world of difference from the state of web application deployment at the time. Despite several point releases, this never really got any easier or more comprehensible. Jini certainly helped make the complex possible, but it certainly did not make the simple, simple.

When I got home after this rumination, I looked around a bit to see what had happened to Jini and if it had any relevance in the brave new world of Amazon and Google. I was pleasantly surprised.

One of the key early Jini services was JavaSpaces. Equally fiddly to set up and comprehend, but powerful and scaleable, and very much in the spirit of the grid/cloud approach. Effectively, Jini and JavaSpaces have developed to become GigaSpaces, a commercial product which attempts to solve the problems of Jini and present it as a contender in today’s world. A sure sign that the GigaSpaces folks “get it” is the way they are integrating with Amazon’s cloud offerings.

The extent of my experimentation so far has largely been limited to following their “hello world” tutorial on my local system. There were one or two hitches, such as the parts of the tutorial code which use Eclipse requiring the project directory names to start with “hello-”, but the build/run batch scripts requiring names without the prefix. Other than that, the process was pretty painless, certainly compared to my experiences with early Jini. Next steps are to try creating my own small application, then to deploy it on the “cloud” and see if the ease of use continues.

As it stands I am impressed.

I can’t think of any real uses for this right now, but I can think of lots of possible uses!

thekua.com@work » Validating JVM Arguments in Code

My personal preference is almost always to deal with a database at a fairly direct level. I have built up a bunch of Java code which largely removes the pain of database access, but it is certainly not any kind of ORM (Object-Relational Mapping) tool. I rely on understanding both the structure and efficiency of the database, and the clarity and effectiveness of the code.

This article recounts one development team’s problems with using too high a level of abstraction for data persistence, and forgetting that there is a database at the bottom of their pile of software.

No New Ideas: ActiveRecord lessons learnt: #1 Never forget there’s a database

Up until recently, I was using a WordPress plugin called “WP-codebox” to format my code samples in this blog, but today it broke my RSS feed, so I have abandoned it. I liked the “geshi” syntax highlighting engine used inside it, but unfortunately it generated flaky HTML, and was not smart enough to disable JavaScript in feeds.

I have now replaced it with WP-syntax. using it is very similar, just wrap code examples in (for example)

<pre lang="Java">
class Whatever {
  public void thing() {
    if(thisHappens()) {
      doThis();
      doThat();
    }
  }
}
</pre>

gives

class Whatever {
  public void thing() {
    if(thisHappens()) {
      doThis();
      doThat();
    }
  }
}

Please let me know if you have any problems with the appearance of code samples, especially if you use a feed reader or aggegator.