My Favorite Technical Hacks

Hacks are simple shortcuts that increase productivity. They can be inelegant, but they solve a problem quickly. Hacks may be brittle, solving a problem under specific conditions, or they can require a few extra steps to realize the effective solution. An ideal hack is an innovation or design pattern that works so well it becomes a feature. My favorite non-technical hack (life hack) is one I use after hunting for a parking spot when they're scarce. In the past, I've parked my car and rushed off to my destination without paying attention to where I parked. This has happened to me a couple time in La Jolla and Pacific Beach. So, one life hack I use to remember where I've parked is to open up the Maps app on my iPhone and take a screen shot as soon as I am parked.

I've come across a few computer hacks that stick out in my mind. Computer hacks are harder to explain than life hacks because one has to have an interest in software engineering. But, here goes...

1. Preventing JPG "Theft"

Java was the hot new language when I first started working at Apple. In order to get up to speed I coded as much Java as I could, especially applets since that seemed to be the future of the Web. (It turns out that Java became everything Ada wanted to be, and JavaScript became everything that Java applets wanted to be.)

One area that I focused on was coming up with a way to prevent JPG images from being "stolen" from a webpage. Once an image is displayed on a screen (computer, smartphone, etc), there's no simple way to keep someone from taking a screen shot. My Java applet solution got around this by taking the thumbnail of the image and blowing it up to the full size image so that it was pixelated (blurry). Then, as the user moused over the image in the applet, a small portion would come into focus. This allowed the user to see the entire image at full resolution, but only in parts (one-sixteenth, to be exact). While it was possible to take 16 screen shots and piece them together into a single, full resolution image, that was far from practical.

The full size image was encrypted on the web server to keep a user from downloading it directly from the server. The encrypted image was then sent to the user's web browser and decrypted in pieces, while in memory, inside the client's applet as they moused over the image. 

2. Facebook encrypted UDP

Awhile back, I heard about a brilliantly simple trick that Facebook uses to speed up their site. When a Facebook user logs into their account, their data is fetched from a database. While fetching the data, the user has to wait. The amount of wait time could be imperceptible to the user, or it could be a noticeably long time if the website is under a heavy load. "Heavy load" is a relative term, but Facebook serves more than two billion active users per month, so saving any amount of time makes a noticeable difference at that scale.

Wouldn't it be great if Facebook's servers knew what data a user needed before the user formally requested it? Well, that's effectively what Facebook's done with their little trick that simply involves sending an encrypted UDP (datagram) ahead of the formal TCP/IP request. UDP requests are fire-and-forget, meaning there's a small chance they might not arrive at their destination, but, if they do arrive (and they usually do) then they'll reach Facebook's servers sooner than a TCP/IP request. There's more overhead with TCP/IP since it guarantees delivery (or notice of a failed delivery). TCP/IP is the reason that webpages render perfectly compared to the BBS's of the 1980s that used unreliable dial-up modems where static and interference would be misinterpreted as data and displayed as garbled text.

So, the UDP datagram arrives ahead of the TCP/IP request which enables Facebook's servers to pre-fetch the data and load it in its cache before the formal TCP/IP request arrives. This hack is a simple, yet elegant, way to optimize a website for speed simply by "priming the pump."

3. Safari DNS and Pre-loading

DNS: Safari speeds up webpage load times by looking at all the host names on a webpage, once it's loaded, and then performing a DNS lookup. This saves time, later, when a user clicks on a link since the DNS lookup has already been completed. The time savings might go unnoticed or it can save a few seconds. (There's even an HTML tag to help DNS prefetching.)

Pre-loading: Although I haven't read about this hack, I noticed it when I was monitoring my web server's logs in real-time. As I started typing my own domain name in Safari it came up with an autocomplete suggestion before I finished typing. At the exact moment that the autocomplete suggestion came up in Safari, I noticed an http request for that autocomplete suggestion hitting my web server and showing up in my web server logs. In other words, Safari was loading a webpage before I hit enter. There's not much harm in doing this even if I never formally requested that URL. This is why some webpages load in a flash, especially when I'm on a fast Internet connection and the web server is using a content deliver network (CDN) like Akamai or CloudFront.

4. Keeping iOS Apps Running in the Background

For nearly four years I lead the San Diego Kickstarter Meetup where I mentored entrepreneurs on crowdfunding their products. (At one point, we had six live crowdfunding campaigns.) A couple of the entrepreneurs had iOS apps that accompanied their product which needed to continue running in the background; but iOS doesn't like to keep an app running in the background because it drains the battery. One of the most interesting hacks to keep an app running in the background was to simply play a silent MP3 file which kept the app "alive," even when it was in the background. The downside was that you couldn't play music from another app, but for some situations that was fine. 

5. Timestamping Race Photos

In the late 1990s, I started going to races (5Ks, 10Ks, marathons, etc), snapping race photos at the finish line, and then selling them either at the race or online. The challenge was finding a runner's photo among thousands – bib numbers had to be entered manually, which would take many hours. I came up with a solution that worked great which, to my surprise, no other race photography had implemented. (Nowadays, RFID chips attached to the racer's running shoes solves this problem.)

My solution was to simply synchronize the time on my digital camera to the race clock where midnight (00:00 on a 24 hour clock) was the start of the race. If a runner finished a race in 23 minutes and 30 seconds then they could simply start looking for their race photo around 00:23:15 (23 minutes and 15 seconds after midnight) since the photos were taken about ten seconds before the runner crossed the finish line.

Not all hacking is bad. 🖥