Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘September, 2005’

At the last meetup, the majority of the people there were ‘thinking’ about using either Rails or Django on a real world project. So by way of some blatant agenda setting for the meetup on the 10th (don’t forget to go and leave a comment if you’re coming) what is stopping you from using either?

Is it concerns about maturity? Scalability? Deployment options? Does the lack of (development) tools put you off? The lack of a workforce, or simply the fact it is in a new language? Is there some killer feature that either one needs to make you use it? Perhaps if enthusiasts of both communities start addressing these concerns and start engaging in some (balanced) advocacy and honest discourse, the adoption of both can be sped up.

Nowadays, creating a webservice can be fairly simple. Axis has finally got to a point where creating a SOAP interface requires the minimum amount of chicken slaughtering and dark incantations, and .NET makes it ridiculously easy (no wonder Java 6 is aping .NET-style ease of use(magpiebrain – Sun on Mustang (J2SE 6.0) – squaring up to .NET?) for webservices). Both Djano and Rails make it easy to create REST-style apps (Django’s URL’s are RESTful out of the box). The problem is creating a webservice shouldn’t simply be a case of placing a language-agnostic HTTP-based interface (be it REST, XMP-RPC or SOAP) in front of your application.

The word ‘service’ in webservice should represent more than the programmatic interface between the server and clients. It should represent a contract between two parties – the maintainer and user of the service – on more levels that what methods can be called, and what types are defined.

As a developer of a service you must be able to commit to (and document if required) a level of service – in terms of uptime, throughput and handling support. You need to have a versioning strategy that allows clients to not only test against new versions of your service, but also gives them time to upgrade once a new version goes live. You need to establish agreed communication channels between yourself and clients. This applies equally if the service is for use inside a team, a department, a company or even between businesses.

As a user you need to give the service some indication of current and future load – giving them a chance to scale if required, throttle your traffic, or look at optimising your current use. You also need to be proactive in testing against new versions of the webservice – not only so you migrate to the latest and greatest version as soon as possible, but also so you can aid the developers and feedback bugs.

As sappy as it sounds it’s about being nice to each other. Webservice developers need to understand that their service doesn’t exist in a vacum – sure your lives would be easier without users, but without them the would be no need for your service. Clients need to understand that the developers need your help to do their job. I’ve seen first hand what can happen when the communication between the two groups of people break down – and that within the same department. Understanding what is involved in creating and maintaining a webservice will make everyone’s lives easier.

A recent post by Cedric in response to an article by Michael Feathers (danger, community navel gazing alert! Obviously this blog is above such things) casts doubt on the necessity of unit tests.

Michael’s rules on what a unit test is seem overly draconian to some (not being able to touch the filesystem for example – 99% of the time I’d agree, but if I’m testing my FileConfiguration class, what the hell am I supposed to do?) – and despite many other people attempting to define what a unit test is, Cedric’s take on it comes the closest to my own understanding of what a unit test is:

…a unit test is traditionally defined as a set of test that exercises a single class in isolation of all others.

Cedric then goes on to say that 90% of the tests he sees written with JUnit are not unit tests. I for one would be wary of working on those codebases. He also states that he doesn’t care if the test he writes is a unit or functional test – which immediately makes me worry about working on his codebase.

The point that gets missed here is that Unit and Functional tests are not different because of how they work, how long they take or the tools required to make them work, but they are different because they fulfill different roles in development.

Unit tests, because they focus on testing one class and one class only, make it much easier to create highly-focused loosely coupled code, as you create and test a class in isolation of other code. As you have good test coverage at a single class level, you can then safely refactor the class and know you haven’t changed the behavior of the unit. As you are writing code and testing at a small level, you can commit your code more frequently, enabling frequent, smaller-scale integration. If you are testing at a class level, the test themselves become a living document detailing how your code works.

Functional tests are supposed to test slices through your system – from UI to back-end and back if possible. You are asserting that your system conforms to the behavior expected by your users.

Unit tests tend to be fast because they limit the code they test. Functional tests tend to be slow, because they test more code, and also interact with slow components (e.g. databases, browsers, networks etc) but their speed doesn’t define what type of test they are.

Often there is the need to separate fast tests from slow tests – and TestNG’s categorisation of tests is perhaps the first feature of the TestNG that has interested me. But the categorisation is done in order to define fast feedback cycles (e.g. run a quick build on checkin, and longer build on the hour, everyday etc – see Speeding up the build and build pipelining for more details) this should not be used to confuse functional and unit tests. Developers need to understand the different requirements for, and benefits of, these two different types of tests.

In an uncharacteristically expletive-light post, Hani talks about the difficulty of defining what good design is:

So what’s the acid test for a good design? I have no idea. The closest I could come up with is A good design allows your code to do things you never expected it to have to do.

I dislike this definition for a few reasons – at least one of which Hani himself touches on:

It’s not about ‘oh I’ll add an interface here so I can plop in different implementations’ when there’s no sane reason you’d ever need more than one implementation, for example.

That is to say using Hani’s definition as a maxim for what makes good design could lead to designs which violate the ever sensible YAGNI principle.

First and foremost, a good design needs to make it easy to do what you are doing right now. There is no point having a design to support future (potential) requirements which makes your current work a pain to do. YAGNI follows from this principle. Second it needs to be easy to change. This can come from having small, loosly coupled, highly-cohesive code. Both of these things require a design that is easy to understand – not just in the sense of “Can I understand the code?” but in terms of all members of the team being able to share a mental picture of the same design.

Good design is inherently contextual. Design that is good today, might not be good for tomorrow. But if your design (which inevitably means your code) is easy to change, it can be made good again.

Yes, it’s another “I upgraded my blog and aint I great” post only this time it’s in the form of thanks to a couple of different parties.

First off, I decided to upgrade the blog to Movable Type 3.2. On a Sunday evening. Right before bed. After a migrane. Without backing up the database. Note to everyone out there: do not hire me as your sys admin. Net Result? One mildly screwed install. The (apparently slicker) upgrade process hung tring to upgrade MT::Log without giving me any helpful information. Luckily some kind soul came to be rescue, and as a result you get to see a useful post like this.

Next up I installed a copy of Douglas Bowman’s photo gallery templates. The excellent documentation made installing the templates a breeze – and the result is fantastic. Anyone that can make my pictures look good deserves a medal – and the least you can offer him is a small donation for such stirling work.

Well last night’s inaugural Django and Rails meetup went very well indeed (photos to follow) – apart from the slow start due to most people not knowing each other, and being unsure if the raised eyebrow from someone else in the bar was as a result of them seeing if they were there for the meetup or as a result of wandering into the wrong sort of bar. Photos soon. It was good to meet Simon and Natalie (who came down from Gloster for the event and had to go back by bus), Matt, Tom (who had to get back to paddington for 10) and everyone else. The unfortunate side of the turnout being so good was that I didn’t have enough time to speak to anyone – and with that in mind felt we should make it a monthly thing.

Unless there are any complaints, the venue and time will be the same, Smiths of Smithfield at 7pm. To avoid clashing with other events (well, my monthly pub crawl which happens on the first Tuesday of every month to be exact) I’m suggesting the second Monday of the month – which this time around is the 10th of October. Simon Brunning is going to arrange the London Python meetup for the same time so there’ll be some fresh blood 🙂 As before, leave your comment if you fancy coming along…