If you have documentation for any sort of HTTP-based API, from a micro-service to a non-trivial RESTful API, if it has existed for more than a week it has got some mistakes in it. Documentation degrades over time. This article aims to help you ensure that your API documentation keeps entirely in line with the implementation, utilizing two tools: API Blueprint and Dredd.

A few months ago I wrote a bit of an emotional article about my visa status, and how I was in a bit of a pickle. A few people since have wanted an update, so here it is.

I've been talking recently about what The League of Extraordinary Packages is up to in regards to components, and made a plea to avoid "Not Invented Here" syndrome to help the community focus on quality instead of quantity. Today I noticed a new pet-peeve.

In the last article I said I wanted to write about when its a good idea to release a component. A lot of this comes down to: is there one out there that does what I want, and if so, can I use it? Should I release a PR or make my own? Why should I maybe avoid writing something that already exists?

As a developer working with multiple languages regularly, I come across a lot of different ways of doing things. Some of the flows and development tools available in other languages are nothing at all to do with the language, they were just something a developer using that language decided to do. Now and then, those things cross the "barriers" between languages, and PHP gets some nice new toys.