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

Spoiler alert: there's more to this…