magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘May, 2004’

With a view to adding “Atom”:http://atomenabled.org/ support to “Informa(Java RSS API)”:http://informa.sourceforge.net/, I started looking into the specification in more detail. Just before I started looking at adding support for the syndication format, and found out that Niko (Informa’s product manager) was already looking at it. Instead, I decided to look at the posting and editing API. A “WSDL(Atom’s WSDL file)”:http://atomenabled.org/developers/api/AtomAPI.wsdl file was available, but “Axis(Apache Axis Web Services API)”:http://ws.apache.org/axis/ wasn’t too successful at converting it into a Java API. To get wsdl2java to actually process the file, I had to remove the @DELETE@ operation. I then hit the limitations of my knowledge as far as we services are concerned, so this has been put on the back burner while I read over some tutorials. I’ll keep you informed as to Niko’s progress on adding Atom syndication support to Informa

Using “HttpClient(Apache Commons – HttpClient)”:http://jakarta.apache.org/commons/httpclient/ I knocked up a simple Java API for “del.icio.us(del.icio.us – the social bookmark manager)”:http://del.icio.us/. It worked, but I quickly hit limitations of what the “del.icio.us API(Documentation for the del.icio.us API)”:http://del.icio.us/api/ itself would let me do – for example there is no way to get all bookmarks for a category. I sent off a feature request, so we’ll see what happens – but for what I wanted to do the current API isn’t good enough.

HttpClient itself did exactly what I wanted, which I guess is all you can ask of an OS project. The documentation was a little lacking, and the dependencies on “commons-codec”:http://jakarta.apache.org/commons/codec/ and “commons-logging”:http://jakarta.apache.org/commons/logging/ was annoying, however it worked well and gave sensible errors when required.

Along the way I looked at using “XStream”:http://xstream.codehaus.org/. I was planning to use it to process the results from the calls to del.icio.us, but the nature of the XML meant that this isn’t possible without transforming the results first. I would have no hesitation in recommending XStream for XML serialization, assuming you aren’t already constrained in the nature of your XML schema.

A rather long gap between posts, this has not been down to laziness on my part, nor the fact that I have noting to post, more the fact that I’ve been doing things rather than actually posting about it. Anyway, more details to follow…

Thanks to some code from “Stuart Langridge”:http://www.kryogenix.org, I’ve managed to implement a live comment system supporting “Textile”:http://textism.com/tools/textile/. Originally inspired by “Jon Hick’s”:http://www.hicksdesign.co.uk/journal/ comment system, as you type comment the text is parsed and formatted as HTML, and inserted into another div. The Javascript doesn’t support all Textile formatting, but supports all of the quick tags (apart from Span) and some of the block formatting (such as blockquotes). I may add support for more of Textile’s formatting commands later – I’ll see how much people use it. Anyway, feel free to give it a go and “let me know(Contact Me)”:http://www.magpiebrain.com/contact if you experience any problems.

For some time now I’ve been using “@DateFormat@(DateFormat JavaDoc)”:http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html (actually “@SimpleDateFormat@(SimpleDateFormat JavaDoc)”:http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html) to parse user inputted dates it situations where a decent date chooser wasn’t available. Some simple bit of code like this would normally suffice:


private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("dd/mm/YYYY");

...

try {
  DATE_FORMAT.parse(someString);
} catch (ParseException pe) {
  //date is invalid
}

I learnt two things about this approach. Firstly, @DateFormat@ is _not_ thread safe. This fact was only documented in Java 1.4 despite it having never been thread safe. This is one of those things you learn, and is easily put right.
Continue reading…

I have long since come to the conclusion that JSP pages are evil. Not just bad, oh no. Nothing which can result in such unmaintainable crufty code can be considered merely bad – only evil will suffice. This opinion has been reinforced over the last few days, and this single gem stands out.
I was using a struts logic tag (asshats, I have no choice in this – the first person to tell me to use webwork instead is getting eaten by rats) to assert a boolean condition. It looked a little something like this:


  I hate JSP

For some reason even if @boolProperty@ returned @false@, “I hate JSP” was still being printed out. It being late in the day (and a Monday) I was slow to spot the closing @/@ on what I took to be an opening @logic:equal@. Despite the fact that I had a closing @logic:equal@, no parse error was thrown. Apart from the fact that a @logic:equal@ tag is of no use to man nor beast without a body (and therefore a validation error should of been thrown by Evil Struts) I would of expected the JSP compiler to notice an extra closing @logic:equal@. Of course assumptions are a dangerous thing when it comes to JSP…

The Overall Aim

Eat lunch.

My aim

Eat Cake.

The scenario

Ten programmers in the centre of London.

The result

No clear vision, everyone wanting to achieve the aim of eating lunch in a different way. Group fragments – some go for bagels, others opt for fish and chips. Lunch takes 30 minutes more than it should, and I don’t get any cake.

The moral

Stuff working as a team, go eat alone…