I just spent a couple of days at the YOW! Connected conference and had a great time, despite nursing a bit of a cold. There were a tonne of great talks at the conference covering a wide range of topics, but in this post I'm going to briefly reflect on one specific trend that interested me at the event: the way in which UI platforms are advancing to adopt modern languages, and are even influencing each other in the process. The end-result: they're all moving towards languages that are both functional and statically typed.
Full disclosure: This year I was a member of the programme committee for the conference. So in writing this post, there's a bit of a risk that I'm creating an echo chamber for myself. All I can really say in my defence is that I hadn't consciously made these connections in advance - it was only afterwards that I saw a trend!
Shine developer and resident AEM expert Michael Leroy will be speaking at the Adobe Source event being held in Sydney on Oct 12 and 13. Michael will be presenting twice. The title of his first talk will be "Building a corporate site solution using Multi Site Manager"....
Every couple of months I'm in a meeting where a couple of developers start arguing about which HTTP status codes to use in their RESTful API, or where they decide to not use HTTP status codes at all and instead layer their own error-code system on top of HTTP.
In my experience, HTTP status codes are more than adequate for communicating from servers to clients. Furthermore, it's preferable to stick with this standard, because that's what most client and server-side HTTP libraries are used to dealing with.
When it comes to which status code to use, the truth is that most of the time it doesn't matter, just so long as it falls within the correct range. In this post I'm going to outline what the important ranges are, and when you should use each one.
If you control both the client and server, these guidelines should do just fine. If you're writing a more generic RESTful service where other people are writing the clients, you may have to be a bit more nuanced. Either way, this rule-of-thumb is a good starting point to work towards the simplest solution possible for your particular problem.
The best piece of advice I ever got regarding a personal software development process was from a grizzled old Unix developer with a neckbeard. OK, that’s not true - it was actually from a clean-shaven principal consultant and architect at a company I used to work at, but that doesn’t sound nearly as impressive.
Nevertheless, the process went something like this:
Having tried all manner of processes over the years, this is the one that has served me best. Let me break it down for you if you’re having trouble understanding it.