TL;DR Check out the Adding ids to Header Nodes section to see how to use the Visitor Pattern.

I recently wanted to add an id to every header tag in an HTML string. This sounds like an easy task right? A little jQuery and the problem is solved: $(":header").attr("id", "1") is a rough solution.

The catch is that this was in Node, not the browser. In most situations I would reach for Cheerio, which replicates the jQuery API inside node, but I needed something lighter weight.

This is a story of parsing, recursing, and modifying raw HTML without comfortable, declarative APIs. It's surprisingly approachable with the help of the Visitor pattern.

TL;DR Check out the Bulk Requests and pageContext section below to learn how pageContext works.

Gatsby has become the de facto JavaScript static site generator because of its dedication to performance, near-infinite flexibility, and its embrace of React and GraphQL. Like any great tool, however, Gatsby is not without flaws.

Gatsby allows you to build your static website by querying a GraphQL API at build time. If you choose this approach, as your site grows, your Gatsby build times will likely increase with every added page. Slow build times hinder developer workflows and make deployments cumbersome. In my previous article, I discussed optimizing GraphQL queries in Gatsby to decrease page load times. This article will focus on how GraphQL queries can be optimized to shorten ten minute or even hour-long build times to seconds.

In my article comparing Gatsby to Hexo, I talked about my experience switching writing this blog using Hexo and then later using Gatsby. In the process, the size of my initial page ballooned 5x.

In retrospect, I did not fully understand the abstraction that Gatsby provides. Fortunately, if you follow a simple rule of thumb, you can avoid bloating your network requests and maintain an ultra-performant website.

There are two major static site generators in the JavaScript ecosystem: the incumbent Hexo and the up-and-coming Gatsby. This site was first built with Hexo, but I've recently switched to Gatsby. Let's talk about why.

I recently wanted to ingest a line-delimited JSON file into Postgres for some quick data exploration. I was surprised when I couldn't find a simple CLI solution that parsed the JSON and loaded each field into its own column. Every approach I found instead inserted the entire JSON object in a JSONB field. Here is my solution.

Postgres introduced the JSONB type in version 9.4 with considerable excitement. JSONB promised to marry a favorite relational database with the noSQL world, permitting data to be stored in the database as JSON without the need for re-parsing whenever a field is accessed. Moreover, the binary storage format permits indexing and complex queries against the stored JSON blobs. This data format embodies the flexible schema and was readily adopted at Fraight.

Two months ago I purchased a GPS device and associated service plan from SPOT. Today, upon trying to cancel the service, the customer service representative informed me that I had accidentally enrolled myself into a 1 year, $250 contract and that I was unable to cancel. He told me that if I blocked the monthly charges against my credit card that they would report the debt to a collections agency. I was initially upset but soon realized it was a great opportunity to talk about ethics in software engineering.

The other day at work, one of my colleagues was frated that he was unable to encode nested objects in a query string and still maintain a readable URL. I went home that night and coded up a simple solution to this problem, and I thought I'd share it here today. This Github repo contains specs and the solution code.

I've conducted about 100 technical interviews over the past 6 months for a software development recruiting company called Triplebyte. I've also been doing consulting work, which has required me to take numerous technical interviews. It's interesting contrasting the experiences to identify what works and what doesn't.

Every Triplebyte interview begins with the candidate coding a short game. We have a series of steps, and each step precisely defines simple requirements for the program to handle. I can generally tell a couple minutes into the 2 hour interview whether the candidate will be successful. There are certainly outliers (as well as mechanisms to prevent bias), but in general, I can quickly ascertain how well a candidate stacks up technically. So then, it begs the question, why is it so hard to hire engineers? The answer is, most of us are doing it wrong.

I'm currently contracted to create a web service using some data from a third party Angular application. I worked off a proof of concept codebase that used Chrome's new Puppeteer API to scrape this site. I strongly regret not starting from scratch.

I posted my article Build Your Own Regex Engine on Reddit the other day, and one of the commenters claimed that the implementation should be trivial to break. Since I had already tested my program against a customized suite of tests, the remark got me thinking about how I could further increase my confidence in the correctness of my program. One extremely low cost however effective strategy for identifying faults in software is known as fuzzing.

I stumbled upon an article the other day where Rob Pike implements a rudimentary regular expression engine in c. I converted his code to Javascript and added test specs so that someone can self-guide themselves through the creation of the regex engine. The specs and solution can be found in this GitHub repository. This blog post walks through my solution.

My inspiration for this blog post came from this video where Dan Abramov walks through the source code to react-redux

As frontend web developers, it's not uncommon that we follow well-specified patterns - often blindly. The frontend landscape is changing rapidly, and sometimes there isn't time to investigate why we use a specific pattern; we just know we should.

One widely used pattern in react-redux applications looks like this

connect(
  mapStateToProps,
  mapDispatchToProps
)(MyComponent);

I'll assume you know how to implement this pattern, but why do we use it and how does it work under the hood?

My first introduction to functional programming was a couple years ago when I read through the famous SICP. As someone who had up to this point worked with mostly in object oriented and imperative languages, I had rarely seen map, fitler, and reduce before that time. The purpose of the former two felt obvious; the latter one not so much. This blog post is geared for someone who knows how reduce works but feels like they struggle to use it practically.

React has taken the web development community by a storm, and with it functional programming concepts have embedded themselves in the mainstream. One common statement you will often read is that all state in React should be immutable, and this practice is justified as necessary for performance reasons. This statement is entirely true, but it only tells half the truth. Immutability alone will not yield any performance gains in React (it'll actually make things slower).