Sad news, Bob Bemer developer of ASCII has died. :(

Key computer coding creator dies

I don't like breaking code that works....

Okay, so that's probably a pretty obvious thing to say, but I think it's turning into a debilitating disease. You see there's a new feature that I've got to add into the client code, I know that it's going to be a complete pain in the arse to add as it is a very special case. So basically I know that it's going to break things for a while till I've managed to get it working properly.

Obviously this code isn't going to go anywhere until it's working, I know that. I know that I'm the only person that is going to have to suffer an application that doesn't work properly, yet somehow this does not help me. I still don't want to start this work.

I think this stems from a general fear I had of breaking things when I started in this company, back in the dreaded old days when the didn't have version control! Yes I know! So we were constantly breaking things, obviously. A team of three working on the same code without version control, what else is going to happen.

I was chatting about these good old days with a friend who worked here back then. He's since run off back to acedemia (it was that scary at the time), but it's nice to chat about it with him. Gives me some perspective on how much better things are now.

Well I suppose writing this is just another way to put off the enevitable....maybe a quick coffee break first... ;)

Self-publishing.

Some time ago I read this article on Java.net.

My adventure in Self-Publishing [June 24, 2004]

I was interested in these experiences, perhapse thinking about the future. The reason I bring this up now is that a friend of mine is trying self-publishing for comics.

The Variance Anthology

They are using the Cafepress.com system, which is publising on demand. There are no up front costs. There are currently only 8 books in their programming section so there might be a gap in the market for the entrepreneurially minded.

XSLT sorting on dates

Roll on XSLT v2 is all I can say. First off, I've not blogged for the last few days due to a sudden and rather large amount of work, which was not Java or XML related, so I didn't have that much to post about. However today we got a query from a licensee of our technology. I'm not going to go into masses of detail about our technology (mostly because it's not that interesting) but needless to say at the end of hte pipeline it produces output (HTML, TEXT, XML, PDF etc) by passing the output XML through XSLT.

This licensee was asking (read moaning!) about that fact that data information came out in the XML as either "YYYY-MM-DD G" or similar with a time on the end. For those of you who may not recognise it the "G" is the Era, i.e. "AD" or "BC". He said he couldn't do any sorting on it in the XSLT.

One of my biggest issue with people is when they ask for help without even trying to find the answer themselves, I judge this by how long it takes me to find the answer....

...10 minutes with the excellent Zvon XSLT Reference and Stylus Studio and I had all dates ordering correctly with only 9 lines of XSLT. You can imagine the curt yet polite response to the licensee.

Still, all of this sort (no pun intended) of thing will be a lot easier when XSLT v2 is available, however I do think that will be a long time coming. After talking to Michael Kay, creator of Saxon and Jacek R. Ambroziak creator of XSLTC at Sun and now the Gregor/XSLT compiler at XML Europe last year, XSLT v2 sounds like it will be much harder to implement and more importantly optimise in XSLT processors.

Web services stacks

I've been following the Apache Web Services mailing lists of late and there is interesting talk of them release a Web Services Pack, as an alternative to Sun's.

This is great news, I think. However what we need is some nice independant group to do interoperability testing for these. Which I think should be part of the WS-I remit. Surely it would be easy for them to set up their Basic and Security profile tests using each of the stacks and cross-test them.

Personally for completness sake I would like this to extend to other languages, such as PHP, C/++ etc. As a developer I want to know which specifications I can use without cutting off people using other languages, for example which languages and implementation stacks have WS-ReliableMessaging implementations and are they compatible.

I'd really like to see a set of flexed aggregations of Web Service implementation stacks pulled together that implemented as much of the standards stack as they could across all implementations. This should be cross-tested, WS-I tested and offered in two variants, server and minimal client (so for example the server Reliable Messaging layer would use a RDBMS and the client would have an in-memory embedded db) to keep client application distributions small.

Well this is the web service nirvana that I dream of, what do you think.

Programmers as artists

We often have this debate with non-programmers, trying to explain to them that we really are artists. For us it started with a comment in a team meeting from me about refining code being like sculpting, as Michelangelo put it;

"The best artist has that thought alone Which is contained within the marble shell; The sculptor's hand can only break the spell To free the figures slumbering in the stone"

Our Director of Technology then suggested that actually we are like poets, trying to find the most succinct way to express something.

Therefore, we are always glad when we find someone else who agrees with our concept of the programmer as artist, such as the following.

Hackers and Painters

House style for GUIs.

Slight detour from the usual stuff directly about Java, but one of the things I've been thinking a lot about lately is having a house style for GUI applications. There is a real pay off in terms of recognition, as long as people like it.

The best example of this is Apple's brushed metal style. You can spot an Apple application from half way across an office, especially if it's running on a PC.

I've just started using Napster for downloading legal music, and the look and feel of that is very much all it's own. However both of these examples are good because they are not "in your face" about it.

To the degree that we can, we've been developing a house style, but there's still a ways to go. But it's something to think about.

JDesktop Integration Components (JDIC)...

I was over the moon when Java.net launched the JDIC (JDesktop Integration Components) project. Our administration appilcation acts in some ways like a remote file explorer, and so is required to open files in the appropriate application.

Well I've bodged this in Windows by calling:

Runtime.getRuntime().exec( "rundll32 url.dll,FileProtocolHandler file:/" + filePath;

Luckily we don't have a drastic call to make the app cross-platform, but then this is Java so it basically offends my sensibilities that it isn't. JDIC seemed like just the ticket, except for one thing.....

...the one other platform that is of importance to us is Mac OSX, which is the one major platform that JDIC doesn't cover. I've been trying to think about why this is the case. The only answer that I've managed to come up with so far is that Sun started the project, and the covered platforms match up with those that Sun directly offers for Java, Apple producing the Mac OSX version of Java.

Anyway, these guys are desparately in need of all the contributors they can get, so I'm putting a plee out there for Mac people to contribute. To tell you the truth I wouldn't be surprised if Apple put some people behind this. I'm definately going to prompt the Mac fan in our office.

If you think you can help, please do.

Date field saga ends...I think.

I've finally completed the Date field, well to what I think is complete. My boss comes back off of holiday tomorrow so he'll have the final say about it.

I'd like to thank all of those people who posted comments about it, they were all very helpful.

I wish I could say that I was totally happy with it, but I'm not. It has restrictions. I'm using the SimpleDateFormat format strings to tell it how to display, but there are restrictions. It will only accept format strings that are eauals in length to the input data (e.g. must be 'yyyy' not 'yyy' or 'yyyyy' which the SimpleDataFormat class will accept as a 4 digit year). It will only work with numerical representations of dates, so no 'Jan' or 'January' or 'Monday' etc.

I know how all of this could be done, but I'm just out of allocated time on this mini project which is annoying. But hey ho, that's the way it goes I suppose.

So I'm now implementing it through out our applications, replacing my last attempt at a date selector. Then it's back onto the Development Process document that I was working on.

Thanks again to all those who helped.

Java date problems follow up...

Some kind, anonymous, soul just posted this link in a comment on yesterdays post. It's a good article generally on Calendar, and explains some of the history of Java and dates. I especially liked the following.

International Calendars in Java: "You would think that when we deprecated most of Date and added the new Calendar class, we would have fixed Date's biggest annoyance: the fact that January is month 0. We certainly should have, but unfortunately we didn't. We were afraid that programmers would be confused if Date used zero-based months and Calendar used one-based months. And a few programmers probably would have been. But in hindsight, the fact that Calendar is still zero-based has caused an enormous amount of confusion, and it was probably the biggest single mistake in the Java international API's."

Thank you to whoever posted that.

Dates in Java.

Calendar class

Can anyone tell me why the Calendar class and the SimpleDateFormat class have so little to do with each other. For this uber-date selector widget that I'm producing I am using a date formatting string, based on SimpleDateFormat's, to tell the control what and how to display, I am also using a Calendar object to deal with the date arithmetic, i.e. rolling from 31st of December to 1st January in the next year.

I've had to build my own date format parser, because there is now way I can find to extract useful information about the date format string from SimpleDateFormat and absolutely no way to get useful textual descriptions of dates out of the Calendar without formatting a complete date.

What is worse is things like the Calendar returning int 0 for the value of January when getting the value of hte month field. I can understand that this is an index of the date, but this is not how any of the other fields work, and quite frankly my view on the matter is that 1 should be value of the month field for January.

Well I've gotten around most of these inconsistencies, for a start my date selector only deals with numerical representations of dates for now. I've created a calendar adaptor which sorts out the month offset problem and also now has get and set field value by string methods, which nicely handles the Era problem, BC=0 and AD=1.

I know that some of these issues are specific to the type of problem that I'm dealing with, but I am sure some of you must also have come across these. I had a scan through the Java bug database for Calendar bugs, but there were far too many to go through looking for these ones.

Dates are a big problem, one of the most recurring problems I have to deal with, but the Java core should be better than this. I won't tell you what we did when storing dates in the database, that's just evil!! ;)

Swing interfaces, how do you implement yours?

I spent late Friday afternoon moaning about how, while extending JTextField, I couldn't consume character key presses before they were entered into the text field. Well of course you can, I was just being particularly stupid....it was Friday after all.

I had implemented the KeyListener interface, but only fulfilled my usual keyPressed method, which obviously gets called after the text field has dealt with text keys. After I'd realised what I'd done it got me to thinking. I have gotten into habits when implementing interfaces that I use a lot. For example, when constructing a new Swing component I also implement the LayoutManager interface, fulfill the layoutContainer method, call onto getPreferredSize from both min and max layout size methods and do nothing in the add and remove layout components. I then override the getPrefferedSize method to ensure I don't get into any infinate loops.

This works for me, but my concern is that I don't realise that this is what I'm doing any more, thus leading to the potential for such gotchas as the KeyListener problem. Well it's one to remember at any rate, and I made myself look soooo stupid over this one that I'm not going to forget it in a hurry. At least I can be thankful that ActionListener only has one method!