tautology.town

A few reasons to like Ruby

Thu, 18 Jun 2026 00:00:00 +0000

Ruby is my favorite programming language.

I have worked in Python, Javascript (Typescript also), and Go. I have written C, C++, Java, and Racket. Consistently, Ruby is the language I enjoy the most.

I like Ruby because it feels “good in the hand”. It is hard to explain, as are all matters of taste, or beauty. I believe Ruby ought to be appreciated like anything else well crafted, the way people obsess over a really nice pen or mechanical keyboards.

It’s rare to find others who feel the same. Ruby has fallen from the zeitgeist, and developers aren’t as interested in learning it anymore. At Recurse Center last year, I was the only one writing any Ruby.

For the unacquainted, here are a few reasons to like Ruby:

0. Ruby wants you to be happy
1. Expressions everywhere
2. Looping with numbers
3. Better lambdas with blocks
4. Enumerating is easy
5. Method pipelines
6. Combinatorics
7. Single line if
8. Meaningful punctuation
9. Modules are namespaces
10. until
11. Do what works for you

Run the code

All the code snippets in this post run in your browser thanks to Opal. You can edit them too. Note that there are differences between Opal and Ruby, but they shouldn’t matter here.

It’s okay if you don’t know any Ruby (and even better if you’re new). You should be able to follow along if you know any modern mainstream language. More important than the language rules, I hope you get a sense of what Ruby is like.

0. Ruby wants you to be happy

For me, the purpose of life is, at least partly, to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, so Ruby is designed to make programmers happy.

– Matz, the creator of Ruby, in 2000

Languages are, in part, philosophical endeavours and are imbued with their creators’ values. Matz has a particular philosophy — Ruby is designed to make you happy.

This is in contrast to languages that have pragmatic goals or technical constraints, like memory safety, concurrency, or mathematical purity.

It’s a worthy and inspiring goal, and the single best reason to try out Ruby.

1. Expressions everywhere

Ruby is inspired by Lisp (everyone admires Lisp, right?). Everything evaluates to a value, including if-else. Functions return their last expression, like in math (and Lisp). No unnecessary returns!

For example, you can do this:

# <- hashes start comments
def ordinal(n)
  suffix = if n == 1 && n != 11
    "st"
  elsif n == 2 && n != 12
    "nd"
  elsif n == 3 && n != 13
    "rd"
  else
    "th"
  end

  # functions return last expression
  "#{n}#{suffix}"
end

puts ordinal(1) # puts is Ruby for print
puts ordinal(2)
puts ordinal(3)
puts ordinal(4)
# all the code snippets are editable! 
# uncomment me and run again
# puts ordinal(5)

Assigning suffix once makes the program’s intent clearer than setting it multiple times.

2. Looping with numbers

Numbers are objects and expose some wonderful methods for looping.

3.times do |i|
  puts i
end

0.upto(2) do |i|
  puts i
end

3. Better lambdas with blocks

Also inspired by Lisp, Ruby has a dedicated and elegant syntax for lambdas. This is the method_name do |variables| ... end and the abbreviated method_name { |variables| ... } above. It’s a “block” of code (a closure) that is passed like a lambda into method_name to be invoked within by yield. |variables| can be omitted if the block takes no arguments.

In the loop examples above, we’ve been passing blocks into loop methods that are invoked once per iteration. The returning last expression choice works well since blocks are usually short.

You can use them for:

context and resource management (with in Python)
middlewares
iterators/generators
domain specific languages (DSL)

For example, a helper to benchmark code:

def stopwatch(&blk) # &blk means accept a block
  start = Time.now
  ret = yield # yield runs the block!
  finish = Time.now

  [ret, finish - start]
end

arr, duration = stopwatch do 
  10000.times.map do
    rand(100)
  end
end

puts "array of #{arr.length} random numbers"
puts "took #{duration} seconds to make\n\n"
puts "first five: #{arr.take(5)}"

Or a compact DSL for testing:

def test(desc, &blk)
  puts "Test: #{desc}"
  @checks, @failed = 0, 0 # @variables are instance vars
  
  yield # run test cases

  if @failed == 0
    puts "[✓] All #{@checks} passed!\n\n"
  else
    puts "[x] #{@failed} / #{@checks} failed!\n\n"
  end
end

def expect(actual, expected)
  if expected != actual
    @failed += 1
    puts "=> Check ##{@checks + 1} failed: #{actual} should be #{expected}"
  end
  
  @checks += 1
end

# Can your language do this?

test "addition" do
  expect(1 + 1, 2)
  expect(2 + 3, 5)
end

test "subtraction" do
  expect(1 - 1, 0)
  expect(-1 - 1, 0) # fails!
end

Blocks are very natural to incorporate and use.

4. Enumerating is easy

Enumerables (Arrays, Ranges, Hashmaps, even Primes) have excellent methods, many of which take blocks:

tally: tallies the number of each item, my personal favorite. What a great method name!
map, reduce: classic map/reduce
select, reject: querying
include?, any?, all?: checking for stuff
sort, sort_by: passing a block can change what it sorts with
take(n): takes n elements
each_cons(n): sliding window of n elements
each_slice(n): tumbling window of n elements
chunk: takes a block and groups each chunk by the return value
lazy switches an iterator to lazy evaluation

These methods are designed to be chained and return another Enumerable.

years = (2020..2025).map do |yr|
  {
    year: yr, 
    leap: (yr % 4 == 0 && yr % 100 != 0) || yr % 400 == 0
  }
end

days = years.map { |hash| hash[:leap] }
            .sum { |leap| leap ? 366 : 365 }

puts "#{days} days"

5. Method pipelines

A nice part of Javascript is method chaining. This is a good style for data being piped through a series of transforms. Ruby does this even better because:

everything is an object
everything is an expression and returns an object
objects come with many useful methods
blocks simplify lambdas
optional punctuation — methods without arguments can omit parens. No need for a pipe operator!

def commas(num)
  num.to_s.chars.reverse
    .each_slice(3).map(&:join)
    .join(',').reverse
end

puts commas(1234567890)

Powerful methods compose into powerful pipelines.

gatsby = "In my younger and more vulnerable years my father 
gave me some advice that I've been turning over in my mind 
ever since. \"Whenever you feel like criticizing anyone,\" 
he told me, \"just remember that all the people in this world
haven't had the advantages that you’ve had.\""

bigrams = gatsby.delete("\'\".\n").downcase.split.flat_map do |word|
  # every 2 consecutive char in the words
  word.chars.each_cons(2).to_a
end

# hashmap sorted as a list of pairs sorted by last item (the value)
top_bigram = bigrams.tally.sort_by(&:last).last

puts "most common bigram: \"#{top_bigram.first.join}\""
puts "seen #{top_bigram.last} times"

6. Combinatorics

There are even methods to shuffle, permute, combine, and sample.

values = ["ace"] + (2..10).to_a + ["jack", "queen", "king"]
suits = ["spade", "heart", "club", "diamond"]
colors = { 
  "spade" => "black", "heart" => "red",
  "club" => "black", "diamond" => "red"
}

deck = values.product(suits)
puts "a deck has #{deck.count} cards\n\n"

drawn = deck.shuffle.take(2)
hand = drawn.map do |value, suit|
  "a #{colors[suit]} #{value} of #{suit}s"
end

puts "you drew #{hand.join(" and ")}"

possible = ["H", "T"].repeated_permutation(4).to_a
ways = possible.map(&:tally).tally

outcome = possible.sample
puts "you flipped #{outcome}\n\n"
puts "that is 1 of #{ways[outcome.tally]} ways " \
 + "to get that number of heads and tails"

7. Single line if

A trailing if conditionally executes a line. Guards read nicely and emphasize early returns.

def fib(n)
  return [0, n].max if n <= 1

  fib(n - 1) + fib(n - 2)
end

puts fib(1)
puts fib(10)

Most things in Ruby are expressions, but this is a statement. Ruby is flexible, not dogmatic!

8. Meaningful punctuation

Question marks ? are a nice touch for methods that return booleans, and read nicely in English.

planets = [
  "Mercury", "Venus", "Earth", "Mars", 
  "Jupiter", "Saturn", "Uranus", "Neptune"
]

puts planets.include? "Pluto"
puts planets.empty?
puts planets.any? { |p| p.downcase.include?("y") }
puts planets.any? { |p| p.downcase.include?("z") }

Exclamation points ! are used for methods that modify an object in-place or throw errors.

Meanwhile parentheses are optional which is great for keeping straightforward method calls visually clean.

9. Modules are namespaces

Namespaces are always a good idea. Names resolve relative to modules or you can fully qualify names.

module Baseball
  class Bat
  end

  EQUIPMENT = [Bat]
end

module Cave
  class Bat
  end

  ANIMALS = [Bat]
end

puts Baseball::EQUIPMENT.include?(Baseball::Bat)
puts Baseball::EQUIPMENT.include?(Cave::Bat)

puts Cave::ANIMALS.include?(Cave::Bat)
puts Cave::ANIMALS.include?(Baseball::Bat)

10. `until`

In addition to while loops, Ruby has its opposite until that is much nicer to read for traversals.

Node = Struct.new(:val, :left, :right)

def dfs(root, &blk)
  stack = [root]
  
  until stack.empty?
    current = stack.pop
    
    yield current
    
    stack.push(current.right) if current.right
    stack.push(current.left) if current.left
  end
end

tree = Node.new(
  "S",
  Node.new("SL", Node.new("SLL"), Node.new("SLR")),
  Node.new("SR", Node.new("SRL"), Node.new("SRR"))
)

dfs(tree) do |node|
  puts node.val
end

You could do this with while stack.length > 0 but until stack.empty? reads so much better.

11. Do what works for you

Ruby deliberately lets you do things many different ways so you can do what maps better to your mental model. This goes as far as making it easy to introspect and modify the language. It wants to fit your thinking, rather than wanting you to think in terms of it.

Give Ruby a try today.

What do Visa and Mastercard do? An intro to card networks

Mon, 01 Jun 2026 00:00:00 +0000

Most people can recognize the Visa and Mastercard brands. Chances are, you use one of their cards to transact every day. You may have some notion that most places (in the US) take both, but some places only take Visa (e.g. Costco), and vice versa.

So what do they do? Here’s Visa’s attempt to answer that question.

A few things they don’t do¹:

They aren’t the company that issues the card. Those are called card issuers.
They aren’t a bank, though the cards you have are probably issued by one (Chase, Capital One, BofA, etc).
They don’t distribute point of sale methods or online checkouts, which are done by payment processors.
They aren’t responsible for onboarding or underwriting stores and merchants, known as merchant acquiring. This is done by banks offering merchant accounts, but increasingly offered by modern payment processors (Stripe, Square, Adyen)².
They don’t manufacture or print cards.
Nor do they manufacture the point of sale hardware.

Instead, Visa and Mastercard are card networks³, facilitating card transactions by connecting the cardholders and issuers to the merchants and acquirers.

This forms a two-sided market of all the participants in a transaction⁴:

---
config:
  theme: 'neutral'
  fontFamily: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif;
  nodeSpacing: 20
  rankSpacing: 25
  flowchart: 
    subGraphTitleMargin: {bottom: 20}
    useMaxWidth: true
---
%% For some reason arrows are still showing up in the Obsidian preview, but not in Mermaid online editor
flowchart LR
    subgraph Issuing[**Issuing**]
        direction TB
        CI[Card issuer] --- CH[Cardholder]
    end
    subgraph Acquiring[**Acquiring**]
        direction TB
        MA[Merchant acquirer] --- M[Merchant]
    end
    Issuing ---- CN[**Card network**]
    CN ---- Acquiring

The key players in a card transaction.

The card network’s job is to enable card transactions, and also to grow participation in their networks.

This boils down to four key responsibilities:

Run the telecommunications network to route transaction messages.
Coordinate the banking network to move money and settle transactions.
Set incentives to encourage the use of the network.
Set and enforce rules of the network, including a mechanism for disputes.

For the rest of the discussion, we’ll focus on Visa, as it’s what I’m most familiar with from my years in the payment industry. Mastercard is more or less the same, with different names for things.

1. Run the telecommunications network

When we talk about networks, we think of the Internet, computers connected together by fiber and deep sea cables.

Card networks, being telecommunication networks, are no different. They maintain data centers and lease fiber optics cables to connect issuers and acquirers electronically. At their most basic technical level, Visa’s responsibility is forwarding transaction messages between its participating issuers and acquirers. Mastercard calls this activity “switching”, seeing itself as a network switch.

Visa takes its data centers very seriously. They are highly secure, redundant, and fitted to survive all kinds of disasters. From Inside Visa’s Data Center (Network Computing, 2013):

“The company’s flagship data center, dubbed Operations Center East, or OCE, is a 140,000-square-foot facility that Visa will only say is located “somewhere along the Eastern seaboard.”

“Not surprisingly, the facility, which is also designed to withstand earthquakes and gale-force winds up to 170 miles per hour, is locked down like a digital Fort Knox. The roads entering the complex have hydraulic bollards that can shoot up fast enough to stop a vehicle traveling up to 50 miles per hour dead in its tracks. (The road is too curvy to drive safely at higher speeds.) Visitors must pass through a security gate, be cleared by roving security teams, and then be subjected to a biometric scan before being admitted.”

And a 2012 headline from USA Today:

Top secret Visa data center banks on security, even has moat

That top secret location? In Ashburn, Virginia, conveniently located by Topgolf and Trader Joe’s.

I think the "moat" is the pool of water on the top center-left.

Authorization and clearing

When a card is used, the card network routes a transaction request, known as an authorization, from the merchant to the issuer. The issuer then approves or declines the request in a response. Card numbers, also known as Primary Account Numbers (PANs), are used like IP addresses⁵. The first 6 to 8 digits of the PAN identifies the card issuer and is called the Bank Identification Number (BIN)

An approved authorization places a temporary hold on the account for the amount of the transaction. Later, the merchant submits the final transaction amount (for example, adding tips written on receipts or voiding the transaction) to initiate the transfer of money, known as clearing⁶.

Consider: before this was done by computers, this was done by people via phone calls⁷ and mail.

2. Coordinate the banking network

In addition to a telecom network, Visa has a financial network of banks.

After a transaction is finalized, money on both ends must move to fulfill the transaction, known as settlement.

Visa’s second job is to route money for settlement by having financial relationships with each party. It can collect money from one and transfer to another.

To be efficient, Visa does net settlement: every day, each network participant’s debits and credits are totalled, and at the end of the day the net money is moved to or from each participant once.

For domestic transactions, moving money is relatively straightforward, thanks to central banks.

Importantly, Visa is also able to settle internationally, even handling currency conversion. Visa acts as an adapter between banking systems with its global banking relationships. This greatly simplifies international money movement for participants in its network — without Visa, each participant would need to manage their own international banking relationships.

---
config:
  theme: 'neutral'
  fontFamily: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif;
  nodeSpacing: 20
  rankSpacing: 60
  flowchart: 
    subGraphTitleMargin: {bottom: 20}
    diagramPadding: 10
    useMaxWidth: true
---
flowchart LR
    CI[Issuer in Country A] --> VisaA["Visa's bank in A"]
    VisaB[Visa's bank in B] --> MA[Acquirer in Country B] 
    subgraph **Visa**
        VisaA -.-VisaB
    end

Visa as an adapter

Shuffling this amount of money around and timing everything right is no easy feat. Visa faces non-payment risk in addition to maintaining a significant balance to cover payouts while waiting to receive settlement payments. From Visa’s 2024 annual SEC report:

Most U.S. dollar settlements are settled within the same day and do not result in a receivable or payable balance, while settlements in currencies other than the U.S. dollar generally remain outstanding for one to two business days, which is consistent with industry practice for such transactions. … As of September 30, 2024, we held $11.2 billion of our total available liquidity to fund daily settlement in the event one or more of our financial institution clients are unable to settle, with the remaining liquidity available to support our working capital and other liquidity needs.

The Company’s settlement exposure is limited to the amount of unsettled Visa payment transactions at any point in time, which vary significantly day to day. For fiscal 2024, the Company’s maximum daily settlement exposure was $137.4 billion and the average daily settlement exposure was $84.3 billion.

3. Set incentives

The key to this whole arrangement are the fees required to participate in the network, largely set by the network.

Let’s walk through an average credit card transaction in the US:

A cardholder pays for a product at a merchant for $100.00.
The merchant pays 2.5% ($2.50) of the transaction to their payment processor or merchant acquirer. The 2.5% is the merchant discount rate or MDR.
The payment processor keeps 0.35% ($0.35), then pays 2% ($2.00) to the cardholder’s issuing bank and 0.15% ($0.15) to Visa. The 2% is the interchange fee, commonly known as interchange. The 0.15% is the network assessment fee. ⁸
The issuing bank keeps 2% ($2.00)!

Surprisingly, the issuing bank keeps most and the network takes the least, by an order of magnitude! This is because for the tranasction, the issuer is traditionally considered to take on most of the risk (although merchants are likely to disagree).

In addition to regulatory requirements, Visa and Mastercard offer zero-liability protection. This means that the issuing bank, not the cardholder, is liable for any charges made on a card if it is lost or stolen.⁹ The issuing bank also takes on credit risk, and must always pay for an approved transaction even if a cardholder cannot pay off their balance.

Out of these, the network sets the interchange and network assessment fee. Interchange fees vary dramatically based on the kind of card, category of spend, and even the metadata attached to a transaction. The network’s goal is to set fees that incentivize desired behaviors on their network, including using more secure payment methods (lowering interchange fees for merchants), or for companies to do more business spending (higher interchange fees on commercial credit cards).

Because of how much is given to the issuers, there are a lot of incentives for issuers to acquire customers and fund lavish rewards programs to encourage spending. This split also explains the recent rise of issuing processors, which make it easier for neobanks and fintechs to issue cards to access a more lucrative end of the market.

Why are merchants willing to pay this fee?¹⁰ The idea is that accepting card payments nets more customers and higher spending, due to convenience, consumer protections, and credit card rewards. More cards means more merchants, more merchants mean more cards, and more of everything is good for the network. In theory, the network benefits through fees, the merchants benefit through more purchases, and the consumer benefits through convenience.

The virtuous cycle of card spend.

In the EU, interchange fees are restricted to 0.3%, which explains the lack of rewards cards and wider acceptance of alternative payment methods like bank payments.

4. Set rules and handle disputes

Aside from incentivizing good behavior, card networks also need to regulate bad behavior on their networks. These rules are detailed in “Visa Core Rules and Visa Product and Service Rules”, a 923 page volume that is publically available. This is a tome detailing things like appropriate use of the Visa brand mark, detailed interchange data requirements, transaction processing timelines requirements, requirements and procedures for specific Visa services, and features issuers/acquirers should support.

For issuers and acquirers, who interact with the network, violating these rules could affect interchange rates, incur non-compliance fines (anywhere from $25k to $1M per month), or risk suspension from the network.

For cardholders and merchants, who interact with each other, networks provide a mechanism for resolving disputes between them. This could mean a fraudulent transaction, the product was not as promised, or a number of other possible reasons detailed in the rules. This is the process that happens behind the scenes when you call your bank to report fraud or request a chargeback.

When a payment method doesn’t have a dedicated dispute mechanism, the legal system is used to settle disputes¹¹. This a problem with cash or bank payments that cards don’t have.

Arbitration

Visa is not actually involved directly in resolving most disputes. The rules essentially impose forced arbitration¹². The issuer of the cardholder and acquirer of the merchant send evidence back and forth until one party yields and accepts liability for the transaction.

If both parties refuse to yield, then Visa reviews the dispute, charging a whopping $600 ($1000 for appeals) makes a decision based on the evidence provided (signature, security footage, receipts, etc) and the guidelines listed in the Visa Product and Service Rules.

The losing party pays the original transaction amount plus the review fee, so both parties have a lot of incentive to resolve it between themselves. Issuers often refund the cardholder themselves and write off the loss. Merchants proactively refund dissatisfied customers since they are charged a $15-30 processing fee by the acquirer upon receiving any dispute, even if they win.

Arbitration is not a fair system, but it is an efficient one.¹³

Conclusion

I hope you have gained some appreciation for the important role of card networks and some reasons for why cards are as popular as they are today. Use this knowledge to topple the V/MC duopoly, design your own payment method, or think about while you spend your money.

Edit: this reached the frontpage of Hacker News — hello, and welcome to town!

Nowadays they may have product offerings for some of these, or own subsidiaries that do some of these, but these are not core to the business of being a card network. ↩
Technically, these are “payment facilitators”. A bank underwites the payment company, and the payment company underwrites their merchants. The different roles in payments have historically been meaningful, but companies are increasingly blurring the lines, so these distinctions and terms are less interesting today. ↩
To be precise, we use “card networks” to colloqially refer to the companies operating their own card payment networks / schemes. For example, VisaNet is technically the network, Visa is the company/brand. Mastercard’s network is called Banknet. Both companies also own and operate specialized subsidiary networks for things like debit cards and ATMs, like Visa’s Interlink and Plus, or Mastercard’s Cirrus and Maestro, although technically VisaNet and Banknet can process debit (this is a story for another time). There are further terms to distinguish the telecommunications network with the bank network, and even subsets of each. Visa even thinks of itself as a “network of networks”. Turtles all the way down. ↩
Or four or more, depending on how you count. ↩
Similar to IPv4, 16 digit PANs are rapidly exhausting due to the use of anonymized “token” PANs used by things like Apple/Google Pay and saved payment details. ↩
Clearing includes finalizing/committing the payment and reconciliation against the authorization. “Capturing a payment” is what this is called from the merchant’s perspective. ↩
Known as a “voice authorization”. You might be able to get one today, although I don’t know if banks are staffing operators to field calls. ↩
Although interchange is short for interchange fee, technically interchange refers to the payment messages being routed by the card networks, and the fee is provided for that data. But, you almost never hear interchange used to mean payment messages except in technical specs. ↩
Although this creates trust in card payments, it has opened the doors to friendly fraud, where legitimate purchases are reported as fraudulent. Not to mention a moral hazard. ↩
Some merchants add a surcharge on card transactions to pass through the fee to customers. This used to be against Visa’s rules (and California state law) but lawsuits have challenged that. The surcharge amount is also only supposed to be the amount the merchant pays on a card transaction, but I suspect that many small merchants charge more. ↩
There are some amusing cases of this at work in large transactions, where the legal fees are much more in proportion with the transaction costs. ↩
Not that you asked, but the expansion of forced arbitration and confidential settlements are bad for society. Back in the day, you could sue your bank (for example) for doing bad stuff, but now contracts for everything include a clause for arbitration, waiving your rights as a consumer. The company pays for the arbitration, not you, so you can guess the outcome of that. Famously, Disney tried to use a forced arbitration clause in the Disney+ streaming agreement to prevent a wrongful death suit from a allergic reaction in a Disney restaurant. In the Visa case, the dispute process means the consumer tends to benefit, at the cost of the issuer and the merchant. ↩
The system is designed to encourage transactions rather than stopping fraud. It opens the door to fraud, especially friendly fraud, as explained in another footnote. Friendly fraud is a growing problem. ↩

Money: a constructivist approach

Sat, 23 May 2026 00:00:00 +0000

When I was younger, I thought that money was cash.

In this view, if you went to a bank and deposited a dollar, at the end of the day, the dollar would be placed neatly next to a stack of gold bricks, in a vault deep beneath the bank. If you sent a wire, the dollar (or another like it) would be aboard an armored car the next day to the receiving bank. An armored plane if you paid for same day.

Of course, this mostly wrong. But, I suspect, that why this is wrong is not as obvious to many people. I might even wager that banks, payments, and money generally, are misunderstood by most people.

Like:

What is money, if money is not cash?
Or: How does a dollar get around, if not by armored car?
And: What do banks do, if not hoard piles of gold in a vault?

To begin to answer these questions, and more, I invite you, dear reader, to close your eyes, and imagine a time before money, and allow us to invent money from scratch…

…

You are Boog.

You have recently invented Agriculture.

On paper (not yet invented), settling down and growing food was a great idea. But, you’re much busier than you expected, and your diet of oats has not been feeling great.

So, you ask Grob, your hunter-gather friend, for a slice of wooly mammoth.

“For Rock-god’s sake!” cries Grob. “This is the sixth time this rock-week. What’s in it for me?”

And so, you agree to exchange three bowls of oatmeal for a delicious mammoth-steak.

Thus, Commerce is born (and Altruism begins its slow decline).

Things are going well. Your oat fields grow large and bountiful. Others settle down near you for oats. You exchange oats for Goods and Services. Eventually, enough people settle down, creating Civilization.

Problems quickly emerge.

You are sick and tired of oats. You happily trade vast sums of oats for modern indulgences like Clothing, Bronze, and Stone Tablets.

But oats have become so commonplace that the oat-rate for these luxuries has reached the hundreds, even thousands, of bushels (this is called Inflation). This is too much for you to carry around, and far too many oats for anyone to eat at once.

Of course, you are Clever, so you devise a Genius Scheme: instead of sending buschels of oats directly, you mark down on a clay tablet how many oats you owe to who in a ledger (in doing so, you invent Numbers and Writing). Oat creditors can redeem their oats as needed in smaller, more consumable quantities. The oats remain safe and dry in a warehouse.

You figure out that you can even gamble and plant the still unclaimed oats to have even more for next year.

The system is pretty good.

So good, that instead of redeeming the oats, people trade by asking you to move oats from their oat-account to another’s. It works so well that soon everything is priced in oats, even as fewer and fewer people are redeeming numerical-oats for real-oats.

This is called: the Money of Account.

To make it you don’t need to be involved in every transaction, you design an oat-redemption-token. Made of pocketable circles of Bronze equal the to value of redeemable oats, you emblazon it with your oat-seal.

“This is a Circular Oat Ingot Note,” you say, holding up a bronze loop, showing it around. “COIN for short. You can use this as a Unit of Exchange. Now please stop bothering me.”

And this is called: Cash.

Okay, we’ve been having too much fun. Let’s break down what we’ve discovered:

Money can be a number, like “money of account”.
Money can be a thing, like cash (or oats).

And, in fact, a number is much more portable than a thing.

How do React hooks associate functions with state?

Thu, 21 May 2026 00:00:00 +0000

How do React hooks know which component instance is being called, without being passed a stable identifier?

There are many high quality answers online. For me, they either focus too much on React internals (Fibers, render cycle, ReactFiberHooks), or are too high level (“it’s just arrays”, closures, call order).

Here is an answer, written for and by me:

React stores state for a component instance by using its relative position in the “virtual DOM” tree. The Rules of Hooks requires hooks for a component to have a fixed order, so the call order can then be used to index an individual hook’s state.

This is alluded to in the React docs:

React keeps track of which state belongs to which component based on their place in the UI tree.
…
When you give a component state, you might think the state “lives” inside the component. But the state is actually held inside React. React associates each piece of state it’s holding with the correct component by where that component sits in the render tree.

Imagine keeping a second state tree that mirrors the shape of the UI tree. When we evaluate the UI tree, we walk through the UI tree and state tree at the same positions. Before a functional component is evaluated, its state is loaded from the corresponding state tree node to be used implicitly by its hooks.

Here is how you might implement a bare bones useState:

let context = {hookState: [], hookIndex: 0} // global hook "context"
// (unrelated to React Context API)

// 0. on first render, stateNode tree copies vnode (virtual DOM) tree structure
// visit() will be called per component instance/node when rendering 
function visit(vnode, stateNode) {
  // 1. before a functional component is called, load in its context
  context = stateNode
  context.hookIndex = 0 // reset for the current component
  renderStuff(vnode) // 2. evaluates the functional component, calling its hooks
  vnode.children.forEach((child, i) => visit(child, stateNode.children[i]))
}

// called by functional component
function useState(initial) {
  // 3. keep track of which hook is being called within the component
  const index = context.hookIndex // copy to closure
  context.hookIndex += 1

  // 4. if there is no prior state, this is the first render. initialize!
  if (index >= context.hookState.length) context.hookState[index] = initial

  return [
    context.hookState[index], // current value
    (value) => { // and setter
      context.hookState[index] = value
      queueRender()
    }
  ]
}

Conditionally rendered elements

How does this work for conditionally rendered elements? If an element is not rendered, then wouldn’t it lose its place in the rendering tree, messing up the rest of the tree?

My own confusion around this stemmed from the convenient representation of JSX.

JSX tags are transformed into function calls like this (try for yourself):

<Parent name="example">
  {showA && <A/>}
  <B/>
  <C/>
</Parent>

_jsxs(Parent, {
  name: "example",
  children: [
    showA && _jsx(A, {}), 
    _jsx(B, {}),
    _jsx(C, {})
  ]
});

Where _jsx and _jsxs are implemented by React or your framework of choice.

Notice that each of the children occupy their own index of an array passed into the parent _jsxs call.

More importantly, the entire conditional expression {showA && <A/>} takes its own place in the array. So the index of all the children in the “UI tree” stay the same, even when one child is not rendered. The element that isn’t rendered does lose its state, though.

For components that return different JSX return (showA ? <A/> : <B/>), React should reset the state subtree if the subtree’s node structure changes.

Keys and lists of elements

This also explains why lists of elements need a key. The entire array producing expression occupies an array index, so it becomes ambiguous which component is which since they share an index.

<Parent name="example">
  {arr.map(item => <A/>)}
  <B/>
  <C/>
</Parent>

_jsxs(Parent, {
  name: "example",
  children: [
    arr.map(item => _jsx(A, {})), 
    _jsx(B, {}),
    _jsx(C, {})
  ]
});

In summary¹

Each JSX tag is transformed into a _jsx function call, passing in the tag name as a string, properties as an object. A tag’s child tags are passed as an array of expressions.
React executes this function call and constructs a “virtual DOM” tree describing the intended DOM structure. React knows how to efficiently update the real DOM from the virtual DOM.
React stores local state for each component in a tree mirroring the virtual DOM. When state is updated, it uses the position within the tree to load the right state for hooks.
Hooks within the same component are distinguished by call order in that component. This is possible because of the Rules of Hooks.
This works with a conditionally rendered component (i.e. {showThing && <Thing/>}) because the entire conditional expression is included in the children array of its parent, so the index of the component is stable.
Lists of components need keys because the entire list expression occupies a single index in the children array of its parent, so they need their own stable identifier.

Resources

Build your own React (Rodrigo Pombo): this was helpful in understanding how JSX transforms into Javascript, which is the key that a lot of other resources missed or assumed. Very detailed!
Getting Closure on React Hooks (swyx): this explains closure for hooks and derives the rules of hooks.
Making Sense of React Hooks (Dan Abramov): introduces some benefits of hooks and talks about the implementation at a high level
- Also, the linked pseudocode from @jamiebuilds
Introducing JSX (legacy React docs): outdated (_jsx is now called instead of React.createElement) but useful context
StackOverflow answer from Knight Industries: provided some intuition, not as useful on its own
Asking questions to Claude was helpful in honing my understanding, especially for the conditional rendering question with JSX, which I verified with Babel.
Hooks FAQ: How does React associate hook calls with components (legacy React docs): this is the former “official” answer, but it’s very high level.
Preserving and Resetting State (React docs): mostly helpful, but a bit handwavey around “UI tree”. Its conditional rendering example hides the second, not first, Counter(), which hides that the conditional expression is in the UI tree.
Reconciliation (legacy React docs)
Virtual DOM and Internals (legacy React docs): clarifies the virtual DOM terminology

I like lists and bullets and I am not AI. Tautology.town is written by hand. I like em-dashes too, but that battle has been lost. ↩

Doing things ten times

Fri, 03 Apr 2026 00:00:00 +0000

I observed lately that there aren’t many things that I’ve done ten or more times. Ten is low enough to be reasonable, but is high enough that it takes some intention to get to.

For example: I estimate that over my life I’ve baked 6 pies: 2 blueberry, 2 apple, and 2 pumpkin (arguably a tart). This was surprising to me, since I consider myself a casual yet decent baker of pies. Decent enough for people to ask for my recipes!

I also consider myself a decent eater of pies. Even there, I estimate a lifetime total of having tried ten individual pies (including pumpkin, excluding cheesecake).¹

Doing a thing once a year will take you a decade to do ten times. Even once a week will take a few months to hit ten times. Despite my enthusiasm, my pie production (and consumption) is largely limited to Thanksgiving. Meanwhile, professional bakers churn through ten pies in under an hour.

Ten is different

If you want to take something seriously, first commit to doing it ten times.

After ten times, you will have done way more than “tourists” who have tried it once. You will have done more than once a year “casuals”, even if they’ve done it for years.

Another data point: the viewership of the math lectures I’m working through.

Assuming (!) that most viewers are watching sequentially, only an estimated 28% of the first lecture viewers will watch the second lecture. By the 10th lecture, most of the viewers that will drop off have gone, with 4% left. Only 3% watch last lecture!

I’m on lecture 6, a group where 20-45% finish the course.

By ten lectures, you have more in common with the completionists than the dropouts — 80% of those who make it to lecture ten continue on complete the course.

A public commitment

Staying committed is a differentiator, especially when fall off is steep, and it often is. ²

This post (10th on this blog) is my public commitment to start doing things ten times. Starting with four more pies.

This is individual pies tried, not kinds of pies tried. Why distinct-pies-tried? I think it gets best at the heart of the matter of what we care about. Better than slices, since it is easy to eat multiple slices in one sitting. Better than volumes of entire pie consumer, since pies are meant to be shared. I considered days-where-pie-was-eaten, but most pies at home are picked at over a long period. Cumulatively, I think I have eaten much more than ten slices of pie, on more than ten days, but much less than ten pies-volumes of pie. ↩
Retention is often log-normal, the limit distribution of multiplying random variables. ↩

Learning how to charcoal grill

Sat, 14 Feb 2026 00:00:00 +0000

I got a charcoal grill. A portable, no-frills, Weber Jumbo Joe.

It is a cute, round, and pleasingly-shaped little thing. You can get one used very cheaply. Contrary to its name, “Jumbo” Joe is one of the smaller grills you can get. (Smaller yet is “Smokey” Joe. Who is Joe?)

There was a Reddit comment I saw that just made me get up and go do it, which I had been hemming and hawing about before. I couldn’t find the comment again, but it went something like this:

was going to end it all on x-mas. my daughter in law gifted me a weber jumbo joe. been grilling 15 years since, never looked back

What a testimonial! I got my Jumbo Joe the very next day.

I’ve grilled on it four times, a little less than once a week since setting it up. There are more detailed guides online, but the absolute basics are quite simple.

The absolute basics

First; invite your friends over. Have some cold drinks!

There are two ways to cook: direct heat, and indirect heat. The “two-zone” technique is putting the charcoal on one side of the grill for direct heat searing, leaving the other half for indirect heat slow cooking via convection with the lid on. Charcoal stacked together helps keep it hot.

For temperature control, the grill has a bottom and a top vent that can be adjusted to control airflow. Open vents will pull more oxygen and the charcoal will faster and hotter.

Generally, try to keep the lid on to control temperatures and prevent flare ups. If there’s flare up, put the lid on and reduce the top vent. Remove some food; it may be dripping too much grease. Interestingly, the distinctive smokey flavor comes from fat drippings hitting the charcoal and turning to smoke.

There will be hotter and cooler spots you’ll notice as you cook. Flip and move the food around with tongs and a spatula. I use the OXO turner and tongs.

You can check the internal temperature with an instant read thermometer to see when meat is done cooking. It’s done at 160 degree Fahrenheit for beef and pork, and 165 for chicken. I use a ThermoPop.

Just in case, have a pair of heat resistant grilling gloves.

To start the charcoals, use a chimney starter and start the charcoal with fatwood. Avoid match-light charcoal and lighter fluid which can impart a chemical taste. I use briquettes, which are supposed to be easier than lump charcoal for beginners.

Once you’re done cooking, put the lid on and close both vents to snuff out the flame.

For clean up, I throw the steel grate and grill tools into the dishwasher the next day and use steel wool to clean off any burnt food. I don’t use a barbeque wire brush because I saw a TV episode about the dangers of ingesting a stiff metal bristle. This technique seems to work better, anyways.

Things to grill

The most popular thing I’ve grilled is bratwurst. Of course, served with whole grain or spicy brown mustard in a bun. Even better are cheddar brats!

The surprise favorite is corn, which has become my traditional way of ending a meal. When you grill corn alongside meat, it is beautifully sweet with a slightly savory smoke. Sweet potato, cut open and finished on the grill works similarly too.

Things I’ve yet to learn

As I’m just getting started, I have a lot to learn: smoking meats for a long time (charcoal snake method, water pan), ribs, reverse searing steaks, using temperature probes, different cuts of meat, wood smoke, mackerel, vortex grilling, bread, rotisserie.

You should grill too

Charcoal grilling is essentially a more sophisticated form of the most ancient form of cooking, cooking over a fire. It is innately human; we are practically born to do it.

I have long maintained that man has long known the ways to a good life, and that they are simple and should be easy to do. This includes good food, good company, and good times. Grilling can save lives.

It is intuitive, it is forgiving (cut off the burnt parts), it is delicious, it is fun, and it is even better with others. You should grill too.

Notes on watering houseplants

Sat, 10 Jan 2026 00:00:00 +0000

Overwatering and underwatering have similar symptoms, but an overwatered plant is much harder to save. Overwatering causes root rot which dries out plants.

A good cadence to water is often every two weeks, or even less.

Water when poking a finger into the soil feels dry or the leaves are curling up.

Instead of watering a little bit all the time, fully water your plant when it’s dry. This means thoroughly saturating the soil and letting the excess run off.

An easy way to fully water is from the bottom up: place your planter in a container of water and let it sit for a while to draw water up the drainage holes. This avoids problems with hydrophobic soil. I like to use a clear deli container so I can see the water level go down.

Also, have drainage holes in your planters!

It can help to write down when you’ve last watered, which may be more or less recently than you thought.

If you are an overbearing plant parent with a habit of overwatering, get a spray bottle to regularly mist your plant with instead.

Use filtered or distilled water instead of tap water.

Interesting links

DOM clobbering 1Password to fix syntax highlighting

Fri, 02 Jan 2026 00:00:00 +0000

TLDR; Add this to your site if 1Password’s browser extension is breaking syntax highlighting:

<a hidden id="Prism"></a><a hidden id="Prism" name="manual"></a>

Skip to the breakdown, or read on.

Backstory

About two weeks ago, I noticed that this blog’s code syntax highlighting stopped working. This blog (tautology.town) uses Jekyll, which comes with Rouge syntax highlighting out of the box.

Eventually, I discovered that 1Password’s browser extension was inadvertently overriding syntax highlighting in all websites (bug report). In a recent update, 1Password added Prism.js as part of an experimental snippets feature.

Prism.js highlights everything by default, so bundling it into the content script without Prism.manual = true means it runs on any .language-* class code block on every website.

The immediate fix for 1Password is simple: Prism.manual = true and manually invoke Prism.

More importantly, Prism.js should not be in the content script at all. The feature is restricted to the 1Password vault, so Prism should be moved to the extension’s popup script. It seems like a major oversight for this to have been included.

Worst of all, it appears to be a useless dependency. I couldn’t find the snippet feature in the browser extension. The desktop app has snippets but doesn’t highlight code.

Screenshot of 1Password desktop, showing an unhighlighted code snippet

I believe Prism.js is only included as a dependency of @lexical/code, part of the editor used for snippets. If so, Prism.js could be omitted entirely.

I assumed this would be fixed quickly.

Some time later…

Two weeks later, the issue was still not fixed and managed to pick up quite a bit of attention online (2.6k likes):

youyuxi: .@1Password browser extension is injecting Prism.js globally on every page, which then applies its syntax highlighting logic on all <code> blocks matching [lang=*] regardless of whether it’s meant to be compatible, thus breaking original highlighting.

Terrible negligence and even more so that this made to prod while already flagged during beta.

Been a user for a long time but this will def push me to an alternative if not fixed soon.

Evan You (@youyuxi) is the creator of Vue and Vite.

I think this was the push for 1Password to act. They are finally deploying a fix and promise a postmortem.

At the time of writing, the fix is not yet live for me. I see an update in the Chrome store, but not in Firefox or Safari (both iOS and MacOS).

While we wait, we can take matters into our own hands.

DOM clobbering

Web extension content scripts get access to the DOM (to do stuff) but run in an isolated Javascript context to prevent web content from accessing or overriding their behavior. Without this, they could be vulnerable to something like prototype pollution.

However, scripts with DOM access are still susceptible to DOM clobbering. DOM clobbering is using the DOM to define/redefine things expected by the running Javascript.

The HTML standard allows for “named property access” on window (docs) and document (docs), which means HTML DOM elements with id or name set can be accessed as if they were Javascript properties. For window:

For each <embed>, <form>, <iframe>, <img>, and <object> element, its name (if non-empty) is exposed. For example, if the document contains <form name=”my_form”>, then window[“my_form”] (and its equivalent window.my_form) returns a reference to that element.

For each HTML element, its id (if non-empty) is exposed.

If a property corresponds to a single element, that element is directly returned. If the property corresponds to multiple elements, then an HTMLCollection is returned containing all of them. If any of the elements is a navigable <iframe> or <object>, then the contentWindow of first such iframe is returned instead.

Recall that properties of window are implicitly global, so in the example my_form also returns the form.

Even DOM APIs like document.addEventListener can be overridden in this way.

<form name="addEventListener"></form>
<script>
console.log(document.addEventListener) 
/* prints <form name="addEventListener"></form> */
</script>

There are some limitations to this attack:

It only works if the corresponding value is not already defined by the Javascript context.
You can only return an HTML element or an HTMLCollection, not arbitrary values.

Still, you can take advantage of things like:

HTMLCollection access by id/name to DOM clobber nested properties.
HTML elements are truthy, so you can override false values.
<a> tags toString() gives the href value, and can be coerced with concatenation.
Convenient property access that matches HTML elements: e.g. if value is accessed you can clobber with an <input value="overridden-value">

We can use the first two tricks to clobber 1Password’s Prism.js.

Clobbering Prism.js

The Prism.js docs show how to normally disable automatic highlighting:

<script>
window.Prism = window.Prism || {};
window.Prism.manual = true;
</script>

Since 1Password’s content script is in an isolated context, including this script on a site won’t affect the content script. Its Prism.js won’t ever see window.Prism.manual = true.

Let’s look at the Prism.js source to see how this setting is evaluated. On line 51 of prism-core.js:

manual: _self.Prism && _self.Prism.manual,

It’s checked on line 1184 before auto-highlighting:

if (!_.manual) {

And _self is set on line 3:

var _self = (typeof window !== 'undefined')
	? window   // if in browser
	: (
		(typeof WorkerGlobalScope !== 'undefined' && self instanceof WorkerGlobalScope)
			? self // if in worker
			: {}   // if in node js
	);

So, manual is set to window.Prism.manual and can be DOM clobbered!

Payload

Let’s craft our payload and put it in our HTML:

<a hidden id="Prism"></a><a hidden id="Prism" name="manual"></a>

Breakdown

There are two <a> tags with matching id=Prism, so window.Prism will return a HTMLCollection with both.
An HTMLCollection’s elements can be accessed by their id and name, so we give the second tag name="manual" to make manual a property of the collection that returns the second <a>.
Finally, an HTML element is truthy, so !window.Prism.manual returns false, stopping automatic highlighting.
Also, we add hidden so they aren’t displayed anywhere + ignored by screen readers.

We can check in the console:

> window.Prism
HTMLCollection(2) [a#Prism, a#Prism, Prism: a#Prism, manual: a#Prism]

> window.Prism.manual
<a hidden id="Prism" name="manual"></a>

> !window.Prism.manual
false

And it works! This is the fix currently deployed to this site, if you need further proof it works.

Security implications

1Password, the app

You may be (rightfully) concerned about other ways 1Password could be DOM clobbered via Prism.js.

In fact, I learned about DOM clobbering when looking into the security of Prism.js.

CVE-2024-53382 describes an XSS on Prism.js 1.29.0 using DOM clobbering. The original report gives a great summary of the vulnerability. At a high level, Prism’s autoloader plugin uses document.currentScript to dynamically load language definitions that an attacker could clobber to load their own script. It was patched in 1.30 by checking if document.currentScript.tagName equals 'SCRIPT'.

Thankfully, as far as I could tell, the version deployed by 1Password is not vulnerable to XSS via Prism. The manual parameter is designed to be overridden, which inadvertently allows for DOM clobbering. Other things on Prism don’t appear to be clobberable.

I did discover XSS vulnerabilities in v2 of Prism.js and will submit a fix or issue. That version has been in development since 2022 and is the default branch on GitHub, but isn’t yet released.

1Password, the company

The bigger question is what this signals about 1Password, the company.

I’ve historically trusted 1Password over other password managers due to their secret key based security model (especially over LastPass, which is not safe at all). 1Password has a good reputation from publishing about security and their approach.

This incident has me second guessing. It shouldn’t have been addressed so slowly (2+ weeks), nor should it have passed code review. Adding stuff to the content script is a big deal for extension development.

It appears to stem from improper bundling in the shared Javascript between the Electron desktop app and the browser extension. Moving from native to Electron already seemed like a cost-saving measure.

Security is largely a function of organizational culture. I worry they’re prioritizing business and growth over product and security.

Let’s hope I’m wrong. We’ll find out more if/when they publish the postmortem.

Trust is hard to gain, easy to lose, and harder still to get back.

Resources

I like this writeup of DOM clobbering best: Beyond XSS: Can HTML affect JavaScript? Introduction to DOM clobbering
A useful table of common patterns: DOM Clobbering Wiki: Patterns and Guidelines
Another developer’s very similar experience: 1Password Dependency Breaks Syntax Highlighting

You might also find interesting the WHATWG specs for named properties:

Learning about IP address routing

Sun, 14 Dec 2025 00:00:00 +0000

One question I had for a long time: What makes a destination IP address authoritative?

I know you can spoof sending a message as a different IP address, but even if your ISP didn’t prevent you, you wouldn’t receive a response because it would be routed to the actual location of the address you spoofed. This had me wondering:

What prevents a destination IP address from being spoofed?
How do we know an IP address we connect to is legitimate?

The short answer

The destination of an IP address is determined through decentralized routing, a protocol called BGP, loose coordination between large computer networks, regional registries for IP address ranges, and lots of trust!

“Spoofing a destination IP address” is possible, and is known as IP hijacking. One way this can happen is if a malicious or misconfigured actor advertises incorrect routing to the rest of the network, known as BGP hijacking.

A long explanation

The Internet is a network that connects other networks. An “inter-network” network, if you will. An Autonomous System (AS) is the largest network “unit” that the Internet interconnects.

Each AS has IP address ranges it controls, registered with a Regional Internet Registry (RIR). An AS knows how to reach any IP address in its ranges.
Each AS is identified by an Autonomous System Number (ASN) assigned by their RIR.
Autonomous Systems are connected to other Autonomous Systems and share reachability using the Border Gateway Protocol (BGP).

BGP messages say something like: “This is the next IP to follow to reach IPs with this prefix, via this path of ASNs”. This information is propagated transitively through Autonomous Systems and processed by each router to build their own routing tables.

A routing table says “to reach the IPs in this range, the next IP in the path is this”.

Routing packets

When you send a packet, it’s passed from router to router:

When a packet arrives at a router, the router looks up its routing table for a prefix matching the destination IP address.
The router forwards the packet to the “next hop” IP address for that prefix. I think the next hop IP address is usually the local IP interface to a connected router.
The process repeats, until the destination is reached.

On my home network, the ISP assigns me a public IP address. The process works the same in reverse when receiving a response, until a packet reaches my router via my public IP and my router forwards the packet to my computer somehow.

Trust and coordination

By design, the Internet is decentralized. The hop-by-hop nature of routing means an AS need only talk to its own neighbors in order to reach the entire connected set.

A few things to notice:

Autonomous Systems have full discretion with what they announce with BGP.
Reachability information from one node is propagated throughout the network.
Routers have full discretion to decide how to route a packet they’re forwarded.

Any router along the forwarded path could respond or tamper with a packet (man-in-the-middle (MITM) attack). You place a lot of trust into your ISP!

The rogue router could lie about the ASN path to advertise a fake shorter or more specific route with BGP, leading to traffic consistently being routed to it. This is exactly what BGP hijacking is. On top of malicious hacks, this happens at lot by accident (e.g. route leaks), causing some famous outages.

It’s a big enough problem that Cloudflare has a dedicated microsite: isbgpsafeyet.com.

Is BGP safe yet? No.

There are many strategies to improve BGP security, but the simplest is to cross check against another source. RIRs know what IP ranges go to which ASNs, so an AS announcing a route origin can be cross checked against the RIR’s signed records, known as Resource Public Key Infrastructure (RPKI). There are also databases called Internet Routing Registries (IRR) that Autonomous Systems publish routes to that can be used to filter obviously invalid routes. In practice, a large AS will be selective with who they accept BGP messages from and have different peering arrangements.

This isn’t perfect: we still have the man-in-the-middle problem, and an AS could still lie while publishing a legitimate-looking route.

This is why things like HTTPS are important — although, you still need to trust somebody, in this case the root cert.

Addendum: a few things to try

Routing tables

Your computer has a routing table. Here’s the one on my laptop (routel on Linux prints this nicer):

$ ip route
default via 192.168.0.1 dev en0
0.0.0/8 via 127.0.0.1 dev lo0
0.0.1/32 via 127.0.0.1 dev lo0
254.0.0/16 dev en0 scope link
168.0.0/24 dev en0 scope link
168.0.1/32 dev en0 scope link
168.0.197/32 dev en0 scope link
0.0.0/4 dev en0 scope link
255.255.255/32 dev en0 scope link

The first line is saying the default route to send traffic through is via 192.168.0.1 and device en0, if no other prefix is matched. en0 is the network interface, and apparently refers to my laptop’s network card. If I run arp -a | grep "(192.168.0.1)", I think it prints the MAC address of my wifi router.

So, this is saying that the first hop goes through network card to my router.

Tracing routes

We can use traceroute (or mtr) to look at the path that a packet can take.

Because no single router knows the full path of a request, traceroute works by repeatedly sending packets with an incrementing hop limit then using the source IP of the error message response and hop count to infer the path of a request. (Interestingly, traceroute to this blog does not work, possibly because the Github Pages CDN does not reply, although mtr works.)

Here’s a traceroute from a DigitalOcean droplet to “example.com” (-q 1 so only 1 IP is sampled per hop count):

$ traceroute -q 1 example.com
traceroute to example.com (23.192.228.84), 30 hops max, 60 byte packets
138.68.34.248 (138.68.34.248)  1.054 ms
143.244.192.80 (143.244.192.80)  1.841 ms
143.244.227.102 (143.244.227.102)  1.654 ms
143.244.225.47 (143.244.225.47)  1.618 ms
*
192.168.224.135 (192.168.224.135)  1.676 ms
192.168.226.131 (192.168.226.131)  1.446 ms
a23-192-228-84.deploy.static.akamaitechnologies.com (23.192.228.84)  1.542 ms

I looked up the ASNs associated with each IP by looking it up on bgp.tools. Surprisingly, most were not found by bgp.tools although most were at least found in RIR registries.

138.68.34.248: 138.68.34.0/24 originated by AS14061 (DigitalOcean).
143.244.192.80: No prefix match, but allocated to ARIN-DO-13 (DigitalOcean).
143.244.227.102: No prefix match, but allocated to ARIN-DO-13 (DigitalOcean).
143.244.225.47: No prefix match, but allocated to ARIN-DO-13 (DigitalOcean).
192.168.224.135: Not found anywhere, 192.168.0.0/16 is a private address space.
192.168.226.131: Not found anywhere, 192.168.0.0/16 is a private address space.
23.192.228.84: Overlapping Prefixes Detected, both under AS20940 (Akamai).

For the unannounced ASNs, I assume these are part of the private network of DigitalOcean as the request finds its way out of the VPS network. I assume the private address spaces are related to that, and that Akamai and DigitalOcean are connected somewhere in an Internet Exchange Point (IXP) with some internal infrastucture corresponding to the two private IP addresses.

To learn more, you might like this post from Julia Evans.

Ruby's object model: eigenclasses, metaclasses, and more

Mon, 01 Dec 2025 00:00:00 +0000

Or, a Class class masterclass.

One way or another, a famous question will cross every Rubyist’s mind, probably many times: what’s an eigenclass?

In the Ruby docs, there’s a tremendous diagram under the page for class Class that made me think of this again:

Classes, modules, and objects are interrelated. In the diagram that follows, the vertical arrows represent inheritance, and the parentheses metaclasses. All metaclasses are instances of the class ‘Class’.

                         +---------+             +-...
                         |         |             |
         BasicObject-----|-->(BasicObject)-------|-...
             ^           |         ^             |
             |           |         |             |
          Object---------|----->(Object)---------|-...
             ^           |         ^             |
             |           |         |             |
             +-------+   |         +--------+    |
             |       |   |         |        |    |
             |    Module-|---------|--->(Module)-|-...
             |       ^   |         |        ^    |
             |       |   |         |        |    |
             |     Class-|---------|---->(Class)-|-...
             |       ^   |         |        ^    |
             |       +---+         |        +----+
             |                     |
obj--->OtherClass---------->(OtherClass)-----------...

I thought I more or less understood Ruby classes, eigenclasses, and what have you, until I came across this. I don’t know about you, but this made very little sense to me. Is a metaclass the same as an eigenclass?

This Question is famous and Frequently Asked enough that Ruby has an official FAQ answer (also: why is this in an FAQ instead of having better docs?).

A singleton class is an anonymous class that is created by subclassing the class associated with a particular object. Singleton classes are another way of extending the functionality associated with just one object.

Better. By the way, singleton class is another word for eigenclass. Does the diagram make any more sense?

After an exciting afternoon, I think I have the definitive answer. Let me now try to answer the question, by way of answering everything.

Objects have a class

Everything in Ruby is an object.

Every object in Ruby has a class.

object -- has a --> a class

Even “primitive” types are objects.

Every object in Ruby has a class.

The class is available in the class method, which returns the class of an object.

irb(main):001> "hello world".class
=> String

irb(main):002> 123.class
=> Integer

Classes have ancestors

We can define our own classes with the class keyword. Then make an instance of that class with new().

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> a = A.new
=> #<A:0x0000000101197e20>

irb(main):004> a.class
=> A

A class has ancestors which it inherits from. On the class itself there is a ancestors method, which returns the order of classes that it inherits from.

              (... rest of ancestors)
                      |  
                    a class
                      ^
                      |
                inherits from  
                      |
object -- has a --> a class 

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003* class B < A
irb(main):004> end
=> nil

irb(main):005> B.ancestors
=> [B, A, Object, Kernel, BasicObject]

Method resolution

When we call a method for an object, we look up its class and its ancestors, then look for a method with that name in each class, up the ancestor chain (left to right).

irb(main):001* class A
irb(main):002*   def say
irb(main):003*     "aye"
irb(main):004*   end
irb(main):005> end
=> :say

irb(main):006* class B < A
irb(main):007*   def say
irb(main):008*     "bye"
irb(main):009*   end
irb(main):010> end
=> :say

irb(main):011> A.ancestors
=> [A, Object, Kernel, BasicObject]

irb(main):012> B.ancestors
=> [B, A, Object, Kernel, BasicObject]

Every class inherits from Object. The root of every class heirarchy is BasicObject. These define the most basic methods every object (everything) can call.

irb(main):002> BasicObject.instance_methods
=> [:equal?, :!, :__send__, :==, :!=, :__id__, :instance_eval, :instance_exec]

Classes are objects

Everything in Ruby is an object.

Every object in Ruby has a class.

Even classes are objects. So they have a class too. They are objects with class Class (uppercase).

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> A.class
=> Class

irb(main):004> A.instance_of? Class
=> true

The class keyword is just one way to give a Class a name.

irb(main):001> Class.new
=> #<Class:0x0000000102778488>

irb(main):002> A = Class.new
=> A

irb(main):003> a = A.new
=> #<A:0x00000001026e7c80>

The class of Class is … itself. Because it’s a class!

irb(main):001> Class.class
=> Class

It is an instance of itself.

irb(main):002> Class.instance_of? Class
=> true

Class also has ancestors.

irb(main):001> Class.ancestors
=> [Class, Module, Object, Kernel, BasicObject]

It turns out all classes inherit from Module.

Module is also a class. Modules objects that are instances of Module.

irb(main):001> Module.class
=> Class

irb(main):002* module B
irb(main):003> end
=> nil

irb(main):004> B.class
=> Module

A lot of things are a class, because everything is an object and objects have a class.

Everything is an object

A “class” is an object that has a class of Class.

It can help to think of an object’s class not as “what it is”, but as a property of the object.

Indeed, in Ruby’s internals, klass is a property on a C struct included on all objects. And everything is an object.

klass

Class of an object.

Every object has its class. Also, everything is an object in Ruby. This means classes are also objects. Classes have their own classes, classes of classes have their classes too, and it recursively continues forever.

So, Class is an object with a klass pointer to itself.

Singleton classes and eigenclasses

So what’s an eigenclass?

It’s a singleton class, of course! Singleton class is the official terminology now.

Okay, so what’s a singleton class?

When you create an object from a class, the object creates and stores an anonymous class that inherits from the original class.

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> a = A.new
=> #<A:0x00000001032e7da0>

irb(main):004> a.singleton_class
=> #<Class:#<A:0x00000001032e7da0>>

irb(main):005> a.singleton_class.ancestors
=> [#<Class:#<A:0x00000001032e7da0>>, A, Object, Kernel, BasicObject]

Importantly, because this singleton class is created per instance, any methods set on the object’s singleton class do not modify the object’s regular class.

When we call a method, we look up the method name on the instance-specific singleton class first. In Ruby internals, an object’s class is secretly actually the singleton class, which inherits from the class the object was instantiated from and allows method resolution to work down the ancestor chain as expected.

This is the point of the singleton class! It allows us to add or override methods at the object level without affecting other instances of the object’s class.

We can use the def {obj}.{method_name} or class << {obj} syntax to define a method on the singleton class for that instance.

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> a1 = A.new
=> #<A:0x00000001010976b0>

irb(main):004> a2 = A.new
=> #<A:0x0000000101097430>

irb(main):005* def a1.hello
irb(main):006*   "hi"
irb(main):007> end
=> :hello

irb(main):008* class << a2
irb(main):009*   def bye
irb(main):010*     "cya"
irb(main):011*   end
irb(main):012> end
=> :bye

irb(main):013> a1.hello
=> "hi"

irb(main):014> a2.bye
=> "cya"

irb(main):015> a2.hello
NoMethodError: undefined method 'hello' for #<A:0x0000000101097430>

irb(main):016> a3 = A.new
=> #<A:0x0000000101096738>

irb(main):017> a3.hello
NoMethodError: undefined method 'hello' for an instance of A

irb(main):018> a1.bye
NoMethodError: undefined method 'bye' for #<A:0x00000001010976b0>

irb(main):019> a3.bye
NoMethodError: undefined method 'bye' for an instance of A

Class methods

This is also what allows class methods to be defined with the same def self.{method_name} or class << self syntax in a class body.

class WithClassMethods
  def self.class_method_1
    "one"
  end

  class << self
    def self.class_method_2
      "two"
    end
  end
end

puts WithClassMethods.class_method_1
puts WithClassMethods.class_method_2
# WithClassMethods.new.class_method_1 => NoMethodError
# WithClassMethods.new.class_method_2 => NoMethodError

All classes are objects, all objects have singletons, so class A (which is an instance of Class) has a singleton class that we’re modifying with the same syntax! The self in the class body points to class A.

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> A.singleton_class
=> #<Class:A>

irb(main):004* class A
irb(main):005*   def self.on_the_class_singleton
irb(main):006*     "yes"
irb(main):007*   end
irb(main):008> end
=> :on_the_class_singleton

irb(main):009> A.singleton_class.instance_methods.include?(:on_the_class_singleton)
=> true

The class singleton class always inherits from the singleton classes of its ancestors, which is how you can call class methods defined on a parent class on a child class.

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> class B < A; end
=> nil

irb(main):004> B.singleton_class
=> #<Class:B>

irb(main):005> B.singleton_class.ancestors
=> [#<Class:B>, #<Class:A>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

irb(main):006> B.new.singleton_class.ancestors
=> [#<Class:#<B:0x0000000100f47378>>, B, A, Object, Kernel, BasicObject]

Because every class is an object, class singletons are also an object, so this chain of inheritance repeats infinitely. Ruby lazily creates singleton classes, so does not repeat infinitely in practice, although you could access them infinitely.

irb(main):001* class A
irb(main):002> end
=> nil

irb(main):003> a = A.new
=> #<A:0x00000001003a7b58>

irb(main):004> a.singleton_class.ancestors
=> [#<Class:#<A:0x00000001003a7b58>>, A, Object, Kernel, BasicObject]

irb(main):005> A.singleton_class.ancestors
=> [#<Class:A>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

irb(main):006> A.singleton_class.singleton_class
=> #<Class:#<Class:A>>

irb(main):007> A.singleton_class.singleton_class.ancestors
=> [#<Class:#<Class:A>>, #<Class:#<Class:Object>>, #<Class:#<Class:BasicObject>>, #<Class:Class>, #<Class:Module>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

irb(main):008> A.singleton_class.singleton_class.singleton_class.ancestors
=> [#<Class:#<Class:#<Class:A>>>, #<Class:#<Class:#<Class:Object>>>, #<Class:#<Class:#<Class:BasicObject>>>, #<Class:#<Class:Class>>, #<Class:#<Class:Module>>, #<Class:#<Class:Object>>, #<Class:#<Class:BasicObject>>, #<Class:Class>, #<Class:Module>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

#<Class:A> is the singleton class of class A (not the singleton class of an instance of A).

Because it is a class singleton class, it inherits the singleton classes of the ancestors of A, so the singleton classes of Object (#<Class:Object>) and BasicObject (#<Class:BasicObject>).

Since those singleton classes are themselves classes, the they eventually inherit from Class. We could repeat this for another layer, then we’d have the singleton class of Class, and so on and so forth.

In the diagram, the horizontal arrows going right should be labeled “is of class” and “has singleton class”.

Language is hard

Finally, “metaclass” means “class of a class”. Only singleton classes of classes are metaclasses, what you use to you define a class method. A singleton class of a class instance is not a metaclass (in the past this terminology was conflated).

In this case, #<Class:A> is a metaclass. Metaclasses eventually inherit from Class, since they are classes.

In summary:

Everything is an object
Objects have a class
Classes have methods
Classes have ancestor classes
Methods are looked up on a class and its ancestors
Classes are objects
Classes have a class
Objects create a singleton class that inherits from their regular class
Objects look up methods on their singleton class first
Class methods are methods on the singleton class of a class
Singleton classes have a singleton class
The singleton class of a class inherits from singleton classes of the class’s ancestors

I think this explains what an eigenclass is, the entire infinitely recurring diagram from the beginning, as well as the rest of Ruby’s object model.

Here is my version of the diagram (where bob = Dog.new and class Dog < Animal):

                      +---------+             +-...
                      |         |             |
      BasicObject-----|-->(BasicObject)-------|-...
          ^           |         ^             |
          |           |         |             |
      Object----------|----->(Object)---------|-...
          ^           |         ^             |
          |           |         |             |
          +-------+   |         +--------+    |
          |       |   |         |        |    |
          |    Module-|---------|--->(Module)-|-...
          |       ^   |         |        ^    |
          |       |   |         |        |    |
          |     Class-|---------|---->(Class)-|-...
          |       ^   |         |        ^    |
          |       +---+         |        +----+
          |                     |
        Animal-------------->(Animal)-----------...
          ^                     ^
          |                     |
         Dog----------------->(Dog)-------------...
          ^
          |
bob--->"eigen-bob"

Vertical lines represent inheritance, horizontal lines represent singleton classes, and parentheses represent metaclasses.

References

Noel Rappin’s “Better Know A Ruby Thing” series on Ruby singletons is the most valuable resource I used:

As short as the Ruby FAQ, but much more informational: Singleton Classes in Ruby (aka eigenclasses)

Official Ruby syntax docs:

This post from Yehuda Katz is good but I think predates standard terminology, so mentally replace every occurrence of “metaclass” with “singleton class”: Metaprogramming in Ruby: It’s All About the Self

tautology.town

A few reasons to like Ruby

Run the code

Links

What do Visa and Mastercard do? An intro to card networks

1. Run the telecommunications network

Authorization and clearing

2. Coordinate the banking network

3. Set incentives

4. Set rules and handle disputes

Arbitration

Conclusion

Money: a constructivist approach

How do React hooks associate functions with state?

Conditionally rendered elements

Keys and lists of elements

In summary1

Resources

Doing things ten times

Ten is different

A public commitment

Learning how to charcoal grill

The absolute basics

Things to grill

Things I’ve yet to learn

You should grill too

Notes on watering houseplants

Interesting links

DOM clobbering 1Password to fix syntax highlighting

Backstory

Some time later…

DOM clobbering

Clobbering Prism.js

Payload

Breakdown

Security implications

1Password, the app

1Password, the company

Resources

Learning about IP address routing

The short answer

A long explanation

Routing packets

Trust and coordination

Addendum: a few things to try

Routing tables

Tracing routes

Ruby's object model: eigenclasses, metaclasses, and more

Objects have a class

Classes have ancestors

Method resolution

Classes are objects

Everything is an object

Singleton classes and eigenclasses

Class methods

Language is hard

References

In summary¹