Twitter, in a now rescinded support article:

At both the Tweet level and the account level, we will remove any free promotion of prohibited 3rd-party social media platforms, such as linking out (i.e. using URLs) to any of the below platforms on Twitter, or providing your handle without a URL.

If you were one of the people who thought Elon Musk's acquisition would be anything but an unmitigated disaster from the day news first broke in early 2022, I implore you to use this as an opportunity to pause and reflect. In my mind, no other outcome was ever remotely plausible. Musk was clearly addicted to Twitter the same way someone might be addicted to slot machines. And if a gambling addict were to buy their favorite casino, no one should expect it to go well.

There have been countless signs over the years that Musk's mystique as a genius playboy was every bit as artificial (and as we've now seen, brittle) as Donald Trump's facade as a serious businessman. The success of Tesla and SpaceX's management teams was clearly to cocoon Musk away from anything operationally important. He's just another rich kid who was able to buy his way into the upper echelons of power. That he funded meaningful enterprises was great, but he clearly never possessed the managerial or engineering skills needed to effectively run them.

If we've learned anything, it's that machismo and faux-intellectualism are even more effective at influencing society's elites than we otherwise might have feared. The only rational reaction to this and similar revelations is for us to put to bed, once and for all, the Great Man myth that wealth is fairly allocated according to a just, meritocratic process. Once you exclude the billionaires that were born into wealth and then further remove the one-hit wonders that lucked into it, scarcely anyone is left to admire and emulate. It's a shame, then, that the belief that the rich deserve to be rich is so vital to the American identity that its endurance is all but assured.

I typically don't pay attention to new static site generators. Having built one myself, I know firsthand that unless they hit critical mass, the ongoing maintenance costs to keep up with front-end tool churn became aren't worth the burden, and eventually whoever's making it will cut their losses and stop maintaining it—effectively saddling users with a site that'll just stop building in one year or five.

Capri was build with CMS integration in mind. Preview your content changes inside a static SPA without a running server.

Okay, now you have my attention.

I was surprised and delighted to learn that my friend Len had been invited to write an essay about Bob Chapek's ouster in the New York Times. The article serves as a great primer on some of the issues those of us who live near Disney World have been griping about for years. The whole thing is well worth reading.

His conclusion really stood out to me:

Mr. Iger is reportedly already scrutinizing the reservation system and is alarmed by the price increases his predecessor instituted. To further mend the relationship with our community, Mr. Iger should explain how Disney is going to use the revenue from upcharge programs to improve the guest experience.

If he wants to learn more, I sincerely suggest Mr. Iger try to plan, book and take a Disney World vacation on a middle-class budget, relying only on Disney's website and app. When he's overwhelmed by the cost and complexity, I know many fans who'd be happy to talk him through it. No charge.

In software we talk about the value in "dogfooding" an app, because it forces us to embody the persona of the user. If I, as a developer, experience any confusion, encounter any bugs, or feel any friction using the app, I can go to work and fix it. Immediately. No need to channel the feedback roundaboutly through focus group testing, customer support, or product management.

If you're the CEO of a theme park company, it may not seem like a huge sacrifice to dogfood your product by going to a theme park to experience it as the average guest would. But as soon as the company starts down the path of selling priority access for people who can pay more (fast lanes, VIP tours, backstage entrances), you'd surely have access to those luxuries yourself—you're the CEO, after all. It would take remarkable self-restraint not to indulge in those conveniences and instead wait in full-length lines—you know, like an average guest would.

I've seen this phenomenon impact countless software teams as well. If an app features multiple differentiated pricing tiers, the experience at the lower levels of access tend to accumulate more bugs, simply because nobody inside the company is compelled to dogfood them. When was the last time an Amazon engineer tried buying something without a Prime membership? Or a Netflix employee with a Basic subscription? Or an Apple engineer whose iCloud quota is capped at the 5GB free tier? It's no surprise that these experiences are terrible for customers, if they even work at all.

Apple's commitment to accessibility is nothing short of remarkable. They pull features all the time. They ship so many bugs that many of my friends wait months before updating their software. But nothing ever ships until every feature supports every accessibility modality.

It generates nearly zero direct revenue, but it surely makes up for it in good karma. And one reason I started taking accessibility seriously as a developer was having a blind friend show me how magical his iPhone 4 was back in 2011. It didn't just set a high standard for excellence, it expanded my understanding of what was even possible.

Now, why should we bring back that artisan, hand-crafted Web? Oh, I don't know. Wouldn't it be nice to have a site that's not run by an amoral billionaire chaos engine, or algorithmically designed to keep you doomscrolling in a state of fear and anger, or is essentially spyware for governments and/or corporations? Wouldn't it be nice not to have ads shoved in your face every time you open an app to see what your friends are up to? Wouldn't it be nice to know that when your friends post something, you'll actually see it without a social media platform deciding whether to shove it down your feed and pump that feed full of stuff you didn't ask for?

Wouldn't that be great?

Few endeavors have felt so immediately "right" as investing in an overhaul of this site and its RSS (well, Atom) feed last week. Looking back, the time in my life that I got the most out of the Internet and put the most back onto it was 1997-2009.

Whatever pulled me away in the years since didn't leave much of an impression beyond my frayed dopamine pathways and a thumb always anxious to scroll up to refresh.

Hard not to conclude that reading and writing blogs is better for the mind than scrolling social media timelines.

An updating monorepo full of self-hostable Open Source fonts bundled into individual NPM packages!

I just stumbled across Fontsource for the first time and it's brilliant. And not because Fontsource provides developers a way to import free fonts, pin them to a particular version range, and host them along with the rest of their applications. For the simple reason that they make it easy to find, filter, and test countless fonts in a web UI that's free of ads, marketing, and visual clutter.

I literally clicked through 228 handwriting-style fonts today before settling on Handlee for a new project. It feels good to finally have a free font site I can recommend without reservation.

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.