Technological justice

In The Age today, it's reported that the Federal court backed iiNet. Finally some sane and reasonable justice from the courts in technological matters.

Well done iiNet.

How to prepopulate your GAE dev_server for testing

This post assumes that you know how the Google App Engine Datastore basically works, and how to perform local unit testing of your code on the dev_server provided in the GAE SDK.

There is a massive gaping hole in the GAE SDK, both in terms of functionality and documentation (of course if there is some documentation on the matter please post it in the comments) in regards to the population of your local datastore (which is persisted to a file) for testing. Why does this matter? For integration, or acceptance testing. Not all testing my Google Overlords wants to be done in a memory only datastore, or within the one process/JVM/however Eclipse runs my dev_server and my JUnit tests.

Even if you setup your test code to point to the same file that your dev_server is reading from, your application wont see your entities. To say it's a frustrating problem is an understatement. Turns out there is a combination of fields that have to be set in your test code for the underlying datastore code to populate the file in such a way to get this to work

Rather than repeat the solution, it can be on the ever helpful Stack Overflow

This solution was found though a lot of pain, trial and error. I hope someone gets a use out of this post to prevent them agonising over the amount of blood lost from when their head hit the desk screaming "why Google why!!!!"

How to beat the competition by being more agile

Over at Forbes there's a discussion about how Facebook beat MySpace. The simple solution I got out of that was Facebook is more agile, but that they also priotise customer input. Enough users want something, Facebook gives it to them (and one would assume as fast as possible). That's responding to change, obviously a key Agile principle.

Makes me think about how doing business might continue to change over the years. The suits and the bean counters may want to do one thing (lots of Powerpoint presos with forecasts), and the techs on the ground might only be thinking three months ahead - getting the latest feature out the door. There's something to be said for long term vision but do short term sprints take precedence? After all the company has to make money to keep the suits in a job.

One thing Facebook does need to do is focus on quality. To much of it breaks (and often non deterministically). The fact that I can't invite friends to an event now for three days means something's going dreadfully wrong. Since you listen to customers Facebook, can you please fix your defective parts as well as push out the latest and greatest features?

Holidaying with Android Froyo

Over the Christmas break, my wife wants to do some traveling. Which is all good and well, except that I have some coding that I want to. I'm sure that a lot people experience this problem.

My biggest annoyance was the lack of internet to look up API docs/reference material on the road for some tech that I want to dabble with. So I considered getting a 3G wireless modem.

Last week, my HTC Magic got upgraded to Froyo (2.2.1 actually), which of course comes with the ability to tether via USB to my computer. A quick google found instructions on how to enable the tethering on Gentoo Linux. A quick kernel config and module compile; followed by some bash scripting to modprobe cdc_ether, rndis_host and usbnet - and I had a usb0 interface sitting next to my eth0 interface. DHCP takes care of getting an IP address from the phone and I'm connected. If you're a Gentoo user, you should symlink /etc/init.d/net.lo to /etc/init.d/net.usb0 like net.eth0 for a convenient startup/shutdown script. One of the best bits is that the phone charges off the USB as well so I'm not draining the battery.

I even used my tethered connection to load Vodafone's coverage map for where we're going to show to my wife. Though knowing Vodafone the best laid USB tethering plans of mice and men are oft to go awry

Moving On

Today I've started at another company Intunity. Despite having to brush up on my Mac skills :p, this should be fun.

Separating out container concerns for unit testing

I got a request - come help me with these failing unit tests. The cause? The dreaded Null Pointer Exception. A member variable wasn't initialised in the constructor, but in in an init() method annotated with javax.annotation.PostConstruct. The inital impulse was to call init in the tests, but this would have led to other problems as other member variables would try to acquire container resources via JNDI (and a ServiceLocater pattern), and since this is a unit test we are mocking those dependencies. The better idea is to factor the initialisation of the attributes that are needed all the time into the constructor (which solved the NPE problem), and those attributes that are holding container resources into the @PostConstruct method since the container will honour the annotation; whereas in the unit test we can setup up the dependencies with mocks. A nice little trick but one that's very powerful.

A better approach is of course to use a DI framework, but that still doesn't get around a bad design. Separating container concerns into a @PostConstruct method (and using constructor injection perhaps) makes the class more testable with the tests taking the responsibility for being the container.

DTOs can be your domain model

Thanks to the powers of the web I can across this blog post today, To DTO or not to DTO. Reading it made me think about how we model data in our EE systems.

I disagree with Gunther that "You must maintain two separate models: a domain model in the backend that implements the business functionality and a DTO model that transports more or less the same data to the presentation layer." Not necessarily true. Quite often the way you represent the model in Java is a natural representation of the entity and thus can be reused by different layers of the system. Take a Customer for example. The properties of a Customer, their name, address, etc wont change between the DB and the system the Call Center person is using to lookup a customer's profile. So why not have a single model that gets reused?

I think it comes down to two reasons. The first is that we think we need "DTOs" and "Entities" and other EE artifacts. Which is conceptually true, but thinking that way causes us to separate the modeling approach so that we end up with different models. But why not reuse the Java class and morph it into whatever EE thing we need? Use ORM tools to squeeze the object into your relational table structures. Use other tools for transmitting and presenting the model (serialisation into XML via JAXB can do this)

The second is a technological issue. We bind a model to a certain layer limiting it's reuse. This is extremely noticeable through the use of annotations and the way they bind us. Using XML deployment descriptors in the correct layer can help us avoid this technological limitation.

Of course you may need to deviate from a single model, but I would question why first? There may be a legitimate technical need, or poor design decision made by a senior architect. If you do have to have two models, make sure that you don't get bogged down in mapping between the two.