Sun 21 August 2016 by Jim Purbrick

At the 3rd Party Dev State of the Union at EVE Fanfest 2016 earlier this year, CCP FoxFour drew my attention to a limitation of the current approach used by crestmatic to generate CREST documentation: it only discovers resources always reachable from the API root from the perspective of the authorised character at generation time. As CREST now includes APIs for transient resources like fleets the entire API isn’t reachable for documentation from a nightly run using the credentials of a character not in a fleet.

There are a couple of ways to fix this. At the API level OPTIONS responses could refer to linked representations that can exist. An alternative is to extend crestexplorerjs with OPTIONS metadata to make it expose live documentation about reachable resources.

At a recent hackathon I took the second approach. crestexplorer now makes OPTIONS requests to each resource it requests and uses crestschema and data urls to generate downloadable JSON schema descriptions for each of the representations available for a resource. It also hyperlinks to the alternative representations so now all representations of all reachable resources are available in crestschema and the human readable descriptions of each field are added to the rendered resource as hovertext.

Now documentation for any valid CREST resource live by specifying the URI for the resource as the crestexplorer hash fragment. Even when the resources are transient documentation is available for resources while they exist.


Sun 03 January 2016 by Jim Purbrick

A year ago I gave a talk at EVE Vegas about building RESTful CREST applications. My #1 recommendation was to specify representations in requests, but that’s hard to do when there is little documentation on which representations are available and what they contain.

Fortunately CREST is self describing: send ...

read more

Free Tests For Everyone!

Thu 11 June 2015 by Jim Purbrick

Modern software development is sometimes colourfully described as being similar to firing tracer bullets at a target. Rather than spending time doing a lot of research, design and specification up front, the smallest, simplest version of the software is built and the feedback gathered from its use is used to ...

read more

Investing In Testing

Wed 10 June 2015 by Jim Purbrick

Droidcon London

Last year I was talking to an engineer at Droidcon London who was working on an Android app with 100% test coverage. I immediately asked whether he thought 100% test coverage was worthwhile: many software engineering teams strive to achieve 100% test coverage, but few succeed because it’s an ...

read more


Mon 18 August 2014 by Jim Purbrick


One of the things I’ve been working on since joining Facebook is Buck, an open source Android & Java build tool which is significantly faster than many other Java build tools for a number of reasons.

As well as being fast, Buck gains a lot of power and flexibility by ...

read more
Fork me on GitHub