Announcement: in just over a fortnight I’ll be packing my bags to go chase the kiwi dream – I’m moving to London!

Provoke has been a wonderful home for the past two years, and I thank all my workmates and clients who made my time there so special. Working here has really been an unforgettable experience, and I hope to take a little bit of that magic onto future jobs and organisations.

So far, my immediate plan for the next few months involves .NET architecture/development work in London, probably on contract basis so I can fit in some travel around Europe between projects. I’m also keen to check out the various developer conferences like QCon and Oredev. But first, I need to start packing!

January 18th, 2010 | 4 Comments

I have a confession to make. After eight years since we first met, I still don’t quite get CSS.

Sure, I can do typography, sprite backgrounds and understand the basics of the box model. I even know about browser-specific CSS extensions for CSS3 effects. But when it comes to clearing floats, vertically-aligning form elements or figuring out inline parents with block children, I go to a very dark place and start cursing.

I freely admit my CSS layout and positioning skills are lacking, and I probably shouldn’t even be blogging about it. But when I discovered CSS grid frameworks, I was naturally interested — anything that helps me get up and running quicker in a foreign language is a win.

Grid frameworks: CSS for dummies

For those that don’t know, grid frameworks like 960gs, YUI grids and Blueprint CSS provide a simple 12, 16 or 24 column grid that abstracts away complicated CSS layout and positioning rules.

For example, using the Blueprint CSS framework, this markup produces the following layout, neatly centered in the middle of the browser window:

<html>
<head>
    <link rel="stylesheet" type="text/css" href="blueprint/screen.css" />
</head>
<body>
    <div class="container">
		<div class="push-4 span-15">header</div>
		<div class="push-4 span-4">menu</div>
		<div class="span-7">main</div>
		<div class="span-4">ad space?</div>
		<div class="push-4 span-15">footer</div>
    </div>
</body>
</html>

How easy was that? As a CSS newbie, not having to worry about floats, clears, negative margings and other positioning tricks is a very attractive proposition.

So CSS grids are very powerful for quickly laying out elements. But there is a trade off you should consider — HTML marked up with grids is not at all semantic. Peppering your HTML with classes like .span-12 or .yui-t3 for layout is no better than specifying table widths and heights everywhere.

Wouldn’t it be great if you could keep using these grid classes, but somehow mask them behind semantic class names?

LESS: CSS preprocessor

About the same time I discovered grids, I stumbled upon LESS: a ‘leaner’ CSS command-line preprocessor that extends CSS with its own syntax and features. The .NET port, .Less, has a smaller feature set than the rails version, but it lets you do stuff like this:

.rounded_corners {
	@radius: 8px; /* variables */
	-moz-border-radius: @radius;
	-webkit-border-radius: @radius;
	border-radius: @radius;
}

#header {
	.rounded_corners; /* mix-ins */

	img.logo { /* nested styles */
		margin: (@radius * 2) + 1px; /* expressions */
	}
}

#footer {
	.rounded_corners;
}

I have .Less is setup as an HttpModule in my web.config. It intercepts any requests to *.less files, translates them to real CSS, and optionally minifies (compresses) them. So you can you can simply reference the .less file directly in your markup, with no extra compilation step required:

<head>
    <link rel="stylesheet" type="text/css" href="site.less" />
</head>

Grid CSS frameworks + LESS = semantic grids

I’ve been using LESS for a few weeks now, and to be honest, I never want to go back to writing ‘raw’ CSS again. So what happens when you combine the CSS grid framework with LESS? Here’s the new stylesheet:

@import blueprint/screen.css;

div.container {

	div.header {
		.push-4;
		.span-15;
	}

	div.menu {
		.push-4;
		.span-4;
	}

	div.main {
		.span-7;
	}

	div.ads {
		.push-4;
	}

	div.footer {
		.push-4;
		.span-15;
	}
}

All that’s left is semantic class names using grids styles as mix-ins. Now the markup is looking acceptable again:

<html>
<head>
    <link rel="stylesheet" type="text/css" href="site.less" />
</head>
<body>
    <div class="container">
		<div class="header">header</div>
		<div class="menu">menu</div>
		<div class="main">main</div>
		<div class="ads">ad space?</div>
		<div class="footer">footer</div>
    </div>
</body>
</html>

Using grid classes as mix-ins gives us the best of both worlds — you get the power of the grid CSS framework, but without introducing layout concerns to your markup.

December 28th, 2009 | 3 Comments

Here’s a couple of real-life documentation examples from a system I’ve been building for a client:

A Monitored Individual is a role played by certain Employees. Each Monitored Individual is required to be proficient in a number of Competencies, according to [among other things] what District they’re stationed in.

A Training Programme is comprised of Skills, arranged in Skill Groups. Skill Groups can contain Sub Groups with as many levels deep as you like. Skills can be used for multiple Training Programmes, but you can’t have the same Skill twice under the same Training Programme. When a Skill is removed from a Training Programme, Individuals should no longer have to practice it.

This is the same style Evans uses himself in the blue DDD book. A colleague jokingly called it Domain-Driven Documentation.

I adopted it after noticing a couple of problems with my documentation:

  • I was using synonyms — different words with the same meaning — interchangeably to refer to the same thing in different places.
  • Sentences talking about the code itself looked messy and inconsistent when mixing class names with higher-level concepts.

It’s a pretty simple system. There are only three rules to remember: when referring to domain concepts, use capital letters, write them in full, and write them in bold.

Highlighting the names of domain concepts like this is a fantastic way to hammer down the ubiquitous language — the vocabulary shared between business and developers.

Since adopting it, I’ve noticed improvements in both the quality of my documentation, and of the communication in our project meetings — non-technical business stakeholders are starting to stick to the ubiquitous language now, where in the past they would fall back to talking about purely UI artifacts. This is really encouraging to see — definitely a success for DDD.

December 10th, 2009 | 1 Comment

Last week I had to write a little javascript for a form that involved a long list of check boxes. To save time, the application only processes rows where the checkbox value actually changed away from its original state.

For example, if a checkbox was checked to begin with, then the user unchecks it then re-checks it, we don’t have to do anything because although it did change, it ended up back at the same original state.

This is pretty easy to achieve by remembering the original state of the checkbox using jQuery data — library methods for storing arbitrary javascript objects in DOM elements — then comparing against the original value when toggled.

<script type="text/javascript">
	$(document).ready(function() {

		// Set aside the original state of each checkbox.
		$("input.toggle").each(function() {
			$(this).data("originallyChecked", $(this).is(":checked"));
		});

		// Check whether it really changed on click.
		$("input.toggle").change(function() {
			var action = $(this).siblings("span");

			if ($(this).data("originallyChecked") == $(this).is(":checked"))
				action.text("(no change)");
			else
				action.text($(this).is(":checked") ? "added" : "removed");
		});
	});
</script>
<ol>
	<li>Apple <input type="checkbox" class="toggle" /> <span/></li>
	<li>Banana <input type="checkbox" class="toggle" checked /> <span/></li>
	<li>Carrot <input type="checkbox" class="toggle" /> <span/></li>
	<li>Zucchini <input type="checkbox" class="toggle" checked /> <span/></li>
</ol>

The next requirement was adding a select/deselect all button. This proved a little bit more difficult, because of the way jQuery deals with events and the checked attribute. To cut a long story short, I ended up with an event handler that manually sets the checked attribute and then fires the change event on all the checkboxes (I tried the click event first, but it didn’t seem to pick up the new state).

$(document).ready(function() {
	$("input#select-all").click(function() {
		$("input.toggle").attr('checked', this.checked);
		$("input.toggle").change();
	});
});

Altogether, it works very nicely in only a few lines of javascript. You can see the whole thing in action here.

December 6th, 2009 | 2 Comments

This is a really good article I came across yesterday with some scary truths about IT projects in general: Roger Sessions – The IT Complexity Crisis: Danger and Opportunity (Nov 2009, PDF)

  • Worldwide, the annual cost of IT failure is around USD $6.18 trillion
  • 66% of IT projects in the US govt were considered ‘at risk’ of failure in 2009 (growing 15% each year)

There’s a bit of maths, but basically it suggests that the whole reason for this is increasing complexity in projects, and presents an equation where the chance of failure in a project grows logarithmically with the number of business functions and the number of connections to other systems.

The answer is to identify these functions and connections and split them out into simpler isolated systems — one per bounded context! — that can be delivered independently of each other (and independently between vendors), instead of trying to smush them all into one humungous ball-of-mud application.

Definitely worth a read if you’re on the architecture side of things!

December 3rd, 2009 | No Comments Yet