- RSS Channel Showcase 8081916
- RSS Channel Showcase 1128726
- RSS Channel Showcase 7182734
- RSS Channel Showcase 5889204
- 05/02/18--00:00: A Native Art Gallery for Your Mac (Take 2)
- 07/25/18--03:32: eGPU Redux: Sticking a GTX 1080 in an AKiTiO Thunder2
- 09/03/18--14:56: Good Spirits: Syncing Data Statelessly
The challenge: fit a rotating art gallery somewhere into my life.
I love visual art and find it hugely inspiring. Unfortunately, reading art books is too much of a context switch to be a regular distraction, while museums are only appropriate for the occasional excursion. Instagram helps, but it only lets you see content from artists you follow. There’s still the 99% of art history beyond that sliver!
Sourcing art wasn’t the problem. For years, I had been keeping a fairly large folder of inspiring images from places such as Imgur albums, RuTracker museum collections, /r/ImaginaryNetwork, and /r/museum. But leafing through them wasn’t enough: I needed to put them into a regular and random rotation in a place that was just out of eyeshot, but without becoming an overt distraction.
In 2015, I finally solved the problem by building an app called Backgroundifier, which converted arbitrary-size images into wallpapers by superimposing them onto attractive, blurred backgrounds. By pairing an Automator Folder Action with the native wallpaper cycling functionality of macOS, I could now drop arbitrary images into a directory on my desktop and have them automatically show up in my wallpaper rotation. Peeking at an image was as simple as invoking the Show Desktop shortcut, and if I wanted to see something new, all I had to do was switch to a new Space.
For the past few years, this scheme had been working fine. But recently, my collection had grown to over 500 images, and I found myself bumping into some slight annoyances. For example, I had no way to retrieve the filename of the current wallpaper, to remove an image from rotation, or to mark it as a favorite. Every maintenance task had to be performed manually.
Finally, I decided to build a menu bar app that would solve all my problems through a unified interface: BackgroundifierBuddy.Continue Reading...
It’s been a year and a half since I wrote my article on building a hassle-free Thunderbolt 2 eGPU for my late-2013 15” Macbook Pro. In all this time—with the caveat that I was exclusively using an external monitor through Bootcamp—I’ve had essentially zero issues with the setup. Booting would occasionally require one or two attempts to hear the Mac chime, but once you were in, performance was flawless. The GTX 1050 Ti was quite an excellent little card.
However, my power requirements recently changed. When the Oculus Rift went on sale for $350, I just couldn’t resist picking one up. VR was new to me and I wasn’t sure if this was something that would stick, but my first experience with Beat Saber and The Climb left me in awe. This was, very clearly, a new category of human experience that was being offered for just a few hundred bucks! Unfortunately, latecy was now an issue with some of the higher-caliber games such as Batman: Arkham VR, and 60–90fps was essentially a hard requirement for VR immersion. Together with the fact that many newer titles were starting to see poor performance even at lower settings and resolutions, I decided to explore upgrade options.
Until recently, I had my eye on the single-fan EVGA GTX 1060 SC to eventually replace my 1050 Ti, since the dimensions were very similar. But in doing this round of research, I was surprised to discover that Gigabyte offered an actual, full-fledged GTX 1080 in almost the same form factor! Though slightly too tall to fit, the card was just the right length for my AKiTiO case, meaning that I could simply take the top off and pop it in without having to do any metal-bending.Continue Reading...
Following my CRDT explorations earlier this year, I wanted to build an app on top of a persistence layer that adopted the same kinds of resilient sync patterns, even if it didn’t use the actual low-level “ORDT” data structures described in the article. Having used a spreadsheet to track my drinking over the past few years, a dedicated drink tracking app seemed like the perfect little project.
The main problem I was aiming to solve was architectural. Many apps establish rather unclear relationships between the main app, the persistent store, and the cloud. Does the local database or the cloud count as the primary store? When a change comes down from the UI layer, how does it eventually get synced to the local database and to other devices, and what code keeps track of all this state? Which system does the cloud talk to? How is offline mode dealt with? How do critical errors percolate through this pipework? And what does the in-memory cache have to say about all of this? A common result is that the data layer becomes a monstrous thing that deals with persistence, sync, caching, reachability changes, UI notifications, and many other systems, all at once.
The reason for this mess, in my mind, is state. Sync often relies on systems catching every change and remembering their exact place in the whole process. If an update falls through the cracks, the data has a high chance of desyncing. Naturally, this leads to monoliths that try to claim ownership over every last bit of data.
Ergo, my goal was to get rid of as much state as possible.Continue Reading...