Steve Pavlina's Non-Objective Reality

Steve Pavlina points out that objective reality, well, ain't. Actually he's on even firmer ground than he thinks.

Now I'm no Sapir-Whorf fanboy, but as it turns out, classical objective reality is also a logical impossibility. Good old Hilary Putnam showed us that.
That doesn't mean there's no there there, just that we can't talk about it without an inevitable subjectivity creeping in. The disembodied AI mind has no experiential frame of reference for creating meaning, but we do, because we experience stuff like up and down, hot and cold, red and blue, in a way that cannot be modelled with set theory (which you kinda need for the objective reality viewpoint). And no, this doesn't mean I think Berkeley was right (now he was one wacky chappy).

In case you think I can think for myself (ha ha, fooled ya!), I'm getting all this from George Lakoff's Women, Fire and Dangerous Things. A bit of a tough read, but right on the money. The main point is that we can choose to make our meanings in the world, and they reflect back on us, determining how we can think. So yes, Steve is right, your beliefs really do create reality.

Really really.

Sudoku, Part One

A while back I was stuck in bed for a week or two due to illness, and after I got bored with mobile games (well your reactions aren't the best on pain killers), I decided to have a go at a few sudoku puzzles.

Actually, my interest in sudoku was just a little bit mercantile. The Irish Independent newspaper runs a weekly "Super Sudoku" competition, with a prize of €150. Problem is, the sudoku variant that they use is not your normal 3x3 grid, with the numbers 1-9. Ah no, if ye are going to be giving away the money, ya have got ta make it a wee bit of a co-nun-drum. "Super Sudoku" is a 4x4 grid with the numbers 0-9 and the letters A-F. Now how anyone can solve that manually I do not know - I can't even solve the 3x3 ones! But I know Perl can…

So I resolved to write a little perl script to tackle this important scientific research project. Nothing like a few associative arrays to solve a puzzle… more tomorrow.

Sudoku, Part two

Bloglines Strangeness

In order to test my hacked atom 1.0 feed, I created a bloglines account and subscribed to the feed. That was all fine, but then things got funky. Bloglines only lists the first two posts. Later posts just aren't there. It doesn't seem to be cache related, as the posts are now over 24 hours old.

I also subscribed to the RSS feed for my blog to check, and that was fine. Both feeds, atom and RSS work fine in FeedDemon. Very wierd. I'll have to register with a few more online aggregators to check this out further…stay tuned.

Dealing with Bugs

If you sell software and a customer discovers a bug in your code, it's not a nice feeling. In fact, you get a very nasty sinking feeling in your gut. And the first thing that your gut says is: "shh! don't tell anyone else!".

If you listen to your gut, you can avoid some temporary pain. But your gut is wrong this time. It's always better to disclose bugs to all your customers. Why? Because most of the time, you are doing them a big favour. Think about it, up till now, all other customers have been getting along just fine. The bug probably doesn't even affect them. Yet. But sooner or later it will and they need to know what their options are.

Imagine you're the customer, you've downloaded a software product, integrated it into your system, (development or otherwise), and now a new release comes along. If things are working fine, you'd rather not bother with the hassle of upgrading. In fact, if your system uses multiple external products and components, keeping up with upgrade cycles is a real pain. So you need to know whether the upgrade is really necessary. The only way to do that is to know what bugs it fixes. If the bug is bad for you, you know you need to sort it out. If not, you can wait till the next major release.

By providing full disclosure of all bugs, fixed and open, you give your customers a little bit of help to manage their own complex environments. If you keep the bugs secret, things tend to blow up nastily every so often.

So that's what I do at Ricebridge. All bugs are accounted for. It means that customers can tell at a glance which version fixes what. And they know right away if they need to upgrade or not.

Hacking atom.vm
Well my little hack of atom.vm to produce valid atom 1.0 output was buggy: I got caught out by the atom content element and the existing showEntryDescription($entry) macro (in weblog.vm). This escapes the content which is not at all the atom way. Instead you have to declare a HMTL namespace. A quick trip over to the source of Tim Bray's atom feed shows how to do it. So I replaced the entry content code with this:

<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
$entry.text
</div>
</content>

Now everthing validates in feedvalidator. Of course, all this messing around makes me a moron. This sort of hacking is actually a really bad idea and pretty fragile, so bring on roller 1.3.

Velocity Templates

I've never really used Velocity templates before.
Sure I checked them out, but I have written my own template engine, Jostraca, so I've never seen the need to use Velocity.

Well, Velocity templates are really pretty easy to pick up. One thing that I did find was that they are rather messy. Now, I know, JSPs and PHP are even messier. In fact, it's all rather ugly. That's one of the reasons I added a general replacement function to Jostraca, so that the template code would look natural, and not much like a template at all - you can code things like: FirstName LastName instead of <%=firstName%> <%=lastName%>. It's not so important for HTML, but it makes source code templates a lot easier to read. But hey, Velocity's not so bad! (Maybe I'll add Jostraca support to Roller, [evil laugh]).

I decided to create my own theme, instead of customising via the web interface. For a start, I get to edit the files in a normal editor, and secondly, it seems like the best way to have a more permanent record of the design. Anyway, it seems to work for the moment – you just hit F5 to reload on the theme preview page and you can check your changes right away. For content however (such as the text of the about page) I am sticking with the web interface, and thus storing that in the database.

I've started with Roller 1.2, which does not have Atom 1.0 support. So I went over to the Roller source and grabbed the latest version of the atom.vm flavor and used that after a bit of tweaking. I'm hoping it will all be OK once I upgrade to 2.0

Going with Roller

After much soul-searching and extensive research, I've decided to use Roller for my weblog.

Actually, no, it was more of an instant, "Oh, that's done in Java, I'll take it", sort of a decision, but hey!

And here I am. So I love messing about with things and breaking them beyond repair (hands up if you've ever tried to fix a digital camera with one of those tiny screwdriver sets), so I'm going to be doing a fair bit of "das Customizing" as our good friends in SAP love to call it.

Hang on, and we'll see what we can make of this roller yoke...