The Weibo user explained that the ‌iPad Pro‌'s new matte display option will be offered in addition to the standard, glossy glass finish. It apparently features -4° to +29° of haze and may tout some kind of blue-light blocking technology to help protect the eyes. Matte screen protectors for the iPad have become popular, so it is possible that Apple is trying to offer such an option at the point of purchase for those who want it.

I wonder what this means for display performance in direct Florida sunshine, as the current iPad lineup is worthless outdoors here.

Faking time is a frequent topic of conversation in software testing, both because the current time & date influence how many programs should behave and because reading a real system clock can expose edge cases that make tests less reliable (e.g. starting a build just before midnight on New Year's Eve may see assertions fail with respect to what year it is).

I've approached this issue a dozen different ways over the years, and there are a number of tools and practices promoted in every tech stack. Rubyists often lean on the timecop gem and Active Support's TimeHelpers module to manipulate Ruby's time during testing. Regardless, no tool-based solution is robust enough to cover every case: unless the operating system, the language runtime, the database, and every third-party service agree on what time it is, your app is likely to behave unexpectedly.

Okay, I'm interested…

Apple is in discussions with Google to integrate its Gemini AI engine into the iPhone as part of iOS 18, according to Bloomberg's Mark Gurman.

Through iOS 5, Maps and YouTube were native apps that Apple built and which were backed by Google services. This was advantageous for both parties at first. Apple wasn't nearly ready to roll out its own mapping service and Google was more focused on growing YouTube's reach than monetizing it. Eventually, it stopped making sense for either party, and they went their separate ways.

The primary media narratives about this focused on Steve Jobs' "thermonuclear" threat over Android's copying of the iOS UI and the degree to which the two companies had begun to compete on services. But one thing that was lost in the discussion—which never really squared with the fact Google has continued to pay Apple tens of billions a year to be Safari's default search engine—was that both companies maintain relatively-tenuous moats to lock in customers.

Right now, Google needs people to reach for its AI and search stack before a generation of users learn to "GPT it", and Apple needs an AI stack for its platform that can compete with the dozens of devices set to launch that are little more than thin candy shells on top of OpenAI's API.

I really hate the idea of this deal, and I bet executives at both companies do, too. Which is why it's so unfortunate that it also makes sense.

[UPDATE: Since publishing, I've simplified these instructions and reduced the latency in bringing up the screenshot tool by about half.]

[UPDATE 2: If you're on macOS 14.4 Sonoma and you want to avoid "Operation Not Permitted" errors, there's no sure-fire way to avoid them whether you set this up via Shortcuts or Automator, so I'd recommend using Keyboard Maestro instead.]

macOS ships with a pretty rad Screenshot app, except that one thing about it totally sucks: it can be configured to either copy screenshots to the clipboard or save them to files, but not both.

Well, I finally got off my ass and cooked up a way to have my save and copy it, too. Read on if you're interested.

Keep reading…

Gripping story, overall, and worth a read. This bit stuck out to me as something I'd never considered before, but felt obvious as soon as I was exposed to it:

Political communicators are sticking to approaches developed for an era when ticket-splitters and swing voters composed a sizeable chunk of the electorate. But with a body politic that has sorted into two highly polarized parties—with just one-tenth of voters torn between them—the logic of persuading voters to support a candidate has grown obsolete. Ad campaigns should instead promote the Democratic Party itself, Malchow proposes, particularly at moments when news events might help it win new adherents, such as after a mass shooting, which thrusts gun-control policy back into the news and voters might be ready to reconsider their allegiances.

To wit: in an era of extreme party polarization, 90% of people in the US are voting based on party affiliation, but campaign advertising is still centered on candidate choice. This isn't just inefficient, it's counter-productive, since most candidates run away from their parties in general elections because both parties' brands are so toxic. Focusing money and messaging on bolstering a party's brand seems like a much smarter way to meet this moment of overwhelmingly party-line voting.

I can only hope I'll still have meaningful insights to offer others during my final week on earth.

My Twitter account had been peacefully lying dormant since November 18th, 2022, but so many people are still using X that I finally caved a few weeks ago and spent 45 minutes wiring up a syndication strategy, effectively adding it to this site's POSSE.

If you want to do this, here's what you'll need:

• The azu/rss-to-twitter GitHub Action and a modest amount of a free account's budget
• A Twitter developer account and app
• An Atom feed to read from (here's mine, specially crafted to cram the full content of each tweet in the <title> of each <entry>)
• The handle you're posting as must be marked as an automated account and registered as managed by some other account

Once you have all that, you can define a YAML file defining the action in your GitHub repo like the one for this site:

# .github/workflows/rss_to_twitter.yml
name: rss-to-twitter
on:
  schedule:
    - cron: "*/30 * * * *"
  workflow_dispatch:
jobs:
  twitter:
    runs-on: ubuntu-latest
    steps:
      - uses: azu/rss-to-twitter@v1
        with:
          RSS_URL: "https://justin.searls.co/shorter-form.xml"
          TWEET_TEMPLATE: '%title%'
          TWITTER_APIKEY: ${{ secrets.TWITTER_APIKEY }}
          TWITTER_APIKEY_SECRET: ${{ secrets.TWITTER_APIKEY_SECRET }}
          TWITTER_ACCESS_TOKEN: ${{ secrets.TWITTER_ACCESS_TOKEN }}
          TWITTER_ACCESS_TOKEN_SECRET: ${{ secrets.TWITTER_ACCESS_TOKEN_SECRET }}

The above cron schedule translates to checking the Atom feed "every 30 minutes", which is more frequent than it needs to be in my case. And as for all those ${{ secrets… }} directives, here's how to configure your repository's GitHub Action secrets.

And that's it. Easy!