Sebastian Rollen

Binding my time: a Heisenbug story

2026-02-17T00:00:00+00:00

I recently debugged a failing test where the issue itself was trivial, but the investigation of the bug was surprisingly gnarly because inspecting the bug using a debugger changed its behavior^{1</a>.}

What?</h2>

I've created a reproduction of the issue below, but the actual class and methods have been modified, so don't get hung up on the exact semantics of the class. The gist of it is that we have a Rails model with a method that checks some preconditions, returns early if the preconditions are met, and otherwise goes on to perform additional logic.

# == Schema Information
</span>#
</span># Table name: orders
</span>#
</span>#  id                   :bigint           not null, primary key
</span>#  canceled_at          :datetime
</span>#  delivered_at         :datetime
</span>class </span>Order </span>< </span>ApplicationRecord
</span>    </span>def </span>update_status
</span>      </span>return if</span> canceled_at.present? || delivered_at.present?
</span>    
</span>      </span># process rest of order, potentially setting the canceled_at or
</span>      </span># delivered_at field.
</span>    </span>end
</span>end
</span></code></pre>
The failing test indicated that the delivered_at</code> field was not being
updated when we expected that it should be, so I added a debugging
statement inside the method and reran the test.</p>
Nothing. The breakpoint didn't trigger and the test was still failing. I
moved the breakpoint to the very top of the method and started walking
through the code, but the method immediately returned from the
precondition check. Normal enough, but when I then reran the test again
to check which of the two preconditions failed, things got really</em>
weird.</p>
(ruby) canceled_at.present?
</span>false
</span>
</span>(ruby) delivered_at.present?
</span>false
</span></code></pre>
With some trepidation, I updated the code and ran again:</p>
def </span>update_status
</span>  should_return = canceled_at.present? || delivered_at.present?
</span>  debugger
</span>  </span>return if</span> should_return
</span>
</span>  </span># process rest of order
</span>end
</span></code></pre>
(ruby) canceled_at.present?
</span>false
</span>
</span>(ruby) delivered_at.present?
</span>false
</span>
</span>(ruby) should_return
</span>true
</span></code></pre>
Oh dear.</p>
The chasm opened up. I was staring into the abyss, and the abyss was
staring back at me. What had seemed like a simple investigation into a
failing test now had me questioning my sanity. How could 
(false || false) == true</code>? How do you even debug that?</p>
My mind was spinning.</p>
We must have done something silly and overridden
the ||</code> method somewhere in the code… But then how would anything work?
And indeed, ||</code> is not even a method that can be overridden, it's a
built-in operator.</p>
Okay, so there must be a ruby bug! But in the OR operator? C'mon… And in
any case, running false || false</code> or even canceled_at.present? || delivered_at.present?</code> returned false</code>, as expected.</p>
While flailing endlessly around for a logical explanation, I was also
instinctively poking around with the debugger, looking for a clue, and
while stepping deeper into the internals of Rails, I found one:</p>
[</span>34</span>, </span>43</span>] </span>in </span>~/</span>.rbenv</span>/versions/</span>3.3</span>.</span>6</span>/lib/ruby/gems/</span>3.3</span>.</span>0</span>/gems/activerecord-</span>8.1</span>.</span>2</span>/lib/active_record/attribute_methods/read.rb
</span>    </span>34</span>|       </span>end
</span>    </span>35</span>|
</span>    </span>36</span>|       </span># This method exists to avoid the expensive primary_key check internally, without
</span>    </span>37</span>|       </span># breaking compatibility with the read_attribute API
</span>    </span>38</span>|       </span>def </span>_read_attribute</span>(</span>attr_name</span>, &</span>block</span>) </span># :nodoc:
</span>=>  </span>39</span>|         @</span>attributes</span>.fetch_value(attr_name, &block)
</span>    </span>40</span>|       </span>end
</span>    </span>41</span>|
</span>    </span>42</span>|       </span>alias </span>:attribute :_read_attribute
</span>    </span>43</span>|       </span>private </span>:attribute
</span>=></span>#0    ActiveRecord::AttributeMethods::Read#_read_attribute(attr_name="delivered_at", block=#<Proc:0x0000000127bf13c8 /Users/rollen/....) at ~/.rbenv/versions/3.3.6/lib/ruby/gems/3.3.0/gems/activerecord-8.1.2/lib/active_record/attribute_methods/read.rb:39
</span>  </span>#1    Order::GeneratedAttributeMethods#delivered_at at ~/.rbenv/versions/3.3.6/lib/ruby/gems/3.3.0/gems/activemodel-8.1.2/lib/active_model/attribute_methods.rb:273
</span>  </span># and 33 frames (use `bt' command for all frames)
</span>(ruby) @</span>attributes</span>.fetch_value(attr_name, &block)
</span>2026</span>-</span>02</span>-</span>15 01</span>:</span>56</span>:</span>45.107254000 </span>UTC </span>+</span>00</span>:</span>00
</span></code></pre>
A-ha! So the delivered_at</code> field is not nil</code>, but actually has a set
date-time. This explains why should_return</code> is true</code>, but then why
would delivered_at.present?</code> return false</code>?</p>
Some more poking around in the debugger pointed to an answer:</p>
[</span>2</span>, </span>11</span>] </span>in </span>~/</span>src</span>/heisenbug/app/models/order.rb
</span>     </span>2</span>|
</span>     </span>3</span>| </span>class </span>Order </span>< </span>ApplicationRecord
</span>     </span>4</span>|   </span>def </span>update_status
</span>     </span>5</span>|     should_return = canceled_at.present? || delivered_at.present?
</span>     </span>6</span>|
</span>=>   </span>7</span>|     debugger
</span>     </span>8</span>|
</span>     </span>9</span>|     </span>return if</span> should_return
</span>    </span>10</span>|
</span>    </span>11</span>|     </span># do stuff
</span>=></span>#0    Order#update_status at ~/src/heisenbug/app/models/order.rb:7
</span>  </span>#1    <main> at (heisenbug):2
</span>  </span># and 31 frames (use `bt' command for all frames)
</span>(rdbg) info locals    </span># command
</span>%</span>self </span>= </span>#<Order id: 1, canceled_at: nil, delivered_at: "2026-02-15 01:56:45...>
</span>should_return = </span>true
</span>delivered_at = </span>nil
</span></code></pre>
So the delivered_at</code> column does indeed contain a value, but the local
variable</em> delivered_at</code> is nil</code>. Some more flailing</del> investigation
uncovered the culprit later in the method3</a></sup>:</p>
def </span>update_status
</span>    </span>return if</span> canceled_at.present? || delivered_at.present?
</span>    
</span>    </span># …
</span>    delivered_at = schema.delivered_at
</span>    </span>if</span> delivered_at < </span>5</span>.minutes_ago
</span>        </span># …
</span>    </span>end
</span>    update_columns(</span>delivered_at:</span> delivered_at)
</span>    </span># …
</span>end
</span></code></pre>
New theory: the local variable that we define later in the method must
somehow be hoisted up by the debugger to the interactive scope and
shadowing the method call even before the actual assignment to
delivered_at</code> had run. Testing the theory, I renamed the delivered_at</code>
local variable and re-ran the debugger:</p>
(ruby) delivered_at
</span>2026</span>-</span>02</span>-</span>15 01</span>:</span>56</span>:</span>45.107254000 </span>UTC </span>+</span>00</span>:</span>00
</span>(ruby) canceled_at.present? || delivered_at.present?
</span>true
</span>(ruby) should_return
</span>true
</span></code></pre>
Success! The code behaved exactly as intended, and I was now quickly
able to fix the behavior leading to the broken test. But, of course, the
story doesn't stop there; I desperately needed to know</p>
WHY??</h2>
Though confusing, it's important to note that the behavior I ran into
here is not a bug or even unintended behavior in the ruby debugger.
Indeed, though not explicitly called out, this behavior is exemplified
in the README of the debug repository</a>:</p>
$ cat target.rb                        </span># Sample program
</span>require </span>'</span>debug</span>'
</span>
</span>a = </span>1
</span>b = </span>2
</span>binding</span>.break                          </span># Program will stop here
</span>c = </span>3
</span>d = </span>4
</span>binding</span>.break                          </span># Program will stop here
</span>p </span>[a, b, c, d]
</span>
</span>$ ruby target.rb                       </span># Run the program normally.
</span>DEBUGGER: </span>Session</span> start (</span>pid: </span>7604</span>)
</span>[</span>1</span>, </span>10</span>] </span>in</span> target.rb
</span>      </span>1</span>| </span>require </span>'</span>debug</span>'
</span>      </span>2</span>|
</span>      </span>3</span>| a = </span>1
</span>      </span>4</span>| b = </span>2
</span>=>    </span>5</span>| </span>binding</span>.break                 </span># Now you can see it stops at this line
</span>      </span>6</span>| c = </span>3
</span>      </span>7</span>| d = </span>4
</span>      </span>8</span>| </span>binding</span>.break
</span>      </span>9</span>| </span>p </span>[a, b, c, d]
</span>     </span>10</span>|
</span>=></span>#0    <main> at target.rb:5
</span>
</span>(rdbg) info locals                     </span># You can show local variables
</span>=></span>#0    <main> at target.rb:5
</span>%</span>self </span>=> main
</span>a => </span>1
</span>b => </span>2
</span>c => </span>nil
</span>d => </span>nil
</span></code></pre>
Notice that even though the execution has stopped on line 5, c</code> and d</code>
are still initialized with value nil</code>. Dig deeper through the debugger
code, and you'll find that this behavior comes from
Kernel#binding</code></a>,
a method that extracts all local variables and other information from
the current scope into an instance of the Binding</code> class. Even more
powerfully, a Binding</code></a>
can be passed to eval</code> to evaluate arbitrary code within the context of
that binding:</p>
class </span>User
</span>  </span>def </span>initialize</span>(</span>name</span>, </span>position</span>)
</span>    @</span>name </span>= </span>name
</span>    @</span>position </span>= position
</span>  </span>end
</span>
</span>  </span>def </span>get_binding
</span>    </span>binding
</span>  </span>end
</span>end
</span>
</span>user = </span>User</span>.</span>new</span>('</span>Joan</span>', '</span>manager</span>')
</span>template = '</span>{name: @name, position: @position}</span>'
</span>
</span># evaluate template in context of the object
</span>eval</span>(template, user.get_binding)
</span>#=> {:name=>"Joan", :position=>"manager"}
</span></code></pre>
This is of course extremely powerful behavior for building a debugger.
You can even build a very simple debugger that lets users evaluate code
at any point in the program by sending the binding to
irb</code>4</a></sup>:</p>
require </span>'</span>irb</span>'
</span>
</span>def </span>custom_debugger</span>(</span>context</span>)
</span>    </span>IRB</span>.setup(</span>nil</span>)
</span>    workspace = </span>IRB</span>::</span>WorkSpace</span>.</span>new</span>(context)
</span>    irb = </span>IRB</span>::</span>Irb</span>.</span>new</span>(workspace)
</span>    </span>IRB</span>.conf[</span>:MAIN_CONTEXT</span>] = irb.context
</span>    </span>catch</span>(</span>:IRB_EXIT</span>) { irb.eval_input }
</span>end
</span>
</span>def </span>method_with_bug
</span>    </span>name </span>= "</span>My name</span>"
</span>    </span>raise </span>'</span>error!</span>'
</span>rescue
</span>    custom_debugger(</span>binding</span>)
</span>end
</span>
</span>method_with_bug
</span></code></pre>
Throw that code into debug.rb</code> and run it, and you'll be placed in an
irb session with the context from inside</em> the method_with_bug</code> method:</p>
❯ ruby debug.rb
</span>irb(main):</span>001</span>> </span>name
</span>=> "</span>My name</span>"
</span></code></pre>
This only moves the question one step deeper: why does binding</code> capture
local variables that haven't been defined yet?</p>
Unlike some other languages, ruby doesn't require local variables to be
initialized before they can be assigned. Ruby also doesn't require
parentheses to call methods, meaning that the identifier foo</code> can
either be a reference to a local variable or a method call. If the Ruby
runtime had to make that determination every time it encountered an
identifier, performance would be much slower, so Ruby instead creates
all local variables in a scope when parsed, not when assigned. The Ruby
documentation</a>
provides another example making this behavior clear:</p>
a = </span>0 </span>if </span>false </span># does not assign to a
</span>
</span>p local_variables </span># prints [:a]
</span>
</span>p</span> a </span># prints nil
</span></code></pre>
So there's the full story: the delivered_at</code> attribute was shadowed by
the delivered_at</code> local variable in our debugging scope, because
binding</code> (which is used by ruby/debug</code> to enable powerful debugging)
captures all local variables, even those that haven't been assigned yet.
This capture happens at parse time, not runtime, for performance
reasons.</p>
And the moral of the story is: don't shadow your variables, kids.</p>
[1] This class of bug is called a
Heisenbug</a>, after the
Heisenberg Uncertainty Principle2</a></sup>, in which observing a particular aspect
of a (quantum) system invariably alters its state. ↩︎</a></small></p>
[2] More accurately the Observer
Effect</a>, which
is often conflated with the Heisenberg principle. The latter states that
the product of the standard deviations of position and momentum has a
lower bound, so if you try to reduce your uncertainty of one of the two,
your uncertainty of the other will increase to compensate.</p>
This sounds (and is!) mysterious, but my favorite way of conceptualizing
it is to instead think of position/wave-length uncertainty, where the
behavior is much more clear. If you think of the first extreme, an
infinitely repeating periodic wave, it's very easy to calculate its
wavelength, but what is its position, if it extends to infinity? And at
the other extreme, if you think of squishing the wave down to a single
point, it's very easy to locate it in space, but what is its wavelength?</p>
And yes, this is a footnote to a footnote, and a physics digression in a
coding article, but it's my blog and I do what I want, damn it! Now
where was I? ↩︎</a></small></p>
[3] Sorry for burying the lede if you were reading this as an exercise and
trying to guess the answer! In my defense, while shadowing an attribute
with a local variable seemed perhaps slightly odious, I never expected
that it would lead to this level of confusion while debugging. ↩︎</a></small></p>
[4] Code taken from this great
video</a> by @CarlosPohloddev ↩︎</a></small></p>

Rendering markdown views in Rails 2023-01-30T00:00:00+00:00 Rails is a fantastic tool for building web applications, with a large set of conventions and "batteries-included" libraries guiding the development. One area where Rails does not have great support though is for hosting static Markdown pages along with the rest of the application. Luckily, it's easy to hook into Rails' rendering flow to build out the functionality ourselves. If you want to try this at home, here's a GitHub link</a> to a demo application that follows the blog post below. Each commit corresponds to a section in the post. Why?</h2> There's many great ways to create and host static pages. This page is generated using zola</a>, and hosted from an S3 bucket, with AWS cloudfront in front as a CDN. This setup is extremely easy to manage, and cheap. Costs are usually below $2 / month, and deployment is as simple as pushing to a git repo that synchronizes with the S3 bucket through a simple GitHub action</a>. Even so, I recently found myself wanting to host some static pages in my Rails application. For my startup, RoQR, I wanted to move my documentation from the docs.roqr.app</code> subdomain to the roqr.app</code> domain1</a>. I host my Rails app at the latter, and though I might do some routing magic to forward from one domain to the other, I would much prefer deploying the full stack as a monolith, documentation included. Another reason to host your static pages along with your Rails application is so that you can simplify sharing state between the two. For example, I would like to have a button on my documentation pages that links to a login page if the user is not signed in, but to the web app if the user is signed in. That's much easier to do if Rails handles both the static pages and the app. What I did not want to do is have to code my static pages using HTML, and so I set out to build out a solution to render my static pages from markdown files, using Rails. Here's how you can do the same. Minimum viable markdown renderer</h2> Let's start by getting a simple markdown file rendered and displayed in Rails. If you want to follow along, generate a new Rails2</a> project: rails new rails-markdown-example --css=tailwind cd rails-markdown-example </code></pre> To render markdown files, we're going to need a gem to convert the markdown into HTML. You have a few choices here, but I'm going to go with redcarpet</a>. bundle add redcarpet </code></pre> Now for the magic part: we hook into Rails' template handler system to register a handler for markdown files, and process those files with redcarpet: # config/initializers/markdown.rb # We define a module that can parse markdown to HTML with its `call` method module MarkdownHandler def self.erb @erb ||= ActionView::Template.registered_template_handler(:erb) end def self.call(template, source) compiled_source = erb.call(template, source) "Redcarpet::Markdown.new(Redcarpet::Render::HTML.new).render(begin;#{compiled_source};end).html_safe" end end # Now we tell Rails to process any files with the `.md` extension using our new MarkdownHandler ActionView::Template.register_template_handler :md, MarkdownHandler </code></pre> We'll test it out by defining a simple controller and route: # config/routes.rb Rails.application.routes.draw do root 'pages#index' end </code></pre> # app/controllers/pages_controller.rb class PagesController < ApplicationController def index; end end </code></pre> Finally, let's create our markdown file to render. Note that the extension is .html.md</code>, not the usual .html.erb</code>:  # Test - This - is - a - list </code></pre> Start your rails server using ./bin/dev</code>3</a>, and navigate to localhost:3000</code>. Success! The markdown file is rendered in our browser: Markdown file being rendered</figcaption> </figure> It doesn't look very good though. This is because we're using tailwind</a> to style our page, but we haven't defined any styles yet. Tailwind resets all styles using its preflight</a> plugin by default, so our page is looking very plain. We could define custom styles for our page, but tailwind also comes with a typography</a> plugin with a set of prose</code> classes that define good looking typographic defaults. Let's format our markdown using that plugin: # app/views/layouts/application.html.erb ... <main class="container mx-auto mt-28 px-5 flex"> - <%= yield %> + <article class="prose"> + <%= yield %> + </article> </main> ... </code></pre> Nicer formatting using `prose`</figcaption> </figure> That's much nicer. Explore the code at this point</a> Using HighVoltage for routing</h2> In the previous section, we defined the PagesController and an index route to register our markdown file at the root path. However, if we're planning on adding a lot of static files, we would quickly get overwhelmed by the amount of routes and controller actions we'd have to create. Fortunately, there's another gem we can use that is designed to solve this specific issue: high_voltage</a>. Lets refactor our app to use it: bundle add high_voltage rm app/controllers/pages_controller.rb </code></pre> # config/initializers/high_voltage.rb HighVoltage.configure do |config| config.home_page = 'index' end </code></pre> # config/routes.rb Rails.application.routes.draw do - root 'pages#index end </code></pre> Let's restart out Rails server and verify that everything still works by navigating to localhost:3000</code> again. It works. Now, lets create one more markdown route to see how high_voltage deals with multiple files.  # New blog post <small>Author: Seb</small> This is some blog text </code></pre> Let's also link to the blog post from our home page: # app/views/pages/index.html.md ... + ## Blog + [Blog post](<%= page_path('blog/new_post') %>) </code></pre> Index</figcaption> </figure> Blog post</figcaption> </figure> Explore the code at this point</a> Customize the route</h2> Our page is looking nice, but I'm not a big fan of the generated path for our blog-post: pages/blog/new_post</code>. There's two issues with it: The content is hosted under /pages</code>, but for this example, I would rather it be under /docs</code></li> The underscores in new_post</code> are a bit of an eye-sore for a URL. new-post</code> would be much nicer.</li> </ol> Let's tackle #1 first. We'll disable high_voltage's automatic routing and replace it with our own. # config/initializers/high_voltage.rb HighVoltage.configure do |config| config.home_page = 'index' + config.routes = false end </code></pre> # config/routes.rb Rails.application.routes.draw do + get '/docs/*id' => 'pages#show', :as => :page, format => false end </code></pre> Easy as that. To tackle #2, we're going to have to bring back PagesController: # app/controllers/pages_controller.rb class PagesController < ApplicationController include HighVoltage::StaticPage private def page_finder_factory PageFinder end end </code></pre> Instead of relying on high_voltage's default page finder, we're going to provide our own: # app/models/page_finder.rb class PageFinder < HighVoltage::PageFinder def find paths = super.split('/') directory = paths[0..-2] filename = paths[-1].tr('-', '_') File.join(*directory, filename) end end </code></pre> This finder just takes the path and replaces any underscores with hyphens in the final URL segment. Now both issues are fixed! Explore the code at this point</a> Change layout based on the URL path</h2> Our URL is looking good, but how about our blog page? What if we want the blog page to have a different layout from the rest of the pages? We can define a custom layout in the pages controller based on our path: # app/controllers/pages_controller.rb class PagesController < ApplicationController include HighVoltage::StaticPage + layout :layout_for_page private + def resource + params[:id].split('/').first + end + + def layout_for_page + case resource + when 'blog' + 'pages/blog_post' + else + 'application' + end + end ... </code></pre> In words, any page under the path /docs/blog/</code> is going to be rendered using the pages/blog_post</code> layout, and all other pages will use that standard application</code> layout. Let's define our new layout. Specifically, I want this layout to render the page in dark-mode:  <!DOCTYPE html> <html> <head> <title>RailsMarkdownExample</title> <meta name="viewport" content="width=device-width,initial-scale=1"> <%= csrf_meta_tags %> <%= csp_meta_tag %> <%= stylesheet_link_tag "tailwind", "inter-font", "data-turbo-track": "reload" %> <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %> <%= javascript_importmap_tags %> </head> <body class="bg-gray-900"> <main class="container mx-auto mt-28 px-5 flex"> <article class="prose prose-invert"> <%= yield %> </article> </main> </body> </html> </code></pre> A few things to note here: I styled the whole page with a dark background using class="bg-gray-900"</code></li> I inverted all the text colors by adding prose-invert</code> to my <article></code> classes.</li> </ul> It looks like this: Dark mode</figcaption> </figure> Explore the code at this point</a> Parsing and rendering front-matter.</h2> Many markdown converters use front-matter</a> to embed certain metadata in the document. For example, instead of beginning all our blog posts with # Blog post title</code>, we might choose to instead encode that using front-matter. Lets refactor our blog post to use YAML4</a> front-matter, and add a published date as an additional point of metadata.  - # New blog post - - Author: Seb + --- + title: New blog post + author: Seb + date: 2023-01-30 + --- ... </code></pre> We'll add one more gem to help us separate the front-matter from the rest of the markdown content: bundle add ruby_matter </code></pre> We have to update our markdown renderer to ignore the front-matter in its normal course of rendering: # config/initializers/markdown.rb ... def self.call(template, source) - compiled_source = erb.call(template, source) + parser = RubyMatter.parse(source) + compiled_source = erb.call(template, parser.content) "Redcarpet::Markdown.new(Redcarpet::Render::HTML.new).render(begin;#{compiled_source};end).html_safe" end ... </code></pre> To extract the front-matter into a usable format, let's update our controller to parse the front-matter into an instance variable: # app/controllers/pages_controller.rb ... layout :layout_for_page + before_action :extract_frontmatter ... private + def extract_frontmatter + @frontmatter = RubyMatter.parse(file_contents).data + end + + def file_contents + File.read(File.join('app', 'views', "#{file}.html.md")) + end + + def file + page_finder_factory.new(params[:id]).find + end ... </code></pre> This almost work, but we run into an issue</a> where the underlying library used for YAML parsing disallows values of Date</code> and Time</code> by default. We can fix this by providing our own lambda for parsing YAML files, where we explicitly allow these classes: # app/controllers/pages_controller.rb ... layout :layout_for_page before_action :extract_frontmatter + ENGINES = { + yaml: { + parse: ->(yaml) { Psych.safe_load(yaml, permitted_classes: [Date, Time]) }, + stringify: ->(hash) { Psych.dump(hash).sub(/^---(\n|\s)?/, '') } + } + }.freeze ... def extract_front_matter - @frontmatter = RubyMatter.parse(file_contents).data + @frontmatter = RubyMatter.parse(file_contents, engines: ENGINES).data end ... </code></pre> Now it works. As a final step, let's render our extracted data in our layout:  ... <article class="prose prose-invert"> + <h1><%= @frontmatter['title' %></h1> + + Posted by <%= @frontmatter['author'] %> on <%= @frontmatter['date'] %> + ... </code></pre> Blog post rendered with front-matter</figcaption> </figure> Excellent Explore the code at this point</a> Conclusion</h2> So that does it: a bona-fide markdown-to-html workflow including front-matter in Rails. Do you have any suggested improvements to this approach? Let me know! [1] I'm no longer working on RoQR, and the domain is now owned by another party. ↩︎</a> [2] I'm using Rails version 7.0.4.2. You might run into some issues following this post if your version is significantly different. ↩︎</a> [3] We're using ./bin/dev</code> rather than the normal rails s</code> as we're running more than one process here using foreman</a>: the web server and a process for redefining our CSS using Tailwind. You can learn more about how that works here</a> ↩︎</a> [4] Sorry, Norway!</a> ↩︎</a> In time 2023-01-14T00:00:00+00:00 As you are, we once were. As we are, you will be. Dust —yes— but so much more: The breath you held, though you wanted to speak— confess—scream—profess— why didn't you? is with us now. From your lips: a gift, permeating to trees, who never once knew your kindness, in time. The blood that trickled through your veins, but rarely ran red, is with us now. Percolating, then coarsing, roaring like it never did in you through rivers and streams hidden from the sun. It evaporates, and falls gently, now, over lands, you only might have seen in time. Your sinews and muscles that atrophied when you forgot that you were living, too, are with us now. Not as carrion, torn by raptors (nothing so romantic) but churning softly, through soil and silt into dust —yes— in time. We have plans for every part of you, the purpose that eluded you, when you step out of time. </blockquote> Some useful git one-liners 2023-01-13T00:00:00+00:00 I have a few useful git one-liners that I reach for relatively often. I don't have them written down anywhere, but just search for them in my shell history (using the wonderful McFly</a>) whenever I need them. Until now! List the number of commits to a repo by day</h2> ❯ git log --date=short --pretty=format:%ad | sort | uniq -c 8 2023-01-07 2 2023-01-09 1 2023-01-10 2 2023-01-12 4 2023-01-13 </code></pre> Create a sparkline chart of the commit history</h2> Bonus! Requires spark</a> ❯ git log --date=short --pretty=format:%ad | sort | uniq -c | awk '{print $1}' | spark ▁▄▃▁▁▆█▁▂▁▇▁▁▂▃▁▁▁█▂▁▂▄ </code></pre> List the number of commits to a repo by day, sorted by commits</h2> ❯ git log --date=short --pretty=format:%ad | sort | uniq -c | sort -r | head 8 2023-01-07 8 2021-10-19 7 2022-04-23 6 2021-10-18 4 2023-01-13 </code></pre> Delete merged branches in a repo that squashes commits</h2> If you work a lot in a repo that uses squashes merge commits to main, you might have found that your local git branch</code> listing quickly builds up, and answers like this one</a> don't actually work. Try this instead: ❯ git fetch -p ; git branch -r | awk '{print $1}' | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk '{print $1}' | xargs git branch -D From github.com:SebRollen/test-repo - [deleted] (none) -> origin/test-branch Deleted branch test-branch (was f865934). </code></pre> Let me know if you have any other good git tricks! The paragraph I went vegan 2023-01-09T00:00:00+00:00 The question that I usually get asked the most about going vegan along with "What food do you miss the most?" (cheese!) and "Is is it hard?" (yes) is "What made you decide to go vegan?" It's a question I have struggled to find a pithy answer to, but it is a fair question, and of a similar ilk as questions I am sure I have asked to others with different habits than mine. My usual response is that it was a book that put me over the edge, specifically Eating Animals</a> by Jonathan Safran Foer. I describe to them that contrary to whatever the title might make you think, it's not a book that shames you for eating animals, but rather a nuanced and rather lamentful consideration of the costs of not eating animals. The title is a double-entendre of the fact that we're also eating-animals: animals who build traditions and bonds around our food. Friendships and kinships are in large part forged at the dinner table, and it's almost hard to imagine being close to someone with whom you have not yet shared a meal. I tell them that Safran Foer is known as a fiction author, and that Eating Animals is not just a persuasive book - it's also beautiful narrative of the human condition. All of this is true. But it's also not a complete and honest answer, because I know exactly at what point in the book I realized that I could not go back to eating animal products again, the exact paragraph. And though Eating Animals as a whole is nuanced, the paragraph in question is about as graphic of an account of a slaughterhouse as you could imagine. And though the book in general does not try to shame people out of eating meat, it's hard to not feel shameful after reading it. Like one of Safran Foer's fiction books, the account is extremely loud and incredibly close. This might of course be the intended effect, a book full of feints and jabs with a concealed upper-punch. It certainly put me down for the count. The paragraph in question is in fact a quote from another book: Slaughterhouse</a> by Gail A. Eisnitz. Eisnitz spent years investigating the conditions in America's slaughterhouses and interviewing the people who worked in them. The conditions she found were horrific and it's in an interview with a worker in a slaughterhouse for pigs that we find the paragraph in Eating Animals: Down in the blood pit they say that the smell of blood makes you aggressive. And it does. You get an attitude that if that hog kicks at me, I’m going to get even. You’re already going to kill the hog, but that’s not enough. It has to suffer.... You go in hard, push hard, blow the windpipe, make it drown in its own blood. Split its nose. A live hog would be running around the pit. It would just be looking up at me and I’d be sticking, and I would just take my knife and — eerk — cut its eye out while it was just sitting there. And this hog would just scream. One time I took my knife — it’s sharp enough — and I sliced off the end of a hog’s nose, just like a piece of bologna. The hog went crazy for a few seconds. Then it just sat there looking kind of stupid. So I took a handful of salt brine and ground it into his nose. Now that hog really went nuts, pushing its nose all over the place. I still had a bunch of salt left on my hand — I was wearing a rubber glove — and I stuck the salt right up the hog’s ass. The poor hog didn't know whether to shit or go blind.... I wasn't the only guy doing this kind of stuff. One guy I work with actually chases hogs into the scalding tank. And everybody — hog drivers, shacklers, utility men — uses lead pipes on hogs. Everybody knows it, all of it. </blockquote> The acts of the slaughterhouse worker above are undoubtedly wicked and inhumanely cruel, and yet they're not as uncommon as we'd hope. One survey of slaughter plant employees at 25 U.S. and Canadian facilities between 1975 and 1987 found that employees at 32% of the plants displayed "[a]cts of deliberate cruelty on a regular basis", with a further 12% demonstrating "[r]ough handling occurring as a routine practice". And these were during announced audits - it's hard not to imagine conditions being worse at times when the plant was not being audited. So much held in a heart in a lifetime. So much held in a heart in a day, an hour, a moment. We are utterly open with no one in the end—not mother and father, not wife or husband, not lover, not child, not friend. We open windows to each but we live alone in the house of the heart. Perhaps we must. Perhaps we could not bear to be so naked, for fear of a constantly harrowed heart. When young we think there will come one person who will savor and sustain us always; when we are older we know this is the dream of a child, that all hearts finally are bruised and scarred, scored and torn, repaired by time and will, patched by force of character, yet fragile and rickety forevermore, no matter how ferocious the defense and how many bricks you bring to the wall. You can brick up your heart as stout and tight and hard and cold and impregnable as you possibly can and down it comes in an instant, felled by a woman’s second glance, a child’s apple breath, the shatter of glass in the road, the words I have something to tell you, a cat with a broken spine dragging itself into the forest to die, the brush of your mother’s papery ancient hand in the thicket of your hair, the memory of your father’s voice early in the morning echoing from the kitchen where he is making pancakes for his children. </blockquote> Joyas Voladoras</a>, Bryan Doyle As children, I think we understand that animals are special, that they are living beings sharing this beautiful world with us. Most children would be horrified if you pointed out that the meat they were eating came from an animal. They'd know that it's wrong to keep a cow continously pregnant, to separate them from their calves right after birth just so that we can have milk. As we grow older, we build up defences and justifications about which animals we can eat, and what types of lives they should live before we slaughter them. And sometimes, the brick wall comes down in an instance with no hopes of ever rebuilding. For me the wall came down from a paragraph about a hog just sitting there, looking kind of stupid. Crypto arguments from the head, the heart and the hands 2022-06-07T00:00:00+00:00 My previous post</a> on the climate-impact on cryptocurrencies garnered some attention on reddit</a> and Hacker News</a>, and I had originally planned a follow-up to address some of the criticisms I received in those comments. I never finalized the article1</a>, but it has been sitting in my drafts long enough now that I decided to post the outline of it anyway2</a>. The title and structure of this post is a reference to the idea laid out in Buster Benson's book Why Are We Yelling</a>, that most arguments can be categorized in three categories: those of the head, heart and hands. In order, those arguments boil down to disagreements about the truth, the meaning, and the usefulness of the argument. Arguments of the Head (Truth)</h2> The correct calculation yields ~2,000 kWh per block, not transaction</a></h3> I addressed one of these comments directly</a> in the HackerNews thread, but for completeness, here's how you can verify yourself that this argument is false. We start by looking at the total energy consumption of the Bitcoin network as a whole. As of the time of writing, that figure is 200 TWh per year</a>. 200 terawatt-hours is the same as 200,000,000,000 (200 billion) kWh. Next, we find the number of Bitcoin blocks mined each day. Since the Bitcoin network is designed to yield a block at a rate of about one block every 10 minutes, we expect this value to be around (1 block / 10 minutes) * (60 minutes / hour) * (24 hours / day) * (365 days / year) = 52,560 blocks / year. Empirically, we can also see that the number of blocks mined daily tends to track very closely</a> to the theoretical average. Dividing our two figures, we find that (200,000,000,000 kWh / year) / (52,560 blocks / year) ≈ 3,800,000 kWh / block, which is about 1,900 times larger than the figure I quoted for the effective kWh per transaction. To bring the calculation all the way home, we can calculate the kWh per transaction by dividing our kWh per block figure by the number of transactions per block. There is no theoretical average for the number of transactions in a block since a block is limited by memory (1 MB) rather than number of transactions, but we can see empirically that the number of transactions per block tends to hover around 1,900</a>. (3,800,000 kWh / block) / (1,900 transactions / block) = 2,000 kWh / transaction, which is very close to the figure I used in the original post. Bitcoin uses mostly renewable energy</a></h3> According to Digiconomist, about 25.1% of the energy used to mine Bitcoin comes from sustainable sources</a>. This is the lowest percentage for multiple years, partially due to many miners having to move their operation from China to other countries after China cracked down on cryptocurrencies in 2021</a>. 25% may still seem like a large number, given that many sources for sources of global energy seem to indicate that the global average share of sustainable energy is much lower. However, most of those statistic include energy usage for applications that are not powered by an electric grid such as shipping and airlines. A more applicable comparison is to look at what percentage of energy consumed through the electrical grid comes from renewable sources. Globally, that percentage is 26.4%</a>3</a>. Bitcoin uses less energy than ATMs</a></h3> This one we can also address with some quick maths. An standard ATM draws between 60W</a> and 145W</a>. Let's go with the larger number to be conservative: that then gives us an energy usage of 145Wh per hour per ATM. Yearly, that is (145Wh / hour) * (24 hours / day) * (365 days / year) = 1,270,200 Wh / year, or 1,270 kWh / year4</a>. There's about 3.2 million ATMs</a> in the world, so assuming that those machines are running 24/7, that gives us a total energy usage of 1,270 kWh / (ATM * year) * 3.2m ATMs = 4,060,000,000 kWh / year, or about 4 TWh / year. So in our worst-case scenario, ATMs use about 50 times less energy than Bitcoin yearly. Bitcoin uses less energy that Christmas lights</a></h3> This would indeed be quite alarming if it was true. The comment I link to provided a source from oral testimony</a> in front of the U.S. House of Representatives Financial Services committee, which may give the statistic the veneer of being authoritative. However, it's important to remember that a wide range of people get asked to give testimony in front of Congress for an equally wide variety of reasons. In this case, the speaker was Brian Brooks, CEO of the crypto company Bitfury, who claimed in his testimony that "bitcoin’s total global energy usage of about 188 terawatts is somewhat less than the total annual energy usage of Christmas lights (around 201 terawatts)". There's no source for his claim that Christmas lights use around 201 TWh (which is what I assume he means by terawatts) per year, but I was able to find an estimate of the energy usage of various forms of lighting</a> in the United States from the Department of Energy. In this report, the DoE reports that as of 2007, around 6.63 TWh worth of energy is used to power "Decorative Holiday Lights" each year. They also helpfully note that at that time, around 5.2% of those lights were LEDs, which are much more energy efficient than traditional holiday lights. It is very likely that the proportion of LED Christmas lights is much higher now than it was in 2007 given that LED usage as a whole has gone from virtually 0% to around 50% of the market</a>. This means that the total energy use from Christmas lights has likely gone down in the past 15 years, but for a worst-case analysis let's assume that the energy use from Christmas lights remains the same in the U.S. Let's also assume that the U.S. is a representative country for estimating the amount of energy used per capita on Christmas lights (another assumption that will most likely overestimate the consumption as many other countries use little to no Christmas lights). The U.S. has around 334m people, and the world population is around 7,952m, so in our worst-case analysis, we arrive at the figure of 6.63 * 7,952 / 334 = 158 TWh / year. A more conservative estimate where the U.S. uses twice as many decorative lights per capita as the average country and where market penetration for LEDs in Christmas lights has reached 50% would yield an estimate of around 40 TWh, around 1/5 of Mr. Brooks' estimate. SEB CHECK THIS CALCULATION https://www.iea.org/reports/lighting https://www.earth-policy.org/datacenter/pdf/book_wote_energy_efficiency.pdf Bitcoin use less energy than data centers</a></h3> This one is pretty close. The best source I could find indicates that data centers consume about 190 TWh / year</a>, with a clear trend in decreasing energy consumption from traditional data centers, and increasing consumption from cloud centers. Interestingly, the overall electricity usage from data centers is now decreasing year-by-year even as cloud computing is clearly on the rise, mainly due to the move to hyperscale server centers, which tend to be more efficient at the workload level. Bitcoin electricity consumption is already past 190 TWh / year and has consistently increased, so though data centers may have used more electricity in the past, that is no longer true. It's also worth noting that some of the electricity consumption from data centers may also be supporting cryptocurrency mining, so the gap between the two may be even larger. There's also a usefulness argument here, as I would wager that the commenters who wanted to see this comparison would also concede that there is a lot of usefulness to the types of workloads that are being run in data centers. My guess is that the commenters expected data center electricity consumption to far exceed that of cryptocurrencies and so they meant to point out that there is a lot of waste in general computation as well. General confusion about energy calculation</a></h3> Though the comment I link to in this section header does not add https://www.reddit.com/r/environment/comments/v4fmcj/comment/ib4jt4i/?utm_source=share&utm_medium=web2x&context=3 Arguments of the Hands (Usefulness)</h2> Bitcoin uses less energy than X</h3> I addressed some specific examples of this type of question in Bitcoin uses less power than data centers</a>, Bitcoin uses less power than ATMs</a> and Bitcoin uses less power than Christmas lights</a>. In those two cases, we found that the statistics quoted in the comments were false, and we can consider them arguments of the head. However, given that aggregate energy usage for cryptocurrencies is still less than a percent there are of course a lot of things in the world that use more energy than Bitcoin. Calculating energy usage per transaction is wrong as transaction rate for Bitcoin is constant</a></h3> [The article does not account for transactions on the Bitcoin lightning network]</h3> The title talks about cryptocurrencies, but the article only addresses Bitcoin</a></h3> Mostly true, though I did try to give a brief explanation in footnote 1</a>. Here's the slightly longer argument: Let's pretend that humanity collectively decided to wind down the Bitcoin experiment and every single Bitcoin holder sold their Bitcoins to reinvest in other cryptocurrencies. If these investors reallocated their money in such a way to not affect the relative weights of market-capitalization for the other cryptocurrencies, they would then buy into the cryptocurrencies based on the ex-Bitcoin asset-weighted mix of all other cryptocurrencies. For example, if Ethereum currently accounts for about 10% of the global cryptocurrency market-cap and Bitcoin accounts for around 80%5</a>, we would now expect Ethereum to account for 10% / (100% - 80%) = 50% of the total cryptocurrency market capitalization. If each cryptocurrency also kept its same power efficiency, we'd expect the electricity usage for each currency to scale up by an equal amount. The full calculation using the numbers from the original article finds that energy usage would increase by 31.61% / 20.31% - 1 = 55.6%. Even though there are cryptocurrencies that are more and less efficient than Bitcoin from an energy perspective, this calculation shows that the asset-weighted mix of all cryptocurrencies sans Bitcoin has worse energy efficiency than Bitcoin itself, and so my arguments from the previous article also hold for the cryptocurrency ecosystem as a whole. Only proof-of-work cryptocurrencies are bad for the environment</a></h3> Cryptocurrencies use very little energy on an aggregate scale compared to other industries</a></h3> It's more important to consider energy production than consumption</a></h3> The global banking system is worse for the climate than Bitcoin</a></h3> Arguments of the Heart (Meaning)</h2> Corporations are worse polluters than individuals</a></h3> Anti-banking</h3> Footnotes</h2> [1] Though I would like to credit my non-posting as a sign of personal growth and a proof that I now know not to pick fights on the internet, in truth it was more of a victim of shiny-object syndrome. ↩︎</a> [2] In good news, the energy-usage of most crypto-currencies have plummeted since I originally drafted the article above. Not necessarily due to technological improvements though - just an artifact of the cratering crypto-prices. Hooray! ↩︎</a> [3] Though the Our World in Data link I used reports the non-fossil fuel percentage energy mix as 36.7%, that mix includes nuclear power. I'm all for nuclear power, but since the Digiconomist definition excluded nuclear from their sustainable sources in arriving at their figure, I do the same here to arrive at the 26.4% figure. ↩︎</a> [4] Note that right off the bat, we see that one Bitcoin transaction consumes about as much energy as 2 years worth worst-case usage of an ATM, so I'd say this argument is not off to a great start. ↩︎</a> [5] These weightings are based on the study linked in the original article, which is re-linked here</a> for easier reference. ↩︎</a> [6] Funnily enough, it doesn't appear like Brian Brooks actually read the section touching on Christmas lights in the hearing for which he submitted his testimony. In the video recording from the hearing</a>, he ends his opening statement in the paragraph before he talks about the sustainability issues of Bitcoin, at the 30:30 minute mark. There's nothing abnormal about this: witnesses in congressional hearings often have limited time to provide their opening statements and can submit written statements that go into more detail than what their oral testimony would allow, but I still find it kind of funny that this very easily-disprovable argument seems to have garnered attention even though the main source of it didn't even address it in his opening arguments. For complete transparency, I did not watch the full 4.5 hours of the Congressional hearing, so my apologies to Mr. Brooks if he did in fact voice this part of his testimony at a later stage in the hearing, though I still stand by the fact that he grossly overestimated his electricity consumption figure for Christmas lights. ↩︎</a> Cryptocurrencies are worse for the climate than you think 2022-06-02T00:00:00+00:00 I came across a pretty astounding article</a> the other day. The author of the article conducted a survey, asking a panel of 2,000 Americans familiar with cryptocurrency what impact they believe Bitcoin has on the environment and climate change. The results were as follows: 6% said It is a significant threat to the environment and climate change.</q></li> 26% said It has a slight impact on the environment and climate change, but not enough to cause a threat.</q></li> 32% said It has no impact on the environment and climate change.</q></li> 26% said It is good for the environment.</q></li> </ul> For those of you keeping score at home, that's a total of 58% of respondents who believe that crypto is either a neutral or a positive influence on the environment. It's hard to believe that this could be the case when some scientists warn</a> that Bitcoin alone could produce enough emissions to push us past the 2°C global warming mark by 2032. I think that the scale and urgency of the climate risks of cryptocurrencies are often misinterpreted when presented at an aggregate level, so I set out to compile some statistics on how to view crypto consumption through the lens of the household and marginal consumption. At the household level</h2> You might have seen articles like this one</a> and this one</a> stating that the Bitcoin1</a> network now uses more electricity than many large countries, like Ukraine. On one hand, this sounds like a lot: Ukraine has over 45 million people, and is about the same size as Texas. On the other hand, I think aggregate statistics like this can serve to obscure the issue. After all, Bitcoin is taking the world by storm, and is a global network - maybe it makes sense that it would rival some countries, even large ones. Comparisons to foreign countries also ask the reader to not only think about the question at hand (how wasteful are cryptocurrencies?), but also a geographical one (how large and developed is Ukraine?). It doesn't help that 2/3 of Americans couldn't even locate Ukraine on a map</a> before March. I find it more illuminating to approach the issue from a much more granular level. Each Bitcoin transaction consumes around 2,150 kWh</a> as of the time of this writing. The kWh unit stands for kilo-watt hours - a watt is defined as one joule per second, so a kilo-watt hour is equivalent to consuming 1,000 joules per second for one hour which is 3.6 megajoules. The only everyday reference most of us has for joules or watts are our light bulbs. One way to think about the Bitcoin energy usage then is that one transaction uses as much energy as keeping a standard 60W light bulb lit for 35,833 hours. That's almost exactly 4 years. Of course, 60W light bulbs are being phased out because they're so inefficient. Modern LED bulbs are more typically in the 10W range, so by that standard a Bitcoin transaction is more like 24 straight years of light bulb usage. Do you like to dabble in cryptocurrencies, and also turn off your lights when you leave a room to save energy? Don't bother. Even the light bulb example can be hard to wrap your head around because us humans are not great at thinking about very large numbers. 24 years is longer than Bitcoin has even been around. Perhaps a better comparison is to look at household electricity consumption. In the US, which is among the countries that uses the most electricity per capita</a>, the average household uses about 11,000 kWh per year</a>. In these terms, your Bitcoin purchase uses about as much electricity as 2.5 months of every other thing you use electricity for. Did you make a round-trip transaction by also selling your Bitcoin at some point in the year? Now those two transactions account for close to half a year worth of all your other electrical uses. The article I linked to above from the U.S. Energy Information Administration has a useful chart breaking down energy consumption for the average U.S. household by end use. Here's a reproduction of the same chart, with an added bar for the energy consumption of a single Bitcoin transaction. That's correct: on average if you make one Bitcoin transaction in a year, the electrical impact of that purchase is larger than any other use case in your household for the full year. Note that this calculation does not presuppose that you purchase a whole Bitcoin. It is equally true for any fraction of a Bitcoin you might purchase - it's the number of transactions that count, not the size of the transaction2</a>. Of course, as any good financial adviser worth their salt would tell you, it's usually not good to try to time the market with a single purchase of a financial asset, and so you may be want to invest regularly in your cryptocurrency of choice. Most Americans are paid every two weeks, so if you were to practice common financial advice of diverting a portion of your paycheck to investments, you'd on average incur a transaction 26 times per year. Here's how that would look like on the same chart: Yikes. At the incremental level</h2> Another effective lens to view cryptocurrency energy consumption through is that of global incremental energy usage. Thankfully, cryptocurrencies do not yet account for a significant percentage of aggregate global electricity consumption, but just as we have seen some pretty meteoric increases in the price of many cryptocurrencies, the electricity usage of crypto networks is also increasing at an alarming rate. The IEA estimates that the total change in electricity generation between 2019 and 2021</a> equals around 1,753 TWh. In the same time-period, Bitcoin's consumption has grown</a> from 38 TWh per year at the end of 2018 to 200 TWh</a> in 2021, an increase of 162 TWh per year. This means that close to 10% of all new electricity generated each year has gone to Bitcoin mining. There are roughly 250,000 Bitcoin transactions per day</a>, so even if each of those transactions came from a different individual, it means that a maximum of 0.003% of the world's population interacts with the technology per day. For us to blow 10%3</a> of our new electricity generation each year on a technology that quite frankly could never serve to replace current payment networks is insane. Footnotes</h2> [1] This article focuses on Bitcoin as it is the largest cryptocurrency and by far the worst climate offender on an aggregate scale, consuming about 2/3 of the electricity of all cryptocurrencies combined</a>. However, the points made in this article also stand for the long tail of other cryptocurrencies, given that the same study linked earlier</a> found that Bitcoin accounts for 80% of the market capitalization of all cryptocurrencies, meaning that if all other cryptocurrencies gained market-share at Bitcoin's expense, the problem would likely get worse, not better. ↩︎</a> [2] Technically, it's limited by number of bytes, but the bytes of a transaction are not very dependent on the size of the transaction. ↩︎</a> [3] That's 10% for now, but crypto electricity usage is still growing at a faster pace than average global consumption so that percentage will go up over time. ↩︎</a> You received an .asc attachment from me. Here's why 2022-04-26T00:00:00+00:00 If you're on this page, it might be because you received an email I sent that had a file attached with the extension .asc</code>. The file is a cryptographic signature, which you can use to verify that the email is actually sent from me, and that no one has tampered with or altered any of the other attachments to the email. By default, I GPG sign all emails that I send which contain other attachments. The easiest way to verify that the signature matches my public key is to use a mail client that supports GPG functionality natively. I use a terminal-based mail client called mutt</a>, but I can also recommend Thunderbird</a>, a full-featured graphical mail client from Mozilla. Once you have your client set up, you will need to import my public key so that your mail client knows what a signature from me is supposed to look like. My public keys are hosted on my website, available at this link</a>. Re-signing git commits 2022-04-24T00:00:00+00:00 Git allows you to sign commits</a> using a GPG key, as a way to prove that a commit that looks like it was made by you was in fact made by you. Perusers of the git history can then verify the signature by running git log --show-signature</code>. On Github, it's even easier to verify, as Github will add a green "Verified" stamp next to the commit, giving a quick visual indication that the signature came from a GPG key that you have asserted as your own in the Github settings. You can view the signing history for the git repository of this website here</a>. By default, Github will add that stamp to verified commits, and leave any commits that were not signed without a stamp. However, it's possible to activate "Vigilant mode" in the GPG settings of Github, in which case any unsigned commit is flagged with a yellow "Unverified" stamp. Since I'm planning on signing all my commits going forward, I've enabled vigilant mode on my account, but now I'm faced with the eyesore of seeing yellow stamps next to all the commits I made in my halcyon</del> pre-GPG days. This can not stand. I started exploring if it was possible to retroactively sign commits, and ended up with a pretty neat solution. The full command is git rebase --root --gpg-sign --committer-date-is-author-date</code>. --root</code> makes sure we rebase all the commits on the current branch back to our initial commit. --gpg-sign</code> adds our shiny GPG signature to each commit. By default, git views these commits as new, and so updates the history to show that all our commits happened today. In order to retain the actual commit date for each commit, we add the final component: --committer-date-is-author-date</code>. So there you have it, a way to retroactively sign all your git commits on a branch. Even though we fixed the most obvious sign of us messing with the git history, it's worth noting that this will most likely cause issues with any open branches that branched from the old history. We're effectively rewriting the whole git history, with new commit hashes and all - you will need to force-push the new branch to update the view on Github.. It's up to you whether the green badges are worth it. Caveat lector, and godspeed. You, me, and GnuPG 2022-04-23T00:00:00+00:00 Over the last few weeks, I've fallen down the GnuPG rabbit-hole. GnuPG</a>, short for "the Gnu Privacy Guard" (long for "GPG"), is a tool for asymmetric encryption, meaning that you can use it to create messages that only a specific recipient is able to read. More concretely, the system relies on private and public keys, where you can use someone's public key to encrypt a message that can only be decrypted with the corresponding private key. Not only have I made my own keys - I have now progressed to the stage where my emails, address book, calendar and passwords are all secured by a GnuPG foundation, with my private keys stored on a tiny device that I can carry with me. Bad idea? Maybe. Totally awesome? Abso-fricking-lutely! In forthcoming articles, I'll go into some detail about how I have – and you can – set up this system, starting with how to create your own GPG keys. In the meantime, feel free to send me an encrypted message using my public key. It's the cryptic-looking thing at the bottom of my website footer, beginning with 0x</code>. You can paste that key, along with the message you want to encrypt, in an online tool like this one</a> and then copy the message into an email to me</a>. I'm looking forward to hearing from you! American Primitive 2021-10-18T00:00:00+00:00 Lately, I've been trying to disconnect from technology in my spare time (more on that soon), and I've found myself reading more as a consequence. One of my favorite literary discoveries of the year is Mary Oliver</a>, the late, great American poet. Oliver's poetry is hauntingly beautiful, but also very accessible for poetry novices such as myself. A few weeks ago, I took a library copy of Oliver's Pulitzer-winning volume of poetry American Primitive</a> along for a walk in Central Park and ended up finishing it in a single sitting, shaded from the summer sun by a tulip-tree. Since I don't have any content yet on this website, I share two of my favorite Oliver poems below. Enjoy! In Blackwater Woods</h2> Look, the trees are turning their own bodies into pillars of light, are giving off the rich fragrance of cinnamon and fulfillment, the long tapers of cattails are bursting and floating away over the blue shoulders of the ponds, and every pond, no matter what its name is, is nameless now. Every year everything I have ever learned in my lifetime leads back to this: the fires and the black river of loss whose other side is salvation, whose meaning none of us will ever know. To live in this world you must be able to do three things: to love what is mortal; to hold it against your bones knowing your own life depends on it; and, when the time comes to let it go, to let it go. </blockquote> Humpbacks</h2> There is, all around us, this country of original fire. You know what I mean. The sky, after all, stops at nothing, so something has to be holding our bodies in its rich and timeless stables or else we would fly away. Off Stellwagen off the Cape, the humpbacks rise. Carrying their tonnage of barnacles and joy they leap through the water, they nuzzle back under it like children at play. They sing, too. And not for any reason you can’t imagine. Three of them rise to the surface near the bow of the boat, then dive deeply, their huge scarred flukes tipped to the air. We wait, not knowing just where it will happen; suddenly they smash through the surface, someone begins shouting for joy and you realize it is yourself as they surge upward and you see for the first time how huge they are, as they breach, and dive, and breach again through the shining blue flowers of the split water and you see them for some unbelievable part of a moment against the sky– like nothing you’ve ever imagined– like the myth of the fifth morning galloping out of darkness, pouring heavenward, spinning; then they crash back under those black silks and we all fall back together into that wet fire, you know what I mean. I know a captain who has seen them playing with seaweed, swimming through the green islands, tossing the slippery branches into the air. I know a whale that will come to the boat whenever she can, and nudge it gently along the bow with her long flipper. I know several lives worth living. Listen, whatever it is you try to do with your life, nothing will ever dazzle you like the dreams of your body, its spirit longing to fly while the dead-weight bones toss their dark mane and hurry back into the fields of glittering fire where everything, even the great whale, throbs with song. </blockquote> Welcome 2021-10-18T00:00:00+00:00 Hi, and welcome to my website. Yesterday I received an email from my domain provider that this domain will auto-renew in a week, meaning that I've been sitting on this domain without publishing something for close to a year - time to change that! In the future, I will post some thoughts here about various things that interest me, including finance, the attention economy, etymology and technology. For now, I've contented myself with creating some basic CSS styling to provide a hopefully pleasant reading experience. Thanks for stopping by, and feel free to contact me through the email link in the footer!