Made in Production has been something that my BFF Zack and I have been working on for a while. We had the idea to start selling super-niche programming t-shirts in 2013, we finally got the store up and running on some janky Python in 2014, then shut it down after a few months due to a slew of unforeseen problems. Now the site is back and better than ever, and I thought I'd tell you lot a story.
File uploads are one thing that always feel rather complicated, and working out how to handle this in an API doesn't make life easier. For many programmers, this has been abstracted away behind the HTTP standard, HTML and convenient features in languages like PHP, that populate a $_FILES array for us to play with. This is not really how it works for an API.
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.