Luthen is the most nuanced character Star Wars has ever had. He has all the gravitas of the living myths like Luke Skywalker and Han Solo, all the convictions of Qui-Gon Jinn, all the complications and commitment of Obi-Wan Kenobi, all the showmanship of Kylo Ren, all the cleverness of Leia Organa, and deeper, more human flaws than anyone the series has ever seen. In the capable hands of Andor creator Tony Gilroy and Skarsgård, Luthen is the kind of complicated, thorny, fascinating character Star Wars just never seemed built to contain.

One of my favorite things about Tony Gilroy's Andor series was that by telling a story that doesn't incorporate the Jedi, the Sith, or the Force—and thereby avoiding Star Wars' traditional, simplistic narrative arc of Very Obviously Good overcomes Very Obviously Evil—it created room for characters to react realistically to the circumstance of a fascist, bureaucratic empire encroaching on their daily existence.

If viewed as a role-playing game, the "smuggler" has long been designated by Lucas and Disney as the third playable class after the rebels and imperials, but until recently they've been relegated to comic relief and MacGuffin couriers. And we'd probably never have seen this kind of believable character development if the final Skywalker trilogy hadn't ballooned into such a sloppy and overblown mess. I guess we have JJ Abrams to thank.

I was grateful to be hosted on the Season 1 finale of Matt Swanson's new podcast, YAGNI. It's an interview show challenging that widely popular tools and practices may not be as worthwhile as people think—as the the eponymous agile acronym ("You Ain't Gonna Need It") suggests.

In this episode I share some history about what was going on at the time RSpec rose to prominence, why its continued dominance in the Ruby community is at odds with the declining relevance of the ideas that begat it, and why I personally stopped using and promoting RSpec in the mid-2010s.

I hope you enjoy it!

I'm genuinely excited about this site's rewrite. I thought it'd be fun to make a video to explain my thought process about the redesign—both why I'm excited about finally publishing a linklog/linkblog/microblog and how all these various tools plug together to enable a (mostly) painless continuous deployment pipeline.

I hope you enjoy it!

There's something new coming in Ruby 3.2 this Christmas that I can't wait to start using in all my projects:

Ruby 3.1 [sic] adds a new core class called Data to represent simple immutable value objects. The Data class helps define simple classes for value-alike objects that can be extended with custom methods.

While the Data class is not meant to be used directly, it can be used as a base class for creating custom value objects. The Data class is similar to Struct, but the key difference being that it is immutable.

It'd be easy to look at this and conclude that this is just the same Struct we've been using for decades, with the added constraint that it's immutable. On the other hand, that's a pretty important constraint!

But if you read the pull request, there are some serious quality of life improvements over Struct, like built-in translation of positional arguments to keyword arguments, which allows for easy-to-define default values:

Measure = Data.define(:amount, :unit)

Measure.new(1, 'km') # => OK
Measure.new(amount: 1, unit: 'km') # => OK

Measure = Data.define(:amount, :unit) do
  def initialize(amount: 0, unit: 'cm')
    super
  end

  # imagine other elucidative methods here
  def metric?
    # …
  end
end

This is great news for people who go out of their way to separate their code into two categories: units that implement feature logic and things that represent values. The units implementing application behavior have no state and the values they receive and return are nothing but state. Adopting this approach rigorously transformed my programming practice, allowing for clearer thinking and making progress more predictable.

It's exciting to see Ruby core continue to make consistent iterative progress year after year!

I've been a VR gaming enthusiast for years (having owned the Rift DK1, the HTC Vive and Vive Pro, and the Valve Index before settling on a Quest 2), so I preordered the Meta Quest Pro to see what all the fuss was about.

The Quest Pro's resolution is 1800 x 1920 pixels per eye, roughly the same as the Quest 2's 1832 x 1920 pixels. In theory, it provides better contrast and a very slightly higher pixel density per eye, but comparing both devices head-to-head, I was hard-pressed to tell the difference. It's still grainy enough that images look all right, but small text is fuzzy.

I, for one, decided to return this thing within 5 minutes of unboxing it.

The $1500 Quest Pro makes trade-offs that add up to a significantly worse headset than its (until recently) $299 predecessor. The Pro's pancake lenses improve the field-of-view slightly, but they also magnify each pixel more, reducing the sharpness of the image. Placing the battery on the back helps balance the Pro's weight distribution, but it also forecloses the possibility of 3rd-party straps—which matters, because the Pro is much less comfortable than my Quest 2 with this excellent $35 strap. The Pro's open design (it barely obstructs the user's peripheral vision) makes it a statement piece that VR doesn't have to be antisocial, but its "wings" let in so much ambient light that it makes most games instantly nausea-inducing.

Do not buy the Meta Quest Pro.

Worlds and Workrooms are available for the Quest 2 and Quest Pro alike, but Workrooms is particularly aimed at Pro users. And—there's just no nice way to put it—it's one of the worst apps I've ever used.

This is what really kills me about this product, though. The hardware is pitched as one's entry point to "the metaverse", but there is no metaverse! Just a couple broken apps. They're so bad that management can't even force the programmers making the apps to try using them.

Superficially, sure, Horizon Worlds is a worse version of RecRoom and Horizon Workrooms is a much worse version of BigScreen VR. On a deeper level, though, this failure is emblematic of what large companies often get wrong when they undertake greenfield software projects. They dream big, staff big, and then start building.

Ready. Fire. Aim.

One way I think about this is that almost every stimuli that a very small team building a very small thing encounters amounts to direct product feedback in some form or another. Even if the team members themselves are the only users, the feedback loop couldn't be tighter. Change a thing. Try it out. Repeat.

The larger a human organization surrounding a product grows—especially when it outpaces the maturation of the product—the less attention will be paid to the product itself. That attention will instead be diverted to the superlinearly-growing needs of all the humans (logistics, consensus-building, rework) and the affordances they demand of the product to accommodate so many people (modularized design patterns, internal tooling, service orchestration).

Big teams don't result in successful products, but successful products sometimes result in big teams.