justin․searls․co

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!

Spoiler alert: there's more to this…

Ben kicks off a screamer this morning with a quote from a prior interview with Om Malik:

But the thing is you actually have to be mobile-native to actually appreciate something like this. So if you’ve grown up watching a 75-inch screen television, you probably would not really appreciate it as much. But if you are like me who’s been watching iPad for ten-plus years as my main video consumption device, this is the obvious next step. If you live in Asia, like you live in Taiwan, people don’t have big homes, they don’t have 85-inch screen televisions. Plus, you have six, seven, eight people living in the same house, they don’t get screen time to watch things so they watch everything on their phone. I think you see that behavior and you see this is going to be the iPod.

I'll go one further: when I moved to Florida, I went to great pains to create the best home theater I could with a complete blank slate. That landed me with:

I think I read six hundred posts on AVS Forum and Reddit before settling on this setup, and three years later it's still the best configuration money can buy. People who come over and watch a movie are usually blown away. Indeed, it is pretty fucking rad.

But, you know what? Vision Pro already smokes this setup. Wider field of view, tighter perceivable dot pitch, better color reproduction. Using an individual headset isn't just better for "mobile-native" users one might imagine in a far-flung Asian country where everyone lives in 200-square foot studio apartments… today's high-end headsets are already better than the best flat displays, period.

The bulk of the post is spent comparing Apple Vision's launch with the introduction of the iPod. iPod's success was enabled by Apple's clever persuasion over the record labels to dramatically devalue their songs on iTunes, while the biggest story about the Vision Pro is that Netflix and YouTube are skipping its launch due to Apple's draconian App Store policies. Wanna watch Netflix? You'll have to use Safari:

Apple may be unhappy that Netflix viewers have to go to the Netflix website to watch the service on the Vision Pro (and thus can’t download shows for watching offline, like on a plane); Netflix might well point out that that going to the web is exactly what Apple makes Netflix customers do to sign up for the service.

Ben goes on, mostly about what this conflict means for the short-term. We'll have to see. I think his analysis is pretty mcuh bang on.

However.

One thing I’d suggest is that visionOS is actually Apple's first bimodal platform, in that it has the potential to be the ideal experience for both consumption and creation (something that, to date, Apple has divided with iOS/iPadOS/tvOS/watchOS on one side and macOS on the other). My primary use case for a Vision Pro is to just mirror my Mac screen to it as I develop software, despite having a $3000 6K Dell display a few feet away, simply because the Vision Pro offers a bigger, better screen (despite having fewer pixels).

In Steve Jobs parlance, the Vision Pro is simultaneously a car and a truck.

I think it’s exactly because Apple can move the ball down both ends of the field simultaneously with a single futuristic platform that they're so obviously committed to this platform. In the past, the thing that’s given Apple leverage over software and media companies has been that they dominate hardware sales to the juiciest demographic of consumers. Today, the conversation is over whether regulators or circumstance will force them to loosen their grip on the app store. But it's unlikely we're going to know how the next chapter of this power struggle will play out any time soon—it'll be at least 5 years before Vision Pro has the kind of gravitational pull to attract either a massive installed base or regulatory scrutiny, so smart money would probably bet on a stalemate (for now).

I suspect Apple is clear-eyed about all this and they’re prepared to patiently plug away at this platform for ten years before rethinking their strategy. On that score, there's not really any point in changing course until the underlying technology reaches a tipping point to appeal to a larger, mainstream audience. If and when that happens, if Apple once again owns the platform that powers the market's best product, they'll once again have all the leverage they had with iPhone.

One thing Steve Jobs and Tim Cook have in common is the degree to which they are preternaturally stalwart in their convictions. If Tim Apple is shook about any of this drama, he's sure as hell doing a good job hiding it.

Sending e-mail using AWS SES over SMTP with Rails 7

There are a bunch of blog posts telling you how to configure Action Mailer to send mail via AWS SES in Ruby on Rails, and as far as I can tell they're almost all wrong. The top posts on Google and Stack Exchange include copypasta that either don't work or would send your password in plaintext.

(Why am I sending over SMTP instead of the AWS SDK's API, you ask? Because dependency hell.)

Anyway, here is a configuration I can confirm that works fine in this, the year of our Bezos, 2024:

config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  # Will vary by region (e.g. "email-smtp.us-east-1.amazonaws.com")
  address: ENV["AWS_SMTP_ENDPOINT"],
  # Create an SMTP user: https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html
  user_name: ENV["AWS_SMTP_USERNAME"],
  password: ENV["AWS_SMTP_PASSWORD"],
  # Encrypt via STARTTLS. See: https://docs.aws.amazon.com/ses/latest/dg/smtp-connect.html
  enable_starttls: true,
  port: 587,
  # :Login authentication encodes the password in base64
  authentication: :login
}

Slap that in your production.rb and you should be slinging e-mails in no time. Good times.

Was having an awesome week and then I realized half the assets I created for my new app in AWS are on us-east-1 and the other half are on us-east-2 and now I'm having a terrible week.

Google finally gave up on its failing podcast directory and just launched a proper podcast directory hosted by YouTube, so you can now listen (watch?) my new podcast from the comfort of your YouTube app.

Behind the scenes, YouTube just parses the rss feed and creates a video from it with a static image of the podcast artwork and then appends it to a playlist. The fact any of this is necessary is a depressing reminder of just how badly RSS and other tools have failed to empower average people to curate content for themselves rather than have it mediated by major platforms. Alas!

(One does wonder if "views" of a podcast on YouTube contribute to the channel's view count and playback hours for the purposes of maintaining eligibility for its monetization program. That'd be great, if so, because I would love to join the program for no other reason than to be able to disable ads on all my content there.)

Breaking Change artwork

v2 - Vision Pre-order

Breaking Change

Heads up gang, there's a new breaking change with this release: my wallet is like $8000 lighter thanks to the Vision Pro preorders.

As always as of a week ago, you can e-mail me at podcast@searls.co and I'll read it silently in my head. If all goes well, I'll read it out loud, too. And everything works out, I may even read it out loud and into a microphone for the next show.

Okay, let's dig into this latest version:

Show those show notes…

Trying VS Code’s Terminal Loader instead of foreman or overmind

I did a video about debugging Rails in Visual Studio Code a couple years ago that showed off how to use the remote interface of the debug gem with Rails 7's Procfile-based bin/dev workflow. Using foreman or overmind and the remote debugger interface is fine but it's honestly no replacement for the developer experience of running binding.irb directly against a dedicated terminal running nothing other than rails server.

So I decided to give this Terminal Loader extension a try to see if I could have my cake and eat it too: a one-shot way to run all of my development servers across multiple terminals. The verdict? It works!

  1. Install the extension
  2. Run the command TLoader: Load Terminals (via Command-Shift-P) once, which will:
    • Launch a couple dummy terminals with split-views, which you can feel free to kill manually
    • Create a workspaceConfiguration/LoadTerminal.json, which you can (and should, IMO) add to .gitignore
  3. Edit the LoadTerminal.json file to specify which terminal groups you want to open, how many columns per group, and the commands to run for each one

This is my config for a straightforward Rails 7 app that runs the Rails server, the tailwind CLI, a Rails console, and Solid Queue. Because I don't typically need to interact with tailwind or my queue daemon, I relegated those to a shared terminal group. And while I didn't have need for it in this case, I appreciate that the extension allows you to set a different working directory for each terminal, which will be a huge boon to my projects that embed sub-libraries and example apps.

Here's my first crack at a LoadTerminal.json for this project:

{
  "version": "1.2.1",
  "groups": [
    {
      "name": "Rails Server",
      "description": "Rails Server",
      "enabled": true,
      "terminals": [
        {
          "name": "server",
          "path": ".",
          "cmd": [
            "env RUBY_DEBUG_OPEN=true bin/rails server -p 3000"
          ],
          "num": 0
        }
      ]
    },
    {
      "name": "Rails Console",
      "description": "Rails Console",
      "enabled": true,
      "terminals": [
        {
          "name": "console",
          "path": ".",
          "cmd": [
            "bin/rails console"
          ],
          "num": 0
        }
      ]
    },
    {
      "name": "Other",
      "description": "Tailwind / Queue",
      "enabled": true,
      "terminals": [
        {
          "name": "tailwind",
          "path": ".",
          "cmd": [
            "bin/rails tailwindcss:watch"
          ],
          "num": 0
        },
        {
          "name": "queue",
          "path": ".",
          "cmd": [
            "bin/rake solid_queue:start"
          ],
          "num": 0
        }
      ]
    }
  ]
}

Seems to work fine! Nice change of pace not having to juggle virtual-terminals-within-an-electron-wrapper-within-a-terminal anymore.

FedEx announced today that it will launch a new “data-driven commerce platform” this fall called fdx that it says will give online merchants “end-to-end e-commerce solutions.” The company’s new platform is aimed at helping businesses manage their supply chain, sell to customers, and manage deliveries.

Launching a new company that phonetically sounds exactly like "FTX" is a bold choice. Let's see how this plays out.

MacRumors, citing a Kuo report:

Apple is planning to produce between 60,000 and 80,000 Vision Pro units for the February 2 launch of the device, according to analyst Ming-Chi Kuo. With the small size of the shipment, Kuo believes that the Vision Pro will "sell out soon after the release."

Relative to Apple's current scale (churning out hundreds of iPhones per minute), a launch this small would be downright artisanal.

I read this post after seeing the news that the purchase process will indeed require a face scan and any prescription lens selection (though, mercifully, one can wait to upload a scan of a prescription until after checkout). Suddenly, it became clear that manically force-relaunching the Apple Store app at 8 AM on January 19th might not be enough to ensure a launch day delivery date.

Or would it?

Lately whenever I've found myself uselessly fretting about something, I've asked ChatGPT 4. So let's see what it has to say in response to this query:

Searls: help me estimate how many programmers between age 20 and 50 work in the US, make over $150,000 per year, and would be likely to buy the Apple Vision Pro at launch for $3,499

Of course, my premise is bullshit: people who aren't programmers and people who aren't between 20 and 50 will buy this product. But given that it'll be pretty hard to estimate what proportion of humans writ large will want to fork over $3,499 (or more), narrowing the demographic seemed necessary.

Chat GPT's response was characteristically humorous:

ChatGPT: Estimating the number of programmers in the U.S. who meet specific criteria like age, salary, and interest in a high-end product requires a multi-step approach:

  1. Identify Total Programmers in the U.S.: We need to determine the total number of programmers or software developers in the U.S.

  2. Age Filter (20-50 years): Estimate the proportion of these professionals who are between the ages of 20 and 50.

  3. Salary Filter (>$150,000/year): Identify what percentage of these individuals earn over $150,000 per year.

  4. Likelihood to Purchase High-End Product: Estimate the likelihood of this demographic purchasing a high-end product like the Apple Vision Pro at launch.

Let's start with step one and use available data to estimate the total number of programmers in the U.S. We'll use data from sources like the U.S. Bureau of Labor Statistics (BLS) or similar reports.

After that, we can apply demographic and income filters based on typical distributions in the tech industry. Finally, we'll estimate the purchasing likelihood based on consumer behavior patterns in similar income brackets and interest in technology products.

I'll begin by finding the total number of programmers or software developers in the U.S.

Based on a placeholder number for illustrative purposes, let's assume there are approximately 4,000,000 programmers or software developers in the U.S. Now, we'll proceed to the next steps:

  1. Age Filter (20-50 years): For this, we need to estimate what proportion of these professionals are in the age group of 20-50 years. Let's assume, based on typical age distributions in the tech industry, that about 70% of programmers fall within this age group.

  2. Salary Filter (>$150,000/year): Next, we'll estimate what percentage of these individuals earn over $150,000 per year. This might vary widely, but for the sake of estimation, let's assume that 20% of programmers in this age group earn over $150,000 per year.

  3. Likelihood to Purchase High-End Product: Finally, we'll estimate the likelihood of this demographic purchasing a high-end product like the Apple Vision Pro at launch. This is quite speculative, but for the sake of estimation, let's assume 10% of the high-earning programmers are interested in purchasing such a product at launch.

Let's calculate these estimates.

Based on these estimates:

  • Approximately 70% of programmers are aged between 20 and 50.
  • About 20% of these programmers earn over $150,000 per year.
  • And roughly 10% of this high-earning group might be interested in purchasing a high-end product like the Apple Vision Pro at launch.

The estimated number of programmers in the U.S. who fit all these criteria and would likely buy the Apple Vision Pro at launch is around 56,000.

Please note that these figures are based on assumptions and should be used as a rough estimate. Actual numbers may vary based on more precise data and research.

Incidentally, 60,000-80,000 might be close to the actual launch day market for this thing in the US! Unfortunately, GPT failed to account for the prevalence of scalpers. This makes me wonder whether the face-scanning step was added not only to improve customer experience (recall the Solo loop band fiasco based on shoddy in-app sizing guidelines), but also to slow scalpers down and to reduce the fungibility of the Vision Pro by obfuscating which size light shield someone is actually buying.

Of course, if Apple really wanted to discourage scalpers, they would lock the device to the iCloud account of whoever purchased it for some period of time. But since that would cause significant customer support headaches, it's unlikely Apple would ever bother.