A database is for life not just christmas

If your wiz bang framework requires the database to be in a particular style (random fields, denormalisation) then dump your framework before you contaminate your database. If your design has any merit the database should be around much longer and have different clients that don't want your rubbish in their face.

How can software be so bad?

Currently working on a database system that costs customers serious amounts of cash per year and big money for configuration. It does pretty much what the charity case management system database we wrote but where as that takes about a week to produce a 250 field database this system takes months to do something vastly simpler. It is also slow and near impossible to use. Some of it can be put down to short timescales and people without the right skill sets but the bulk of it seems to be just lack of a tidy mind. Muddling different concerns and concepts. Ah well.

database as persistence bucket

RDBMS are rubbish as persistence stores for OO systems so why is it the norm to use them? It leads to sensible people using them as just a persistence bucket. Using them as the point of integration is seen as being very old fashioned. Maybe due to their age rather than elegance the tools alone make it very attractive.

Data legacy

Nice things like automated testing means coders can relax when it comes to code structure and actual implementation but definitely does not mean we can relax about data legacy. External APIs, even for people, build up a very hard to change legacy. Even more often forgotten is the rubbish that sometimes gets put into customer databases in a hurry to get a new version out.

Seems to me it is worth being very anal and putting a lot of thought into everything that will build up legacy. Public APIs, UIs, datastores...

Eclipse and CTRL-t

To remind myself in the future as much as anything. In interface heavy code bases like EJB3 apps CTRL-t in eclipse is very handy for finding the actual code you want to look at rather than the interface. btw I really need to get out more given how ugly I find "public" keyword on interface methods.

Logging hell

How did we manage to make such a mess of logging in Java? Yet another project that has been all the way through log4j, commons-logging (the worst), slf4j and managed to leave traces of all of legacy behind. Need to be brighter than me to work out where the logs are going. slf4j is miles better than commons-logging but don't think I've ever actually needed the abstraction.

Wicket Ajax

(Particular comparison with GWT)

• pro - very good for HTML only
• pro - good security - e.g. just as Java removed pointer arithmetic Wicket doesn't expose property paths, ids etc by default
• con - request synchronized on Session so Sjax
• con - very heavy server side requirements
• con - very complex code base
• con - ugly API compared to Swing etc
• con - every click goes to server (unlike GWT)
• pro - very helpful community
• con - requirement for ids is more annoying than useful
• con - dual HTML and component tree is annoying
• con - components must be serialised! Real pain.
• con - if server state is lost can't just get user to login again as state of UI is on the server.
• con - more care needed as action runs in same VM as page state (e.g. ensure tx does not fail before updating page state).