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!
WebRTC is pretty cool. It allows any web browser to make voice and video calls to any other browser – no extra software required!
The problem is that while there are tons of guides and gobs of sample code out there, nobody really explains how it works.
The end result is that you program away, and then discover that OOPS! It’s not connecting…
So, let’s see how to make WebRTC actually work!
Recent Comments