Person 1: My messenging app is more secure.
Person 2: No, MINE is!
Person 3: No way, I ONLY use Signal – it’s the most secure!
Okay, y’all are fired.
What if I told you that NONE of the messaging apps you use are really, truly secure?
Sound crazy?
Well, it is. The encryption is as good as you’re gonna get.
The problem is the way it’s used that actually matters…
The global IT outage on Friday, July 19th 2024 was a humdinger.
We’re told it’s nothing to worry about, but what’s really going on?
I’m afraid the rabbit hole goes a bit deeper than you think.
Join me for a look at the Crowdstrike “bug” and what it means for you…
What’s the one thing no coder wants to talk about?
Chances are, you know a few coders. They’re everywhere these days!
What you might not know is that most of them have experienced something, well, unexplained: code that works, but shouldn’t. At all.
It’s just part of many programmers’ lives. But what’s really going on here?
How is it that something that never should have worked in the first place works perfectly – sometimes, for years?!
If you code in JavaScript, you should know all about debouncing functions.
When an event listener such as a window ‘resize’ fires, sometimes it will fire 72,000 times per second. That means your callback function is also firing 72,000 times in a row, bogging down the browser.
This isn’t as much of a problem as it used to be, but debouncing is still needed and should still be used.
So what’s the best way to debounce/throttle in JavaScript?
Let’s say you’re writing a web app, and of course you’re using JavaScript. So far, so good!
But then let’s say you need to load some images on the fly, and then do something useful AFTER each image is fully loaded.
IOW, maybe you want to adjust the layout of the image modal that pops up, or you want to do something crazy with a caption, or whatever…
Naturally, you’d use JavaScript to do this – including changing CSS on the fly.
So the question is: How do you use JavaScript to detect when an image is fully rendered on the page – not just loaded?
In recent news, a guy at Google claimed that one of their AIs, LaMDA, had become sentient.
Well, that’s quite a claim!
So, I decided to read the entire transcript of a chat with LaMDA and see what all the fuss is about.
Turns out, it’s not so simple…
If you’ve ever created a website, you’ve surely used jQuery.
It’s a lovely JavaScript library that lets you do all sorts of whiz-bang Web 2.0 stuff while shielding you from the underlying plain vanilla JS functions.
But hang on a minute – do you really need jQuery?
The answer is, as usual, complicated… but fascinating!
JavaScript is THE super-helpful programming language that makes the whole internet go.
From Google Docs to online mapping, JavaScript makes it all possible.
Despite its popularity, many concepts in JavaScript programming are rarely explained in a simple, down-to-earth way.
For example: the self-executing function.
What in the Sam Hill is that all about?!
If you’ve ever designed a web site, you know that the ‘dev tools’ built into browsers are invaluable.
You can play with the CSS, debug JavaScript, see requests in realtime, and so on.
That’s all great for desktop, but what about debugging on mobile?
Typically, developers jump through all sorts of hoops – including hacks in their code that are added strictly for development debugging.
Isn’t there a better way? Why yes, there is…
Chrome 94 was recently released with a new feature: Idle Detection.
Specifically, there’s a new JavaScript API called IdleDetector. It reports two things to the JS code of the web page you’re viewing: keyboard/mouse activity, and if your screen is locked or not.
Much has been said about the diabolical nature of this new capability in Chrome…
Thing is, while we can be forgiven for doubting Google’s motives in adding this feature, it just so happens that Idle Detection is actually quite safe – and useful!
Recent Comments