Live Forever!

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?

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:
  1. 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.

  2. 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


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

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

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

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

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

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

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 Sad

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

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

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!

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.:

  1. 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.

  2. 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


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:

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?