The ongoing DateField component saga....

So I'm still working on building a new date entry field for out swing application. I do like have a small constrained problem like this, especially one that can be built completely out of the main development pipeline.

While as "good" developers we always want to build reusable components with fantastic public APIs that are self documenting and completely consistent, we don't often have the time to do this. My current date field project is one of those rare occasions when I find I have the time and the scope to be able to do just that. What I am finding though is that it's much harder than you would think.

How often do you, on your own, get to practice the art of producing perfectly atomic components? Well I don't know about you, but this is rare for me. You cannot rely on specific usage senarios. This is made even more difficult by the fact that this is a Swing component, inheriting off of JTextField, so I am having to consider what functionality from the super class I am going to support, and therefore have to test and maybe override to make safe for use in this context.

Whatever your feelings on this, perhaps you think that I am just stupid and that this should be a no brainer, I am finding this an amazingly useful exercise. It's setting me thinking about how I programme, in a way that is unusual for me, and really, no matter how that happens, surely that is a good thing.

-----------

On a side note, I realise that yesterdays post about Web Service interoperability went off on a bit of a tangent, but I am going through one of those phases where a concept is stuck in your head and just keeps poping up at you from all over the shop.

The idea of programming to surfaces, nebulus though that statement is, just keeps on appearing. While I wrote about the ideas of Jaron Lanier, what I also realised is that this is linked to the ideas about the brain that Steve Grand puts forth in his book that I also wrote about yesterday.

I have this annoying little itch in the back of my mind that keeps making me think that there is something important in this idea, but I just cannot figure out what. Any suggestions more than welcome, comment away.....

Web Services Interoperability...

Here is a great article discussing exactly what "Web Services Interoperability"
means and the role of WS-I.

WebServices.Org - The Web Services Industry Portal - Interoperability: the Key to Web Service Quality

I was particularly taken with the line;

"Interoperability needs to happen at all levels of the Web services protocol stack for a Web service to be certified as "interoperable".

From my perspective there are still too many manual stages in the usage of Web Services, still too many places for human error to creap in. We are still a long way off of complete automation, and standards such as Web Services Metadata Exchange will help.

Looking even more forward into the future I can see a lot of applicability for the theories of Jaron Lanier, see this interview. I can see the WSDL and WS Metadata being the basis for the surfaces that he talks about, and UDDI could form the landscape on which the surfaces lie.

However that is a long way off, and in the mean time we need to work towards much better interoperability for simple web services.

Some of you may have read James Gosling's weblog entry
"The world needs more crazy people" this month. It stuck in my mind, as I agree with him whole heartedly.

I've been off sick for the last few days, but I've had a great book to keep me company. Growing Up with Lucy: How to Build an Android in Twenty Easy Steps by Steve Grand. If you've never heard of Mr Grand, well quite franckly I wouldn't be surprised. Basically he's a quite insance guy who has spent the last few years dedicating himself to research into artificial intelligence/life. He works on his own, in his garage, and yet has built one of the most advanced research robots in the world.

He also happens to be a greate popular science writer. Good books are those that pose questions, great books are those that make you pose your own questions. This book is of the latter variety. I recommend this to anyone that needs some inspiration to strike out with their own crazy ideas.

Date entry, the never ending story...

DateFormat (Java 2 Platform SE v1.4.2)

So I'm starting a little mini project today, rebuilding the date entry field for our swing application. I think this is the fourth time I've rebuilt this one. First there was the simple text field with post entry validation. Then a 3rd party date widget with the calendar view. Then the Java 1.4.3 formatted text field.

None of these have appeared to meet all of our requirements. There's always something someone doesn't like about a calendar view, even with large number that we've tried, plus they don't always fit in well with the layout. The formatted text field does have many problems for people, it's not very intuitive and many look and feels still haven't got it implemented correctly.

This time I'm starting from scratch, gethering requirements, good examples of what people want.

It's strange that this is the one part of the interface that has faced so many problems, you'd think it would be simple. It has been a bit of a case of problem avoidence, thinking that this must be a problem that someone else has solved in a way that works for us.

This is way time estimations can be thrown so far out of whack. Would you have seen this as being a major problem? Oh well, it could be worse, I could be implementing one of my collegues ideas for date entry based on concentric circles!

Optimisation update...

So we're still improving on our optimisations from the other day. I've been doing a bit of a postmotem in my head about how we got into this situation.

At the core our code is five years old, has been optimised and works extremely well. Our problems have come from adding a new layer over that code. In this case a WebDAV implementation, for communications with the administration application. Now WebDAV specifies oppourtunities for optimisation of the protocol, for example you are able to ask for a partial set of a resources properties.

Well the WebDAV optimisations didn't quite fit with our model and so we were getting all the properties each time, planning on fixing this later....it got forgotten.

Bonuses, motivation and managing people.

Why salary bonus and other incentives fail to meet their objectives

Picked this up from Keith Pitty's weblog. Interesting article, and a subject that is much debated here. Our company has always given healthy bonuses, but one I've not felt that directly linked to my work. Our evaluation processes have changed many times as well, pretty much always for the better.

I have to say that while I think most developers will to some extent agree with the concepts of this article, very few will want to see them implemented. You see there are, and always will be, developers who are mearly doing this as a job, and you cannot dismiss them as bad developers and many are very good.

Traditionally our company has employed young people with very few comitments, this has led to a team who are willing to put in the hours and give, perhapse, too much of themselves to the job. This is now changing as the company grows up, and therefore our policies on rewards will have to change. We now have people who value holiday far more than I, and therefore are not happy with our relatively low holiday allowance. There are people who will never work much overtime as they have responsibility to families, a very new thing for our company.

All of these people will have differing views about what they want from the company, and I suspect many will be more than happy for a bonus scheme to continue.

Optimisation... more thoughts.

I posted yesterday about the importance of optimising your code, something that is often done as an after thought (we're just as bad as this). Well it got me thinking on my way home last night.

Currently I am rewriting the development process for my company. This is something that's never been done as a formal excercise here, and it's harder than you might think.

It's not like we have no development process and it's all chaos, not at all. The process has evolved over the last 5 years. But no one has sat down and tried to pull all the threads together into a cohesive whole and bring in new best practice from outside.

The reason I'm talking about this is that while I was bemoaning the fact that people don't have planned optimisation periods in their development plans, I hadn't yet thought about this in the one I was writing.

As part of the rewriting the process I have been reading Java Extreme Programming Cookbook by Eric M. Burke and Brian M. Coyner. In this they talk about JUnitPerf. While this canot do all your performance monitoring, and you should still have a period of optimisation, I do think that this should be the foundation of an early warning system for you.

I'm going to add this to our development process document, and I'll let you know how it goes. Would be good to know if anyone else had ideas about this.

So there's another Swing debate going on at Java.net. AS one of the people posting points out there are many such debates going on all the time.

java.net: Swing Usability [May 19, 2004]

I guess I don't have that much of a problem with swing, see my comments on the matter.

What does amaze me though is how Java developers do seem to struggle with it. What does this say about the current state of the development community.

It is perfectly possible to create decent Swing apps, just check out the ones selected for Sun's Swing Sightings column. I'm really proud of our client application, especially since I didn't know any Swing before I started it. (I'll post a link to the demo as soon as it's up)

Swing is after all just an API to be used, it isn't that complicated, just big. Most Swing guides give an overview, but they focus on the MVC aspects of Swing. I suspect that this isn't quite how most Java developers will work. People very quickly break the MVC architecture, and that's not always a bad thing. The other side of this is that I know a lot of Computing graduates wouldn't have a clue what MVC is, which worries me even more.

So I'd like to share my 2 top practical tips, the things I learned in my adventures in Swing:

1) Develop your own components.

Do not be affraid to customise and aggragate components into something that is easily reusable for you. This will help you test at a lower reused level, and keep the look and feel of you application consistent if you reuse these components.

2) Build your own layout managers for anything slightly more complicated.

After I'd bitten the bullet and built my own layout manager for one very complicated component I didn't stop. Most all of the components that aren't simple containers now have their own layout managers.

I guess that's it. Only two tips for now, but they are just about the most important two that I learned.

javaperformancetuning.com review of Borland Optimizeit.

So it's been a few days of performance tuning for the development team here. We're still a bit reactionary with this, and the latest bout was triggered by the 15 minutes it took to load a collection of resources in the administration client, there were only 726 resources and all we wanted was basically a directory listing.

So we started looking into it, I fixed a stupid part of the client application which made an extra call to the server for every resource listed. The call was safely moved to an as needed call rather than being preemptively made. The rest of the team started looking in the server code. For this they were using Optimizeit. Now I'm not one for recommending commercial products much, only when I find them to be of excellent quality and usefullness.

Very quickly serveral bottle necks were located in the code, mostly through massive object creation and garbage collection. We've now got the server and client screaming through that very collection load at a healthy <20 seconds. That's still a lot and we have further to go on this, but it is acceptable for us and the client so that's what matters. The main benefit is not for this strangley full collection of resources, but for the system as a whole. Mostly the rest of the system loads in what appears to be real time which gives a much better feeling to it.

Lesson to be learned, make sure you look at your running code for possible optimisations. There may be more than you think, and there's no better feeling than seeing your code fly.

Google News: van helsing

So I went to see Van Helsing at the weekend. First let me say that I was a massive fan of both The Mummy and The Mummy Returns, so I am very confused that I didn't enjoy VH.

It didn't make me laugh, and I found the story far too convoluted for the type of film that it is.

This could be the dissappointment of this not being the film that I wanted it to be. I was really looking forward to the merging of the three main Universal monsters, something that would take itself just seriously enough but also be fun in the old style.

Ah well....

Datapower Break Gigabit Barrier For XML Processing with its XG4 XML Chip

You see this is the kinda stuff that I like to see. XML hardware, wish I could persuade my company to let us play with this stuff.