This is a copy of the Searls of Wisdom newsletter delivered to subscribers on May 1, 2024.

We kicked April off right around here with a stay at the new Evermore resort's Conrad hotel, which saw fit to include yet another upscale tiki bar in a part of town that contains an order of magnitude more tiki bars than thai restaurants. And five times more tiki bars than pharmacies. Roughly as many tiki bars as schools, judging by a quick search. Anyway, here's me drinking an Oaxaca Colada out of a ceramic conch shell:

Not too much to report this month that I didn't already cover on my web site, as I was mostly heads-down writing software.

Oh, by the way, to all the folks who kindly wrote in to express sympathy about the back pain that I documented here last month: thank you. It was entirely uncalled for (as in, I did not call for it), but I appreciate the sentiment. For what it's worth, I got in to see my physical therapist and she patiently listened to me ramble about the dozen theories I'd been crafting before simply asking, "are you doing the hamstring stretches I showed you two years ago?" At which point, I melted into a pile of humiliated goo and slid away, escaping under the door.

Anyway, stretching my hamstrings every day is helping a lot. God, I hate doing them, though.

April was also defined by the various preparations needed for what's shaping up to be another epic Japan trip. (Incidentally, this is also what consumed a good chunk of last April.) After going to RubyKaigi as a foreign correspondent for Test Double, I've decided to return in a slightly more low-key fashion. Oh, and this time Becky's joining me!

After the conference, I'm hoping to spend a couple weeks wandering heretofore unexplored (by me) regions of the country on a solo language-learning and research expedition. To assist in documenting all the places I'll go, I added a mapping feature to my site that I call Spots.

As I check items off my packing list, I re-installed and logged into several of the apps I use whenever I'm in Japan. Switching my phone to my Japanese Apple ID for this purpose has become something of an annual ritual of mild frustration that nevertheless leaves me ponderous. Why does everyday life in Japan require a full home screen of only-available-in-the-Japanese-App-Store apps? And if we were to compare them to their counterparts in the West, what might they teach us?

When I first signed up for a study abroad program nearly 20 years ago, it was in large part because Japan seemed like such a radical departure from my upbringing in the states. When I took an elective on post-war Japanese industrial design, I was repeatedly awestruck by the number of tools and appliances that solved common problems in ways I hadn't seen before. That so many things are designed and produced independently in Japan made me realize how many facets of life I'd assumed to be constant were in fact variable. Knobs that twisted left when they "should" have twisted right. The tea kettle whose fully-concealed cord resulted in my not realizing it was electric and subsequently melting it over my gas range. The countless bathtub drains whose basic operation escaped me, leading to my checking out from more than one hotel with a tub full of water. But one thing I hadn't bargained for was the degree to which this profound differentness would also apply to Japanese software design.

Japan produces a lot of software intended primarily (if not exclusively) for domestic consumption. For almost every major function of our lives that's mediated by a popular app, it's likely some other app you've never heard of dominates the same market in Japan. The fact these apps often emerged in relative isolation provides a sort of natural experiment, offering us the opportunity to question features we thought were essential and appreciate alternate approaches we might not have arrived at ourselves.

In case it might whet your appetite for exploring these differences, today I'm going to give a quick run-down of a few of my favorite Japanese apps below.

Spoiler alert: there's more to this…

I've been using the new MacBook Air since it launched last month and I'd been thinking about writing a full review of what it's like to live with it, but I'm lazy so I'll just piggy-back on Paul Thurrott's glowing review of the 15" model with the following modifications that only apply to the 13" version.

Additional review notes:

• Its screen is 2" less than 15"
• Its speakers are somewhat worse than the 15"
• Contrary to Paul's review, the microphone array held up surprisingly well in my testing—especially with Voice Isolation activated—and were far superior to the mics on the AirPods Pro 2
• At 2.7 pounds, the 13" M3 MacBook Air is 35% heavier than the discontinued 12" MacBook, a model that was originally released in 2015

Despite 9 years of technological advancement, Apple has regressed significantly on the only metric I care about in a portable computer: weight. Considering that the ARM transition was meant to provide significantly more thermal headroom and enable the design of new form factors, the fact that Apple was able to ship a 2-pound MacBook with a retina screen and Intel chip in 2015 but has thus far failed to ship an M-series Mac that weighs less than 2.7 pounds is simply bewildering.

Everything else about the computer is great.

Searls Score: 2.7 / 10

John Hawthorn, a brilliant Rubyist and contributor of quite a lot of important open source in the Ruby ecosystem references a benchmark for a gem that lets you invoke the Crystal programming language from Ruby.

I'll spoil the post here by giving you the before and after.

Before:

The "crystalized" version runs about 4x faster than the pure Ruby version.

After:

Now it's Ruby that's 5 times faster than Crystal!!! And 20x faster than our original version.

Writing a program that behaves the way you want is hard, but that's not the end of the journey. Without an understanding of how the computer will execute your instructions, you're left at the mercy of a bunch of arbitrary performance implications that can lead to misguided beliefs emerging within teams and organizations.

A common refrain in recent years is, "we're rewriting all our critical sections of Ruby into Rust." Closer inspection by an expert almost always finds flaws in the assumptions (or, if there are any, analyses) that lead to these whole-cloth "optimizations", however.

I've seen organizations try to pull off pretty much every approach you can think of to escape performance problems and technical debt. The more dramatic the maneuver—like, say, bifurcating one's codebase into two languages and then bridging them—the more likely it is to fail to accomplish the stated goal or to fail outright.

Trust me when I say it's almost always better to dance with the one who brought you. Embracing the problem usually leads to better solutions than running from it.

This week, I've been working on a new multimedia mode for the blog that I call Spots, which are essentially map pins of places I visit.

Rather than merely list all of my Spot posts one-at-a-time as reverse-chronological posts, I also wanted to make a single interactive map that aggregated all my annotations in one place so that readers could explore them spatially. Because I'm a tool for all things Apple, I decided to use the MapKit JS framework they introduced in 2018 for the job.

All told, it was actually pretty easy to get up-and-running and the documentation (while sparse) told me what I needed to do to get a map rendered, centered, and loaded with annotations.

One thing the docs didn't tell me however, was how to let users make a map full screen, and the reason the docs don't mention it is because framework doesn't support it. And that's quite a bummer when your layout's maximum width is as narrow as it is on this humble blog.

So this morning, I figured out a way to hack together a full-screen button that aped the Maps UI's look-and-feel for MapKit JS. Since it's an odd omission, I figured it might be useful to somebody out there if I did a quick show-and-tell on how I did it.

Here's what the button does, before and after clicking it:

Interested? Well, here's what the recipe calls for:

1. An absolute-positioned div inside the parent element of the map, styled to look like a button and with a couple full-screen zoom icons from Tailwind's excellent Heroicons project
2. A click handler that that toggles a bunch of Tailwind classes to switch the map's parent div between its regular and fixed full-screen display (also swapping the button icon)
3. A keyup handler that listens for escape key and—if any maps are full-screened—will exit full screen. This felt necessary while I was testing, because the shrink button can be an awful far distance for one's mouse to travel

Let's dive in and find out…

This is going to be a niche one, but maybe somebody will Google for this someday.

This morning, I figured out a relatively low-effort way to export my visited restaurants (行ったお店) in Tabelog and then decorate them with latitude and longitude as well as translations of each restaurant's name and summary.

There are basically three steps:

1. Gather each page of your visited restaurants using JavaScript in the console
2. Export them to a JSON file
3. In a Ruby script, update the JSON for each restaurant, adding:
   1. Latitude and longitude
   2. English translations of its name and summary

But wait, there's more…

In a post on X (formerly Twitter), Kosutami explained that Apple has stopped production of FineWoven accessories due to its poor durability

Sorry cows, your skin is simply too good to not wrap our metal devices in.

The company may move to another non-leather material for its premium accessories in the future.

On second thought, it's very unlikely Apple would ever go back to leather. My guess is FineWoven quietly disappears and isn't immediately replaced with another "premium" material in 2024.

Yesterday, Zuck got on stage to announce Meta's ChatGPT killer, Llama 3, apparently making this bold claim:

Meta says that Llama 3 outperforms competing models of its class on key benchmarks and that it's better across the board at tasks like coding

Coding? You sure about that?

I've been pairing with ChatGPT (using GPT-4) every day for the last few months and it is demonstrably terrible 80% of the time, but 20% of the time it saves me an hour of headaches, so I put up with it anyway. Nevertheless, my experience with Llama 2 was so miserable, I figured Zuck's claim about Llama 3 outperforming GPT-4 was bullshit, so I put it to the test this morning.

TLDR: I asked three questions and Llama 3 whiffed. Badly.

Question 1

Here's the first question I asked, pondering a less messy way to generate URL paths (secretly knowing how hard this is, given that Rails models and controllers are intentionally decoupled):

And then what happened?…