Diversity of thought and tech conferences

The traditional approach to running a tech conference is having a speaker talk at you for 40 minutes with a small time allotted for questions. I’ve heard conspiratorial grumbling that this leaves you feeling quite disengaged. But people aren’t quite sure what to do about it.

Conference organisers have tried alternatives like unconferences, lightning talks or moving the whole conference to a resort. All quite interesting, but still not resolving the problem of creating a conference that engages the attendee.

Recently I attended a political conference. Political conferences also have sponsors, birds of a feather and keynotes. But they spend the majority of the day debating where they want to take their community next. When there is a diversity of opinion on an issue this creates an electrifying atmosphere, unlike any I’ve experienced elsewhere.

There is constant debate in our communities. Whether it’s what Ruby testing framework to use this week or whether it’s sacrificing another sacred cow of Agile. Instead of reflecting this debate we have one-sided conferences which don’t express the spectrum of opinion on the latest issues.

A debating format

I would like to suggest that for part of a conference we use a debating format.

Conferences during the CFP ask for topics to debate. From this list a few key proposals will be chosen on subjects like “Are estimates harmful?”. A champion must be chosen for both sides of the issue, followed by a second person to give additional perspective.

Given a 45 minute session:

  • The announcer introduces the topic and asks the room what their current voting intention of the topic is
  • The champion for the subject has 7 minutes to make their point
  • The champion against the subject has 7 minutes to make their point
  • The seconder for the subject has 5 minutes
  • The seconder against the subject has 5 minutes
  • The champion for is given 3 minutes to sum up and respond
  • The champion against is given 3 minutes to sum up and respond
  • The announcer asks the audience to vote again and announces the outcome of the vote

Feel free to scale up or down the number of speakers and time allotted to them.

These debates coould be encouraged to happen spontaneously if for example the keynote speaker says something controversial.

So what do I want?

I still think that we can enjoy and learn from the traditional classroom conference format. But I think we are rather lazy in the way that we rely on it so heavily. Let’s get political.


How to get started with Continuous Integration

Recently a friend asked me how they could get started using Continuous Integration (CI). I’ve written about the theory and practice behind CI before.

Here is my checklist for getting your application and team going with CI:

  1. Find the main integration branch in your VCS (trunk, master or an integration branch)
  2. Work out how to build the application locally
  3. Automate this build in a single script
  4. Choose and setup your CI software (i.e. Jenkins, TeamCity, TravisCI)
  5. Get the application building on the CI (first get the version control checkout, then use the build script)
  6. Let everyone on your team know where the CI job is
  7. Inform your team about the options for notification of broken builds (email, IDE plugins, desktop notifiers, TV with dashboard)
  8. Encourage everyone to commit at least once a day
  9. Make sure the team know they have to keep the build green

If you are looking to use a TV dashboard I highly recommend Dashing, which is a lovely Metro-like dashboard that runs in your web browser.


Move your mouse pointer with Java

At work we have a big TV screen with a build status being displayed. The desktop support team had a large lead time on changing the settings to stop it locking the machine every 5 minutes. This was the temporary workaround.

The java.awt.Robot has a few other interesting methods like taking screenshots, getting the colour under your cursor and clicking the mouse.

This code has no dependencies.

import java.awt.Robot;
import java.util.Random;

public class MouseMover {

    public static final int FIVE_SECONDS = 5000;
    public static final int MAX_Y = 400;
    public static final int MAX_X = 400;

    public static void main(String... args) throws Exception {
        Robot robot = new Robot();
        Random random = new Random();
        while (true) {
            robot.mouseMove(random.nextInt(MAX_X), random.nextInt(MAX_Y));

What’s your problem?

Google don’t do Test Driven Development, so I don’t see why I should either
Countless software devs

We live in a world where people love to apply quick fix solutions to problems. Lose 10kg in 2 weeks! No cash until payday? Borrow £100 at 30000% APR! We crave these simple solutions, and deeply want to believe that they can make our lives better.

It’s a good idea to look at the context we are in, then work on a way to change the system that governs that context. Once we understand the system we can then look at adopting tools to help us.

For both of the examples I gave in the introduction a good question would be: What’s your food intake and exercise like? How are you spending your money currently? But people don’t do this. They are far more interested in the next miracle fix. Sadly in the IT world we are just as susceptible to quickly grabbing a new tool that worked for someone else, then either blindly going with it or quitting in absolute disgust.

We can improve the process we use to select tools to remedy our problems. The key to this is to stop only focusing on how a tool works and its benefits and start by asking what problem the tool solves. The first two parts are important, but useless without knowing if it’s solving a problem you have.

I suggest we use this checklist when considering any new tool or practice:

  • What problem does it solve?
  • How does it work?
  • What are the benefits?
  • Will this work in my context?

A lot of people have a strong reaction to BDD and Cucumber so let’s use that as an example. We’ll use a shortened summary of the checklist items then consider a recommendation for two different personas.

Cucumber checklist summary

Cucumber solves a number of problems often seen in software development where misunderstandings are rife. In particular it solves the problem of the business speaking a different domain language from the development team by asking them to collaborate on acceptance tests together in a simple natural language script.

Its benefits include living documentation, automated acceptance tests, and encouraging an outside in view of software development.

Is Cucumber right for Angus?

Our first persona will be Angus. Angus had an idea for a mobile app and hired two people he trusts to help him build it. Angus has heard great things about Cucumber at conferences and wants to try it out with his team.

Angus doesn’t have a major problem with miscommunication within his team. If he tries Cucumber he’ll probably decide that he doesn’t like “the extra layer of indirection” Cucumber introduces. As the readers of the tests are all technical, he could get the same benefit from just writing outside-in integration tests in the testing framework he’s already using.

Angus should look for other methods, or invent his own, that can give him some of the other benefits that Cucumber brings.

Is Cucumber right for Bruce?

Bruce works for a medium sized digital agency who specialise in online shopping sites for a wide variety of clients. His customers like to run discount campaigns during different seasons. Currently he gets the client to write the pricing rules down in an email which he turns into code.

The product owner for Bruce’s project is not part of the team. By using Cucumber’s acceptance criteria with the client he could quickly discover problems with his understanding of the pricing code and also open up other conversations with his client.

Bruce should look into adopting Cucumber.

Context is king

When you hear about a tool you need to look at the problem it solves, the other benefits it brings and consider if this makes sense in your own context. The misapplication of tools leads to pessimism and waste. We should be optimistic about new tools, but grounded in our current context. Context is king.


Everyday Git Aliases

Git gives you as much flexibility in how you construct your VCS workflow as it does for the commands you use on your local repo. In your gitconfig file you can add alises for your favourite commands, in this article I’ll talk about mine. You can see my gitconfig on github.

git standup

alias for git log ––since yesterday ––author joe

Just about to head to a standup but you can’t remember everything that you did yesterday? This command will come to your rescue. It only lists what you did in the last 24 hours.

3400455 - fixed the whizzbang (Mon, 1 Apr 2013 13:57:37 +0100) 
5dae0a0 - whizzbang feature (Mon, 1 Apr 2013 13:57:32 +0100) 

git purr

alias for git pull ––rebase

In Git you have public and private branches, public branches are the ones on github (or your own git host), private branches are in your local git repo and are setup to be tracking or topic. A tracking branch is linked to a public branch and a topic is only in your local git repo.

You have two options when you want to integrate changes between branches, either you merge or rebase. By default when you do a pull on a tracked branch it performs a fetch then a merge. If you’ve made changes locally and someone else has pushed changes to your git host then git will automatically merge these together with a merge commit.

4ffe733 - Merge branch 'development' of github.com:YourCompany/project into master

On an active project with other colleagues using pull will generate a load of these noisy commits in your projects history. I only like merge commits to be in the history when a topic branch has been reintegrated. Tracking branches should have a linear history.

When you do a git pull ––rebase, git fetches the changes from your remote repo and then perform a rebase rather than the default merge. A rebase resets the HEAD of your local branch to be the same as the remote HEAD, then replays your local commits back into repo. This means you don’t get any noisy merge messages in your history. As well as giving a linear history, this also helps when using bisect.

git st

alias for git status -sb

Git gives a verbose output when you perform a status which is excellent when you are getting started with git. As you become used to the output you want a shorter version. The output of this alias shows a single letter that represents the change type and reports how far ahead of the remote branch you are.

## master...origin/master [ahead 2]
A  g
D  gitignore

git ready

alias for git rebase -i @{u}

Once you’ve committed a few local changes you’ll want to share them with your team by pushing to your git host. Before I push I always run the git ready alias to see what’s going to be pushed so I can reword commit messages and squash related commits together. git ready performs an interactive rebase on your unpushed commits.

Let’s say I’ve pushed two commits that are related to a new feature and I have another where I made a spelling mistake in the commit message. When I run git ready I get dropped into vim with this input.

pick 7f06d36 whizzbang feature - adding fizzbuzz
pick ad544d0 whizzbang feature - minor refactoring to fizzbuzz
pick de3083a spelling mizzztake

I want to squash the two whizzbang feature commits together. So I change pick to say s to squash the two together into a single commit. I also want to reword the commit with the spelling mistake. To do this I make the file look like:

pick 7f06d36 whizzbang feature - adding fizzbuzz
s ad544d0 whizzbang feature - minor refactoring to fizzbuzz
r de3083a spelling mizzztake

This gives me two new commit messages to edit, which I update. Now when I push the remote repo host receives two commits

3400455 - spelling mistake
5dae0a0 - whizzbang feature 

git lg

alias for git log ––pretty=format:’%Cred%h%Creset -%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’

When I’m viewing history I just want to see the SHA, the commit message, who made the commit and how long ago. This custom log output gives me:

3400455 - spelling mistake (20 minutes ago) 
5dae0a0 - whizzbang feature (28 minutes ago) 
efaea80 - Removing trailing space on save (4 days ago) 
c351700 - Copying to system clipboard in vim (5 days ago) 

I’d be interested to hear about your favourite git aliases too.