G'day! I'm Glen

For my "teach yourself Grails" project I’m building a little SMS Website gateway which I’m calling CyaThen. The idea is to be able to logon, select a bunch of users from your addressbook, and send them an SMS (or schedule one for later).

Turns out that this is quite a good little tester for grails, since I’m needing to:

• Write a ton of simple forms for create/edit/delete messages, history, addressbook - all with database integration - and all with form validation* Implement a signup process (email integration, SHA1)* Generate XML for submission to the SMS provider gateway* Integrate commons-http to submit the XML to the gateway website* Customise the CSS with my own template

Here’s a grab of the latest workings:

 

I estimate that I’ve spent around 20 hours so far and I’m nearly done. The last bits centre around integrating the addressbook selections into creating a new message. (I’d also like to integrate some Ajax into the new message dialog ala Gmail addressbook selection).

So far, I’ve given Grails a pretty good workout. I’ve hit two bugs (and one in Groovy) - all of which were fixed in two days (where do these guys get the time??).

I just can’t believe how much stuff I can do so quickly in Grails. I’m really having a ball. The listserv support is awesome, the doco is growing every day, and I really feel like I’m getting stuff done.

I’ve developed service classes (and test cases), I injected them into controllers, I’ve written custom queries (In grails you can query straight of your domain class using dynamic methods created for each of your fields, so you do stuff Account.findByUserId and Account.FindByUserIdAndPassword - how funky is that!), I’ve used regexp validators with custom error messages, I’ve written dynamic taglibs. Geez, this thing is a productivity machine.

Worth a look if you haven’t already… (will post up CyaThen for people to play with in a week or so - so you can get a feel for what Grails can do in a hurry).

After spending the last couple of weeks tinkering with Groovy, I figured it was time to have a closer look at Grails to see what it had to offer. I’ve gotta say that my first impressions are very positive.

First of all, the user guide has increased out of sight - with tons of coverage on the stuff you want to know about (how controllers work, dynamic tag libraries, ORM integration, all very cool). Follow the quick start and you’ll be up and running very quickly. Be warned, you really need to know a little Groovy before you embark on this journey otherwise a lot of things won’t make much sense to you. Just the essentials: closures, groovy beans &  collections will probably get you started.

Grails uses Hibernate under the covers, and if you’ve worked with Hibernate before, you’ll be pretty comfortable with the conventions. "One to Many" operations are a snap - inside your Order class declare your "Set lineitem" then use a "def relatesToMany = [ lineitem : LineItem ]". If you want to make navigation bidirectional, "def belongsTo = Order" in your LineItem and you’re off.

In the hour I had this arvo, I’ve managed to get a small app doing bidirectional mappings between four domain classes. Using the standard controllers (you get basic CRUD controllers for free without a line of code), I’ve got things persisting to my Postgres database, with the schema generated for you by Grails on the fly. Geez.

I haven’t done any work with Ruby on Rails (Matt is doing a tail on this at our next CJUG), but I guess this is the kinda thing that people talk about when they say that dynamic languages can really help shorten development cycles.

Will write some more when I’ve had more of a chance to tinker…

I’ve cut over from Pebble 1.9 to 2.0 RC1 without too many issues. But for those of you attempting this down the track, here are a few of my hurts to learn from…

First it would not display any of my previous 1.9 entries. Whenever I attempted to reindex it would dump out FATAL errors to the logs. I finally wound up logging on the Pebble DAO stuff and saw:

Loading /data/pebble/blogs/glen/2004/03/13/1079209312000.xml
org.xml.sax.SAXParseException: Premature end of file.

Turns out some of my old pebble blog entries must have died with a 0 length file (there was typically a .bak file right next door which I could just rename). Once that was sorted, a full reindex and they all came back. Phew!

The next hurdle was getting RSS feeds working again. Due to a bug in Jetty that Greg discussed on the mailing list, .xml files weren’t being processed correctly. I ended up having to add the following entries to Pebble’s web.xml:

<servlet>
    <servlet-name>jspxml</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet </servlet-class>
  </servlet>

  <servlet-mapping>
        <servlet-name>jspxml</servlet-name>
        <url-pattern>*.xml</url-pattern>
  </servlet-mapping> 

Pebble 2.0 looks really good. Simon’s made the move to a total Spring solution with this release, using Acegi for the security engine, so I’m keen to take a wander through the source - been meaning to learn Acegi for ages.

Big props to Simon and the guys for a great new release!

Another chapter in the “tiny CSV library keeps on growing” saga… opencsv 1.5 has gone out the door. The new version includes changes to CSVWriter to allow for easily exporting a SQL table or query to a CVS file.

The new method writeAll(ResultSet rs, boolean includeHeaders) makes exporting SQL to CSV a snap! Does the hard work of coercing Bits, CLOBs, Timestamps and whatnot to Strings on the way out.

Thanks to Sean Sullivan for the good work in adding this feature.

I’m learning Groovy at the moment, and having an absolute ball. If you haven’t played with it for a while, jump on in - things seem very stable these days. I’m finding I’m using it all the time for little scripts.

I’ve also had a chance to review a close-to-final Groovy In Action and I gotta tell you that this is gonna be one sensational book. Very accessible writing style coupled with deep technical content and killer examples - it will be the definitive work on Groovy.

Today I’ve been playing with GroovySOAP - very groovy little library for web services. In the mood for some world cup action? (I know, the Australian Socceroos are out through a VERY SOFT penalty in the last minute of extra time). One of my mates send me the wsdl for a World Cup Web Service so I figured I have a crack at a client:

import groovy.net.soap.SoapClient

def proxy =
    new SoapClient("http://www.dataaccess.nl/wk2006/footballpoolwebservice.wso?WSDL")

println "nn  Cities Hosting Games:  nn"
proxy.Cities().each() { city -> println "${city}" }

println "nn  Teams and their Flags:  nn";
println proxy.Teams().getMtTeamInfo().each {
    team -> println "${team.msName}tt${team.msCountryFlag}"
}

Very groovy! I’m hoping to rewrite the crypto libraries for my PasswordSafeSWT app in Groovy since ranges just make byte operations so darn easy. I’m finding anytime I have to dealing with anything to do with datastructures I wish I was coding in Groovy…

Olay, Olay, Olay! Groovy, Groovy!

… Then at least get a butt-kicking GUI design tool like WindowBuilder Pro. I’m not a Swing fan. I’m not smart enough to deal with its layout managers nor creating damn model backing objects for my Combo boxes. I’m pretty much SWT only these days (and probably have been for the last two years) and unlike pretty much everyone… I love using a GUI builder (I know, what a pansy… but for the smallish projects I work on I find it unbelievably productive).

I’ve heard good things about Matisse, but I’ve been using WindowBuilder for years and it’s been just fantastic (FD: I received a promo copy of WindowBuilder ages ago so it was extremely good value for me!). It works great in Eclipse, I can use it for both Swing and SWT development (why I got into it originally), and it’s got a kicking UI designer that is unbelievably smart about underlying code changes and refactors - with no “untouchable” sections or magic tokens (so your buddies on the CVS don’t need to have it installed). I’ve always found it really intuitive too… when you’ve got to shuffle components around the tree view of things is a Godsend….

So I had to throw together a “useful for about two weeks of testing” GUI this arvo, and, for something different, it seemed like Swing might be a nice candidate since I was after a quick and dirty GUI and wanted to keep the bundled jar count to exactly zero. Ahh… Coming home to Swing after SWT… Tell me again why:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

is required? Is there ever a reason that you’d want to not default to this if it was available? And throwing a checked exception too… But I digress…

All of that said, my quick and dirty Swing GUI was a snack with WindowBuilder. I’ve never used the Swing part of it before, but it has all the same GUI building goodness that I’ve come to love from the SWT Designer portion.

The fidelity things still bites after having worked with SWT for so long… Why can’t I Ctrl-Z to undo a paste in a JTextArea? But the platform has come a long way, and it definitely fits the goods for a quick hackup of a GUI:

Which will run unaltered on multiple platforms…

Just uploaded the latest release of opencsv to Sourceforge - a very simple CSV parser under Apache 2.0 license. The new release adds two requested features:

The real cool thing from my perspective was that these were both user-submitted changes (thanks Andreus and Peter!). I just had to write the test cases… and sometimes users even submit those with their changes!

Living the open source dream…

If you’ve ever had issues with conflicting versions of the same jar file, you really need to take a look at JarJarLinks . JarJarLinks is an Ant task that lets you repackage jar files into your own package scheme by doing neato bytecode kungfu.

So you can do stuff like this to repackage commons-kungfu.jar into your own package structure:

        <jarjar jarfile="myapp.jar">
            <fileset dir="build/classes"/>
            <zipfileset src="lib/commons-kungfu.jar"/>
            <rule pattern="org.apache.commons.kungfu.**" result="au.com.bytecode.commons.kungfu.@1"/>
        </jarjar>

In the sample above (stolen from the manual), you simply use the jarjar task (which descends the standard jar task, and offers all the same config switches) to repackage the classes from commons-kungfu.jar into myapp.jar. Jarjar rips out the classes, changes the package naming to whatever makes sense for you, changes any references in your code to the new name, then adds the modded classes to your target jar. So, for instance, Jarjar does the work of changing all your references to org.apache.commons.kungfu to, say, au.com.bytecode.commons.kungfu and repackages the changed classes inside your own jar. You then no longer need to distribute commons-kungfu.jar with your app - the changed classes end up in your app’s jar file.

Here’s two killer scenarios…

• Scenario one is when you don’t want to ship external jars (commons-kungfu.jar) with your standalone app.* Scenario two is when you want to bundle commons-kungfu.jar with your webapp, but your appserver has an old version of commons-kungfu.jar in its own root classloader. Use jarjar to package it into your own war file under a different package name and you’re good to go.

I’ve recently used it to great success where I wanted to deploy a particular jar file to /lib/ext on Websphere, but didn’t want to force everyone else on the appserver to use that particular version of the jar. Repackaged the jar into my own naming structure and I was good to go.

JarJar is even smart about embedded strings in your jar files. So if you do a Class.forName("org.apache.commons.kungfu.FactoryImpl") then that string will be successfully changed to the new package name too.

Many props to the guys at Tonic Systems. Really slick piece of work!

Alright. I can’t stand it any more. After hearing all the cool stuff people are doing with Dynamic Languages, I’ve just gotta jump on the bandwagon to see what all the fuss is about.

I’m going to have a play with Groovy first up, cause I’m not willing to surrender the head space of going totally non Java…. or the tons of libraries that I’ve got used to over the years. I think just getting into closures and builders will be enough of a sea change for this little black duck.

I am very keen to see what Groovy might offer in the web tier (Groovlets anyone?), since I’m doing less and less MVC as things get more and more Ajaxy with Spring and DWR. Also reckon that scripting engines are going to be a great tool for developing Domain Specific Languages (like the ability for users to write pluggable rules for our monitoring software). Very keen to explore more.

Had a quick squiz at Grails to get a feel for what’s achieveable in a hurry in the web space… and following the great Quickstart I had my first CRUD app up in a flash… Of course, then I became completely lost since the whole groovy story is quite a paradigm shift in itself.

Anyways, more news here when I’ve had a more solid play.

I’ve played around with Google desktop (and others) in the past and never had much success. They all slurped too much CPU, didn’t handle my OpenOffice files or PDFs, and came with interfaces that were either too simple, or far too complex.

My local Aussie PC mag, PC Authority did a feature on desktop search technologies this month and gave the editor’s choice to Yahoo! Desktop. I didn’t have much luck with Google desktop, but based on their review the Yahoo offering looked like it was worth for a spin. And it was…

I’ve gotta say that I’m pretty impressed. Handles all my OpenOffice docs, and displays them inside the search window just fine (note: you do have to download the filters pack which handles an extra 200 file types - don’t know why they didn’t just roll it into the base install). Ditto for the PDFs. (Screenshot below)

Haven’t been able to get it to index my IMAP store yet, but other that than it works a treat. Low CPU impact. Nice UI. Very stable. And I’m actually finding it very handy!

Big props to the Yahoo! Dudes. Very class offering.

I’ve been doing a bit of work for a client that centres around SAML & XML Signatures over a SOAP transport. I’ve done plenty of work in the SAML space before (and XML Security for that matter), but the web services angle is new.

Anyways, it gave me a chance to look at the (surprisingly slim) SAML Java landscape again to see what’s hip and happening. I’ve developed stuff with Verisign TSIK (which has interestingly been donated to Apache recently… but without the SAML stuff), but these days I’m pretty happy with opensaml. I’ve found it’s very accurate to the SAML spec, and the library is very productive to work with. Only neg is the use of a special (later?) JAXP dependency meaning you have to do funny business with /jre/lib/endorsed overrides for the javax.xml.* replacements. Under the covers uses Apache XML Security for the digital signature stuff which seems to work just great.

I thought it was all going to be so simple… until I took a look at how the SOAP DOM implementation integrated with what the XML Security library wanted out of it.

XML Security goes through a process called Canonicalisation (c14n) on the XML before calculating hashes and whatnot. That process takes into account namespaces that are in place for the elements being signed and handles the various ways the same piece of xml can be represented. For example, an element which is represented as zz:myelement xmlns:zz="http://xxx" could just as validly be stored as myelement xmlns="http://xxx" and the same signature will still hold. Throw a single extra character of whitespace into the body of the tags, or insert any new namespaces into the picture, and your hosed…

Which is where my problems began. The implementation of the DOM interfaces in the underlying SOAP library was… well.. suboptimal. Some of the namespacing on the elements and attributes was just broken. And as for the SOAP API, well, I found myself actually liking and respecting DOM after going through the pain of creating SOAP Names, and then associated Elements and then trying to append them to various places… and finding out they’re not really children of the element you just added them to until you call update() on the message context…

After blowing a ton of time working out what was all bad, I finally worked out a strategy. Write out the SOAP message to a stream, feed that stream into a real DOM document, calculate your signature, add your nodes, then tranform the resulting DOM back into a SOAP message. Voila! Valid signatures and valid SOAP.

And don’t even get me started on JAX RPC fault handling… that’s for another day. But it has taught me that not all DOMs are created equal. You’ve been warned…

But huge props to the opensaml and Apache XML Security guys… both first class offerings.

If you haven’t played with Eclipse WTP and you do web development… then today is your day to start. I’ve been using it for about a month now and I’ve gotta say I am totally impressed with it.

The WTP is a set of plugins for Eclipse 3.1 that gives you very neat stuff to make web development that much easier (things like syntax colouring and command completion for HTML, JSP, JSTL, Javascript, CSS). Anyways, here are a few of the things I just love about it…

First off the bat is css tag completion… I always forget these..

And the completion is smart about potential values too..

I’ve been doing a lot of ajax stuff lately with DWR, and the WTP Javascript completion is just great. Does completion for your own functions too..

Next big fave is the JSTL completion. First class.. just love it…

For a while now I’ve been wanting a way to test out java.util.regex.Pattern regexs. So with a little bit of DWR and a one-line implementation using String.matches()… I’ve developed a java.util.regex.Pattern Ajax Tester - possibly the world’s most trivial Ajax app! Type in your patterns and click for red or green pattern matching goodness. At least it saves recompiling :-).

Hope you all have a sensational easter. If you’re keen to explore religon a little more this weekend, I can definitely vouch for Christian City Church as a contemporary, energetic and relevant faith community. Sure to be one near you.

Have a great holiday.

There is so much to love about DWR and Spring integration. Just configure up your dwr.xml and tell it which spring beans you want to expose for Ajax goodness, and which methods you want to expose on them.

In preparation for a talk I’m giving Wednesday night to the Canberra JUG, I’ve added Ajax goodness to my little [

Spring-powered Sudoku solver](http://www.bytecode.com.au/sudoku/). And it was a total snack. You can double click on individual cells to solve just that square, or use the “Solve” button to solve the whole puzzle. You could probably write a better one entirely in Javascript (other people have), but it does serve as a great example of using Spring IoC, AOP, ORM, and Unit testing support.

Check it out (source available here soon). And if you’re in the Australian capital this Wednesday night, drop into the Sun offices on Northbourne from 6PM for Pizza, Beer and a fun introduction to Spring (and if you’re not into Spring, just come for the Sudoku solving :-).

I admit it. This week is the first time I’ve ever used java.util.logging. I’ve pretty much always used commons logging and log4j for all my logging needs since one of them was already a dependency in a supporting library, and I’ve never really had a reason to look elsewhere.

Till now…

I’ve had reason to work on some code that integrates into Websphere’s Member Manager stuff. This code is way down in the WAS stack, and if I wanted to use log4j, I’d have to drag it into /lib/ext…. which means that everyone on that app server is now using my version of log4j. Not so sweet.

My next thought was to use Commons Logging (JCL). WAS5.1 uses commons logging internally, and I could get it into WAS6, but I found there are all sorts of classloader issues with it when /lib/ext comes into play. So that was off the list.

Finally I did some digging and discovered that WAS6 has switched to java.util.logging for all its logging goodness. Read a few good [

articles](http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html) and I was good to go. Had to get used to the idea of Loggers, Handlers and Formatters and how they hung together. but it wasn’t much of a switch really. You end up doing stuff like:

Logger myLogger = Logger.getLogger(myClass.class.getName());

along with a:

if (myLogger.isLoggable(Level.FINE))
    myLogger.log(Level.FINE, "Try catching this", e);

Seems that the log method does some reflection to see what method are logging from. Not sure of the performance implications of that one under load… the IBM docs recommend using the logp() version of the call for just that reason… but we’ll see. The basic Formatter is pretty average (two line log messages!), but it’s pluggable so you can probably simulate a log4j console appender if you were that keen. The standard ConsoleAppender goes to stderr which I found a bit annoying and haven’t work out how to fix just yet.

While I’ve blogged about cookie grief before, I spent most of yesterday discovering more than a man should about cookie deletion. So I’m iterating over request.getCookies() and finding the relevant cookie to delete, then calling setMaxAge(0) to expire it immediately. What could go wrong?

Well… the cookie wasn’t disappearing. These things can be a bit of a bugger to track down since you need to see the browser and response headers to work out what is going on. The tool I like best for this is ieHttpHeaders (an IE equivalent of livehttpheaders).

My first drama was that I wasn’t seeing the Set-Cookie header come back to the browser to delete the cookie. Hmm… seems you’ve got to add the cookie to the response once you do the setMaxAge(0) on it. Probably should have known that. No biggy… Try again…

Ok. Now I see the Set-Cookie coming back to the browser header to kill off the cookie, but on then next request, the browser is still sending the cookie to the server! After much stuffing around I noticed that when I created the cookie, the Set-Cookie header has a path and domain, but when I delete the cookie there’s no such beast. You’d think I could call Cookie.getDomain() and Cookie.getPath() on the cookie I retrieve from the request. No cigar. The browser doesn’t tell you that stuff, so you just get nulls.

So then I changed my deleteCookie routine to call the same code that generated the Cookie in the first place (with domain, path, and age), and call setMaxAge(0) on that and add it to the response. All good.

The moral of the story is that setMaxAge(0) only does what you think it does if the path and domain match the ones you used to set the cookie in the first place. Of course, once you know about it, you find out that it’s a well known thing anyways…

Blogging it up so that Google may save you from setMaxAge(0) pain in the future…

It would be pretty insane to argue that regularly delivering running, tested, value-add code is hazardous to any project. But when it comes to iterations, if you’re not careful the mojo can get very funky pretty quickly. I’ve just finished reading a fantastic article by Alistair Cockburn on the misuse of iterations in agile projects… and I’ve just realised that I’m living the nightmare myself!

Alistair’s argument comes down to the fact that shipping iterations is not necessarily the same as delivering real value to the client. And it’s not the same as getting you closer to your end-game. A fave quote from the article:

_

“Danger grows when the results of the iteration are not directly linked to delivering the product to the end user. Without that linkage, iteration results hang in the air just as badly as the old, pre-agile forms of wandering in the wilderness.”

_

Reading this I started to rethink our iterations in line with the big picture of getting our product out the door. I’ve spent a bunch of time over the last couple of months “tidying” up stuff, refactoring and adding small features that don’t (1) add immediate value to the client; and (2) Move us closer to getting 1.0 out the door. Yes I am hitting iterations, but no it’s not moving us closer to 1.0. That thinking is changing today. The problem is not the iterations - the problem is that I’m not planning them properly!

In line with Alistair’s recommendations, I’m setting aside some time this week to make sure that our monthly iterations are better aligned to our end game. In essence, it’s all about delivering. Not about delivering iterations, but about delivering the features that are adding value and getting us closer to a revenue stream.

If you haven’t read Alistair Cockburn’s Crystal Clear - do yourself a favour. I have found this book a really challenging read. This really brought together a whole bunch of agile thinking into my world - and it’s the most practical and battle-tested book on small team development methodology I’ve read.

Awesome stuff…

I was tracking down some unusual date behaviour and came across this little gem. Check out the following code and tell me what the output should be…

        DateFormat formatter = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");  

        Date startDate = new Date();
        String strDate = formatter.format(startDate);
        Date parsedDate = formatter.parse(strDate);

        System.out.println("Start Date is: [" + startDate +"]  Parsed Date is: [" + parsedDate + "]");

Looks pretty straight ahead. Create a new date formatter, apply it to a Date object, output the string, and then reverse the process. Should end up with what you started with. Well, if you try it in Australia on a JDK that’s pre 5.0 you’ll get this:

Start Date is: [Wed Mar 22 **13:53:18** EST 2006]  Parsed Date is: [Wed Mar 22 **14:53:18** EST 2006]

Whoa there! Where did that extra hour come from? It all comes back to that magic z in the format string. Seems there are issues with that TimeZone parsing story pre JDK 5.0. Going on the Pragmatic Programmer “select() isn’t broken” philosophy, it took me a long while to assume the problem wasn’t in my code, and finally to check out the bug parade. But sure enough, let me introduce you to bug 4845901.

You have been warned…

I’ve been integrating DWR into our web monitoring app to display recent monitoring events dynamically while the user is doing other stuff. Since I already have a service object that does all the heavy lifting, integrating it was a snap. And now they have a section of the page where they can see events as they happen.

Pretty chuffed with myself, I decided to experiement with making one of our edit forms ajax-ified. Again, the service calls were already there to add/update/delete the object the form was representing, so I just exposed then in dwr.xml… and I have a dynamic table that I can add/edit/delete within one html page.

Ok. Now I’ve now got freight-train momentum, so I added some OpenRico sauce to make things slide and collapse… baby.

Then I got to thinking… This was all pretty easy. I didn’t need to setup a special controller with custom table, edit, and delete views; I didn’t have to configure any bean marshalling; I didn’t have to do a stack of view mapping config; and I could develop and test with a click of “Refresh” on the browser.

Then the penny dropped. You know, I could probably live without most the web framework entirely! Have one html page for each portion of functionality, do the service calls via DWR to do the heavy lifting, and just add some script for interface swishness. It does mean I’m committing the javascript only for the view… but it seems to a lot less work than the MVC framework I’m using now. And then I found that much smarter people than I have already been thinking this some time.

So is this just crazy talk? Doing the view in straight Javascript and just use DWR to call appropriate methods in the Application Service layer to do the add/update/delete/execute/query or whatever the business logic requires?

DWR gives me the security to lock down what methods are exposed. And the business layer itself applies security to make sure users can only delete/edit/update their own data. So can I kiss my MVC framework goodbye? Any brave souls walked this path? Validation could be a deal, ditto for browser compatibility, but if DWR and Rico are solid there then I’m pretty close to a compelling rapid web dev environment.

I’m a big fan of keeping stuff in a simple textual format (even more so since reading The Pragmatic Programmer). So on our little startup project we’ve simply been keeping the documentation in text files. The project to-do list, installation instructions, all that sorta stuff. There’s only two developers on the project at the moment, so we just sync up to CVS and we get the latest gear.

Well I’ve started doing doco for more serious stuff on coding internals, and decided it would be cool to hyperlink from one text doc to another… but I didn’t want to start marking everything up to html. Too much overhead… and overhead means another reason to stop me documenting. But I also didn’t really want the overhead of a full blown wiki right now… another thing to manage/secure/backup/administer… and I would have to leave the IDE to update the docs… giving me another reason to not document while it’s fresh. So text files have been serving me pretty well.

Enter EclipseWiki: a very cool eclipse plugin that will treat any text document in your project with a .wiki extension as being a Wiki doc. It will mark up your CamelCase links to the related CamelCase.wiki text file. And it will even mark up references to your class files as a link the class file itself in the IDE (so you can just use Ctrl-Space in the text editor, select your class, and you get a hyperlink to the real class).

As shown above, the EclipseWiki view has some tabs at the bottom to switch between editing, browsing, and help, and you can choose from three wiki formats (Ward’s Wiki, TWiki, and SnipSnap). Sweet.

Overall a very cool little plugin. I preserve my simple and easily editable text format that I can hack straight from my IDE while I’m there… and I get the benefits of having a Wiki framework to make it look pretty and link it all together. And down the track if we need to move to a full blown wiki, it’s just going to be cut and paste.

Great work guys. Recommended.

JoSQL is a pretty addictive API for querying java.util.Collection classes. The more I use it, the more I like it.

This weekend I had a scenario where my Collection was full of objects implementing a custom Event interface - some of them SystemEvent, and some of them MonitorEvent (and one day, potentially, a host of others). MonitorEvents have a bunch of additional routines they expose which I needed to query on.

So, how do you filter out all the MonitorEvent instances out of the Event collection, then apply a query only relevant to MonitorEvent methods so you can extract only a subset of those that match your criteria? First you talk to Gary at JoSQL support… And then you write three lines of JoSQL…

    Query q.parse("SELECT * from a.b.c.MonitorEvent " +
       " where class.name = '" + MonitorEvent.class.getName() + "' " +
       " and orgId = " + orgId +
       " LIMIT " + max);
    // eventQueue is my List of Event objects
    QueryResults qr = q.execute(eventQueue);
    List myList = q.getResults();

Of course, there’s actually a bunch of other ways to do this. I could add a getType() method on my Event object, and be done with the class filter. Just query for objects matching the given event type (but that might not make semantic sense depending on what an Event represents).

Another option Gary suggested was to write a custom JoSQL function which does an instanceOf() check (the ANDs get applied before the cast, so life is all good). In fact, he mentioned this feature might even make it in 1.3. Too cool.

Anyways, really happy with the expressiveness JoSQL gives me to do all sorts of collection querying. Great stuff. Loving that JoSQL goodness…

I’ve been meaning to have a play with some of the “dynamic proxy” type mock frameworks out there for a while and yesterday I finally had a chance.

For most of consulting stuff I’m writing J2EE tests (EJB,MQ,JDBC,JNDI,Web stuff) and I’ve found Mockrunner to be the business. Huge fan. But MockRunner works on providing mock implementations of InitialContext, HttpServletRequest, and all those other essential classes in the JEE space.

What I was after was a way to mock out a particular interface in my own code (without writing an empty implementation of that interface by hand). There seems to be two main players in the “dynamic” style of the mocking space: EasyMock and JMock. They both seem to have a fair bit of traction, so I thought I’d take a look at both.

I had a look at JMock first, since it’s probably got the bigger buzz (and every codehaus project I’ve played with has been pretty smick). There were a couple of things that I had trouble with:

• Your test classes have to extends their MockObjectTestCase. This is a bit of a showstopper. I already have other JUnit base class extensions that I want to use (which I’ve hacked in some custom Spring stuff) and found this restriction pretty arbitrary.
• Method names are stored in strings. It’s going to make refactoring a little trick… but not a showstopper by any means. I miss the command completion, so it’s a little annoying, but I can see what they’re doing at it makes sense from a design decision.
• Syntax sugar tastes a little sour at first. I’ve heard lots of good things about the “naturalness” of the JMock API and that your code reads like a spec. The whole idea looks pretty cool… and you end up with something pretty concise… but my head wasn’t there and the one example in the doco didn’t take me to a place where I could generalise in my own tests.

After getting a little frustrated with JMock, I thought I’d have a look as EasyMock. I first heard about EasyMock in an appendix to Pro Spring - geez that’s a good book - so I was keen to give it some airtime too. A few things:

Both APIs have the capacity to mock either interfaces or classes (though to mock classes you have to add a dynamic bytecode generator jar - to be expected). Both seem to have plenty of traction. Can’t really go wrong with either depending on your needs.

EasyMock is definitely the business for me. Looking forward to giving it a more solid workout over the next couple of weeks.

After reading and reviewing MicroISV, I’ve done a brain dump on bunch of key software business ideas I learnt from that book. This stuff may be old news for you, but it’s really making me think right now…

• Forget the VC thing for now. A 200 page business plan isn’t worth it… but a 2 page one probably is. There is power is committing stuff to paper and if it forces you to cogently present your “one big idea”, and how you’re gonna get there… it’s worth it for you. Anyways, you’re much more desirable to a VC if your app is out there and creating buzz then if you’re still getting off the drawing board.
• You have to be able to clearly define your target market… and the smaller your target market the better. That seems weird but it’s like this: there are 10000 other online photo organisers out there and how is yours going to break through the noise? You probably can’t even affort the Adwords to get visible. Now.. online photo organisers that are niche targetted for wedding photographers? Now that’s a market. Wedding Photographers have heaps of money, you can look up 30 in your local yellow pages, and probably drop in and talk to a few. You can add real value in your design, promote it more easily, and make a good living for you and yours.
• Users don’t care about technology and you probably shouldn’t either. Does it matter that it’s AJAX powered and uses the latest MVC framework? No, that’s not a selling point. To use the above example, a selling point is that you can transform your photos with a single click, and view the previews in realtime to make the call on what the right contrast is. That’s stuff users care about. People don’t buy the steak, they buy the sizzle. So make it sizzle with practical features that are easy to use and easy on the eye. Spend some money buying some nice icons, and get a nice template for that web app. It’s likely to have more appeal to your users than that new infinitely scalable and configurable web framework that will take you three months to learn.
• Small companies in the bootstrap stage can’t affort big marketing $ and shouldn’t try. You don’t have the expertise or the $ to throw at marketing, so build organically – in other ways. You’re likely to get much better return from blogging it, writing articles about it, getting it reviewed, and generally creating your own buzz than spending thousands on ads.
• Release it for sale earlier rather than later. Don’t spend three years on it perfecting it, you might not even have a decent market. Keep your business model “non-binary”. Get something out there that someone is willing to pay for then iterate, iterate, iterate. If no-one’s willing to pay for it then at least your found out early and can move on to something more profitable.
• You’re better off release a new enhanced version of your current product than have an ever-expanding line. People will line up for an impressive v2 or v3 who won’t necessarily love your new clipboard manager app.
• Focus on Revenue. It’s all about revenue. This was actually a big eye opener for me. Fight your programmer instincts and ask yourself “What’s the minimum coding I can do that will increase sales?” You might think it’s a cool new feature but if it doesn’t swing new users your way, it’s not worth implementing. What feature would really make your users life easier? What would really save them time? Implement that.
• Be conservative about your profit estimates. When budgetting with your wife, plan for $0 revenue from this thing. Then if everything goes brown, you’re still happily married. This is a good thing. It’s worth protecting. Make sure they are on board with the huge time suckage this thing is going to be – they are paying the price for this so they better know that they come first.
• A big part of getting your ISV going is bootstrapping. For most of us that means working a day job and powering on after hours / part time. You’re better off having a plan B than just quiting your sucky day job and planning on becoming a Software Giant. Hold on to that dream – it’s what will keep you going – but add some wisdom to the passion. If you starve to death in the process, or you lose your family home, well… I think that price is too high. YMMV. Don’t think “if only I had six months off I could develop a killer app…” start now at 10 hours a week in the early morning and actually execute on that vision.
• Execution is everything. Steve Jobs said “Real Artists Ship!”. It’s not about the talk, it’s not about perfection, it’s not about a million features. The ultimate validation of any artist is getting their stuff out for public consumption. Be brave. Get it out there and listen to your customers, beta testers, bloggers, and others who will say it’s great/ok/fair/rubbish and give you invaluable (and sometimes painful) insight into how to make it unbelievable.

Just finished reading MicroISV: From Vision to Reality and I have to say that this is one sensational book. If you are interested in starting your own software company, then this is one book that you need to get a hold of.

The focus of this book is starting a small product-based software company with a vision to grow it into something great. But by far the most valuable bit for me was the 50 or so interviews that the Bob Walsh carries out through the book. There interviews the startups of various sizes, their bootstrapping strategies, their marketing plan, how their product came into being, how they improved their sales, what kind of revenue you can expect and so on.

But the interviews aren’t just with software guys. There’s also interviews with editors of CNET on how to get a software review, legal guys on license agreements, eCommerce providers on how to organise credit card payment for your app, Google Adwords folks on how to improve your advertising, and even guys from Microsoft Acquisitions on how get bought!

Overall I’ve found this book invaluable. Some of the really important stuff he covers includes:

Overall a fabulous book chock full of helpful info. I’ve done a brain dump of about ten things that were really helpful to me. I’ll post it up here over the next week or so.

If you’ve got a vision to be a software entrepreneur, just go get it.

If you live in Australia, I recommend bookware - great folk to deal with.