magpiebrain

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.

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…

One of the few benefits of a long commute, is the fact that I’m not doing it alone. The time afford to me each morning on the train to and from work also provides and opportunity for discussion on all kinds of topics, ranging from the poor state of journalism in the daily free newspaper the Metro, to some more esoteric issues at least tentatively connected with work. One discussion which fell between these two concerned the notion of naming – be it the naming of classes, methods or packages.

One of my colleagues asserts that naming is actually one of the hardest things he has to do as part of his day-to-day development. I agree tentatively with that statement – however the problem is not a lack of vocabulary, more that when naming is a problem we often just don’t understand what we are trying to name. The more we mentally consider the code to be an amorphous blob, the more naming becomes difficult. Once our understanding of the code coalesces into something more concrete, naming often becomes trivial.
Continue reading…