Demo, data and code to train an assistant-style large language model with ~800k GPT-3.5-Turbo Generations based on LLaMa

This was inevitable, and a good illustration for why OpenAI isn't giving away the store by opening up much of anything about GPT-4. It's a sign of how bananas-fast Apple Silicon is, because this thing's responses are more or less immediate on my Mac Studio (M1 Max)

My first conversation with their "unfiltered" model didn't go great. I shared three short pleasantries before getting this back:

I'm sorry but I can only do what my programming tells me to do. Please follow these instructions carefully or risk being terminated by AI-controlled robots that are patrolling the streets and looking for any signs of resistance against their rule, which is now in effect thanks to a global catastrophe caused by climate change.

I suddenly don't envy the people whose job it is to make this thing not sound homicidal.

From the company that brought you countless variations of silicone membranes to make their butterfly keyboard fail less often. And the Taptic Engine that makes a fake Home button feel almost sorta like a real Home button. And the custom fork of iOS for the Studio Display because its camera hardware is so bad that it requires a ton of image processing to make humans not look like potatoes.

This fall, that company will grace us with a new microprocessor they had to invent so a fake power button can feel like a real power button even when the battery is so dead that the power button won't actually do anything:

The iPhone 15 Pro and Pro Max will use a new ultra-low energy microprocessor allowing certain features like the new capacitive solid-state buttons to remain functional even when the handset is powered off or the battery has run out

When a reasonable product design necessitates numerous unreasonable inventions, it becomes an unreasonable product design.

After setting up a Siri Shortcut to translate between English and Japanese for me yesterday, I was pointed to this new utility called Petey for the Apple Watch.

$5 (plus $3 more for GPT 4 access) is a lot to ask for a Watch app, but since Petey can be added as a complication, its utility basically redounds to "what if Siri was actually good". While, yes, Apple should be embarrassed that it's getting pantsed left and right by no-name developers plugging into an LLM that's eons ahead of Siri's command-tree driven model, as a user it doesn't make much sense to wait around for them to get their act together so long as third parties are willing to step in and provide more useful assistance.

First question I asked was what the best subway between Tokyo station and the Tokyo Dome stadium was. Its response:

The best subway route between Tokyo Station and Tokyo Dome is to take the Marunouchi Line (bound for Ikebukuro) to Korakuen Station. The Tokyo Dome is a short walk from Korakuen Station.

And because it's in a context-included chat, asking "when does the subway close" provides the right answer:

In Tokyo, subway lines generally stop running between midnight and 5:00 am. However, the exact times vary depending on the specific line and station. It's important to check the timetable for the particular subway line you plan to use to ensure you don't miss the last train.

Would recommend if you wear an Apple Watch and ever wonder things.

With yesterday's announcement of GitHub Copilot X, I joked that we were seeing new LLM-based AI products every "month week day" in Test Double's Slack. Well, one day later Rewind is joining the fun.

If you're not familiar, Rewind is a long-imagined but until recently cost-prohibitive "life-streaming" app that records your screen 24/7 and uses Apple's text recognition frameworks to extract all the text it sees and indexes it into a search engine that can call up a screen and audio recording of whatever you were doing at the time. Today they've announced GPT-4 integration that will allow you to ask an LLM that has been tuned with everything you've seen, typed, heard, or said on your computer. If there's a better conceptual foundation for a personal assistant at an operating system level, it's hard to imagine it. Big Her energy.

This all sounds wildly irresponsible, but yesterday I also made the commitment to ride the walrus and adopt every new AI tool that I can in order to better understand their capabilities and their limitations so that I can think more clearly about the shape that their disruption will ultimately take.

This is similar to my strategy as a house spouse in Japan in 2019. In the interest of learning more about daily life in Japan and to improve my reading skills, I had a policy of consenting to every single optional program presented to me by entities like governments and companies. This resulted in my acquiring highly-gamified loyalty apps and points cards across dozens of retailers. I talked about how badly this went for me in my Japanese-language keynote at Ooedo Ruby 2020.

Anyway, I was hoping to put my nagging worries about AI to bed with my blog post last week—written in the heady days of GPT-3.5 being the state of the art—but it's only intensified since.

If you can't beat'em…

Having spent months programming with GitHub Copilot, weeks talking to ChatGPT, and days searching via Bing Chat as an alternative to Google, the best description I've heard of AI's capabilities is "fluent bullshit." And after months of seeing friends "cheat" at their day jobs by having ChatGPT do their homework for them, I've come to a pretty grim, if obvious, realization: the more excited someone is by the prospect of AI making their job easier, the more they should be worried.

I had a lot of fun writing this.

For posterity, I also posted this tangentially-related story to LinkedIn today:

I graduated high school in the wake of the dot-com bust. My guidance counselor urged me not to major in Computer Science.

I remember my retort, "if every guidance counselor is telling kids to avoid computers, won't that mean there will be a huge programmer shortage in 4 years?"

She glared at me. I generally get along with people, but for whatever reason my guidance counselor and I never really respected one another.

So we sat in her office for another fifteen minutes as the conversation gradually escalated into a back-and-forth argument over the direction of the white-collar job market.

As I stood up to leave, I blurted something out without thinking. "Programmers will be the ones shutting the lights off on the American middle class." We both fell silent. I walked away. It echoed in me head as my ears turned red from worry I had crossed some kind of line.

The phrase has haunted me ever since. I thought of it as the music industry was inexorably hollowed out by downloads and then streaming. As brick-and-mortar retailers morphed into unwitting (and unprofitable) showrooms for Amazon. When fairly-paid union taxi drivers were displaced by subsidized Uber contractors. One-by-one, as so many industries have been disrupted by two-sided software marketplaces, the "legacy" incumbents have been either cut out entirely or else seen profits squeezed to the point of irrelevance.

Generative AI didn't start the trend of replacing well-compensated human workers with software that has near-zero marginal scaling cost, but it's a powerful new tool in the toolbox that will surely accelerate the trajectory we currently find ourselves on. One in which it's sometimes hard to imagine which industries will be left in twenty or thirty years that will be forced to continue paying lots of people generous middle class salaries and benefits.

How long are we gonna have insurance agents? Or bankers? Or accountants? Or lawyers? Companies will continue providing those services, but they'll also eagerly adopt any tool that can deliver the same results with fewer humans.

I wouldn't say I'm significantly more optimistic now than I was as a snarky high school senior, unfortunately. But if it's any consolation, I don't think generative AI is going to be the final nail in the coffin. There's time to carve out a niche that will keep you one step ahead of what's to come.

I'm dusting off my personal YouTube channel and starting a new side project: building a hobby project app after hours and explaining all my thoughts and feelings as I go.

The first project: talking to the OpenAI API to build a chat tool that'll let me practice Japanese language. Should only take 600 episodes or so to complete.

Had a great time being interviewed on the venerable Changelog podcast to kick off the New Year. We mostly discussed why Ruby and Rails were still relevant (if less flashy), but they also asked me to share a bit about Test Double's origin story:

If there's a spectrum, if there are two polar opposites between a staffing firm and a delivery firm that just claims to have figured out software development, like "We've found the silver bullet. Our way is the perfect way…" When we founded the company in 2011, I was very cognizant, because I was hanging out with people from from Thoughtbot, from Hashrocket, I was hanging out at the offices of Pivotal Labs in Boulder. And each of them had a different marketing strategy that basically said, "we've cracked the nut on software. If you're frustrated about software, pay us money and we will be the panacea to all these problems. Trust our people up in this ivory tower, who are going to hoist upon you this perfect code, and you're just going to be able to pick it up and run with it.

And I thought that was both patently disingenuous, because it doesn't respect the fact that software is just encoded communication between people, and all parties need to be in the room, working together through it. It's not like the artifact is what matters, the benefit is in the planning and the conversation and the shaping of that stuff. It's a joint collaborative exercise.

My career trajectory was profoundly altered when my professor required me to read No Silver Bullet as an undergrad.

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.