I finished up yesterday with the Ministry of Justice in Wellington, NZ. I believe I finished on a high, and I'm very glad that I've been able to make a strong contribution to the IUP programme, and, I'd like to believe, have left behind something that has lasting value.
I believe my thoughts on what I've learnt thus far can be best categorised by the technology I've been using recently:
Oracle APEXI'm an Enterprise Java person by training. I left university thinking: more layers and more compartmentalization are the only way to go. I'm thinking along the lines of the
OSI model and MVC here, and this pattern of thought can be extended to all software development ad nauseum.
Over the last few years we've seen an attitude shift in the Java world, moving towards lighter frameworks and processes. So I really welcomed a chance to customise
Oracle APEX, which is in some ways at the other extreme of the spectrum.
There are
two layers (if you consider the database a layer)! No MVC. From one point of view, it's a Mickey-Mouse approach to software development harking back to the dark ages. Any level of complexity beyond "save the values in this page to this table in the database" would (probably) become quickly unmanageable. Thing is though, there
are applications out there which don't
need any more complexity than that! And that's where Oracle APEX really excells.
All developers to whom I showed the framework to were amazed at how quickly we could construct a fully-fledged application (a matter of hours) that would have taken weeks in a Java enterprise solution. And this was including all the mod cons like role-based authorization, disaster recovery and an extremely attractive exterior (I based the theme on the Ministry's very pretty intranet).
Of course, this still has to be dealt with by someone, somehow, but this can be done up-front just once for the entire organisation, and maintained centrally from then on. Most enterprise applications I've seen don't use organisation-wide components for authentication/authorization, look-and-feel etc, and some projects implement and maintain these items better than others.
Jasper ReportsOne thing that APEX doesn't do well on its own is reporting. Oracle are pushing BI Publisher for an arm and a leg. Tomas Babic and I were searching for alternatives, and until about 2 days before we had to turn in our solution options report, the only real alternative about was my own XSLT-and-OpenOffice solution (which I had developed because of the prohibitive cost of BI Publisher). I was proud of it, but I knew it wasn't as easy to work with as I would have liked.
Then Tomas finds
Jasper Reports, and I'm so glad he did. It turned out that Jasper Reports (and their design tool) was exactly what we were looking for, and it would be relatively easy to write an interface which would allow APEX to use Jasper templates, seemingly by magic. I threw my own solution out the window and wrote a tiny servlet which would act as the interface instead. I'm very proud of how small and graceful the implementation is, and how little it does to achieve a great deal by exploiting the work of others.
(Then I wrote a ton of documentation to ensure that others would know how to use and maintain what I left behind.)
I've learnt these lessons over my (still humbly short) career, which have materialized in my latest work:
- Don't over-engineer. Just do enough to manage the complexity you expect. This frees you up now and in the future to do the stuff that really matters.
- Always look hard for good 3rd party solutions and integrate these instead of writing your own.
- Where you have to write your own solution, code it once, code it well, and try and ensure it's used across the organisation.
Of course, it's laughable to claim that I've single-handedly come up with a revolutionary way of doing things. I'm merely riding the Zeitgeist, and have made full use of the hard work of others. Anything that I've written is as small as possible, which I feel is the way to ensure reliability and future maintainability.
