People who know me are familiar with my dislike for Flash, so for me to be doing some work in it might come as a surprise.

Why am I doing it? Just for the Hells of it, really. I’ve been playing around with SWFTools for a while, and I decided to try doing something useful with it – and here it is:

Okay, not exactly Earth-shattering stuff, but not bad for a beginner, I thought. I’m the first to admit I’m no designer, but I was pleased with what I had – a simple call-to-action, that was also useful. I had a lot of “fun” getting the ActionScript behind it working (especially the deceptively simple task of getting the form to submit when you hit the RETURN key).

I don’t think I’ll be giving up my main work in Perl and forging a new career in Flash, but I’m happy that I can probably make some of the creatives for my own projects (at least until I can afford to pay a designer to create some new ones for me!)

I guess I should pay her more attention really…

Just listening to some music, when I thought it started to sound a bit slow and warbly. “Batteries must be running out,” I thought.

Two problems:

1. I’m listening to MP3s
2. On my laptop

Not, as my age-addled mind briefly decided, on a portable tape player.

I may have been slightly bored…

(i think grifferz is the best <taras> for VPS)

Edit: using an embedded font (makes the text smoother) and it’s now clickable!

Excitement outside the house tonight…

I use console applications – a lot. When it comes to running multiple programs on a computer, GNU screen is essential, but I find myself connecting to multiple servers and running GNU screen in each. It’s possible to run GNU screen under GNU screen, but it can get messy getting the keyboard shortcuts right. I needed a tabbed terminal program. Read the rest of this entry »

I could never get my head around the FreeBSD -CURRENT, -RELEASE and -STABLE versions, not helped by them being poorly explained by someone I used to work with.

Then I found this page of the OpenBSD FAQ:

http://www.openbsd.org/faq/faq5.html#Flavors

And it suddenly all made sense. 🙂

Having recently been battling to keep some servers out of the CBL, I decided it was time to get strict on what the email servers were accepting, so I created an Exim ACL to reject non-RFC2821 compliant HELO/EHLO strings. Read the rest of this entry »

I wiped 189 junk accounts from one of my sites, and my Google AdSense earnings have dropped through the floor.

Ethically good, financially bad. 🙁

Although adoption of Open Source software is growing, three things are generally considered to be holding it back:

1. No commercial support
2. Clunky user interfaces
3. Poor documentation

The first one is usually available from third-parties, the second one is usually because developers are largely developing for their own benefit (and so know the way around their own UI) but the third one is a killer.

Take, for example, the Planet Planet project. The entire project description is two short sentences, which does cover the basic “What does it do?” question, but doesn’t go any further. Reading the rest of the page, you find out it’s written in Python, but that’s where the documentation ends. To find out anything more about the project (configuration file format, capabilities, etc.) you need to download the entire source code and pick through it yourself. Hardly user-friendly, given that the first thing a lot of people do when faced with a problem is hit the search engines.

It gets better with the Planet Venus fork of the project. They have the documentation available online, so you can see what you’re getting before you download it. One major omission (IMHO) is what the fork is/was all about – it’s advertised as a ‘radical refactoring’ of the original Planet code, but doesn’t actually say what’s changed and why it should be used instead of the original codebase.

So, when faced with the choice between the two projects (as I am) there’s nothing really to help me make the decision. I’ll probably go with the original codebase, given that forks have a habit of either dying or getting merged back in, and that there seems to be some big names using it (in Debian we trust), but I don’t like the fact that I can’t make an informed decision. Downloading both and trying them really isn’t an option with the deadlines I have.

So, if you’re going to create an Open Source project, please take some time to write project documentation. Put a full description of what the software is and what it does on the project homepage. Clearly list any software/hardware requirements. Make the documentation available online, including configuration examples. The more someone knows about the project before they install, the more likely they are to install (or, at least, to keep the install).