Archive for November 16, 2022

Wednesday, November 16, 2022 [Tweets] [Favorites]

Xcode 14 Unintentionally Increases App Size

Max Topolsky and Josh Cohenzadeh (Hacker News):

Shortly after Xcode 14’s release, a number of iOS apps saw significant size increases. We first tweeted about observing a large spike in the Zillow iOS app. Zillow was not an isolated example.

[…]

The simple explanation is that bitcode optimizes production builds, partly by stripping binary symbols. Without bitcode turned on, Xcode build settings have to be changed to strip binary symbols.

So when Xcode 14 removed bitcode, a lot of apps lost that implicit build setting.

Previously:

Entropy of Big Distributed Systems

Gergely Orosz:

Scoop from within Twitter: small things are breaking, not enough engineers to fix them.

[…]

This is exactly what you’d expect when a large part of the workforce is laid off, another chunk quits, and those left are expected to ship new features as the #1 priority.

Hector Martin:

All large services and platforms are “built to be resilient”. But they are also extremely complicated, with countless internal interactions between microservices, configuration systems, load balancing and directing subsystems, networking fabrics, and more.

These systems are built to be reliable in the face of things like machine failures, or entire optional microservices going down. That’s not what will take Twitter down. Twitter will crash and burn when a complex interaction between systems goes wrong and causes a cascade failure.

[…]

People think of servers as things you can just reboot and be fine. That’s not how this works. If you rebooted every single $FAANG server simultaneously right now, all of $FAANG would be down for probably months. Or worse. And that’s with functional teams. This stuff is hard.

Dan Luu:

One thing that’s been interesting about recent events is seeing how people imagine big companies operate, e.g., people saying that Twitter is uniquely bad for not having a good cold boot procedure.

Multiple $1T companies didn’t or don’t have a real cold boot procedure.

Jon Luke:

In a complex system like Twitter or AWS, there is always a trade-off between doing failure automation work up front and incurring operational burden later on. It’s a decreasing ROI, and trying to automatically handle every possible failure case just isn’t worth it.

[…]

Yes, of course you try to threat model all possible failure modes. But then you only handle the 95% or so known/expected cases and don’t bother with the 5% unknown/rare cases. For those, you just throw smart humans at the problem once it arises.

Failures that seem only theoretical in a smaller system, like bit flips from cosmic rays, suddenly become very very real once you’re dealing with millions of servers and millions of rps. At that scale, you have to assume these things will happen.

[…]

The culture at AWS, for example, was hyper-aware from the beginning of circular dependencies and the need to cold boot, and it was always a big topic in any Principal-level design or operational readiness review.

Jaana Dogan:

Many executives fail to understand why tech companies are bloated. They are bloated because everything is held together with duck tape and “task force” teams. And it’s due to gross lack of funding when it comes to removing complexity and technical debt.

Eric Frohnhoefer:

Frankly we should probably prioritize some big rewrites to combat 10+ years of tech debt and make a call on deleting features aggressively.

Joshua Koudys:

Leave something poorly architected, and it can give you a hundred easy-to-fix issues a month. You fix those, you have great velocity, everyone celebrates the 10x engineer. Fix the fundamental problem, you get 1 ticket closed, they fire the low-velocity engineer.

Steve Streza:

Strongly recommend going to see the list of apps you rely on Twitter for single sign-on.

If Twitter burns to the ground, which looks increasingly likely, these are the apps that you used Twitter to log in to. Set up email backups on those accounts ASAP.

Previously:

Command Bars

Maggie Appleton (via Dan Grover):

Command bars are command-line bars that pop up in the middle of the screen when you hit a certain keyboard shortcut.

[…]

Rather than remembering which sub-sub-sub menu a function lives in, users need only remember its name.

They don’t even have to remember its exact name. Fuzzy search can help them find it by simply typing in similar names or related keywords.

I’ve long used LaunchBar as a universal command bar, but now some of the productivity apps that I use daily have their own versions with app-specific commands. In BBEdit, it’s Go ‣ Command… (Command-Shift-U). In Tower, it’s File ‣ Quick Actions (Command-Shift-A). And macOS adds a built-in command searcher to each app’s Help menu (Command-?). Part of the appeal is discovering new commands or quickly locating infrequently used ones, but I also find it useful for commonly used commands in an app where the convenient keyboard shortcuts are already in use.

Weathergraph 1.0.129

Tomas Kafka:

Open the full screen view to see six days at once. Press and hold the chart to read the exact conditions. Swipe down to close.

I like being able to see much farther ahead with the new full screen view. It’s also great that I can enter the mode with a button tap rather than having to toggle Rotation Lock, then rotate my phone, and then toggle Rotation Lock again when I’m done.

Weathergraph:

Weather service response time for Foreca vs. @Apple Weather. Apple seems to occasionally take up to 20 s to respond.

Previously: