Dirty Thieving B*st*rd

Yesterday at work I was having a pleasant few minutes chat with Nadeem over coffee – a break from refactoring our acceptance test suite and we go talking about Gordon Ramsay’s Kitchen Nightmares. A subject close to my heart as a when Ramsay first started doing Kitchen Nightmares a colleague compared him to me, while reviewing code.

Like Ramsay I am passionately against over complicated things and that sometimes means I come across a little strong.

Anyway, we finished up with me saying that I was going to blog about it, so what do I find when FeedReader opens up this morning?

Very nicely written Nad.

Physical World Hyperlinks

The Pondering Primate has been chattering away about PWHs, or Physical World Hyperlinks for ages. The potential is obvious.

In my world, many of our customers use RFID on their books and self-service terminals from intellident, 3M or other partners. This is the same thing as a PWH in many ways, apart from one key thing. They’re local, proprietary and constrained in purpose.

I had thought the ISBN13, ISBN joining the EAN world, might help but I’ve since discovered that EAN get reclaimed and re-used once a product is not being retailed. So in 20 years I might find an old tin of beans, check out the EAN and find it’s been re-issued to Oakley sun glasses. Permanence in Hyperlinks is important, so this isn’t ideal.

TMS looks like a really nice new approach. It’s a machine-readable tag designed to be read by a phone camera – how long before I have glasses that can read them?

Things are always the way they are because they got that way.

How things got that way

Andy Hunt’s (Pragmatic Programmer) blogs a quick post about how “things are always the way they are because they got that way”.

I always try to look at what I am checking in and ask “does it improve or weaken the overall codebase?” I’ve never come across a situation where the honest answer is that my contribution is neutral; I’m either improving the code for the next person who checks it out or I’m making it worse. If the team all make the code just a little worse each check-in it soon adds up.

Second Life… All the wrong reasons

Warren Ellis posts a colourful description of his drop into Second Life. This is an extreme position. I’m a non-paying user of SL and have managed to avoid being harangued in any of these ways.

At work we’ve looked at opportunities for SL, we’ve even sponsored some initiatives and we even have our own office there.

In SL, there are opportunities to do things just not possible in first life. The most obvious is simply flying and tele-porting around the world; but many folks are setting up businesses too. One of my colleagues, of all the things to do, has a nice little routine of finding a nice little sitting spot (where he gets paid $1 Linden for every 5 minutes he sits) and when he’s earned enough he’ll hop up and wander over to the virtual one-armed bandits and feed them his virtual earnings.

While there is so much great stuff going on the only money being made seems to be on Gold-Rush businesses. During the gold-rush those who made money weren’t digging for gold, they were selling houses and land and clothes and shovels; all of the SL millionaire stories I’ve heard fit into that category – selling real-estate, buildings and avatar designs. It’s a virtual world and still the most common businesses are based on how we look.

If it’s going to go anywhere we have to find business models that are about doing business in a virtual world, bot about the world itself.

Updated to add: Nad has expanded on this to note his own feelings

Strong vs Weak

My colleague Ian Davis pointed at a great post by Nelson Minar.

The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break. And I don’t just mean major semantic changes break things, but cosmetic things like accepting a 64 bit int where you use used to only accept 32 bit ints, or making a parameter optional. SOAP, in practice, is incredibly brittle. If you’re building a web service for the world to use, you need to make it flexible and loose and a bit sloppy. Strong typing is the wrong choice.

This difference in capability and philosophy betwen weak and strong typing is still something I’m getting a handle on. On the one hand I like the flexibility of wekly typed languages like Smalltalk and more recently Ruby, but on the other hand strong typing gives us great gifts like Intellisense and compile-time type checking (which I still find useful when I’m using someone elses API).

I’ve been watching Teqlo for a while (haven’t had my preview key yet though) and it seems they also appreciating strong typing

The questions in my mind are:

Do Teqlo know something I don’t about the trends for web services and typing?

Could Teqlo do what they’re trying to without strong typing?

If web services go weakly typed will Teqlo have a business?

Teqlo

I’ve been watching Teqlo for a little while (since before the renamed from Abgenial Systems) and they look very interesting. They’ve been pretty coy about what they’re doing other than letting us know they’re broadly about letting you combine web services into applications without doing any programming. Anyways, they finally got a video out showing precisely… nothing. Although the UI looks like it’ll be quite pretty…

I’ve signed up for the preview, so I hope dissing the video doesn’t stop them sending me a login…

Usability for Programmers

At work we have a geek book club, a little while ago we all read Joel Spolsky’s User Interface Design for Programmer’s, which is a longer, printed version of this earlier online work. Joel does a great job of explaining the basic of use interaction, provides a few rules-of-thumb and some well-written anecdotes.

What’s struck me back in the office, though, is that the phrase can be read two ways, as teaching programmer’s how to design interfaces or about how to design interface that programmers will use.

This set me thinking about other stuff we’ve been reading, lie Paul Graham’s Hackers & Painters, The Pragmatic Programmer, Object Thinking Code as Design and other bits and pieces. A common thread of all of these is that writing code is about describing a solution to a problem, rather than simply providing a set of instructions to a computer.

Then this week a few of us were working on checkout and build processes for one of our newer codebases, trying to make it easier for ourselves to work on and it struck me that we were really designing software for each other and that a big part of best-practice and common approaches is really just about usability and interactiopn design.

Take, for example, any one of the popular c/c++ open-source applications and you’ll find it has an sutomake based configure script which generates a makefile that has ‘clean’, ‘build’, ‘all’ and ‘install’ targets in it. i.e. it follows the standard pattern. This is no different to using standard menus, buttons and other controls in a Win32 GUI – it’s easier to use.

So, mental note to self:

Consider anyone who will be working with code I’m writing as a class of user and design the development interface with as much care as the user interface.

Google TechTalk: Open Source Performance Testing

Goranka Bjedov – Using Open Source Tools for Performance Testing, Google TechTalk, 8 September 2006.

Goranka provides a great overview of how Google are doing performance testing

“solving problems by just adding more machines is contrary to our mission statement, which is, ‘let’s try to conserve resources’. Make sure you can always throw more machines at it, but eventually you run out of space, you’re usng too much electricity and it’s just the wrong thing to do.”

Performance Testing

“So any time you run a test and you’re actually measuring how quickly a system responds to work load – that means performance test. So, in a sense, you’re answering the question, given a load x, how fast will the system return the result, right? But the important thing is I’m really interested in the time. That’s what I’m measuring.”

Stress Testing

“Like, in the case of a stress test, what I’m really more interested in is when will the system fail and how will it fail. I don’t necessarily care about how fast the response times are, but hwat I really want to know is under what load will the system fail. And hopefully it’s going to do so gracefully.”

Load Testing

“Load test, for me means, I’m putting certain load on the system and what I want to find out over a prolonged period of time, how will the system behave. … But in general for my load tests, … we try to use about 80 percent of the maximum load that the system can handle and see what happens if we’re running the system under that load for a long period of time.”

Benchmark Testing

 ”And so a benchmark test, most important to us, is … it’s simplified, it’s measurable and it’s repeatable, right? Those are the three things that are very important to me. … But basically what bench marks [mean] to us is, let’s try to figure out what the customer or other users are doing out in the real world and then klet’s extract some subsystem or subset of those operations that we can reasonablt, easily recreat and that reasonably well represents the behaviour of the system. And then every single time we make a code change, lets’ run that benchmark and find out, did we mess up the system to the point that it’s unusable or did something really change tremendously. So we tend to do a lot of benchmark testing.”

Scalability Testing

“And scalability means, if I increase a paricular resource, for example, on a typical system where I may have clients and then some frontends and a load [balancer] in front of them and then backends and so on. What if I have 5 frontends as opposed to 10 or as oppsed to 15. If I double the number of frontends, how will my throughput change? … So, some particular variable is being changed … how does it affect the performance of the system or the throoughput of the system …”

Reliability Testing

“So basically, reliability testing – and I honestly believe that yuo should run it on pretty much any product that you have, and run it for at least 72 hours and find out how is your system handling the load? You’ll find out strange things happen.”

Availability Testing

“Availability testing is tied to reliability testing … when people talk about four nines, five nies and so on, that’s what they’re talking about. Availability testing is something slightly different and it basically says when a system fails how quickly will it come back up. … So availability testing tells you , okay,  so finally something has failed, but can it be back up online very, very quickly.”

Very good talk.