[DynamoDB](https://aws.amazon.com/dynamodb/) is Amazon's key-value/document database service. It's a fully "serverless" database with pay-per-request pricing & nearly effortless scaling. It's also completely closed-source, so unlike [MongoDB](https://github.com/mongodb/mongo) or [SQLite](https://github.com/sqlite/sqlite), it's hard to know what's really happening behind the scenes.

I've been using DynamoDB a lot recently at work, and I was curious to learn more about its internals. Luckily, the team behind Dynamo, Amazon's in-house database & the predecessor of DynamoDB, published an [academic paper](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) on just that!

While technically not the same database we all use today, Dynamo gives some great insights into where DynamoDB came from & why it works the way it does. (For example, did you know it might use MySQL behind the scenes? I didn't!)

## A Purpose-Built Database

The "NoSQL" movement came out of the realization that not every application interacts with its data in the same way. Relational databases, like MySQL, make a lot of trade-offs to maintain their flexibility and strict data integrity.

Amazon looked at how they used their database, though, and found that 70% of operations simply requested a single record by primary key, and another 20% asked for a set of rows from within a single table. So [90% of queries](http://www.allthingsdistributed.com/2017/10/a-decade-of-dynamo.html) didn't use `JOIN` or other tools in the relational database's toolkit!

With that in mind, Amazon engineers decided that they could sacrifice some of the _consistency_ and _isolation_ guarantees from [ACID](https://en.wikipedia.org/wiki/ACID) in order to make it easier to scale the database horizontally (by splitting it up into a bunch of servers, rather than making one server more and more powerful):

<blockquote class="paper">
Experience at Amazon has shown that data stores that provide ACID guarantees tend to have poor availability. This has been widely acknowledged by both the industry and academia. Dynamo targets applications that operate with weaker consistency (the “C” in ACID) if this results in high availability. Dynamo does not provide any isolation guarantees and permits only single key updates. pg. 206
</blockquote>

Rather than build a database completely from scratch, Dynamo was built *on top of* a lot of other existing databases like [Berkeley DB](https://en.wikipedia.org/wiki/Berkeley_DB) and even MySQL! The big difference was how Dynamo arranged each underlying database.

## Napster for Databases

Dynamo may have been built on top of existing databases, but it's design was really inspired by peer-to-peer file-sharing networks like [Freenet](https://freenetproject.org/index.html) and [Gnutella](https://en.wikipedia.org/wiki/Gnutella).

Because files in these networks were spread across thousands of computers and these computers would go online & offline unpredictably, they had to establish their own links to each other & maintain their own maps to help route queries to the right place.

<blockquote class="paper">
Dynamo can be characterized as a zero-hop DHT, where each node maintains enough routing information locally to route a request to the appropriate node directly. pg. 209
</blockquote>

This was one of the keys to solving Amazon's horizontal scaling problem. Instead of one really powerful machine knowing where to find every record, each machine kept enough of a "map" to route requests directly to their final destination. This allowed the entire database to run on cheap commodity hardware & scale near infinitely.

Maintaining this map wasn't necessarily simple, though. Like in file-sharing networks, machines could go offline unpredictably due to network issues. Engineers might also purposefully add new machines to "scale up" a database, and then those maps would have to be updated efficiently.

## Consistent Hashing

Hash tables, or "dictionaries", are a way of storing data & quickly looking it up by a unique key. They generally work by splitting data into a bunch of arrays, and using a _hash function_ on the key to determine which in-memory array to store each key in. A hash table's data will be split up into more and more independent arrays as it grows.

You can apply the same idea when storing data on multiple servers, using the output of the hash function to decide which server a record lives on. But what happens if you need to add & remove servers? If you just evenly split keys between servers, you'd need to move a lot of data when scaling.

Dynamo uses [consistent hashing](https://en.wikipedia.org/wiki/Consistent_hashing) to tackle this tricky scaling problem. It's a way to create hash tables that can resize dynamically without having to rearrange too much existing data.

<blockquote class="paper">
 <picture>
 <source srcset="//images.ctfassets.net/pdp8shfq85fk/3saNcTJV2eDZWvU773kqA4/d2bebe66c65f9d800a6da600752cffdf/dynamo-ring-dark.png" media="(prefers-color-scheme: dark)">
 <img src="//images.ctfassets.net/pdp8shfq85fk/1qtlk83XhVMKDltqrx3rVr/718376fef2814f048df5fcacd7cf783a/dynamo-ring.png" alt="Figure 2: Partitioning and replication of keys in Dynamo ring" width="350" />
 </picture>
 
 Dynamo uses a variant of consistent hashing (similar to the one used in [10, 20]): instead of mapping a node to a single point in the circle, each node gets assigned to multiple points in the ring. [...] Read and write operations involve the first N healthy nodes in the preference list, skipping over those that are down or inaccessible. pg. 210-211
</blockquote>
 
Consistent hashing imagines that servers are all evenly spaced out around a circle. Each record's primary key is then run through a hash function which outputs a degree on the circle, e.g. the key K is hashed to 10° in the diagram above. The next N servers clockwise from that key's position in the circle — B at 15°, C at 30°, and D at 45° — all store a copy of that record.

This allows engineers to add (or remove) servers with minimal data migrations. If more servers are added to the ring, the new servers "steal" tokens from existing nearby nodes in the ring. If a server leaves the system, its keys are distributed to the nearby nodes in the ring.

Some services, like Amazon's product catalog, need to be able to process more reads than writes. Dynamo allowed each application to adjust how many servers they rely on for read & write operations based on their own specific performance & consistency needs:

<blockquote class="paper">
To maintain consistency among its replicas, Dynamo uses a consistency protocol similar to those used in quorum systems. This protocol has two key configurable values: R and W. R is the minimum number of nodes that must participate in a successful read operation. W is the minimum number of nodes that must participate in a successful write operation. Setting R and W such that R + W > N yields a quorum-like system.
In this model, the latency of a get (or put) operation is dictated by the slowest of the R (or W) replicas. For this reason, R and W are usually configured to be less than N, to provide better latency. pg. 211
</blockquote>

In this equation, the value of __N__ determines the durability of the object. The values of __W__ & __R__ impact its availability & consistency. This lives on in DynamoDB's [read & write capacity units](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html).

## Conflict Resolution

Despite being visualized around a circle, the servers in the consistent hashing "rings" aren't physically right next to each other. They're placed in separate data centers to reduce the chance that a network outage would cause any particular key to become unavailable.

If one server is down, you can just read the key from the remaining servers that are still online. But what about writes? If one server that holds a key is offline & you write to the others, then you'll end up with _two_ versions of the same record!

Unlike traditional ACID-compliant relational databases, Dynamo explicitly acknowledges inconsistencies might occur it its design:

<blockquote class="paper">
This requires us to design applications that explicitly acknowledge the possibility of multiple versions of the same data (in order to never lose updates). Dynamo uses vector clocks in order to capture causality between different versions of the same object. pg. 210
</blockquote>

In Dynamo, the client has to specify which version of an object it's trying to update, via the "context" it obtained from an earlier read operation. This context is stored as a [vector clock](https://en.wikipedia.org/wiki/Vector_clock), which tracks what changes led to each potential state.

That information can then be used to resolve conflicts in different ways, depending on the needs of the application. The simplest option is to use the vector clock to simply pick the most recent update. This was the conflict resolution strategy used by Amazon's session service.

Sometimes, developers might want to be more careful when resolving conflicts. Dynamo allowed these applications to resolve conflicts themselves & merge the two conflicting records based on business rules. This is how Amazon handled conflicts in their "shopping cart" service.

## Hot Partition!

The use of consistent hashing to scale also explains one of [DynamoDB's most notorious problems](https://segment.com/blog/the-million-dollar-eng-problem/#dynamodb-hot-shards). If the key that's used to partition records around the ring isn't universally distributed (either by volume of keys _or_ by volume of read/write requests), then too many requests will end up hitting one section of the ring:

<blockquote class="paper">
Dynamo uses consistent hashing to partition its key space across its replicas and to ensure uniform load distribution. A uniform key distribution can help us achieve uniform load distribution assuming the access distribution of keys is not highly skewed.

In particular, Dynamo’s design assumes that even where there is a significant skew in the access distribution there are enough keys in the popular end of the distribution so that the load of handling popular keys can be spread across the nodes uniformly through partitioning. pg. 215
</blockquote>

This problem is discussed in terms of "load imbalance". It's easier to deal with a lot of popular keys (say, during a busy weekday) than a small handful of popular keys (like a flash sale on a single item that happens at midnight).

This was an unsolved problem in Dynamo, and [until recently](https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/), in DynamoDB too.

## You can't have it all!

The story of Dynamo and DynamoDB is all about trade-offs. What's important to your application? What can you do without? DynamoDB won't be the right choice in many situations! In solving some of the tricky scaling problems that Amazon was facing back in 2004, Dynamo introduced a whole new set of problems that relational databases didn't have.

Nonetheless, it was at the forefront of a big shift away from "one size fits all" use of relational databases. It's a great reminder to evaluate the problems you're facing, and make sure you're using the right tool for the job!

The ideas behind DynamoDB, Amazon's serverless key-value database.

The Dynamo Paper

After years of faithful _Vim_ usage, I've started using _Visual Studio Code_ more and more for my everyday work. It took a long while to rebuild my [Ctrl-P](https://github.com/ctrlpvim/ctrlp.vim) muscle memory to ⌘P, but I finally did it!

However, I still use _Vim_ to make quick edits to files here and there. And that's where that newly acquired muscle memory betrayed me – as all my attempts to quickly open files ended up mired in iTerm's "Print" dialogue! No good!

## Re-mapping ⌘P to Ctrl-P in _MacVim_

According to the [_Vim_ documentation](https://vimhelp.org/intro.txt.html#keycodes), you can _theoretically_ map the "command" key using the `<D-` prefix. When using [MacVim](https://github.com/macvim-dev/macvim), it actually is that simple!

```vim
" In ~/.vimrc: 
map <C-p> :CtrlP<cr>
map <D-p> :CtrlP<cr>

" In ~/.gvimrc:
if has('gui_macvim')
 " This removes the Cmd-P binding from 'Print':
 macmenu &File.Print key=<nop>
endif
```

Alas, the terminal doesn't know about the Command key and so that doesn't help us when using classic _Vim_. The best we can do is tell _iTerm_, a modern graphical application, to intercept our ⌘P keystroke and turn it into another key combination that the terminal _can_ understand, like Ctrl-P.

## Re-mapping ⌘P to Ctrl-P in _iTerm2_
_iTerm_ allows us to add custom key bindings in our profile. Open **Preferences** and head to **Profiles** → **Keys**. Click the "+" button to add a new mapping:

<picture>
 <source srcset="//images.ctfassets.net/pdp8shfq85fk/2mnpos4x9QzZgTWqW01hOH/02617b21647759472a12717e2bf89600/Screen_Shot_2020-07-09_at_12.52.01_AM.png" media="(prefers-color-scheme: dark)">
 <img src="//images.ctfassets.net/pdp8shfq85fk/2c4HV2ZUv1Cyt51s7WbCU2/a212f23a11a08a48da2e1d944721bacc/Screen_Shot_2020-07-09_at_12.52.11_AM.png" alt="iTerm's Preferences window, editing the "Keys" tab." />
</picture>

Click the box next to "Keyboard Shortcut" and then press ⌘P – you should see it appear in the box. Then, choose the "Send Text with 'Vim' Special Characters" option from the "Action" dropdown.

Then, simply type the _Vim_ binding you want to map this key to, like `\<C-p>` or `\<C-s>`. Don't forget the leading backslash – otherwise it'll just print literally.

And that's it! When you press ⌘P, _iTerm_ will now interpret it as Ctrl-P.

## Hacker Mode

While I was researching how to do this, I came across [this StackOverflow answer](https://stackoverflow.com/questions/33060569/mapping-command-s-to-w-in-vim/33063643#33063643) which suggested using the "Send Hex Code" action. (That's actually how I stumbled upon the "Vim Special Characters" option!)

This approach involves asking iTerm to sending the _hex codes_ for a different pair of keys to the shell, as if we'd hit those buttons on the keyboard instead. Unlike the Vim bindings, though, it can be difficult see at-a-glance how we'd adapt this to other keys. For that, we'd have to [use a program like `xxd`](https://stackoverflow.com/questions/36321230/finding-the-hex-code-sequence-for-a-key-combination/36403113#36403113) to inspect the hex codes for different keys on the keyboard.

So, to emulate Ctrl-P via a hex code, we'd map ⌘P to `0x10`. Neat!

Sadly, there's [no hex representation for the command key](https://superuser.com/questions/1178542/super-key-notation-for-stty/1178565#1178565), so this doesn't help us with our original problem. But in exchange for less readability, it does [unlock more potential keybindings](https://stackoverflow.com/questions/6205157/iterm-2-how-to-set-keyboard-shortcuts-to-jump-to-beginning-end-of-line/29403520#29403520) – for example, you could re-bind ⌘← to `0x01` to move the cursor to the beginning of your terminal prompt, or ⌘→ to `0x05` to jump to the end.

Happy hacking!

It turns out binding some keys in Vim & iTerm2 isn't as easy as you'd think!

Using the ⌘Command Key For Vim Shortcuts

Con Edison started offering [free smart air conditioner kits](https://conedsmartac.com/) a few years back. In exchange for letting ConEd occasionally adjust your air conditioner's temperature setting to reduce load on the electrical grid, you can make any A/C "smart"!

The Smart A/C kits are manufactured by [ThinkEco](http://www.thinkecoinc.com), and use a temperature sensor to toggle the power on and off.[^1] Unfortunately, their app is slow & doesn't integrate into existing smart ecosystems, like Apple's [Home](https://www.apple.com/ios/home/) app.

## Homebridge

[HomeKit](https://developer.apple.com/homekit/) is how smart devices integrate with Apple's ecosystem – allowing Siri to control the lights, or using geofences to automate devices when you arrive at home. Unfortunately, it isn't as widely supported as _Alexa_ or _Google Home_.

Luckily, [Homebridge](https://github.com/homebridge/homebridge) is there to help. It's a Node.js application that acts as a "bridge" between third-party device APIs & the HomeKit spec. The [homebridge-platform-smartac](https://github.com/dave-atx/homebridge-platform-smartac) package adds support for the ThinkEco SmartAC thermostats.

Homebridge emulates a HomeKit "bridge" - a piece of hardware, like the [Hue Bridge](https://www.philips-hue.com/en-us/p/hue-bridge/046677458478), that controls smart devices on a network. You'll need an "always on" device that can run Node.js - like a Raspberry Pi. I used a [Raspberry Pi 3 B+](https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/).

## Configuring Homebridge on a Raspberry Pi

I recommend setting up your Raspberry Pi using the [official "Getting Started" guide](https://projects.raspberrypi.org/en/projects/raspberry-pi-setting-up), or [this "headless setup" guide](https://hackernoon.com/raspberry-pi-headless-install-462ccabd75d0) if you don't have a spare monitor and keyboard. Don't forget to [change the default password](https://www.raspberrypi.org/documentation/linux/usage/users.md)!

### Install Node.js with nvm

Homebridge's [setup instructions](https://github.com/homebridge/homebridge/blob/master/README.md#installation) use `sudo npm install` and `--unsafe-perm`, which is scary! Instead, I'd recommend [installing Node.js with nvm](https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-ubuntu-18-04#installing-using-nvm) (which does not suffer from [the underlying node-gyp issue](https://github.com/nodejs/node-gyp/issues/454) that requires those elevated permissions. Plus, it's easy to install & swap versions!)

### Install Homebridge

Now, we can install Homebridge & its dependencies safely:

```sh
sudo apt-get install libavahi-compat-libdnssd-dev
npm install -g homebridge homebridge-platform-smartac
```

Next, create `~/.homebridge/config.yml` using [this template](https://github.com/dave-atx/homebridge-platform-smartac/blob/master/config-sample.json), with your ThinkEco username & password at the bottom. (Yes, you'll need to store your password in plaintext. 😬 This is one of the trade-offs of using an unofficial API like this.)

```json
"platforms": [
 {
 "platform": "SmartAC",
 "name": "ThinkEco SmartAC Platform",
 "username": "YOUR_THINKECO_EMAIL",
 "password": "YOUR_THINKECO_PASSWORD"
 }
]
```

Make sure you've [configured your ThinkEco modlets](https://support.thinkecoinc.com/customer/en/portal/articles/1966375-how-to-set-up-a-wifi-smartac-kit-from-a-browser-on-a-wifi-connected-computer-or-tablet-), and then run `homebridge` from your Raspberry Pi's terminal. You should see something like this:

![Running 'homebridge' from the terminal](https://images.ctfassets.net/pdp8shfq85fk/7Fo0ISN3POIZGWGALFl5RS/b3105e93dcb9ce5daf1341d84db383ed/homekit-terminal.png)

Open your _Home_ app on your phone, choose the "+" button on the Home or Rooms tab, "Add Accessory", and then scan the QR code from the terminal.

You should now see your air conditioner(s) listed as HomeKit accessories!

<img alt="Homebridge air conditioners in the iOS control center" src="https://images.ctfassets.net/pdp8shfq85fk/3RSCm9NxSyxteu6ajo7VK0/99a3edffc2cb80dbf345a20fc728fcc4/homekit-ios.png" width="350" />

### Configure as a Background Service

Your Homebridge accessories will only work as long as the `homebridge` command remains running on your Pi's terminal. You can configure it to run in the background using _systemd_.

Add a new "service" with `sudo systemctl edit --full homebridge`:

```ini
[Unit]
Description=Homebridge
Wants=network-online.target
After=network-online.target

[Service]
Type=simple

# Set this to the user you want to run Homebridge as. The
# default Raspberry Pi user is simply named 'pi', and the
# working directory should be that user's home directory:
User=pi
WorkingDirectory=/home/pi

# You can find the absolute path for 'homebridge' by running
# 'which homebridge' from the terminal. It will likely look
# something like this (but with your Node.js version):
ExecStart=/home/pi/.nvm/versions/node/v8.16.2/bin/homebridge

[Install]
WantedBy=multi-user.target
```

You can run `sudo systemctl enable homebridge` to run this service automatically when your Pi starts (and `sudo systemctl start homebridge` to start it right now).

## So how does this work?
Homebridge acts as an intermediary between the Home app & third-party APIs.

Homebridge communicates with the Home app using the [_HomeKit Accessory Protocol_](https://developer.apple.com/support/homekit-accessory-protocol/), via [hap-nodejs](https://github.com/homebridge/HAP-NodeJS). Different [types of accessories](https://github.com/homebridge/HAP-NodeJS/tree/master/src/accessories), like `Light` or `HeaterCooler`, expose different information & abilities.[^2]

On the other end, Homebridge communicates with devices via their own third-party APIs. (For example, the `homebridge-platform-smartac` plugin pretends to be a visitor to the ThinkEco website & uses their unofficial API).

## Uh oh! About that unofficial API...
The downside of using an unofficial API is, well... it's unofficial! ThinkEco updated ther web application in July 2018 with a brand new API. This completely broke the Homebridge plugin, and I had to contribute a fix that [updated all of those API calls](https://github.com/dave-atx/homebridge-platform-smartac/commit/5453fd7c2cb501eee2527cff4555de1671f21461) to continue to control my air conditioners.

Here's hoping for official HomeKit support in the future!

[^1]: The ThinkEco remote takes temperature readings every 10 minutes. It uses these readings to cut power to the A/C once the sensor reads 1°F below your target temperature & turns it back on once the temperature is 1°F above the target. ThinkEco claims that this [protects the air conditioner's compressor](https://support.thinkecoinc.com/customer/en/portal/articles/1998465-thermostat-responsiveness), but it's still probably not as safe as using the built-in power button.

[^2]: I was able to add the [ability to "tap" an air conditioner to turn it on or off](https://github.com/dave-atx/homebridge-platform-smartac/pull/5) by changing the accessory type from `Thermostat` to `HeaterCooler`! Yay, open source!

Controlling Con Ed's free Smart A/C kit with my iPhone & a Raspberry Pi.

Con Edison Smart A/Cs & Apple HomeKit

I've had a lot of people tell me they'd love to learn how to code, but that they wouldn't be good at it because they aren't good at math.

After a few times having this conversation, I started keeping track of how much math I use in my day-to-day work and spoiler alert: it's not much.[^1] I sometimes use statistics and probability, but I certainly don't use Linear Algebra or Differential Equations. And if you asked me to, I doubt I could without a textbook.

Instead of those high-level math courses, I really wish I had taken more classes on writing. It turns out the real world involves a lot of writing – emails, Slack messages, and meeting agendas – and if your job is programming, it involves a heck of a lot more than that. We just don't think of it that way.

## Source Code

Here's the dirty secret. Writing code is just that: _writing!_

Sure, you're writing instructions to a machine. Humans are much more forgiving conversation partners. But once you get used to the sometimes strange syntax, it's amazing how closely it resembles the way we talk to each other.

There are nouns (variables) and verbs (functions) & they're broken up into sentences (statements). Nouns may be described with adjectives (types or interfaces). And programmers often break independent thoughts into "paragraphs" separated by an empty line.

```js
let dave = new User();
dave.setEmail('david@example.com');

let welcomeEmail = new Email();
welcomeEmail.send(dave);
```

There's a lot of information communicated there. When writing code in object oriented languages, we're describing things and the ways they interact with each other. If you read that block of code aloud, it actually doesn't sound too awkward:

> Let Dave be a new user and set his email address to [dave@example.com](#). Then, let "welcome email" be a new email and send it to Dave.

It may not win points for eloquence, but it's pretty easy to follow! This is invaluable for getting your bearings when going back to change some behavior, debug an issue, or onboard yourself into a new codebase.

Unlike us, the computer wouldn't mind if I re-wrote the code like this:

```js
let a = new A();
a.b('dave@example.com');
let c = new C();
c.d(a);
```

That'd be awfully frustrating to work with, though, and I think that proves an important point: we write code for humans, more than for the machines that run it. Otherwise we'd all still be writing assembly!

While the computer only reads those lines long enough to optimize them into the second form (and beyond), humans interact with the high-level code again and again. Whether through code review, refactoring, fixing bugs, or integrating with other systems - it's almost guaranteed that code is _read_ many more times than it's written.

The parallels to written English don't end once the computer gets involved. As part of parsing & running code, computers build [abstract syntax trees](https://en.wikipedia.org/wiki/Abstract_syntax_tree) to describe the relationship between words and symbols, and enforce grammatical rules for how they can be combined. Linguists do the same with [phrase structure rules](https://en.wikipedia.org/wiki/Phrase_structure_rules) for how we can form valid English sentences.[^2]

Of course, sometimes we still write code that doesn't work. While both these tools provide some guardrails for effective communication, being grammatically correct doesn't always mean you'll make sense:

> "Colorless green ideas sleep furiously."

The linguist Noam Chomsky composed [that sentence](https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously) as an example of a phrase that makes sense grammatically but not semantically. For computer programs, this would be code that compiles but doesn't do what you expect - a bug!

## Comments

To help make sense of complicated logic, there's another part of code that's just for humans: comments. There's a frustratingly widespread belief in programming circles that code should be self-documenting and therefore doesn't need comments. But I think that's missing the point.

The source code itself should explain _what_ it does, but the comments explain _why_ it does that. There's often a lot of context that goes into a solution for a problem – business constraints, hacks to work around browser or framework quirks, or even just cutting a corner to meet a deadline. Comments are a way to leave a note to future readers so they know what you know.

Developers always complain about working on legacy code (and often, about how poorly written it is). I think an overwhelming reason for this is that context deteriorates over time - either the people working on a project change or the needs change and old solutions no longer make sense. Or the same people continue working on the same problem, but just forget things over time! I know I do.

Comments keep track of the things that aren't important to the computer, but are essential for understanding _why_ the computer is doing that task. In doing so, they preserve institutional memory which is crucially important to the long-term health of an organization.

## Commit Messages & Pull Requests

A huge part of writing code is collaboration, but even if you're working alone it's helpful to keep a history of your work. This is where version control comes in. Unfortunately, commit messages often end up as an afterthought as deadlines or other frustrations ramp up the pressure:

<a href="https://xkcd.com/1296/">
 <picture>
 <source srcset="https://images.ctfassets.net/pdp8shfq85fk/1V58H86uJxd5oS4DjvZptj/d8aa0174f5cd8567310941ab59dfd33f/git_commit_2x.png" media="(prefers-color-scheme: dark)">
 <img src="https://imgs.xkcd.com/comics/git_commit_2x.png" alt="XKCD Comic: As a project drags on, my commit messages get less and less informative." width="439" height="auto" />
 </picture>
</a>

With just a bit of discipline, however, commit messages become an amazing tool. It's not unusual for a developer to look at a file and wonder why a change was made. The git commit log is a great tool to jump back in time and ask the author. Like code comments, they're a way to maintain context.

The aggressively named [git blame](https://help.github.com/articles/tracing-changes-in-a-file/) command allows you to trace when a particular line was last changed, which can often help explain its use now. And in GitHub, the commit that a change is introduced in links back to the containing pull request, adding even more valuable context.

Pull requests are where it all comes together. A pull request groups together code changes, comments, and commits into a neatly packaged solution to a problem. When reviewing a pull request, the diff tells you what changed but the comments and commit messages should tell you _why_.

To remind us of any other questions we should be answering, our team at [DoSomething.org](https://www.dosomething.org) uses a [pull request template](https://quickleft.com/blog/pull-request-templates-make-code-review-easier/). It's a great reminder of the kinds of questions your teammates might have before handing code off for review.

<img src="//images.ctfassets.net/pdp8shfq85fk/26UEDl6h9ddYCl8iArhJaM/da731c6ebb4bd80250615564744f2129/pull-request.png" alt="a pull request" width="600" height="auto" />

One of the nice side-effects of writing more thoughtful commit messages and pull requests is that it forces you to stop and think about why you’re writing that line of code. Is this the most efficient way of solving this problem? Am I even solving the problem I set out to? By “making a case” for your code in your comments and commits, you’ll find you catch bugs and logic errors, and find solutions you may have missed had you been in more of a hurry.

## It's all communication.

There's a myth of the "genius" that writes code so clever that nobody else on their team can understand it. I think that a truly great programmer writes code so clear that nobody can _misunderstand_ it.

It's often said that "you don't really know it unless you can teach it", and I think that's especially true with programming. What's simple to you may be complex to me, and vice versa. The most interesting (and challenging) programming work is taking something complex and making it seem simple.

Writing code is rarely about finding the most clever solution. It’s about finding the most understandable solution. The more code I write, the more I wish I'd gotten a degree in English.

[^1]: Full disclosure: I write web apps. If you're working on machine learning or computer graphics, you probably do need math. But you're still writing code, so don't close the tab just yet!
[^2]: I took a bunch of Psychology classes as electives and it's fascinating how much overlap there is between Linguistics and compiler & type theory in Computer Science.

Why writing clear code is often more important than writing efficient code.

Good Programmers Are Good Writers

I presented at the _NYC Contentful Meetup_ about how we re-built our website at DoSomething.org, and some of the lessons we learned along the way.

### Deconstructing the Monolith
Like many organizations, we had an aging monolithic application that was resistant to change. We wanted to burn it all down and rewrite it from scratch, but we accepted that was probably a [bad idea](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/).

Instead, we used the [Strangler Pattern](https://martinfowler.com/bliki/StranglerFigApplication.html) to slowly extract & rebuild - moving our chatbot into an event-driven Node.js application, our user & activity data into [Laravel](https://laravel.com) REST APIs, and our content into [Contentful](https://www.contentful.com).

This allowed us to tackle our overwhelming technical debt in manageable chunks, completely rebuilding a complex monolith – over five years! – without stopping feature development.

### A Toolkit for Social Change

Our old content management system had a strict "one size fits all" schema, which stifled our editors' creativity & made it difficult to quickly respond to current events. In order to build a flexible toolkit for social change, we architected our new website around the concept of _pages_ and _blocks_.

Blocks are user interface elements that can be arranged to make page layouts. We used an adaptor component, `ContentfulEntry`, that read JSON from our CMS & translated it into the relevant React interface component.

This also allowed us to iterate quickly, adding new site-wide or one-off functionality without needing to adjust our underlying page schema.

### Making Informed Decisions
While moving quickly, we needed a way to measure the impact of our changes. We use [Sixpack](https://sixpack.seatgeek.com), an open-source A/B testing tool from the team at Seatgeek. Sixpack allows us to run experiments in our codebase, comparing the effectiveness of one interface to another.

We also created an `SixpackExperiment` block in our content management system, allowing editors to create their own self-service experiments to test different content and blocks.

### Continued Developments
Development doesn't stop after shipping 1.0. We're continuing to evolve our website and development practices. We use the [Contentful Migration CLI](https://github.com/contentful/migration-cli) to evolve our content models (and content itself) using scripts, and are using [GraphQL](https://graphql.org) to optimize our queries to these newly decoupled services.

How we rebuilt our website & some of the lessons we learned along the way.

Rebuilding DoSomething.org

In Summer 2015, I built my own parser, [Sasstree](http://dfurnes.github.io/sasstree/), to power a [code linter](https://github.com/DFurnes/sasslint). It was a fascinating side project (and a refreshing change of pace from my day-job writing a web application). And it helped me better understand a question I'd been wondering about: how do computers make sense of what we write?

## What's a compiler?

A compiler is a computer program that translates computer programs - either turning source code into machine code (like compiling C++ code into a 64-bit Windows binary) or to another language (like how the [Typescript](https://www.typescriptlang.org/) and [Babel](https://babeljs.io/) compilers output JavaScript[^1]).

And compilers can process more than just source code! Markdown compilers like [Marked](https://github.com/markedjs/marked) output HTML, and GraphQL and SQL use compilers to parse queries. Heck, JavaScript's `JSON.parse` is a compiler that parses JSON text into JavaScript variables!

## How do compilers work?

Compilers process code in stages. First, they need to make sense of the text they've been given by *tokenizing* and *parsing* it. This is tackled by the "front-end" of the compiler. After that, the "backend" of the compiler can make _optimizations_ and _generate_ the final result.


## Part I: Frontend

The frontend's job is to turn structured text into something that's easier for the computer to work with - an abstract syntax tree.



### Tokenizer (Lexical Analysis)

The tokenizer (sometimes called the _lexer_ or _scanner_) is the first stage of the compiler, and the first component of the frontend. It breaks the source code into "words", called *tokens*.

Tokens are characters or strings that have particular meaning, like a number, a string, or or keywords (like `var` or `function`). Here's how we might tokenize a simple math equation:

```js
// tokenize("2 + 3 = 5");

[
 {type: 'Number', value: '2'},
 {type: 'Operator', value: '+'},
 {type: 'Number', value: '3'},
 {type: 'EqualSign', value: '='},
 {type: 'Number', value: '5'},
]
```

You could parse strings into tokens using regular expressions, like using `/[0-9]+/` to match a number token. However, regular expressions are slow - and notoriously tricky! - so it's [probably safer](https://commandcenter.blogspot.com/2011/08/regular-expressions-in-lexing-and.html) to use simple conditionals & loops.

Parsing the input text into "words", instead of one unbroken stream of characters, might not look like much but it makes the compiler's next job easier.


### Parser (Syntactic Analysis)

The parser takes the "words" created by the tokenizer and groups them into "sentences"[^2], based on the [grammatical rules](https://en.wikipedia.org/wiki/Context-free_grammar) of the source language. This process is called _syntactic analysis_.

The result of this stage is an _abstract syntax tree_. This is a [tree data structure](https://en.wikipedia.org/wiki/Tree_(data_structure)) that makes it easier to think about logical parts of the source code & how they relate to each other:


```js
// parse([
// {type: 'Number', value: '2',
// {type: 'Operator', value: '+'},
// {type: 'Number', value: '3'},
// {type: 'EqualSign', value: '='},
// {type: 'Number', value: '5'},
// ]);

{
 type: 'Equation',
 leftSide: {
 type: 'Expression',
 operator: '+',
 leftOperand: {
 type: 'Number',
 value: '2'
 },
 rightOperand: {
 type: 'Number',
 value: '3'
 },
 },
 rightSide: {
 type: 'Number',
 value: '5'
 }
}
```

💡 You can play with the syntax tree for my SCSS parser on the <a href="https://dfurnes.github.io/sasstree/">live demo</a>!

 
The grammar tells the parser how tokens may (and may not) be combined with each other. If it finds something it wasn't expecting, this is where a "syntax error" might occur:

```js
2 + + 3 = 5
 // ↑ syntax error! unexpected token '+'. expected 'Number'.
```

Parsers can read tokens in a couple different ways, depending on the complexity of the language's grammar. The simplest option is a "top-down" parser.



#### Top-Down Parsers

Top-down, or _recursive descent_, parsers read the token stream from left to right. The parser uses functions to process each type of element that could exist in the grammar.

To parse math equations like in the examples above, we'd write functions like `parseEquation`, `parseExpression` and `parseNumber`. Each method is responsible for parsing that particular type of thing, and hands off parsing to other functions when it makes sense.

A top-down parser always starts with the "outermost" grammar rule, like `parseEquation`. That function would then hand off to `parseExpression`, which in turn might call `parseNumber`.

Sometimes, the parser might also need to "peek" ahead to determine how to interpret a given token - like figuring out whether a `NUMBER` token is a standalone number or the first term in an equation.

Languages that can be parsed this way are called **LL(1)** grammars, because the tokens are parsed **left**-to-right, the parser always produces a **leftmost** derivation (a fancy way of saying it builds the tree from the top-down), and it peeks at most **one** symbol ahead.

Compilers like [gcc](https://gcc.gnu.org/), [golang](https://golang.org/), and [V8](https://v8.dev/) use handwritten recursive-descent parsers.

#### Bottom-Up Parsers

More complicated languages that can't be unambiguously parsed top-to-bottom might use a "bottom-up" parser, which starts with the bottom "leaf" nodes on the AST and builds "up" from there. These types of parsers are too complicated to write by hand, and are therefore generally created by tools like [ANTLR](https://www.antlr.org/) or [Bison](https://www.gnu.org/software/bison/) (which powers the parsers for Ruby and PHP).

One notable advantage of LR parsers is that their grammars can include [left recursion](http://en.wikipedia.org/wiki/Left_recursion), because they already know about the children when evaluating a parent node that might include left recursion.

Languages that can be parsed this way are called **LR** grammars because they parse the provided tokens **left**-to-right, but use the **rightmost** derivation (which is just a fancy way of saying they build the AST from bottom-to-top).



## Part II: Backend

Now that the compiler understands the text it was given, it's time to do something with it! The backend's job is to optimize and transform the parsed code into the desired output format.

(The "backend" for my parser, [Sasstree](http://dfurnes.github.io/sasstree/), was a [code linter](https://github.com/DFurnes/sasslint). It traversed the AST and ran functions to check code style on each node, and then output their suggestions to the console).

### Code Optimization

Optimization is the compiler's superpower. It allows humans to focus on writing readable source code, while the computer finds ways to optimize it for a machine. (That usually means "faster", but it could also mean using less memory or being more power-efficient).

Since the compiler has a flawless memory & a perfect understanding of how code is structured, it can make optimizations that would be too tedious for any programmer to bother with.

In many modern languages, like [Rust](https://www.rust-lang.org/) and [Swift](https://swift.org/), the compiler optimization step is handled by [LLVM](https://llvm.org/). LLVM is able to optimize different types of languages by using a common "intermediate representation" for the optimization step. The LLVM project also includes front-end and back-end components for a slew of languages.[^3]

There are also compilers that solely focus on optimization. For example, [UglifyJS](https://github.com/mishoo/UglifyJS) renames JavaScript variables to space-efficient (but completely illegible) names like `n` and `p`. It can also remove "dead" blocks of code that are never used. (And experimental tools like [Prepack](https://prepack.io/) take this even further by actually evaluating code _in the compiler_ when possible!)

Of course, these tools still just create other (smaller and faster) JavaScript files. Web browsers have their own compilers that then parse, optimize, and execute that code.[^4]

### Code Generation

The code generator step takes this optimized version of the code & writes it into the compiler's target language. This might be instructions for a particular machine, another high-level language... or just running the code right then and there!

#### Machine Code Generation

If the target is machine code, then this is where the compiler makes platform-specific optimizations (like picking processor [registers](https://softwareengineering.stackexchange.com/questions/209760/what-are-cpu-registers) to store variables in). This is how the same program can be compiled for different types of processors - like a 32-bit or 64-bit binary for Windows, or an [Intel or PowerPC](https://en.wikipedia.org/wiki/Universal_binary) binary for macOS.

#### High-Level Code Generation

Other compilers output high-level code, like JavaScript. After optimizations are performed, the compiler traverses the syntax tree one last time. For each type of node, it runs a "print" or `toString` function to write it in the target language.

#### Code Execution

Some compilers aren't meant to output code at all! These compilers are called _interpreters_. Instead of walking the tree and running functions to print compiled machine or high-level code, they "run" each type of node directly from the tree.

It can be slow to re-compile the same functions over and over, so many interpreted languages[^5] instead use _just-in-time_ compilers. These languages are still run on-demand, but the compiler keeps track of how many times each function is called. If one gets popular, it's optimized & compiled to machine code for a performance boost.

## The History of Compilers

Early computers were programmed by writing binary. Not only was this dreadfully tedious, these instructions were specific to a particular computer and had to be rewritten from scratch if you ever wanted to run a program on a different machine. Ouch.

The first compiler [was invented by Grace Hopper](https://www.computinghistory.org.uk/det/5487/Grace-Hopper-completes-the-A-0-Compiler/) in 1952 as a way to make programming less tedious by using English words instead of 0s and 1s. It paved the way for the introduction of high-level programming languages, like COBOL, that are still used to this day.

Many of the ideas that form the basis for modern compilers, like LR grammars (invented [by Donald Knuth](https://web.archive.org/web/20120315152151/http://www.cs.dartmouth.edu/~mckeeman/cs48/mxcom/doc/knuth65.pdf)) or just-in-time compilation (invented by John McCarthy [for LISP](https://en.wikipedia.org/wiki/Just-in-time_compilation#History)), were also created in the 60s.

## References:

[_Compilers: Principles, Techniques, and Tools_](https://www.amazon.com/dp/0321486811) – colloquially known as "The Dragon Book" because of its absurd cover art. It's dense, but covers almost anything you could want to know about compilers.

[_Writing An Interpreter In Go_](https://interpreterbook.com) - this book walks through building a fully tested parser & interpreter for a simple programming language in Go. (This is a really fun excuse to play with Go!)

[jamiebuilds/the-super-tiny-compiler](https://github.com/jamiebuilds/the-super-tiny-compiler) - a simple well-annotated compiler for a LISP-like language, written in JavaScript.

[LL & LR Parsing Demystified](https://blog.reverberate.org/2013/07/ll-and-lr-parsing-demystified.html) - the best explanation of LL & LR parsing I've seen, with a clear explanation of the pros & cons of each


[^1]: And some compilers output the exact same language they take in! [Prettier](https://prettier.io) takes in JavaScript, parses it to understand the code's structure, and outputs it with standard formatting rules. And [jscodeshift](https://github.com/facebook/jscodeshift) takes in JavaScript code and applies [codemods](https://github.com/reactjs/react-codemod) to edit it programmatically.

[^2]: This is more than just a convenient analogy! Linguists use [phrase structure rules](https://en.wikipedia.org/wiki/Phrase_structure_rules) to build syntax trees out of human language, just like compilers do for code. If we were writing a compiler for English, our tokenizer would tag words as nouns, verbs, and adjectives. Our parser would wire them together (for example, identifying the subject of a sentence or tying an adjective to the noun it describes).

[^3]: You can even compile LLVM-based languages like C, C++, Swift, or Rust to [WebAssembly](https://webassembly.org/) (via [emscripten](https://emscripten.org/)) and run them in a web browser! Woah!

[^4]: And surprisingly, web browsers actually start the optimization process [in the _parser_](https://v8.dev/blog/preparser)! They "skim" code using a _preparser_, which does the bare minimum work needed to identify all the functions in a JavaScript file (but skips most of the contents). Then, the parser only has to fully parse each function if it's run later on!

[^5]: Examples include Ruby's [MJIT Compiler](https://blog.heroku.com/ruby-mjit), the [PHP 8 JIT](https://stitcher.io/blog/php-jit), and WebKit's [B3 JIT](https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/).

How To Speak Computer

Pattern libraries exploded into popularity over the past couple years as a rebellion against confusing, mismatched designs & websites that become increasingly complex and difficult to maintain with age.

Two years ago, we found ourselves in that situation at [DoSomething.org](https://www.dosomething.org/). When performing an audit of our existing stylesheets, we found repetition all over the place.[^1] It was hard to know where a particular rule would apply, and the only reliable solution was either duplicating code using new selectors, or applying skyrocketing specificity (hello, `!important`).

Development had slowed to a halt, so we declared bankruptcy and began to rebuild our CSS with a focus on maintainability. We rebuilt our site chrome in a fresh stylesheet, which we used when we redesigned our homepage in 2013.

Of course, most websites are never "finished". We knew it would only be a matter of time until our lean new stylesheet once again grew bulky & slow, unless we addressed the problems that led us there the first time around. 

This meant changing how we worked.

![A screenshot of Forge, the DoSomething.org pattern library.](https://images.ctfassets.net/pdp8shfq85fk/jZODmlpdWG7SqvXqXwiq0/a89aea568c6541597abeb94633c34692/forge.png)

We built [Forge](http://forge.dosomething.org/), our pattern library, as a weapon against cruft. It's a living design tool that we've maintained and expanded over the past two years. By building and cataloguing reuseable components, we've been able to keep our stylesheets under control even as our site continues to grow.

We write Forge components using [Sass](https://sass-lang.com). Each component lives in a standalone file, like [button.scss](https://github.com/DoSomething/forge/blob/b8b6a87794351e15d2064ae0cc75ca0852ff4ca5/scss/_components/_forms/_button.scss), named for its top-level CSS class. This helps prevent naming collisions & makes each pattern easy to find. Each file also begins with a [KSS](https://warpspire.com/kss/) documentation block, which allows us to write comments that are automatically parsed into [user-friendly documentation](http://forge.dosomething.org/#forms-button), published via _GitHub Pages_.

We distribute the final product as an [npm module](https://www.npmjs.com/package/@dosomething/forge).[^2] This allows us to version our designs just like any other dependency. If we make a breaking change - where we'd have to change an application's markup - we can communicate that via [semantic versioning](https://semver.org). And, because we can "pin" dependencies in each application, there's no rush to upgrade everything at once.

## Process

A pattern library is, first and foremost, a tool for building a healthy development process. It's a shared language for developers, designers, and product owners.

It makes developers' lives easier by allowing us to reference things we've already built, rather than reverse engineering previous solutions to match pixels in a mock. By encouraging developers to build & document reusable components, we make it easier to _reuse_ than rebuild. This is true for designers as well!

Pattern libraries like Forge also make it easier to *talk* about design. Mocks – let's face it – are troublesome. Because they're a static canvas, it's easy to forget how dynamic the web is! Multiple screen sizes, hover states, and variable content all fall by the wayside. And because mocks start as a blank canvas, they encourage you to build everything from scratch every time.

Think of your pattern library as an API for your stylesheets. Just like an API hides complexity between different classes or services in your codebase, your pattern library is a interface that allows everyone to use interface patterns without necessarily understanding all the code behind the scenes.

## Complexity

A pattern library is like "your own personal [Bootstrap](http://getbootstrap.com/)". But instead of a toolkit for building any sort of website, you're building specialized tools for building *your* website. So while Bootstrap includes grids, form styles, and some common elements like breadcrumbs, your own pattern library will include things that are more specific to your particular needs.

When building a pattern library for yourself, you're zeroing in on patterns in your own designs. What makes your website special? What unique challenges has your team had to solve? The easiest way to start building a pattern library is to look for things that you repeat in your designs.

Any project inevitably gets more and more complex over time. The goal of a pattern library is to avoid letting that complexity slow you down! You can keep nimble by limiting the number of things you need to be able to hold in your head to work on a project. Each component in your pattern library is an isolated solution to a problem your team faced when building your site.

## Design & Architecture

A pattern library merges the domains of software design and software architecture. Think about the [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single-responsibility_principle) or [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself): it's not just about saving keystrokes; it’s about making sure you have a single representation of any logic you depend on. If styles are scattered about your codebase, it makes them hard to reason about or change.

To apply the _Single Responsibility Principle_ to our stylesheets, we first identify and separate responsibilities. This means picking out pieces of a design that deal with things like layout, visual styles, or interactivity. A great example of this is Nicole Sullivan's [media object](http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code/) – we found it everywhere in our designs. By encapsulating that layout concern into a [reusable class](https://github.com/DoSomething/forge/blob/b8b6a87794351e15d2064ae0cc75ca0852ff4ca5/scss/_modules/_figure.scss), we're able to keep those implementation details in one place. We can then layer on visual styles or interactivity by composing this with other patterns.

We constantly make revisions to components – either for UX or visual improvements, or to fix bugs we've uncovered. When we fix a component, all of the pages that use it get that improvement for free. (And because each component has a single responsibility, we can feel safer updating and changing them without unintentionally breaking things!)

## The Future

So how will we be building pattern libraries a year or two down the road?

 
<img src="//images.ctfassets.net/pdp8shfq85fk/5raVDNSkbY9KlfMp8Zvv5Q/371ba6b28a6f87c81809eccd215253bb/react.png" alt="React.js logo" width="400" />
 

It’s hard to talk about components without thinking of [React](http://facebook.github.io/react/), Facebook’s library for building the “view” layer of rich javascript applications. It touts simpler code through one-way data flow & a nifty Virtual DOM diffing algorithm that handles state transitions for you. And at its core is [the idea of components](http://facebook.github.io/react/docs/why-react.html):

> "React is all about building reusable components. In fact, with React the only thing you do is build components. Since they're so encapsulated, components make code reuse, testing, and separation of concerns easy."

That sounds awfully familiar! Those components are your patterns. 

With React's [prop types](http://facebook.github.io/react/docs/typechecking-with-proptypes.html), we can take our KSS documentation on how components should be used & automatically validate input. If an invalid argument is provided to a component, it will print an error to the web inspector.

About a year after React was introduced, [Webpack](https://webpack.js.org) entered the scene. Like _RequireJS_ & _Browserify_, it lets you bundle your scripts into modules. But it _also_ supports other types of assets through loaders. Using Webpack’s CSS loader, we can import our CSS class names directly into our React components.[^3]

These are the missing pieces for building cohesive front-end applications! Together, these tools let you bundle everything for a pattern – markup, styles, behavior, and documentation – together in one place:

```js
import React from 'react';
import classNames from 'classnames';
import styles from './button.css';

function Button(props) {
 var kind = props.kind || 'primary';
 var classes = classNames([styles.base, styles[kind]]);
 
 return (
 <button className={classes} onClick={props.onClick}>
 {props.children}
 </button>
 );
}

Button.propTypes = {
 kind: React.PropTypes.oneOf(Object.keys(styles)),
 onClick: React.PropTypes.fn,
};

export default Button;
```

And this isn't just about React! All the major web frameworks are moving to a components-based UI architecture. So no matter your stack, your pattern library will play a central role in how you build applications.[^4]

## Build things to help you build things!

Your pattern library is not the product. It's a tool to help make development easier by giving engineers, designers, and product owners a common language, and making it easy to document and reuse solutions to problems in the future.

Ultimately, this is about building things that help you build things. Your pattern library is a toolkit of battle-tested solutions to problems that your future self can reach for when they arise again.

[^1]: And we weren't alone! I love Brad Frost's concept of an [interface inventory](http://bradfrost.com/blog/post/interface-inventory/) as a way of taming this sort of "design bloat". It's incredibly easy for designs to fragment, especially if you're working on a large website – or [operating system](https://twitter.com/zacbowden/status/619947511868997632) – with a big team.

[^2]: And yes - this is a *public* package and repository! We [open-source all of our code](https://blog.dosomething.org/we-open-sourced-our-code-here-s-why-you-should-too-437bf5ef8e58) at DoSomething.org, including our production website. We've learned so much from others and want to make sure we give back. Feel free to poke around, make an issue or ask a question, or fork it as a blueprint for your own pattern library.

[^3]: The styles variable is a JavaScript object that exports classnames from our CSS file. Because Webpack knows all the classes we use in our application, it can automatically generate unique classnames for them as [CSS Modules](http://glenmaddern.com/articles/css-modules). It then outputs a “manifest” that maps all those optimized classnames to the human readable equivalents, which my component or app can use.

[^4]: Web standards are moving in this direction too – [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) will introduce custom elements, template tags, & scoped CSS!

How pattern libraries can decrease complexity & increase team velocity.

David Furnes

2020

2019

2018

2015

.css-1te1vur{position:relative;cursor:pointer;}David Furnes.css-1qms9jn{position:absolute;top:50%;left:50%;}

2020

2019

2018

2015

David Furnes