Console Hacking

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

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:

1. Small & Fast. I'm not after a massive clunky IDE, just an editor with enough smarts to make editing multiple python files easier.
2. Sensible syntax highlighting.
3. Understands python indentation, PEP8 style. Specifically, indents with 4 spaces, backspace key can be used to unindent.
4. 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:

1. 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.
2. 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.
3. 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?
4. Geany. Looks promising, but no integration into lint checkers.
5. 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:

1. Eclipse & pydev. Eclipse is a huge, hulking beast. I want a small, fast, lean editor, not an IDE.
2. Emacs. Can't be bothered learning another editor. Doesn't look that much different to vim, so what's the point in learning both?
3. 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

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:

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:

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

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

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:

1. 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...
   
   
2. 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"
   
   
3. 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

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.