justin․searls․co

Vision Pro with the Good Strap

Following up on my post from this morning on how to use a 3rd party "halo" strap for Vision Pro, my incredible brother Jeremy printed and sanded these adapters for me. The experience wearing this strap is night-and-day better than either of Apple's built-in straps. The headset's weight is finally where it should be.

PSA: This is the first good Vision Pro strap

UPDATE: It works! Photo here

As I mentioned in my review podcast, the two straps that ship with the $3500 Apple Vision Pro are god-awful and mediocre, respectively.

If you just spent that much money on this thing, do yourself a favor and buy two more things:

  1. A BOBOVR M2 Plus strap

  2. This 3D-printed conversion kit for connecting it to Vision Pro (you can also print it yourself)

And boom: for under $50 you'll have a comfortable way to actually use the Vision Pro. Shame on Apple for dropping the ball so badly in the name of aesthetics (what happened to, "design is how it works"?), but hat tip to Mark Miranda for pointing me to this Etsy listing.

Just survived my first flight with Apple Vision Pro. Watched 2 hours and 35 minutes of downloaded video and had 8% battery remaining.

If you've ever paid a significant amount of money for a seat upgrade, consider buying a Vision Pro instead. I literally forgot I was sitting in economy.

One of the strangest things about United Airlines is that booking a premium economy seat (of which there are only a dozen or so on this plane) has zero bearing on your boarding zone unless you buy an extra add-on. It's so bizarre because it results in United being wholly excluded from Premium Economy searches on sites like Google Flights. Feels strange paying twice as much to hang out in Group 5.

Still got it

10 pounds. 19 liters. Vision Pro, MacBook Air, spare battery, and all the clothes and toiletries I need to travel indefinitely.

Still got it.

HTML fragment caching really works!

I have somehow been using Ruby on Rails since 2005 and have never worked on an app that needed to think seriously about web request caching, probably because of my proclivity to reach for static site generators and simple asset hosting whenever anything I make will be public-facing. But the current app I'm working on is actually mostly accessible without requiring users be logged in, which means it will both (1) run the risk of having bursts of hard-to-anticipate traffic to certain pages and (2) render pretty much the exact same markup for everyone.

I'll start with the results. Here's a mostly-empty, public-facing page my basic Heroku dyno without caching:

Completed 200 OK in 281ms (Views: 201.9ms | ActiveRecord: 47.5ms | Allocations: 37082)

And now with a few lines of caching setup:

Completed 200 OK in 9ms (Views: 3.5ms | ActiveRecord: 1.6ms | Allocations: 2736)

So over 30 times faster. And that's on a very basic page. Once the site is primed with content it'll probably be even more dramatic.

Here's how to do it.

And then what happened?…

Breaking Change artwork

v4 - Facial Computing

Breaking Change

This podcast is a month old and four episodes in and the singular event looming over all of it has finally arrived! The era of facial computing has begun!

Join me for a Vision Pro extravaganza in which I detail all of my first impressions using the device, including dozens of things that seemingly every media and YouTube reviewer missed or excluded. Listen to this podcast and you'll hear tell of bugs you wouldn't believe even if you did see them!

The headline takeaway is: Apple Vision is clearly the future, because it's clearly not yet the present. (And why I'm probably keeping it anyway.)

As always, e-mail me your reviews, reactions, and errata at podcast@searls.co and I'll absorb them into the bubbling stew of opinions I'm forming about this futuristic-and-not-necessarily-in-a-good-way computing platform.

Scant show notes follow:

Show those show notes…

I wonder if anyone has attempted to fork VS Code to run under WebKit instead of Chromium. My M2 MacBook Air should get "all-day battery life" but has never cracked 3 hours and the only running app other than Safari is usually VS Code.

This'll be an insta-purchase for me before it can get yanked from the App Store:

Juno delivers a fully native visionOS UI that taps into YouTube's embed API, which is designed to allow videos to be embedded in external webpages. When you want to browse YouTube's video catalog, Juno pulls up a tweaked version of the YouTube website. Apparently, the app is even clever enough to not show ads for YouTube Premium subscribers, though it remains to be seen how Google feels about a third-party developer being in control of an app for one of its biggest services on a new piece of hardware. Selig notes that he didn't use any private/internal APIs to develop the app.

I'm not one to kink shame, but it's starting to feel like this guy's fetish is building businesses whose survival depends on the mercy of hostile platform holders.

Real beaut of a lede in the WSJ (News+ link) today:

Meta Platforms is hoping Apple's launch of the Vision Pro can reinvigorate its $50 billion metaverse effort, which consumers have yet to widely embrace.

Love the optimism here, but I wouldn't be surprised if this ages about as well as the CEO of Palm's, "PC guys are not going to just figure this out," quote prior to the iPhone's launch.

Update: this take by Kristopher Browne on Mastodon raises a great point:

I believe them. Goggles are the last device category where Apple didn't have designs for others to crib from. It's a space like "smart phones" were in before the iPhone, when android was going to be a blackberry clone because it's not like google knew how to design a device or interface.

I almost forgot about this mess. I guess the analogy really holds: just like Google had no clue that touch metaphors like "pinch-to-zoom" were going to be the breakthrough interface paradigm for smartphones, Meta (as indicated in this WSJ article) wasn't seriously chasing down mixed-reality computing of the sort implemented in visionOS until after WWDC.

Neat HomePod Update

The latest batch of 17.3 updates appear to have nuked all my HomePods. Very neat.

Breaking Change artwork

v3 - Core Technology Fee

Breaking Change

Welp, Apple forced my hand and generated even more news in the run up to the launch of Apple Vision Pro and it demands a response! (Right?)

As is so obvious and well-established that I forgot to mention it, you can e-mail me the show at podcast@searls.co and maybe I'll find a way to work it in. Comments, questions, and complaints are all welcome!

Without further ado, let's a-do it:

Show those show notes…

Brand-new Rails 7 apps exceed Heroku's memory quotas

Update: Judging by this commit and the current status of main, this should be fixed for Rails 8. Great PR thread about this, by the way.

In the history of Ruby on Rails, one of the healthiest pressures to keep memory usage down has been the special role Heroku has played as "easiest place to get started hosting Rails apps". In general, Rails Core and Heroku's staff have done a pretty good job of balancing the eternal tension between advancing the framework while still making sure a new app can comfortably run on Heroku's free (or now, cheap) "dyno" servers over the last 17(!) years. Being able to git push an app to a server and have everything "just work" has always been a major driver of Rails' adoption, and it's seen as obviously important to everyone involved that such a low-friction deployment experience—even if developers ultimately move their app elsewhere—is worth preserving. And that means being cognizant of resource consumption at every level in the stack.

Anyway, there have been numerous bumps in the road along the way, and I think I just hit one.

I just pushed what basically amounts to a vanilla Rails 7.1.3 app to Heroku and immediately saw this familiar error everywhere in my logs:

Error R14 (Memory quota exceeded)

It started literally minutes after deploying the app. The app was taking up about 520MB. What gives? I even remembered to avoid loading Rails' most memory-hungry component, Active Mailbox!

Keep reading…