I previously wrote about how I use asdf and dirvenv together to setup per-project postgres versions. I recently learned about asdf-direnv, a direnv plugin for asdf.

asdf works by creating shims of every executable. This adds some overhead. The plugin works by leveraging direnv to change the PATH to the actual executable, instead of the shim.

Results

I use asdf to install most versions that I want to control precisely for my projects. Usually, this means the ruby and postgres version. Let’s time the performance without using asdf-direnv:

$ which ruby
/Users/ylansegal/.asdf/shims/ruby

$ time ruby -e "puts 'hello'"
hello
ruby -e "puts 'hello'"  0.04s user 0.02s system 38% cpu 0.155 total


$ which psql
/Users/ylansegal/.asdf/shims/psql

$ time psql -c 'select now()'
              now
-------------------------------
 2022-11-28 17:01:07.470615-08
(1 row)

Time: 0.142 ms
psql -c 'select now()'  0.01s user 0.01s system 12% cpu 0.129 total

Installing asdf-direnv is straight forward, as listed in the documentation. Once enabled in my .envrc file:

$ cat .envrc
use asdf
watch_file ".ruby-version"

We can see the performance gains:

$ which ruby
/Users/ylansegal/.asdf/installs/ruby/3.0.4/bin/ruby

$ time ruby -e "puts 'hello'"
hello
ruby -e "puts 'hello'"  0.04s user 0.02s system 93% cpu 0.065 total

$ which psql
/Users/ylansegal/.asdf/installs/postgres/13.5/bin/psql

$ time psql -c 'select now()'
              now
-------------------------------
 2022-11-28 17:01:42.357192-08
(1 row)

Time: 0.195 ms
psql -c 'select now()'  0.00s user 0.00s system 56% cpu 0.012 total

In both cases, the savings are ~90 ms. It’s commonly said that anything below 200 ms is acceptable UX as “immediate”. To me, my terminal feels much snappier.

I’ve been using this setup for a few weeks. The only issue I’ve encountered was that the plugin seems to fail to pickup the occasional changes in .ruby-toolbox even though the documentation states that watch_file in the documentation should fix that. I’ve been able to work around that by with touch .envrc, which forces the PATH to be re-calculated.

Rebase dependent branches

Taylor Blau at the GitHub blog points highlights a new feature git (v2.38) that I am super excited about. You can now git rebase --update-refs. Since reading that, I’ve already saved a lot of time (and minimized mistakes) when working on a set of branches that build on each other.

Partitioning in Postgres, 2022 edition

Brandur highlights that Postgres has made great usability improvements to partitioning over the last few years. It is now relatively easy to take advantage of it.

Add Data class implementation: Simple immutable value object

An new immutable value object, Data, has been merged into Ruby for release soon. It’s stricter than a Struct, which in many cases is exactly what you need from a value object.

git recently shipped some performance improvements when working with large repositories, as announced on the GitHub blog.

I tested in a large repository. With default configuration:

$ time git status
On branch master
Your branch is behind 'origin/master' by 686 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean
git status  0.40s user 8.55s system 429% cpu 2.082 total

We then configure fsmonitor and untrackedcache:

$ git config core.fsmonitor true
$ git config core.untrackedcache true

And run twice, to warm up the cache:

$ time git status
On branch master
Your branch is behind 'origin/master' by 686 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean
git status  0.38s user 1.43s system 159% cpu 1.141 total

$ time git status
On branch master
Your branch is behind 'origin/master' by 686 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean
git status  0.13s user 0.03s system 92% cpu 0.178 total

The improvement is quite significant. The end performance is under 200 ms, generally considered to be perceived as instantaneous by users. I’m thrilled!

Signing Git Commits with Your SSH Key

SSH keys are more common than GPG keys, by far. I don’t know many developers that have GPG keys, but all of them have SSH keys, if only to use GitHub. However, the support for the signatures seems a bit rough at the moment.

Transactionally Staged Job Drains in Postgres

The article explains well how background jobs that run outside of a db transaction can have several categories or problems. However, job queues driven by relational databases sometimes don’t scale well, when compared to other queues. For example see DelayedJob, or Que vs Sidekiq. The article presents a pattern that keeps the transactionality, but regains much of the performance by using a staging table for jobs, which drains into the actual job queue that will do the work.

Understanding GenStage back-pressure mechanism

Really concise explanation of what the concept of back-pressure means in Elixir, and how it can prevent overflow and the capacity of the system being exceeded.

Your Makefiles are wrong

make is a very powerful build tool, but it has sharp edges. In this post Jacob Davis-Hansson explains some best practices to improve the experience. The key insight is that each make target, by default, is suppose to generate a file, and execution is determined by laying out dependencies between files.

Why are you so busy?

as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.

Tom Lingham writes about being busy in software engineering teams. The quote above gets at the crux of the problem: You can only do so much. Asking for more, means that you need to work more or take shortcuts. Both of those lead to non-sustainable work. The appropriate response is to push back and have the tough conversations.