I must apologise (that’s if anyone did notice) for not really keeping up with this blog in the recent several weeks. I certainly plan to continue the blog; it did seem such a good idea at the beginning, but I’m afraid that I have had a lot of distractions recently.

Version control
In fact I have completed the Griffon apps that I started to describe – thanks to pressure from the users – so you’ll have to treat the new few entries as a sort of action replay. However I did find out a couple of weeks ago that I had missed something in one of the Griffon release notes which meant that I could do a bit of recoding. And so I thought that I’d actually set up some VCS since we now have an “initial release” to save.

Because I’m also writing a Grails app I wanted a VCS to handle all the projects but I was a bit disappointed in that some do seem a little inflexible. Grails is the greater issue, but perhaps that’s another story. In the end I decided on Mercurial with TortoiseHg as a quite nice graphical client. (I should have mentioned that at the moment the work is WINDOWS XP-based.)

Back to the Griffon
I suppose that having actually finished the apps it should make writing about them a little easier, well I certainly hope so! The preliminary stuff was fairly general so next time we’ll just start with the Model and take it from there; it actually worked out rather straightforward in the end so I hope that I can get through the development in a few more posts.

And then I have a few more ideas for Griffon apps, the next time will be using SQL but we’ll have to see how well that goes. This is in addition to our main Grails project, of course, although I can see some scope for a Griffon app that will provide some desktop functions related to the main project.

Hopefully I now have a bit more spare time and I will finish the write-up of the application over the next few days.

I mentioned before that MigLayout looks to be the best way to go, so I set up a few trials (and errors, of course) and came up with a decent layout with which to start. It’s not the final version, there are a lot more fields to add, but it does show the sort of thing that can be achieved fairly quickly. There is plenty of documentation on the MigLayout website and, of course, the relevant jar to download and it was easy to create the following form:

and all this needed was the following code

import net.miginfocom.swing.MigLayout
application(title:'p45pt3',
//size:[320,480],
pack:true,
//location:[50,50],
locationByPlatform:true,
) {
panel(border:emptyBorder(12),layout:new MigLayout("wrap 4","[100][200][100][200]","")){
  label("name :",constraints:'right')
  textField("enter name", constraints:'wrap, width 150:150:')
  label("reference :",constraints:'right')
  textField("employee reference")
  label("NI number :",constraints:'right')
  textField("nino")
  label("date of birth :",constraints:'right')
  textField("dd-mm-ccyy")
  label("gender :",constraints:'right')
  textField("m/f")
  label("starting date :",constraints:'right')
  textField("dd-mm-ccyy")
  label("job title :",constraints:'right')
  textField("?")
}
}

This is by no means complete, there are no binds, for example, but it shows the layout quite nicely. What we wanted was simply two columns of entry fields, so here’s how it gets there:
1. new MigLayout(“wrap 4″,”[100][200][100][200]” ,”")
there are three arguments: the first is for the layout, here “wrap 4″ means that it will wrap to the next line after four fields (label, textField, label, textField); the second is for column constraints, what “[100][200][100][200]” gives is four columns with those widths (default in pixels); the final argument defines the row constraints, which is null at the moment.
2. add the various labels and textFields, I’ve used mostly defaults except for the “right” on the labels to right-justify the label text, and on the “enter name” textField I’ve used “wrap” to end that row and “width…” to define the actual width of the box (otherwise they are given the size of the initial contents).

I’ll use this style for the full form, but adding a few extra constraints to improve the appearance.

And then tomorrow, I’ll get it actually working…

Interviews – who needs them ?

At the moment I’m rather, well very, short of money and I have been looking for work, so when I saw a posting on a UK website looking for a developer in, well let’s say, language A, and “experience in B an advantage” and they were developing a “C” package and I can tick all of those boxes,  I sent off my CV, and I received an invitation to to an interview. Now, there was nothing in my CV to suggest that I had a great depth of experience in A nor B, just a couple of years, but I do know the C application very well; however it became apparent very quickly in the interview that they weren’t looking for someone like me and the person they wanted would have had much more experience than I have (and what it says in my CV) but, apparently, they wanted to see me because of the combination – “not many people with that in their CV”, I was “top of their list of fifty CVs, the first we’ve seen”. All very well, but really there was no way they would have employed me based on the type of person they said they were looking for. They did mention just how far I have travelled, more than once – and that’s what really irritated me, they did realise just how long the journey took and how inconvenient it was. And so for the apparent sake of “just having to meet me” they had me travel nearly 400 miles in really bad weather, wasting a day of my time (left at 9.30, back at 19.25), no apologies, no “compensation” just a couple of handshakes and a “thank you”… A right bunch of pillocks, is what comes to mind – well a lot stronger, actually. So I am very annoyed…

NetBeans and the Griffon plugin

I briefly mentioned this in the previous posting but I’d only heard that there was a new version that day and hadn’t had much opportunity to have a look at it. I’ll be getting back to it now, but so far it looks absolutely fine. I noticed that the plugin (the previous version, actually) did get a lot of use at JavaOne including in a few demos. Certainly I’ll be using it my work now.

In essence this app is just a simple front-end to take in the data for a new employee, there’ll be a bit of validation and then, of course only if valid, it will be all packaged up into an XML document and sent to the IR. In the real application this data will be used to create a new employee record (well, with some exceptions if it’s someone who’s returning); however in our current hybrid state only some of the data will be sent to the interface modules to the COBOL package to create the record there because the old system doesn’t keep as much data as the new one does/will. However we will keep the XML document that has been sent and the IR responses (also XML documents). The upload processes and the COBOL interfaces have already be written in Java and we’ll just make use of those.

User Interface

I came to the first ‘stop and think’ moment over the UI very quickly. I’ll admit that it may be slightly more logical to look at the data model first but to some extent that is defined by the IR specifications so I started with the user interface. Our typical user knows about their business but probably wants to spend as little time on the computers as they can so the UI is very important. It can certainly break an application; a poor UI is going to cause problems, a good UI is going to smooth the user’s interaction with the software and that is to everyone’s benefit. In addition we plan to get the software out fairly quickly and be prepared to make amendments as required by the users, probably fairly minor, but in a general sense maintainability is very important; this is a small app and the last thing we want is to have minor UI changes costing significant developer time and effort.

So, I had to “stop and think” – how are we going to make the UI ? Well, Swinguilder, but of course. However I don’t really know Swing, I mean I’ve written Swing apps but that was courtesy of NetBeans GUI designer and, well, it just worked; and why should I want to understand how it works ? But builders are a bit different and do appear to require that the programmer has a fair degree of knowledge of the thing that they are building, and that was my conclusion after a few attempts. Anyway after some hours searching the web I discovered that the general consensus is simply “don’t use native Swingbuilder” and I see no reason to disagree with that.

So what do we use ? Well, there do appear to be a few alternatives; I looked at a couple but again decided to go with the one that seems the most popular: that’s MigLayout. In essence you can do what you want with MigLayout but far more simply than with native Swing, and with fewer lines of code and , to me, fewer lines of code do usually improve maintainability. Perhaps there are some UI features that you cannot achieve with MigLayout but we do try to keep UIs clean and simple and after a quick look at the documentation I was quite happy with it.

IDE, editors etc.

Finally I was almost able to write some code. Personally I like IDEs, perhaps, being of an age when I can remember having to write out coding sheets for card punch operators and then have to faff about with overnight runs etc. etc. etc., there does seem to me to be a benefit in having one bit of software that does almost everything you want in one place. As far as I’m aware, at the moment it is only NetBeans 6.7 that has any Griffon awareness (via a plugin). There’s just (that’s today) been a new Alpha version of the plugin released and Geertjan has said that he does intend to develop it further. I’m using it now; it gives you a Griffon project structure and quite a few features, obviously including the editor and ‘run’ facilities, which, at the moment, is all I need.

and next time I’ll actually develop something that runs…

I’m involved in a small software company in the U.K.; currently we’re updating our payroll package and we’re (well I’m) using Griffon to produce a small desktop application. We already have a small Java app. that takes the data for a leaving employee and prepares an XML file and uploads that the the Inland Revenue, the Griffon work will be an upgrade to this Java app.

The reason that we’re using Griffon is, in the main, because we have been re-writing our existing package using Grails and so we’re familiar with Java and Groovy. So it seemed reasonable to give Griffon a try, and here’s a description of that work. I’ll give more details of the actual function later.

I should point out that our work is currently on WINDOWS XP, we are looking to move our development towards Linux, but that’s for the future.

Downloading

This is an easy bit…the Griffon web site gives the instructions for downloading and there’s not much one can say about those – just do what it says. We just downloaded the latest 0.1.2 version, and actually took the ZIP.

Installing

Again just follow the instructions:

• make a new directory (say c:\griffon, and why not ?)
• unzip into there, WINDOWS unzip can do odd things if you don’t watch, so we manipulated the results so that we now have c:\griffon\griffon-0.1.2
• create new environment variable for GRIFFON_HOME  (=c:\griffon\griffon-0.1.2)
• add an entry to the PATH variable for %GRIFFON_HOME%\bin

and, essentially, that’s it, Griffon should now run.

Because you’ve set up the PATH, just open a DOS window and type ‘griffon’ and something should happen. If you are going to just try ‘griffon create-app’ be warned that it will create the application structure in the current directory.

Next time – what we want to do with Griffon…

More to come soon….