magpiebrain

I’m currently writing a UI layer for Naked Objects. I’m using a TDD approach and have also used the development as an excuse to give “JMock”:http://www.jmock.org/ a go. It being my first experience using a proper Mock Objects API (I have used the very handy “MockRunner”:http://mockrunner.sourceforge.net/, which Mocks application frameworks rather than objects) its been slow going at the start. Things have now started to click into place mentally and JMock is at last making some sense.

Today however I hit a really annoying problem. I’m developing a simple @FrameFactory@, who when given a @NakedClass@ will return a window showing a list of instances. The code looks like this:

public class FrameFactory {
  public FrameFactory(FactoryDependancy dependancy) {
    ...
  }

  public Component makeInstanceList(NakedClass clazz) {
    //make an instance - this is what I want to test
  }
}

Continue reading…

“Rome”:http://wiki.java.net/bin/view/Javawsxml/Rome is another Java API which provides RSS parsing capabilities. Unlike the more mature “Informa”:http://informa.sourceforge.net it also supports Atom. Their comparison with Informa makes interesting reading – they state that Informa is hard to use! The mind boggles – here is how you can parse a feed:

FeedManager feedManager = new FeedManager();
FeedIF feed = feedManager.addFeed(getUri());

What is complicated about that? It’s true that Informa doesn’t support Atom yet, but that is a trivial task and support should be in soon (Niko is working on it now). Their only other complaint seems to be that Informa can only 1.0 and 0.91 in output – this is a valid criticism but RSS output never core to Informa’s goals. In any case adding support for other export mechanisms is trivial but to my knowledge has never been requested by anyone.
Continue reading…

In a recent trend of technologies being used as verbs (think _googling_, and err, well something else) of late I have been mostly Naked Objecting. For those who don’t know, “Naked Objects”:http://www.nakedobjects.org/ is a framework which allows the developer to quickly roll an application which provides both a UI and persistence layer simply by coding a domain model (for a better overview see ” Introduction To Naked Objects”:http://today.java.net/pub/a/today/2003/07/15/nakedaddress.html over at Java.net). Thats the good side.

That bad side is that the built in default ‘lightweight’ UI just plain sucks. It makes heavy use of drag and drop which is not in itself a bad thing, however its a jolt for those users more used to a standard UI, and no non-drag and drop alternatives are provided. It is also ugly, and not that intuitive. Luckily, Naked Objects make it fairly easy to roll your own UI for it, something I’ve been playing around with over the last few days.
Continue reading…

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…

Each language feature introduced that tries to enforce safety of some kind invariably introduces some reduction in the power of the language. Some of these tradeoffs’ seem acceptable. The Java security model is an example of a limiting factor in the deployment and execution of a Java application which makes perfect sense to me. Java also hides memory management and pointers from you, which for the majority of applications also makes sense, however sometimes you really want to get hold of the underlying memory model and do nasty things with pointers and that is why C and C++ are still used for writing OS API’s.

Other limitations just become more frustrating over time. Java’s strongly typed language provides a great deal of compile-time checking, at the cost of program flexibility – Python, Ruby et al provide a richer, dynamically typed language which gives the programmer much more power (And anyone saying “You get dynamic typing with Groovy” is going to get smote with the cluestick of death, +1.). At this point I’d like to borrow a phrase from Spiderman (uh oh – nerd alert!) “With power comes responsibility”. Such dynamic languages with their more flexible typing can also get you into a bit of a mess. These dynamic languages can be seen primarily as enabling languages – they make the assumption that developer actually know what they are doing. As a result, they will on occasion let them shoot yourself in the foot. C and C++ likewise let you shoot yourself in the foot – they also however let you shoot the guy next to you, blow your car up, drink your beer and steal your girlfriend, but that perhaps is a discussion for another day.
Continue reading…

“Paperairplane”:http://www.paperairplane.us/ looks _very_ interesting (link courtesy of “Die Puny Humans”:http://www.diepunyhumans.com/archives/000161.html). Based on JXTA technology, it is a Mozilla plugin (here’s hoping Firefox is supported too) which allows the development of decentralized communities. The content is stored and served from individuals machines, hopefully providing the ability for individuals to setup communities where they would otherwise be restricted form doing so (either due to commercial or political reasons). I was a big fan of the “peek-a-booty”:http://www.peek-a-booty.org/ project, originally launched with much fanfare, that attempted to provide methods for sharing information that could not be blocked by governments, however little has materialized since the project was first announced over two years ago. Paperairplane seems to of made at least one of the same mistakes as peekabooty – it has announced a project without anything to actually show for it (the java.net website for the project contains the usual “We’ll post code when we have it” type message). From the peekabooty Lessons Learned doc (PDF):

What did I learn from the first version of Peekabooty?
…
1. Don’t release before it does something useful.
This lesson is recounted in Open Sources: Voices from the Open Source
Revolution as well as other places. I had even read about this rule before we
released, but I had to learn it for myself. If you release too soon, you spend a
lot of your time answering emails instead of developing.

I hope that the paperairplanes project manages to produce some actual usable code, and doesn’t join the ranks of other vapourware OS projects like peekabooty (and many of my own). If it can, then it will undoubtedly prove useful in a world where censorship is on the rise.