Ruby’s Bundler introduced a feature that I’m loving for prototypes and quick scripting

Inline Gemfiles

Introduced in v1.10, these avoid needing a separate declaration of a Gemfile and you write it directly into the script you’re creating.

It fixes the following ergonomic issues:

• Writing a separate Gemfile when your program is a single Ruby script is overkill
• Packaging your Gemfile to accompany aforementioned script is a hassle
• For single file scripts you can now rely on Gems!

How To Use It

require 'bundler/inline'

# Declare Gemfile in ruby script
gemfile do
  source 'https://rubygems.org'
  gem 'mongo'
  gem 'pry'
end

client = Mongo::Client.new(ENV.fetch('MONGO_URL'))

PS

I’m not writing much Ruby these days because I work leading engineers, but when I hack on things in my spare time I’m prototyping and want to iterate on an idea before converting it to Golang. I did this recently when iterating on how to speed up controlled MongoDB failovers and when spiking out a terraform-like system for MongoDB configuration management.

Bundler-inline is great for these situations because they’re a single Ruby script but require installing Gems :).

As an engineering leader, saying no is a superpower.

Counter: Saying yes and imagining what’s possible is a superpower.

Honorable mention: Avoiding becoming a gatekeeper or single point of failure is a superpower

TLDR: Build distributed and fault tolerant human systems. Reject what needs to be rejected and say yes to ambitious things you can’t yet conceive.

A good summary and collection of Rails security/anonymizing practices:

https://ankane.org/sensitive-data-rails

TLDR

When I build my own company, I’ll think back to working at a bootstrapped startup and the lessons I learned from our founder.

My business will embody these principles:

• Believe (obsessively and doggedly believe)
• Keep It Super Simple ^{1 2} (radical simplicity)
• Ship It (ship the bare minimum and get feedback, repeat)

Honorable mention:

• do things that don’t scale ³ (By the time you have scaling limits, you can pay to figure out scale.)

When I’m building features, finding customers, or planning technical architecture, I’ll think of her and say: WWMD.

My Startup Story

Small startups at a cesspool of ideas, experiences, stress, and joy and I learned a ton through my phases in smaller startups. Today, I want to highlight lessons learned from working at a small bootstrapped-ish startup. I’ve also been reading Ray Dalio’s book Principles ⁴.

The startup was ~50 people when I left and I was there for 3 years. I joined two years into their journey (~25 ppl total with 6 in engineer). Money was always tight and yet we were moving two digits of millions in revenue when I left.

Beyond learning from my time there, I learned from the 2 years before me… from the example set by out solo founder.

She had a year or two of professional experience in web development focused on design and frontend and had no business experience…. until she made her own experience! She became obsessed with a business problem encountered casually and from then on, lived, breathed, and fought for her business.

She built a truly minimum viable product… and was a shining example of what you can do with radical simplicity. Her busines started with a Google Form. She leveraged amazing productivity and value from off-the-shelf free tools. Turns out free tiers can be pushed REALLY FAR with the right urgency and necessity! If Airtable existed at the time, I think that would have been our database.

She learned what she needed to know about databases, servers, analytics but it was a means to an end of making the business work. She didn’t get lost in la-la land of falling in love with the tech. They were a tool she became proficient with but they didn’t rule her. Technology was a means to an end of building the business. My time with her honed my business approach to delivering the most value we could with available time and energy. We radically optimized for making the biggest bang for the buck, because there weren’t many bucks to go around.

What drew me to the company was her obsession, passion and success. Her fervor and obsession were infectious and I saw my own star rising with hers. I learned to see the world a more like she did, with less rules and boundaries. I bring that with me to my own engineering leadership and personal values in software engineering.

Recommended reading Blue Tape List

A Story of Ludicrous Speedups (3000 sec -> 5 sec)

During a work hackathon, our project involved using Docker for deployment and dependency management.

The dockerfile was inherited from an underlying open source project and was ok when used for deployments but very slow for local development work. Why, you might ask?

It used multi-stage builds, one for node, one for golang and then a final stage that collected the built artifacts from the prior stages. But the problem was…

Conflating package installation with project build

The Dockerfile failed to use a best practice of first copying over the package manifest. For Node these are package.json & yarn.lock. For Golang it’s go.mod and go.sum.

Instead of copying over these specific files up front, the Dockerfile copied the full project into the container then performing a build.

The problem

Since the local copied source code changed frequently during development, all later steps in the Dockerfile were invalidated and performed without caching :(. Downloading all golang dependencies and compiling from scratch was onerous.

The solution

Break apart the dependency installation phase from the local code phase. Package manifests should be copied in first, then yarn install will install Node dependencies. I had to get hacky to accomplish the same thing with Golang, but I’ll post my solution when I have a good moment.

Conceptually, the outcome was:

1. Build phase a1: Copy in package manifests for Node & yarn install
2. Build phase b: Copy in package manifests & fetch golang deps
3. Build phase a2 (built on a1): Build local code for js/ts
4. Build phase b2 (built on b1): Build local code for golang
5. Build phase c (independent of a or b) Selectively copy build artifacts from a2 and b2.

Outcome

Dev build time for docker image is now near instant (5 seconds) rather than 2900 seconds on a low power laptop.

Bonus

We also created a dedicated Dockerfile.dev that excluded js production build logic which was accounting for 300+ seconds of build time. Instead the js was built with a development script enabling hot module reloading.

Using yubikeys everywhere is my jam…here’s how.

Setup

I did it by installing yubikey-agent with a:

brew install yubikey-agent
brew services start yubikey-agent

Then shell configuration in ~/.zshrc:

export SSH_AUTH_SOCK="/usr/local/var/run/yubikey-agent.sock"

For each yubikey

• Create an 8 char password in password manager
• Run yubikey-agent -setup
  • Enter PIN/PUK
• Get the public key and verify it works with ssh-add -L
• Record public key in password manager and use the Yubico id to disambiguate which yubikey
• Add the public key to anywhere relevant, ie https://github.com/settings/keys

Credit/Links

• My workflow is a mixture of docs from https://github.com/FiloSottile/yubikey-agent and my own password manager setup.
• Another time when I want to tinker more, I’ll try out this set of instructions ssh and gpg from yubikey
• Superceded by 1st link: https://github.com/jamesog/yubikey-ssh

I’m trying out a new note taking system with the following goals:

• Easy to draft
• Searchable
• Similar syntax/shortcuts to other workflows (markdown)

It’s based on the concept of Zettelkasten and I’m stitching together my own system using:

• Neuron
• vscode-memo
• vscode-highlight: For coloring #tags and @-mentions
• ripgrep for searching (used from bash scripts)

• Transitioning a Startup from MongoDB to Postgres
• Engineering Leadership with Remote Teams
• Lessons as an Engineering Leader
• Emotional Labor of Management
• Productive Engineering and Management Culture
• The Value of Long Form Writing and Thinking Time
• Elixir Reflections: 2013 to Now
• My Development Environment
• Notetaking 2021
• Startup Horror Stories

My blog has been dormant, where have I been?

Busy! With my professional life and personal life. Big and good things on both fronts.

Since I last wrote:

• I led a 50 person startup in manufacturing as the CTO using Elixir and Typescript
• I led the development of a SaaS product as their Sr. Director of Engineering (Python, Elixir, Typescript, Graphql, and REST)
• I built and ran an open source app in production that streams mutations in MongoDB to Postgresql called Moresql
• We used Moresql to transition a company from MongoDB to Postgresql.
• I spent a lot of time with my cats
• I refined my bash coding style, evidence in my dotfiles
• I’ve lived in 3 distinctly different places and I’ve gotten to do some traveling
• I’ve been fully remote in remote and colocated companies since 2013

I haven’t written about my engineering leadership experiences because it’s hard to sufficiently abstract them in the moment in a way that I can publicly write about. I’ll see if that changes in the future because I want to be able to share learnings, since my professional growth is so very important to me.

I recently put up two pull requests for a commandline tool written in Rust called Tome. Tome is a rust binary tool that helps make a folder of scripts re-usable for one or more people so that it has good user ergonomics. My pull requests are https://github.com/toumorokoshi/tome/pull/4 and https://github.com/toumorokoshi/tome/pull/5.

With three days of Rust, my impressions are as follows:

• The compiler teaches me the language, through useful error messages
• Some types are obvious (Option/Result types) while others (String vs str and borrowed version) need me to investigate to understand
• Cross compiling isn’t as user friendly as golang but is working now that I took time to set it up
• All my favorite commandline tools are moving into Rust, perhaps I should too!

If you see me and want good conversation starters:

• Ask me about using Trello as a columnular data store
• About moving from MongoDB to Postgres (thanks JSONB)
• About what my best purchases were during covid

In 2021, I’m looking forward to:

• Learning and growing technically (Rust?)
• Getting good at a few things outside software engineering.
• Spending more time outdoors.
• Traveling to see friends.

It’s 2021, I’m happy and have challenges to work on :).