Quickly bootstrapping a new Node.js project

A problem that often happens to me: I get the inspiration to whip up something in Node.js  (for fun, for experimentation, for a side project, etc) but then I realize that I need to go through the process of actually setting things up before I can even start writing some code.

Usually, I have to dig through previous projects and copy over my eslint and prettier config files, read through some documentation and remember how to setup TypeScript again, install the correct dependencies for running tests. Before I know it, I’m bored and tired and no longer interested in doing whatever I was going to do.

I decided to experiment with some command line tools and created a Node.js script that can help me quickly bootstrap a new project with common configuration parameters that I use. It’s available on GitHub: Bootstrap Node Project.

The GIF above shows this tool in action. I’m able to get the scaffolding for a new project up and running within about 20 seconds! After running, the project structure looks like this (with associated npm start and test scripts, all ready to go). That is pretty awesome.

my-cool-project/
├─ .husky/
├─ node_modules/
├─ src/
│ ├─ index.js (.ts)
│ ├─ index.test.js (.ts)
├─ .eslintrc.json
├─ .gitignore
├─ .prettierrc
├─ package-lock.json
├─ package.json
├─ README.md
├─ tsconfig.json (optional)

Obviously, it’s highly opinionated and caters to configuration options that I personally like to use. But I figure it’s a great resource for anyone who wishes to roll their own utility to quickly bootstrap projects as well.

 

Creating an automated Twitter bot about gun violence

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 SABSStochastic 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.

Which of course includes unhinged Republicans.

Experimenting with parallel computing using node worker_threads

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).

Fixing rendering issues with React and IE11

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:

if (!window.console || Object.keys(window.console).length === 0) {
  window.console = {
    log: function() {},
    info: function() {},
    error: function() {},
    warn: function() {}
  };
}

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.

<!doctype html>
  <html>
    <head lang="en">
      <meta content="user-scalable=no, width=device-width, initial-scale=1.0, maximum-scale=1.0" name="viewport"/>
      <meta charSet="UTF-8"/>
      <script>
        if (!window.console || Object.keys(window.console).length === 0) {
          window.console = {
            error: function() {},
            log: function() {},
            warn: function() {},
            info: function() {},
            debug: function() {},
          };
        }
      </script>

After that, everything started working again in IE11.

#TheMoreYouKnow