Yes, it isn't

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

And before you knew it…

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):

But wait, there's more…

If you have any Rails models that define a custom table_name AND you load fixtures in your test database, then you're probably going to have a bad time. Maybe you're here from Google. If so, hi, hello! You're in the right place.

Here's the model I just ran into this issue with:

# app/models/build/program.rb
module Build
  class Program < ApplicationRecord
    self.table_name = "build_programs"
  end
end

You'll never guess what happens next…

As the post-launch hype has cooled, the Apple-watcher zeitgeist has started to turn against the platform—some are even bold enough to invoke the word "failure".

(Aside: if Apple considers Vision Pro a failure, it's not because of sluggish sales figures or a weak App Store lineup. It was clear from the jump that Apple is committed to a ten year roadmap for this thing, regardless what you or your favorite Youtuber thinks. Burback's video was hilarious, though.)

I've been using Apple Vision Pro for no purpose other than Mac Virtual Display for 4-8 hours a day, 7 days a week, since it launched on February 2nd. Meanwhile, my brand-spankin'-new M2 Ultra-equipped Mac Studio and 32" 6K monitor are collecting dust. More than that, I'm getting more done than at any point in my career. So I figured I'd share the Good News with y'all, in case it might sway anyone sitting on the fence into giving Vision Pro a shot.

First, I'll explain why my productivity shot through the roof once I strapped a computer to my face. Then, I'll show why such an expensive device is no more an irresponsible use of funds than other "Pro"-tier equipment in the Apple ecosystem.

And then what happened?…