humancode.us

Lego George Lucas and $4.05B

July 4, 2023

A fictitious rendering of a Lego Star Wars set called “George Lucas with 4.05 Billion Dollars”, featuring a George Lucas minifig lying on top of a vast ocean of green 1x2 plates with currency print.

This is actually a great way to illustrate how much a billion dollars actually is!

According to Bricklink, a 1×2 Lego tile weighs 0.26 g. If each tile represents a dollar, this set would contain four billion tiles, clocking in at over one million kilograms. Delivering this number of bricks would require 49 standard cargo containers (each nominally rated at 21,600 kg).

Even if each tile represents $100, the largest denomination that US paper money comes in, we would still end up with more than 40 million tiles, weighing more than ten tons. Imagine holding a tiny Lego tile that you can sell for $100, and looking up to see that you have ten tons of it stored in a warehouse. That’s how much $4B is worth.

A billion dollars is an incredibly, mind-blowingly vast sum of wealth for one person to own today; an amount so huge that most people don’t really comprehend how large it is.

And once you realize how much $4B actually is, realize that Bill Gates has 29 times that amount, and Elon Musk has 62 times that amount.

How to Survive a Crisis

June 16, 2023

At some point in your life, you will encounter a crisis. Something so alarming will happen that affects you, your work, or your loved ones, that it leaves no space in your brain for processing anything else. When I find myself in one of those situations, I find that these principles help me navigate the situation.

Read more…

Embrace Hyrum’s Law

May 26, 2023

If you’re a library or service developer, be keenly aware of Hyrum’s Law, which states:

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Your primary job is to deliver a feature, not an API. The API is merely a way to deliver that feature. Breaking your feature breaks your client’s product, even when the change strictly adheres to the API.

Consider every change across the API boundary (except maybe adding new API) a potentially breaking change. Have a communication channel to tell (known) clients about your upcoming change. Invite clients to test your change with you. If deploying to a service, watch your deployment, and revert it at the first sign of trouble.

With a popular enough API, there will be clients you haven’t heard of that depend on your implementation. Give yourself way more time than you think to roll out your changes.

All about xcframeworks

May 19, 2023

You may have heard about xcframeworks and how they are a way to distribute libraries on Apple platforms. But documentation on the format is hard to come by. With this blog post I hope to summarize everything you need to know about xcframeworks and put it all in one place for your reference.

This section provides a rationale for the existence of xcframeworks. Feel free to skip it if you’re not interested.

Before xcframeworks were defined, there was no Apple-supported way to distribute libraries for more than one platform at a time. This wasn’t really a problem for a while, since the only Apple platform a developer could build a framework for was OS X. Even when the Mac switched from PowerPC to Intel, the single-framework model survived because it was possible to create Universal “fat” binaries that contained more than one architecture slice. Since a framework would still target a single platform, including a Universal binary worked quite well.

When Xcode began supporting frameworks for the iPhone SDK, the picture became more complicated, since developers had to deal with two new platforms: iPhoneOS and iPhone Simulator. Developers could ship two frameworks—one for each platform—but it was not easy to consume two distinct frameworks in a project that should be easily built for both iPhone hardware and the simulator. While build-settings tricks could be employed to switch FRAMEWORK_SEARCH_PATHS depending on the build platform, the lack of automatic support in Xcode for doing so made it a difficult chore.

One workaround that some developers adopted was to use the lipo tool to splice an arm64 slice from the iOS build of the framework, together with an x86_64 slice from the Simulator build, and distribute a single “Frankenframework” that could be used to build both a device binary and a Simulator binary, without build-settings shenanigans. This hack conflates architecture with platform but it worked…

…until the M1 Mac came along. Since the M1 Mac natively used the arm64 architecture, both iPhone hardware and Simulator builds consumed the arm64 architecture; developers could no longer use architecture as a proxy for platform. Add to that the proliferation of platforms—tvOS and watchOS and their simulators—and it was clear that a better solution was needed.

Apple defined the xcframework format as a way to cut through this chaos. This officially-supported specification allowed developers to distribute the same library built for a variety of platforms and architectures in a single package. Projects that consumed an xcframework needed only specify a single link dependency, and Xcode would switch between platforms and architectures automatically. The xcframework specification is future-proofed enough to accommodate new platforms or architectures Apple might support in the future.

An xcframework is a library distribution bundle

To be precise, an xcframework is a universal, binary, library distribution format. Let’s break that description down in reverse order.

An xcframework is a library distribution format. Each xcframework holds exactly one library. A library is a precompiled collection of code that can be consumed by another project to create an executable (or app).

An xcframework is a binary distribution format. That means it does not include source code in its distribution. Only built binaries and interface specifications (headers and/or Swift interface files) are included.

An xcframework is a universal distribution format. That means it holds libraries and interfaces for different platforms as well as processor architectures in the same structure. A single xcframework can, for example, offer the same library for consumption for iOS, watchOS, and Mac projects using either Intel or ARM architectures.

Finally, an xcframework is a bundle because it’s a directory with a well-defined content structure and file extension, and has an Info.plist file in its root. Examining its Info.plist file shows that it has a CFBundlePackageType of XFWK.

Read more…

Phase-detection autofocus is a bit sloppy

May 13, 2023

Today I learned that phase-detection autofocus is fast and accurate, but not precise—the resulting focus when you hit that AF button is a tiny bit sloppy. When that AF beep is heard, your focus will be ever so slightly front or back of the actual focus point. I’ve even seen evidence on my lenses that that where you left your focusing ring the last time affects whether the next autofocus is front- or back-focused.

This means that you should never simply take the first number that Automatic AF Fine Tune gives you. Instead, take a dozen or more readings and average them out to get a feel for your lens’s focus bias, then manually adjust the fine-tune setting. Take a few photos of a sharp, stationary target, and pixel-peep until you get the setting about right. If you’re like me, you’ll get three super sharp shots out of four, with the last one just a bit soft. Here are my takeaways when using phase-detect autofocus:

  1. When shooting with wide aperture, take a bunch of shots, and hit that AF button each time. Remember, phase-detect AF is probabilistic in nature.

  2. DoF is your friend. Stop down that aperture a bit more to give yourself the best chance of getting your subject in sharp focus.

  3. Don’t bother with AF Fine Tune unless you notice that your shots are consistently back- or front-focused. Most lenses hover around 0 bias out the door unless they’ve been abused.

  4. When shooting a still subject with a tripod, use Live View to focus using contrast-detection. It’s much slower, but it will never misfocus. Alternatively, use manual focus and Focus Peaking.

  5. Don’t pixel-peep too much. As long as your photo looks pretty good on a 2 MP screen, it’s probably good enough. With cameras pushing 48 MP+, even the most insignificant misfocus will look awful at 100% magnification.