Some things that need to happen to enable this decision are
a) moving house
b) moving job
c) moving contents of said house to another country

It has been said that moving house and changing jobs are two of the most stressful things you can do. Throw in the international element, and the fact we have a three year old daughter, and this could potentially make us all a tad irritable. While there’s no silver bullet for solving all the logistical issues that are going to arise, I think that using good software engineering practices can take the edge off.

1. Co-ordination
What’s the best way for me to remember what needs doing? What’s the best way to divide tasks logically between my wife and myself? How can I keep track of what’s already been done?

Important questions, and the answer is just the same as when working on a project – use good tools! In this case, Jira is providing the heavy lifting – you can buy a 10-user license for US$10, and for that you can give yourself the ability to manage all the tasks for yourself and others from anywhere. Projects and categories mean the work can be divided logically. Works best if you have a server running at home you can expose to the internet.

2. Small changes aggregate into big features
Or, to put it another way, use small boxes! Using big boxes may have the psychological benefit of clearing a lot of items from site, but they are
a) heavy, possibly too heavy
b) unwieldy
c) not as flexible when it comes to transport or storage.

Small boxes, on the other hand, allow you to control the weight of the box more easily – a large box of books weighs a *lot*, and if you don’t throw your back out it’s still possible the contents will drop through the bottom when you pick it up! Another psychological benefit is you fill more boxes more often, and it feels like you’re making real headway into the packing.

More importantly, small boxes allow you to…

3. Release early, release often
Since we’re driving over to Belgium every couple of weeks for various reasons (looking at houses, job interviews…) it makes sense to take some of those small boxes with us, and leave them in a rented storage space (or friend’s garage). This has the benefit of creating more working space in the house – boxes aren’t building up with no immediate place to go – and reducing the number of boxes we need to move over in one go on the big day.

4. Constantly refactor
This is a good opportunity to locate things you no longer need, or items you have unnecessary multiples of, and get rid of them. By starting early on the packing process, this gives you the opportunity to freecycle or sell things instead of just taking the down to the dump.

Not an exact fit?
It’s impossible to make one discipline fit another exactly without a little massaging, but I think try to apply to activity A skills learned in activity B will often provide new ways of approaching a problem, or help to anticipate issues that haven’t yet arisen.

I also think that software development provides a more useful model than most – I’ve tried to avoid really forcing the two together (“hey, let’s treat potential buyers as peer reviewers!”), but since we tend to blend a wide range of practices and have lots of shiny tools for managing work it’s easy to use engineering practices on major life-related projects.

Looking through the Jetbrains documentation on its API for IntelliJ plugin development, it’s interesting to note their workaround for enforcing type safety in a map containing heterogeneous values:

• DataKey<T> – the access point to the map
• DataContext – an interface that can be used to wrap a map

This approach externalises the type-safety of the map’s content by shifting the casts to DataKey.

The interesting part of DataKey, from this viewpoint, is

@Nullable
public T getData(@NotNull DataContext dataContext)
{
    return (T) dataContext.getData(myName);
}

Read access is via the key, and not directly on the map itself, e.g. for a key

DataKey<Foo> FOO = DataKey.create("foo")

a type-safe call without a cast can be made on the wrapped via:

Foo foo = MyKeys.FOO.getData(dataContext);

The map-based implementations of DataContext just does a regular lookup with the key provided by DataKey:

public class MyDataContext implements DataContext
{
    private final Map<String, ?> data = new HashMap<String, ?>();
    @Nullable Object getData(@NonNls String dataId)
    {
        return data.get(dataId);
    }
}

and the returned object is cast to the correct type on the way out of DataKey. Simple and elegant.

It’s worth noting that both DataKey and DataContext are read-only in function – there’s a getData(), but no setData().   It’s easy enough to extend the concept to make sure that what goes into the map is of the same type as what comes out by adding a couple of extra methods, one on DataKey:

    public void setData(DataContext dataContext, T value)
    {
        dataContext.setData(getName(), value);
    }

and another on DataContext:

    public void setData(String key, Object value)
    {
        data.put(key, value);
    }

I’ve seen a lot of code where keys to access values from maps have been declared as static final Strings. Using DataKey, you could replace these declarations with DataKeys that specify the key to access the value and the type of the value itself, so

public static final String USER = "user";
...
User user = (User)map.get(USER);

would become

public static final DataKey<User> USER = DataKey.create("user");
...
User user = USER.getData(dataContext);

Going to my usual domain registrar, I bought itsnotyouits.me (in retrospect, not the most memorable domain so I’m kind of glad things worked out as they did…) and waited a couple of days for the DNS change to propagate. And a couple of days more, and then a couple more for good measure. Regardless of how many times I checked my typing, every time I pointed my browser at the domain it didn’t go to a landing page – it couldn’t be resolved.

Checking the Macedonian domain register, I found the following message:

The domain itsnotyouits.me is a Governmental Reserved Name and is available for registration only by eligible applicants.

This wasn’t mentioned when I purchased the domain, but when I called the domain name registrar they said the registration had been refused (and by the way, we’ll get a refund out to you immediately). Unless “It’s not you it’s” is Macedonian for Ministry of Defence, or maybe something unflattering about a prominent government figure, I can’t work out why it would be refused. Indeed, various other predictable domain names with give-or-take four letters seem to have been happily sold.

Any ideas?

<s:url var="url" action="%{link}" >
  <s:iterator value="parameters.keySet()" var="key">
    <s:param name="%{key}" value="%{parameters.get(#key)}"/>
  </s:iterator>
</s:url>

…and nothing happened. No parameters at all appeared in the URL.

Odd.

I got rid of the iterator and used a single parameter, just to check:

<s:url var="url" action="%{link}" >
  <s:param name="test-name" value="test-value"/>
</s:url>

That worked fine. One quick debugging session later and I found the problem – the Struts2 org.apache.struts2.components.Param component parameterises its parent component. In this case, the parent component is an iterator and so it was absorbing the parameters and they were never getting as far as the URL.

I couldn’t find a way to do what I needed the core Struts2 components and tags and so I created my own.

IterableParam overrides Param’s findAncestor method to return the grandparent component in the case where the parent is an Iterator:

<s:url var="url" action="%{link}" >
  <s:iterator value="parameters.keySet()" var="key">
    <ob:iterable-param name="%{key}" value="%{parameters.get(#key)}"/>
  </s:iterator>
</s:url>

Result – works as required.

Despite the title of this blog entry, any Struts2 component that can be parameterised using the <s:param> tag can be parameterised using <ob:iterable-param>.

You can get the new tag and component from

• binary: objectify-struts2-tags-1.0.jar
• source: objectify-struts2-tags-1.0-src.zip

Instead of having chunks of code such as

public class Foo
{
    private static String BLAH = "default-value";

    private String myString;

    private int myInt = -1;

    public static void main(String[] args)
    {
        if (System.getProperty("blah.value) != null)
        {
            BLAH = System.getProperty("blah.value");
        }

        Foo foo = new Foo();
        if (System.getProperty("mystring.value) != null)
        {
            foo.myString = System.getProperty("mystring.value");
        }
        if (System.getProperty("myint.value) != null)
        {
            try
            {
                String intValue = System.getProperty("myint.value");
                foo.myInt = Integer.parseInt(intValue;
            }
            catch (NumberFormatException e)
            {
                ...
            }
        }
    }
...
}

you can instead use objectify-led to bind the properties for you :

public class Foo
{
    @Property("blah.value");
    private static String BLAH = "default-value";

    @Property("mystring.value");
    private String myString;

    @Property("myint.value");
    private int myInt = -1;

    public static void main(String[] args)
    {
        Foo foo = new Foo();
        new PropertySetter().process(foo);
    }
    ...
}

By default, Strings and all primitive/wrapper classes are handled.  If you wish to convert a property value into a specific class, you just need to plug in your own object factory.

Additionally, the source of the properties is completely up to you.  By default, properties are taken from the system environment and any Properties objects you may have plugged in; custom property contexts can be used to provide a facade to more complex value stores.

Static values are handled in two ways. If an instance of a class is processed, both its instance and static members are populated if necessary.  If a class is processed, just the static members are populated (what with the lack of an instance and everything…).

Final properties- despite the ability to do so via reflection – are not set.  This may or may not change depending on feedback.

If you want to try out objectify-led, you can get the binaries and sources from the links below, or directly from http://www.objectify.be.  They will be submitted to the well-known Maven repositories in the coming days.

Binaries:

• objectify-led-1.0.1.jar
• objectify-led-1.0.1-bin.zip
• objectify-led-1.0.1-bin.tar.gz

Sources:

• objectify-led-1.0.1-src.zip
• objectify-led-1.0.1-src.tar.gz

IntelliJ has long been my favourite IDE.  In fact, it’s the only IDE I’ve ever liked – having used Eclipse, Netbeans, VisualAge for Java, NetDynamics and I don’t know how many others, only IntelliJ has ever delivered what I’ve wanted.

I personally belive that Eclipse’s current position as the favoured IDE (based on a long-running poll on Facebook) has purely been down to two reasons – it’s free, and key generators for IntelliJ are hard to google.

I’m going to be watching the outcome of this with extreme interest, having advocated and defended IntelliJ against Eclipse for  the last 8 years.

A comparison of the difference between the community and commercial licenses are available here.

There are two distinct conceptual areas in the video – the multi-touch interface, and the Con10uum desktop environment itself.    They meld (apparently) seamlessy, but I started to wonder how easy it would be to separate them out in order to bring the benefits of the desktop design to those who won’t or can’t easily use dexterity as their primary input mechanism.  In the same way that some people have trouble using a mouse but are able to cope with a trackball, physical barriers to the use of some technology will always be present.

In order to think about how well Con10uum would interface with a mouse, the major constraint is the typical 2-button mouse.  The limited buttons mean that using one would require a gesture-heavy input style.  This is, of course, exactly what the multi-touch screen uses but the key difference it the multi-touch environment is very friendly to gestures; it’s easy to imagine pinch-zooming or scrolling with a sweep of a finger because the result is close to the physical gesture itself.  Gesturing using a mouse is very much an exercise in training the user to remember what does what.

Luckily, the mouse is at heart a device to move a pointer from point a,b to point x,y.  Buttons, scrollwheels, navigations buttons. etc are just gravy – well, one of those buttons isn’t gravy but the rest certainly are.  Accordingly, I think it’s fair game to choose, if not some tooled-up übermouse, then at least one with a clickable scrollwheel and two navigation buttons.  They fit ergonomically onto a well-designed mouse (some debate about the scrollwheel may be inserted here by sufferers of carpel tunnel syndrome) and exist in a mouse that you can just stroll down to your local hardware store and buy.

What, then, can these buttons and gestures be mapped to?

Con10uum has global and local “edges” defiend at the extreme left- and right-hand edges that are activated when a finger-press is detected in one.  This is nice and easy – let’s assume that if the mouse pointer hits either edge and remains there for 1 second the menu pops up (all times are subject to arguments, bar fights, etc).

Scrolling left/right across the workspace can be assigned to the navigation buttons – one click equals one window to the left/right as appropriate.  Holding down either navigation button while using the scroll wheel would drop to the thumbnail view of all open applications.

Zooming in and out is – yawn – a function of the scroll wheel.

Repositioning windows to the left/right is done by grabbing the title bar and gesturing sharply to the left/right (had to be a gesture in there somewhere!).

Expanding windows would be done by an expand-to-visible-area button that doesn’t appear in the video.  I think it could be worked in easily enough, given all the other comprises we’re making at this point

I personally think the Con10uum desktop has got some legs to it, and I wouldn’t be at all surprised to see someone knock up at the very least a prototype for Linux.  I think the multi-touch input device – powerful as it is – will take a while to achieve mass market popularity and therefore shouldn’t be forced to slow anything else down.

However this turns out, it’s going to be interesting.

However, back in the present day a problem has presented itself.   While the code in the trunk has improved in leaps and bounds in terms of both high- and low-level architecture, features, modularisation, and to a lesser degree for this example, testing and documentation a parallel path of development has formed in one of the branches.

As previously discussed, branches are best used for fixing bugs in specific versions.  More than occasionally, a branch becomes the site of new development in order to cut out the overhead of migrating customers to newer versions – I’ve seen various reasons for this, but they’re of no importance as it’s the outcome that counts.

Depending on the timescale involved, and the amount of active development in both the trunk and the branch, the result may be two versions of the same project that are in essence both the latest version but are partially or totally incompatible with each other.

The problem can be alleviated to a greater or lesser degree by porting new features from the branch into the trunk.  If this is done diligently, this ceases to be a problem.  It’s still not a good situation to be in, but it is one less problem on your plate…for now, at least.

If porting doesn’t happen – due to perceived time contraints, difficulty in doing a quick port because of architectural changes, laziness, whatever – you’re heading into territory where the merge from hell lives.  Let’s take the example where a project which in the branch is a monolithic project built with Ant now exists in the trunk as a modular Mavenized project which has been refactored to the nth degree to improve many aspects; we now have two incompatible codebases that require reconciling.

There are a few approachs that can be taken here.  The brute force approach is to examine the branch compared to the trunk to build up a profile of files that have been added or removed.  You can finesse this process a little by comparing the branch to the trunk at the time of branching to get some addition information – but any major strucural changes to the trunk (like that described above) will negate this.  Once you’ve compiled your exhaustive list of files that have been added, removed or updated you can go through and copy each file from the trunk to the branch – ensuring in the process that you’re not introducing any bugs, incorrect assumptions, duplicate functionality, etc.  Also, make sure that you’re matching the new architecture and coding guidelines if you don’t want a rap on the knuckles from the other developers.

Another approach is to merge at the functional level, in other words port the features but not necessarily the code.  This may feel like a counter-intuitive approach given the features already exist in perfectly good code just over there, but digging those features out of the branch could well be as intensive – and probably a hell of a lot more frustrating – than implementing them afresh in the the trunk.

If all this seems like a lot of hard work – it is.  It’s far better to never get into this situation in the first place, but we live and work in a world where things have not always been as pragmatically optimised as we would like.  As we move towards cleaner, better tested and architecturally sound projects there are occasionally a few pit stops along the way.

Versioning is a crucial key of the development process for several reasons best described through the lack of versioning:

1. Want to see a great piece of code that was refactored out, deleted or otherwise lost six months ago? Hmm…
2. If you have multiple versions of a product used in live environments (by customers or yourself), how are you able to provide any form of bug-fixing without upgrading to the most recent version?
3. Want to experiment with a new architecture, build system, unit test library or general-purpose doomahickey without risking your current setup? Tough.
4. Is your code full of commented-out chunks that are kept around just in case? That’s poor man’s versioning!
5. And a whole bunch of other reasons that I’ll probably remember as soon as I hit the publish button.

The most basic – and naive – form of versioning if simply to take a copy of the codebase every so often and place it somewhere safe.  This is better than nothing, but it would require logic to be convoluted at Olympic level to persuade anyone it’s a reasonable approach; it smacks of the wrong kind of laziness – zero effort up front, and sustained effort for minimal gain on the back end.

Skipping over the part where a company decides the best solution is to develop an in-house versioning system, we can move directly to tried-and-tested version control systems (VCSs).  Many exist, both free and commercial, and whichever you decide will generally make your life easier.

In this particular example, I will use Subversion (http://subversion.tigris.org) , a.k.a. svn- a popular, well-established VCS system that enjoys support from the command line, and various continuous integration servers and IDEs.

Versioning with Subversion

At the core of the user interaction possible, Subversion works on a system of checkouts, commits and updates.  A quick definition:

• repository – a collection of versioned files within the svn server
• checkout – the process by which the versioned files, plus some svn-specific information, are copied from the svn server to a working copy (e.g. on your local computer, or on a continuous integration server)
• commit – an atomic operation where all the files added, removed or updated in the working copy are propagated back to the svn server.
• update – synchronizes the files of the working copy with those of the svn server.  This is used to pull the results of commits other than your own into your working copy.  Your own commits, by definition, are already in your working copy because that’s where you made the changes.

A typical project lifecycle in an imaginary world would be

1. Create project in subversion

2. Create or import the initial files

3..n-1. Commit and update files as you and other committers make changes to the repository

n. End of project

Anyone who has ever got to n, break out the champagne and take a five-minute break – you’ve either shipped the definitive (not to mention bug-free) version of the project, or you’ve just been downsized.  Nonetheless, this illustrates versioning with a single branch with no tags.  Each commit can be traced to a specific committer, and the development history of the project is kept for both posterity and code audits.

Branches?  Tags?

As mentioned above, versioning can be done in a linear fashion – one single line, with commits falling exclusively on that line.  In svn terminology, this line is called the trunk.

Versioning using the trunk only

A project that has multiple versions, however, needs to consider branching.  Branching, just as the name suggests, represents a major offshoot of the trunk.  In fact, it’s an exact copy of the trunk at the point the branching took place.  We now have, in effect, two parallel lines of development which are completely independent but have a common root.

The branch may represent, for example, the point at which version 1.1 was released.  The trunk would be branched into, say, MyApp-1.1, built, tested and shipped.  At roughly the same time as this, the person sitting opposite you just committed a major change that won’t be available until version 1.2 – this commit does not affect the 1.1 code, and so ongoing developments in the trunk do not corrupt bug-fixing endeavours in the 1.1 branch.

A more realistic development cycle would be

trunk.1 -  Create project in subversion

trunk.n..trunk.n-1 -  Commit and update files as you and other committers make changes to the repository

trunk.n – Branch code as new customer comes on board and makes various requests

trunk.n+1 – Continue working on new features, requirements, etc, no effect is felt by the branch.  Any bug discovered which also exists in the branch may have its fix ported into the branch.

branch.n.1 – Bug fixes, no effect is felt by the trunk.  Any bug discovered which also exists in the trunk may have its fix ported into the trunk.

A repository with branches and tags

When certain points are reached, for example when all the requirements are have been met, tags come into play.  A tag is a snapshot of the branch at a given point, and is useful for recalling the state of the project at a given point.  Tags should be used, at the very least, for each release;  they may also be used, for example, for internal tracking.

So you can only have one branch?

So far, the examples have centered around the trunk and a single branch.  This is fine for illustrative purposes, but remember that not only are multiple branches possible, it’s also possible to branch from branches.  In fact, you can think of the trunk as a branch with the only difference being it doesn’t have a parent.

Why version when the binaries tell the whole truth and nothing but the truth?

Pragmatism and laziness are, at the end of the day, two of the greatest attributes any developer can have.  They lead to automation, efficient processes and a tendency to get things right in the minimum amount of time.  Taking this into account, surely adding version control to your project is an unnecessary overhead?  After all, the binaries held by the customer not only fit their reqiurements but also contain exactly the bug that requires fixing!  The binaries can be requested from the customer, decompiled, patched, recompiled and redistributed.  Easy as pie, sweet as a pea, etc, etc.

If you’re going to take this route, you have to ask the customer for their binaries each and every time you have to fix a bug for them.  There is, of course, the possibility that you’ll keep a copy of each binary you send to them to avoid this unprofessional and embarrasing request…but if you’re going to do that, why not just version the source code in the first place?