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

Next level code review skills

I’m always searching for better ways to improve my workflow, increase productivity, and just generally learn new and exciting things. (Besides, it’s part of having a healthy growth mindset.)

We’ve had some big changes on our team during the past year and I’ve felt like I’ve needed to step up when it comes to reviewing code that my fellow colleagues write. While searching for some ideas on how to improve my code review skills, I discovered a blog post from 2018, entitled “Code Review from the Command Line“.

This blew my mind and really helped reframe how we engineers should approach code reviews:

When I ask that other people review my code, it’s an opportunity for me to teach them about the change I’ve just made. When I review someone else’s code, it’s to learn something from them.

Jake, the author of the above post, goes on to describe his setup and custom tooling for conducting an interactive code review.

He uses custom git alias to see which files have changed and how many changes there are, a custom script that visualizes how often the files within the pull request have changed over time, and another custom script that can visualize the relationship between changed files.

All of these go above and beyond the call of duty for reviewing code, but it’s stuff that decreases friction and can make a sometimes tedious process much more enjoyable.

I’ll be implementing some of these ideas into my own workflow in the near future.

National Novel Generation Month, 2017 Edition

November is traditionally “National Novel Writing Month.” The goal is to write a short novel that is 50,000 words in length. I always have grand plans to attempt it and have started a number of times over the years but have never actually finished. (One day, I swear!)

Recently, I stumbled across a geekier take on it, called National Novel Generation Month. The goal of this particular project is to write code that can generate a 50,000 word novel instead. Hey, why not?

I published my code at the beginning of November for my project: The Complete Encyclopedia on 1,449.5 Random Ways to Make a Sandwich.

This book of 1,449.5 random sandwich recipes was created for NaNoGenMo (National Novel Generation Month) 2017. You can view the source code for this project on GitHub.

It uses data parsed from a 1909 book, entitled “The Up-To-Date Sandwich Book: 400 Ways to Make a Sandwich”, written by Eva Greene Fuller and now available for free in the public domain.

For this particular book, new sandwich recipes were generated using Markov chains created from the above text.

Please don’t try to actually make any of the sandwich recipes created with this process. However, if you do, please contact me and show me pictures.

Disclaimer: I cannot be held responsible for any health issues that may arise from eating any of these sandwiches.

There are definitely some interesting ones…

BUTTERED CHEESE AND OLIVE SANDWICH NO. 3

Use three slices of Swiss cheese, spread fresh butter and two tablespoonfuls of olive oil, the juice of two oranges and knead the mixture.

Want to learn to code?

A friend of mine recently asked for some suggestions on which language she should use to learn to code.

There are so many different routes to go! Python and JavaScript might be easiest because they’re dynamically typed languages (basically they’re more forgiving with how you use variables and pass them around — it’s one less thing to worry about as you start out).

I find Python to be super fun and easy to pick up. Plus there’s tons of neat libraries available for manipulating data. One bonus: down the road, you can start playing with some of the many machine learning libraries that are available. Then you can build a model that will predict names of Android phones.

I’m partial to JavaScript. At this point, it’s probably one of the most popular languages right now. People are building web apps, desktop apps, native mobile apps, and backend servers with it due to the abundance of tools available. Plus, there’s a really addictive feedback loop with it: when you’re first starting out, you code something, refresh your browser and boom, there it is!

I’ve played only a little bit with Swift. I like it and I think Apple is doing some good work trying to provide tools to help people learn. For now, you’re mostly going to be limited to building mobile apps, though there are more tools being built that expand its uses (e.g., servers).

There are tons of great resources. Codecademy, Code School, Udemy, free tutorials, etc. When I started out, I started learning by trying to build a JavaScript app that could solve Sudoku puzzles. Somehow, I eventually did it! I was pretty hooked!

Emoji Say What?

Here’s a random little side project that I’ve been working on: Emoji Say What?

It’s like a game of telephone, but using the latest in human communication technologies, hieroglyphics, emoji!

Basically, you visit the site and get a completely out of context sentence or set of emoji and it’s your job to decipher it. And so on and so on. It evolves over time and eventually you get something like this.

Using neural networks to generate names for craft beer.

I’ve been on a machine learning kick lately. Given a large enough dataset to train with, it’s really interesting to see what a neural network can come up with.

This week, it’s names for craft beer.

If you’re a fan of IPA beer, you’ve got names like Dang River, Yamquak, Yall in Wool, Wicked Geee, Yampy, and Oarahe Momnila Day Revenge Bass Cornationn Yerve Of Aterid Ale. Like strong pale ales? Trippel Lock, Third Maus, Third Danger, Spore of Gold and Drammnt. Stouts more your thing? Look for Sir Coffee, Shock Slate, Take Bean, Black Sink Stout, Shrump, Avidberry, or Cherry Trout Stout.

Naturally, I tried to create my own model using a Python library called Keras and a dataset of 7,500 craft beer names.

…I should leave this stuff to the professionals.

Update: Kaggle has a new tutorial teaching you how to do this exact same thing. Neat!

Setting up tests using Tape

Test driven development has become an important process in the software engineering world. It allows coders to develop functions by first creating a series of tests that the new function must solve. The benefit of this is that once your app grows more complex and you add new functionality, you can see if any existing tests have failed, meaning that something broke (and now you know where to find it). Look no further than any popular project on Github and you’ll often see a “tests” folder.

Today, we’re going to talk about setting up tests using Tape.

Tape is an alternative to popular testing suites such as Jasmine and Mocha. Like any tool related to software engineering, there are some developers that strongly prefer Tape over other options. It’s fairly easy to setup and can easily be run in automated task runner tools such as Grunt and Gulp.

To use it as part of your project, you can install it through npm:

  npm install tape --save-dev

Once it’s been added as part of your project, you can create a new tests.js file and require the module.

For our demonstration, we’re going to write a simple test that checks if my name is Dave, plus a few additional parameters.

Start off by setting up your test.js file like so (you can name it whatever you prefer). I’ve commented the code for some additional clarity on what’s happening here.

// Require the Tape module imported from npm
var test = require('tape');

// Write your tests in the code block
test('All about Dave', function (t) {
    // The number of tests that you plan to run.
    // NOTE: If this number doesn't match up with the number
    // of tests that are run, your test will fail.
    t.plan(2);
    
    // Let's setup some variables to test
    var name = "Seymore";
    var city = "Oakland";
    var favBaseballTeam = "Athletics";

    // This test will check for my favorite baseball team.
    // The first parameter is the result, the second is
    // the value you're expecting, and the third is the message
    t.equal(favBaseballTeam, "Athletics", "Favorite baseball team should be Athletics");

    // This test will check for my name.
    // As you can probably assume, it will fail.
    t.equal(name, "Dave", "Name should be Dave");

    // This test will check if city has been set:
    if (city) {
      t.pass("City set");
    } else {
      t.fail("City not set");
    }
});

That’s it! You can run Tape from your terminal and point it to your newly created test.js file in order to run it.

Screenshot 2015-09-01 14.00.18

Using the Mongo CLI to find your data.

We’ve been working on many projects lately that have utilized MongoDB as the primary means of database storage. I have previous experience building and using MySQL databases, so the idea of these NoSQL databases is a new concept for me.

I’m not one to shy away from new technologies, so I’ve been trying to embrace MongoDB and learn how to use it.

One of the most important things I’ve been learning is how to view the databases, collections, and records that I’ve saved in my various applications through the MongoDB command line interface.

Let’s do a quick walk through and pretend I have a database dedicated to baseball.

Once you have Mongo installed on your machine, you run the interface by typing mongo in your terminal. Now, you can bring up a list of databases by typing show databases.

Screenshot 2015-08-20 10.24.51

How do we use a particular database? Easy! Just type use [database_name]


use baseball

Awesome! Of course, you’ll want to do more than just “use” the database. We want to see what’s inside it. This is accomplished by telling mongo to show us all collections (e.g., think of these as “tables” in a traditional SQL database).


show collections

Screenshot 2015-08-20 10.27.33

Awesome! Now we have a collection of teams and collection of players. Well, let’s display everything within a particular collection. In this case, let’s print out all teams that we have stored in our database.


db.teams.find()

Screenshot 2015-08-20 10.28.32

Great!

Now, let’s say you’re looking for a particular record. How do you limit your search to just one thing? Like this:


db.teams.find({team: “dodgers”})

Screenshot 2015-08-20 10.30.04

Now, you can imagine that if we had more data, there are a lot more things that we could search for and find. It’s pretty powerful!

Anyway, this was a quick tutorial on how to use the Mongo DB CLI. I hope you found it helpful!

Getting started with Firebase, by building a persistent chat client

Screenshot 2015-08-07 14.05.09

I recently utilized Firebase to power the database and back end of an AngularJS web application I’ve been working on.

Firebase was proved to be amazingly easy to setup. Their “5 minute quick start” sold me on the utility of this service.

How easy is it? Let’s go ahead and create ourselves a persistent chat client in about 5 minutes. I’ll assume you’ve had some previous experience with Angular, but it’s not required.

In an empty HTML page, let’s add the Firebase Javascript library in the head section of our page.

<script src='https://cdn.firebase.com/js/client/2.2.1/firebase.js'></script>

Alright, easy enough, right?

Now, you need to create a reference to your Firebase database inside your script tag. When you sign up (for a free, even!), Firebase will give you a random URL that links to your new database.

So, a reference in your script tag, like so:

  <script>
    var myData = new Firebase('https://d______.firebaseio.com/');
  </script>

Okay, okay. Not too bad.

How do you start sending data to your new Firebase DB? You just apply some Firebase methods to the reference we created about. In this case, we’ll use the set() method.

  // Store values from our input boxes here.
  var name, text; 

  // jQuery or other magic here to set input boxes
  // to the values above.

  // Save to our Firebase DB using the .set() method.
  myDataRef.set('User ' + name + ' says ' + text);

You’d likely use jQuery to set the values of a particular input box to the name and text. You can also pass in objects to the set() method like so:

  myDataRef.set({name: name, text: text});

Another option that you can utilize to store data inside Firebase is the push() method. You can utilize this method to easily create lists of objects.

  myDataRef.push({name: name, text: text});

Okay, we talked a lot about how to send messages to our database. But how do we retrieve them? We can create an event listener using the on() method, like so:

  myDataRef.on('child_added', function(snapshot) {
    var message = snapshot.val();
    displayChatMessage(message.name, message.text);
  });

And just like that, you now have a working chat client supporting many users and can share data to all clients using it. Amazing!