Pointbeing.net

I was recently chatting with a colleague about bonus schemes, and it occurred to me that every single company I've worked for (that's four, if we're counting) has implemented at least one such scheme, and the outcome is always the same: pissed off employees.

There seems to be a kind of unquestioned assumption that employees want bonus schemes, and that employers are being good employers by introducing them. Such schemes are, without exception, described as being a "benefit". After all, who doesn't enjoy receiving a bonus with their pay cheque? What could possibly go wrong?

I'd like to argue that bonus schemes can go wrong. In fact, they are harmful more often than not, and should be handled with care.

In Part 1 of this series we looked at the basics of command-line Subversion, and Part 2 covered importing, branching and merging. In this third part I'd like to introduce a useful and very powerful Subversion feature, which isn't always terribly well understood by developers: that of Subversion Properties.

I've recently been enjoying - if that's the right word - advanced cryptic crosswords. These are those extra challenging puzzles that crop up in the weekend supplements of the broadsheet newspapers here in the UK.

Advanced cryptics aren't quite like normal crosswords. They tend to be set out on a "barred" grid, as opposed to the more familiar "black and white" version, they typically employ obscure or obsolete vocabulary, and they often feature "special instructions" in the preamble of the puzzle. For example, the solver may be expected insert or remove letters before writing in the grid entry, or resolve clashes between "across" and "down" answers. It can be a bit like solving a puzzle layered on top of a puzzle on top of a puzzle.

Examples of the genre include Inquisitor and Beelzebub in the Independent, Mephisto and The Listener in the Times, Enigmatic Variations in the Sunday Telegraph and, perhaps the father of them all, Azed in the Observer.

I'm not even close to being an expert on these, but I've picked up a few...er...clues over recent months, and I thought it couldn't hurt to share what I've found out so far, and perhaps see if readers have any further advice. So here are my thoughts on solving advanced cryptics.

I've recently been thinking quite hard about software architecture. Not just about UML diagrams and classical design patterns and other technical gubbins, but more and more about what it really means to be "doing" software architecture, and moreover to be doing it well.

And it seems to me that architecture is actually a very poor metaphor for software design, so this is an attempt to get my thoughts in order on that front.

I'll interrupt this "slow blog month" with a quick book recommendation. I recently picked up a copy of "97 Things Every Software Architect Should Know", edited by Richard Monson-Hafael, and published by O'Reilly, and I think that you should too!

While the title suggests that the target audience might be limited to software architects, I really think that everyone involved with the software development process could benefit from reading the book - from the junior developer just getting started on his or her career, to the visionary technology executive at the top.

"97 Things..." is structured as a collection of ninety-seven pieces, none more than a couple of pages long, by about thirty or so different authors. It's not an especially technical book - there are no UML diagrams or code examples, say. It's more like the collected wisdom of a bunch of people who have been designing and building software for many, many years.

There are a couple of themes that emerge from the essays, both of which rang true with me.

You need to know about TED, if you don't already. TED stands for "Technology, Entertainment and Design" and is essentially an annual conference renowned for the quality of its speakers and presentations.

You can't go to TED talks unless you're remarkably eminent - a former US president or Nobel Prizewinner, say - but it is to TED's eternal credit that you can watch hours and hours of video recordings of talks online, for free.

The subject matter is eclectic, to say the least, but the one thing that all the talks have in common is that they are utterly fascinating. It's kind of tricky to pick highlights, and far easier to just dive in and spend hours clicking around. But nevertheless, here are three talks from TED that particularly appealed to me.

In Command-Line Subversion Tutorial, Part 1: The Basics, I covered many of the more common svn commands, and hopefully illustrated a typical SVN workflow.

This time around I'd like to tackle some of the commands involved in managing a project within a Subversion repository, specifically those that you'll need in order to import a project to a repository, and to branch and merge a project's codebase.

About a month ago, the New WURFL API for PHP was officially released. While the code had been available in one form or another for some time, the official release coincided nicely with the early stages of a new project at work, so it seemed like an appropriate time to have a look at the API and see if it was something we wanted to use.

By way of a refresher, WURFL is a "Device Description Repository" - a huge open-source XML-based database of information regarding mobile handsets and their capabilities. I've discussed WURFL in the past, for example here. Prior to this release, the only practical method of querying WURFL in real time from PHP was via a library named Tera-WURFL, which I blogged about here. In fact, both WURFL and Tera-WURFL were covered in an article I wrote for php|architect magazine last year.

We've generally been very happy with Tera-WURFL, but it's always worth considering one's options, so what follows is an overview of my experiences with, and first impressions of the New WURFL API.

One of the trickiest aspects of unit testing or Test Driving an application's code is testing those parts of the system which depend on an external system, such as a database or a SOAP service.

In this post I'll outline an approach to testing a class which happens to communicate with a third-party SOAP service using PHP's built-in SoapClient class. Hopefully, the principles involved will be applicable to the more general case of testing code which relies on an external system.

Back in September of last year, I started studying part-time, for a BSc in Maths, with some computing thrown in. It's now six months since I made that first post, and this is a really, really busy phase of the degree course, so I thought it might be time for an update.