I’ve been browsing around the Django site for a few weeks and just discovered the django resources page. It’s a collection of heaps of really really good links to unofficial stuff out on the web.

It’s kinda hidden so this is just a little pointer.

Rory is talking about user experience which is a subject I find pretty interesting.

I was just thinking about sites that I use frequently. In most cases I’m happy with the user experience; I get the feeling I have a fairly low tolerance for bad design.

My other feeling is that the usability-functionality trade off is just the easiest excuse to make where there’s a lack of features or poor usability.

In business software, the customer wants the biggest bang for buck so they’ll demand every feature they can think of. In consumer software, all other things being equal, the most feature-rich application will sell more units.

In both cases I think we need to accept it and get focussed on making the desired feature-set work. If the functionality doesn’t go into 1.0, it’ll need to be there eventually. By leaving it out in the first instance it becomes more difficult to include in a way that makes sense later on.

I think the trend over the past 2-3 years has been to roll out features asap and tweak the user experience afterwards. Sites like Flickr and to a slightly lesser degree Last.fm spring to mind.

When it works, it works well.

Since the beginning of the year I’ve been doing a lot less coding at work. The result of taking up a team lead role.

It’s going fairly well and less time spent developing at work definitely has it’s advantages.

It means I start to get that desire to cut some code in my spare time. In the last month I’ve reacquainted myself with python and thrown together a g-maps mash-up built with the Django Framework. I’ve brought in Dojo for JavaScript and it’s all buzzing nicely.

The app I have is just a simple proof of concept at the moment. Before I go too far I want to get my head around some of the unit testing/tdd tools for Python and JavaScript. I’ve seen a few around the place while googling but I’d love to hear any recommendations.

More updates on tdd with python to come.

I’m still tidying up after the move. I’ve used a couple plug-ins and guides that are worth mentioning because they’ve helped a lot and deserve the plug.

I’ve created a FeedBurner account and wired up the RSS feed for this blog. There’s a neat WordPress plug-in that guides you through the steps to configure things on the FeedBurner side as well as auto-magically redirecting requests to the standard WordPress feed url. Subscribing to the URL behind the Entries (RSS) link at the bottom of the page should work a treat.

I also followed a few simple steps to get client-side redirects going on the old Blogger site. Somebody commenting on the instructions and said Google has flagged their blog as a spam-blog. Hopefully this won’t be a problem for me.

Last night I got my act together and purchased some hosting and a domain name.

Tonight I’ve installed WordPress and grabbed a simple but effective plug-in, aptly named Import New Blogger To WordPress, to drag everything out of my old blog at Blogger.

Now I just have to wait for the DNSs of the world to do their thing before dwightgunning.com comes online. I’ll have some more about my host, TextDrive and the blog setup/move when things come online.

I’m in the process of moving this well and truly neglected blog over to a new server and some new, yet to be decided, blogging software.

The rationale is that having my own hosting motivate me to post more often. It’ll also give me an outlet to let loose the various bits and pieces of prototype and sample apps I’ve created over the years. I keep telling people I’m a web developer but it seems rather fake without my own website. It should be some fun too.

No doubt the minuscule readership I once enjoyed will have either removed me from their aggregators or forgotten the url entirely. Hopefully some more frequent posting about interesting stuff can bring a few people back and entice a few newcomers.

Time will tell.

A friend just del.icio.us‘d me this treat of an article. It lays out an argument that Design Patterns are really just evidences of language weaknesses.

This really Makes Sense to me. I dig that I’ve never really considered this in the ever before. It’s a different perspective but almost kind of obvious.

That’s not to say I’m jumping off the patterns bandwagon. Haha no way! The thing to remember is that it takes years for languages to go from concept to widespread use. Once a language gains momentum, it’s going to be used heavily and for a long time into the future. Minor flaws, quirks or missing language features that weren’t recognised before the 1.0 release won’t stop a language in its tracks.

Also, as mainstream languages evolve and are supersceded, the most valuable patterns will continue to be absorbed into the language. Over time, the patterns that we use most commonly are more complex and probably less “general” in both explanation and solution. This makes them more difficult to roll into a language and become transperant to the developer.

I wonder how many patterns from GoF or PEAA could go easily into a next-gen Java/C# or Python/Ruby?

Sam Gentile has some pretty interesting things to say in his post Being an Agile Architect.

Lots of things are popping in and out of my head about this… too tired to write anything constructive or thought-provoking. Maybe another time.

I just read Jamie Zawinski’s open letter of resignation from Mozilla.

It’s an interesting and quite a heartfelt piece. DisclosureI may be seeing it that way because I was always a bit of a netscape fanboy. Taking out the tech references to Netscape and the early days of the web, I found it to be a very honest description of the inner torment and self-doubt one can go through when deciding whether or not to continue on with something they’ve been super-commited to for a long time.

A couple weeks back, Eugenio Pace posted a piece about the direction Microsoft’s Patterns and Practices group are planning to take with the UI Process application block.

There’s not a lot of meat in the article, it seems they’re looking to get feedback from implementers and prioritise requests at this point. What’s interesting is some of comments outlining the good and bad of the UIPAB from people who have obviously spent a lot of time with UIP.

Extra: GotDotNet code gallery for UIP.