Objectify

Summer is almost here, the days are long and my good lady wife and I have decided to sell our house here in England and move over to Belgium (my wife is Belgian) for the rest of our lives.

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.

Java’s generics have undoubtedly made life easier in some cases by enforcing type safety on collections. One collection that frequently does not benefit from them is maps used in a heterogeneous way – that is, a java.util.Map (or equivalent) that contains several non-compatible values. Assuming the keys are of the same type, it’s still not possible to type the value of the map as anything other than a java.lang.Object – exactly what it would have been prior to generics.

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);

Having recently been thinking about a new project, I started looking at available domains and was attracted to Macedonian .me domains as both useful and playful in what you work into them.

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?

In an annoucement earlier, Jetbrains announced a community version of IntelliJ IDEA.

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.