• The REPL: Issue 104 - April 2023

    Making A Network Call: Mitigate The Risk

    Nate Berkopec, well knows for his Ruby/Rails performance work, writes some good advice to mitigating the performance risk of making network calls: Make calls whenever possible in background jobs, set aggressive network timeouts, and use circuit breakers to fail fast when you detect a system is misbehaving.

    I’m not saying this is easy, I’m saying it’s necessary.

    Makefile Tutorial By Example

    make is tried and true technology. I don’t write Makefiles often. When I do, having a mental model of how make treats dependencies helps make the whole enterprise more efficient and enjoyable. This guide has plenty of material to get you started.

    Pure sh Bible

    Very ingenious collection of recipes for sh, that avoid using new processes. Some of the syntax is clever, but terrifying to read. Case in point:

    trim_string() {
        printf '%s\n' "$trim"

    Read on →

  • The REPL: Issue 103 - March 2023

    What Is ChatGPT Doing … and Why Does It Work?

    The Stephan Wolfram explains what ChaptGPT is doing. This article is very technical and on the long side. I found it quite enlightening to learn about what LLM are doing. A more accessible article article can be found, but I hate it’s name: “normie” is an objectionable term. It’s condecending, like you are not “in on something”.

    I wish people would stop insisting that Git branches are nothing but refs

    The article covers the friction of the mental model of using git vs the actual implementation. I’ve read a ton of complaints about git’s UX, the leaky abstraction, and all that. It’s true: Using git without knowing some of the plumbing is hard and doesn’t make much sense. In my experience, the more I’ve learned over the years from articles and especially from the Building Git Book, have made me much better at it, because I know understand the internals.

    In any case, the author seems correct to me: Saying that branches are just refs, is not helpful. A branch is a moving ref, which implies a series of commits. That is how most people think and talk about branches.

    Read on →

  • TIL: rails restart

    I first started writing Rails in 2010. Today I learned on the Ruby on Rails Blog that you can restart a running server in development with:

    $ bin/rails restart

    Up until today, I always quit my server (ctrl-c) and restarted when I wanted to pick a change that won’t be hot-reloaded (e.g. a change to an initializer). This works, but it is slower, especially when I am using foreman to start a fleet of processes (e.g. webpacker, background workers).

    Learning is a life-long process.

    Read on →

  • The REPL: Issue 102 - Februrary 2023

    That Wild Ask A Manager Story

    This article references a story that is new to me. In short, the person that went through the series of interviews is not the same person that shows up for work. Instead of over-reacting, Jacob Kaplan-Moss argues that we should do nothing:

    The premise here is simple: designing a human process around pathological cases leads to processes that are themselves pathological.

    Postgres DDL Statements and Availability

    This is a great reference of how each schema changing operation affects availability in Postgres.

    A career ending mistake

    John Arundel talks about career paths in software engineering:

    As software engineers, we’re constantly making detailed, elaborate plans for computers to execute. Isn’t it weird that we rarely give a moment’s thought to the program for our own careers?

    Read on →

  • Using bashly to create a CLI

    bashly is a command-line application that let’s you generate feature-rich command line tools. The idea is that you specify via a YAML file what subcommands, arguments, flags and environment variables you want for your executable, and bashly takes care of generating all the boilerplate on a bash script, so that you can focus on your code. Many languages support similar via libraries, like optparse in ruby.

    I recently used it to port a series of scripts for personal use that where all part of a series of commands I use to manage my personal note taking. I turned the all those separate scripts into a CLI with subcommands. Instead of zk_title and zk_today, I know have zk title and zk today, among others).

    Here are my observations:

    1. The documentation is well done. In particular the examples showed me how to do everything I needed.
    2. The ability to check for required environment variables was very useful. If only a particular command requires a certain environment variable, that can be configured too.
    3. Reading from stdin or from a file is a very common use case. It’s well supported.
    4. Commands can be aliased to shorter names.
    5. Flag handling is great. Short flags can be combined (i.e. zk title -ps instead of zk title -p -s)
    6. Each command lives in it’s own file. If needed, custom functions that are called from other commands are supported.
    7. Some of my previous commands were written in Ruby. bashly supports heredocs, which make it possible to continue using ruby for portions of your script, albeit this is a bit of a hack and makes the script less portable:
    /usr/bin/env ruby - ${arguments} <<-RUBY
    puts "hello #{ARGV}"

    Note that for heredocs to work, the following environment variable needs to be set BASHLY_TAB_INDENT=1.

    Overall, I was happy with the results. All the boilerplate code like creating global and command --help output, argument and environment variable checking, and flag handling was abstracted away.

    Read on →