Late last year, I got a Sonos setup for my living room. I chose the Premium Immersive Set, which includes:

• Arc Soundbar
• 2 × One SL rear surrounds
• Their third-generation Subwoofer

I cannot overstate how great this system sounds. Surely better can be had, but Sonos makes everything so simple. Furthermore, their ability to pipe audio from anywhere to anywhere makes AirPlay 2 look positively barbaric by comparison. Truly. I say this as a person who makes a living talking about how much I love Apple.

Sonos has a couple of really useful features when you’re watching television.

• Night Sound: At lower volumes, quiet sounds will be enhanced and loud sounds will be suppressed
• Speech Enhancement: Increases the volume of speech

These features are super great for nighttime viewing, particularly when your living room is directly below your son’s bedroom. Together, the Sonos will tone down the loud booms that are most likely to wake him up, but also bring up the relative volume of speech, so we don’t need to rely on subtitles.

As great as this is, I never remember to turn them off; instead, I attempt to watch TV the following day — often to watch a guided workout with music behind it — and wonder why everything sounds so wonky. Though it only takes a couple seconds to pop open the app and turn off Night Sound & Speech Enhancement, it gets old when you do it every day. There must be a way to automate switching these off, right?

One of the great things about being a nerd developer is that you can pretty quickly put together a few tools to make something happen. Last night, I figured I’d start digging into the Sonos API and see if I could whip something up. Thankfully, after only a few minutes down that path, I realized there must be something futher up the stack that I could use.

Enter SoCo-CLI, which is a command-line front-end to SoCo. SoCo-CLI allows you to do a stunning amount of things with your Sonos system via the command-line.

For me, I needed to do two things, both of which are easily accomplished using SoCo-CLI. Note that my system is called Living Room, but SoCo-CLI is smart enough to match my speaker name by prefix only — Liv is automatically parsed to mean Living Room. With that in mind:

I needed to turn off speech enhancement:
sonos Liv dialogue_mode off

I needed to turn off night sound:
sonos Liv night off

I can also combine these into one command in SoCo-CLI:

sonos Liv dialogue_mode off : Liv night off

Now I just needed to run this overnight every night. I turned to my trusty Raspberry Pi, which is in my house and always on. I added a new line to my crontab:

0 3 * * * /home/pi/.local/bin/sonos Liv dialogue_mode off : Liv night off

Now, every night at 3 AM, my Raspberry Pi will ask the Sonos to turn off both night sound & speech enhancement. I never have to worry about remembering again, and my workouts in the morning will no longer sound off.

🤘🏻

Today I joined Allison Sheridan on her podcast Chit Chat Across the Pond. On this epsiode, we discuss our many and varied home automations. Many of which — particularly for me — are utterly bananas. Most especially, my oft-derided-but-darnit-it-works-for-me garage door opener notification system.

I really really enjoy using Shortcuts, but I feel like I’m a complete novice. Discussing Shortcuts — and automations in general — gives me tons of inspiration for myself. Allison provided plenty of those examples.

This episode comes in well under an hour, but it packs a lot into not a lot of time.

Every podcast is, to some degree, a pet project. I’ve hosted some, and guested on many. This guest appearance was something else entirely.

Martin Feld is a PhD student at the University of Wollongong, and is doing his thesis on podcasting, RSS, and more. As part of his thesis, he’s hosting a podcast, which he cleverly named Really Specific Stories.

Really Specific Stories is an interview show, where Martin deftly asks his guests about their origin stories, how they got into podcasting, their relationship with the open internet, and more.

On this episode, Martin and I walked through my path into podcasting, starting all the way — and I’m not kidding — from when I was a toddler. It was a fun discussion, and I’m honored that Martin asked me to be a part of the project.

I’m also in the company of a ton of amazing guests; do check out the other episodes as well.

Despite being willing to go to my grave defending °F for the use of ambient air temperatures, America gets basically all other units wrong. Inches/miles, pounds, miles per hour, etc. All silly. We should be all-in on metric… except °C. I don’t care how air feels outside; I care how I feel outside.

Anyway.

Americans will generally write dates in MM/dd/yy format; as I write this, today is 11/14/22. This is dumb. We go broad measure → specific measure → vague measure. The way Europeans do it — dd/MM/yy makes far more sense. You go on a journey from the most-specific to the most-vague: day → month → year.

For general-purpose use, I prefer the European way; today is 14/11/22.

Yes, I know that 8601 is a thing, and if I’m using dates as part of a filename, I’ll switch to 2022-11-14. Same with database tables, etc. But in most day-to-day use cases, the year is contextually obvious, and it’s the current year. So, for the purposes of macOS’s user interface, I set it to dd/MM/yy.

Prior to Ventura, you could go into System Preferences, move little bubbles around, and make completely custom date/time formats. With the switch from System Preferences to System Settings, that screen was cut. So, there’s no user interface for making custom formats anymore.

I asked about this on Twitter, and got a couple of pretty good answers. One, from Alex Griffiths, pointed me to a useful and helpful thread at Apple. The other, from Andreas Hartl, pointed me to another useful and helpful thread at Reddit. Between the two of them, I was able to accomplish what I wanted, via the command line.

Apple has four “uses” that roughly correspond to the length of the date string when it’s presented. As expected, they use ICU format characters to define the strings and store them. They’re stored in a dictionary in a plist that’s buried in ~/Library, but using the command line it’s easy to modify it; we’ll get to that in a moment.

Here’s where I landed so far:

In order to store these in the appropriate plist, you need to issue four commands. Each has the same format:

defaults write -g AppleICUDateFormatStrings -dict-add {Key} "{Format}"

For example:

 defaults write -g AppleICUDateFormatStrings -dict-add 1 "dd/MM/yy"

Once you complete this, you can go into System Settings → General → Language & Region. In there, you’ll note the Date Format drop-down appears to be blank, but the non-interactive sample should show what you’d expect:

I hope Apple brings back the user interface for this, but at least there’s a way to hack around it.

By happenstance, I feel like I’ve been on a new-dad tour lately. Last month, I spoke with Max shortly before he became a Dad. Today, I was the guest on, believe it or not, iPad Pros podcast. We spoke about iPads a tiny bit, but instead, mostly discussed what it’s like to be a new Dad. Tim, the host of the show, became a Dad just a short time before we recorded; this was a surprise to both of us, as the thought was to have this conversation before baby showed up. Sometimes life has other plans. 😊

I am far from a perfect Dad; I can name a thousand ways in which I need to do better. However, I like to think I am honest with what I get right, and also what I get wrong. Particularly on Analog(ue), but also in other avenues like this website, I try to truthful and not sugar-coat.

To have both Tim and Max ask me to join them on their bespoke “Dad” episodes is a tremendous honor. It’s also funny that this coming Saturday is the eight-year anniversary of me being a Dad in the first place. 😄

This week is, it seems, iPad week. Certainly, that’s all we discussed on this week’s episode of Clockwise. I joined my friends Kathy Campbell, Dan Moren, and Jason Snell to discuss all things iPad.

After wondering about how squishy the middle of the iPad lineup is, we grumbled a bit about the lack of fun colors for pros, compared notes about Apple Pencil, and discussed our preferences for or against cellular iPads.

It’s always a blast to hang out with those three. 🥰 Whether or not you’re an iPad superfan, I think our mutual admiration comes through.

Generally speaking, I don’t care for doing podcasts with video. Often, I don’t feel like video adds too much. Worse, for audio-only listeners, video allows me to make reference to things that only those watching can understand. More than anything else, though, my home office is usually a wreck, and embarrassing to have on camera. 🙃

A month or two back, David Lewis asked me to join him for an episode of his podcast, and do so on video. Initially, I told him “No video! No way!”. However, in a fortuitious turn of events, I had just cleaned my office for Relay FM’s Feuding Families, so I told David “let’s do it”.

Available both as a podcast, and on YouTube, David and I spoke about my history as both a developer and podcaster. We discussed what it’s like to build an app from idea to launch, how and why some apps are successful and some aren’t, and more.

As David said to me privately when we were done recording, whenever you do an interview with someone — irrespective of what side of the table you’re on — it’s always a bit of an unknown. Perhaps you’ll get along great with the other person, or perhaps it’ll be like pulling teeth. Chatting with David was, for me anyway, really fun. I think you’ll hear (or see!) that in the conversation. 😊

Most podcasters joke that there are two primary rules of podcasting:

• Don’t discuss politics
• Don’t discuss parenting

Today, I broke the second rule, and spent 90 minutes talking parenting with my friend Max Roberts on his Max Frequency Podcast.

Max is just a few short weeks away from becoming a dad for the first time, and naturally, had some questions. Though my advice is probably surely garbage, it was fun to be compelled to relive the time when Declan was brand-new.

On the episode, we couldn’t help but discuss Apple’s new announcements a little bit. However, this episode is predominantly me trying to do the impossible: help someone about to have their first child understand what they’re in for. Hopefully my advice was more useful and actionable than “sleep now, while you still can”.

When one is “in the trenches” parenting, it can occasionally be difficult to remember why you’re here. To remember all the work you put in to have a child. This conversation with Max was a really great reminder that even though kids can drive you nuts, they’re an incredible gift. No matter how challenging they can be, every single child is a miracle.

Some of my friends just sent their first-born off to college; others are soon-to-be empty-nesters. To relive the infant stage with Max was a fun way to remind myself that not only can it be worse 😆, but that every stage is a gift.

Accessibility, on the surface, seems like it’s affordances for people that don’t have normal bodies. That’s a very immature and ignorant view, and one that’s patently wrong. It’s also the opinion I’m ashamed to admit I held as a younger man. As with many things, it took a clarifying, first-hand, experience to help me realize how wrong I was. It only takes one experience trying to read things on your phone with your eyes dilated to realize accessibility is for everyone. If not today, then tomorrow.

With that in mind, I was really excited when my pal Shelly Brisbin asked me to join her and Robin Christopherson on her accessibility-focused podcast, Parallel. On the epidose, we discussed this month’s Apple announcements, with a bent toward accessibility. Speaking with someone who is low-vision, and someone who is blind, is absolutely fascinating. In this one-hour conversation, I learned a ton about how those with true vision challenges navigate not only their world, but their devices, too.

Yesterday, Apple announced the iPhone 14 and iPhone 14 Pro. While they added a lot, like satellite connectivity for emergencies, a much improved camera sensor on the 14 Pro, and crash detection.

However, they also took away. From the iPhone 14 Pro specs page:

iPhone 14 Pro and iPhone 14 Pro Max are not compatible with physical SIM cards.

Hm.

My iPhone 13 Pro currently has a physical SIM in it, and though I’d assume Apple would have a plan for upgrades like this, you never really know. This is also complicated because I buy phones unlocked; I wonder if the upgrade path is a little squishier when you’re not replacing an existing device with one locked to your same carrier.

So, in order to hopefully get ahead of the game for next week, I decided to try to convert my physical SIM to an eSIM. As it turns out, this process wasn’t particularly difficult, but I figured it’d be worth documenting for others.

The instructions below will only be useful for my carrier, Verizon Wireless.

First, make sure you’re on both the cellular and Wi-Fi networks, as there is a chance you’ll need to fall back to Wi-Fi at some point during the process.

Next, log into your account. I did all of this on my Mac; I can’t speak for how it’d work on either mobile web or the app.

Once you’re logged in, find your phone, and click Manage device.

On your device page, scroll down and find this section:

Click Activate a SIM.

At this point, Verizon knew that I had a 13 Pro, and offered for me to use one of the onboard eSIMs:

Naturally, I clicked Use my IPHONE 13 PRO's eSIM [sic].

At this point, I was punted to an instructions page, which I didn’t really need to bother with. The rest of the process happened on the phone. I didn’t think to take screenshots of this, unfortunately.

On my phone:

1. Open Settings
2. Right at the top, I noticed a line that said something like Finish Setting up Cellular, which I tapped.
3. At that point I basically followed a wizard that completed the setup

A couple things worth noting:

It took a few minutes for the activation to complete, on a random Thursday morning, before everyone in the world is trying to upgrade their iPhones. I’d estimate maybe 3 minutes?

🚨 BE CAREFUL 🚨

After I did my transfer, I noticed that iMessages were suddenly being sent and received as text messages. This may have been user error on my part, but it seems that my iMessage settings were altered such that my phone number was no longer a valid iMessage address for me.

If you do the above, it’s probably worth verifying your settings. To do so:

1. Open Settings.
2. Scroll down and tap Messages.
3. Tap Send & Receive.
4. Verify your phone number is checked. In my case, my email address was checked, but my phone number was not.
5. If it isn’t checked, tap your phone number to check it.

It’ll take a minute or so, and then iMessages should start coming back in.

After posting, Leon Cowle reached out via Twitter to provide instructions that seem to have worked for him on AT&T.