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...
Disclaimer: this approach won’t be suitable for everybody, please factor in your particular requirements before using it.
Towards the end of 2018, our client started to move our codebase from AngularJS to Angular 7+ (now 8). While this, in itself, is a great move, it completely broke our A/B testing capabilities. (What's A/B Testing?) Implementing deep changes to our Angular applications would be much more challenging. The methods we used to amend code on bootstrap of AngularJS applications are no longer available in Angular2+. If you are interested in A/B testing in AngularJS applications, you can read about our previous approach and Adobe setup.
While some A/B testing can, and should, be done from the backend, this article will focus on the frontend approach.
It was early morning rush hour on Friday, June 22nd, and the Melbourne winter sun shone on my face. I was attending Angular Conf Australia, being held at South Wharf. Arriving with just enough time to spare, I looked around the conference venue and had a quick chat with some of the participants.
After a slight delay, the conference kicked-off with a quick thanks to sponsors and supporters. In this post I'm going to give you a rundown of what I saw next.
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.
[caption id="attachment_6264" align="alignnone" width="500"] 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:
Initial annoyance at having to do it
Slow progress reworking sections of markup
Growing satisfaction that the app was becoming accessible to a broader audience
The realisation that the codebase itself was actually better off for the process
In this post I’ll talk about the 3 things that I’ve done so far during this journey to an accessible Angular app: accessible icons, keyboard navigation and finally, ARIA support.