One thing about my current theme that was really annoying me was that my trackback URLs were pushing into the sidebar. Roller trackbacks are faily long, and there's no way I was going to go mucking about with the code making them shorter.

So then I remembered that the fancy new Google Analytics system does something nice with URLs that are too long. If you set overflow:hidden on the div, then the URL is cropped if it gets too long, but you can still select the entire thing – the div scrolls when you select text, and double clicking works too.

At first I started editing the roller template, but that is the wrong way. Just edit the div.trackbackUrl style in your stylesheet instead.

More roller hacking.

So it looks like I'm not the only one who's a bit annoyed about crappy API documentation.

Even Microsoft can't get it right. And I'm not surprised. How many Microsoft developers have been on a creative writing course? Something to think about Bill.

Like I said before, API documentation is hard problem. The only way to produce good API docs is to get the developers to write good copy. No two ways about it. It's a good skill to have and something that should be encouraged. And yes, I know, it's damn hard.

Back to the doctor today, I had to get a mole removed. They can't enough of me.

The worst thing about minor surgery is the fact that you are conscious. Of course, the drugs are great and work really well (and amazingly quickly), but you still feel all the tugging and pulling.

The irish health service may have it's share of problems at the moment, but the people who work in the service are really excellent. I've met a lot of them this year and the standard of care once you get admitted is really great. I do think that the (traditional) media does it's usual trick of highlighting bad news. Like any organization, most workers are just trying to do a great job despite all the bureaucratic silliness.

Getting a health service to work efficiently is a really hard optimisation problem. It's not just about money – you have to get the standard of care right. It's not even a straightforward problem of deciding on priorities because a lot of your resource allocation has to be done on the basis of ethical criteria. I studied moral philosophy in an earlier life and, hey, it's one hot cookie.

Anyway, I am not going to offer some half-baked opinion on how to do things right. How did we end up with effective market economies in the first place, the kind that work out OK for most citizens? The ancient greeks put a whole lot more thought into it than we ever did, and we just happened to stumble upon an idea that really worked, almost by accident. So the default strategy as regards health care should really be to keep trying to find new solutions. There has to be a few "good enough" local maxima somewhere in there, and we may even hit the big time.

An important and serious contribution to the advancement of the mathematical sciences.

A new kind of ringtone!

So this weekend myself and the family, big culchies that we are, are off to the Dundrum Town Center (pathetic flash site - hello guys, HTML please) for a gawk. This is Ireland's latest and greatest "mall", which includes a Harvey Nicks, and a Sony Centre.

Hold the phone?

A Sony Centre? Well, like any gadget-geek-freak programmer I was just gonna go wild buying stuff! Not any more. You know why.

By the way, if you're still buying stuff from Sony, shame on you.

And if you think the little guys can't make a difference, think again. I'd like to show you something. When the SCO thing was just starting, many moons ago, I wrote some emails to companies that were selling SCO, informing them of my, er, distaste for their behaviour. Here's a sample:

Dear Sir/Madam,

I am an independent software consultant and I notice
that you are a reseller for The SCO Group.

As I am sure you are aware, The SCO Group has made
baseless claims to own the Linux Operating System.
Such claims have already been withdrawn by SCO in
Germany by court order.

I'm afraid that so long as [NAME DELETED] continues to
support the actions of The SCO Group by providing a
sales channel for them, I will refrain from recommending
your other products and services to any of my customers.

Yours Faithfully,
Richard Rodger.

-----------------------------------

Dear Richard,

Thank you for your email.

Unfortunately we have never heard of you, therefore, we are
unaware of the effect this will have on the worldwide sales of SCO software.

Kind regards,
[NAME DELETED]

And where is SCO now? Bet you've changed your strategy. Lot's of little guys that you have never heard of can be quite noisy.

If big companies do nasty things, complain! They need your money to survive you know.

Oh and in case you think I'm some sort of free software nut, I have my own software company, and I sell software for a living, and I rely on copyright laws to do that.

So this post is part of my continuing series on hacking Roller.

I use the textile plugin when typing up most entries as it saves on the amount of typing you have to do. If I'm going to write up pure HTML I'll do that in Emacs thanks very much.

But the textile formatter has a really annoying bug – it messes up apostrophes! They end up the wrong way round, rather just the normal old ASCII character, which is what I want. So into the source we go. The textile formatter source is available from sourceforge.

It turns out that it's all done with regular expressions, so I just disabled the relevant ones in the Textile.java file, and jarred up a patched version.

With my local JDK 1.5 compiler. And tried to run it on the server (JDK 1.4). Oh Joy. Website down. Remember to use the source and target options when you try this at home. Tomcat is such a pain to restart. Actually I wrote a neat little Tomcat restart script, expecially designed for data-center staff with no patience. I must post it sometime.

Anyway, if the apostrophes in this post are still wrong, I will cry.

Oi! Kansas! You know who's having the biggest laugh at you? The Big Man himself.

Hey didn't you guys try to redefine PI at one stage as well?

Microsoft's new extension to RSS is a pretty big deal. Now normally I would roll my eyes at yet another attempt to smother an open standard, but this time it's actually not so bad.

You know an idea is in the air when many people are coming up with it independently. The idea that I'm taking about is micro-content. We have a lot of different people working on this at the moment, and RSS has shown the way. Even that new database thing by that annoying startup is all about micro-content.

I've been working on some ideas for a micro-content "broker". A piece of the infrastructure that makes it easier to synchronize and exchange micro-content items. Now, I knew that Lotus Notes had some cool synchronization algorithms, and that Ray Ozzie had probably had a hand in bringing a few of them over to Groove. I wanted me some of that action, but it was all tied up in the proprietary code.

So what has Ray gone and done? Only spec'ed out a working version of the synchronization algorithm! Way to go! And it's politically correct and all, using a Creative Commons license. This is gonna be big.

You're not going to like this.

Tom Evslin points out that APIs will make or break most of the new web applications. And he's dead right. In fact, API's are where all the really interesting stuff happens, because you get people doing things with your service that you never dreamed of.

Now we're talking specifically about web service APIs here. Because it's the network effects that make the magic. Metcalfe's Law, Reed's Law, even Godwin's Law. Take your pick. So these days, any sensible web services entrepreneur is going to want to get an API on the boil sooner rather than later.

Now I've been doing some work with the "big" APIs, like Google, Amazon and friends. I'm building a set of examples for my new product (due out shortly). One thing I will say is, go REST young man! SOAP interfaces are the suck. They raise the bar to entry far too much. Heck, do you realise that most people not only do not understand XML Namespaces, but are actually afraid of them? Too many nooks and crannies. Too much to go wrong. Amazon, for example, seems to change their namespace on a regular basis – it's date based. What a pain.

The other thing about APIs is that they are very very hard to design and maintain. I've run into this issue quite a bit with my Java Components. It is basically impossible to fix a broken API after the fact, but version 1.0 of anything useful still has far too much complexity to get it all right the first time. Actually, I took an approach to this problem based on some ideas by David Bau, which has worked out quite well. All the callback interfaces in my components use an intermediate abstract class to provide a DMZ for future changes. I've already used this succesfully to fix some problems, without any users having to recompile.

So how can you apply this to web services, where there is no inheritance model? The most important thing is to ignore what you don't understand. HTML is the classic example of this. The second thing is that you must support until death-do-us-part all your declared objects, methods, values and properties. You just gotta. Think real hard about them before you publish them. It's very difficult to get right, but that's programming for you – not as easy as it looks. And finally, don't reinvent the square wheel. You absolutely, positively should look at what other people are doing, how it's worked for them, and what you can do better. Build a Toyota, not a Trabant.

I predict (OOH, dangerous sir!) that a market will develop in helper applications and third party API providers for websites and services. In fact, you can appize (you heard it here first: [æp'aiz]) any site, if you really want to – just look at all the blogification (OK, I'll stop now) going on. So, start your motors gentlemen! We've just got ourselves a new business model.

Business ideas are worthless. Trouble is, when you get one, you can never believe otherwise. They usually strike around bedtime, and before you know it, you've designed a full-scale enterprise architecture to support the concept by 1AM, prepared an initial marketing plan by 2AM, and by 3AM you're wondering about how to structure refunds.

Great. Any idea can work, you just have to execute. I had this idea while back that you could sell "words". You'd have some sort of attention-getting site, and then punters could buy the right to be linked from a certain word. Yeah, I know, RealNames and all that. Still, this would be a "Web 2.0" web service thing with an API and so forth. Great.

In the cold light of day you end up discarding most of these brainwaves. Still, you wonder, maybe some of them could work.

So I was delighted to come across AllYourWords. A deadringer! I jumped in and bought some words right away, just to say thanks for going with the idea. So it would have worked!

Business ideas are worthless because if it's just occured to you, somebody else has probably already implemented it (If that breaks your heart, just remember, Google wasn't the first search engine).

So you want to start your own software company? You've got a great product idea and it's a simple case of programming to get the first version together. Then you have to put up a website, and a payment system. Oh and there's a load of documentation to write. Oh and support. And don't forget regression testing, a formal release procedure and backwards compatiblity, and after all that, marketing and promotion and managing ads and...

Right, still want to start a software company? The truth is, if you have never built an actual product, that is, a coherent entire solution to a business problem, you are vastly underestimating the level of effort required to create one.

Most developers work on software projects. Custom software projects for in-house use, or custom software projects for direct clients. For this sort of work, you can provide the client (internal or external) with so much direct support that you don't need all the collaterals that go along with a software product. And someone else probably did the selling. And you'll have students in to do the testing, and so forth. In fact, if your company has any clue, they will make sure that you can focus on your job: writing code, rather than doing any of that other stuff. And it's mostly a good idea to organise things this way.

So if this describes your situation, and you still want to create our own company with your own products, how do you go about it? Well, write a business plan, get venture funding and sit back. Oh no wait, sorry, parallel universe.

You have to learn how to build a product and you have to learn how to run a business. Learning how to build a product is easier than you think. Start an open-source project and run it as a virtual product. Believe you me, even free doesn't sell by itself. And you'll need to get the whole software product production thing down before you go off trying to the business stuff.

Next, get yourself in front of paying customers. In your day job, try to move into one of those "client-facing" roles. Push outside your personal comfort-zone here - you're gonna need to do that big time when you want to make your own money. There's nothing like dealing with customers on the front line to change your perceptions. You really should work as a freelance contractor as well, for a while at least. When you have to put your own bread on the table, you learn a lot really fast.

And then comes the most difficult part. You've got to let go of all the safety nets, quit your job, fire your clients, and start trying to sell. It's very easy to get stuck at this point, with a half-developed product that will never see the light of day. Because now you have to stop thinking like a programmer and start thinking like a business owner. Keep cutting features, for a start. Remember, every feature has to be documented and tested and supported.

Product development takes ten times more effort than custom development, probably more. Be prepared.

By the way, if all this sounds like too much hard work, you can always start a web service.

I've been writing about a Perl sudoku solver. Sudoku is a great example of a problem worthy of study. It looks easy from the outside, but when you have a go at solving it, it gets tricky very quickly. The comments on this series have included suggestions to go recursive. Well, that's definitely a better approach than the one I am documenting here - but the nice thing is that I know that for sure because I tried it the simple way first. Less is not always more. Anyway, this series is a retrospective, so if I may beg your indulgence, we shall continue to stick our heads in the sand for a little while longer.

So where were we? Well, at this point it may help to actually name some of the processes we have applied to solve sudoku puzzles. This page on solving sudoku provides us with the necessary nomenclature. If you review that page, you'll see that what is refered to as excluding and reducing in the Perl code is more commonly known as removing singles and hidden singles respectively.

Once I got this far I was a bit stuck. I refused to allow myself to look up anything on the web (yeah, a bit pointless, considering my original aim was to win €150!). Eventually I realised that if you have two cells, with just two number possibilities in them, then no other cells in the same vertical, horizontal or home square can have those two numbers. If other cells did have, say, one of the numbers, then that would solve one of the double number cells, leaving the other inconsistent with the other solved cell. Ok, an example: say we have 12 and 12 and 123 in the top left corner, with all other relevant cells solved. Then we can exclude 1 and 2 from the 3rd cell, giving 12 and 12 and 3. This approach is known as naked pairs.

Actually if you think about it for a moment, this technique also applies to sets of three cells with three numbers, four cells with four numbers, and so on. I have only coded it up for pairs however, and that has solved all the sudokus that I have tried.

Before I show you the code, let's talk economics. You see, I had to stop doing the Irish Independent Super Sudoku. Firstly, and most importantly, entering a load of hex digits into square boxes every weekend get boring very quickly. Secondly, I wasn't winning anything and it was starting to look like I might actually actually lose money. In order to enter the competition you have to buy the paper, €1.50, and then you have to post off the entry, another €0.48. Do that every week and after 76 weeks, you'll hit €150.48 (I was already 10 weeks down). Plus it's boring filling out the squares. Did I mention that already?

Right, here's how we do naked pairs. By the way, Perl was really great for hacking out this solution, but it is still pretty verbose. I'm considering porting this to Javascript and some other scripting languages, just for the craic.

sub excludePair {
  my @cell = @{shift()};
  my $prow = shift;
  my $pcol = shift;

  my $valbin = $cell[$prow][$pcol];
  if( 1 == keys(%{$valbin}) ) {
    return;

  }

  my $cmpstr = join('',sort(keys(%{$valbin})));

  my @vals = keys(%{$valbin});
  my $valsmatch = 0;

  for( my $c = 0; $c < ($sqsize*$sqsize); $c++ ) {
    if( $c != $pcol ) {  
      my $testbin = $cell[$prow][$c];
      if( 2 == keys(%{$testbin}) ) {
        my $teststr = join('',sort(keys(%{$testbin})));
        if( $cmpstr eq $teststr ) {
          $valsmatch = 1;
        }
      }
    }
  }

  if( $valsmatch ) {
    for( my $c = 0; $c < ($sqsize*$sqsize); $c++ ) {
      if( $c != $pcol ) {  
        my $testbin = $cell[$prow][$c];
        if( 2 <= keys(%{$testbin}) ) {
          my $teststr = join('',sort(keys(%{$testbin})));
          if( $cmpstr ne $teststr ) {
            for (@vals) {
              delete(${$testbin}{$_});
            }
          }
        }
      }
    }
  }


  $valsmatch = 0;

  for( my $r = 0; $r < ($sqsize*$sqsize); $r++ ) {
    if( $r != $prow ) {  
      my $testbin = $cell[$r][$pcol];
      if( 2 == keys(%{$testbin}) ) {
        my $teststr = join('',sort(keys(%{$testbin})));
        if( $cmpstr eq $teststr ) {
          $valsmatch = 1;
        }
      }
    }
  }

  if( $valsmatch ) {
    for( my $r = 0; $r < ($sqsize*$sqsize); $r++ ) {
      if( $r != $prow ) {  
        my $testbin = $cell[$r][$pcol];
        if( 2 <= keys(%{$testbin}) ) {
          my $teststr = join('',sort(keys(%{$testbin})));
          if( $cmpstr ne $teststr ) {
            for (@vals) {
              delete(${$testbin}{$_});
            }
          }
        }
      }
    }
  }
}

Well that's a candidate for The Daily WTF anyway. Notice that I was too lazy to actually code up the home square part. Oh well.

This subroutine assumes that it is only called on cells with two numbers left. It searches for another cell that matches the current one, and if found, removes the two numbers of these two cells from all the other relevant cells. The first two for loops handle the column, and the second two handle the row.

The expression join('',sort(keys(%{$testbin}))) gets the keys of the cell, that is, the numbers in the cell, sorts them and concatenates them together to form a canonical comparison string. Probably not the most efficient way of checking each cell for two numbers.

Ok, I guess I'll let you have the whole damn thing now. Download the Perl code at your peril. It's public domain and the usual disclaimers apply (not guilty for "thermonucular" destruction of your computer, etc.).

I am quite interested in seeing how far one can push this type of heuristics-based approach. So the plan now is to write up some sort of test harness and generate a few unsolvable sudokus. I would like to keep adding heuristics as described on the suduko hints page above and see how far we get. I may then compare it to a proper solution, using real algorithms, but for now, Good Bye, Good Night and Good Luck!.

Sure I suppose I'd better give this Google Analytics thing a go. If only for the fancy graphics. I already use awstats and that's OK as far as it goes.

The Google stats system is pretty flash, but surprisingly slow. I wonder is that because it was not developed by Google (it was originally called Urchin and Google bought it). Since it's free there's basically no downside to trying it out.

So what will Google buy next – the million dollar home page? that's about the only business model left on this planet…

Thanks to Adam Stiles for this one.

I fell off my chair the first time.

Yoda, telling it like it is.