Recently, I went down a rabbit hole attempting to learn how to generate interesting looking maps for games (insert mind-blown-gif here). While I’m not going to be using Voronoi diagrams anytime soon,  I am still interested in attempting to generate Civilization-like maps.

Most map generation algorithms rely on perlin noise. I wanted to go a different route.

So far, these are the rules that I’ve come up with for my algorithm:

1. Create a grid of some given size (e.g., 100 x 50). Set all tiles to “ocean”.
2. Randomly pick 8 tiles (variable) across the map to seed as “land”.
3. Now iterate across all tiles on the map and build an array of tiles that are “ocean” tiles but have a land tile N/W/S/E of them.
4. Once you have this array, randomly pick a single value. Flip it from “ocean” to “land”
5. Repeat step 3 until a given number of tiles have been filled across the grid (e.g., for an “Earth-like planet”, 30% of tiles will be land).
6. Now, to add some additional randomness — iterate across all tiles and build an array containing all “land” tiles next to water (N/W/S/E).
7. Randomly pick 1, flip from land to ocean.
8. Repeat step 6 a given number of tries (e.g., 100).
9. Done! (Maybe)

Height maps, biomes and all that can come later. To quote Amit, whom I linked to earlier:

The most realistic approach would have been to define elevation first, and then define the coastline to be where the elevation reaches sea level. Instead, I’m starting with the goal, which is a good coastline, and working backwards from there.

Anyway, it’s been kind of neat to figure out.

Another example map, created using the above rules:

Story of my life lately.

It seems like every year, late in the summer or early in the fall, the air in the Bay Area fills with thick smoke from raging infernos happening around northern California. The air is hazardous to breath, preventing you from taking kids to the park, walking your dog or even opening your windows.

Last year, we made the wise decision to purchase an air purifier, which admittedly, looks like a giant iPod shuffle.

As fires continue to burn around these parts, we’ve started to rely on air quality data from PurpleAir, which monitors air quality data from a series of IoT sensors that people can purchase for their homes or businesses.

You can view a map featuring realtime data collected from their sensors. Here in the Bay Area, the sensors are quite ubiquitous and can give a more realistic pictures of air quality near your home.

For example, here is the current air quality around the Bay Area from PurpleAir while I write this post.

For comparison, here is the current air quality map for Bay Area Air Quality Management District (BAAQMD), which we used to reference when trying to determine local air quality.

The fidelity you get from PurpleAir is pretty amazing.

Knowing this, I decided to write a Node app that periodically queries PurpleAir for air quality data from a sensor located a few blocks from our house. It continuously runs on a Raspberry Pi setup in our entertainment center and sends me a text message to close our windows when the AQI crosses above 100.

I’ve made the source code available on Github. Check it out!

I recently wrote a simple hook for React to automatically detect a device’s dark mode preference (as well as any changes to it) and style your web app accordingly, using something like ThemeProvider from styled-components.

It was developed as part of a side project I was hacking around on using my personal React Starter Kit, which is my own React project for quickly getting prototypes and side projects up and running.

I’ve released this as a standard GitHub repo instead of an NPM module due to the simplicity of this hook, especially in light of one-line packages breaking the Internet. To use it, just copy it into your project where needed.

I’ve released this under an MIT license. Feel free to use as-is, fork, copy, tear apart, profit, and share as you wish.

You can check out the code on Github.

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

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.

I wanted to play around with Event Emitters in Node tonight. Pretty neat! I’m going to have to figure out a way to incorporate this into future projects.

It gives me a bit more insight into how things like WebSockets work as well.

Github link to my repo.

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.

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!

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.