Tech-Foo

KiwiPyCon Sloecode Talk

2011-10-13T09:21:00.000+13:00

It's about time I posted my Kiwi PyCon talk from last August! I spent an enjoyable 30 minutes talking about what Sloecode is, how we built it, and the problems encountered along the way. As per my usual approach to public speaking, I tried to keep things light-hearted and entertaining. Anyway, the slides and audio are available here:

Introducing Sloecode: a python-powered, installable code-forge.

View another webinar from ThomiRichards

Dear Journalists: Bits and Bytes

2011-09-27T10:01:00.000+13:00

Dear Journalist type person,

There's something we must discuss. You see, you've been making a very basic mistake in many of your articles when it comes to writing about the Internet, and specifically Internet speeds. Let's take a look at a small quote:

...unless you have an internet connection of impossible speeds. (Mine is nominally 10MB, by the way, which in practice means maximum download speeds of 1.4 megabytes per second).

(source: Rock-Paper-Shotgun).

Can you spot the problem here? Internet speeds are measured in megabits per second. The symbol for 'bits' is a lower-case 'b', so an Internet connection that's 10 Megabits per second could be written as "10 Mbps". I guess if you're feeling lazy you could leave off the "ps", and end up with "10 Mb" (although it's a really sloppy thing to do), but NEVER "10 MB" - that means something else entirely.

Modern PCs use bytes that contain 8 bits. The correct symbol for a byte is an upper-case 'B'. so "10 MB" means "ten mega-bytes", not mega-bits, which is probably what you meant when you were describing the speed of your Internet connection.

Back to our Internet connection that runs at 10Mbps. It's unfortunate that speeds are measured in bits, because a much more useful measure is bytes per second, since that's how we deal with data sizes. We know that a CD ISO image is likely to be around 700 MB, an MP3 file around 3 MB, and an image from a digital camera to be around 1 MB. To convert our 10Mbps connection speed to megabytes per second, we divide by 8, and get 1.25MBps. However, this is the theoretical maximum speed, and there's a lot of overhead in any network connection, so in practise it's unlikely you will experience anything close to this maximum speed.

If your eyes glazed over, or perheps you felt light-headed reading that, here are a few take-home points to make it easier for you:

Connection speeds are measured in megabits-per-second. The correct unit symbol for this is "Mbps".
Files are measured in Megabytes.
A Byte has 8 bits. So to turn your connection speed into something useful, divide the number by 8 and make the unit symbol "MBps".

I would be honoured if you'd consider this small point next time you go to write online. Some of us are acutely sensitive to these matters, and you really don't want to upset the geeks of this world.

Kind Regards,

KiwiPyCon 2012 will be in Dunedin

2011-08-29T15:54:00.001+12:00

It is a great honour and privilege to be involved in bringing the New Zealand Python developers conference (KiwiPyCon) to Dunedin in 2012. I intend to blog regularly with details of next year's conference as they emerge, so watch this space for more information over time!

Finally, a huge "Thank You" to Tim McNamara for organising the best KiwiPyCon to date. I have a huge task ahead of me, and he's raised the bar very high indeed.

Have any good ideas for next year? Please let us know!

Sloecode 1.1 - get your bugreports in now!

2011-08-28T11:10:00.000+12:00

I'm at KiwiPyCon in Wellington, New Zealand. It turns out, being surrounded by geeks is great inspiration & motivation. Because of this, I've created a Sloecode 1.1 milestone in launchpad. If you have any bugreports or feature reuests, now's the time to get them in!

...I can't believe I'm asking people for bug-reports. This feels wrong...

Sloecode: now with 100% more website

2011-08-03T18:52:00.000+12:00

Sloecode now has a real website! It's a rather minimalist affair at present, but it's better than nothing!

Since I last blogged, the setup instructions for the Sloecode server have changed a lot. The new instructions are available on the new site.

Representin' the home-boys!

2011-07-07T19:59:00.000+12:00

That's *exactly* the kind of blog title that's liable to get me in trouble down the road. Faux street swagger doesn't age well.

In other news, I'm presenting a talk at this years NZ Python conference KiwiPyCon. Their website does not have the schedule visible yet, but there is a list of talks available.

I'm looking forward to meeting other python developers, and maybe getting some help with Sloecode!

Unity Workarounds

2011-05-29T11:34:00.000+12:00

I'm currently running the unity desktop shell on my development computer. I got fed up with KDE's lack of support, and the gnome-shell just annoyed me. Unity seems like a good start, but suffers from several problems. I've found workarounds for all of these, and thought I'd post them below.

Scrollbar Corruption:

One of the major changes in unity is the thin scrollbars (technically called "overlay scrollbars", I believe), which are enabled by default for all GTK applications. This is what I'm talking about (image from techgarage.com):

These work fine for native GTK applications, but applications built using the wxPython toolkit suffer from render corruption when you try and scroll a styled text control (bug report). This bug manifests itself in many applications, including my current favorite development text editor editra. Here's a screenshot of the issue:

Solution:

The problem can be avoided by turning the thin scrollbars off. How do you do that? Easy - launch the application with the "LIBOVERLAY_SCROLLBAR" environment variable set to 0, like this:

You can of course edit the menu item for editra to include this, or add the line "export LIBOVERLAY_SCROLLBAR=0" to your ~/.xprofile file (create it if it doesn't exist).

Panel Corruption:

Whenever I change a setting in the compiz config settings manager (ccsm), the top panel of my unity desktop becomes corrupted. Previously the only way to fix this was to log out and log back in again (effectively restarting unity). Here's a screenshot of the problem:

Solution:

When this happens you can restart unity without having to logout, or close any applications. Simply run (either by pressing Alt+F2, or in a terminal):

unity --replace

CAPTCHA Fail

2011-05-10T19:18:00.000+12:00

I can understand the need to filter humans from machines on the Internet, but we need to do a much better job. It seems like the most common captcha software I run into these days is reCAPTCHA. The system has some noble goals - specifically, users who submit captchas are actually helping digitize books. However, here's the problem:

What the hell does that say? The first word is obviously "the", the second? "Claccupr?". Perhaps I have bad eyesight, but I often get these wrong. Here's an alternative proposal:

Instead of asking humans to perform text recognition (something computers can already do reasonably well), ask them to do something that comes naturally to humans, but not to computers. How about asking the user to pick which image they might find at a beach. Or ask the user to pick the image that represents the largest object in real life. Use context that humans understand instinctively, but computers do not.

Any ideas? Someone should build it!

Sloecode: Now with Ubuntu Packages!

2011-04-29T16:24:00.003+12:00

We're still working towards a sloecode 1.0 release. We're now dangerously close - we have some UI tweaks to complete, and a few other bits and pieces. However, we now have Ubuntu packages for both the client and server components, ready for you to test!

What is Sloecode?

Sloecode is an open source project, hosted on launchpad.net that aims to provide a comprehensive, installable code forge. A "code forge" is a set of tools that help groups of people write software (think sourceforge, launchpad etc). It typically includes a revision control system, and optionally project wikis, bug tracking, issue tracking, feature planning and any other features people might need. However, it's important to note that we're not trying to replicate Launchpad! Launchpad is a great service, and we don't want to compete with it. Instead, we're providing a tool for people who:

Don't want their code to be public - either because it's commercial software or because it's not ready yet. You can use sloecode in your business, college, university without having to release your software to the wider world. You can do this on launchpad, but you must pay for the privilege. The project was borne out of the need to have a code forge for an educational environment: putting students' work online is not an option.
Want their code forge system to be hosted locally. For large code bases, the communication times between a local machine and the central launchpad.net servers can become expensive - especially in locations where the Internet connection is poor. Running sloecode is easy (as we'll see soon) and gives you complete control over the system. You're are responsible for server maintenance, backup, and general administration.

Compared to Launchpad, we're aiming for a completely different user base.

How does it Work?

Sloecode is made up of two distinct parts:

The Bazaar/SSh smart server is a python-twisted application that understands the SSH protocol, and runs bzr-serve on demand for users. Every time you interact with the server using a Bazaar client application you're actually talking to the smart server. We need this component for several reasons: first, we don't want users to require a system account on the Linux server (which is the usual way of setting up a Bazaar server), but we do still want to use SSH public/private key authentication. This means the SSH server needs to know about our database and be able to retrieve keys from it on demand.

The Sloecode Web App is the front-end for the whole system. It's written in pylons, and makes use of a whole host of other libraries including jinja2 (page templates), formencode (input validation), YUI3 (javascript components), repoze.what and repoze.who (authorisation and authentication), and a whole lot more. The web-app provides control for managers and administrators to create projects and users and assign users to projects (with different levels of access). Regular users can see basic information about their bazaar branches (both personal repositories and project repositories), and manage their SSH keys.

The plan for the future is to add optional components - the key word being optional. One of our design goals is to make sloecode easy to install; this includes minimising install-time dependancies.

The key thing to understand about Sloecode is that we're not writing the VCS ourselves - we're simply making Bazaar easier to install and manage.

Enough already, give me the server!

Sloecode has not yet been released, but you are welcome to participate in testing. To set up the server, you'll first need the sloecode PPA in your sources.list. To achieve this, run the following command:

sudo add-apt-repository ppa:sloecode

Then update your package lists:

sudo apt-get update

You can now install the sloecode server package:

sudo apt-get install sloecode

The server package should install all the package dependancies. However, before you can run the server, you need to set up the database back-end. The default back-end us sqlite, which is fine for testing or for very low-use installations. Sloecode uses sqlalchemy, which allows us to use any number of databse backends. This, and many other configuration details can be edited by tweaking this file:

/etc/default/sloecode-production.ini

Once you're happy with the settings, you need to create the database tables. Do this by running:

sudo paster setup-app /etc/default/sloecode-production.ini

This command will read the values present in the configuration file, and create the default database tables for you. You only need to run this command once (to create the tables in your database)!

If you have edited any of the other values, you will want to restart the server:

sudo service sloecode restart

By default, log files are in /var/log/sloecode, Bazaar repositories are created in

/srv/sloecode/bzr-repos

and the default database is a simple SQLite file (which won't handle any kind of heavy workload or concurrency, so you may wish to change that). The RSA public/private key pair the smart server uses to communicate with clients are stored in

/var/sloecode/keys

And the clients?

Client setup is much simpler. Simply follow these steps:

Make sure you have an account created for you in the sloecode web interface. Log in to the web interface with your username and password.
Click on the "Manage SSH Keys" link on your home page. You need to paste your SSH public key in the form provided. This allows your Bazaar client to authenticate with the sloecode server. If you don't have an SSH key, you can generate one by running:
```
ssh-keygen
```
and view the public key by running:
```
cat ~/.ssh/id_rsa.pub
```
All client machines need the 'bzr' and 'bzr-sloecode' packages installed. Assuming you have the sloecode PPA installed (see instructions for doing this in the server section, above), you can run:
```
sudo apt-get install bzr bzr-sloecode
```
Finally, you need to tell the Bazaar sloecode plugin where the sloecode server is. The client plugin looks for an environment variable called "SLOECODE_SERVER", and will complain if it is not found. The easiest way to set this environment variable is to edit your "~/.bashrc" file and add this line to the end:
```
export SLOECODE_SERVER=domain.of.your.server.com
```
The value of this variable should be either a domain name, OR an IP address that points to the sloecode server you wish to use. For example, if the server is installed on the local network you might have the following:
```
export SLOECODE_SERVER=192.168.1.10
```
Note that you must not add any network protocol specification - the sloecode client plugin takes care of that for you. If you are running the sloecode ssh service on a port other than 22, you must add this port to the end of the string, like so:
```
export SLOECODE_SERVER=192.168.1.10:4022
```
Finally, if your username on the sloecode server is different from your local computer username, you need to tell the Bazaar sloecode plugin what username it should use. To do this, run the command:
```
bzr sc-login sloecode_username
```
Where "sloecode_username" is the username you use to log in to the sloecode web interface. For example, on my machine the command is:
```
bzr sc-login thomir
```
If you run the command without a username it will tell you what username is currently set.

That's it! Everything is all set up. Now you can start using the sloecode server.

Bazaar / Sloecode Basics

I won't cover the details of how to use Bazaar. If you need that instruction, look at the official Bazaar documentation. However, here are a few pointers:

Every user on the sloecode server has a personal repository. To push code to your personal repository, do this:
```
bzr push sc:~sloecode_username/branch_name
```
By default personal repositories are created with no branches, so whenever you push or pull from a personal repository you must always specify a branch name!
Personal repositories are private - you are the only one who can read or write to your personal repository. If you need to share your code with someone else, you need to store it in a project repository.
To pull code from a project repository, the command looks like this:
```
bzr pull sc:project_name/branch_name
```
Note that there is no tilde character before the project name. Also note that you need not specify the branch name if you want the special branch called "trunk". For example, if I want a copy of the trunk branch of project "elastic", I'd run the following command:
```
bzr pull sc:elastic
```
However if I want a specific branch called "fix-bug-1234", I'd run the following:
```
bzr pull sc:elastic/fix-bug-1234
```

Final Thoughts:

We're still writing sloecode - it's an ongoing effort and won't be finished any time soon. We welcome your feedback - the best way to contact is us via the sloecode-developers mailing list, or in the #sloecode channel on freenode IRC, or leave a comment below. Have we missed anything? Spot any bugs? Have suggestions for improvements/future direction? We'd love to hear from you!

Sloecode updates: UI tweaks

2011-04-05T12:42:00.000+12:00

Several members of the sloecode team have been hard at work tweaking the sloecode web-app UI - we think we have a much more usable product as a result. We've still got a long way to go, but the UI is looking better every day. Here's a picture of the portal page a user sees when they log in:

Changes from the previous version include:

Addition of the project menu - this allows users to quickly jump to any project they are a member of.
Branch logs are now shown on separate pages, instead of cluttering up the main user/project page.
"Account Settings" and "Logout" Links are now pushed to the right of the page menu bar, which is where most users expect them to be.
More help topics have been written.
Lots of small textual changes to page content - too many to list individually.

We still have not got the server package into our PPA. In the mean time, installing and running a sloecode server involves a few manual steps, but is by no means complicated. If you're interested in the project, feel free to drop in the #sloecode channel on irc.freenode.net, or introduce yourself on the sloecode developers mailing list!

bzr-sloecode Installer for Windows

2011-03-15T19:45:00.000+13:00

There's now a basic installer for the bzr-sloecode Bazaar plugin for Windows. It currently does the following:

Installs the plugin to the right place.
Sets the SLOECODE_SERVER environment variable to whatever you want.

There are a number of aspects that require improvment however:

It doesn't check that Bazaar is installed first.
It doesn't ask if the user wants to install the plugin for everyone or just the current user. Currently the SLOECODE_SERVER setting is system-wide, which requires admin permissions to set.
No validation on the Bazaar server address.

...So it's a work in progress! Patches are more than welcome. You can grab the installer from the bzr-sloecode launchpad page.

Another Microsoft UI Fail

2011-02-25T11:54:00.000+13:00

...this time in Microsoft Outlook. Could the programmer who was too lazy to write their code properly please go back to school? There is no excuse for this:

You want me to take this string, split it on comma characters, and re-join it with semi-colons instead? Sure, I'll do that you you, with my meat-fingers, because I'm really good at that, and computers are known to be terrible and SIMPLE TEXT MANIPULATION.

Introducing: Sloecode

2011-02-24T16:34:00.000+13:00

Bazaar is wonderful. It combines the right powerful features with a good dose of common-sense and a sprinkling of usability. Well okay, perhaps more than a sprinkling of usability. I use bazaar a lot in combination with launchpad. The client-side bzr-launchpad plug-in makes this a breeze: I don't have to remember user-names, passwords, project URLs, or anything else. However, occasionally I don't want my code to be visible by default. Sometimes I don't want my code leaving the building. I could easily host a simple bazaar repository locally, but creating teams of users quickly gets difficult. What I'd love is a system like launchpad, but with a few key differences:

Optimised for the most common use-case. Launchpad does an awful lot of stuff that I have never used, and probably never will. All this functionality makes launchpad a very large beast indeed. I want a system that's compact and easy to use; I don't need translations, build recipes, mailing lists, bug tracking, etc. etc.
Easily installed on my own server. It is technically possible to install launchpad wherever you want, but it's difficult.

Enter my current open source project: sloecode.Sloecode is a simple wrapper around bazaar and a few other key technologies that makes it easy to set up multiple users & teams of developers. We're trying to optimise sloecode for the most common problems. What do we have so far?

A simple web app (written in python & pylons) that allows one to create users, teams, and manage both.
A bzr+ssh smart server that understands the accounts and teams created in the web-app.
A client-side bzr plugin that allows users to use shortened repo URLs (similar to the lp:projectname scheme the launchpad plug-in provides).

Sloecode is still very much "work in progress" (we've got big plans), but it is usable right now. If you want more information, feel free to leave a comment below, or join the sloecode-dev mailing list on launchpad.

Visual Studio Fail

2011-01-24T09:26:00.000+13:00

Perhaps this is a symptom of the underlying operating system, rather than the Visual Studio IDE. In either case it sucks:

I like to keep my files organised in folder hierarchies. Now I'm being forced to use a flat, wide folder tree by my IDE.

Not. Happy. At. All.

Virtualbox web front-end

2011-01-17T14:08:00.000+13:00

I mentioned before that virtualbox rocks. Now it rocks even harder. I've always wanted to run multiple virtual machines on a powerful, headless server. Previously there hasn't been an adequate user interface (read: not a command line) that lets me manage multiple virtualbox instances.

Now there is.

...and my doesn't it look pretty?

Ubuntu One Madness

2011-01-12T11:25:00.003+13:00

For those of you who have been living under a rock the last few months, Ubuntu One is:

...your personal cloud. But it's not just about syncing files — whether you need to access your contacts, notes or bookmarks from any computer or the web, enjoy your favorite music from a cloud integrated store or stream your entire collection to iPhone and Android mobile phones — we've raised the bar on personal clouds.

Clearly the marketing department at Canonical have been hard at work!

Unfortunately, the ubuntu one client has no support for any desktop environment other than Gnome. For a service that offers file synchronisation, having to launch a non-native client application makes the whole system rather useless. At first, this seems fair enough - a company with limited budget must allocate resources where they will do the most work. However, after a bit more digging, things seem to be in a rather poor state of affairs.

It's worth noting that the Kubuntu project is an official derivative of Ubuntu. It's listed as such on the Ubuntu derivatives page, you can purchase official canonical support for Kubuntu, purchase printed CDs through shipit, and the two projects use exactly the same software package repositories.

For a while there was light at the end of the tunnel: Harald Sitter started work on a KDE ubuntu one client. At one stage there were packages for it in a PPA, and people started using it. It even got a few independant web articles written about it. Then everything died. The PPA was removed, and development halted. Why? Harald commented on a bug report, and had this to say:

Well, Google Summer of Code is over.

And after having spent more than a week shaking a new graphical frontend for the now third version of authentication handling out my sleeve, I have learned but one thing. While you work on building something, something else will surely break in a way that will requrie half a work day to track down.
It is somewhat impossible to develop a KDE frontend while sitting outside of canonical and being in a completely different time zone than the Ubuntu One team.
On top of that I have seen crappy code design, crappy packaging, inexistance of cross-desktop awareness and cross-operatingsystem awareness and unavailability of a stable working target to develop against...

So I would put it as "I am giving up".

In the future I will devote time towards making ownCloud (a truely free "Cloud" implementation) more accessibile to the masses.

So what can we do? owncloud is not yet at a point where it can be used, and I cannot see any further development on an Ubuntu One client for KDE. Probably the most useful thing non-developers can do is to ask for clarification on the main bug report (politely please!), and make sure you click the "This bug affects me" link at the top of that page.

The real tragedy in all this isn't that there is no officially supported U1 client for KDE, or even that Canonical decided to support Windows and Mobile OSes before it's second-most popular operating system, it's that the upstream sources are (apparently) being built with no consideration to portability to other desktop environments. For a product with so many derivatives, you'd think this would be a required part of the development & planning process.

Console Hacking

2011-01-07T10:18:00.003+13:00

Several news outlets are reporting that the PS3 has been compromised. What strikes me as odd is that most of the time, the people doing the hacking have no interest in piracy (at least, that's their claim). Instead, their motives seem to be towards allowing home-brew app creation. This is a noble goal, and one that will surely become more and more popular, as we start moving away from passive entertainment towards a more participatory model.

My question is this: Why do console manufacturers still struggle to prevent home-brew projects? The time spent trying to prevent these sorts of exploits must be incredible, and so far, none of them have succeeded.

Personally, I'd love a console that allowed me to run whatever code I want on it - imagine the uses! MythTV running on an XBox? Awesome!

Why your python editor sucks

2010-12-30T15:17:00.006+13:00

I'm doing a reasonable amount of python-coding work these days. It would help me to have an editor that doesn't suck. My requirements are:

Small & Fast. I'm not after a massive clunky IDE, just an editor with enough smarts to make editing multiple python files easier.
Sensible syntax highlighting.
Understands python indentation, PEP8 style. Specifically, indents with 4 spaces, backspace key can be used to unindent.
Can be integrated with one or more lint checkers. Right now I use a wonderful combination of pep8, pyflakes and pylint. I want the output of these to be integrated with the editor so I can jump to the file & line where the problem exists.

That's it. I don't think I'm asking too much. Here's the editors I've tried, and why they suck:

KATE. I love kate, it's my default text editor for almost everything. However, there is no way to integrate lint checkers. I could write a plugin, but that's yet another distraction from actually doing my work.
Vim. I'm already reasonably skilled with vim, and Alain Lafon's blog post contains some great tips to make vim even better. My problem with vim is simply that it's too cryptic. Sure, I could spend a few years polishing my vim skills, but I want it to just work. Vim goes in the "kind of cool, but too cryptic" basket.
Eric. When you launch eric for the first time it opens the configuration dialog box. It looks like this:
How many options do I really need for an editor? Over-stuffed options dialogs is the first sign of trouble. It gets worse however, once you dismiss the settings window, the editor looks like this:

Need I say more?
Geany. Looks promising, but no integration into lint checkers.
pida. Integrates with vim or emacs for the editor component. Looks promising, although the user interface is slightly clunky in places. Pida suffers from exactly the same problems as vim does however, but I may end up using it.

There are a few options I have not tried, and probably won't:

Eclipse & pydev. Eclipse is a huge, hulking beast. I want a small, fast, lean editor, not an IDE.
Emacs. Can't be bothered learning another editor. Doesn't look that much different to vim, so what's the point in learning both?
KDevelop. Same reason as Eclipse, above.

I suspect there's a market for a simple python editor that just works. Please! Someone build it!

Visual Studio Exception Woes

2010-12-03T10:00:00.004+13:00

Microsoft, in their infinite wisdom have decided to make programming easier. How? By setting the default behavior for Visual Studio 2010 Ultimate to be to ignore (i.e.- not break on) exceptions thrown from non user-code. Behold the default settings for exceptions in a brand new C# project:

Try as I might, I have not yet discovered a way to change the default for these settings for all projects. How am I supposed to teach students about exception handling when Microsoft are doing their best to get rid of them?

Bah.

Attention all Programmers:

2010-12-01T10:21:00.003+13:00

As a user of open source software, I like to try and give something back to the community whenever I can. As a somewhat proficient programmer i can do this more often than most, but one of the most effective ways of giving back for non-programmers is by filing bug reports.

Unfortunately, there are two main issues with this:

Submitting a bug report is often incredibly painful. Most software bug trackers I have seen require an account, which means registering a new username & password (I can't wait for more non-essential services like bug trackers to start using openId), activating my account... all this can take 30 minutes of more. Submitting a bug report should be a fire-and-forget affair, taking 10 minutes tops: any longer and I can't afford to spend my time.

Many bug trackers ask users for information that is hard to obtain, or intimidating to non-programmers. How many users know their CPU architecture? Or distribution? Or even the software version they're using? One way around this is to have the bug-reporting done from within the application on the client machine itself, but still - bug trackers should be as friendly to users as possible. How about posting some simple instructions on how to obtain this information for non-technical users?
Even after navigating the multiple hurdles involved in submitting a bug, you then have to deal with the programmers fielding the bug report. This is where it gets tricky. Many programmers view bug reports as a personal insult to them (perhaps subconsciously). Many programmers will triage bugs that they don't want to fix, giving excuses like "It's like that by design", or simply "Low priority, won't fix".

Here's the thing though: The customer is (nearly) always right.

If a user has taken the time to navigate your awful bug tracking software and submit a bug, it must be a big deal to them. If the matter at hand really is like that "by design", your design is probably screwy. If you won't fix it because it's low priority then you need to stop adding new features, and fix the ones you already have.

Open source software seems to suffer from these problems more than commercial software. I guess it's because we're not trying to extract money from our clients. Can you imagine a professional code shop telling a paying customer "I'm sorry, we're not going to fix that bug you reported, because we intended it to work like that"? Yeah, right.

So how do we fix this for the open source world?

There's no simple answer that I can fathom. It requires programmers to be a bit smarter and have a bit more empathy for the mere mortals who have to use their software. As a programmer, I include myself in this category.

That is all, thank you.

Code Craftsmanship

2010-11-09T09:50:00.002+13:00

Dunedin now has a local code craftsmanship group!

Code craftsmanship is like craftsmanship in any other area. It describes the transition between knowing how to write code, and knowing how to write good code. Like most crafts, there's an element of constant iterative learning involved. Working with people who have more experience than you can save you some of those iterations.

This is an excellent opportunity to meet other programmers, and discover the rich, yet hidden IT talents in Dunedin. If you're interested in joining us, check out the (brand new, as yet unfinished) website.

Project Documentation

2010-11-09T09:40:00.003+13:00

Why is it that most open source project pages are so terrible at documenting their own project?

I'm not talking about API or technical documentation - I'm talking about telling new visitors to your site what the hell your code is about.

Project authors, here are some handy tips:

On your project front page, right at the top, put a simple explanation of what your code does (or what you hope it will do someday). Remember that your audience may not have the same level of technical experience as you do. Examples (screenshots, code snippets) are a MUST. A picture speaks a thousand words and all that...
Make sure you include the development status of your project. I can't count the number of times I've spent 30 minutes looking at a project only to realize that it's not nearly complete enough to be usable to me. There's no shame in saying "this library is working, but not production ready. It is missing features X, Y, Z"
Inject some enthusiasm! How many boring, dull, dry project descriptions do I have to read through? Most sound like the authors aren't passionate about their product. Sell your project; inject some enthusiasm, and maybe your viewers will become more enthusiastic in the process!

Well, that's my rant for the day. Now I must go update my project documentation...

Life Update

2010-10-18T09:35:00.003+13:00

Yes, It's been a while.

In the last few months I've been through the painful experience of trying to keep a company running despite the best efforts of the directors. Realising that the odds were stacked against me I decided to throw in the towel and relocate back to New Zealand.

So farewell England! I arrived as a graduate programmer, with a bit of open source hacking under my belt, and left with several years programming experience, a whole ton of knowledge that could not be leaned through any means but hard work, not to mention a few (emotional) scars. It's been a great experience, and one I encourage any graduate to do.

So now I'm back in Dunedin, what am I doing? Well, I've taken a 12 month contract to teach at Otago polytechnic; I'll be teaching third year programming and database papers. I've also completed a short stint programming for ARL and fixing the Survival Factor exhibits at Otago Museum. I'm hoping to set myself up as a contractor, so I can take on any odd jobs that I see.

My hope is that I will be able to return to more open source hacking now that I'm in a more flexible working environment. I'm not sure what project I'll end up helping - perhaps KDE, perhaps something new.

Will write more soon.

Design and Implementation

2010-03-10T23:35:00.011+13:00

One of the key tenets in good software deisgn is to separate the design of your product from it's implementation.

In some industries, this is much harder to do. When designing a physical product, the structural strength & capabilities of the material being used must be taken into account. There's a reason most bridges have large columns of concrete and steel going down into the water below. From a design perspective, it'd be much better to not have these pillars, thereby disturbing the natural environment less and allowing shipping to pass more easily.

Photo by NJScott. An example of design being (partially) dictated by implementation.

Once you start looking for places where the implementation has "bubbled up" to the design, you start seeing them all over the place. For example, my analogue wristwatch has a date ticker. Most date tickers have 31 days, which means manual adjustment is required after a month with fewer than 31 days. I'm prepared to live with this. However, the date ticker on my watch is made up of two independent wheels - and it climbs to 39 before rolling over, which means manual intervention is required every month! What comes after day 39? day 00 of course!

It's easy to understand why this would be the case - it's much simpler to create a simple counting mechanism that uses two rollers and wraps around at 39 than it is to create one that wraps at the appropriate dates. I have yet to see an analogue wristwatch that accounts for leap-years.

Software engineers have a much easier time; our materials are virtual - ideas, concepts and pixels are much easier to manipulate than concrete and steel. However, there are still limitations imposed on us - for example data can only be retrieved at a certain speed. Hardware often limits the possibilities open to us as programmers. However, these limitations can often be avoided or disguised. Naive implementations often lead to poor performance. A classic example of this is Microsoft's Notepad application. Notepad will load the entire contents of the file into memory at once, which can take a very long time if the file you are opening is large. What's worse is that it will prevent the user from using the application (notepad hangs, rendering it unusable) while this loading is happening. For example, opening a 30MB text file takes roughly 10 seconds on this machine. This seems particularly silly when you consider that you can only ever see a single page of the data at a time - why load the whole file when such a small percentage of it is required at any one time? I guess the programmers who wrote notepad did not intend for this use case, but the point remains valid: an overly-simple implementation led to poor performance.

The unfortunate state of affairs is that the general population have been conditioned to accept bad software as the norm. There really is no excuse for software that is slow, crashes, or is unnecessarily hard to use. It's not until you use a truly incredible piece of software that you realise what can be achieved. So what needs to change? Two things:

Developers need to be given the tools we need to make incredible software. These tools are getting better all the time. My personal preference for the Qt frameworks just paid off with the beta release of Qt 4.7 and QT Creator 2.0. I plan on writing about the new "Quick" framework in the future: I anticipate it making a substantial difference to the way UI designers and developers collaborate on UI design and construction.
Users need to be more discerning and vocal. As an application developers it can be very hard to know what your users think. If you don't get any feedback, are your users happy, or just silent? We need a better way for users to send feedback to developers; it needs to be low-effort fast and efficient.

My Morning thus far

2010-01-13T22:03:00.003+13:00

My morning thus far:

Woke up. Noticed it had been snowing. Roughly 4-5 centimetres on the ground, and still coming down, although it's more ice crystals than snow.

Since today is the first day that my company is exhibiting at the BETT trade show in London, got dressed in snazzy new company shirt, and trudged my way (30 minutes) to train station.

Bought £21 ticket. Went into station, just in time to hear announcment that all trains were terminating at woking, and there would be no services to London. Damn!

Walked home through park. Snow quite pretty, but cold and wet as well:

Finally got back home. Roads didn't look too bad, so I thought I could at least drive into office. Cleared car of snow and ice, drive 2 metres forward and got stuck, half in, and half out of driveway!

So here's the thing: If the gulf stream breaks down, or becomes more erratic, this will happen more and more. We need infrastructure to cope with the bad weather. How do other countries deal with this?

Torchlight

2010-01-12T22:35:00.002+13:00

Just purchased Torchlight from steam. It's brilliant - casual, but not brain dead, exciting, but not over done, simple, but not stupid. It'll even run on a netbook.

Go - get it now!

Live Forever!

2009-12-24T02:19:00.002+13:00

Ray Kurzweil suggests that most, if not all technical development & evolution happens on an exponential scale, rather than a linear one. What does this mean? It means that, amongst other things, by the year 2020, we will have access to technologies far beyond anything we've thought about to date.

Makes sense to me!

Sexism in IT?

2009-10-24T01:11:00.005+13:00

Mark Shuttleworth recently copped some flack for allegedly sexist content in a talk. I wasn't there, and haven't seen the talk, so I can't really comment on the material itself, but a few things struck me about some of the online responses:

Many of the people complaining weren't there - they watched the video footage online. Why would you do this? If you suspect that there's going to be content that offends you, don't watch it. If you do decide to watch it, I'm not sure you can complain too loudly when (surprise surprise) you are offended by it.
Yes, IT is a male dominated field - for whatever reason (there's lots of research discussing why this is, but that's for you to find). That's not to say that sexism should be inherent, or even tolerated, but it is to be expected. Anyone shocked by this statement should try working in other male-dominated fields, such as construction or engineering. No, it's not right, but it's how it is.

I met Mark briefly at a Linux conference a number of years ago and he seemed to me to be a straight-talking, reasonably honest, good natured kind of guy. I'm sure he made an honest mistake, and regrets his choice of words. I would urge Mark to apologise, and urge everyone who complained to spend the same amount of energy protesting equally important matters such as software patents, or advocacy for open, sane standards.

Spolsky loses his cool

2009-10-03T02:57:00.003+13:00

Today I stumbled across Joel Spolsky's article "The Duct Tape Programmer". Essentially it's a thousand word rant to make this simple point:

A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.

Of course he's right - however, his post is ten agonising paragraphs wherein he rants about design patterns, extended C++ features such as template classes (wait, they've been around for a while now - can we still call them "extended" features), and multi-threading (!!!), and finally one succinct paragraph in which he makes his point (most of which I have quoted above). Now don't get me wrong - I am by no means criticising his writing style ("people in glass houses..." and all that) - all I'm suggesting is that someone with Joel's reputation may wish to think a little harder before posting this sort of tripe online, lest he tarnish his otherwise good reputation. Let me give an example:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

So Joel Spolsky is seriously suggesting that C++, templates, multiple inheritance and multi-threading are invariably going to "doom your project"? Come on. Multi-threading is critical to the success of many projects - without it, or something similar, a huge portion of applications simply wouldn't exist, or at least would be a lot more complicated. I challenge Joel to write a print spooler as part of an interactive application in a single thread. I challenge Joel to write a tool for scientific analysis that must process lots (gigabytes? exabytes?) of data while maintaining an interactive user interface.

As I mentioned earlier, Joel has a point - however, instead of suggesting that any slightly-complicated technology be banned outright, I'll instead suggest that any slightly complicated technology had better be understood by your programmers before you use it in your project. Don't use multi-threading because it sounds cool, use it because it's the right tool for the job.

A New job

2009-09-12T00:40:00.003+12:00

It's been a while since I had the time to post here. In the last few months I've left my old emplyer (Pebble Beach Systems), and joined AB Software Consulting. Why the change? I've always maintained that the best way to keep your skills honed is to keep moving. ABSC requires a completely different skill set to Pebble beach. It feels like the next logical step in my career progression.

It's very easy to stay in a job that isn't giving you what you need. Don't make this mistake! If something isn't right, and you've tried fixing it, it may well be time to move. It's a very hard thing to do, but in my case it's been worth it.

Cheers,

Compiling != Testing

2009-05-23T03:57:00.001+12:00

Just a small note, folks, to remind you all that just because your code compiles, it's not guaranteed to work. Writing the code is only 10% of the total effort.

I've neglected this blog for a long time now. Hopefully I'll be back soon, but until then, watch this space!

Distractions

2009-03-09T02:10:00.002+13:00

I've been very distracted lately - I haven't written any code outside work hours for several weeks now. What's kept me so busy? mainly it's been my guitar(s). I've just added a new guitar to the growing collection. If you're interested, you can see some pictures here.

Microsoft's unpaid testers

2009-02-27T22:30:00.001+13:00

I just discovered this charming little quote in the winows 7 blog:

To date, with the wide usage of the Windows 7 Beta we have received a hundreds [sic] of Connect (the MSDN/Technet enrolled beta customers) bug reports and have fixes in the pipeline for the highest percentage of those reported bugs than in any previous Windows development cycle.

So you're publically advertising the fact that your product was very buggy when you launched the beta test phase, and you're scrambling to fix all the bugs at the last minute? Whatever happened to internal testing? Who will test all the bugs introduced with your bug fixes?

Bah, my dislike of the Microsoft software mill continues! Hooray for uninformed opinion!

Webkit / Konqueror issue raised again

2009-02-24T01:02:00.001+13:00

Just thought I'd point out that I'm not the only one who would like Konqueror to use webkit rather than KHTML:

WebKit in Konqueror

...It's a pity the comments are 90% flame, and 10% content.

Product Branding Critical to User Expectations

2009-02-11T05:16:00.004+13:00

A recent post on kdevelopers.org caught my attention. In a post tagged "rant" (I love rants), "tstaerk" outlines his situation:

I am in a small team where we provide a Linux Terminal Server (LTS) for a company. It is based on NX. Every employee in this company can use the service, however, we provide it free of charge and out of enthusiasm. That means, we are not paid for setting it up nor for giving phone-support. We sometimes have 70 concurrent users on the server, that may mean we reach 500 users on the whole. The server is running KDE 3.5 as desktop environment. Recently, we evaluated - no, let me keep this understandable - we sat together and discussed the possibility of upgrading to KDE 4.

Everyone including me was against the upgrade. This is especially ashaming for me as I am spending every weekend to develop KDE. So what were the reasons?

KDE4 seems to have suffered a lot from people complaining that it's not an easy upgrade from KDE3, and to a certain extent, the complaint is justified. When KDE4 first arrives on the scene, it was really little more than a tech demo, and certainly not usable by normal users (I use the term "normal" users with all due respect - "normal" in this context means users not in the KDE development scene, and perhaps not as technically literate as the developers). However, the hype surrounding it's release meant that lots of normal users upgraded and were subsequently disappointed. With KDE4.2, we're finally getting to a stage where the KDE 4 series is actually usable as a desktop environment.

However, that's still not answering the original concern: KDE4 is still not a replacement for KDE3. Tstaerk goes on to list some of the shortcomings he sees in KDE4:

If you install a KDE 4 desktop by default, you do not have the possibility to add icons to your desktop by right-clicking onto the desktop. That would mean to us: Take 500 phone calls, explain users why it is no longer possible, explain 500 times why we do a change if it is a change to the worse... You got it, 500 times an ENOTAMUSED.

If you install a KDE 4 desktop by default, you do not have the possibility to move the clock in the panel. For me, the clock is ticking constantly on the left where I do not want it. Our users will be upset seeing another change to the worse. Yes, there is a work-around but it is so complicated that I do not want to tell it 500 times on the phone

If you install a KDE 4 desktop by default, you get a strange icon in the upper right corner. No one could explain to me what it is called, but everybody said it was something about Plasma. Users will click on it and eventually hit "Zoom out". Then, their screen is filled with strange gray squares. Just imagine you have to sit on a phone and answer 500 phone calls (for no money) from users who all tell you something about "squares" not knowing they should call it "activities".

Does he have a point? Perhaps.

In some ways, calling the new product KDE4 implies an easy upgrade path from KDE3, which is misleading, since many aspects of the product have been written from scratch, and behave in a totally different manner. It would have been a better decision, I think to brand KDE4 in such a way that it was obvious that it was a new product, that would not work in the same way. This in turn might have saved a considerable amount of grief when developers found that their snazzy new technologies were being ignored, since users could not use the product like they were used to.

So, the moral of the story?

Be careful how you brand your product, especially when a newer version breaks compatibility with an older version. Is it an upgrade, or a new entity in it's own right?

KDE 4.2: First Impressions

2009-02-01T23:29:00.004+13:00

As you may already know, KDE4.2 was released a few days ago. I was interested in writing a plasmoid in python (more on that in a future post), which meant that I had to upgrade.

So what did I think of KDE4.2 after experiencing KDE4.1?

In a word: Brilliant!

KDE4.2 is a breath of fresh air after 4.1. Many of the crashes I experienced in KDE4.1 have been fixed. For example, in 4.1, every time I opened the "Display" configuration dialog my laptop would freeze, and needed to be hard rebooted in order to get it working again. Every time I launched a full-screen application (like a game) my laptop would freeze. I couldn't kill the X server with Ctrl+Alt+Backspace without my laptop freezing... there's a whole list.

KDE4.2 fixes almost all these bugs, and even throws in some nice performance tweaks at the same time. Things feel more responsive - menus are faster to open, and some applications seem faster to load (although I haven't done any actual timing tests - so this is all subjective). Finally, it looks very nice:

It looks good, and it's responsive on my three year old laptop!

A big congratulations to all the KDE developers that made this happen. I believe I've committed a whopping 10 lines of code to KDE4, so I'm glad that other people have more commitment than I do ;)

Henry lives on

2009-01-30T00:54:00.001+13:00

After complaining about the poor state of the web browser in a KDE platform, I have to report with mixed emotions that I've bitten the bullet and installed firefox. I'm not a huge fan of firefox - yes, it's open source, and seems to work fairly well, but it's also slow and a huge resource hog.

Who here remembers when firefox first came out? It was supposed to be a stripped down version of the mozilla web browser. The idea was that by removing the mail client, IRC chat application, and god knows how many other applications we'd end up with a smaller, faster, lighter browser. To some extent it worked. However, I'm starting to wonder if they'd have been better starting from scratch.

I challenge anyone reading this to use Chrome for windows for a week and then switch back to Firefox for good - I guarantee you you'll be pulling your hair out within a week; firefox is slow! I always assumed that the reason my browsing experience was so poor was down to my slow Internet connection, but it turns out that a fair amount of the delay is the browser.

So I have firefox - the GTK theme KDE installs looks awful, and several web sites look rubbish, but at least I can check my email...

Well, that's it for now. More to come soon (and this time I'll lose the shakespearean titles).

My Kingdom for a Browser!

2009-01-21T07:45:00.007+13:00

This post is set to be one of the most painful entries I have ever written on this weblog. Not because the subject matter is particularly difficult, but because the technology has let me down.

The story starts with me upgrading my laptop to Kubuntu 8.10. It's been out for a while, and I'm a big fan of KDE 4, but I hadn't had a sufficiently quiet weekend in which to take the plunge. I was previously running Kubuntu 8.04, so I could have just downloaded the latest packages, but I wanted to start from scratch, for a couple of reasons.:

I wanted to remove all the rubbish that I had installed over the last six months. I frequently download and install applications, only to find that they're not quite what I want. I rarely uninstall them, so over time my lhard disk fills with cruft.
I wanted to wipe away all the stale config, especially as my window manager would be changing from KDE 3.x to KDE4. Besides, there's a certain pleasure to be derived from configuring a brand new KDE installation.

The install was a breeze, and for the first time ever all my laptop hardware was detected and configured correctly without any hacking on my part - even the weird web-cam, which doesn't even work in Windows XP. Life was good, until I went to browse the Internet.

KDE ships with Konqueror as it's default web browser. As far as web browsers go it's fairly nice - It lacks the large "Add-Ons" repository that Firefox has, but many of the plugins I can't live without when using Firefox are included as standard in Konqueror.

Konqueror is more than just a web browser though - the integration between konqueror and the rest of KDE is truly stunning (as an aside: this is why I prefer KDE over other desktops. Technologies like KPart and DBus are the future of desktop applications, and KDE is leading the charge in this area). As an example, if you want to search google for something, but don't have your browser window open, what can you do? Easy! just press Alt + F2 to open the "Run Command" dialog, and type "gg: " followed by your desired keywords. Hit enter and you'll launch Konqueror with the google results right there waiting for you.

Konqueror also has extensive protocol support. For example, SCP and SFTP are supported by default. Try typing something like "fish://user@host" - konqueror will as for the user password, and will then behave like a file browser for the remote machine.

These two examples hardly scratch the surface of what Konqueror can do. However - there are some very serious problems with it. Using GMail with Konqueror is torturous. First Google will give you the plain-old-HTML-only mode, since Konqueror isn't officially supported. Then, if you ask for the full version anyway you get all sorts of weirdness - and a completely unusable inbox. The solution seems to be to set the user agent to Safari 2.0, but even then my inbox seems to be incredibly slow.

Members of the KDE community have pointed out that GMail plays fast-and-loose with web standards, so it's understandable that Konqueror misses a few tricks. The Google engineers must have tested the javascript enhanced version of GMail with the most popular browsers, and left Konqueror out in the cold - and fair enough. However, the KDE developers are missing the point: no matter how good their browser is technically - no matter how standards compliant it is, it simply does not work for me - the user. I now have a browser that I cannot use to check my email (no, using the HTML-only version is not an option).

So what are the alternatives?

Before I upgraded Kubuntu I had Firefox installed. However, when I went to install it, I nearly had a heart attack. In order to install Firefox, I had to install 63 other packages - most of them gnome or GTK packages. The reason for this is simple: Firefox uses the GTK toolkit to provide a UI. I knew this already, but this early on in my new Kubuntu install I wasn't about to pollute my OS install with GTK packages.

What can I do? There are a few other options available to me:

There's been talk of a Firefox port to Qt. However, nothing usable has materialised yet, so that's off the cards.

There's the Arora browser - this is a Qt browser running the Webkit engine (which is included as standard in later Qt distributions). A quick install told me what I needed to know: also not really usable as my default browser.

Finally there's Google's offering: Chromium. However, this has not yet been ported to Linux.

So what's the underlying cause of my troubles? Without hacking the code directly, I have no idea. Perhaps this is part of the KHTML vs Webkit debacle - There's a good article outlining the whole issue here, but I'd like to quote a couple of paragraphs:

So, what's the situation? Well, it appears that KHTML will remain the web rendering engine for Konqueror going into KDE 4.0, and that it could be changed to qtWebkit as of KDE 4.1. That does not seem to be officially settled, so much as the most likely scenario. It appears that the KHTML team seems hesitant about the proposition, while many KDE developers and users alike have expressed a very receptive attitude toward seeing Konqueror user qtWebkit. And Rusin made clear to a reader that he believes the KHTML team should continue their work as long as they like.

The challenge is that Webkit, which comes from Apple, is widely tested, and is thus known to work well with a large number of websites. KHTML is not as widely tested, and, for example, GMail doesn't work well with Konqueror. Many Konqueror fans have expressed regret at having to keep Firefox around just for sites like GMail, that don't recognize KHTML. Using Webkit would solve these problems, enabling many users to stick to one browser.

In other words: "The developers are dragging their feet to implement a fix that would arguably make Konqueror a better browser". Of course, the developers involved are free to do as they please with their code, but they're dragging down the rest of the KDE platform - I now have to have multiple browsers installed to do the most basic of day-to-day tasks.

While the situation is frustrating in itself, the unfortunate fact is that similar things are happening all over the open source scene. Frequently developers get too caught up in making sure that their code is "right" (that may mean designed correctly, stable, cool, standards compliant, well integrated, or anything else the developer feels is important), and not enough time is spent making sure that the product is usable. I suppose this is one of the draw backs to a development methodology where there is no external pressure to develop your product.

Usability is king, and trumps all other concerns in a product. If it's not usable, it's no good.

WiiWare: Innovation and mistakes

2009-01-01T03:03:00.002+13:00

I bought a Nintendo Wii earlier this year. I've never actually owned a console before, but have a reasonably strong loyalty to Nintendo. They appear to publish the best games (of course, that's entirely subjective). My game catalogue now includes the following titles:

The Legend of Zelda: Twilight Princess
Super Mario Galaxy
Metroid Prime: Corruption
Wii Sports
Mario Kart
Super Smash Bros Brawl
Star Wars The Force Unleashed (this game barely makes it into the list, I'm thoroughly disgusted with this title, and am considering using it as a coaster)

You may have noticed that I'm not a big fan of the more lighthearted "party" style games out there - I prefer the more focused, single player games.Once I had purchased those titles I began to look for something else, but quickly found that there's not a whole lot of choice out there right now. Most new Wii games tend to be in the "party" category.

Thankfully, Nintendo have launched WiiWare. WiiWare is a collection of titles created by third party developers. There are many different titles to choose from, and each title costs around £10. I ended up purchasing two titles:

These are both splendid games. However, once again, the pool of good games in the WiiWare collection is very limited - the main reason for this as far as I can see is that it's incredibly difficult to get your hands on the tools required to develop games for the Wii. For a start, Nintendo are only selling their development kit to well-established development houses (you need a registerred business, proper offices, previously published titles etc.). Their application form states that:

The Application includes a NonDisclosure Agreement (NDA). Once the Application and NDA are
submitted by you, we will email you a copy of the Application and NDA for your records. Please
note that your submission of an Application and NDA does not imply that your company is approved,
or will be approved, as an Authorized Developer for the platforms above.

...
If the Application is approved by Nintendo, we will notify you by email. At this point, your
company will be considered an Authorized Developer for the platform(s) specified. If your company
is approved for Wii, this also includes WiiWare. If approved the appropriate SDKs can be downloaded
from Warioworld, and development kits can be purchased from Nintendo of America.

So First you need to sign an NDA, Then, if you are accepted you need to purchase the development kit (priced at over $1000 USD). All this makes is increadibly hard for "joe programmer" to start cutting code for the Wii.

I really think Nintendo have missed a trick here; imagine the community that could form behind a free development kit. Think about the success of the Apple AppStore for the iPhone, but with games instead. The Wii is a revolutionary platform, with a unique control interface: surely lowering the barriers to entry can only be a good thing?

There's another side to this as well: The Wii Homebrew team have already done a lot of work reverse engineering the Wii, to the point where there is already an SDKs available for use. Is it usable? I haven't tried it myself yet (perhaps when I finish some of my current projects I'll play with it), but there are already a fair number of games available for the homebrew channel: I count more than 70 games listed, as well as a number of utilities, emulators and other bits and pieces.

The free development kit is based on the gcc PPC port, and comes bundled with everything you need to start development. GNU gcc has been a well established payer on the compiler scene, so it's not like we're playing with untested technology here.

Given that many of the secrets of the Wii are out (or are being reverse engineered even as you read this), wouldn't it be prudent for Nintendo to officially welcome third party developers to the fold? More importantly, for other, future consoles, imagine a world where:

The original manufacturer (Nintendo, Microsoft, Sony or whoever) use an open source toolchain from the beginning. I assume that Nintendo have spent a lot of time and money developing their toolchain, which seems a little wasteful to me, when an open source solution already exists. Sure, it may need to be tailored for the Wii, but I'm sure there are plenty of people who would embrace these changes. An open source toolchain lowers development costs, and lowers the barrier to entry for third party developers.
Third party developers are encouraged to write applications themselves, and the cost to entry is kept as low as possible. The manufacturer supplies the hardware, points to a pre-packaged toolchain of open source applications, and provides a development SDK with decent documentation. If all you need to test your games is a copy of the console itself, that would be great. However, why not build an emulator that can run on a standard PC?
The manufacturer provides bug-fixes for the SDK when needed, and creates a community-oriented website for budding developers.
The manufacturer provides a free (or very cheap) means of distributing third party applications via the internet, and offers the option of DRM routines, should the initial autors wish to make use of them.

I believe this setup could bring about a number of beneficial changes to the console gaming market:

An overall increase in the diversity and quality of available games.
A vibrant community of developers who help the manufacturer maintain the platform SDK and development toolchain by submitting bugs, feature requests and other suggestions.
Increased popularity for the platform (I'd buy any platform that offered all of the above).

Unfortunately, I can't see it happening any time soon. It seems to me that the big three console manufacturers are still engrossed in the "proprietary hardware, closed source" paradigm. Still, a guy can dream, right?

Happy Holidays

2008-12-22T06:35:00.002+13:00

This is the last post of 2008 - on reflection it's been a rather good year: there have been several posts on this blog worthy of a read (and several that were pure garbage), I've gotten involved in a few more projects (I hope to unveil a new one fairly soon - it's very exciting). Time will tell what 2009 has in store for us!

I'm going to visit family in the UK, and I don't expect I'll be back home before the new year. So, happy holidays to one and all - even if you've decided to work through them!

Cheers,

Jop Opening at Pebble Beach Systems

2008-12-15T20:25:00.005+13:00

We have a couple of job openings available here at Pebble Beach Systems, due to expansion of the programming team.

If you know C++, a bit of SQL, think you know how to handle a thread, and think you have a handle on programming in general, feel free to contact me and I can pass your CV and cover letter along to the big boss-man. The best way to contact me is via email: thomir gmail com

We're looking for a graduate and a senior developer. Pebble Beach Systems is a great place to work - very friendly relaxed atmosphere with a great bunch of people.

Cheers,

Teaching Programming mk. 2

2008-12-09T08:22:00.007+13:00

I blogged before about what I think we should teach programming students, and almost immediately wished I hadn't. Sometimes I feel that my blog posts are somewhat pointless meanderings through the garbage that inhabits my sleep-deprived brain. At other times I feel that I have contributed something useful to the general public. The post in question is firmly in the former category - but what can I do? I won't start deleting articles as soon as I fall out of favor with them, so I'm hereby correcting my earlier mistakes (at least, attempting to). Illiad Frazer knows how I feel:

The whole point of the previous post was that I felt that most graduate students were under-prepared for work in industry. My main evidence of this is that it seems to take a long time, and more importantly a lot of interviews before one strikes "candidate gold" when recruiting for a new programmer.
I will admit that this could be for many reason: perhaps our expectations are too high, perhaps we are not paying enough to attract the kind of graduate we're looking for, or perhaps the industry we're in isn't desirable enough to attract the better candidates. The list goes on endlessly - and yet I cannot ignore the fact that most graduates I meet are not up to scratch.

So what prompted this revision of a past article? I happened to read E. W. Dijkstra's article entitled "On the cruelty of really teaching computing science". In it, he postulates that the methods used by most universities are fundamentally flawed when it comes to teaching computer science, and more specifically when teaching computer programming. I'd like to quote part of this article:

...we teach a simple, clean, imperative programming language, with a skip and a multiple assignment as basic statements, with a block structure for local variables, the semicolon as operator for statement composition, a nice alternative construct, a nice repetition and, if so desired, a procedure call. To this we add a minimum of data types, say booleans, integers, characters and strings. The essential thing is that, for whatever we introduce, the corresponding semantics is defined by the proof rules that go with it.

Right from the beginning, and all through the course, we stress that the programmer's task is not just to write down a program, but that his main task is to give a formal proof that the program he proposes meets the equally formal functional specification. While designing proofs and programs hand in hand, the student gets ample opportunity to perfect his manipulative agility with the predicate calculus.

This method of programming - approaching the programming language as a kind of "predicate calculus' has it's advantages. It demands that the students pay attention to the features, rules, regulations and guarantees that the language provides. Whichever language is used (and to a certain extend it does not matter), the rules and regulations of that language are going to dictate the structure of the program. This is similar to the fact that the laws of math dictate the form of any mathematical proof; ignore the laws of the language, and your program (or proof, if you will) no longer makes sense. In the domain of integer mathematics, 2 + 3 will aways equal 5. In the domain of C++, local variables are destroyed in the reverse order that they were created in (insert whatever rule of the language you want there).

Consider for a moment my previous post; I listed 11 things which I thought were essential for any programming student to know. Looking back, I notice that the top five items are all specific to C++ (since that's the language I talk in). Is it a coincidence that the five most important things any programming student can know are specific to the language they are using? I think not.

Rather, I believe that to be a great programmer, one must have a deep understanding of the language at hand, and how that language allows you to express logical problems. One must approach a program like a mathematical problem - that is, one must know the rules of the language, and then use those rules to design a proof that conclusively solves the logical problem using the language at hand.

That last point is worth reiterating: Anyone can write a program that appears to solve a problem most of the time. However, for non-trivial problems it becomes much harder to guarantee that the program will solve the problem 100% of the time. As we get further into the "edge cases" of the application logic it becomes less likely such a naive implementation will work correctly. However, a program that has been built from the ground up using the guaranteed behavior of the language can still contain bugs, but it's much more likely that they are logic errors introduced by the programmer, rather than subtle bugs introduced through language misuse.

At this point I must point out that I do not believe that Dijkstra's idea is as good as he makes it sound. He addresses one point - that students should understand the rules of the language, but a "love of the language"is only half the picture. There are also many non-language related skills that come in to play. Consider debugging for example; there are formal techniques that can be used to debug certain types of errors. Knowing these techniques, and knowing when to employ them is a powerful aid in any language, and these are skills that should be taught, rather than learned in an ad hoc approach.

So, my revised top 10 list of things every programming student should know can now be revised into this, much shorter form:

Know your language. I don't care what your language is - if you want a job it had better be something that's being used, but you can be a great programmer even if all you know is an out-dated language. Not only do you need to know your language, you need to have a passion for knowing your language - you must actively want to extend your knowledge of the language and how it works, what guarantees it provides and which it doesn't. This knowledge will translate into programs that use the features of the language to create minimal, efficient, well structured and error-free programs.
Be willing to learn new techniques. There are so many useful techniques and skills for a new programmer to have that I cannot list them all here, and course designers cannot possibly include them all in their course material.

That's it - two things. Much better than the self-absorbed tripe I rattled off a few weeks ago. To anyone who actually bothered to read that, I apologize profusely.

All BLacks vs. Wales

2008-11-22T00:01:00.003+13:00

I don't normally write about sport, but I thought I'd mention that I'm about to start the long drive to Wales to see the match this weekend. My money's on the All Blacks to take the match, but many people have suggested that it may be a close call.

Will post an update upon my return!

EDIT: Well, I'm back. The Rugby was awesome, possibly the best game I've ever seen. I wanted to post a link to a highlights video on YouTube, but it seems no one has posted one yet. Instead, I'll post a video of the initial stand-off between the teams after the Haka. The atmosphere was incredible - a full house (74 thousand strong) all screaming at the top of their lungs. Good fun. Anyway, you can see it here:

The data: URL scheme

2008-11-16T22:55:00.000+13:00

Here's something you may not already know: You can include data directly in an (x)html page, instead of referencing it externally.

For example, most of the time when you want to display an image you would write code like this:

<img src="http://www.blogger.com/some_image.png" alt="some random image" />

Web browsers downloading your HTML source will download the text first, then download any external references, including "some_image.png" (assuming the user has not turned off image downloading).However, there are a few cases where you want to distribute an HTML file with images, but don't want to distribute multiple files. In those cases, the 'data:' URL scheme is what you need.

The scheme is documented in the (very readable) RFC2339. Essentially, you can include the binary data straight into your HTML code. The example they give in the RFC looks like this:

<img src="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw%20%20%20AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz%20%20%20ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp%20%20%20a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl%20%20%20ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis%20%20%20F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH%20%20%20hhx4dbgYKAAA7" alt="Larry" />

Which equates to this image:

There are many reasons why you wouldn't want to do this - it increases the size of your HTML file, forcing users to download more before they can see whether your content is what they want (especially if the embedded data is near the beginning of the file). There are also some limitations on the size of data and those limitations vary depending on where this technique is used. Still, it's a useful technique that can be used when you need to embed small amounts of binary data within an HTML file and you don't want to distribute multiple files.

Ten Things to Teach Programming Students

2008-11-07T07:03:00.004+13:00

While talking to a friend recently, we began discussing the role of graduates in the industry. My belief is that employers employ graduates and expect them to have the same skill level as their existing, trained employees (I have certainly seen this first-hand). Having been on the "other side" of the problem I appreciate that graduates are rarely fit for the tasks set for them without further training.

This got me thinking: If there were 10 things graduates should know before graduating, what should they be? What short list of skills can graduates teach themselves to become better than their competition (and getting that first job is just that: a competition). That train of thought spawned the following list:

Ten things programming students should know before graduating:

Inheritance & Composition. In the land of OO, you must know what inheritance does for you. In C++, this means that you must know what public, protected and (rarely used) private inheritance means. If class A is publically inherited form class B, that does that tell you about the relationship between A and B? What about if the inheritance was protected, rather than public? In a similar vein, what does virtual inheritnace do, and when would you want to use it? Sooner or later a graduate programmer will discover a complex case of multiple inheritance, and they need to be able to cope with it in a logical fashion. Knowing the answers to the above questions will help.
Unfortunately, a lot of the time inheritance is over-used. Just because we have access to inheritance, doesn't mean we should use it all the time! Composition can be a useful tool to provide clean code where inheritance would muddy the waters. Composition is such a basic tool that many graduates don't even think of it as a tool. Experience will teach when to use composition and when to use inheritance. Graduates have to know that both can be solutions to the same problem.
Memory Allocation. So many graduates do not understand the importance of cleaning up after yourself. Some do not fully appreciate the difference between creating objects on the stack and on the heap. Some know that but fail to understand how memory can be leaked (exceptions are a frequent cause of memory leaks in novice programmers). Every programmer should know the basic usage of new, new[], delete and delete[], and should know when and how to use them.
Exceptions. Most programmers share a love / hate relationship with exceptions; You gotta know how to catch them, but at the same time you tend to avoid using them yourself. Why? Because exceptions should be .... exceptional! There's a reasonably large amount of overhead associated with throwing and catching exceptions. Using exception as return values or flow-control constructs are two examples of exception mis-use. Exceptions should be thrown only when the user (or programmer) does something so bad that there's no way to easily fix or recover from it. Running out of resources (whether it be memory, disk space, resource Ids or whatever) is a common cause for exceptions to be thrown.
Const correctness. Const correctness is so simple, yet so many programmers just don't bother with it. The big advantage of const-correctness is that it allows the compiler to check your code for you. By designating some methods or objects const you're telling the compiler "I don't want to change this object here". If you do accidentally change the object the compiler will warn you.
Threading. Threading is hard. There's no simple way around this fact. Unfortunately, the future of PC hardware seems to be CPUs with many cores. Programs that do not make use of multiple threads have no way to make use of future hardware improvements. Even though using libraries like Qt that make it ridiculously easy to create threads and pass data between threads, you still need to understand what a thread is, and what you can and cannot do. A very common thing I see in new programmers is a tendency to use inadequate synchronization objects in threads. Repeat after me: "A volatile bool is not a synchronization object!".
Source control. Every programmer on the planet should know how to use at least one version control system. I don't care if it's distributed or not, whether it uses exclusive locks or not, or even if it makes your tea for you. The concepts are the same. Very few professional programmers work alone. Graduates must be able to work in a team - that includes managing their code in a sensible fashion.
Compiler vs Linker. Programmers need to understand that compiling an application is a two step process. Compilation and Linking are two, discreet, and very different steps. Compiler errors and Linker errors mean very different things, and are resolved in very different ways. Programmers must know what each tool does for them, and how to resolve the most common errors.
Know how to debug. When something goes wrong, you need to know how to fix it. Usually, finding the problem is 90% of the work, fixing it is 5% of the work, and testing it afterwards is another 10%. No, that's not a typo - it does add up to more than 100%, which is why there's a lot of untested code out there! Of course, if you were really good you wouldn't write any bugs in the first place!
Binary Compatibility. This one is for all those programmers that write library code, or code that gets partially patched over time. As you probably already know, shared libraries contain a table of exported symbols. If you change that table so a symbol is no longer available (or it's signature changes), code that uses that symbol will no longer work. There's a list of things you can and cannot do while maintaining binary compatability, and it's very hard not to break those rules, even if you know what you're doing. I've blogged about this before, and linked to the KDE binary compatibility page on techbase - worth a read!
The main method of maintaining binary compatibility is to program to an interface, rather than to an implementation. Once you start paying attention to binary compatibility, you'll quickly realise that it's a very bad idea to export your implementation from a shared library, for one simple reason: If you want to change your implementation you're stuck with the restrictions placed upon you by the need to maintain binary compatibility. If all you export is a pure interface and a means to create it (possibly via a factory method) then you can change the implementation to your heart's content without having to resort to pimpl pointers.
Read the right books. There are a few movers and shakers in the programming industry that it pays to keep an eye on. There are many books worth reading, but I'm going to recommend just two. The first is "Design Patterns: Elements of Reusable Object-Oriented Software", and the second is the "Effective C++" series. Neither are considered to be great bedtime reading, both are considered to be packed from cover to cover with things that will help you out in every-day situations. Any programmer worth his or her salt will own a copy of at least one of these books, if not both. Of course, there are books on UI design and usability, threading, text searching, SQL and database maintenance, networking, hardware IO, optimisation, debugging... the list goes on.
Networking. What's this? An 11th item? That's right: it's in here because it cannot be ignored in most programming tasks. It's getting harder and harder to avoid networking. Most graduates will have to write code that sends data over a network sooner or later, so they'll need to know the difference between UDP and TCP and IP, as well as what the basic network stack looks like (think "Please Do Not Touch Steve's Pet Alligator"), and what each layer does. Being familiar with tools like wireshark helps here.

What's not in the list:

You may notice that I haven't included any specific technologies in this list. That's because I firmly believe that it really doesn't matter. Sure, there are some libraries that are better than others (I'd bet my life on a small set of libraries), but the programmer next to me has a different set. I care not one grote whether a graduate knows how to program in .NET, Qt, wxWidgets or anything else - as long as they're willing to learn something new (whatever I'm using on my project).

Which brings me nicely to the conclusion: The single quality I see in all the programmers I admire is a sense of curiosity; a restlessness and a sense of adventure. Our industry is constantly shifting. The best programmers are able to ride the changes and come out better for it.

Is this post horribly self-indulgent and boring? Probably, but it had to be done. Have I forgotten anything? Things you feel should be on the list that are missing? Remember that the point of the exercise is to keep a small list - I could list every programming skill and technology required under the sun, but that would not be very useful would it?

Releases Galore!

2008-10-31T10:14:00.004+13:00

It would be negligent of me if I did not point out that today several important software releases were made:

The first is the project formerly known as project greenhouse - now known as Qt Creator. I've blogged about this before. You can now download a technical preview. I'm very excited about this - having played with it in it's beta state I can't wait to use it with some of my active projects. Unfortunately I won't be doing any coding this weekend, as I'm off to Switzerland for a long weekend. I'll have to try it out when I get back.

The second big release event today is the Ubuntu family of distributions. That's right, version 8.10 is out now. I'm a kubuntu man myself, so I'll be trying this out after my long weekend as well.

That's all from me - I have several projects in the wings to blog about in the coming weeks, but for now I need to catch some sleep - my taxi arrives at 5:00 AM tomorrow.

Cheers,

VMWare Server 2: Worse Than Failure

2008-10-25T04:34:00.002+13:00

OK, so this is hardly breaking news, but I thought I'd share this mini-rant with you now any way.

At work We deal with multiple operating systems (WinXP, Vista, Linux), and multiple programming environments. A few weeks ago I decided to take the plunge and do all my development work inside virtual machines. The advantage of this approach is that it's very fast to switch from one environment to another (much faster than a whole machine reboot).

There are two problems with this approach:

Performance. Programming is a pretty CPU-intensive task. Well, compiling the code is anyway. Compiling our code base takes around an hour on a physical machine with top-of-the-line specs (this makes compiling the Linux kernel seem fast). On a virtual machine, that time doubles. This is an inescapable truth about software virtualization: there will always be some overhead.
Hardware. The applications I program need access to physical hardware, over a variety of interfaces, including RS232, RS422, USB, Parallel, TCP/IP, UDP/IP and a few others besides. Any software virtualization package must be able to forward all these hardware interfaces through to the virtual machine.

In my experience, the only software virtualization package that meets requirement 2 is VMWare. I know I've raved about Virtualbox before, and I was very tempted to use it again now, but it lacks the hardware support I need.

So, VMWare Server it is then. The next question then becomes: which version? I've used version 1.x before, and it fulfilled all my needs at the time. However, I noticed that version 2 is now available. I thought "In software, bigger numbers are better, right?"

After downloading the sevrer, and registerring for a free license key, I spent a busy 30 minutes clicking through the ubiquitous license agreements and installation options (does anyone ever read these things?). Everything was installed. I went to fire the application up, only to have it launch Mozilla Firefox. What's going on here? Then it hit me: a wave of fear and horror. What were they thinking?

The managment interface for VMWare Server 2 is web based.

That's right... you want to use your virtual machine? You need to run a web browser. The interface is slow, the browser plugin that supports the interface is buggy... I could go on, but some other people have detailed the problems with the software far better than I ever could (Yes, I realise that link is talking about the beta release. Trust me, nothing much has changed).

Maybe I'm missing something, some gold nugget of understanding that would make Server 2 more usable for me, but right now I just don't get it. Why would you decide that the primary interface to a virtual machine should reside inside a browser? Browsers are notorious for implementing different standards, being generally slow, memory-hogging apps that occaisonally crash. Who in their right mind would want to use a browser for their virtual machines?

Until then, I'll stick with VMWare server 1, thank you very much.

It's true: Qt Developer Days Rock!

2008-10-18T06:26:00.003+13:00

Well, I'm back. I arrived home at 1:30 AM this morning. Qt Software's "Developer Days" conference was simply brilliant. On top of the many technical talks (I'll digest them and use them as inspiration for new posts here over the next few weeks), it was a great chance to meet other Qt developers, and the trolls themselves.

There's a lot of stuff to talk about - more than I can do justice in one post. I will quickly mention Project Greenhouse, the new IDE that should be released as alpha software in the next few weeks. Details are sketchy, but the following points are probably all correct:

"Project Greenhouse" is the development title - it may chance before release.
The IDE is aimed at creating a truly cross-platform development environment.
Uses GCC / GDB to compile / debug code.
Includes nice editor features like code folding, syntax highlighting, auto-completion etc.
It's been touted as a "replacement for Vi/Emacs" - although this is misleading - as I understand it no one is going to create a Vi clone editor in the IDE. It's a replacement in the sense that you will no longer need to use Vi in order to edit your code under Linux.

One point the trolls were very insistent upon was that they're not trying to replace Visual Studio, Eclipse, KDevelop, or XCode. Those IDEs have a great many features, whereas PG intends to deliver a core set of features - just enough to make Qt development a breeze across multiple platforms.

At least, that's my interpretation of the project. There's been lots of speculation across the internet and on the Qt-interest mailing list about the project, so we may have to wait and see.

TT Dev Days: Here I come!

2008-10-12T22:40:00.003+13:00

Just thought I'd let you all know that I'll be attending the Trolltech Developer Days in Munich, Germany. I'm not taking my laptop, so I probably won't update this site while I'm there (not that you'd notice a change in activity levels, right?), but I hope to provide a few details once I get back.

Until then, keep coding!

End of the world as we know it?

2008-09-26T06:42:00.002+12:00

This is a short post - I am overcome with grief. I have been waiting for spore to arrive on the Wii, and now I hear it will never arrive.

So many years of anticipation; so much disappointment - DRM issues aside I was still looking forward to this. Now I won't have a chance to sample that sweet candy of gaming goodness.

Slackware Rant

2008-09-19T22:19:00.005+12:00

Yes, this is a rant. pure, unaltered hate and bile to follow:

<rant>

Check out the first sentence on the Slackware "General Info" page:

The Official Release of Slackware Linux by Patrick Volkerding is an advanced Linux operating system, designed with the twin goals of ease of use and stability as top priorities. Including the latest popular software while retaining a sense of tradition, providing simplicity and ease of use alongside flexibility and power, Slackware brings the best of all worlds to the table.

Does anyone using slackware actually believe this? How is a distribution that has no graphical installer, no network-enabled package managment and a severely restrictive list of packages available on the default install easy to use? How is slackware more advanced than a distribution that provides proper package managment services?

I guess when they say "while retaining a sense of tradition" they mean "feels like you just stepped into a time-warp into the Linux distros fo yester-year".

I guess it's fine for those of you who want the massochistic rituals of using Linux in the early 1990's (I was there: been there, done that, bought the T-shirt). The the sane members of the human race who want a proper Linux distribution I strongly recommend something else.

</rant>

I think I need more practise at ranting - that was pretty tame really, but I feel better, whcih is the most important thing.

Cheers,

threads vs. processes

2008-09-14T23:45:00.003+12:00

It's been a few weeks since my last post. My excuse is that I've been busy - my job is always busy around this time of year due to the IBC trade show. Thankfully most of the work is now done. In my own time I've been working on a number of projects (to be unveiled shortly, once they're usable).

In the last few weeks we've seen the launch of the google chrome browser. I won't discuss it here directly (plenty of other people have reviewed it separately). I will, however mention the one feature that has converted me away from firefox and towards chrome:

Google Chrome has a multi-process architecture, meaning tabs can run in separate processes from each other, and from the main browser process.

What this means in theory is that a misbehaving website cannot bring down the entire browser session - you can just close / kill the offending tab / window.

This is pretty cool, but how does it relate to my own work?

I'm writing an application that makes extensive input of python scripts to customize the input and output of the application. I could have spend a while embedding the python scripts using the python API, and then running those separate scripts in a thread, but instead I chose to run them as separate processes spawned by a central application. The way I see it, this approach has several advantages:

Crashing child processes (in this case python scripts) are unlikely to bring down the entire application - you still need to be careful since there's likely to be communication between child and parent process, and the parent needs to be able to hand corrupted data in that communication. Other than that, if one of my scripts breaks, I can easily carry on; no error handling or cleanup needs to be done.
In my application, I need to repeatedly call the script files - probably thousands of times for a single application run. In a traditional threaded environment the possibility for memory leaks is huge. This way, since each sub-process is short lived, the operating system takes charge of cleaning up any memory not deallocated by the child process.
It's a damn site easier to program too. No thread synchronization required!

It's not all roses however.

From my experiences the main drawback is that it's much harder to pass data between parent and child processes. For simple communication it may be enough to use stdin and stdout, but for anything more complicated you'll want to use some form of proper IPC (sockets, named pipes, DBus etc). Even with proper IPC it's still harder to pass custom data structures between processes, since you'll need some sort of data serialization.

Think this all sounds obvious?

That's because it really is! I can't believe how much simpler this approach is, especially if your requirements are for simple delegation to scripts or sub-processes. If you require more complex interaction you might find this approach more trouble than it's worth.

virtualbox rocks

2008-08-31T03:16:00.003+12:00

I know I've said this before, but VirtualBox kicks ass. It has that whole "it just WORKS" feel to it. I realise that repeating yourself is supposedly one of the hallmarks of a bad blog, but please indulge me this once; VirtualBox deserves your attention. The image to your right shows virtualbox running windows XP - I'm installing Qt4.4 in the hope that some of the bugs I mentioned in my previous post have been cleaned up.

I'm also compiling the latest KDE4, which is where a multi-core system would be really nice. Until then, I'll continue to struggle with my old box.

Twitter Submission

2008-08-28T00:55:00.001+12:00

I posted previously that I just didn't "get" twitter. I guess this sums up my objections pretty well; unless you have anything interesting to say, stay silent. Do we really need one more idiot blathering on about the most mundane details of his life? I think not.

Even some of my most respected peers seem to be reduced to complete morons when it comes to their twitter feeds.

However, it turns out that the cost of my stubbornness to jump on the twit bandwagon has grown to the point where I am now on twitter. That's right, I'm bowing to peer pressure, and have officially jumped on the twit wagon - You can see my last twitter updates on the right, or you can follow me on twitter.

Now the entire world can join me in my mindless ramblings... of course, if you're reading this then you've already had that pleasure!

Buffalo Routers Rock!

2008-08-26T00:15:00.004+12:00

Waaaaay back in Janurary I mentioned that I might build my own wireless router. Well, like most of my projects I got half way then got distracted. The other day i got fed up with the lack of wireless (I needed to get my Wii online, apart from anything else), so I splashed out and bought a Buffalo Air-Station (£45).

This baby comes pre-loaded with the open source dd-wrt firmware. It was dead-easy to set up, and boy, what a difference the open firmware makes! This is easily the best router firmware I have ever seen - it boasts more feature than you can shake a stick at. Better yet - it's aimed at people who know what they're doing, and doesn't try to hide it's functionality behind restrictive setup "wizards".

All in all, I'm a very happy man with my new wireless network ;)

pointer quiz

2008-08-08T23:52:00.003+12:00

One of my pet peeves with regards to C++ is how very few people understand how the delete operator handles NULL pointers. Let's see if you pass the test!

Question: What happens when you do this:


myType *ptr = NULL;
delete ptr;

Well? Your choices are:

a) Crash, bang, boom, your computer is now a very heavy paperweight.
b) Nothing - the delete line ignores the ptr to be deleted.

It turns out that deleting a null pointer is safe. Section 5.3.5/2 of the C++ standard states that:

"In either alternative, if the value of the operand of delete is the
null pointer the operation has no effect."

This has been a pet peeve of mine for a while now. I can't count the number of times I've seen programmers write something like this in class destructors or cleanup methods:


if (pMyPtr)
 delete pMyPtr;

This is stupid for several reasons. For a start, the if statement is redundant - if the pointer is NULL the delete will do nothing. Secondly, the programmer never sets the pointer to NULL after deleting it, which means that if this code were to be called again, you would definitely experience problems.

In order to avoid these issues, and avoid angering me if I ever see your code, you should:

Always initialize pointers to NULL if you're not going to set them to something else straight away (i.e.- if the pointer is not always used).

Always set them to NULL after you delete them, especially if there's a chance that the delete can be called twice.

piwup: A Picasaweb Image Uploader for Linux

2008-08-03T16:47:00.001+12:00

One of my pet peeves has always been that unless you want to run google's picasa application under Linux, the only way to upload photos to your picasaweb account is via a klunky web interface that only allows you to select 5 images at a time. When I come back from a trip I have hundreds of photos, so this gets tiresome very quickly.

There is a kipi plugin that is supposed to be able to do this, but it has not yet hit the Linux distribution I am using, and I'm not about to start compiling plugins from source. Besides, half the fun is in making the application!

This is definitely not a finished application! I got it to the point where I could upload my images in a batch, but it needs more work before it's useful to anyone else. Here's a few sample screen shots:

Selecting images to upload.

Uploading the first image.

The application still has a long way to go. Just some of the things yet to complete are:

Remove hard coded items from the code (account details, service host, album name), and make these configurable via a nice configuration dialog. Make sure password is stored in a secure form - via the KDE wallet perhaps.

Make the GUI half-decent. Originally I just wanted something to work - I need to go back and do it again with a proper menu and image thumbnail support.

Bug fixes too numerous to mention here... this is some rouch, cheap and nasty code!

Perhaps, once I get all this done I will attempt to get it officially released into some distros. I think it's a useful application, and the kipi plugin version doesn't seem to be moving along much. Yes, I realize that I'd be better off spending my time improving the kipi plugin, but to be honest I can't be bothered right now - this was a learning experiment for me as much as it was about making an application that solved one of my problems.

The entire application is written in C++ and Qt4. The more I use Qt the more I like it. This application was simplicity itself to make, and I look forward to continued development.

Problem with pimpls

2008-08-03T05:03:00.003+12:00

That's "pimpl", not "pimple" - I'm talking about opaque pointers, these beauties help protect your public interfaces from changing implementation. This useful technique has a few drawbacks that aren't so well publicised. In order to prevent others making the same mistakes I have, I thought I'd outline the general use of the pimpl pointer, and some of it's drawbacks:

Here's an example of a first-pass class to encapsulate a user account (I'm making this up on the fly, so bear with me):


class
userAccount
{
public:
    // public methods go here
private:
    // private data members:
    unsigned int accountId;
    std::string username;
    std::string realName;
};

This will work just fine, but there's a problem. If you need to change the implementation (say you want to store the user's real name in two fields instead of one), unless you're very careful you will end up changing the size and / or the declaration of the class.

Changing the size of the class is a big problem if you're trying to maintain binary compatibility. Changing the declaration of the class is a problem because (some) compilers will now recompile every file that includes your changed header file, even if the changes make no difference to the binary output.

The solution comes in the form of an opaque pointer, or "pointer to implementation" (which is where we get the charming "pimpl" name from). The idea is that the implementation details are put in a separate class that is forward declared in the header file, and fully declared in the cpp file. Your external interface now only contains a single pointer - you can change the size of your implementation class to your hearts content, and you will never change the size or declaration of your external interface. The class above refactored to use a pimpl pointer looks like this:

Header File:


// forward declare implementation class:
class
userCountImpl;

class
userAccount
{
public:
    userAccount();
    // public methods go here
private:
// private data members:
    userAccountImpl *pimpl;
};

Source File:


class
userAccountImpl
{
public:
    unsigned int accountId;
    std::string username;
    std::string realName;
};


userAccount::userAccount()
: pimpl(new userAccountImpl)
{
}

Now any data members can be accesed via the private implementation class. There are several things you can do to extend the example above (using a shard_ptr is a start), but I want to keep things simple for the sake of the example.

Until recently, I took this method for granted and used it as often as I could. As so often happens when I learn something new I rush to use it in every possible situation, including ones where it doesn't make sense. The pimpl idiom has a few problems associated with it, which I will outline here:

Your object's memory footprint is now split into more than one place in memory. This may not be a huge problem for 90% of classes, but consider a small utility class that contains only standard data types:
```
class colour
{
public:
    // public methods go here
private:
    unsigned char red;
    unsigned char green;
    unsigned char blue;
};
```
In order to serialise this into a buffer (like a file), you can get away with using a memcpy or similar technique. Since your object's memory footprint is contiguos, copying the entire object into a file is simple (Yes yes, I know: there are many reasons why this isn't a good idea, but let's face it - this happens all the time). Once you start using pimpl pointers it gets a bit more difficult. Since your implementation class is private to the .cpp file, the code to do the copying needs to be in the same cpp file (otherwise it doesn't have access to the definition of the implementation class). This is relatively easy to work around, but the trouble doesn't stop there - consider what you need to do to un-serialise an object from a buffer. You can no longer be cheeky and use a reinterpret-cast like so:
```
colour *pCol = (colour*) pBuffer;
```
Again - I realise that this isn't the best idea in the world, but when you're programming with constraints sometimes this is the best way to do things.
The default new and delete operators are expensive. I never realized just how expensive they can be. In a recent bout of performance testing on some real-time software I saw the default new operator take 55ms to allocate a block of 4B of memory. That's way too slow for the real-time application i was working on, and may be too slow for other applications as well. What's more, the times get worse the more memory you allocate - so using the pimpl pointer may not be a good idea at all, since it adds the overhead of a new call to each constructor, and a delete to each destructor. ouch!

If you're looking for more info on the pimpl idiom, Sutter wrote a good article on the pimpl pointer, and a more recent article that talks about some of the performance issues associated with pimpl pointers. This technique is worth using - it can save many attacks of "code cheese" in the future, just be careful where you us it, or you may end up with some nasty performance issues you didn't expect!

Apathy, Apples and Understanding

2008-07-22T22:03:00.001+12:00

You may notice that it's been a long time since my last post. Truth be told I've been lazy. It's tempting to say that I've been busy, but that's a sugar coating on apathy. For that I apologise! Hopefully I can get back into the habit of regular posting again soon.

Inspiration struck the other day when Jeff Atwood posted an interesting article on his blog. "Dealing With Bad Apples" talks about how single members of a programming team can be difficult, often working against the rest of the team.

Atwood quotes Robert Miesen:

I was part of a team writing an web-based job application and screening
system (a job kiosk the customer called it) and my team and our
customer signed on to implementing this job kiosk using Windows,
Apache, PHP5, and the ZendFramework -- everyone except one of our team
members, who I will refer to as "Joe". Joe kept advocating the use of
JavaScript throughout the technology deliberation phase, even though
the customer made it quite clear that he expected the vast majority of
the job kiosk to be implemented using a server-side technology and all
the validation should be done using server-side technology.
The fact that the customer signed off on this, however, did nothing
to deter Joe from advocating JavaScript -- abrasively. Every time our
project hit a bump in the road, Joe would go off on some tirade on how
much easier our lives would be if we were only writing this job kiosk
in JavaScript. Joe would constantly bicker about how we were all doing
this all wrong because we weren't doing it in JavaScript, not even
bother to learn the technologies we were actually using, and, whenever
fellow teammates would try and gently bring him back into the fold
(usually via email), Joe would just flame the poor guy. At the height
of Joe's pro-JavaScript bigotry, he would regularly belt off comments
like, "Well, if we had only done it in JavaScript," to such an extent
that the team would have been better off if he had just quit (or was
reassigned or fired.)

Jeff then goes on to suggest that perhaps the problem here is a "bad apple" - a team member that is doing more harm than good in a team. He's probably right, but I have a slightly different angle.

Perhaps the real problem here is poor team leadership / management? Without meeting "Joe" personally, I cannot make any accurate assessment of the situation, but it seems to me that perhaps Joe feels undervalued in his team? I say this because i recognize that behavior pattern - in myself.

In any team of programmers, each member will have different backgrounds, strengths and weaknesses. Joe obviously has experience using Javascript, and feels the need to share his expertise in that field. I'm not saying that this is a good thing, but perhaps the underlying problem is a lack of cohesion and understanding between team members?

So, further to Atwood's list of warning signs for detecting "bad apples", I have a list of actions team leaders could consider taking when dealing with a so-called "bad apple":

Listen to them. Most geeks (I use the term with all possible affection) are reasonable people. If a team member is repeating themselves, perhaps they feel that their point was never seriously considered in the first place? I can't count the number of times I've made contributions in meetings that were ignored, only to hear (usually six weeks later) "hey, we should have done X, what a pity it's too late now...". It always seems petty to point out that I suggested X from the start. Bear with me here - I'm certainly not suggesting that I'm always right - far from it; my point is that you ignore contributions from your team members at your own risk!

Finally, I'm not suggesting that team leaders always act on suggestions from their team members, but listening is a good start.
Once you start listening to bad apples, you may find that some of your team members have strengths you didn't expect. Can you use these strengths in the future? This depends a lot on your business model and workload. From my own experience I can understand that programming code that doesn't interest you week in - week out can be incredibly draining. Perhaps bad-apples can be encouraged to pull together with the team?
Finally - I don't know what the IT job market is like where Jeff lives, but you can't fire programmers and expect to get a replacement any time soon. Jeff writes:

You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude.

I say "bollocks" to that - it's incredibly expensive to fire and replace someone. Not only is there the cost of looking for, and hiring someone new, but there's the training overhead, and there's no guarantee that you can find someone with the appropriate skill set any time soon. From where I'm sitting it looks like we have to wait around 6-8 weeks between looking for, and hiring a new programmer. That's almost two months of productivity down the drain! Suggesting that you can't develop a positive attitude in your team-members is incredibly negative and close-minded. I'm certainly glad I'm not on a team with a leader like that!

That said and done, I do hope that the current skill shortage in this country develops a greater appreciation of the worker. I suspect that most companies vastly underestimate the value of their skilled (and unskilled) workers.
Next time you have a problem with someone, consider the massive cost of replacing them, and - more importantly - consider the huge amounts of good work they've done, before you concentrate on the bad.

Masters of the big buildup

2008-06-04T20:09:00.002+12:00

The Foo Fighters are the masters of the big buildup. Listen to a track like "Let it Die" from their album "Echoes, Silence, Patience and Grace" - Brilliant!

QtScript: Exposing C++ classes (part two)

2008-05-12T02:42:00.003+12:00

This is the second part of my QtScript walkthrough / tutorial. You can read the first part here.

As in the last tutorial, I must add the following disclaimer:

I'm writing these posts as I learn to use the QtScript module. As such, the solution I present here may not be the best / most elegant way of doing things. However, if I find a better solution, I'll certainly post back here in the future with corrections.

If there's any (QtScript-related) topic you'd like me to write about in the future, just leave a message and I'll endeavor to fulfill your request.

Background:

The last post was all about deferring some execution from a C++ class to an ECMAScript. The basic idea was that the C++ class could emit signals, zero or more of which were connected to functions in the script file. The script file set up these connections, so the the C++ code doesn't need to know which signals are being overridden, and which aren't.

This is all well and good, but you'll soon find that there's very little you can do in the script file, since the only functionality you have available is the builtin ECMASCript functions.What I'm going to look at today is how to make your own, and Qt classes available for use in the script file. In my example, I'm going to make the QMessageBox class available, but you can choose any other method you want.

Take 1:

First off, I want to be able to write "mb = new QMessageBox;" on my script, and have it work. This is actually pretty simple to achieve. The way I have chosen to do this is with a wrapper class. This wrapper derives from QMessageBox and QScriptable, and contains the magic "qscript_call" method. Here's the code:


// wrapper around QMessageBox:
class Wrapper_QMessageBox: public QMessageBox, protected QScriptable
{
 Q_OBJECT
 public:
 
 Wrapper_QMessageBox(QWidget *parent =0)
 : QMessageBox(parent) {}
 
 public slots:
  QScriptValue qscript_call(QWidget *parent = 0)
  {
   QMessageBox * const iface = new Wrapper_QMessageBox(parent);
   return engine()->newQObject(iface, QScriptEngine::AutoOwnership); 
  }
};

This is the complete wrapper so far. Note that normally I wouldn't write all this code inline, as I firmly believe that inline functions are evil, but for demonstration code I think this makes it more readable. As you can see, we inherit from QMessageBox and from QScriptable. Note the protected inheritance! QScriptable gives us the engine() call we need later on.

The constructor is pretty straight forward - no surprises there!

Then we have a special slot called "qscript_call". This seems to be an undocumented feature in Qt, (try searching for qscript_call on google and you get very few results). Essentially, this slot gets called when our wrapper class is called as a function. I guess this is similar to the meta-method "__call__" in python. All we do in this slot is make a new instance of the wrapper class (remember that our wrapper class is a QMessageBox as well), and return it.

Our wrapper class still isn't available in the scripts however. In order to do that, we need to add this one line of code:


 m_pEngine->globalObject().setProperty("QMessageBox", m_pEngine->newQObject(new Wrapper_QMessageBox, QScriptEngine::AutoOwnership));

This one line adds our wrapper class to the script global object. Once you've done this, you can no create QMessageBox instances from within a script file, like so:


 mb = new QMessageBox();
 mb.text = "Test!";
 mb.exec();

However, there are still a few issues left to resolve:

We can only use the default - empty constructor.
Only properties and slots of the QMessageBox are available from the script. For example, there's no way to set the window title text<> right now. If we could use the overloaded QMessageBox constructor that took the window title as a parameter then we could just specify it at creation time, but we'll need a way to export non-slot methods as well.

Let's tackle these issues one at a time:

Adding Overloaded Constructors:

This one's pretty simple. All you need to do is add another constructor that takes the additional parameters, and passes them up to the QMessageBox class. Then, you overload the qscript_call method in a similar fashion. Here's what my class looks like now:


// wrapper around QMessageBox:
class Wrapper_QMessageBox: public QMessageBox, protected QScriptable
{
 Q_OBJECT
 public:
 
 Wrapper_QMessageBox(QWidget *parent =0)
 : QMessageBox(parent) {}
 
 Wrapper_QMessageBox(Icon icon, const QString & title, const QString & text, StandardButtons buttons = NoButton, QWidget * parent = 0, Qt::WindowFlags f = Qt::Dialog | Qt::MSWindowsFixedSizeDialogHint)
 : QMessageBox(icon,title,text,buttons,parent,f) {}
 
 public slots:
  QScriptValue qscript_call(QWidget *parent = 0)
  {
   QMessageBox * const iface = new Wrapper_QMessageBox(parent);
   return engine()->newQObject(iface, QScriptEngine::AutoOwnership); 
  }
  QScriptValue qscript_call( Icon icon, const QString & title, const QString & text, StandardButtons buttons = NoButton, QWidget * parent = 0, Qt::WindowFlags f = Qt::Dialog | Qt::MSWindowsFixedSizeDialogHint )
  {
   QMessageBox * const iface = new Wrapper_QMessageBox(icon,title,text,buttons,parent,f);
   return engine()->newQObject(iface, QScriptEngine::AutoOwnership);
  }
};

You can now call this new constructor straight from your script file, just as you could earlier!

Exposing Additional Methods:

Finally, we need a way to expose arbitrary methods that are not slots in our base class. This is pretty simple. We make our own method with the same name, and call into the base class method with the parameters passed to us. Consider my wrapper class, now that I have exposed the setWindowTitle method:


// wrapper around QMessageBox:
class Wrapper_QMessageBox: public QMessageBox, protected QScriptable
{
 Q_OBJECT
 public:
 
 Wrapper_QMessageBox(QWidget *parent =0)
 : QMessageBox(parent) {}
 
 Wrapper_QMessageBox(Icon icon, const QString & title, const QString & text, StandardButtons buttons = NoButton, QWidget * parent = 0, Qt::WindowFlags f = Qt::Dialog | Qt::MSWindowsFixedSizeDialogHint)
 : QMessageBox(icon,title,text,buttons,parent,f) {}
 
 public slots:
  QScriptValue qscript_call(QWidget *parent = 0)
  {
   QMessageBox * const iface = new Wrapper_QMessageBox(parent);
   return engine()->newQObject(iface, QScriptEngine::AutoOwnership); 
  }
  QScriptValue qscript_call( Icon icon, const QString & title, const QString & text, StandardButtons buttons = NoButton, QWidget * parent = 0, Qt::WindowFlags f = Qt::Dialog | Qt::MSWindowsFixedSizeDialogHint )
  {
   QMessageBox * const iface = new Wrapper_QMessageBox(icon,title,text,buttons,parent,f);
   return engine()->newQObject(iface, QScriptEngine::AutoOwnership);
  }
  void setWindowTitle ( const QString & title )
  {
   QMessageBox::setWindowTitle(title);
  }
};

Simple!

Conclusion:

Combined with my earlier post, this should be all you need to make a Qt application extensible through ECMAScript files. I'm doing all this work to write a small game, but the techniques covered should work for all types of projects. If / When I find anything that requires updating, I will endeavour to update these posts. Since I'm still learning QtScript myself, I'm sure these pages will be filled with innacuracies.

How to make C++ classes available in QtScript

2008-05-10T04:29:00.005+12:00

It's been a while since I posted here. What have I been doing? Mostly working, and in my spare time trying to get my head around QtScript. What follows is a short introduction into QtScript. I'm sure that there are points of inaccuracy in this post - this is only to be expected, since I'm just starting out.

What I need for my game, is a single C++ class that can defer some of it's processing to a script, thereby changing the behavior of the class. For example, I want a "GameObject" class, that takes a script filename as a constructor parameter, and defers certain parts of the processing to the script. In the case of the game object, I may want to defer the following functionality to a script:

Graphics loading (so different game objects look different).
AI processing.
Generic event handling.

However, not all scripts will do all of the above - some may only customize a very small amount.

The easiest way to do this is to have signals in the C++ class, that the script can choose to connect to (or not, as the case may be). As the C++ class is executed, it can emit these signals, and the corresponding slots in the script file can be called.

The Code

The C++ code is relatively simple. Consider the following header file:


#ifndef TESTSCRIPTOBJECT_H
#define TESTSCRIPTOBJECT_H
//
#include <qobject>
#include <qscriptvalue>
#include <qscriptable>
#include <qscriptengine>
#include <qmessagebox>
//

class QScriptEngine;


//
// Test script object class - used to demonstrate the fundamentals of QtScript.
//
class testScriptObject : public QObject
{
Q_OBJECT
public:
 // ctor for this class - pass in the script engine to bind to.
 testScriptObject( QScriptEngine *pEngine, QObject *parent =0);

 // attach ourselves to a script file - this could be done inside the ctor. I
 // have chosen to use a separate method instead.
 void runScript(const QString &strProgram);
 
 signals:
 // test signal - we can emit this, and have some QtScript code run.
 void signal1();
 
public slots:
 // test slot - just displays a message box. 
 void slot1();
 // second test slot - displays the string in a combo box.
 void displayMsg(QString strMsg);
 
private:
 // store a pointer to the script engine.
 QScriptEngine *m_pEngine;
 
 // store the "this" object, so we can manually call script functions if we need to.
 QScriptValue m_thisObject;
};

This should all be fairly easy stuff. If it's not, you should probably look at the Qt tutorials before going any further.

Before we can use this class in any sensible manner, we need to do two things:

Create a QScriptValue object that represents the "this" pointer. We do this so that we can call a script function, and pass it the C++ class object as "this" (we'll see this later).
Open a script file and execute a "create" function, the contents of which will set up any signal / slot connections we require.

Let's dive into the C++ code, and take a look at the constructor for the above class:


testScriptObject::testScriptObject(  QScriptEngine *pEngine, QObject *parent) 
 : QObject(parent),
 m_pEngine(pEngine)
{
 // create this object in the scripting land:
 m_thisObject = m_pEngine->newQObject(this);
 
}

This is also pretty simple - the only line of any significance is the one where we create "m_thisObject".

Now on to step 2 - running the script file. Let's take a look at the runScript method:


void testScriptObject::runScript(const QString &strAppName)
{
 QFile file(strAppName + ".js");
 
 if (! file.exists())
 {
  QMessageBox::critical(0, "Error", "Could not find program file!");
  return;
 }
 
 if (! file.open(QIODevice::ReadOnly | QIODevice::Text))
 {
  QMessageBox::critical(0, "Error", "Could not open program file!");
  return;
 }
 
 QString strProgram = file.readAll();
 
 // do static check so far of code:
 if (! m_pEngine->canEvaluate(strProgram) )
 {
  QMessageBox::critical(0, "Error", "canEvaluate returned false!");
  return;
 }
 
 // actually do the eval:
 m_pEngine->evaluate(strProgram);
 
 // uncaught exception?
 if (m_pEngine->hasUncaughtException())
 {
  QScriptValue exception = m_pEngine->uncaughtException();
  QMessageBox::critical(0, "Script error", QString("Script threw an uncaught exception: ") + exception.toString());
  return;
 }
 
 QScriptValue createFunc = m_pEngine->evaluate("create");
 
 if (m_pEngine->hasUncaughtException())
 {
  QScriptValue exception = m_pEngine->uncaughtException();
  QMessageBox::critical(0, "Script error", QString("Script threw an uncaught exception while looking for create func: ") + exception.toString());
  return;
 }
 
 if (!createFunc.isFunction())
 {
  QMessageBox::critical(0, "Script Error", "createFunc is not a function!");
 }
 
 createFunc.call(m_thisObject);
 
 if (m_pEngine->hasUncaughtException())
 {
  QScriptValue exception = m_pEngine->uncaughtException();
  QMessageBox::critical(0, "Script error", QString("Script threw an uncaught exception while looking for create func: ") + exception.toString());
  return;
 }
 // now emit our test signal:
 emit signal1();
}

Again, this is all pretty simple stuff. This method does the following:

Looks for, and opens the script file specified.
Does a static check of the code (makes sure that it's syntactically correct, but does not ensure that the script will run without error).
Evaluates the script file.
Retrieves the function named "create" from the script file.
Executes this function, passing our previously created "m_thisObject" as the "this" object for the script to use. This function then binds our signals to slots in the script file.
Finally, we emit our test signal.

Finally, let's look at the ECMAScript file I'm using:



// set up the game object - the 'this' object will be an actual QObject 
// derived class passed in from the application.
function create()
{
 // test 1 - call a slot in the class:
 this.slot1();
 
 this.signal1.connect(this, testSlot);
}

// create our own slot:
function testSlot()
{
 this.displayMsg("Testing testing.. 123");
}

...and that's it! The "create" method will first call the "test2" slot in our C++ class, then connect our test signal to a scripted function. When we emit the signal in our C++ class, the "testSlot" function will be called.

This is just a starting point. The more I use the QtScript module, the more I marvel at the possibilities created with this tool. I shall post follow-up articles with more information and techniques as I see fit. In the meantime, go add scripting extension support to your faviourite project. With tools this easy to use, there's no excuse not to!

Game update

2008-04-27T01:45:00.003+12:00

A few things I should clarify about my earlier post:

I'm writing this for fun. I don't expect this game will come to anything much at all. If it's fun and playable, I might release it and try and get it packaged for a few different distros. My main motivation in writing the game is for me to improve my own programming skills.

I'm using Qt4 and qDevelop, nothing else. Qt4 is simply the best cross-platform C++ library I've ever seen, and qDevelop is a nice cross platform IDE that does everything I want it to.

Right now I have collision detection going, although it needs a few tweaks for fast-moving objects (like bullets). My next step is to investigate The QtScript module. Basically I want to be able to write the AI routines for the game in ECMAScript, so I can change them without having to recompile the game. This should also make the game easily extensible, possibly by people who aren't hard-core programmers.

Will post another video when I get something worth showing!

Pet Project: game

2008-04-21T02:17:00.003+12:00

Yep, I'm writing a small game. I'm usually rather tight-arsed about proper code design before you start writing code, but I've realized that a lot of the time this stops me writing any code at all.

For this project my general methodology is to write whatever comes to mind, and be prepared to throw away code that I think is too crap to last in the final build.

In fact, my design phase has been so minimalistic I don't even have a name for the game. For now, it's just called "game". It's going to be a land-cased top-down 2D shooter, with lots of weapons and cool stuff. Right now it can load a very simple level format from XML; you can control the player using the keyboard "WASD" keys, and fire the players rifle using the mouse. Bullets have collision detection.

Here's an early video that shows the game sans collision detection:

My next step will be to have predefined objects for a level (right now they're all just boxes). I might start with an immobile gun turret - that should let me get some AI going for the enemies, as well as some health stats for the player and enemies.

Eventually I want to make the game easily extensible using QtScript for enemy AI.

Working with Qt4 has made this project an absolute breeze - there's hardly any code in this project! When it gets a few more features I'll upload the source online.

Cheers,!

When source code control goes wrong

2008-04-18T06:42:00.001+12:00

Question: when is source code control not source code control?

Answer: when your development model forces you to have working copies outside the source control environment.

This happened to me recently - I lost alot of work due to a bug in the source code control package we use. I had several weeks worth of changes checked out on my local hard disk. The development model at this company is such that I cannot check in my changes until they are finished and stable. I guess I've known that this is a bad idea from the start, but it took a catastrophic loss of data for me to find out.

So let this be a lesson to all of you - whatever source code control package you use (you DO use one, right?) make sure you're using it properly. That means:

Regular commits (at least daily, but I recommend hourly or even less).
Useful commit messages. If you're committing work often, you'll need to know what you've been working on.
Use branches to separate high-risk code, so you don't pollute the main source tree with your changes.
Keep release code and development code separate, yet easily accessible. Branches are a good way to go here as well.

As far as I'm concerned, branches are absolutely critical to a decent source control environment. Creating a branch should be dead easy. If I can't create a usable branch in less than 10 seconds, then I probably won't bother. Some tools (like vault for example) create branches by copying the part of the source tree you're branching to a new folder with a different name. The problem with this is that it breaks Visual Studio's SCC integration. In fact, *any* embedded reference to the code location within the code repository will be rendered useless for the new branched code. A much better method is to create true parallel branches - either as a separate instance of the repository, or using the same instance with tags.

Linus Torvalds has the right idea in this presentation on git. The things most important to programmers should be dead-easy to do. That's branching, merging, and tracking changes over time.

Twitter: I don't get it

2008-04-11T20:31:00.001+12:00

So what's with this twitter business anyway? Why would I want to have a conversation with someone online? Maybe I'm missing something here, but what's the point?

Having said that, I'd love a silver bullet that makes me rich, popular, and famous - Merlin Mann seems to have seen the darker side to the spree of social networking websites that have graced our browser screens of late. Jeff Atwood asks us "how many online identities do we need?", and I have to agree with him. You may have noticed the LinkedIn link on this page - I use that simply because a lot of my former colleagues are present, and it's a useful tool to keep in touch.

However, I suspect that those exact reasons are at the very heart of most social networking sites. So why are there so many?

Perhaps it's vanity - everyone wants the world to know how many friends they have...

Qt programming contest

2008-04-09T20:22:00.001+12:00

Qt Centre Programming Contest 2008

: collaboration, education, project management, automation, demo, plasmoid and newcomer

I may even enter myself!

Why this website sucks: A rant on poor web design

2008-03-30T06:15:00.004+13:00

I have just had an epiphany of biblical proportions:

Fixed-width websites suck.

Okay, so it's not a huge revelation, but still, I was quite proud of myself. Why is it that website designers think they know how large I want their website to appear on my screen? I have two 20" monitors, and many websites show content in less than half of my browser window.

Any decent website would have a template that showed content at whatever resolution the viewer wanted.

That's why there'll be some changes around here. I'm going to try and design my own blogger template, or at least rip of someone else's good work and call it my own.

Edit:

Round one of changes has been completed. The new theme is based on the stretch-denim blogspot theme, with a few revisions of my own.

Virtualisation under Linux

2008-03-27T09:42:00.001+13:00

I've been doing some Qt development lately - a little cross platform utility that will save me lots of fingerwork when programming. I've found that certain aspects of Qt don't work the same under Windows as they do under Linux. In order to debug these niggly bugs I've begun running windows XP under a virtual machine.

I looked at three different virtualisation projects: bochs, QEMU, and VirtualBox. Of the three, virtualbox really stands out. It's a commercial product that is also released as open source software, and it really shows. The user interface is very similar to Microsoft virtual PC, possibly even a bit better.

It's been a long time since I tried running any virtualisation software under Linux, and I'm pleasantly surprised at the results.

Talkback

2008-03-20T21:37:00.002+13:00

It seems that interesting blog posts come in berths. I wanted to take this opportunity to comment on a few interesting ones I've seen around recently:

Aaron Seigo on Multiscreen X

This is a topic I've been fretting about for a long time - why can't we get multi-screen support done properly? My personal theory is that since we've had multiple virtual desktops for a long time, there has been less need for solid multi-screen support.

The panel problems that Aaron mentions really don't bother me that much. What I really want is a few more window management buttons - for example, one that allows me to move a window to the second monitor, and back again.

Jeff Atwood on Extensions

Jeff argues that many of the extensions currently provided for in firefox should be shipped by default. I can see where he's coming from, but at the same time you must realize that firefox started life as a slimmed down version of the older Mozilla browser. I can remember the days when switching to firefox meant having to wait 10 seconds for the browser to load, instead of 20-30.

Several of the user-comments on that page are very insightful. One chap mentions that perhaps we need a better way of browsing extensions, and grouping extensions together. Also, perhaps we need a firefox installation package that provides a core set of extensions pre-installed?

Of course, we don't want to get back to the mozilla days, so I can understand why firefox is shipped sans extensions.

Holidays

Well, Easter is here - the first holiday I've had since my New Zealand trip. Should be good fun, except the weather promises to be bad.

On Idealism and creating your career

2008-03-16T10:40:00.003+13:00

I enjoy working with open source software - I guess that comes as no surprise to those of you who know me. There are many reasons why I'm drawn to the open source model, including the following:

I like making stuff, and have the skills to do so - It's getting easier too. Application developers are realizing that making it easy for their users to extend and customize their products can only be a good thing. KDE 4.0 does this very well - you can write many simple KDE extensions in a language of your choice. Of course there are more ways to extend an application than by programming - but that's hat I'm good at.
Most of the time, I enjoy the community. Like any community, there are always going to be your garden variety blockheads, who seem to live for the sole purpose of making every one else's lives difficult. The open nature of an open source community makes it harder to deal with these people, but I guess that's the price you pay for freedom. On the other hand, where else can you mingle with thousands of industry experts for free? It's like being at a huge tech conference twenty four hours a day for free!
Open != unprofitable. Many open source projects have gone on to be the basis for a successful business model. Sure, it's harder to make truck loads of cash by treating your customers poorly, but it is possible to grow a successful business by releasing open source software. The list of companies is huge - Trolltech springs to mind - they've just been bought by Nokia for some vast sum of money, so they must be doing something right.
Finally, I enjoy the fact that there are no boundaries. If you have an idea for a piece of software, you can make it. There are no closed protocols to get in the way, there are no commercial pressures forcing you to take shortcuts; you are free to write your software as you wish. If you feel that writing a product that consumes massive amounts of memory and randomly crashes is a good idea - go ahead. The measure of success will be how many users use your software.
Another point here is that this openness and strong competition leads to some very careful planning of software features. Take KDE 4 for example. Some very intelligent people have sat down together and thought about the best new features they need to make KDE even better. Don't believe me? See Aaron Seigio's KDE4 release keynote speech; it'll knock your socks off.

In some ways, that last point leads to a kind of Darwinian evolution amongst software packages. Good packages survive because they're popular, and thus more developers work on them. Bad packages languish and die. Sometimes packages are forked and sometimes packages are merged. This seething "package soup" has given us a very rich mix of packages to choose from. I can name a dozen web browsers, at least fifteen email clients, and twenty text editors off the top of my head. They're all slightly different, but they're all good software. Some might argue that we're spoiled for choice, but that's another blog post for another day!

Working as a volunteer on an open source project takes skill, commitment and determination. There are very few external motivating factors. If the project you're working on doesn't interest you, chances are you won't complete the work. The reward at the end of the tunnel is the gratitude of your fellow developers and users; not to mention some new skills you can take to your next project.

I've been involved in open source software for the last 10 years in one way or another. In that time I've picked up many skills that I can be proud of. Unfortunately, in my professional life, these skills aren't recognized by my peers - and understandably so. I have no formal qualification in the subject area, they've never seen me apply my skills in a practical manner, there may even be a lack of understanding that it's possible to gain new skills outside professional development or formal qualifications.

Which brings me to the point of this post. I want the open attitudes of the open source world to migrate to the commercial software development world. I want to have an "anything is possible" attitude towards our commercial products. We've already seen time and time again how products that started out as garden-shed projects with this open attitude have merged into multi-billion dollar products. Why can't we replicate that in a real business?

Obviously these Utopian ideals need to be tempered with the reality of running a business, but I refuse to believe that the two trains of thought are mutually exclusive. I encourage any of the readers of this blog to try to develop an "anything is possible" attitude towards product development. If you set your mind to achieve greatness, it'll happen. Why settle for anything less?

I realize that this may sound a little naive - but that's the whole point. Naivety isn't something to be ashamed of, that idealism is what makes us great; our ability to see the world as it should be, and strive to meet that distant goal is (as far as I'm concerned) fundamental to what makes us human.

Best Tech Videos

2008-03-13T22:31:00.002+13:00

In an effort to avoid work, I started searching the internet for new sources of entertainment. I stumbled upon Best Tech videos.

There are many many videos for your enjoyment, covering a wide range of topics. Since the OnSoftware Podcast series seems to be slowing, this should keep me amused for a while longer!

Enjoy!

Short Update

2008-03-07T02:07:00.003+13:00

You'll notice that there's a severe lack of posts in the last few weeks; I'm moving house, and it seems to be impossible to get an Internet connection in a timely fashion.

Got lots to post about, so hopefully I'll be back online this weekend.

Stay tuned!

Yes, we DO care!

2008-02-01T09:21:00.001+13:00

Jeff Atwood writes a brilliant blog over at coding horror. My only gripe is that he's a .NET kinda guy - which is fine, most of the time. However, his recent post, entitled "Why Doesn't Anyone Give a Crap About Freedom Zero?" seems a little short sighted. For those of you who have never heard of freedom 0, It's one of the four freedoms that the free software foundation have set out to protect. The FSF define it as:

The freedom to run the program, for any purpose.

I don't have a problem with Jeff's love of .NET and microsoft in general, but when you post a blog with a title like that, it sidelines and marginalises everyone who does care.

Jeff - there are many of us who do care about Freedom 0 - and the other three. Take some time out of your busy schedule to investigate Linux and the BSDs. You'll find a community full of bright, innovative developers who all want to make a better computing platform.

This brings me to my second point. Okay, so this is probably really obvious to the rest of you, but I had a sudden realization the other day. It went something like this:

The reason why there are so many technically brilliant innovations found only in open source platforms (Yes, I genuinely believe that to be true) is that the pressures of software development aren't there. Commercial software vendors are always struggling to maintain a balance between allocating time to develop new features, maintain existing features, test / QA the product, and get it out the door. I don't believe that there's a single software product that was 100% complete when it was shipped. That's the nature of commercial software development. Too often the "right" way of doing things is sacrificed for a cheaper, faster way of doing things.

On the one hand this means that deadlines and schedules are met (everyone gets paid), but on the other hand the software quality is lacking. In an open source project however, there are no commercial pressures at all. Developers are left to their own devices to code what they want. Package maintainers are allowed to choose their own schedule - and who better to choose that balance between release frequency and code quality than the programmers who know the product best?

The more I look into the KDE project the more I realize that I'm right. There are some truly brilliant bits of code in there; It's a pity that they're never appreciated by the general public.

On C++ programming IDEs

2008-01-27T21:25:00.001+13:00

I've been doing a bit of programming work under Linux for the last few days, and I'm very disappointed with the selection of integrated development environments on offer. Read on for my complaints.

First though, a bit of history. I usually write code under Windows for my job. I use Microsoft's visual studio 6. For those of you who haven't tried it, compiling code with the VS6 C++ compiler is a bit like pulling teeth. For example, Microsoft thinks that the following is perfectly valid code:

for (int i = 0; i < 10; i++);
printf("After loop, i = %d", i);

However, The scope of the variable "i" is limited to the contents of the for loop (in this case it's en empty loop), and so shouldn't be available to the printf line. This becomes even more painful when you want multiple for loops within a function, and you want to be able to use the "i" variable for each loop. Under windows, you can do this:

for (int i = 0; i < 10; i++)
{
// do something
}

for (i = 0; i < 10; i++)
{
// do something else
}

Note that I don't need to re-declare "i" in the second loop, since it already exists? If you try and compile this code under a compiler that observes the C++ standard, you'll get compilation errors. So, how do you turn this into cross-compiler code? AFAIK the only way is to use a second variable inside the second for loop, OR to wrap each for loop in it's own additional scope block, like this:

{
for (int i = 0; i < 10; i++)
{
// do something
}
}

{
for (int i = 0; i < 10; i++)
{
// do something else
}
}

However, I digress from the true subject of this post. For all it's compiler digressions, the user interface actually isn't that bad. Sure, the toolbars seem to move to random positions on your screen every time you debug a project. Sure, you can't use it on a second screen because all the tooltips draw themselves on the first screen, and yes, if you want decent code completion you need to use a plugin like visual assist X, and no, there's no code folding either. But apart from all that, the UI is just right. It's not overcomplicated, it's easy to use.... simple!

So, let's look at KDevelop, KDE development environment. I have several problems with it:

Code completion requires the user to jump through waaaay too many hoops. As far as I'm concerned it should be turned on by default, or, if that ruffles too many feathers, have one checkbox to turn it on. I shouldn't have to root around in the KDevelop settings, and project settings, add the library include directories I want to use for the project, exit KDevelop, install ctags, re-load project, tweak settings, and then find that code completion is actually not that brilliant.
The User interface is way too cluttered. Many of the menus are so full of entries that they cascade off the bottom of my screen. There are so many toolbars and sidebars that I can barely see my work. Many of the sidebars don't even work properly! The documentation sidebar seems particularly useless. I could probably find out what I have to do to get it going, but my point is that it should work out of the box! When I fire up KDevelop, I want to write some code, not mess about with the environment.

The best development environment should be completely transparent to the programmer. OK, so none of the IDEs I've used to date achieve this, but a man can dream, right?

In the mean time, I'm going back to my old IDE: Kate, with the scons build system, activated from the console, and gdb as a debugger. What more could you want?

Maintaining Binary Compatability

2008-01-22T10:07:00.002+13:00

It seems to be common practice for software development companies to patch individual parts of a released product. Usually this means distributing a second installer that creates new shared object (.so or .dll) files, so the next time the application in question runs it loads the new object files, and thus runs the new code.

In practice this is a great idea - it means that companies don't need to re-release and re-ship the entire product. Unfortunately, it's not always that easy. The biggest problem is that the new libraries must be binary compatible with the old ones. Essentially this means making sure that all objects within the library are the same size as they were, and that things like vtables haven't changed.

For a while now I've been looking around for a definitive list of guidelines to help me maintain binary compatible libraries. I finally found it on the KDE website.

Behold: Binary Compatible Issues with C++

Anyway, I thought that might be useful to some of you. Enjoy!

New Tools!

2008-01-21T01:32:00.001+13:00

I've started to use scribefire to publish posts on this blog. The built-in blogspot editor was just too clunky. Ideally I'd like to use a separate KDE application, but the ones available simply aren't good enough for me to use yet.

Speaking of KDE, I'm currently downloading the KDE sources from subversion - I'll see what small contributions I can make.

Finally - I know this is old news, but if you haven't already, head over to the GIMP website, and check out gimp 2.4. It's been a long time coming, but it was worth the wait. The new version contains (amongst other things) a whole raft of bug fixes, improved icons, scalable brushes, and (my personal favorite) a new and improved selection tool!

post-vacation blues.

2008-01-19T21:47:00.000+13:00

Well, I'm back from my holiday, with a slight tan and some great photos. Works has been busier than usual, so I'm struggling to find spare time to domuch at all.

My next hobby project will be to build my own ADSL / Ethernet / Wireless router box. I'm planning on using a Soekris net 4501 motherboard running a cut down version of Debian Linux. I'll update the blog when I get the parts, and I plan on writing a short HOWTO document which will include selecting the hardware, putting it all together, and the software as well.

I've added a selecton of photos from New Zealand to the main page - these haven't been edited in any way - yes, the country really does look like that!

Until next time!

Holidays and Higher Standards

2007-12-18T22:30:00.000+13:00

In the last few weeks, Jeff Atwood has posted a few articles about common problems in code. The one that grabbed my attention was about ASCII vs. Alphabetical sorting. I couldn't agreee more with the post. However, I think it's slightly unfair that the programmer cops the flack for these issues.

I know, that sounds odd. We write the code, why shouldn't we be responsible for it? Personally, I think that a lot of poor quality code is written in places where there is no higher standard. Managers accept code that achieves 90% of the initial specification, and thus bad code is born.

Programmers need to have a bit more pride in their work! Why can't we peer review other's code, even if it's not in a formal manner. What's wrong with striving to better your coding skills? Employers can help too - find the programmers who are serious about their work and offer to send them on a usability course. You will be rewarded with cleaner user interfaces, and happier programmers. Promote programmers who write good code - let THEM shape the programming culture in your business, not the programmers who have been there the longest.

On that note, I leave you, dear reader. I'm on holiday for three weeks in New Zealand. I'll try and take some photos and upload them when I get a chance.

Till we meet again!

General update

2007-12-03T01:38:00.000+13:00

After spending four days in France, I have a newfound respect for anyone who lives or works in a country where their language is not spoken. The French are certainly not the most forgiving when it comes to people who don't speak their language.

In other news, I'm starting a new project to build a better build script for my work's source tree. It's kind of like scons, but much much simpler. Should be interesting to see what it's like when it's finished.

I'm still thinking about ideaforge... I really think it needs to be done. I wonder who can provide some insight on the issue...

Turning ideas into applications

2007-11-28T07:06:00.000+13:00

If you're anything like me you'll frequently come up with ideas for neat applications. For me, turning those ideas into code is the challenge. It's not that I'm incapable of writing code - I have more than enough experience to write simple applications. The problem is that I lack the enthusiasm and energy to complete my projects.

Looking back over the projects I have completed, I notice a pattern. In order for me to complete a project, one of two criteria must be present:

I need to be paid. Money is a great incentive. Think this is shalow? you're probably right.
I need to be working with other, like minded individuals. There's nothing more rewarding than working with a bunch of intelligent people who are as excited about the product as I am.

For commercial projects, the former requirement is enough to get me to do my work. For open source projects however that is a luxury don't have.

So, getting back to the original problem - how do I turn a half baked idea for an application into an open source project with 2+ developers? Traditionally the process has been something like this:

Have brilliant mind-blowing Earth-shattering revolutionary idea.
Start writing code.
When code gets slightly usable, create a sourceforge project and advertise project page like crazy.
Hope that some like minded developer notices it and wants to join in.

There are several problems with this approach. First, sourceforge is littered with projects that have 0% activity. These ghost projects have long since been abandoned by all the developers (I swear they're not all mine!).
Second, you only have a chance of attracting new developers to your project after you've written a good chunk of the code. This forces new developers to learn the code that has already been written, and prevents them from offering any input as to programming style, programming language, libraries, code organization, feature list development strategies etc. etc. Personally, I think that one of the best parts of working on an open source project is having the opportunity to makes these kinds of decisions.

It seems to me that what we need is an ideas forge. Imagine a place like sourceforge, but for ideas. There would be facilities for advertising ideas, giving feedback on existing ideas, hosting design documents, holding discussions etc.

Unfortunately, ideaforge is an... idea.. Now all I need are some talented programmers to help me create it....

KDE 3.X: The good, the bad...

2007-11-16T06:32:00.000+13:00

I Love KDE. With the final KDE4 release just around the corner, I thought it'd be good to note down some of the best and worst features in the 3.X series.

Why KDE?

I use KDE exclusively on all my Linux boxes. Why? It just... feels better. I've tried several alternatives - XFCE (which I like very much, but it lacks some of the features I need), WindowMaker, Fluxbox (great on a low-end PC), Enlightenment (supposedly the nicest looking window manager for Linux), and Gnome. Gnome is, of course the main competitor for number of users. It's the default window manager for the Ubuntu project.

With so many other choices, why choose KDE? There are two main reasons:

It is incredibly configurable. There are so many options I could spend a whole day setting up a new install. Some people say that this is a bad thing, and it certainly is for a novice user. Who wants to be bombarded with configuration screens? However, I consider myself a power user and enjoy the added flexibility.
KDE features brilliant integration between it's apps. Thanks to the KPart technology (Think OLE done right for Linux), it's very easy (from a programming perspective) to embed one application ( or "KPart" inside another.

The Good:

As far as I'm concerned, the best featured of the KDE 3.x series are (in no particular order):

Window Management. I personally Love the "Keep Above Others" option - it allows you to keep a window above all other windows on your desktop. Some windows applications can do this, but I've found that they don't play nice with the Alt-Tab task switching when they do.

In KDE, this feature is part of the window manager. Application programmers get it for free! You can also do the reverse ("Keep Below Others"), or enable full screen mode (no prizes for guessing what that does!).
Another useful feature is te ability to customize the behaivour of any window - either just once, or every time that window is created. For example, I may want my IRC chat client to always start at a specific place on the screen, have it stuck to the bottom of the window stack, and disable thew window decorations. With KDE, this is all taken care of by the window manager. Neat huh? but we're just getting started...
Kate is a brilliant text editor for KDE. I use it for all my programming (well, sometimes I'll revert back to vim). Out of the box it supports syntax highlighting for hundreds of languages, code folding, and a whole lot more. you can download plugins to extend the editor too. One of the main reasons I use it above other text editors is the built in Konsole (thanks to KPart). This is so increadibly useful i can't imagine life without it.
Other KDE applications that I use every day and love include Konversation (IRC client), Konsole (guess), and Amarok (best music player you ever did see!)

I'm aware that other window managers may have similar features, especially the larger ones, like Gnome.

The Bad:

Nothing is perfect, and KDE is no exception. Here are a few of the things that I don't like about KDE.

Konqueror. Konqueror is KDEs default web browser, file manager, and a whole lot more. My main gripe is that it's trying to do too much at once. When you think about it, browsing the web and browsing your hard disk are two very different tasks. Konqueror tries to achieve this balancing act by working in "modes". Sometimes it looks like a web browser, and some times it looks like a traditional split-pane disk browser.

The web browsing features are okay (I especially like the fact that typing "gg: foo" in the address bar searches google for the word "foo"), but why try and compete with Mozilla firefox? The first thing I do on a new KDE installation is install firefox and remove all the konqueror shortcuts. Firefox is already well known amongst computer users. Why not put more energy into integrating firefox with KDE?

The disk browsing side of konqueror is rather tragic. My main gripe is that by default, clicking on something opens it. A single click! Users migrating from windows will find this very confusing. If you just want to select something you have to hold down the Ctrl button.

It seems that in KDE4 the disk browser part of konqueror is being split out into a separate app called Dolphin. I can't wait! Now if we could just ditch the rest of it...
Lack of Xinerama support. I run a dual (and sometimes triple) head setup at home. KDE has very limited support for Xinerama. For example, I'd like a window decoration button that lets be move an application to the next / last / other screen, even if it's maximised. Ultramon for windows gives me this, and it's very handy. Several applications will always display their "fullscreen" mode on the first display only, which is a real pain (especially since my first screen is my laptop).
The K menu needs a lot of work. Mine tends to get cluttered very easily. It'd be nice to have some easy way to organise applications into frequently used groups.

All in all, I'm not complaining. If I had more time I'd try and improve KDE myself, but I'm rushed off my feet as it is!

Book Review: Begining Game Development with Python and Pygame

2007-11-12T03:21:00.001+13:00

I love Python. I Love Pygame, and I love programming. What could be better than a book that combines all three?

These were the excited thoughts that were racing though my brain as I was looking for a suitable money sink on amazon. The book's subtitle is "From Novice to professional", and I wasn't expecting much. You see I have a tendency to buy books that I don't really need. I already know a fair amount about programming with Python, and I've used the Pygame library on numerous occaisons. So why buy the book? I was hoping that the book would stimulate me to finish one of the hundreds of half-completed game projects on my hard disk.

The book has 12 chapters in total. The first three are a gentle introduction to the python programming language and the pyGame module. The next four chapters are the meat of the pyGame related matter. Most of the pygame modules are covered here. Finally, there are four chapters covering 3D aspects and OpenGL.

As you may already have guessed, I'm not overly impressed with this book. My main gripe is that the content doesn't reflect the book title. For example, Apress (the publisher) have included a little diagram on the back of the book (I appologise for the poor image quality):

To me this indicates that the book in question assumes a working knowledge of python. Why then the four chapters introducing the programming language? Similarly, the last four chapters of the book are about OpenGL and 3D game programming, which bear very little relevance to PyGame, which is primarily concerned with 2D applications. The books chapters also seem a little jumbled together. For example, there is a chapter on playing sounds in the middle of the 3D chapters... where did that come from?

The chapters that were on topic were pretty mundane - the reader might have just browsed through the superb PyGame documentation.

Overall, this book probably isn't worth buying if you want to learn how to use Pygame, just read the online documentation. If you want to learn Python or OpenGL, there are better books out there. This is a book with great potential. If the author had stuck to the subject matter this book would have been a lot better. A few constructive criticisms then:

Lose the Python into and the OpenGL stuff. People will buy this book because it has the word "PyGame" in it. We don't care about OpenGL, and we already know how to program in python!
Make the example a little more meaty. At the moment almost all the examples demonstrate simple pieces of the pygame library. Some examples that demonstrate how these pieces are put together to form a playable game would be nice!

I did actually enjoy reading the book, it wasn't a complete waste of money. I'd give it 5/10. It was enjoyable to read, and did contain some useful information, even if that information was present in a better form on the web.

Now, If I could only get around to finishing that game.....

Filthy Lucre in the United Kingdom

2007-11-05T06:25:00.000+13:00

As I sat on a train in Waterloo train station today I noticed that two large credit card companies were touting the end of cash as we know it. The first is the mastercard "CASH" billboards (sorry, I couldn't find a photo online). The second is VISAs "paywave" system.

I would like to take this opportunity to point out to both credit card companies that cash is not dead. The main reason is that card machines are still not universal. I come from a country where every store, no matter how small accepts bank cards. In the UK however, it seems that only larger stores bother with electronic bank cards. I suspect that the banks are behind this.

Let's not introduce yet another form of payment before we've made the current forms universally available! Drop bank charges for companies wanting to accept credit cards (after all, it must result in fewer bank tellers handling cash, which can only be a good thing, right?), and lets make electronic purchasing
universal!

Programming without Requirements?

2007-11-01T08:13:00.000+13:00

I had the opportunity to catch up with some old college friends of mine recently. We all graduated together, and we're all working as programmers in a variety of industries around the world. I work in broadcast automation, another friend works in publishing, another in engineering.

Eventually we began talking about our jobs. What struck me was that none of us are happy with the way our programming is being directed. Let me be a little more clear...

In college we were all taught that requirements determination is a fundamental step in producing quality software. This makes sense - after all, how can you write good software if you don't know what it needs to do before you start writing it?

Unfortunately, none of my friends feel that requirements determination is given the focus it deserves. It is, of course entirely possible that we were unlucky; three is a very small sample size to make sweeping generalizations about the entire programming community. However, I'm going to do just that!

All three of us had been in a situation where we were being asked to program something without having a very good idea of what the required outcome was. As it turns out, I am in this situation right now (Actually, I'm writing this blog entry as a venting mechanism so I can sleep tonight). I'm being asked to write a plug-in module that will take me at least a month of solid programming. What does it do? I wish I knew!

Don't get me wrong - I have a rough idea of what it needs to do. However, I have no formal requirements, no use cases, no user stories, no access to the target environment or system, no protocol document, and no access to anyone who knows any more than I do. Frustrating? you bet.

I understand that in a project-driven environment sometimes some of the requirements may change - I accept that. However, I really think that there needs to be more attention paid to the period of time before any code is written, so that hopefully programmers can spend less time writing code, less time fixing code that was poorly written, and more time drinking beer!

If anyone has similar stories, or can tell me that I'm being naive, I'd love to hear them (for the record, I don't think that naivety is such a bad thing - sometimes it takes a little innocence to spark changes for the better).

*buntu rant

2007-10-27T07:58:00.000+13:00

I've noticed several negative news stories regarding the latest (7.10) release of the Ubuntu Linux distribution from Canonical. I feel I owe it to the good people working on this fine operating system to defend them on a few points.

First, I want to comment about stories such as this one that complain about the bugs found in Ubuntu after it's release. The article talks about the broken IPv6 / DHCP implementation. To start with, the article seems like it was written on a whim after a single reader wrote in to complain. I quote:

Our reader told us that Gutsy Gibbon's internet access "whether by wireless; ethernet or USB DSL modem is either impossible without some deft work at the CLI [Command Line Interface] or is incredibly slow (mostly from delay in resolving DNS)".

Hmmm... Perhaps in the future they should stick to reporting only what they have personally researched? And the poor journalism doesn't stop there - they then use a quote from Willie Faler's blog completely out of context; to quote the article again:

While blogger Wille Faler, who pointed out that many routers do not support IPv6, has offered a possible "work-around" for a problem he described as being a "big flaw in Linux's handling of DNS-servers".

However, if you actually read the article on his blog, you'll see that he wrote

Ok, I’ll be the first one to admit that my dismissal of Ubuntu as, shall we say “not too good” was a bit premature. I eventually found the cause and fix to my network problem. It is not a fix for what I consider a big flaw in Linux’s handling of DNS-servers, but it is a workaround that should be sufficient for most people, including those that spend considerable time on the go, like me.

What on earth is happening at The Register?

Anyway, regarding the actual release... I have a deep sympathy for anyone working on the Ubuntu project, volunteer or otherwise. I write code for a largish sized application suite, and I know how hard it is to test every possible permutation of software combinations - I can't imagine how hard it must be to test an operating system for a wide variety of hardware. I suggest that the author of the offending article spend a few months fixing bugs for any large software project; perhaps he will gain a better understanding for the issue.

I would like to take this opportunity to remind people that Ubuntu relies, to a certain extent on community support. I encourage anyone who wants to help out to download the beta releases and release candidates and report these bugs as soon as they appear. That way, we can hopefully reduce the number of such incidents along the way.

Incidentally, I stumbled upon this blog entry by Matt Loney - he expresses my thoughts on the Microsoft Vista operating system better than I ever could. He writes:

Why did Microsoft ignore the first rule of usability and ditch all familiar methods of doing stuff that I'd spent 15 years getting used to?

I couldn't agree more! Further, in the XP to Vista upgrade Microsoft deprecated many of it's APIs; this creates a whole lot of work for application authors. I understand that APIs need to be updated as the technology improves, but many of the libraries that were removed were still functioning and widely used. Why remove them? The cynic in me suggests that there must be a monetary motive at play here..

But I digress; this post was supposed to be about Ubuntu! If you haven't tried it already, download the new 7.10 release of one of the Ubuntu projects!

A new beginning

2007-10-27T07:05:00.000+13:00

Well, this is the first post for the new-and-improved tech-foo blog. I used to maintain a blog-like website on my own web server back home, but the hard disk crashed and burned. For a long time I couldn't be bothered keeping a blog, but this post from Coding Horror convinced me otherwise. Hell - even if no one reads this it'll help me offload after work. If this blog seems more like a therapy session than an actual tech blog you know why!

Hopefully I'll have the mental discipline to keep this blog going. So many of my friends cite lack of spare time as the main reason why their blogs died. Personally I think that's a bit of a weak excuse. Please remind me of that when I stop updating this blog.

Anyway, welcome to the blog, please feel free to leave your mark in the comments section!