In this post I want to share a story. The story is about how I added semantic-release to an existing Angular library project. It's also about some of the errors I encountered along the way, and how I resolved them. There aren't many such stories...
A couple of weeks ago I attended ComponentsConf 2019 in Melbourne, Australia. This conference focuses on JavaScript frameworks and libraries, and I was pretty excited to attend it. This is because over the last year I have been working on a component library to be shared across a number of projects. It needs to work in everything from Drupal to Angular, and we're still trying to find the best foundation to build it on. A conference that is framework-agnostic seemed like a good place to learn more about the options that are available.
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.
A clash of the old-school and new-school[/caption]
Over the last couple of years at Shine we’ve built a number of Single Page Apps (SPAs) for large businesses. An app we recently built had to integrate with Oracle Access Manager (OAM), an Identity Management System (IDM) from everybody's favourite enterprise software company. In this post I'm going to talk about a strategy that we used to successfully work around mismatches between the way that SPAs and OAM do things.
I recently did some preliminary work adding accessibility support to an existing Angular application. At the start of this work I knew very little about website accessibility, and I suspect the evolution of my thinking during the process would be common amongst other developers who have been in the same situation. Specifically: