Do you need Zend Framework training or consultancy? Get in touch!

Ctags with Swift

I always seems to end up in vim sooner or later and I use Tim Pope's excellent Effortless Ctags with Git process to keep my ctags file up to date for my projects.

As I'm now coding in Swift too, I needed ctags to support Swift. This is what I've added to my .ctags file:

Any improvements, welcome!


As I'm writing about Swift and vim, I should also point out that the vim-swift plugin by Kevin Ballard is a must-have!

Iteration in fixed-everything projects

There are three main variables when setting up a project with a client: price, scope and time. The more flexibility we have here, the easier it is to run an agile project.

This is especially true when the scope is not fixed as agile development techniques really start to come into their own. Short development cycles of small, minimal, features allow the client to see the progress of the project earlier and so direct the shape of the project to ensure that a successful project is delivered.

Fixed-everything projects

However, sometimes it's really hard to persuade a traditional client (and especially their financial department) to sign up for a variable scope project. Sometimes you even end up on a project that's fixed-everything; the project has a fixed set of requirements listed in the contract, along with a hard delivery date and a fixed price.

As a result, you tend to see waterfall type development processes used. I think this may be partly due to lack of experience by the PM and also it seems "logical". The contract has the requirements listed, along with a deadline and budget; hence you have a timetable. To the inexperienced PM, it seems logical to start with the design, do the build, test and then deliver.

Projects that follow this path are rarely successfully delivered to a happy client.

Agility helps

In an agile project, the requirements and hence what is delivered shift during the project as the customer understands what they actually need isn't quite what they ordered. In Scrum, this is managed by the prioritisation of the backlog items based on business value. New items with more business value are added to the backlog as we learn what's really required for this project to be a success. However, this doesn't always work so well with a fixed price, scope and budget.

Nevertheless, I strongly believe that to succeed, key features from agile processes are required and the project manager needs to maintain a firm grasp of what's going on though to ensure that the contract requirements are met by the deadline.

For me, the key feature of the agile process is iteration. By delivering the project to the client in small increments, the client is able to see the direction early and correct misunderstandings while there is still time and budget available. This is where a good project manager comes into their own. As the project progresses, the scope of change that the client can make is smaller, due to the oncoming deadline and lack of remaining budget. The project manager needs to reign back the client in later stages.

Each iteration needs to be a something that the client can comment on and ideal sign off as complete. It can also help if the iterations are in an order that makes sense to the client. While the scenes in a feature film is shot in a very different order to the what we seen in the final film, I've found that clients rarely want to sign off say the shopping basket before they've seen how the product catalogue looks.

As with all project management, communication is key. Clients come up with all sorts of great ideas once they start seeing the project come alive. One of the roles of the PM is to keep this in check as the project's success is measured by the contract requirements, not by a new great idea. Don't allow the project to be derailed by a change late in the day. If the client says that it's a "must have", then a contract change or extension is required. I've found that creating a "next phase" list is helpful and encouraging the client to to place all the new work onto this list. If nothing else, it starts the process of getting the next contract.

To sum up

So, in summary, try not to be fall into the trap of a waterfall-based development process just because you have a fixed project. Iteration is one of the best ways I've found to successfully deliver and works on all projects, especially the ones with the most constraints.

Notes on keyboard only use of OS X

It's been a while since I could use a trackpad without pain and even longer since I could use a mouse or trackball. Currently I use a Wacom trackpad as my mouse which works really well as long as I don't use it too much. Fortunately, keyboard usage doesn't seem to be a problem (yet?), so I try to use my Mac using only the keyboard as much as possible. These are some notes for others who may be in the same boat.

This is a potpourri of items as I think of them. Hopefully, over time, I'll come back to this article and organise it better!


A launcher application is invaluable. Spotlight is built in to OS X and bound to cmd+space. However, I use Alfred with the keyboard shortcut set to the same cmd+space as it's more powerful. This lets me open applications, folders and run scripts very easily.


Shortcut allows me to click on any control in a native application (known as Cocoa applications) via the magic of OS X's built in accessibility system. This is fantastic and has to be seen to be believed. I've bound it to alt+space and once activated, I type in the first letters of the thing I'm trying to click and it will highlight it. I can them press enter to click it, ctrl+enter to right click it, etc. Even more usefully, typing . into the shortcut box will highlight every control in the window, so I can click on items that do not have any associated text.

It is this tool more than anything else, which has made Safari my main browser.

Keyboard access to the menu

One of the nice things about well-written Mac native apps is that pretty much all operations are available as a menu item. You can access the menu via the keyboard by pressing shift+cmd+?. This opens the Help menu with the search box focussed. You can now type the first few letters of the menu item you're looking for and easily find it. Alternatively, use the arrow keys to navigate the menu.

Note that on OS X, some menu items have alternatives. Hold down the option key to see those.

For right clicking, I use shortcat. This is rarely needed on OS X as the right click menu's items are usually available directly from the main menu.

Moving and resizing windows

I use Mercury Mover which I really like. I'm not sure that it's still offered for sale though. Alternatives include Moom, SizeUp, Phoenix and Spectacle.


As I've said, Safari is my main browser as it supports Shortcat and the cross-platform ones don't. However, I have a link selector extension for all three main browsers as it's quicker on Safari for well written HTML and the only option in Firefox and Chrome:

Other resources

See also:


Every so often, I will get "stuck" in a control or app and can't get out. This is really frustrating and invariably, the only solution is to use the mouse. The web in particular is the most problematic, including apps that are essentially websites in a window. I've also noted that apps that write their own versions of the native OS X controls are generally inaccessible as invariably the developer doesn't hook into the Cocoa accessibility framework with their own control.

OS X has a really good accessibility framework and it seems that all native apps get it for free. As a result, it's certainly possible to use OS X without a mouse with the right tools and knowledge.

View an SSL certificate from the command line

I recently had some trouble with verifying an SSL in PHP on a client's server that I couldn't reproduce anywhere else. It eventually turned out that the client's IT department was presenting a different SSL certificate to the one served by the website.

To help me diagnose this, I used this command line script to display the SSL certificate:

Running it against, the start looks like this:

In my case, I noticed that when I ran this script on the client's server, the serial number and issuer were different, and that's when I worked out that PHP was telling me the truth and that it didn't trust the certificate!

Cross-platform Makefile for Swift

I'm mostly building Swift applications for deployment to Linux, but sometimes it's easier to build and test directly on OS X rather than spinning up a VM. To facilitate this, I use a Makefile that means that I don't have to remember the compiler switches.

It looks like this:

Let's go through it.

This simply sets which version of Swift this project uses. It's up the top as this is the only line that I change on a regular basis.

This section allows for different compiler and linker switches for each operating system.

We're compiling libdispatch on Liux, so we need to enable the blocks language feature in clang. This is done by using the -Xcc switch to tell the compiler to pass the next switch (-fblocks) to clang.

For linking on OS X, I nee to pick up the Homebrew Mysql library in /usr/local/lib. This isn't needed on Linux as apt puts the relevant library in the right place. However, on Linux we need to link against a library in our own .build/debug directory, so we pass the switches for that. In the same way as -Xcc, -Xlinker passes the next parameter to the linker (ld). We need to pass -rpath .build/debug, but as we can only pass one argument at a time with -Xlinker, we do it twice.

These are the standard make targets for building, testing and cleaning up intermediate files. By using the standard names, working on different projects is very easy and predictable as the same make commands work everywhere.

The init target is specific to my Swift projects. It sets the correct local Swift version for this project using swiftenv. The - before the swiftenv install command ensures that make continues even if this command fails (which it will if the version is already installed).

We then do something that's specific to Linux and install lib-dispatch which we need for GCD. It's included already in OS X, which is why this is guarded by the ifeq ($(UNAME), Linux).

That's it. This is a simple Makefile which leaves me to think entirely about my code, rather than my build system.

View header and body with curl

I recently discovered the -i switch to curl! I have no idea why I didn't know about this before…

Curl is one of those tools that every developer should know. It's universal and tends to be available everywhere.

When developing APIs, I prefer to use curl to view the output of a request like this:

-v is for verbose and so you get told all the information you could possibly want. However, usually, I only want to know the response's headers and body.

Enter the -i switch!

Much better!

-i is for include and from the man page:

Include the HTTP-header in the output. The HTTP-header includes things like server-name, date ofthe document, HTTP-version and more…

This is exactly what I want without the information that I don't!

swiftenv: Swift version manager

Swift 3 development is so fast at the moment, that a new development snapshot is coming out every couple of weeks. To manage this, Kyle Fuller has rather helpfully written swiftenv which works on both OS X and Linux.

Once installed, usage is really simple. To install a new snapshot:

Where {version} is something like: DEVELOPMENT-SNAPSHOT-2016-05-09-a, though you can also use the full URL from the download page.

The really useful feature of swiftenv is that you can set the swift version on per-project basis. As change is so fast, projects are usually a version or so behind. e.g. at the time of writing, Kitura's current release (0.12.0) works with DEVELOPMENT-SNAPSHOT-2016-04-25-a.

We register a project specific swift version using:

i.e. for Kitura 0.12: swiftenv local DEVELOPMENT-SNAPSHOT-2016-04-25-a

Nice and easy!

Filtering the PSR-7 body in middleware

Sometimes, there's a requirement to alter the data in the Response's body after it has been created by your controller action. For example, we may want to ensure that our brand name is consistently capitalised.

One way to do this is to create middleware that looks like this:

This works perfectly, so if my response body contains "I consult through my company, nineteen feet.", then the output of the middleware$brandFilter middleware is "I consult through thought my company, Nineteen Feet.", which is exactly what we want.

That's great, but what happens if the new string is shorter than the old one? For instance, suppose I want to replace all uses of "nineteen feet" with "19FT".

Using the same middleware, but changing the str_ireplace call with:

creates this output:

That's not quite what we wanted! This result is because the new string is shorter, so the characters from the old string are still in the PHP stream and as we haven't change the length, they are still there. The PSR-7 StreamInterface doesn't allow us access to the underlying stream, so we can't call ftruncate on it.

Hence, the easiest solution is to replace the Response's PSR-7 StreamInterface object with a new one containing what we need:

The output is now what we expect:

Slim 3.4.0 now provides PSR-7!

I've been neglecting Slim's PR queue recently, so this weekend I dedicated a lot of time to merging all the good work that our contributors have done. As a result, I'm delighted to release version 3.4.0!

This release has a larger set of changes in it than I would have ideally liked which is a direct consequence of having gone two months between releases rather than one.

One particularly interesting addition that we have a made this release is adding a provide section to our composer.json file:

This means that we have informed Composer that Slim provides a valid implementation of the interfaces in psr/http-message-implementation virtual package that defines the PSR-7 interfaces.

This means that when you install a Composer package that requires psr/http-message-implementation in your Slim project, then Composer will now recognise that Slim satisfies this requirement and won't insist you install another PSR-7 implementation just for package resolution!

There's lots of other goodies in 3.4.0, so check out the release notes and upgrade!

Compiling Swift on Linux

Swift is open source, which means that we can build it ourselves. This isn't too hard to do, but takes some time.

Set up the dependencies and grab the code

Firstly, you need a lot of memory and as it takes ages, give your VM plenty of CPUs! My Macbook Pro has a quad core process, so I tell Virtualbox that it can use all 4 using this configuration in my Vagrantfile:

You then need all the dependencies inside the VM:

If you want to build the docs, then you also need Sphinx:

Now grab the code from GitHub:

In addition to the core swift repository, you also need a number of other repositories and fortunately, there's a script to do this for us:

Alternatively, if you don't want to do all this manually, you can just grab this Vagrantfile from IBM.

At a later date, if you want to collect the latest changes to the source files just run update-checkout with no arguments:

Introducing build_script

To compile Swift we use a script to do it all for us. This one is called build-script which takes a number of different parameters. Use -h to see what it provides.

In order to successfully build in 8GB of RAM, we need to build without the debug symbols, so we use the -R switch for that. To also run the tests, we need -t and if you want to build Foundation and XCTest, you need to add the switches --xctest and --foundation.

The simplest build command, however, is:

This is a good time to get a cup of tea. On my computer, it takes 55 minutes to build… Once built, the binaries are in build/Ninja-ReleaseAssert/swift-linux-x86_64/bin.

Compiling for usage

When you build with -R, you're building for contributing to the compiler and associated libraries. If you want to build so that you can then use the tool chain for writing Swift applications, then the easiest way is to use preset which creates an installable package:

Again, this takes a while to do!!

Once done, you have a fully working swift package at ~/swift-install.

Test using: