Yesterday, monday, was our first day in our new office after the move: yeah, great office space. Every one of us looked happy and content. I was merrily working throughout the afternoon and suddenly noticed that it was 17:45 (I had to go home at 17:00 in order to eat before people arrived)... I just didn't look at the time. I blame it on the nice building :-)

The old location started to get cramped (see last photo), so we needed the extension. Jean-Paul and Esther (=bosses) did manage to find a good office that they're rightfully mighty proud of. Three random things that I especially like:

• Two entire walls filled with whiteboards. I love whiteboards and have a big one at home. Zest's new office takes it to a new level. We immediately put the whiteboards to good use to plan out a new customer project.
• Big Window. One of the long walls is all glass. From floor to ceiling. The programmers are on the second floor: when you come up the stairs the first thing you see is a big open space and a wide view outside. Loads of light, loads of openness. Gives me a feeling I'm capable of more: more overview of projects, better architectures, less bugs, whatever :-)
• Dead next to the metro (=subway). On a day, it shaves 2x10=20 minutes off my commute compared to the old office location. If I manage to be more strict in my morning routine, this bit of margin ought to allow me to be home on a better time. I have a 1 hour 35 commute (one-way) now (was 1h45) three days a week (I work at home two days a week). So I mostly got home just when dinner was finished. Those 20 minutes might make quite a difference!

There's some work to be done on the office, of course. But the office is off to a good start, seeing everyone's enthousiasm on the first day!

The location? Right here , but it is a brand new building, so google maps doesn't have it on its satelite photo yet :-)

Part of my personal capabilities series .

A Belbin teamroles inventory (to me) is the most useful test you can do both as a team and as an individual that works in teams.

The basic summary is that, within a given group, people tend to fulfil one or more of 8 basic roles. If you miss a role in your group, you can be hampered; other roles have a one-person-only-please limit. Remember that person that always seems to end up taking charge? Are you the person that ties up the loose ends? Are you constantly spewing forth new ideas?

Each role comes with strengths and with weaknesses. I'll illustrate it by giving some personal examples. I've done the test a few times over the course of 6 years. Three times in a university setting, once just by myself on the internet and once at my current workplace Zest software .

My number one role: monitor/evaluator (Dutch: waarschuwer). Consistently the number one. In every test. And with a, for this role, ridiculous high score. I'm smart and I can analyse well. A definition of this role is "you have a capacity for shrewd judgements that take all factors into account and you seldom give bad advice". Not that I don't make mistakes, but if I really advice against something, I'm often right.

Some drawbacks that I notice in myself. I can be long winded: talking for a long time so that everybody loses my point. Critical and intelligent also equates often to distant and cold. And there's a risk of slamming an overly negative brake on creative discussions and processes.

A point about drawbacks: some drawbacks are allowed drawbacks. They're a package deal. If you want the benefits of a monitor/evaluator, you'll just have to learn to live with some of those attached drawbacks. At the same time, those drawbacks are something I want to be aware of so that I can limit their detrimental effect.

Numbers two and three: company worker/team worker (Dutch: bedrijfsman of teamwerker) and shaper (Dutch: vormer). In the earliest tests company worker was the clear number two, in the more recent ones the shaper takes that spot. I've got a story that illustrates I really have some shaper characteristics later on.

A company worker is loyal (something that's really strong in me). Perfectly willing to do nasty or menial tasks. I can translate goals or customer wishes into practical tasks. Brainstorming how to convert a goal into specific tasks is one of the things I like most.

As a company worker, the demands of practical work can make me a tad conservative. A finely honed system or work approach: don't throw it away before its time. And if I see no practical use in something, it is virtually impossible to motivate me (though loyalty goes a long way).

The second number two spot candidate: shaper. I totally do not fit the "nervous energy" and "aggressive extroverts" characteristics you often see in descriptions of this type! I do have a tendency and desire to technically structure the projects I'm working on or the processes I'm working with. Doing design work on the architecture. Writing programs/scripts that are used to manage the software. Keeping the overview, juggling tasks (and people to do them). If there are obstacles of if there is a looming deadline: I don't mind that much and I'll continue functioning, structuring and pushing myself (or others) along. A shaper is said to be one of the most effective members of a team in guaranteeing positive action.

One of the Belbin summaries I have lists the following three drawbacks that I recognize: prone to provocation, irritation and a tendency to offend others. Those are listed under the heading "allowable weaknesses" but I severely dislike them. Having a technical argument: OK. Being part of a war in a student club: OK, a long as you still can play on the same soccer team with the opponents. But offending persons: bah.

The story with the shaper-drawback that I mentioned. We did this Belbin test with a couple of PhD candidates and got split into two groups afterwards to do some task. We soon discovered that the groups were divided in the most sub-optimal way possible :-) In my group were 4 finishers: ready to do a lot of work and waiting for instructions. And I was the 5th member and my shaper role came front and center: 4 people waiting for structure and instructions. That's what they asked for and what they got. But in the feedback round afterwards I got some hefty feedback that I had given structure, but that I had also driven a 40 ton main battle tank over some quite sensitive feet. Ouch.

For projects, I can function well both as a shaper and as a company worker. In the first case, I try to maintain the overview and try to steer the process and try to have a lot of influence on the architecture. In the second case I'm a loyal team member that gets tasks done.

A couple of weeks ago I read two related things. First was a suggestion to learn to describe yourself in a maximum of 8 words. Probably Tom Peters or Seth Godin. A few hours later I saw Steve Pavlina request people to describe him in three words . Hey, that's a good idea! And I went off in search of spouse and colleagues.

I got feedback from 9 persons total, in a mix of Dutch and English words. That mix probably results in some loss of nuance. On the other hand, it allows me to group mostly-similar items.

Three items were mentioned three times:

• Smart/intelligent. Well, yes :-)
• Headstrong. (Dutch: eigenwijs/onbuigzaam/standvastig). Stubborn, obstinate. If I believe something to be true, I really believe it.

  My PhD topic's solution gained exclamations like "sheer idiocy", "that will never work" and "that is heresy". I did not listen and did not do the same non-working thing that others had done before me.

  A problem I have with a technical discussion: sometimes both "sides" are mostly right, they're just a different technical choice. With the same goal in mind. I can be headstrong in favour of my opinion.

• Driven/dedicated. (Two were Dutch: gedreven, gepassioneerd). I sometimes stay up till 5:00 in the morning to finish off a particular bug or customer problem. (As an aside: a common defence tactic I use is by being non-dedicated to something that I don't like. Passive resistance.)

Three items were mentioned twice:

• Efficient.
• Friendly.
• Thorough. (Dutch: grondig).

And 11 items were mentioned once. Conservative; deep thinker (diepe denker); helpful (hulpvaardig); introvert; lax (laks); open mind (open blik); owl; tranquil (kalm); sympathetic (sympathiek); to the point; self-confident (zelfverzekerd).

So, thanks to all that send me three words. If someone else wants to send me his or her three words that best describe in their opinion: please do send them to me (reinout@vanrees.org). Also other feedback: much appreciated.

This experiment has been helpful to me. Good to see how others perceive me. And helpful to prod me to keep improving my strengths (smart, dedicated, efficient, friendly, thorough) and to watch out for steam-rolling over other peoples' toes (driven, headstrong).

In ye olde barbaric days, one thing was handy: templates and python scripts reloaded just fine in debug mode and a refresh.txt in your product went a long way to not having to restart your zope too often.

Zcml only loads on startup, so a change there means a zope restart, probably nothing to be done about that. But I seem to be restarting zope for just about every single little python change.

So I asked around on the mailinglist last month: on the current strategies for preventing too many zope restarts during development?  I was bound to miss a few tips and tricks otherwise :-) So here's a summary.

• Raphael Ritz had the shortest answer: TDD. Yes, test driven development is   core to preventing restarts as you minimize the amount of in-browser testing   and trying.
• I've tried RefreshNG and that seemed to   work reasonably OK. Not all the time, but it helped. Andreas Jung rightfully   mentioned it. I didn't install it in the last projects I worked on: time for   a more focused test later this month.
• Kai points towards my restart-preventing product of   choice: pyflakes   . The best python syntax checker available! Missing imports, = instead of   ==, head-slapping stuff like that. Catch it before restarting zope :-)
• Kai again: PDBDebugMode can help you to find a solution exactly at the point   of error. It does actually prevent try-error-retry restarts and is a joy to   use.

Martin Aspeli provided the full list of rules on what requires a restart:

• If you are in non-debug-mode, a restart is required for any change at all,   more or less.
• If you are in debug mode, any .pt file changed anywhere does not require a   restart
• If you are in debug mode, any Zope 3 browser resource (accessed with the   ++resource++ namespace) can be changed without a restart
• GenericSetup XML files and Install.py files (unless there's also an   Install.pyc file, but you can delete it while Zope is running) created in   Extensions for use by portal_quickinstaller can be changed without a   restart. However, a custom setuphandler in a normal .py file cannot be   change.d
• Anything in a skin layer will not require a restart - that includes Script   (Python)'s.
• Any other kind of .py file change will require a restart
• Any ZCML change will require a restart

Those plone mailing lists sure are great :-)

Tags: plone

A few days ago, the final 1.0 of omnifocus was released. Omnifocus is a wonderfully polished "Getting things done" (GTD) application for OSX. I've been following the beta releases for a few months now and the quality of the software humbles me, being a software developer myself. Solid, reliable, userfriendly, handy.

Over the weeks, I'll think I'll add a few entries (look at the GTD tag) telling you how I use omnifocus. Here are some initial ideas that seem to work well for me.

• Weekly repeating items. I don't want to be bugged constantly by items that I   want to do once per week. But I do want to do them about once every week   (review plone.net, review projects, clean out desk). I   especially don't want constant deadlines for them. The solution in   omnifocus? Set them to start 1 week from now ("+1w" is the handy shortcut),   give them a due date 2 weeks from now and set them to repeat themselves   every two weeks, starting 1 week from the completion date.

• I've ordered my projects into three folders. One purely work-related   ("customers"). One purely personal ("personal"). And one in-between   ("plone/skills/maintenance"). In the last category are open source projects   that I might work on at work or at home. And planning work like doing a   weekly review with omnifocus: that touches both home and work.
• Above three project groupings are what I use as omnifocus "perspectives". A   perspective is just a saved view/filter. So I have a "work planning"   perspective showing the work projects and the mixed projects. And a "home   planning perspective with the personal and the mixed projects. Same for the   accompanying "home tasks" and "work tasks" perspectives which shows the   context view instead of the project view (you'll have to know omnifocus or   look at the 15 minute introduction video   to understand those terms). That "mixed" set of projects is essential for me   to maintain my sanity :-)

  Tags: gtd, omnifocus

I saw Ricky Spears' list of books he read in 2007 and thought "such a list is a great idea. So I delved into my memory and came up with a reasonably complete list of books I read in 2007. I didn't include the ones I re-read in 2007 :-)

L.E. Modesitt is easily my favorite author. So I read a couple of new paperbacks that came out this year and bought a few of his older works that I had not read yet. He writes both SF and fantasy, both with a good eye for human nature, practicality and, within bounds of course, realism.

• alector's choice, part 4 of a series. Insight in a culture that was only hinted at in 1-3.
• cadmian's choice, part5. Some heavy action. Who says all-powerful beings cannot be defeated?
• soarer's choice, part 6. The culture sizzles out misserably and disappears off the face of the earth. Modesitt outdid himself by making the end so miserable and seemingly pointless. Appropriate.
• Eternity artifact. Stand-alone book. A nice read, nothing spectacular. Attractive through the multiple (6 or so) main personae.
• Archform: beauty. Politics, media, art. Nice. Get into the atmosphere of the current US presidential race.
• flash. Builds on archform: beauty. More action. Very well thought out: recommended! And in-between attacks on him and by him, the main persona needs to feed kids and get them to school.
• Hammer of darkness. This is a weird one. Weird. I read it in two days, but it was quite some work to get through. Weird. At the end it is all wrapped up amazingly well.

I like history. Apart from the first book, none of them are recent, either.

• Norman Davies' Europe at war (I read it in Dutch: oorlog in Europa). World war two history that's much more centered on the eastern front. I'd consider it recommended reading when you want to get a better feel for the second world war. A good number of data, too, to put common misperceptions into perspective (in man-months, the western front from D-Day to the end in 1945 doesn't compare to several of the offensives in the east at all, for instance).
• It never shows in September. Surprising account from the German side of things about the Market Garden airborn assault in 1944. Highly recommended!
• I was a stranger by British airborn general Hackett. Severely wounded at Arnhem, he was hidden away at the house of three dear older ladies. He recounts his stay there and, at the end, his escape to freedom.
• Kenneth Macksey: invasion. About a fictional early (and thus succesful) invasion of England by the Germans in July 1940. Well worked out.
• Alfred Duggan: count Bohemond. Well-readable book about one of the crusaders in the first crusade. Well-described battle scenes. A good insight into the mood and the morals of those days.

Assorted fiction.

• Harry potter and the deathly hallows. A fitting closure.
• Tom Holt, faust among equals. Hard to get started, but was reasonably funny after the first hurdles.

Technology and personal development

• Kuestenmacher/Seiwert: simplify your life. I read the book in the original German language. Great, practical book for improving yourself and get yourself more on track.
• Von Weitershausen: web component development with Zope 3

• Brooks: The mythical man-month. A classic!
• Strengthsfinder 2.0. See a separate blog post with my results .
• Niven: The 100 simple secrets of successful people. Not that good.
• Seth Godin: the dip. Finished it off in about 35 minutes. A good one.
• Levine: cut to the chase. Good tips.
• Jim Loehr, Tony Schwartz: the power of full engagement. I've really got to put this into a separate blog post. Valuable insights!

That's it for 2007 :-)

I got a new MacBook last week (thanks, boss !). I'm very happy with it:

• The speed, oh, the speed! The 2.5 year old powerbook pro (G4) started to show not so much its age but more especially the rightness of apple's decision to switch from power processors to intel processors. Starting/stopping zope instances is way more speedier now. Running tests too. And making an occasional movie.
• It has the 10.5 OS, Leopard. They just have to name the next one Leopard II as they've had the Panther and Tiger already... The leopard main battle tank might not be as well-known in the USA as in Europe, but everyone I've heard till now uses the German pronounciation :-) Leopard-the-OS is great, especially the improvements in spotlight. That's actually usable and useful now. I also enjoy the improvements in iMovie.
• The one thing I missed on the mac is now available in a usable form: the gimp. I mean the version at wilber loves apple . Grab a newer version of the x server that OSX uses from sourceforge (yes, the official OSX-used Xwindows version is on sourceforge); download the wilber-loves-apple package; install; be happy.
• The MacBook is noticably lighter than the old powerbook pro. And it has a better battery life (important for me as I blog a lot at conferences :-) ).

  Tags: plone, osx

Hurray, after 6 years of work I got my PhD on 15 January 2007. Finally I'm done! There was a nice formal ceremony in which I had one hour to defend my thesis against 7 official opponents. Actually pretty funny to do, but very intensive. You've got to keep all your wits about you for one full hour.

That's also exactly one full hour, for after one hour you get a loud bang on the floor of the beadle (Dutch: pedel). That means you've got to keep talking while she looks at her watch as it is appreciated if you have to stop mid-sentence. I even had to stop mid-word, so that went OK :-)

There's a lot more to say, but I'll just link to the photos for now. A switch on the photo camera that was in the wrong position ruined about 80% of the photos, but there are enough left to give a good impression, luckily.

Loads of people have asked me "what I'm going to do now", mostly meaning whether I'm going to continue research or whether I'm going to look for a job now. Well, I'm simply continuing the work I've done for the last 1.5 years: Zest software . Building pretty elaborate websites and intranets (like milieudefensie , triple p , two philips intranets, etc.). For that, I'm working with the content management system Plone that I also used for many of the prototypes in my PhD thesis .

I've got permission (and encouragement) to continue to keep my eye out for opportunities in the building&construction industry. There's still a bit of prototype software lying around that I want to resurrect again as people found it useful and want to use it again. So I'll continue to dabble a bit in it, as it is a really interesting problem :-)

The One Who Writes Wins is a chapter about contracts in a book I ordered yesterday (of course I haven't got it yet). It's a chapter about writing contracts and dealing with them.

That reminded me about something I like about my employer, Zest software . Standard IT supplier contract terminology (like in our standard conditions) sounds to me like "we own everything we program and we'll barely allow you to use it for the next five minutes". Contrast that with the contract another company that we worked for wanted us to sign: their standard contract with their suppliers. It sounded to me like "sacrifice your first born, hand over all you posess and be glad we don't chase you over the borderline". So "The one who writes wins" in this case sounds almighty like an war in which you want to infict pain on the other. I'm sure the book doesn't intend it this way :-)

How to solve that dilemma? In our case, we explicitly say most of the time that our software is placed under the GPL license. So that's in addition to the standard contract clauses, effectively removing most of the pain points. It doesn't necessarily mean that we actually widely distribute the customisations we make for our customers. But it gives both Zest software and the customer a lot of advantages:

• We keep the copyright to the code we write. No signing-over of copyright to the customer, making it hard to re-use bits and pieces in next projects.
• No tie-in for the customer. They can take our GPL-ed code, go to one of our competitors/collegues and ask them to work on it. No problems.
• It is easy to donate pieces of code to Plone itself, there is no license to sort out and we don't need the customer's approval. Ultimately (and sometimes even directly), that's to the customer's benefit.
• The customer has the code! Not just the binaries, but the actual source code. That's real good for reducing nightmares and uncertainty. One of our customers has subversion access so that he can make changes of his own. That's one company that doesn't have to worry about vendor lock-in :-)

In Zest software's case, it seems to work out real well. I get the impression that it actually lands us contracts, as the benefits seem to appeal a lot to our customers! To me, it's mostly the reduction in hassle that appeals: you just don't have to worry about it. "Just" put the code under GPL and you're done. It protects both you and your customer.

James Governor says How to Hire a Good Developer: Read Their Blog: No interview required . Through weblogs you can get a good feel for someone's qualities and, within margins, someone's character. That can save you a lot of hassles and job interviews.

It's true also the other way around. I think it is one of the big reasons why I got my current job . After the first interview I even put a good overview of my python/plone/zope experience up on my weblog. And I was able to tell them to just check out google. And point them to a few weblog posts. And some products here and there on sourceforge.

They probably did their googling themselves, too, before the first interview. Make sure you will be found by your future employer, I'm sure glad I could be found :-)

My administration was a bit of a mess last month and I didn't get around to writing down my hours. Now, that's not necessarily a problem cause most of my work is in subversion, so I can always look at the logfile. But filtering out my commits from the other busy bees at the company takes some time. Time to automate things!

You can use svn --verbose --xml log http://yourserver.org/yourrepository to give you an xml log of all the changes in your projects. If you add a -r{"2006-01-01"}:HEAD you restrict it to last 1 Januari till now. Redirect the output to an xml file and process that (with saxon or xsltproc for instance) with the following xslt file:

  <?xml version="1.0"?>
  <xsl:stylesheet 
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns:xml="http://www.w3.org/XML/1998/namespace"
      xmlns:date="http://exslt.org/dates-and-times"
      version="1.0">
    <xsl:output 
      method="html" 
      encoding="UTF-8"
      indent="no"/>

    <xsl:template match="/">
      <html>
        <head>
          <title>Uren</title>
          <style>
            .discreet { font-size: 80%; }
            @media print {
            .noprint {display:none}
            td {
            font-size: 80%;
            }
            }
          </style>
        </head>
        <body>
          <xsl:apply-templates select="/log"/>
        </body>
      </html>
    </xsl:template>

    <xsl:template match="log">
      <table border="1">
        <tr>
          <th>Date</th>
          <th>Message</th>
          <th class="noprint">Changed files</th>
        </tr>
      <xsl:apply-templates 
          select="logentry[author='reinout']"/>
      <!-- ##################################### -->
      <!-- Change this author name to yours -->
      <!-- ##################################### -->
      </table>
    </xsl:template>

    <xsl:template match="logentry">
      <tr>
        <td>
          <xsl:value-of select="date:date(date)"/>
        </td>
        <td>
          <xsl:value-of select="msg"/>
        </td>
        <td class="discreet noprint">
          <xsl:apply-templates select="paths/path"/>
        </td>
      </tr>
    </xsl:template>

    <xsl:template match="path">
      <div>
        <xsl:value-of select="."/>
      </div>
    </xsl:template>

  </xsl:stylesheet>

That gives you a handy html overview. It sure saves me at least 15 minutes right now, so it already paid for about half the time it took to make the template :-)

Yeah, we just got the news today that we (Zest software) have a new client. Big one, too, with 200, 300 employees. We're going to (re-)build their intranet, with the option more work later on.

The fun thing for me personally: they're based in Vianen, which is 45 minutes of cycling time from my house. And they want some regular on-site development work. 45 minutes of cycling time instead of 1 hour and 45 minutes of tram+train+metro time.

I'm working from home 2 or 3 days a week, so the travel time is fine with me. Gives me a chance to do some serious reading. (And I like trains a lot). But getting a new client so close to your new employee that lives quite far away from the rest... That's a happy circumstance :-)

The company I'm working now (Zest software) has a very healthy attitude on working overtime: don't! That's not something that is automatically so in the IT industry with "death march projects" being proverbial.

Andy Hunt has an article with some of the logic behind not working overtime, 40 hours being considered a normal working week. After 40 hours, your productivity drops. Like Andy says, you can do it for a week or two, but not for the long haul.

So, when I pulled an all-nighter to hunt down (and destroy) a bug last week, I had to promise to take a day off this week. Which I did yesterday, giving me a day to type away at my PhD thesis :-)

John Cleese treats backup trauma, watch that video.

Job job job job job job job job job job job job job job job job job job job job job job job job job job job job job!

This thursday I'm going over to sign the contract. I've got a new job! Me happy! More news on thursday :-)

Btw, it's an open source zope company!

Grig Gheorghiu wrote a walk-trough of the selenium web app testing tool which makes it sound like an attractive tool! I'm not currently using functional tests, but I probably will. Selenium 'll be my first stop, then.

The next article in his series 'll be about a plone version of selenium.

You can find online demos at the thoughtworks site and an article on it .

Update: Grig 's got an update, with instructions for simple usage.

James Governor says open source is like a personal trainer for commercial software. For instance:

MySQL is pretty damn busy; it has DB2 and Oracle on the treadmill, and it got Ingres to do some serious cardio work too.

Yes, that's a positive effect of open source software. Proprietary software has to prove its worth and it must be we worth the price. One powerful example is apple. I was amazed at the number of apple laptops at last year's python conference.

Laptops are hardware, but in this case it is also apple's partly-proprietary operating system (unix-based) that matters. Most python-related software is developed on linux, but for laptops apple seems to be really compelling. Compelling enough to lure a lot of open source developers into its fold :-) A linux-using friend whose opinion I trust is also enthousiastic about his apple powerbook.

Apple is probably giving windows a workout, but is itself continually threathened by the likes of KDE, a good linux desktop. The progress and innovation I've seen over the years in KDE is amazing. Apple 's got to have a pretty decent stamina to keep ahead!

I think, however, that open source software has some pretty strong points of its own. It's not just good for giving the "commercial" guys a workout. In many ways and for many fields it is actually a better choice. Take for instance investment security: open source won't go out of business. There's no real safety in big players. Even the likes of peoplesoft get bought, causing uncertainty in many companies. You won't have that kind of worry with a good open source project. One-man projects with unreadable code: that's unsafe. But, for instance, Zope or Plone with its big number of developers, well-documented interfaces, well-tested code: you won't be left floundered as a company that bets on that. Guaranteed.

Ted Leung talks about commons based peer production, by which he means open source. I've seen that phrase a few times now and I'm starting to like it. Here's my take on the phrase.

Commons based

The commons is for instance the common grazing ground for a village. In the village scenario, overgrazing is a problem. When there are no checks on behaviour, short term optimalisation destroys the common grazing ground for sure due to overgrazing.

In open source development it is more like an inverted commons. The more the common ground is used, the more useful it becomes. Software doesn't degrade by use! And everyone working constructively with it can add to the commons.

Peer production

The software is produced by peers. Not everybody can change everything, but it normally doesn't matter which company you work for, what your hair color is or on which planet you live. You've got individual contributors. You also 've got academic-like "peer review", in which you can look over the code or the documentation of your peers and point out errors, omissions or possible additions. If you do this in a helpful-enough manner, you stand a good chance of having your error corrected or suggestion adopted.

Personally, I haven't submitted many fixes but I've seen a very good acceptation ratio. Which is very gratifying, but not in the "I got my way"-kind of way you'd expect: for me it's much more the gratification of being able to contribute a bit back to the commons, to help build it. Likewise helping out on a mailinglist (and getting some of your own questions answered in the proces!). Or adding some (de)capitalisation functions to an XSLT extension library because you need it in there and the owner is happy to add them to the core: everybody happy.

Unrelated: I've been too busy using LaTeX lately, I'm starting to type \textit{.....} when I want to put something in italics... :-)

Oooofff. I just send off my first-ever job letter. All in all it took me two very full days to get it all done and tidied up. Keeping the actual letter to just ONE page, but including enough good info, but sounding attractive, but also saying what you like about the job, but being a bit on the formal side, but being also spontaneous...

Well, happy I've pressed send (ok, ctrl-x...). Strange in a way. In my school days I was told to write well by hand, as job letters had to be written by hand. Now I just package up a PDF and send it over. That's something that's changed in the last 10 years or so. And sending an email instead of sending a letter... Ah, it's way easier on both parties. I did do a cc: to myself and a bcc: to a collegue to make sure the mailserver doesn't have a hickup halfway. With that university mailserver being cracked a few weeks ago and backups being only halfway decent... (Sure glad to be doing all my email hosting myself!).

Ok. Time to sit back and relax for five minutes. I've got a thesis to finish. And job hunting won't stop now, either. I've got a meeting at a sotware company on monday :-)

Spotted at Brian Marick's blog, a link to ping pong programming .

Wow, that sounds like great fun. And a great way to get good unit tests for your software. I've done some unit testing (and liked it every time), but I don't yet do it consistently enough. Just last week I started adding unit tests to my zope/plone programs. Long overdue and not actually too hard to get running. And it saves time!

Now to get that lazy brother of mine to join in some ping-pong-programming :-) He might learn some zope and plone by the way. (I won't mention the shell and bash tricks he showed me that I somehow missed though I'm using linux 3 years longer than him... :-)