Michael Heap mheap

Capturing an API's behaviour with Behat

Once an API is shipped it doesn't matter if it behaves as originally intended - how it actually behaves is the important part. Consumers depend on it's existing behaviour and we need a way to capture that and ensure that it doesn't change. This is where Behat comes in. Behat is a BDD tool that was built to help design software, but it’s actually a fantastic tool for testing APIs after they have been developed too.

We’ve successfully used this technique to give us the confidence to refactor 5+ year old applications by capturing the existing behaviour before making any changes. Now, I want to share the secrets we learned with you. You don't need existing Behat or testing experience, just a desire to prevent breaking changes in your API.

Integrating open source

You might be stuck working with an internal framework that’s like nothing you’ve ever seen in the wild, but that doesn’t mean you can’t leverage the power of open source in your projects.

Together, we'll take a look at what Composer is and what it can do for you, as well as open source libraries that we can use to solve established problems such as logging and access control.

By taking a look at common problems and how we can integrate freely available tools into our bespoke frameworks we can minimise the amount of code that we have to maintain ourselves, leaving us to do what we do best: build meaningful software.

Not Invented Here Syndrome is a big problem in a lot of companies that believe that what’s out there isn’t suitable for them. They believe that they can do a better job writing something custom than adapting open source products.

This talk covers a lot of common problems that emerge in day to day development and takes a look at the available solutions that have been adopted by hundreds of companies. From things like logging and metrics to database access, this is a whistle stop tour of all the technologies out there that you could be using today.

Move over Jenkins, there’s a new kid on the block and it’s called GoCD.

GoCD is a continuous integration system developed by Thoughtworks and open sourced in 2014. At it’s core, it’s a pipeline based build system that takes an input (or multiple inputs) and runs commands that you define on it.

This talk is a basic introduction to application packaging and continuous delivery, along with an overview of GoCD and how it can be used to ship continuously.

We’ve all used HTTP before - we use it every time we go to Google or Facebook, every time we refresh our Twitter client on our phone.

HTTP is a very well defined protocol that we can use to build our own apps. It guarantees a response if you make a request, it has predefined error codes that everyone implements and it’s a very simple format to read if you need to inspect what’s going on by looking at it.

This talk takes you through HTTP, starting at the beginning with how a connection is established, parsed and how the response is formatted. We’ll also cover things like status codes, common headers and some advanced topics such as HTTP streaming and web sockets.

	# Maintainer: Michael Heap <[email protected]>
	pkgname=git-rook
	pkgver=0.0.1
	pkgrel=1
	pkgdesc="A git hook runner that can be used to execute multiple hooks in a git repository."
	arch=('any')
	url="https://github.com/mtdowling/git-rook"
	license=('MIT')
	depends=('git')
	checkdepends=('bats-git')

	package main

	import (
	"flag"
	"fmt"
	"os"
	)

	func main() {
	name := flag.String("name", "", "your name")

	# Set up some variables we need
	test -z "`xrandr \| grep '^HDMI1 connected'`" && HDMI_ON=1
	test -z "`xrandr \| grep '^DP1 connected'`" && DP_ON=1

	# Both on, I'm probably at work
	if [[ -z "$HDMI_ON" ]] && [[ -z "$DP_ON" ]]; then
	bash ~/.screenlayout/work-desk.sh

	# Only the HDMI on
	elif [[ -z "$HDMI_ON" ]]; then

	<?php

	// Interestingly, a null value in an isset() check will return false

	$r = array(
	"a" => 1,
	"b" => null
	);

	echo "a: ".(isset($r['a']) ? 'Yes' : 'No').PHP_EOL;