But what if you then want to switch to another API provider? Maybe the one you were using isn’t accessible, doesn’t support the older browsers you need? Maybe they put their prices up? Whatever the reason you may need to switch at some point.
There is a better way.
Rather than working directly with an API and using the properties and methods in your code, you create an intermediary, your own internal service, which handles this functionality. The internal service maps the properties and methods you need to those of the third party API. It handles any data transformation needed. Your app works with this service, your own API, so that when a change of service provider is needed the app itself does not need to be rewritten, just the internal service.
An internal service can also be set up to work with multiple APIs at once so it maps everything it needs for each. This allows you to push choice to your users. So, for example, if it’s a news, sport or weather feed built into a site, you can let your user choice their preferred information source. You could use different services for different regions, e.g. local news.
To use a slightly inappropriate analogy, it’s better to be dating these APIs than to move in with them. 😉
Just thought I’d pass on a few tips that I’ve been given for setting a password that won’t get hacked.
Passwords can be hacked in two ways – being guessed by a human or being “brute forced” by a computer. Brute forcing just means trying lots of different passwords until it succeeds and powerful computers can do a lot in a short time.
The more characters you use, the more possible combinations there are and the longer it would take a computer to crack. To keep it easy to remember but hard to crack, try using a few words. However, you should avoid any common combinations of words, such as well known song lyrics, which may be more guessable. Random, unconnected words are best.
How Secure is Secure?
You can actually get a measure of how secure your password is on the aptly named https://howsecureismypassword.net/. This site will estimate how long it would take a computer to crack your password. You want this to be so long that it wouldn’t be possible within your lifetime. You should ideally allow far longer than seems necessary as computers will inevitably become more powerful and faster over time. I’d aim for at least a millennium (1000 years) but the longer the better.
The final check is to see if your chosen password has been previously involved in a data breach. When companies’ user accounts are hacked, the usernames and passwords used are stored (not together) in a public database so they can be flagged as unsuitable for reuse in the future. The service https://haveibeenpwned.com/ allows you to check if your password is safe from being on hackers’ known password lists.
Pass It On
Please pass this info on to anyone and everyone so that we’re all safer. Share or feel free to copy and reword the content of this post however you see fit, just get the message out there. No more Pa$$word1.
* It looks like a weird typo but ‘pwned’ just means hacked.
Having to support a minority of users on IE11 is painful. It’s a browser that is still officially supported by Microsoft, until 2025, but active development has stopped, or at least slowed right down, so the gap between it and other browsers is growing wider with every update.
The growing feature gap means either not using newer features if we’re working to the lowest common denominator or else having to provide polyfills or fallbacks so IE11 can still be used.
But there could be a light at the end of the tunnel, and before 2025. Microsoft Edge is moving from using the EdgeHTML engine to open source Chromium, which will bring it in line with Chrome, Opera and Safari. That’s nice for compatibility but the big deal is that it will be available on older Windows operating systems. Up until now Edge was only available on Windows 10 but it will soon be available on 7, 8 and 8.1 too so more users can drop IE and use Edge as their official Microsoft browser.
The Edge team are going one better than that though. One of the big reasons for clinging on to IE is the use of legacy software which only works on that browser. Edge is introducing an IE11 mode, so users can seamlessly (hmm – I can already hear the massive crash) switch over to IE for specific sites. Very clever.
It looks like we might have a way out of IE11 support in the next 12 months or so. Just need to convince the large corporations to make the switch now but I’m sure Microsoft will be pushing hard on this too. Good news.
I’ve got a little trick to make the processing of lists appear to go faster than it actually does.
Let’s suppose we have a list of 10 items and there’s some kind of processing to be done on them, maybe sending them off to a service which returns a Boolean true/false response for each. In reality we post a single request with the data of the 10 items and we get a single response back after 3 seconds.
In the UI we can use animation to make it look as if each item is being sent one at a time by adding a 100 millisecond delay between each state change. This means that the user thinks the last item of the 10 is sent after 1 second but in reality it’s already gone a second ago buying us extra time.
When we get the response, rather than show all the results immediately, we can use a similar animation to make them appear one by one with a 100 millisecond delay again. Although this is slower than just showing them all it maintains the illusion of the items being processed one by one.
So, the reality, without the trickery, is like this:
perceived waiting time begins
perceived waiting time ends
This would mean a perceived waiting time of 3 seconds.
And with the trickery:
perceived waiting time begins
perceived waiting time ends
Even though the time to getting the final bit of data on screen is actually extended to 4 seconds, the perceived waiting time is reduced to 2 seconds.
This seems to be a bit of a hot topic on Twitter right now so here’s my take.
The definitions of designer and developer and where you draw the line between the roles is a bit of a nonsense. In reality you can’t box things like this. It’s about the individuals and what skills they have and what fits your team. Overlaps in skills are not a problem, gaps are. So, the handover points will naturally surface out of what works for the team. That said, I do have some more specific thoughts about what might kinds of coding might empower a designer.
Knowing some basic DOM manipulation techniques can really help to add some life and interaction to designs – “Interaction Design”.
- Being able to select a DOM element with
document.querySelector() is a good starting point.
- Basic event handling with
.addEventListener('click', handler) is useful as it allows you to add actions.
- Handling events means learning how to write a very basic named function.
- Finally being able to toggle properties like
disabled or add/remove/toggle items from
classList enables you to design for lots of different states within the same document.
I think just these few basic steps will enable a designer to achieve a lot more in their designs.