Shrey Banga's blog

Learning Rust in 3 attempts

2024-02-02T00:00:00.000Z

Learning Rust in 3 attempts

One of my earliest programming languages was C++, which for all its warts, was a giant leap from my first language, BASIC. I especially enjoyed understanding precisely what's happening at the CPU and memory level¹ to my program when it runs.

Once I got a Real Job, I moved on to higher level languages and spent the last decade mostly writing JavaScript and Python. These are both exceedingly powerful languages that have been a joy to build stuff with, but they do sometimes make you miss the low level control of a systems language². But C++ had moved on quite a bit since I last wrote it and it didn't really entice me as a pleasant language to use on the side.

So Rust had my attention when I first heard of it and made a few attempts at learning it. I've finally reached a point where I feel comfortable and productive in it, so I thought I'd log my progress in case it helps someone get there faster.

Attempt 1: RTFM

For all of the languages I've learned in recent memory (TypeScript, Go, Python), my process was the same – read the official manual, start using it and read the documentation as needed. So back in 2019, I did the same with Rust. I read The Book and started using it for some mini projects.

But this time I didn't feel productive enough to actually start building with it. I could get programs to work by pattern matching and trying things somewhat randomly to appease the compiler, but it didn't feel like I knew what was really going on. It was a while back, but I felt that The Book didn't quite have a specific audience in mind and tended to distribute time to topics unevenly in relation to their difficulty.

Attempt 2: A hobby project

A number of people mentioned how they eventually got productive by just writing more rust, so I thought I would try that by using it for a big project.

One of my favorite projects is ray tracing, ever since I learned how it works in POV-Ray's manual (where they build a ray tracer within POV-Ray using its meta language), converted it into a C++ program and rendered it in glorious 800x600x24 resolution via extended Mode 13h. I still cannot help but be amazed that a bit of high school level math can produce such realistic images. So I thought it would be fun to write one in Rust.

I wrote a very basic spheres-only version in July 2022 and got it to do multi-threaded rendering in about 5 days. This was substantial enough to actually feel productive, and a testament to Rust's design that adding correct concurrency was not particularly difficult. I was even more impressed when I swapped out my multi-threading code with the crayon library's parallel iterator.

However, the raytracer was pretty limited at this point. There's only so much you can render with matte spheres:

So I opened up the PBR book and slowly added more features while keeping my day job. While I was learning a number of things around this time (like multiple importance sampling and Radiometry), I wasn't learning much Rust.

It looks like you are trying to write a program

In 2023, I had a break from work and had a lot more time to spend on it. At this point, GitHub Copilot had come into being and I enabled it for this project. It had two interesting effects:

It was good at filling in the obvious and repetitive code that needs to be written in graphics, like repeating a calculation for $x$ , $y$ and $z$ dimensions.
It would sometimes show me new features of rust that I was not aware of. With its help, I managed to even write a parser for a custom scene file format for the raytracer, with some particularly clever logic to make it concise and extensible.

However, while it made me feel more productive and let me focus on figuring out the trickier aspects of raytracing, I realized that my understanding of rust wasn't getting particularly clearer. So I eventually disabled it and decided to learn it the old fashioned way.

Attempt 3: Read a book

I picked up the Programming Rust, 2nd Edition ebook, which seemed to be the most common recommendation. I made my way through it slowly at first but I started to notice that I was "getting it" more now. It's hard to say whether this was a result of better writing or having had more practice with it, but it didn't take long to realize that the book was clearing the fog. I definitely felt that the authors were good at realizing which parts deserved more elaboration and which didn't.

Around this time, I left my job and took a complete break from programming. Then around the end of 2023, after I did Advent of Code in Rust, I got a second wind and started reading the book again. As I learned things I could use in the raytracer, I would go back and apply them to it. I eventually once again got distracted by the graphics and added several sophisticated features to get to the point of rendering images like this:

The Wooden Staircase by Wig42

Anyway, I did finish the book once the raytracing side quest was done (for now). While there are a few chapters that will need a revisit when I actually need to use them (Async, FFI, unsafe rust), I ended it feeling a lot more comfortable with the language.

For the most recent work I did in the language, I felt nearly as productive as I had previously in TypeScript or Python³. Rust is a vast language and sometimes the safety checks can get quite onerous, so I'm sure I won't always feel this optimistic about it, but it's nice to not be intimidated by a popular systems level language anymore.

I was equally disheartened and delighted to later learn that the simple mental model I had for the cpu and memory were yet further from reality. Compiler optimizations, pipelining, branch prediction, out of order execution etc. were all fascinating and slightly terrifying things to learn about. ↩
Especially when the GC comes a knockin'. ↩
Each of these languages excel in their own domains, so perhaps this isn't totally accurate. I wouldn't be as productive building websites in Rust as I would be in TypeScript, but the opposite is true for writing, say, a database. ↩

The rocket equation for startups

2024-01-09T00:00:00.000Z

The rocket equation for startups

Startups love being compared to rocket ships. Let's take that analogy where it has never gone before.

The tyranny of the equation

For the unfamiliar, the rocket equation describes how much total mass ( $m_t$ ) your rocket will be if you want to get a payload of a given mass ( $m_f$ ) up to a given velocity ( $\Delta v$ ), if the exhaust velocity of the fuel is $v_e$ . It turns out to be exponential, which makes going to space quite expensive:

\begin{align} m_t = m_f e^{\Delta v / v_\text{e}} \end{align}

In plainer words, to carry some stuff to space, you need to carry some fuel, but to carry that fuel, you need to carry some more fuel, and so on. To leave the gravitational pull of a planet, you need to reach a minimum velocity, called the escape velocity. As the required velocity increases, the required mass increases exponentially.

When an organization hires more people to do more work, it must also hire some people to support these new people, who in turn might need to be supported by a few more new people, and so on. If you take the rocket analogy literally, the size of the organization must grow exponentially relative to the amount of work that needs to be done.

If you have worked at a rapidly growing startup, you have probably experienced this. You spend ever more effort hiring and training people, and yet there are never enough people to work on everything and support everyone. In the extreme case, it can feel like a paradoxical machine where everyone is busy hiring and training new people so they can get the work done that no one is doing because everyone is busy hiring.

How to leave the gravity well

Startups of course don't usually¹ want to grow their size exponentially. Still taking the equation quite literally, there are a few ways around it:

Use more efficient fuel. There are many ways to translate this: hire people who need less support. Focus on doing fewer things. Sell to bigger customers.² Build on free technology and content.³ Hire generalists who can fill multiple roles.

Lower the escape velocity⁴. If we take escape velocity to mean survival of the company, lowering it could mean picking a different business plan, a different mechanism of funding, or pivoting to a market with a lower floor.

Launch smaller rockets. This doesn't relieve you of the exponential growth rate, but it gives you more attempts at finding the parameters of a successful launch. This is more commonly deployed after an organization is feeling the effects of rapid growth. Tiger teams, two pizza teams, moonshots, 20% time, hack days etc. are all variants on the same desire – send out smaller rockets and see which ones make it.

Back on planet earth

As promised, I've stretched the analogy to max q. It amused me how far it held up as I was noodling with it, so I wrote it down. Hopefully, next time someone offers you a seat on a rocket ship, this will inspire a little chuckle.

Pre-2023, some startups did appear to be manifesting their higher valuations by hiring a lot of people very quickly. ↩
Most tech companies attempt a pivot to selling to big enterprises sooner or later. ↩
Arguably, many of the largest consumer software companies succeeded by figuring out novel ways to extract value from information and technology that was shared for free by someone. ↩
Interestingly, since escape velocity is independent of mass, load-shedding (i.e. layoffs) does not actually lower it. ↩

I spent way too long building this blog

2023-12-23T00:00:00.000Z

I spent way too long building this blog

...and must therefore write about it to alleviate the guilt.

Hiding from Dr. Jekyll

As you can probably tell, this blog has been inactive since the peak of March 2020, where I apparently reacted to the pandemic with a surge in creativity.

Back then, the blog was hosted on GitHub pages, which used Jekyll to build and serve the blog from a set of markdown files. This was fine to start with, but it used a lot of unfamiliar tech (Ruby, Liquid, markdown extensions) that made it difficult to configure and maintain. It soon bit rotted enough to discourage me from writing in the fleeting moments of inspiration.

I have been taking a break from programming for the past few months and as I return from it to start a job search, I thought I should clean up my online presence. So I decided it was finally time to replace the Jekyll setup.

My initial investigation revealed that GitHub now allows you to deploy pages using GitHub Actions, so you can pick from a plethora of static site generators. However, this time I wanted something very minimal that I could jump back into a year from now and not get bogged down reading outdated docs and updating dependencies.

So, I decided it was finally time to enter the rite of passage that is writing a tool to generate your website.

Making a list, checking it twice

Such projects go a lot better if I have a clear idea of what I want from them. Otherwise, I spend way too much time playing with the tech and not enough building the thing that needs to exist.

I had a rough idea that I wanted a fast, minimal, modern site that introduces myself and hosts my writing. I imagined expanding it out over time to link to more details about my work and side projects.

My previous home page was a small 3d business card¹ that didn't link to my blog². The site and the blog were hosted via separate GitHub repos, where the home page was just a static site and the blog was generated by Jekyll.

There were a number of things I liked about the old blog — posts authored in markdown³, footnotes, math, syntax-highlighting, heading permalinks, dates in urls, autogenerated RSS feed, SEO and OpenGraph tags etc.

So I made a checklist of the features I wanted in the new setup and got cracking.

First, we prototype...

I first wanted to see how feasible it was to write something that could generate a site with similar functionality without the same complexity as before.

My plan was to find a way to convert the markdown content of posts to html, wrap it in some scaffolding to form a valid html document and save that to a static directory that the public site could be served from. Even better if this could be done automatically in a GitHub Action.

I have been learning Rust lately and using it for Advent of Code, so I briefly wondered if I should use it for this project as well. I decided against it quickly, because so far it hasn't proved great for prototyping and the ecosystem of markdown related tooling was much bigger in JS.

So I started with a node+TypeScript project. I used react-markdown (which uses unifiedjs and plugins) to parse the markdown posts, wrapped them in a component and serialized them to corresponding html files.

For styling, I like the utility file approach⁴ of writing out generic classes like .font-small and using those to style components. We used this approach at Airtable and it felt much more productive than the traditional approach of using CSS. I created one from scratch, allowing that I might switch over to a framework, but didn't want the overhead from the start.

With that, I had a tool that could generate blog posts to my liking and enough confidence that this was worth building out.

...then draw rest of the owl

A bunch of the remaining work was just setting up the code as a script that could generate the full site with some configurable parameters like the host name (for local testing) and the posts directory (so I could store drafts separately). I'll skip those boring details, but there were a few fun things along the way:

Deploying to GitHub Pages

I remembered finding the original process for deploying a GitHub Pages website quite confusing. Digging around into the source code of various GitHub actions demystified it a lot. I started with this action that deploys a static directory and modified it to run a build step first. This pretty much worked the first time, partly out of luck because I was placing my generated files in _site/ (a holdover from Jekyll) and the upload-pages-artifact action defaults to picking up the content from that folder.

Generating preview images for OpenGraph

One of the useful things Jekyll generated was metadata for search engines and social networks to help surface your content properly. Those were fairly easy to figure out since I already had the relevant metadata from posts. While looking at other blogs for some inspiration, I noticed that Guillermo Rauch's blog had an <og:image content="..."> tag as well, which Jekyll did not generate.

On opening the linked URL, I realized that this was meant for the preview image in social networks, such as this one for an issue on GitHub:

This was too charming to not implement. I knew that generating screenshots of websites on the backend is a pain⁵ because it usually involves either downloading a headless browser or a combination of DOM emulation and serialization libraries, neither of which screams maintainability.

However, on a closer look at rauchg's blog, I realized that it was using their Open Graph Image Generation edge function, which in turn uses Satori that has (limited) support for rendering DOM elements on the backend using wasm+JS. This worked like a charm⁶, with the only annoyance being that I had to duplicate some of my CSS as inline styles. I left a little TODO to figure out how to share these styles, perhaps via css-inliner.

Generating permalinks to headings

One thing I've comed to love from working at and using Quip is deep linking to documents (which lets you do so to any paragraph). It's a great way to share deeply embedded information in context and build out a knowledge graph. GitHub has a particularly nice approach about this where they automatically create anchor links for headings in the document, such as https://github.com/banga/git-split-diffs/tree/main#themes.

With the Jekyll setup, I was using some plugin that required manually writing out ids in curly brackets next to headings, like

# Smart Selection {#smart-selection}

to generate a permalink. I much prefer GitHub's approach. I looked at the plugins for react-markdown but didn't find anything that worked this way, so wrote something based on this suggestion in an issue thread:

react-markdown allows you to override rendering of specific HTML tags via the components prop. I wrote a component that would replace the default renderer for heading elements, had it parse the contents of the heading, generate an id from that and then insert a link next to the heading. With a touch of CSS to only show these links on hover, this was ready to use.

There is a gotcha with these links called DOM clobbering because these links use an id attribute, which automatically exposes said element to the window global. However, since I don't plan on hosting any external JS⁷ or sensitive content here, I'm giving it a pass.

Rendering math

My last post made heavy use of math using $\LaTeX$ notation, which I wanted to preserve. Thankfully, there are multiple unifiedjs plugins that can parse and render math in markdown. I initially picked remark-math and rehype-mathjax, which rendered correctly on the web.

Later, when I was generating a blog feed, I noticed that the tags used by MathJax were not rendering in feed readers. This took some delicate fixing, because feed readers don't seem to support evicting their caches. So I had to dust off my old The Old Reader and NewsBlur accounts. I replaced rehype-mathjax with rehype-katex, which uses MathML tags that finally have cross browser support in 2023⁸ and seem to render fine in feed aggregators.

Syntax highlighting code blocks

I shared a few code snippets before, which were highlighted by Jekyll by default using Pygments. I wanted to improve on that by rendering it in VS Code's dark theme, having written a tool to do the same on the terminal. I used react-syntax-highlighter, which delegates to Prism. It's not identical, but it ships with a theme called vsc-dark-plus that replicates VS Code's Dark+ theme. Loading this theme was a bit of a pain in my node ESM setup, partly because the types shipped with react-syntax-highlighter are wrong, but it worked fine after that.

Edit: I have since replaced react-syntax-highlighter with shikiji, which renders accurate VS Code themes.

Rendering footnotes

My last post really went all out on all the github extensions it could use, which included footnotes. Thankfully, these were easy to support, via the remark-gfm plugin. It actually pulls in a number of features from GitHub Flavored Markdown apart from footnotes, such as strikethroughs, tables and task lists. These will come in handy in the future.

Generating a blog feed

I use Feedly to follow other blogs and hopefully someone will want to follow mine some day. So I wanted to generate a feed for my posts as well. I sampled the feeds for a few blogs I read recently (v8, Keyhan's blog, Mihai's blog). Between RSS and Atom, I found the Atom format slightly easier to write. Other than the math rendering hiccup mentioned earlier, this worked easily.

Auto reloading

My last bit of indulgence in this project was to add auto reloading. My workflow so far had been to run the build script in watch mode via nodemon, serve the output using npx http-server ./_site and then hard refresh pages to see my changes.

This worked fine, but I have seen a few too many auto/hot reloading demos to be satisfied with it. A fast feedback loop during development and design makes iterative improvements that much easier. Reading a well formatted web page also beats reading markdown.

The usual approach for this works by having the client talk to a server (usually via a WebSocket), which watches the inputs and sends a message to the client when the relevant inputs change.

I didn't want to add the complexity of setting up my own server, so I took a different approach. My build script writes out a hash file at the end of the build containing the content hash of everything in the output directory. The client polls this file and reloads if the contents change. The only thing it relies on from the server is to not cache the contents of the static directory. This is achieved by passing the -c-1 flag to http-server.

I'm pretty pleased with the result as I type this and hit save.

Too long, didn't read?

That's ok. This is mostly for my own documentation when I look back and wonder how to get this thing working again. I also found and corrected a couple of issues in the process of writing this.

It also dawned on me as I wrote this down that even a dinky little website like this relies on an absurd amount of engineering and creativity by often thankless volunteers.

So, if you are one of those who share their work for free, thank you. The source for this repository is available at banga/banga.github.io

https://web.archive.org/web/20220203233535/https://banga.github.io/ ↩
https://web.archive.org/web/20230126105442/https://banga.github.io/blog/ ↩
I generally don't like markdown as a storage format or API surface, largely because it's not really a standard, but it works fine for an authorship of one. ↩
I don't know if there's an actual name for this style, is there? ↩
Many web apps do this in their export and print flows, because rendering to an image is often more reliable and easier to customize than client-side printing in browsers. ↩
Thank you vercel for open sourcing this and WASM for making it possible! ↩
In fact, no JS at all so far. ↩
See https://www.igalia.com/2023/01/10/Igalia-Brings-MathML-Back-to-Chromium.html. “This is the first example I know of that a major, major feature is really coming to the Web despite there not really being a business case for the business that normally advance the Web,” said Rick Byers of the Chrome team at Google. Many thanks to the volunteers! ↩

What's the smallest country that can fit everyone standing six feet apart?

2020-03-28T00:00:00.000Z

What's the smallest country that can fit everyone standing six feet apart?

Today's xkcd got me wondering how much land would we need if everyone stood six feet apart.

Methodology

We are all but spherical cows

If we want everyone to keep a minimum distance of $r$ from each other, the problem boils down to efficiently packing $n$ circles of radius $r$ in the smallest area possible. This can be calculated as follows:

Area of a circle with radius $r$ ,

$A_r = \pi r^2$

Optimal circle packing density¹,

$\eta = \frac{\pi\sqrt{3}}{6}$

Area required for $n$ people,

\begin{align} A_n & = n \cdot \frac{A_r}{\eta} \\ & = n \cdot \frac{\pi r^2}{\frac{\pi \sqrt{3}}{6}} \\ & = 2 \sqrt{3} \cdot n \cdot r^2 \end{align}

Crunching the numbers

Plugging in the current world population² and the recommended distance of 6 feet³:

$n = \text{7,773,861,168}$

$r = 6\text{ft}$

we get

\begin{align} A_n & = 9.695×10^{11} \text{ft}^2 \\ & = 34,775 \text{mi}^2 \\ \end{align}

And the answer is...

According to Wikipedia⁴, this is just shy of the land area of Portugal 🇵🇹. We could also squeeze into Hungary 🇭🇺 if some of us were willing to swim.

Corollaries

How many people can San Francisco fit standing 6 feet apart?

Dividing the area of San Francisco by $2 \sqrt{3} \cdot 36 \text{ft}^2$ , gives us around 10.5 million people.

Are there any countries where people couldn't stand 6 feet apart?

1 square mile of land can have 223,563 people standing 6 feet apart. This is much higher than the most densely populated countries and territories in the world⁵.

Syncing dev environments the hard way

2020-03-07T00:00:00.000Z

Syncing dev environments the hard way

If you use multiple machines for development, you probably run into the problem of keeping your dev environments in sync. For example, say your coworker introduced you to fzf and you installed it on your work machine. Wouldn't it be nice if it was also installed on your machine at home when you opened it?

Some of these changes only require sharing dotfiles (e.g. .bashrc or .zshrc) which is simple enough to do via something like Dropbox. However, I wanted to sync much more, like my zsh plugins, vscode extensions, Mac apps, fonts etc.

Luckily, I enjoy spending hours of programming to save minutes of future drudgery. The solution I landed on (inspired by mathiasbynens/dotfiles) is a Github repo with files that describe the environment and a script that makes sure the environment matches them.

The rest of this post describes my setup in detail, but if you just want the repo, check out banga/dotfiles-template. It's a cleaned-up version of my personal setup that you can just clone and customize.

How this works

Syncing happens via a shell script, .updatelaptop, which is invoked automatically every time you start a new shell. Once a day, it will pull any updates from the repo and trigger the update.py file which ensures that the environment matches the expected state.

The update.py script runs a number of checks and runs fixes for checks that fail. Here are the notable ones:

Dotfiles

This ensures that the dotfiles in my home directory are symlinked to the dotfiles checked into this repo. I keep my common shell settings in .shrc and machine-specific settings in .hyperlocal.shrc, which is gitignored.

Brew

The BrewBundle ensures that everything in the checked-in Brewfile is installed. This is the most powerful check for ensuring a consistent environment across machines. I can even use it to sync my favorite monospace font: JetBrains mono.

Zsh

The OhMyZsh and OhMyZshCustomPlugins checks ensure that Oh My Zsh and the plugins I use for it are installed. The plugins are included as submodules in this repo and symlinked to the zsh directory.

Git commit previews

This copies a custom CSS file I wrote to make git instaweb output look similar to Github. Along with this file, I have a shell command that allows me to preview my latest commit before pushing:

function gcpr() {
    pkill -9 lighttpd
    git instaweb start -l
    commit=$(git rev-parse ${1:-"HEAD"})
    # Assumes git instaweb is running on port 1234
    open "http://127.0.0.1:1234/?p=.git;a=commitdiff;ds=sidebyside;h=$commit"
}

VS Code

The VSCodeSyncing and VSCodeExtensions checks ensure that my vscode settings and extensions are synced across machines. I find this particularly useful because I often make small tweaks to vscode in one machine and end up needing them on another.

Dropbox

I still end up using Dropbox for syncing some settings which I change often enough for it to be too annoying to have to check-in into a repo and push. These include iTerm2 settings, Karabiner configurations, Alfred settings etc.

Little known features of iTerm2

2020-03-02T00:00:00.000Z

Little known features of iTerm2

iTerm2 has a lot of little-known features that can make development much easier.

Smart Selection

If you work in a large codebase, chances are you often need to open commits on Github, or revisions in Phabricator or tickets in your in-house bug tracker. This usually involves copying and pasting an identifier into a URL and opening that in your browser. For example, you may want to open commit hashes or PRs on Github with a single click. You can make iTerm2 recognize arbitrary ids and take custom actions using them when they are Command-clicked via Smart Selections.

Here are a couple of examples:

Open commits on Github

To make Command-clicking on a commit hash open it in Github, do the following:

Install hub
In your iTerm2 Preferences, go to Profiles -> Advanced -> Smart Selection -> Edit
Click the + button to add a new rule and set the Regular Expression to [0-9a-f]{7,40}
Click on Edit Actions... and add a new action
Set the Action to Run Command...
Set the Parameter to cd "\d" && /usr/local/bin/hub browse -- commit/\0. You may have to update the path to hub here if you installed it to a different directory.

Once this is done, Command-click on a commit hash in iTerm2 should open it in its respective repository if it exists on Github. You can customize this technique to open PRs and Issues on Github as well.

Open revisions in Phabricator

In your iTerm2 Preferences, go to Profiles -> Advanced -> Smart Selection -> Edit
Click the + button to add a new rule and set the Regular Expression to D[:number:]{5}
Click on Edit Actions... and add a new action
Set the Action to Open URL...
Set the Parameter to https://secure.phabricator.com/\0 or a similar URL for your organization.

Dynamic Profiles

If you work on a project that requires starting a number of terminal sessions in specific conditions, it can get annoying to get your environment running from scratch. iTerm2's Dynamic Profiles allow you to create custom profiles that can depend on other profiles. You can use this to create a hierarchy of profiles that share your common settings but run different commands on startup.

For example, say your project always needs you to be running npm run build, npm run server and npm run worker during development. You can use dynamic profiles to start iTerm2 with all of these commands running as follows:

Generate four GUIDs by running uuidgen in your terminal four times and copying the results.
Create a file in ~/Library/Application Support/iTerm2/DynamicProfiles with these contents (fill in the parts in <...>):

{
  "Profiles": [
    {
      "Name": "Development",
      "Guid": "<guid1>",
      "Dynamic Profile Parent Name": "Default",
      "Working Directory": "<path-to-your-project>",
      "Custom Directory": "Yes"
    },
    {
      "Name": "Build",
      "Guid": "<guid2>",
      "Dynamic Profile Parent Name": "Development",
      "Initial Text": "npm run build"
    },
    {
      "Name": "Server",
      "Guid": "<guid3>",
      "Dynamic Profile Parent Name": "Development",
      "Initial Text": "npm run server"
    },
    {
      "Name": "Worker",
      "Guid": "<guid4>",
      "Dynamic Profile Parent Name": "Development",
      "Initial Text": "npm run worker"
    }
  ]
}

Reload iTerm2

These profiles should now show up in iTerm2 as dynamic profiles. You can then start sessions with these profiles to create a window arrangement and hit Command-Shift-S to save it. Then you can start all of these sessions at any time by just pressing Command-Shift-R or tell iTerm2 to open the arrangement when it starts! Check out https://blog.andrewray.me/how-to-create-custom-iterm2-window-arrangments/ for a detailed guide on window arrangements.

Shrey Banga's blog

Learning Rust in 3 attempts

Learning Rust in 3 attempts

Attempt 1: RTFM

Attempt 2: A hobby project

It looks like you are trying to write a program

Attempt 3: Read a book

Footnotes

The rocket equation for startups

The rocket equation for startups

The tyranny of the equation

How to leave the gravity well

Back on planet earth

Footnotes

I spent way too long building this blog

I spent way too long building this blog

Hiding from Dr. Jekyll

Making a list, checking it twice

First, we prototype...

...then draw rest of the owl

Deploying to GitHub Pages

Generating preview images for OpenGraph

Generating permalinks to headings

Rendering math

Syntax highlighting code blocks

Rendering footnotes

Generating a blog feed

Auto reloading

Too long, didn't read?

Footnotes

What's the smallest country that can fit everyone standing six feet apart?

What's the smallest country that can fit everyone standing six feet apart?

Methodology

We are all but spherical cows

Crunching the numbers

And the answer is...

Corollaries

How many people can San Francisco fit standing 6 feet apart?

Are there any countries where people couldn't stand 6 feet apart?

Footnotes

Syncing dev environments the hard way

Syncing dev environments the hard way

How this works

Dotfiles

Brew

Zsh

Git commit previews

VS Code

Dropbox

Little known features of iTerm2

Little known features of iTerm2

Smart Selection

Open commits on Github

Open revisions in Phabricator

Dynamic Profiles