Got some stupid melody stuck in your head?

Well go find out what the song is!

I've been following this blog called Creating Passionate Users for a while. It's by the people who write the "Head First" books. Now I've never actually read any of their books, but I did use the amazon preview to check them out. Wow. Wish I'd had textbooks like that in school. The books are amazing at presenting information. It's hard to explain, but the format and style of the presentation just plugs right into your brain.

Anyway, I started following the blog and they spend a lot of time describing the psychology behind their text production. Well I was really taken with it and wanted to try it out. I used some of the ideas for a tutorial/article about CSV and IP address location. Of course, my attempts are pretty woeful in comparison, but here's the interesting thing - it was a lot more fun to write than most of my documentation. I've posted before about the real difficulties of producing decent API documentation. And this "Head First" stuff looks like a good way to tackle the problem.

Today, they have just posted a great little article summarising the main points of their approach. If you read nothing else in the blogosphere today, read this, it's worth it.

Do you dojo? Dojo is the JavaScript toolkit that I'm going to use from now on. Why? Well I did a quick eval of most of the toolkits out there, and it made the best impression. I wasn't looking for database-oriented features. I was looking more for something to help me put together DHTML interfaces.

The thing is, when you enter a new programming space you are faced with a real challenge to your time. You can't properly evaluate each option, because that means learning each system completely. And for programmers, since most learning is done by doing, that would just take too much time. If you can find some neutral reviews of the options in your chosen area, great. But what you find most often are opposing position statements - heartfelt defences of chosen frameworks and thinly disguised contempt for the other options.

My approach in this case is to check out each site, check the level of activity, the state of the docs, the overall approach, the background of the main committers, all that stuff. But not exhaustively. You want to trust your intuition. After all, the right framework for you might not be the "best" framework, the one to rule them all. So, Blink.

I opened my eyes, and I saw dojo. Whojo? It's the JavaScript stuff behind JotSpot, apparently. Technically it's a merger of several extant frameworks into a sort of JavaScript Gestalt. In other words, a great big grab-bag of JavaScript goodies! And they have a pretty website!

The real biggie for any JavaScript toolkit is HTTP request handling. Hiding all that dodgy XMLHttpRequest crap. Such a humane interface (NOT). And dojo sure does it nicely. I decided to use dojo for the online demo of my new product: XML Manager Demo. This demo submits an XML document for server-side parsing, and includes a set of XPath expressions defining what to parse out of the document. If you use dojo together with the JSON data format, the whole thing is a cinch. Here's the request code:

dojo.io.bind({
  url: 'demo-handler.htm',
  method: 'post',
  postContent: jsonquerystr,
  handle: function(type, data, evt){ 
    if( type == 'load' ){
       jso = JSON.parse(data);
       if( jso.data ) {
         setTableData( jso.data );
       }
       else if( jso.xml ) {
         setXmlData( jso.xml );
       }
       setMessage( jso.stats+
                   (jso.msg?jso.msg:'') );
    } 
    else {
      setMessage( "Sorry, "+
        "there's been a server error." );
    }
  },
  mimetype: 'text/plain'
});

Pretty nifty huh? If you want to see the whole thing, here's the code: demo.js (Yeah, I know, that code needs some cleanup - hey, it's on the to-do list...).

The only little problem is that there is no user feedback when the demo is on the server-side doing the XML parsing. The user just has to wait. Not so good.

Ages ago I had a similar problem with the back office admin site of a client. Now I was using a hacked together pre-AJAX solution - an invisible iframe with a hard-coded form. But it worked pretty like the modern AJAX model. Anyway, I had the same problem: how to provide feedback to the user when a request has been submitted behind the scenes.

What I wanted was a progress bar. It would start with a set of grey boxes and change them blue one by one until the request was done. Of course, we have the little issue of not knowing how long the server is going to take. So the idea I came up with was to make it an exponential progress bar. Each little box takes longer than the last one, rather than all boxes dividing the time equally. So you never actually get to the final box. Instead, when the server returns, you mark the boxes that have turned blue a darker gray. What you are left with is an indication of how long the request will take the next time (based on the principla that, as a general rule of thumb, tomorrow's weather has a 70% probability of being the same as today's). This turns out to work rather well, and users pick it up right away without explanation. The whole thing is completely visual.

So this what I want for my demo, a web progress bar, not a desktop progress bar. So at first I was just going to cut-and-paste (ah the joys of being a professional!) the old code over to my site. But then I thought: hold on, what if I write a dojo widget to do this? Coolaboola says I, we'll do this properly!

Well, it turns out that dojo is, um, challenged, in the documentation domain. But they do have starter article on widget writing. It does tell you pretty much all you need to know to write a dojo widget. And that's the problem. I don't want to write a dojo widget, I want to write my own widget. Hey, I might submit it to the project later, but for the moment, as a good engineer, I want to keep my custom stuff from polluting the dojo framework. Hmm.

So here then is my first utterly simple and completely pointless widget, to be morphed into a progress bar live on this blog! All it does is display the word "Foo" with a border. But it is a proper dojo widget, and it is as separate as possible from the main dojo code. I say, "as possible", because complete separation turns out to be, well, difficult. I am just hacking about here, so bear with me.

Dojo widgets have their own HTML and CSS files. I placed the files for my Foo widget in the same folder as the test HTML page. Here they are:

<div class="foo"><b>Foo</b></div>

div.foo {
  border: 1px solid black;
}

Whoopy-doo, says you. Indeed. But hey, it's a start.

So the main page, the page with the user interface, looks like this:

<html>
<head>

<script type="text/javascript">
	var djConfig = {isDebug: true};
</script>
<script src="dojo.js"></script>
<script>
dojo.require("dojo.widget.*");
dojo.require("dojo.widget.Foo");
</script>

</head>
<body>

<div dojoType="foo">
</div>

</body>
</html>

Notice the isDebug declaration. That's real handy. Use it.

The dojo require statements are a dojoism that tells the dojo system about the widget support code that we need. It's standard dojo stuff and covered in their docs. The div with the dojoType attribute is where the magic happens. This makes our Foo widget appear.

Now for the widget code itself. This pretty much a direct copy from their example.

dojo.provide("dojo.widget.HtmlFoo");
dojo.provide("dojo.widget.Foo");

dojo.require("dojo.widget.*");

dojo.widget.HtmlFoo = function(){
    dojo.widget.HtmlWidget.call(this);

    this.templatePath = dojo.uri.dojoUri("foo.html");
    this.templateCssPath = dojo.uri.dojoUri("foo.css");
  
    this.widgetType = "Foo";
}
dj_inherits(dojo.widget.HtmlFoo, dojo.widget.HtmlWidget);
dojo.widget.tags.addParseTreeHandler("dojo:Foo");

This is just the object-oriented JavaScript that defines the Foo widget. I still have a pretty weak grasp of all this, so let's just leave it as an artefact and move on. Suffice to say that you need the Html prefix on your widget name, otherwise the voodoo won't work.

The tricky bit is where you put this file. You have to put it in a folder structure where dojo can find it. It needs to be under src/widget, relative to your main HTML user interface file. Why? Dunno, just does.

And amazingly, the whole thing works. Next time I'll be blogging about my attempts to get this toy code to actually do something. I still want that web progress bar. Hopefully this blog entry will save you the half hour of trial-and-error I spent on this.

One final word, to the dojo guys. Love your stuff, but please just stop coding and write some docs. Pretty please? Cherry etc?

Yeah. So it had to happen. Cats.

And you though this blog was cat free – hah!

So my blog has this ad banner down the side, which may or may not annoy you, but hey, what's a blog without adwords these days? Anyway, it suddenly struck me that I was failing to advertise my own products on some prize real-estate. Like, Duh!

So, forthwith, there shall ads for my products! Big shiny ones. Really big shiny ones. Right at the top.

I am such a dumbass…

I have changed the price of our first product, CSV Manager from $97 to $47, for the entry level license. This was not an easy decision. No pricing decision ever is.

CSV Manager was launched in September 04, so I do have a lot of data on sales at the $97 price point. Enough to generate a reasonable estimate of the value of the demand curve at that point. But it really is a black art. I have decided that the information obtained by changing the price is more valuable than the possible loss of revenue.

But there is another factor. One of the drivers for starting a business is to solve problems for people. To "create value", to put it in marketroid-speak. So what is value? What is wealth, in fact? People are wealthier when they get more for less. In this century, we have indoor plumbing. Two hundred years ago, you had to be Queen Victoria if you wanted enamel. Another example: Virgin Galatic. Pretty soonish you'll be able to view the final frontier for less than the price of nice house. Space is quite a bit more accessible than it was in 1969. So providing value is just the same as creating wealth. More for less makes you money. The true purpose of a good business is to make its customers wealthier. That's what Henry Ford did with the Model T, that's what Skype is doing today. A good business makes money for its customers.

And the purpose of technology is to make stuff cheaper. A true technology company keeps lowering its prices. Year-in, Year-out. That's why Ricebridge prices will get lower each year.

So why is XML Manager priced at $97, the old, high price? Because it's a new product. It has to prove itself in the market. Once that happens, and sales ramp up, we turn on the wealth tap and make it cheaper.

You may be thinking, "this guy is nuts! He's throwing money away!" Maybe, but our code is there to be used. The more it is used, the more valuable it becomes. More users mean more squashed bugs, more FAQs, more feedback, more features, and so on. By the way, that's what makes Open Source work so well – many eyeballs. Well, we have to earn a living, so we can't Open Source our products, but we can approach Open Source, asymptotically. And in doing so, we end up with products that people want to use, not products that they are forced to use.

These ideas are similar to Jonathan Schwarz's thoughts on "Volume". Now he does go on a bit, but he's basically right. Giving people more power to get stuff done is the purpose of a tech company. (hey, Jonathan, where's my server? hope you're not just keeping them for the big boys. I have benchmarks too you know!)

So this is all nice and warm and fuzzy, especially for new customers – cheaper stuff, Yay! It's not so nice for existing loyal customers though. They get a wee bit annoyed, and rightly so, when stuff they just bought gets cheaper overnight. So here's a pledge: If you are an existing Ricebridge customer you will always get a nice big fat discount on new stuff. And even then, if you think you've been treated unfairly, just let us know, and we'll find even more free stuff for you.

Well, what do you think? Am I about to run my company into the ground?

One of the beta reviewers for our new product, XML Manager, asked me why I had not documented the development process on this blog. She suggested that it would be very interesting and useful for potential clients to see the development unfolding.

Well, it is a valid point. In fact, Eric Sink has some good thoughts on this very question. On the plus side, you give your customers a clear idea of where you're going, they know what products are coming along downstream, they can plan more effectively. On the other hand, you give your competitors a head start.

Seems like it comes to down to a question of, "do you love your customers more than you hate your competitors?" When you put it that way, it's a no-brainer. So I will be discussing the development of the next Ricebridge product. Why did I not do it for XML Manager or CSV Manager? Well the first mistake was not having a blog. The second mistake was not having a blog. And the third mistake was writing a business plan.

Yeah. I spent so much time writing a bloody business plan in the first half of this year I nearly bankrupted myself. More about that later.

So, you're in for a good read. Our next product is a standalone user management engine. It has a few nifty features you won't find in the user handling of your common-or-garden web framework. And it's half written already and in production for a client. This will be a classic case of productising consulting-ware. I'll be giving you the inside scoop, all the tears and all the laughter. Hey, with a few intelligent comments you might even get an honorary mention in the docs! (and no, there won't be a nerd movie.)

A lot of the discussion will be market-focused rather than tech-focused. Hey, this is a business. If you've been thinking about setting up your own software company, or thinking of running a weekend micro-ISV, then this is your chance to get an insider's view before taking the plunge. So hop on, this could get bumpy!

Big news this Monday. Ricebridge Software has launched our second Java component: XML Manager. It turns your XML into a list of data records, ready for processing. Check out the demo (all AJAX-ified, if I do say so myself!). We're doing a soft launch on this as it's far to close to Christmas to get into a big launch scenario. But come the New Year we'll have lots of fun.

This blog is supposed to be about starting a software company so you'll be hearing a lot more about my product marketing efforts over the next few months. I was holding off a little while we were finishing XML Manager, but now that the cat's out of the bag, I can start pontificating about how to run an ISV! Now I'm no Joel, I don't always do things perfectly, and if you've been thinking of starting your own software company then you might as well follow along and watch me make all sorts of entertaining mistakes. But no fatal mistakes. Rule number one of this trade is to set things up so that you can't fail. We're talking zero overheads, and self-maintaining systems.

Anyway, back to XML Manager. To reward all my readers, I've a little Christmas treat for you. Anyone who posts a comment before Jan 1 2006 gets a free single developer license. Hey, that includes a free CSV Manager single dev license too! So why not – you never know when you'll need to get a load of XML into a database!

Possibly the daftest thing you can do with Skype: WeeMee.

Roller shows a list of recent entries and recent drafts on the left sidebar of the weblog editor page. This is a really handy little feature and lets you access entries and drafts really quickly. The problem is that only 20 entries are shown as standard, and there's no setting to change this. Back to the code!

So the sidebar template is in weblog/WeblogEditSidebar.jsp, surprisingly. A quick scan of the code reveals that the list of recent entries is predefined by the model:

<c:forEach var="post" items="${model.recentPublishedEntries}">

Looking at the top of that page, we see that the model is org.roller.presentation.
weblog.actions.WeblogEntryPageModel. That's kind of a deep package structure, but OK. So inside that class, we hack up the getRecentPublishedEntries method. It's actually just a parameter change:

    public List getRecentPublishedEntries() throws RollerException
    {
        return rollerRequest.getRoller().getWeblogManager()
            .getWeblogEntries(
                rollerRequest.getWebsite(), // userName
                null,              // startDate
                null,              // endDate
                null,              // catName
                WeblogManager.PUB_ONLY, // status
                new Integer(20));  // maxEntries
    }

Change the maxEntries parameter to however many you want and away you go.

Now to deploy. Just run the wonderful build.sh all command from the Roller source root folder and it does most of the work. Copy across the new rollerweb.jar file and restart tomcat. And you're done.

And yes, before you point it out, I am aware that the Roller source does not meet my exacting standards of indentation. The fallback strategy is to stick with whatever dumbass indentation standard the codebase you have to work on uses. That's just the way it is.

I may be a bit late to the game, but I won an MP3 player in a raffle recently. Hey, I'm cheap! Anyway, I finally got into this podcasting thing. If you're just getting into it as well, check out IT Conversations. They have all sorts of great techie stuff there. You wouldn't use your MP3 player for music now would you? Not when there's loads of nerd stuff out there. Well, actually, I'm listening to The Killers at the moment (you know, from the Champion Sports ad), and they kind of rule in a sucky way – some good morphy sounds.

So if you've read Gladwell's Tipping Point, you'll appreciate this one.

I was taking my daughter down to the local outdoor playground on Sunday, and the car park was unusually full. As in, completely. People were even parking up on the grass, and in no-parking zones. Cars all over the place. "Feck!", says I. "Look, the Park!", says herself, with no room for excuses.

Except, the local credit union car park, right next door, is empty. I'd say it's the great big scary "we will clamp you and your children unto the seventh generation" sign. So nobody has dared disgrace this tarmac. They've parked illegally everywhere else, but not in this car park.

Anyway, I have no time for this, so I just park there anyway. You can see the car from the playground and I'm ready to storm over and have it out with any clamping truck that comes along. Plus, you can see them coming along the main road so there'll be plenty of warning.

An hour later we head back to the car. The entire car park with the scary signs is now full. Looks like I've started something. As soon as one car did it, all the rest followed. Seems like the tipping point is one car.

I suppose it makes sense too – if there are loads of illegally parked cars, the clampers will take longer to get to yours. But the main reason is probably the old "everybody's doing it so it must be OK" line. So my tip for the week is, park it, and they will follow. Want to make use of a reserved car park? Just park and you'll soon have a bunch of followers to take the heat…

Here's one for all you MBAs out there. I'm trying to work out the cost of a data center minute. Huh? What's that?

OK. Imagine you have a mid-range web server in a data center. You pay an annual fee, maybe some more for bandwidth, and maybe even more for tech support. I am talking about dedicated hosting by the way, so maybe you bought the server, or you leased it. Anyway, each minute of uptime is something that you pay for. So how much does it cost? For any given server, you can work this out, but I want to get an "average" figure. What is the market price for a data center minute right now?

This sort of setup seems to be about $200-$400 a month based on some googling. Which works out as $0.005-$0.01 a minute. Does that sound right?

I'm using Roller 1.2 for this blog at the moment. Roller 2.0 is out, but I'm in the middle of a beta-testing a new product so I'm not going to risk upgrading for a few weeks yet, in case I end up yak shaving.

I'm pretty happy with Roller. It's a great piece of code and it's been really easy to customise. I run it because I was already running tomcat, and it's just easier to keep everything Java focused if you can. (more on that later - there's a big deficiency in the webmail area with Java).

So anyway, the one thing that was really annoying me was the permalinks. The standard form is:

http://www.richardrodger.com/roller/page/richard?entry=foobar

Yuck. Not only does it look ugly, but the entry is only identified in the query parameters and is thus not analysed properly in most web stats packages (including google analytics, which I was lucky enough to get an account on). This makes it hard to tell which entries are getting the most hits etc. Also, the permalink is not search-engine friendly.

So time to put the hacking hat on. After scanning through the Velocity templates in the Roller distribution I was none the wiser. But then I decided to bite the bullet and hack the code. In the end it was pretty easy to change the permalink code. First, links of the form

http://www.richardrodger.com/roller/page/richard/Weblog/foobar

are supported (why are they not standard? dunno.), so this was my target. After a bit of global searching, I discovered the getPermaLink method in org.roller.pojos.WeblogEntryData. Replace the line:

String plink = "/page/" + website.getUser().getUserName() + "?entry=" + lAnchor;

with

String plink = "/page/" + website.getUser().getUserName() + "/Weblog/" + lAnchor;

And now the permalinks are just right. By the way, the easiest way to make this kind of quick change is to download the source and tools distributions, unpack them, and run build.sh all. It all "just works". Great stuff.

Of course, as you may have noticed, mucking with your feeds is not a good idea. If you change the permalink then all the old entries get replicated, because the aggregators think they are all new. So make this change before you go live.

Hi. You may have noticed that all my posts have replicated themselves. I changed the permalink code to a nicer format, forgetting that this would mess up all the feeds. Sorry about that.