(Re)Programming

Posted on by

I have recently started a new project at work on which I’m both the only architect & developer. This project is an extension of an existing one but rewritten from the ground up. I’m taking this opportunity to look back at my past work and select things that have worked for me, as well as drop those that didn’t. I also have the chance to check out the latest technologies on offer to the Java web programmer of today.

Underpinning my decisions are several key ideas. First and foremost is the need for open source software (which is a strong thread here in ILRT). Secondly it must work on non-javascript enabled browsers. This is partly for policy reasons, partly for accessibility reasons but mostly because I believe that’s how websites should be designed (I’ll leave this discussion for another post). Finally the desire to do things ‘the right way’ – by which I mean using good programming methodologies, standards compliance, design patterns, documentation and though testing throughout. The bane of many a developer is to attempt to adhere to these while under pressure from deadlines.

This time round I’ve chosen to use as many of the latest and greatest (as well as some of the more well established) technologies as I can get my hands on. So the list includes…

  • Log4j – everybody needs a good logging system 🙂
  • Spring – which I now think is a fantastic framework (once you get the hang of things). I’m learning as I go but I already have some issues around MultiActionController not being quite the all-in-one it should be (and no, FormController just doesn’t cut the mustard in highly ajax environments)
  • Spring JS, – bit of a shame I have to use their supplied Dojo framework. Really had to hack it a bit to override their decorator pattern so that I could add decorators dynamically with my own bit of javascript. It needs to play better with others. I’m also saying no (or at least a ‘not yet’) to Spring Webflow at this point.
  • Spring Security – yep, yep, yep.
  • Hibernate – can’t quite make up my mind on hibernate yet. So far its been slightly quicker to get hibernate out of the box and running then for me to write my own interface layer. When I see the shear number of queries Hibernate is making just retrieving a single User object I do wonder if I could write more efficient code. I also had to do quite a horrible hack just to get pagination working. Maybe when I tweak the config files or start hitting really large data sets I’ll find hibernate will come into it’s own.
  • Tiles – I suspect most people think JSF is the better framework, however tiles are A. conceptually very simple to work with and B. great for working with spring’s ajax tile support.
  • CSRFGuard – after one of our in-house developers produced something similar for Zope I realise this type of protection is must. I’ve not tried it yet however.
  • DWR – DWR allows me to directly call my Spring validators from the client browser. I’ll go into more detail about Ajax provision in a later post.
  • jQuery – I really love jQuery. Its parallel with CSS selectors and the ability to easily decorate page elements is really handy.
  • YUI (specifically their compressor and html widgets) – I really like the pick-and-choose nature of the YUI library and the fact that those guys really know their stuff. A minor point is that I had to hack their compressor so that I could call it from inside java classes rather then from the command line.
  • JUnit – You don’t need me to remind you that you should always have unit tests supplied along side the source code. Spring makes unit testing your applications a breeze. However in recent weeks I’m starting to wonder if the real value in application testing is not with unit tests themselves (which simply tests if your code works as you expected it to work – in a one developer environment why wouldn’t it?), but instead with integration tests (testing that your code plays well with others). Maybe the subject for another blog posting.
  • Selenium – I’ve already played with selenium a few times in the past. It’s a really great tool and essential for cross-browser testing, however the real problem is in keeping your scripts inline with your interface. Its all too easy to make a minor modification to your html which renders all your selenium scripts invalid.

This is all topped of with a light dusting of NetBeans 6.5 as my IDE of choice to contain everything.

So onto some of my initial thoughts….

Documentation

I have had a lot of success using TiddlyWiki as a documentation tool. I use it to keep journal entries, todo lists and explain the workings of the code as I go so. It’s my design document, readme file and todo list all in one 🙂 It looks way better then a plain txt file and I feel having a documentation system that is easy for others to contribute to is always a plus.

Event logging

Before I used a database table to record user login details. This was useful however it never really told me what my users were doing (for that I’d have to delve into the application logs)

Accesslog := id|sessionid|referrer uril|timestamp

In my new system I use an event log. Rather then just keeping authentication requests, events such as login, logout, creating objects, updating objects, deleting objects, sending messages etc will all get logged. This helps me keep much better track of user activies, easily view what is happening on my system without having to dig through lots of logs and potentially offer users the ‘view login activity’ feature often seen in online banking systems. It really becomes and all-in-one provenance tracker.

Eventlog := id|userid|action|referencetype|reference|timestamp

The action specifies the human readable description of the action, the referencetype represents the name of the db table the action occurred in while the reference is the id of the object the action is performed on.

e.g.

292|5|'User logged in'|'User'|5|123456789
293|5|'Create Report'|'Report'|62|123457000
294|5|'Report updated - title changed'|'Report'|62|123457290

Working with Designers

One of the real problems with a UI built from fragments is that it becomes really hard to track down where elements of the page come from. Was a real issue for me and our graphical designer on the last Plone site I developed. It is only really recently with the introduction of tools such as GloWorm that tracking the location of page templates on a Plone site become easier. I was determined that my application shouldn’t fall into the same trap. My solution is to insert comments at the start and end of each tile or page fragment in my application as in the following example:

<c:if test="${DEBUG}"><!-- START ${requestScope['javax.servlet.include.servlet_path']} --></c:if>
// JSP code here ...
<c:if test="${DEBUG}"><!-- END ${requestScope['javax.servlet.include.servlet_path']} --></c:if>

Now if I enable debug mode, the resulting html is littered with handy comments explaining where each piece of html comes from. This solution is not as automated as I’d like; it would be better to have these statements inserted automatically for me by the application somehow, but at least I could hand over all my JSP pages to a designer in one go and tell them to get on with it.

That’s enough to be getting on with for now. I have a lot of other ideas flying around my head so look forward to a few more posts from me in the near future.