Testing time-sensitive logic in Java


It's astounding. Time is... fleeting (The Rocky Horror Picture Show)

Testing time-sensitive business logic is essentially about being able to change the current time in our tests - somehow - and then checking how this affects the behaviour of the domain object being tested.

The primitive and brute-force way to do this is to manipulate the computer system clock by manually changing the current time prior to each test...  Crucially this approach does not lend itself to running as part of an automated test suite, for obvious reasons.

The other (better) way is use two different clocks: the production code can rely on the system clock while the tests code will depend on a custom clock, i.e is a clock which can be setup to return any particular time as the current time. Usually this custom clock will expose methods to advance/rewind the clock to specific points in time. 


interface clock{
   public DateTime now();
}

class SystemClock implements Clock{
   public DateTime now(){
     return new DateTime();
   }
}

class CustomClock implements Clock{
    private DateTime now;
    public CustomClock(DateTime now){
       this.now = now;
    }
    public DateTime now(){
      return now;
    }
    public void tick(){
      now = now.plusDays(1);
    }
}

Both clocks realize the "now()" method defined in the Clock interface. The difference being that the now() method from SystemClock is a simple wrapper around a new instance of a Joda dateTime instance, while the now() method from the CustomClock returns a dateTime attribute which can be modified through the tick() method to make time pass faster :)

The custom clock will be injected as a dependency of the testing code and the system clock as a dependency of the production code. For a (somewhat contrived) example of how this plays out check out: https://github.com/eleco/customclock

First steps with... Cucumber JVM

Cucumber is a tool used to support behaviour driven development. Originally written in Ruby there is now a JVM version, called, quite logically, Cucumber-JVM

The basic idea (very summarized...) is to write acceptance tests for a new feature, together with the product owner, before the code is written. Then run the tests, see the tests fail, implement the missing behaviour, re-run the tests etc.. until the tests pass. 

The key objective here is to involve the product owners as much as possible in writing the tests, which from experience can be tricky as they do not generally have a technical background. So it's important for an acceptance tests framework to generate tests with a syntax which is a close as possible to a natural language. 

Cucumber achieves this quite well, see below for an example Cucumber script (click to zoom in)


The right panel defines the tests scripts to execute, easily understandable by non-technical people. No messing around with HTML either, a big win compared with alternative frameworks such as Fitnesse or Concordion.

The left panel maps the tests scripts to their associated junit tests. Full code source for this example is at: https://github.com/eleco/bdd


Cucumber outputs the tests results in a nicely-formatted page like so.





Deserializing/serializing JSON with GWT

A fairly typical use case: a GWT server-side component serializes java objects into Json, to be consumed by GWT clients.

Server-side serialization is actually very easy thanks to the google-gson library. It's literally a one-liner:
String json =new Gson().toJson(myObject);

On the client side things are a little bit more complicated. Gson (or any other library with features which are not supported on a GWT client such as reflection, dynamic class-loading, multithreading... ) cannot be used.

One possible alternative is to use autobeans

To deserialize a Person class
class Person {
   private String name;
   public String getName();
   public void setName(String s);
}

1. define an interface for the class to deserialize
interface IPerson {
   public String getName();
   public void setName(String s);
]

2. Mark the class to deserialize as implementing the above interface
class Person implements IPerson {...}

3. Define the interface extending AutoBeanFactory
interface Beanery extends AutoBeanFactory{  
   AutoBean <IPerson> createBean();
}

4. Instantiate the bean factory and deserialize
 
Beanery beanFactory = GWT.create(Beanery.class);
IPerson person = AutoBeanCodex.decode(beanFactory, IPerson.class, json).as();


Infinite scroll with GWT

The classical pagination pattern leads the user to click on numbered icons to navigate in a long list, each icon being associated with a different page in the list. This is how you browse google search results for instance. This is optimal when moving from page 1 to page 999, but not so much when moving from page to page in sequential order, which is the most frequent use case.

The alternative is the "infinite scroll" technique. Here the application detects when the user scrolls down to the bottom of the list, and automatically adds the result of the next page to the list. Scrolling can go on this way for as long as results are available to be added to the list, hence the term "infinite scroll". Obviously it's infinite in theory only... but I guess "very long scroll" doesnt have quite the same ring to it.

Building an infinite scroll component withb GWT is easy.... because it's already been done. Check out the GWT showcase  for an example. Or have a look at my side-project javadevjobs.com .

The key is in the ShowMorePagerPanel class (source code available from the showcase page) which listens for scroll events and  increases the display range when the it detects that the scrollbar has nearly reached its bottom position. This triggers in turn a rangeChangeEvent which acts as cue for the dataProvider to go and fetch more records from the database.











volatile piggybacking


Volatilty piggybacking is the (dubious ?) technique which attributes volatile-like semantics to non-volatile variables.

The new memory model , from java 5, states that "a write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field".

i.e writing to a volatile field creates a memory fence, which will flush the data held in memory cache, so that anything visible to the thread writing to a volatile field becomes visible to any other thread reading that same field. 

The "anything" in the sentence above might be a non-volatile variable - which will end up being visible to all threads in the same way the volatile which initially triggered the memory fence is. Thus the former piggybacks on the memory flush triggered by the later.


Examples of this technique in core jdk classes are hard to come by (ie. I havent found any...) . Possibly a reflection on how fragile that technique is. 


First steps with GWT Bootstrap


Gwt-Bootstrap is the port for Gwt of the Twitter Bootstrap framework. Twitter Bootstrap  defines a set of javascript and css components which are used to kickstart the development of websites (at least on the client-side).

The idea is to make it easy to develop a reasonably-good looking website without too much effort. Although of course a truly polished result will require additional customisation work on top of the framework. Twitter bootstrap also provides advanced features out-of-the-box, eg. responsive design (the components size is automatically adjusted function of the resolution of the device they're being drawn on to). 


How to use.

The best way to learn is to download the Gwt-bootstrap sources from Github and study the examples provided... but to sum up:

- Grab the GWT-bootstrap jar , version 2.0.3.0-SNAPSHOT at the time of writing.

- Add the jar to your project build path (menu File->Properties->Java Build Path in Eclipse)

- In the gwt.xml config file add a reference to the gwt-bootstrap library.
 <inherits name ="com.github.gwtbootstrap.Bootstrap"/>

- Assuming you're using UI binder then add the following namespace to the <ui:UiBinder> element.
xmlns:b="urn:import:com.github.gwtbootstrap.client.ui"

- the bootstrap components are now ready to be used:
<b:heading size="2">Hello World</b:heading>
    

Downsides.

- Gwt-Bootstrap it's still a work in progress. Not all Gwt widgets have been ported yet, eg.CellTable is missing at the time of writing.

- Most sites built with bootstrap tend to look a little bit similar. Greyish tones, the top navigation bar and the "Hero" unit underneath are the usual dead giveaways.


Examples.

Builtwithbootstrap has an extensive collection of websites leveraging Twitter bootstrap.

For Gwt-bootstrap specific websites - the main reference is the gwt-bootstrap showcase.


Edit 1: my side-project also runs gwt-bootstrap. Check it out.

Edit 2: one of the GWT-bootstrap committer copies most of the above post, without attribution. Now - as the saying goes imitation is the most sincere form of flattery but still that's another point in the downsides section - dubious ethics from (some) of the developers on this project.





Comparing csv files with the linux shell


My heart sinks whenever I witness people resorting to Excel to compare large files. It's kind of ok when the files to be compared are below 10K rows in size... anything bigger than that and the time it takes to select the rows to compare (and the comparison in itself) becomes too much of a frustration.

The alternative is to use the command line of course.

To compare two csv files file1.csv and file2.csv, columns to columns, on a Linux operating system.

step 1. copy all lines containing the string to search from the first input file
grep 'searchString' file1.csv > f1.csv


step 2. extract the relevant columns (here columns 3,4 and 5)
cut -d',' -f3,4,5 f1.csv  > cols_f1.csv


step 3. sort on the 2nd column (for example)
sort -k2  -t"," cols_f1.csv > sorted_f1.csv


step 4. remove duplicates
uniq sorted_f1.csv > uniq_f1.csv




Quite a bit of typing here... and that's only to extract the columns from the first file. Fortunately all of these commands can be piped.

steps 1,2,3 and 4 for the second file.

grep 'searchString' file2.csv | cut -d',' -f3,4,5 | sort -k2 -t"," | uniq > uniq_f2.csv



And finally the last step.  Show all lines unique to file1, all lines unique to file2 and all lines common to both files, arranged in a 3-columns output

comm uniq_f1.csv uniq_f2.csv