Want an integrated deployment process that sends tags off to the right environment (QA or Production) automatically as soon as they're pushed to Git? Read on!
When planning my talk and book on REST/HTTP API development, I ended up mentioning documentation towards the end, and flippantly said "Oh and API Blueprint is pretty good probably just use that." This is something I'd love to fix with a time machine, as these days I spec out an API in API Blueprint before I get anywhere near the code.
Regularly, I make a general piece of advice, and the types of responses are pretty similar regardless of the actual conversation.
Don't be fooled into thinking you can use HTTP status codes on their own. You need to supplement them using error messages, with maybe some specific error codes of your own and links to documentation explaining what the problem is.
Something we're always taught as developers, usually by tutorials or via the defaults in various ORM tools, is every SQL table needs an auto-incrementing ID. This is a weirdly common fallacy, enforced by old tutorials, new tutorials and half-arsed tooling in various forms. Why are auto-incrementing IDs a problem? Because it means people can download your database.
In 5 weeks I'll be riding my bike a really long way to raise money for charity. Sadly, as I ride bikes all the time, not so many people are interested in forking out. Luckily, I have a plan!
There are a lot of my opinions and viewpoints that have changed over time. Some slowly and naturally, and some sharp and sudden like a wet mackerel to the face. One is on the ratio of women speakers when it comes to tech conferences.
A lot of things in programming are argued to death, but one subject where people almost unanimously agree is that magic numbers can be a pain in the ass, and they should be avoided whenever possible. Sadly when it comes to HTTP status codes, people keep on hardcoding them, and it leads to all sorts of confusion.
Back in 2013 I did a three-day ride from Boston to New York, along with hundreds of amazing people. Everyone was in various levels of fitness and with various levels of interest in cycling, all who had come together with the aim of helping raise a shitload of money to help those living with HIV/Aids.
I’ve been working at Ride.com since October 2014, and I’ve got to do some awesome stuff with them. As far as my job has been concerned, the first 4-5 months were entirely green field development. As a team we built multiple services to compliment a central API, and with the help of some other gophers at the company I built most of a little Go service to handle various autocomplete requirements.