The school shooting in Uvalde last week was horrible. As a parent, I feel so powerless to protect my kids from something like that. Taking them to school the next day was extremely emotional.
It’s clear that we, as a country, are going to continue to do nothing about guns and gun violence. I channeled some of my emotion into building an automated bot for Twitter. I call it SABS – Stochastic Analysis for Ballistics Superfans (alternative title is “Second Amendment Bullshit”).
If you’re so technically inclined, you can download and run it yourself. Powered by Node and a fun little experiment into Twitter’s API.
It automatically replies to any congressional member who tweets.
I’ve wanted to play around with worker threads in Node JS, so I put together this little repository that demonstrates how it all works. Check it out here.
In order to simulate multiple threads that are each processing data, each worker thread uses a randomly generated timeout between 100 to 700 milliseconds. In addition, it has a random number of loops (between 10 and 1000) that must be completed before the worker is terminated.
It’s kind of fun to watch the tasks run and automatically complete inside the terminal (check out the screenshot of the output up top).
Happy April Fools’ Day. This post is no laughing matter because it deals with IE11. 🙀
Awhile back, we had an issue where visitors to our site would hit our landing page and not see anything if they were using Internet Explorer 11. The skeleton layout would appear on the screen and that was it.
Debugging the issue using IE11 on a Windows box proved to be difficult. Normally, we open up the inspector window, look for an error stack and start working backwards to see what is causing the issue.
However, the moment I opened the inspector, the site would start working normally again. This lead me down a rabbit hole and I eventually found a relevant post on StackOverflow: “Why does my site behave differently when developer tools are open in IE11?”
The suggested solution was to implement a polyfill for console.log, like so:
Interestingly, we didn’t have console.log statements anywhere in our production build, so I figured it must be from some third party library that we were importing. We added this line of code at the top of our web app’s entry point to try and catch any instances of this. For us, that was located at the following path: src/app/client/index.js
After rebuilding the app, things were still broken, so the investigation continued.
We eventually concluded that the issue had to do with how our app was built. Our web app is server side rendered and we use Babel and Webpack to transpile and bundle things up. It turns out, Babel wasn’t transpiling code that was included in third party libraries, so any library that was using console.log for one reason or another would cause our site to break.
(The fact that IE11 treats console.log statements differently when the inspector is open vs. not is an entirely separate issue and is frankly ridiculous.)
Knowing this, we were eventually able to come up with a fix. We added the polyfill I posted above directly into the HTML template we use to generate our app as one of the first things posted in the head block. The patches console.log so that it’s available in any subsequent scripts (both external or not) that use it.