Symphonious

So Long EditLive! and Thanks For All The Fish (with rounded corners and drop shadows)

2012-05-17T10:20:24Z

Since the very early days of my blogging, I’ve integrated a copy of EditLive! to make the editing pleasant and more powerful. For many, many years there was simply no way I could bring myself to use anything else. Lately though, Apple have been making Java applets less and less appealing while browsers have been continuously improving their content editable suport and JavaScript editors have gotten better at working around the remaining quirks and smoothing off the rough edges on the editing experience. The final straw for me though was that the current early access release of EditLive! 8.0, which appears to include a lot of fixes for the latest OS X, breaks backwards compatibility with a number of APIs I use to integrate it into this blog.

So the time has finally come to switch to TinyMCE. I still have a custom plugin to fix some of the incredibly poor configuration choices made by default in WordPress (P tags are important remember!) but it’s significantly less custom code and complexity. There are also a bunch of new features that have built into WordPress which I’d never enabled in my EditLive! integration which are nice to have. The biggest win however is that I can now write blog posts on my iPad, so hopefully I can share a few more links and quick thoughts without having to drag out my laptop.

It is sad to retire EditLive! though. I worked to build it almost from scratch for nearly 10 years and for most if not all of that time it was the absolute cream of the crop for in browser editing with features and usability that were simply unmatched. I have some slight consolation that I’ve also been able to spend some time contributing to TinyMCE and I know the guys behind it are top notch so I’m happy to pass the baton of favourite editor over. I will miss the integrated image editor and its rounded corners and drop shadows…

Growing a Team By Investing in Tools

2012-05-16T00:27:23Z

It’s widely recognised that adding people to a team often doesn’t result in increases in velocity and can even reduce the velocity of the team due to the extra communication overhead. Instead, teams look to increasing levels of automation and tools to improve their productivity without adding extra people.

Where many teams struggle however is in finding the right balance of building out the product versus “sharpening the saw” by improving their tools and automating processes. With the same people attempting to do both jobs that contention is unavoidable.

The solution then is to build a second team who’s job is entirely focussed on building, maintaining, configuring and improving the tools that the product team uses. Since the majority of tools used by a project are fairly orthogonal to the project itself – and often shared with other product teams – the tool team can be much more independent, reducing the communication overhead. Not only do the product team now have more time to devote to improving the product, they are continuously made more productive because of the work done by the tools team.

The most common argument against having a separate team devoted to tools is that the people building the actual product are in the best position to know what tools will make them work better and exactly how those tools should work. While this is certainly true, agile development methods are explicitly designed to help one team efficiently deliver solutions to other people’s problems. The customer for the tools team is the product team – and they already have a common understanding of software development and speak roughly the same language.

This certainly isn’t a new idea – Fred Brooks suggests it in The Mythical Man Month – and it’s used in many large companies but many small teams have a hard time switching over to this level of thinking, unable to really believe that adding people to the product team may make it go slower and that the same number of people could do significantly more if they had better tools. The time to create a dedicated tools team is significantly earlier in a team’s growth than most people initially think.

Go Faster By Not Working

2012-05-02T00:37:35Z

We all know by now that continuous integration is part of good software development – check in regularly and have a suite of automated tests run to confirm that everything is working as expected. If a test fails, jump on it quickly and get the build back to green. Simple right?

But what happens when something goes wrong in a way that can’t be fixed quickly? For example, the build server has a hardware fault or runs out of disk space. You can’t just rollback the faulty change, its going to take time to get the build back to green. As your CI system grows, it may take time just to understand what went wrong. If your team is small they may all be taken up fixing the problem, but if the team is larger a pair focusses on fixing the build as quickly as possible and the other developers carry on working. Now you have two problems.

You still have the build problem, but now you also have a process problem because you’re no longer doing continuous integration. When things are working well in continuous integration, you have a continuous stream of commits proceeding through the build pipeline. If a bug is introduced the build quickly picks it up and you can identify the problem change easily because it can only be one of a few commits.

On the other hand, if developers keep working while the build is broken, they build up a large backlog of commits which makes it more difficult to identify which revision broke the build. It also makes it significantly harder to resolve the build problem because the code keeps changing and you can easily wind up with multiple build breakages starting to overlap and interact.

To avoid this problem, many companies put up an embargo on commits or close the source tree to prevent any further changes from being committed. This controls change in the build environment and makes it easier to resolve the problem, but it doesn’t prevent the build-up of changes. The result is that when the embargo is lifted, there is a huge swarm of incoming changes all at once, introducing merging problems and making it difficult to identify the culprit if any of them introduce another problem. There could well be multiple problems introduced by that batch of changes with their effects overlapping and interacting making it even harder. Essentially, the longer an embargo is up the greater the chance that it will need to be put back up because of problems in the batch of changes developed during the embargo.

So what’s the answer? Simple – stop working. The team as a whole will go faster if developers simply stop writing code once they reach the point where they would normally commit but can’t because there’s an embargo. For short embargos, most developers won’t be affected at all, but as the embargo lasts longer more and more developers will have to stop work. This feels really bad, but it ensures we keep doing continuous integration and overall benefits the team’s productivity. For build problems that are hard to understand, it also means that gradually more and more developers are available to spitball ideas about what’s wrong and to pick up lines of investigation to help get the build working again.

Also, not coding doesn’t mean that developers can’t do anything at all, maybe now is a good time to do those higher level design sessions and ensure everyone is pushing in the same direction, maybe read up on technology that is either in use but not fully understood, or that could be of benefit if it was introduced. If there are spikes to be played, they can usually still be picked up and worked on, write a blog post (like say, this one). Or even just take an early lunch.

The bottom line is that build breakages are always hugely expensive – pretending that everything is normal and you can continue work when the build system is broken doesn’t make them any less expensive, it just makes you look busier while creating the next problem.

Ignoring Changes to Tracked Files in Git

2012-03-27T06:25:49Z

I’m going to want to remember this one day, so here’s a pointer to Rob Wilderson’s Ignore Changes to Tracked Files in Git.

I’m especially going to want to remember the bit about how to find which files I’ve ignored in this way.

Resolving SVN Tree Conflicts

2012-03-19T23:19:59Z

SVN tree conflicts can be insanely annoying – especially when they occur because you’ve deleted something locally and then an incoming change also deletes it. They can also be hard to resolve from most IDEs.

The trick is to resolve them from the command line. Edit/create/delete the files to get things into the state they should be and then from the command line run:

svn resolve --accept working <path>

No more tree conflict.

Alternating Table Row Colours Filling All Available Space

2012-03-02T03:19:01Z

CSS3 makes it trivial to have alternating row colours for tables, but when the table is in a fixed height scroll panel, it’s much more difficult to have those alternating row colours extend beyond the bottom of the table content to fill the available space. Here’s the approach I use.

First let’s start with a simple table with alternating colours in a scroll panel:

<!DOCTYPE html>
<html>
<head>
<meta charset=UTF-8>
<title>Alternating Rows Example</title>
<style>
* { margin: 0; padding: 0; }
table {
  border-collapse: collapse;
  width: 100%;
  height: 100%;
}
.scroll {
  position: absolute;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
  overflow-y: scroll;
  overflow-x: auto;
}
.scroll tr {
  height: 20px;
}
.striped tr:nth-child(odd) {
  background-color: #EAEAEA;
}
</style>
</head>
<body>
<div class="scroll">
<table class="striped">
<tbody>
<tr><td>Row 1</td></tr>
<tr><td>Row 2</td></tr>
<tr><td>Row 3</td></tr>
<tr><td>Row 4<br>With an extra line</td></tr>
<tr><td>Row 5</td></tr>
</tbody>
</table>
</div>
</body>
</html>
 view raw simpleTable.html This Gist brought to you by GitHub.

That gets us alternating row colours where there is table content. To get it to extend beyond the table content we need to add a filler row:

<div class="scroll">
<table class="striped">
<tbody>
<tr><td>Row 1</td></tr>
<tr><td>Row 2</td></tr>
<tr><td>Row 3</td></tr>
<tr><td>Row 4<br>With an extra line</td></tr>
<tr><td>Row 5</td></tr>
<tr class="filler"><td></td></tr>
</tbody>
</table>
</div>
 view raw fillerHtml.html This Gist brought to you by GitHub.

This gives us an extra row in the table that we know will always start immediately after the last row of content in the table and line up. We can now set a prepared image as the background of that row that preserves the alternating colours and stretch it out to take up the remaining space:

.striped .filler {
  line-height: 0;
  background: url(stripes.png) repeat top left;
  height: 100%;
  padding: 0;
}

.striped .filler td {
 padding: 0;
}

.striped .filler:nth-child(even) {
  background-position: 0 20px;
}
 view raw fillerStyles.css This Gist brought to you by GitHub.

Apart from the background image, we set the height to 100% so that our filler row fills the remaining space. If the table is empty, the filler row will get 100% height and fill all available space, if however the table has other rows in it, the table rendering algorithm will shrink our filler row down so that it can fit within the bounds of the table – preventing the filler row from overflowing the scroll container and activating the scroll bar.

Since our background image starts with an odd row colour, if the filler row is an even row, we use background-position to shift the background image down by the height of a stripe so it effectively starts with an odd row colour.

We also add line-height: 0 and padding: 0 so that when the table content fills all available space (or starts scrolling), the filler row has no minimum height and disappears entirely.

Note that this approach will adjust perfectly well even if the content rows vary in height, because the filler row will always start immediately after the last content row and fill the available space. The height of the alternating colours in our image will just provide the default row height in the filler space.

If we’re only targeting modern browsers anyway, we can go ahead and replace the background image with a dynamically generated gradient:

.striped .filler {
  line-height: 0;
  height: 100%;
  padding: 0;
  background-image: linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -o-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -moz-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -webkit-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -ms-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);

  background-image: -webkit-gradient(
	linear,
	left bottom,
	left top,
	color-stop(0.5, rgb(255,255,255)),
	color-stop(0.5, rgb(234,234,234))
  );

  -webkit-background-size: 40px 40px;
  -moz-background-size: 40px 40px;
  -ms-background-size: 40px 40px;
  -o-background-size: 40px 40px;
  background-size: 40px 40px;
}
 view raw gradientStripes.css This Gist brought to you by GitHub.

The final version of our page is:

<!DOCTYPE html>
<html>
<head>
<meta charset=UTF-8>
<title>Alternating Rows Example</title>
<style>
* { margin: 0; padding: 0; }
table {
  border-collapse: collapse;
  width: 100%;
  height: 100%;
}
.scroll {
  position: absolute;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
  overflow-y: scroll;
  overflow-x: auto;
}
.scroll tr {
  height: 20px;
}
.striped tr:nth-child(odd) {
  background-color: #EAEAEA;
}
.striped .filler {
  line-height: 0;
  height: 100%;
  padding: 0;
  background-image: linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -o-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -moz-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -webkit-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);
  background-image: -ms-linear-gradient(bottom, rgb(255,255,255) 50%, rgb(234,234,234) 50%);

  background-image: -webkit-gradient(
	linear,
	left bottom,
	left top,
	color-stop(0.5, rgb(255,255,255)),
	color-stop(0.5, rgb(234,234,234))
  );

  -webkit-background-size: 40px 40px;
  -moz-background-size: 40px 40px;
  -ms-background-size: 40px 40px;
  -o-background-size: 40px 40px;
  background-size: 40px 40px;
}

.striped .filler td {
 padding: 0;
}

.striped .filler:nth-child(even) {
  background-position: 0 20px;
}
</style>
</head>
<body>
<div class="scroll">
<table class="striped">
<tbody>
<tr><td>Row 1</td></tr>
<tr><td>Row 2</td></tr>
<tr><td>Row 3</td></tr>
<tr><td>Row 4<br>With an extra line</td></tr>
<tr><td>Row 5</td></tr>
<tr class="filler"><td></td></tr>
</tbody>
</table>
</div>
</body>
</html>
 view raw final.html This Gist brought to you by GitHub.

Or try the demo in your browser.

How To Round-Trip Data Via SSH

2012-02-28T01:59:58Z

I keep forgetting this so for the record, you can use SSH to round trip data out to a remote server and back to your own box. This is most useful for adding latency and bandwidth limitations to a connection when doing website testing. The trick is to use both local and remote port forwards:

ssh -L 9090:localhost:9091 -R 9091:localhost:80 remote.server.com

The -L argument starts listening on port 9090 locally and sends all that traffic to port 9091 on the remote server (the domain name, localhost, is resolved by the remote server so it refers to the remote server, not your local machine). Then the -R argument listens on port 9091 of the remote server and forwards all that traffic back to your machine’s port 80 (here localhost is resolved on your local machine).

You don’t have to use localhost as the domain name. For example, if the site you want to test is deployed on your intranet at testmachine.intranet which remote.server.com doesn’t have access to, you could use:

ssh -L 9090:localhost:9091 -R 9091:testmachine.intranet:80 remote.server.com

Or if the test site is publicly available you can do it all without the -R argument:

ssh -L 9090:testmachine.com:80 remote.server.com

In all these cases, you connect to localhost:9090 to utilise the tunnel.

The Business of Standards

2012-01-25T21:25:34Z

Recently I’ve been getting spam from the “standards organisation” OASIS inviting a company that I don’t work for1 to join a new standards initiative. There’s no pretense that I’m being invited because of my clearly superior knowledge of the area involved, merely that the company could get great advertising exposure by participating – including being listed on a press release! Naturally we’d need to become OASIS members and pay the appropriate fee, and to be in the press release you’d have to be at minimum a “sponsor level member”.

On the one hand it’s nice that they aren’t pretending to be anything other than a for-profit marketing company, but isn’t it a bit sad that we think standards are just a marketing tool?

1 – yes, they’ve done so much research into how much I have to contribute that they’ve got the company wrong ↩

Development Mode – Concatenating Scripts and CSS

2012-01-11T21:37:30Z

HTML 5 Boilerplate reminded me of an old-school tool which is extremely useful for concatenating JS and CSS files on the fly – server side includes:

<FilesMatch ".*\.combined\.(js|css)$">
  Options +Includes
  SetOutputFilter INCLUDES
</FilesMatch>

Then you have a main scripts.combined.js (or css) which contains:

<!--#include file="libs/backbone-min.js" -->
<!--#include file="libs/underscore-min.js" -->
<!--#include file="libs/jquery-1.7.1.min.js" -->

Plus any other files you need, in the order you specify. This works great for development mode so you can change a file on the fly and just refresh the browser without running any kind of build script. When it comes time to push to production, it’s easy for a build script to process the file ahead of time and be confident that you’ll get exactly the same result.

Cross Pairing

2012-01-03T21:43:11Z

This evening I stumbled across two interesting posts about alternate layouts for pairing rather than sitting side by side. Firstly Tom Dale talking about Tilde’s corner desk pairing setup (and some of the software setup they use) and that was inspired by Josh Susser’s face to face pairing setup at Pivotal Labs.

Both approaches require more floor space which makes them difficult to setup but I would expect the face to face pairing to be a heck of a lot better if done well. I’ve always preferred having separate screens in mirror configuration as well as separate keyboards and mice to allow the developers to sit a little further apart to be comfortable and to be able to look straight ahead at the screen. That said, I quite like having a second monitor for spreading out windows as we have at LMAX so it’s not clear cut which is better.

It’s also interesting to note the popularity of the flat screen iMacs as opposed to Mac Pros or laptops. The former being too expensive for extra power and extensibility that generally isn’t required and the latter often being a bit too individualised to be good as pairing machines. Plus laptops, while amazingly powerful these days still have less bang for the buck and the reduction in performance is just enough to matter for development.