justin․searls․co

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!

To be continued…

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.