On Saturday, I'm heading off to San Francisco to attend Google I/O and also spend some time with my colleagues at SynthaSite in our US office.  Of most interest at the conference (at least in my personal capacity) is Google App Engine, but pretty much everything sounds interesting (with GWT being the big exception), and I can just imagine that making the decisions on what sessions to attend will be hard to do.  (And, you know, I guess I'm supposed to keep an eye out for things that might be useful to the company, or something...)

Over the weekend, I'll hopefully be heading to Sebastopol (in California Wine Country) for the Pylons/WSGI Sprint being held at O'Reilly Media's headquarters there.  There's two days of sprints, and I'm hoping to be there for most of both days - but it depends on travel arrangements.  If I get the time, I hope I can pop out and see a bit of the surrounding country and maybe one or two of those "places of interest".

In between the gatherings and travel, and before I head back, I'll spend time at the SynthaSite offices, doing what I'd generally be doing in Cape Town, but with better connectivity and less rainy cold winter.

If you want to catch me while I'm in San Francisco (or in London for the half-day I'll be there on the trip back) send me an email or leave a comment.

When I started at SynthaSite and returned to doing some sysadmin-related work I discovered BackupPC and rdiff-backup, and I offered to give a talk at CLUG.  For my sins, I'm talking tomorrow from 18:30 onwards at the UCT Chemical Engineering Lecture Theatre.  There will be the usual post-CLUG dinner for anyone who wants to continue chatting after the talk.

Despite recovering from burn-out and malaria from previous years, 2007 turned out rather well.  I suspect I learned a lot more in 2007 than I have since the skipping lectures in university to hack on things all day.  And, finally, I get what this "experience" thing is about - it takes a while to have a few lessons sink in.

One big lesson, which I learned early on in the year, is how so much in the software development process needs to be about keeping everyone honest.

The programming stage introduces a level of honesty not enforced in earlier stages.  No longer can one hand-wave over how to achieve something, and there's nobody lower down the chain to delegate decisions to.

The most detrimental mistakes in the programming stage of a project are those that stem from ambiguity in the specification of the work to be done.  This is made even worse if the developers are not given the overarching vision and operating parameters of the project - so that they have a better than average chance to realise when an ambiguity actually arises - it'll just feel wrong.

If you've not managed to be honest in your previous stages in the development process, the programming stage is the most morbid phase for everyone.  For those involved in the earlier stages of a project, all they hear is that they've not done their job correctly.  (But, more realistically, I imagine they just think they have bad programmers.  It's amazing how easy it is to just blame it on the programmers for not "realising the vision" or not "knowing how to overcome technical difficulties" or just "being crybabies".)

For all employees, assuming you've not screwed up and not hired people who are good at their job or at least who are enthusiastic about doing their job well, you should practise small government.  Let the default position be that your employees should do their job with a minimum of overhead, with intervention only when justified.

If you want to make someone happy, make it possible for them to do their job the way they want to do them - for a lot of people, that means doing it properly.  Take them seriously when they talk.  If they complain about the light levels where they work, don't simply lament the situation - do something about it.  If they express disinterest in something, try find a way for them to avoid it.  If they think a particular book would be useful, buy it.  Be the facilitator of their success, the filter of outside forces, and the deliverer of praise.  Sure, you can't accommodate your employees every time, but make sure they think that you're doing what you can to avoid the company making their life difficult.

I contemplated what success is, especially in terms of technology within business.  Basically:

Success can't be measured only by what you have achieved - the resources, the accolades, and the good will.  More important than those, it should be measured also by what you can achieve from this point on.

I also became a lot more elitist, and decided that the IT industry in South Africa (and I'm sure elsewhere) are the major cause of the problems finding good IT staff - because they hire by quantity, not by quality.

The reason there are fifteen billion other graduates is because the companies are asking for quantity of staff, not quality of them.  People see lots of jobs open, and so decide to go "into IT".  Those people who go "into IT" because of the available jobs are just not worth as much as those actually interested in the particular subject.  10 low-experience programmers earning R5k a month (take home) aren't nearly as valuable as 2 higher-experience programmers earning R25k a month (take home), and the 10 low-experience programmers also cost more because they use more desk space, more parking bays, and so forth.

That's bad enough, of course, but now they're calling IT graduates lazy, because the average IT graduate probably is lazy, because the average IT graduate is in the wrong field.  If you want someone who isn't lazy, don't ask for 10 graduates - ask for 2 higher-experience people.

After a bit of a break, I started thinking more about project roles, and about some of the things I've got wrong in previous projects, and about non-granted and granted power in projects.

To me, it seems the project leader is the person who lives the project - the one who has the clearest idea of what the vision of the project is (and probably the goals), and who keeps this in mind in approaching every decision that is made.  The leader is the person who cares the most about the project, and who seems to make the most cogent arguments about the project as a whole ("Which feature should we drop?", "How do we best fulfil the spec in this case?", and so forth), and to whom these questions tend to become asked of first.

The last third of the year was dominated by thoughts of StarCamp.  Growing the pool has become a passion of mine - because I think there's a tipping point around the corner for South Africa and especially Cape Town in terms of technology innovation, and it needs a bit of help to come sooner.  It needs for people who are interested in technology innovation to know of each other, so that they can team up, and so that they can be counted.

Growing the pool is making new connections, bringing new people into the community, providing new people to learn from and new opportunities for work or play.  It isn't necessarily about bringing new people into the field (but it is a by-product) so much as it is about making everyone in the field more aware of each other.

...

Nobody is going to put on fancy conferences like SXSW, LugRadio Live, OSCON, Emerging Technology Conference, or Ubuntu Live, for us in South Africa until we show that there are enough people for such a thing.  And who wants somebody else's formula anyway? 

That theme continued when I thought on what made BarCamp Cape Town in 2006 so special, and realised why it needed to be a meeting of minds from all around technology innovation - not just geeks, but all the other people who need to be interested in the field and involved for stuff to happen.

One things that struck me about BarCamp Cape Town was the breadth of those who came - anything from hard-core C programmers through the Python/Ruby fanboys to more run-of-the-mill PHP programmers to those who couldn't program at all as well.  Those who work in marketing to those interested in it to those who find the entire field a bit distasteful.  Businessowners to wannabe-entrepreneurs to those who'd just like to code and have pizza slid under the door every evening.  It was a place to meet new people in your area of interest - existing groups weren't really growing the pool, and also a place for inter-pool connections to be formed.

Can't wait to see how 2008 unfolds... 

Last Wednesday was my last day at CareerJunction (well, this time around).  After some initial issues (mostly to do with culture), I'd started to settle in, I got my team a quiet environment, and my team was hitting milestones and generally impressing everyone.

So, why leave?

Well, I'd decided to stay on at CJ for a bit, while waiting to see if other options would pan out.  I'd put bits of my life on hold, since there's little point to finding a new flat or buying a new vacuum cleaner if you might be leaving the country in a few weeks.

Then, I got a phone call from Synthasite, saying that they'd like to have a chat with me.  So, I went past their offices, chatted to them for a bit, got really excited about what they had done and what they were planning on doing, realised that they were wanting me to work there, told them that I might not be around long since I was waiting on those options, and they said they'd take the risk.  Which either meant they were truly confident of their ability to convince me to stay, or didn't think I was good enough to have the other stuff come through.  But I gave them the benefit of the doubt.  And then I took the weekend to think about it, and decided to give it a go.

Fast forward a month: Day 3 of new employment being the launch of the Synthasite beta (more from boss-man Vinny Lingham in his announcement), and much watching of Munin graphs to see how well we're handling the load.

After much poking, cajoling, and downright finger pointing and laughing by Bryn and a bunch of other "friends", I now have Gibe, the little project saving my sanity from the tedium of burn-out and under-stimulation, in a publically accessible place for more people to do more finger pointing and laughing.

Gibe is just your standard web log software - people can log in and add posts, other people can read the posts and make comments on them, and there's anti-spam (using akismet) and there's also a bit of a beginnings of a plugin architecture there for people who want to expand it beyond what it does now.

Oh dear, I'm "blogging about blogging" again.  I apologise in advance.  And although I know it's silly to talk about "true blogs", I'm going to do it anyway.  More apologies. 

The "technology" section of Amatomu (maybe I should suggest mod_rewrite to them for prettier URLs...) is starting to get a bit crowded.  If it isn't gadgets, it's games.  Both of which I think should be considered "lifestyle" more than "technology".  Sure, there's the occasional useful bit of technical information about the gadgets or games (or their platforms), but the primary point of interest on those sites is the gadget or game, which while made from technology, is mostly about the experience of owning it or playing it.

So far, I've been looking at modifying existing pages in Gibe (my still as-yet-unreleased TurboGears blog application) - adding widgets to post pages, dynamically adding the comment field and handling it for different comment formats, and adding additional fields at blog entry create/edit-time and handling these fields to add tagging (or whatever).  Adding new pages (or replacing the default ones) is pretty much necessary - for example, to add a page where there is a list of all pages with a particular tag.

I use Routes for dispatching incoming URLs to functions in Gibe.  It's not the default dispatcher in TurboGears, but it's pretty easy to set up (there's a TurboGears/Routes integration recipe on the TurboGears wiki).

Why go through the bother?

It makes adding new pages easy - no matter how complicated the URL structure is and where the dynamic portions are.  It also makes it easy to pass through the dynamic portions, and also to pass through defaults if the dynamic portions don't exist.   The killer function is named routes, which allows me to look up where something is (ie, generate the URL for it), and not hard-code the link to where the page is.  That means that I can totally change the URL structure of the site without changing any code.

In terms of dynamicism, the worst cases I've explained so far in Gibe are the little comment format hack to allow the use of Postmarkup instead of HTML in comments, and the adding of little trivial plugins to add visual widgets at the top and bottom of blog entries.  Certainly not rocket science.  And, well, neither is this...

My next task was to look at how one could add additional fields to the blog entry create/edit screen - to allow plugins to ask for additional information like tags, geographical location, your mood, what you're currently listening to, and other vain things that nobody really cares about (I mean, it's a blog, it's not like it's useful...).

I used tags as my test case, since that is at least something I can see some value in, and it's something that's already around except for the actual entry of the tags.  Until now, I've been manually typing in things like:

INSERT INTO post_tag
    SELECT 625 AS post_id, tag_id FROM tag
        WHERE name IN
            ('gibe', 'python', 'code','amatomu',
            'blogs','me','tgsociable');

The last time I was talking code (I mean, besides the little example usage snippet when I was announcing TGOpenIDLogin, in between my reporting back about the GeekDinner, the Western Cape Linux User Group  meeting, the Cape Town Python User Group meeting, and so forth), I was showing how I converted the Wordpress Sociable plugin to a TurboGears widget (innovatively named TGSociable).

The ultimate purpose of this was to make a plugin for Gibe (my little weblog engine) which would add the sociable icons with the correct URLs to blog entry pages, without having to put anything sociable-specific in the code.

When writing the comment format "plugin system" so that Gibe could use something other than the built-in TinyMCE, I used pkg_resources to create an "entry point" so that other packages could provide functionality to Gibe, and Gibe would know about them without anything but installing the package.

So, I started with the near-simplest possible Plugin class:

class Plugin(object):
    def post_top_widgets(self, post, widgets, context):
        # widgets to put above the post
        pass

On Saturday, the Cape Town Python User Group had its second shorter and smaller meeting, again at the African Institute for Mathematical Sciences (aka AIMS) in Muizenburg.

Simon Cross gave the "main" talk on Genshi, the XML markup based templating system.  Simon explained the evolution of XML-based templating systems from TAL, via Kid, to Genshi, and also gave a pretty good look at how Genshi is organised internally and how one would write a filter and convert from Genshi streams to ElementTree XML objects and back.

Jeremy Thurgood gave one of the two shorter talks, on Python decorators.  Neil Muller spoke about the Python Imaging Library, from simple stuff I could understand to more complicated things like using the excellect NumPy with PIL in the latest version, allowing for much more powerful image manipulation.

We set a date for the next meeting - except I've forgotten what it is.  Somewhere mid-May.  I'm sure Neil (Muller) will post it to the CTPUG list soon - sign up to keep updated.