I loved Yojimbo for many years. I still think it’s the most “Mac-like” app for taking notes and storing data. The best thing about it was that when capturing data with the hotkey, it would look at your clipboard before presenting you with a UI, and customize the UI for the data. It was fast, fit in perfectly with the Mac, and was rock-solid reliable.

But, time passed, things changed, the iPhone changed computing forever, and Yojimbo just didn’t keep up. it didn’t adopt a widescreen view, it didn’t offer iCloud sync, it didn’t have an iPhone app, it didn’t adopt the new UI widgets for the toolbar, it didn’t adopt Markdown, etc…. It still works, but it feels old and stagnate.

I’ve talked to the devs a few times, and they always give the same feedback. No future plans for an iPhone app. No plans to change anything, just to keep it running as is. So, I too started looking elsewhere.

DEVONthink

Great app, really, but holy cow is it deep and complicated. It can do so much, whenever I spend a significant amount of time using it I start to feel overwhelmed and start questioning how much I really need a single app to do everything when there are individual apps that do things better. Like the text editor, and the PDF markup. Hazel can automatically file things for you, although not based on AI, but it does a good job.

The ability to capture text and web archives is good. And if you really need deep textual analysis of your data, this is the way to go. If not, there are other alternatives.

Evernote

Did you know Evernote use to be an app that was just one long page? That might have been an early beta or something, I don’t know. Anyway, again, for capturing text and web content, it does a great job, but it’s not really Mac-like, and it’s still a bit of a roach motel for data. Also, I’ve run into weird limits on things when I really start digging in. For me, I’d rather my data stayed on my Mac in a format that I can move around. Except…

Bear

My current favorite for managing text, some images, and some captured web content. It doesn’t save web archives, but the Safari plugin will grab the text of the page you are looking at and try to extract the text to Markdown. It does a fair job. Great for storing bits of code and random pieces of information that I know I’ll need later.

Apple Notes

Rich text formatting leaves something to be desired, but syncing is solid and Notes does a good job of being a reliable place to put data. If Apple merged the best of Notes and Bear we’d have a winner. That stupid textured background always annoys me though.

Eagle Filer

A lot like Yojimbo, but it gets updated far more often and keeps data in an open format. Unfortunately it also suffers from the same drawbacks in sync and iOS companion apps. And it also looks dated to my eyes :man_shrugging:t2:.

Everything Else

Let’s not forget crowd favorite Simplenote + NVAlt, which I suppose is still a thing but I’m not sure Brett is ever going to release that updated NVAlt replacement. Then there’s Microsoft’s OneNote, which Circus Ponies blames for killing their Notebook app. If you’re into Microsoft, I guess that’s another way to go. There’s Keep It Together, which I think was renamed just “Together”, and I think abandoned. There’s StickyBrain, which became SOHO Notes, which is now Notelife… I guess? Oh, and let’s not forget the new hotness of Agenda, which combines Notes and a Calendar.

The Finder

Overwhelmed? Me too. That’s why I just went back to the Finder. I feel your pain, I really do. I’ve tried every application, method, and system out there to manage my data, and I still don’t have a perfect system. If Yojimbo was modernized and an iPhone app created, I think I’d have it, but as it is, Bare Bones just doesn’t have the motivation to work on it.

For years now I’ve wanted a simple way to encrypt or decrypt a file in macOS, so this morning I built it. This takes five to ten minutes to setup, and provides the encryption service as a right-click menu item and a pair of folders with folder actions enabled. Here’s what I did.

First, I installed the command line utility ccrypt with Homebrew: brew install ccrypt.

Next, I added a hidden config file containing my secret key in ~/.ccrypt and saved the key to 1Password.

Then, I created two new services in Automator with a single action of “Run Shell Script. The services accept files or folders in Finder, and have the “Pass input: “ setting of the Run Shell Script action set to “as arguments”. The Encrypt File service looks like this:

EXTEN="cpt"

for FILENAME in "$@"
do
	if test "${FILENAME#*$EXTEN}" != "$FILENAME"
	then
		echo "Already encrypted."
	else
		/usr/local/bin/ccencrypt -k ~/.ccrypt $FILENAME
	fi

done

And the Decrypt File service is only slightly different:

EXTEN="cpt"

for FILENAME in "$@"
do
	if test "${FILENAME#*$EXTEN}" != "$FILENAME"
	then
		/usr/local/bin/ccdecrypt -k ~/.ccrypt $FILENAME
	else
		echo "Already decrypted."
	fi

done

The first line in the script sets the EXTEN variable to “cpt”, which is what the ccrypt executable adds as a file extension when it encrypts a file. Next I setup a for loop to cycle through all of the selected files, and then do a test to see if the file being looked at already has the “cpt” extension or not. This is especially important when setting up a folder action, because when the file is encrypted it will drop in as a new file in the folder, which will then attempt to encrypt it again unless this check is preset.

After saving these two Automator services you should be able to right click on any file in the Finder and encrypt it, and then the same again to decrypt. I’ve also added the two scripts as folder actions to two folders name “Encrypted” and “Decrypted”, so if I’d rather move and encrypt the files, I can just drag and drop them on the folders.

All in all, this gives me a little more peace of mind about saving files in iCloud and syncing them between my two Macs. They won’t be available in iOS, but for the types of files I need on both machines, that’s not a problem.

I’ve been using, and subscribing to, Ulysses, Bear, and Day One for a while now. It seems a bit silly, especially since they all do basically the same thing. On the surface they are all writing apps, but once I start to think a little deeper about them I can see where the differences lay.

Ulysses

Ulysses is for writing, the act of thinking through ideas and putting them on a page. That’s what it’s designed for, and that’s what it’s best at. That’s why the first draft of my book is in here. In long-form writing and exporting text into multiple formats, Ulysses excels. Even the little features, like daily writing goals, are geared towards helping you be the best writer you can be.

Bear

Bear can do most of the things that Ulysses can do, but less elegantly. Bear can store long-form text, but that’s not what it’s designed for, it’s designed to be the notebook you keep in your back pocket. It’s a note-taking app. A storage space for bits of code, a Zettelkasten for keeping bits of information that I might need some day. There’s quite a bit of overlap between Ulysses and Bear, but the features slightly lean one way or the other, for taking notes in Bear, and writing projects in Ulysses.

Day One

This is my journal. Day One is a diary app, a place to record and reflect on where you’ve been and what you’ve done throughout the day. It’s my running journal, a record of films I’ve watched and what I thought of them. It’s my ongoing record of my life… travels and all. It’s also, recently, where I’ve started storing my daily work journal.

What I’d Lose

I suppose the reason I’m using Ulysses less is because I’m not doing quite as much long-form writing. If I got back to blogging regularly, and if I made an effort to work on my book, I’d have more time spent in this app. But, it seems like I need Bear far more often for my day job, and even this text I’m writing now is going to end up in Day One, or maybe on my blog.

If I moved my journaling into this app, I’d lose the end-to-end encryption and location recording that Day One does. Day One makes a note of the weather, the date and time, and address where you recorded the entry. I’d lose all that in moving to Ulysses.

If I moved my note-taking into Ulysses, I feel like I might lose some of the mental separation between my writing and my notes. I’d also lose Bear’s code blocks and syntax highlighting, which I use all the time. I’ve got a lot of little code snippets and command line scripts saved in Bear, and Ulysses just doesn’t capture code blocks the same way.

So, in the end, I’m sticking with the three writing apps. Their role is well-defined, they fit in my workflow, and they’ve earned my trust. I suppose that’s all I can ask for.

David and Katie are great, they really are. I’ve enjoyed MPU, like most of you have, for years. I’ve bought the books, the scanners, implemented the workflows, heck, my paperless workflow is still a derivative of David’s book. Most of all though, I’ve bought the apps. Lots of apps, and there’s a couple things to say about that.

For one, I like being part of the Mac community, always have, and I like supporting independent developers. Secondly, many times indie devs have more incentive to make their apps the best they can possibly be, and I’ve often found that the smaller, and older, the team, the higher quality the app. For example, BBEdit, MarsEdit, Keyboard Maestro, Acorn, etc…

However, there’s another aspect to this discussion. You don’t buy your way into becoming a power user. You become a power user by understanding your Mac and knowing when and where buying an app makes sense in your personal workflow. I’d argue that if you’re not writing code, BBEdit is probably not for you. If you don’t already know that having a text expansion tool will save you hours of work every year, than it probably doesn’t fit into your workflow and doesn’t make sense to buy it.

Having a ton of system modification apps running doesn’t make you a power user, but knowing which ones to run and why does. There are things macOS doesn’t do that you might find useful in a third party app, but understanding the what, why, and how is the key.

And finally, and most importantly, have fun! In the end that’s what this is all about. Get your work done, do it efficiently, and have a good time doing it.

I spent some time remodeling the old digs here, adding a fresh coat of paint in the form of a new theme, new hosting, and a shiny new SSL lock.

The new paint comes in the form of the Swiss Jekyll Theme, which I just thought looked like fun while keeping the site readable. The only configuration I did was to switch the theme color to orange, just to brighten things up a bit. And I like orange. I decided a while back that designing my own theme comes at the price of me not writing as much, because I tend to spend too much time tweaking the theme. Now, I search around and browse through twenty or thirty themes till I find a few that I like, then I download each of them and drop my content in them, run the site locally and see how my posts look. Most of the time I just go with my gut… do I feel happy when I look at the site? If not, I move on. For now, I’m happy with how this looks.

I was inspired by Jack Baty’s post on moving to Amazon to migrate my own blog over to S3 and CloudFront. I love that the SSL comes along for the ride. Although I don’t need it for anything here, at least Chrome users won’t be subject to a warning when visiting my site. I remember advocating for doing this back in 2002 in a paper I wrote for college, encrypt everything.

Apart from that, the site is still my outlet for talking about technology, design, and culture. It’s a place for me to own my words, and hopefully say something useful. Maybe, someday years from now, my kids or my grandkids will find this and have some idea of who I was, and what I stood for.

Sometimes it’s a miracle the Internet works at all. For the past week or so I’ve been unable to clone, pull from, or push to private Git repositories from either Bitbucket or Github using the normal git clone git@bitbucket.org:whatever/whatevs.git syntax. The problem had the symptoms of a blocked port or a bad network route; I’d issue the command in Terminal and wait, and wait, and wait, and the command would eventually timeout. After a quick look at the Github documentation I tried ssh -T git@github.com which also timed out and confirmed my suspicions. The ssh protocol was not getting through, but VPN and normal web traffic was.

My first thought was that the issue was probably related to my new Mediacom modem. For my wife’s sake, we recently went back to cable, and when the installer came out to the house he replaced my modem with a newer, fancier one. I don’t think I needed the upgrade, although my speed has been bumped up a bit since the new one was put in, so whatever. Along with the new modem the installer was insisting on setting up “home networking”, which is Mediacom’s way of charging you to use their crappy wireless built into the modem. I explained to the installer that not only do I not need his assistance setting up my network, but that I also have invested in a very nice Eero mesh networking setup that was far better than anything Mediacom could give me.

This resulted in a few phone calls between the installer and his supervisor. The installer informed me that he couldn’t turn off home networking or I’d be charged an additional $40 per month. That seemed ridiculous to me, but again, whatever, I asked the installer to just make sure my wireless worked the way it did before he came out. He obliged, my speed was good, and he finished setting up cable and left.

It wasn’t for a day or two that I noticed the ssh problem. It was easy enough to verify that the issue was isolated to my home network using the Instant Hotspot ability of my iPhone. I verified that ssh to my repositories still worked over cellular, and decided to get in touch with Mediacom. But, knowing what I know of them, I figured I’d better cover all my bases and also get in touch with Eero.

I thought I might need to talk to them because I have “Advanced Security” turned on in Eero Plus. This, among other things, checks outbound traffic for known malicious destinations and blocks it. I wondered if it might mistakenly be blocking my SSH traffic, but after contacting Eero support on Twitter they verified that was not the case. They did however point to what proved to be the problem. Eero advised me to contact Mediacom and make sure that the modem was in bridge mode and that we were not in a double-NAT setup. After checking my Eero’s networking settings I saw that it had a private IP address and knew that had to be the case.

Then I waited a week to get in touch with Mediacom because I figured explaining all this to tech support would be a nightmare.

Turns out, it wasn’t so bad. The first person I talked to had no idea what was going on and sent me over to “Tier 2”. Tier 2 helpfully explained that they do not offer ssh service, which I was fine with because I didn’t want to ssh to Mediacom. Then my call was disconnected while I was on hold, so I called back. The third person I talked to understood exactly what I needed. He was able to turn off the wireless networking on my modem, switch it over to be just a basic modem, reboot it, and just like that outbound ssh worked again. The first two support representatives met my expectations, the third exceeded them. I should probably have higher expectations for Mediacom, but here we are.

I’m glad to have everything working again. Not being able to clone repositories using the standard git+ssh protocol was really cramping my style. Hopefully I won’t have to change anything about this setup I’ve got now for a few more years. I suppose the next thing I look into will probably be ipv6.

Dropbox apparently saved a boatload of money by moving their infrastructure off of AWS and building out their own data centers. Taken at face value this might seem like a strike against AWS, but the way I see it this was the only way Dropbox was going to be able to differentiate themselves as a service. Their job is to provide cloud storage, something AWS can do easily, but if that’s the only thing you are getting from AWS, it’s going to cost an arm and a leg. This news once again got me thinking about the industry as a whole, my place in it, and how I think about cloud services.

If you’ve been in the technology industry for a while it’s easy to think about cloud services like AWS as just another data center. A place where you can spin up a new virtual machine and manage your server instance just like you would if you were racking hardware or using VMWare. AWS will happily let you do that, but you’ll be missing out on the advantages that thinking about the cloud as a development platform offers.

The biggest innovation from AWS is that you only ever pay for what you use. Compare this with managing a data center, where you have to purchase enough hardware to handle peak utilization for the next several years, and then watch as your investment sits mostly underutilized for most of the time. You also have to make an educated guess about expansion for the next few years. Did you buy enough storage? How about memory? Will you need to purchase more in the future? How much of an interruption will that be if you do? Cloud services take care of all of that by only providing what’s needed when you need it, as long as you take advantage of what the platform offers. 

Over the years I’ve noticed a trend towards more simplification in the systems that I build and design. In general, the fewer moving parts in a system the better. It will be more reliable, and easier to troubleshoot when something does go wrong. Unfortunately, I’ve also watched as the industry went in the opposite direction, building card houses out of frameworks and management systems barely out of their infancy. It may be that I’m jaded by my experience, or it may be that I’m just a grumpy old man, but whenever I hear about someone building out a Kubernates infrastructure to run their Docker containers in the cloud I get the suspicion that someone along the way got a case of the clevers¹. Is that necessary? Is it really?

I should specify that the fewer moving parts in my part of the systems I build the better. Amazon, Google, and Microsoft undoubtedly have several layers of gears running their underlying systems, but the trick here is that they use those same layers for thousands of customers running millions of workloads. For example, my favored system uses very small instances in an autoscaling group to automatically add and remove capacity as needed to reflect the ebb and flow of normal business traffic. If sales sends out a big promotional email, the system will recognize the increase in traffic and spin up enough instances behind the load balancer to be able to handle it. When traffic dies back down, the system terminates the additional instances. All transparently behind the scenes. The configuration for the build is simple enough, and the documentation for what each component does is straight-forward. What’s more, Amazon themselves use the same systems to build out higher level services.

Growing your instance size or changing it’s type is also a simple matter. If the base size is too small or too big, a simple adjustment to the CloudFormation template will automatically create a new instance, deploy the latest revision to the application to it, and shut down the old one. Building on the massive scale of AWS, it’s virtually guaranteed that you’ll never run out of resources. Also, unlike hardware in a data center, Amazon’s instances tend to get both faster and less expensive with each new release. Simply upgrading your instance type can save time and money.

For a lot of business out there that aren’t Dropbox, AWS can provide you a path to simplification of your infrastructure where you can build up secure, scaleable, and cost effective environment. If this sounds appealing, but you need someone to handle the complexity for you, get in touch, maybe we should talk.

I’ve heard several people on podcasts or blog posts claim that they’d like to see Apple hold off on new features that nobody wants and just fix the existing bugs in the Mac. This claim is normally followed up with a missive that they can’t imagine what Apple could add to the Mac at this point anyway, since macOS is a stable, mature operating system. Well, I can think of a few things.

Let’s start with the Mac’s management of information. There is, supposedly, artificial intelligence baked into the Mac in the form of Siri, an AI assistant that is supposed to be able to answer questions and perform basic tasks. Basic, as in “far too basic”. I’ve yet to find a way that the AI actually helps me get anything done. Siri has hooks into all of the built-in apps that manage my information: Notes, Contacts, Reminders, Calendar, Mail, Spotlight, and the file system, but doesn’t help me find relevant information unless I specifically ask her for it. What if Siri could suggest additionally relevant information with a simple swipe of the trackpad? The “Today” view in the Mac’s right-hand sidebar would be a perfect place to show relevant files, folders, emails, contacts, notes, or tasks based on textual analysis and AI.

If you have an email selected in Mail, you could swipe over from the right and see a list of other information related to that email. Likewise if you select an event in Calendar, or a Note, etc… Eagle-eyed readers will most likely note the similarities between my suggestion and the fantastic DEVONthink. That’s no accident. I’ve felt for a long time that the AI at the core of DEVONthink would be spectacular if built into macOS. In DEVONthink, selecting a file and clicking on their little top hat icon will show you a list of related documents and suggest an appropriate group, or folder, for the document. I’d like to see the Mac sherlock that bit of functionality and expand it to the entire system.

Speaking of things that should be system-wide, how about tags? I suggest the next version of macOS come with the ability to tag everything. Let’s put tags in notes, todos, calendar events, contacts… the entire suite of productivity apps built into the Mac. The whole shebang, as they say. And, to be clear, let’s make sure they are the same tags, not siloed tags unique per application. That wouldn’t be nearly as useful in the big macOS data soup.

Next, you know how Apple bought the iOS app “Workflow”? How about we stop messing around and ship Hazel as a built-in part of the Mac. It already fits right in, running invisibly in the background and acting on rules set in the preference pane. Of course, if Apple bought it we could put rules for everything in Hazel. We could have Hazel triggering rules not just for files and folders, but for Mail, Calendar, Reminders… are you getting it?

Finally, let’s build in real security into every part of the Mac. I suggest private key encryption for everything before it is sync’d off of the machine. Transmitting files over SSL is fine. Storing files on the server on an encrypted disk is also fine. However, the files themselves are not encrypted, which means (as I understand it) that if the iCloud server is running the files are available. The encryption on the server just means that if someone tried to run off with the hard drive they couldn’t get into it. That’s why you can get to them from the web. Your login to icloud.com does not unencrypt the files, it simply allows you access to them. End-to-end private key encryption would be the next step that Apple could take to ensure that their customer’s information is safe and secure, even when transmitted across the Internet.

The purpose of a computer is to be a bicycle for the mind, a way to not only manage information, but help you make better decisions, cook better meals, make better deals, build better software, write better papers. Whatever you do, a computer should seamlessly help you do it better, and get out of your way to let you do it.

If the Mac is the pickup truck, or SUV, of the computing world, and the heaviness of macOS is what lets iOS stay light, then my suggestion is to lean into that philosophy and make the Mac the absolute best tool for managing information. A professional grade tool for professional daily use. And, obviously, since this is us, do it with style.

The work of systems administration, that is, racking new hardware, running cables, and loading operating systems, is quickly becoming eclipsed by devops. Servers come from the factory ready to rack, and the base operating system has become nearly meaningless in the context of running applications thanks to Docker. All you need is a baseline Linux install, the specifics of what each application needs to run are taken care of inside the Docker container.

If you are running your workloads in the cloud¹, the need for a dedicated sysadmin is even more redundant², since both the hardware and the base operating system are outsourced to AWS, Microsoft, or Google. However, bridging the gap between deploying applications to production and writing the application code sits devops, which for the past several years has been a fantastic opportunity for sysadmins to branch out into new and interesting ways. That opportunity is not going to last forever though. The core tasks of a devops engineer are repeatable, and the current complexity that devops now handles is moving more and more towards simplification.

In devops, there is a starting point, a set of tasks, and a specific end goal to achieve. Primarily, a devops engineer will take code from a repository and build out the systems to test and deploy that code to production in a secure, scaleable environment. That’s what I do anyway. History tells us that any repeatable, programmable task will be automated by a machine sooner or later, and I think we are starting to see what those new machines will look like.

Jason Kottke posted a link to Chess.com earlier today about how Google’s AlphaZero AI became the best chess player in history in four hours. It wasn’t loaded with a chess program, the AI taught itself how to play, and became unbeatable. Putting Skynet theories temporarily aside, how big of a step is it from there to automating devops? An AI could be trained on Github, given AWS or GAE as a deployment ground, and given an end goal of each application up and running.

Programmer friends who I floated this idea to in the past had mixed replies. Some claimed that the AI necessary to do this would be beyond anything currently in our capabilities. Others said that it might be possible. I think the writing on the wall is clear. It is possible, and I imagine it’s only a matter of time before the big three cloud providers each deploy their own version of automatic code deployment. It won’t look like much from outside, the only configuration they’ll need is access to your repository, and the AI will build up everything else necessary.

The models exist, the artificial intelligence exists, and the need for the service exists. DevOps is a career path with an expiration date. If that date is 10, 20, or 30 years down the road, I can’t tell, but it’s closer than any of us working in the industry would care to consider.

I’ve been enjoying watching the new iPad commercial of a kid and her iPad roaming around the city. Two things come to mind. First, is this what it’s like for kids in the city? Having never lived in one myself I find it fascinating that she just roams around, takes the bus, hangs out in an alley, whatever. Second, and more important, is what she’s doing with that iPad.

The first time we see her with the iPad she’s chatting with a friend over FaceTime, snaps a screenshot, and draws on it. She shows the screenshot to her friend, then sends a copy of it over Messages. Next she’s in an alley with a bunch of furniture, sitting in a seat and twisted to her left to type on the iPad keyboard. She notices a praying mantis on a leaf next to her and quickly snaps a photo, dropping that picture into what looks like a Pages document about bugs in the city. We see her typing in a bakery, drawing in a tree, and reading a comic on the bus. Finally, she’s laying in the grass in her backyard typing again, and when her neighbor asks her what she’s doing on her computer, she replies “what’s a computer?”

We’ll put to the side the ridiculousness of that question, as we the viewer are supposed to assume that the next generation is going to grow up using the tablet form factor and will have no idea what a classic desktop computer is. It’s a stretch, but ok. The commercial calls back to a previous iPad video that shows people working in different ways in different occupations using an iPad Pro. In the previous video they use the camera to capture and analyze athletic performance, they type and draw, share building schematics, and use the iPad in place of printed technical manuals. Both commercials point to the type of lifestyle and work-style that Apple believes the iPad is best suited for.

In no video does it show a developer sitting at his desk for eight hours a day starting at the screen and trying his level best to edit code, ssh into servers, and manage his git repositories. All things that are technically possible on an iPad Pro, but not better than they are on a Mac. A few months ago I bought an iPad Pro, Smart Keyboard, and Pencil and attempted to work only using it. The experience was very similar to using a laptop. The screen was small, and I wound up hunched over my desk for several hours a day struggling through tasks that were second nature on the Mac. Before my two-weeks were up, I wound up returning the iPad and getting my money back. I bought a 27” iMac instead, and it’s been fantastic.

However, the experience made me think about what kind of work I do and how I don’t want to get stuck in the past while the world moves on around me. There’s a thin line between waiting for the technology to mature to the point where you can use it without stress, and growing stagnant. There is a fairly good chance that many new developers in the next ten years might not have worked on anything but an iPad, depending on if they got one issued to them in school or not. I want to be able to move to the new technology when it’s ready for me, but judging when it’s ready might not be something I can do objectively, but I think we can lay some ground rules.

The iPad needs to be able to connect to an external monitor and trackpad.

Yes, I can hear the “but it’s a touch interface” objections from here. To answer that I’d like to point at the current iOS feature to 3D press on the keyboard to move the cursor in a text field. Like Jason Snell has argued, they’ve already given us a mouse-like interface, why not take it all the way? It’s probably healthier to move around all day like the kid in the video, but there are a whole lot of us who have a desk they sit at every day, and the iPad is simply poorly ergonomically designed for long periods of work.

The iPad needs to be able to run a full suite of Unix tools.

So much of my development work happens in Terminal.app. For example, in one of our applications we need to run a Django app that uses a ssh tunnel to a MySQL server, and then be able to load the Django site by browsing to localhost on a particular port. One could argue that if that’s the kind of work you are doing, you should just use a Mac. I’d argue that loosening of the iPad restrictions just a bit would open the device up to an entirely new class of user. They don’t need to give full access to the Unix underpinnings of iOS to provide a Unix development environment, they could chroot the user in a sandbox. It’s technically possible, but not currently possible.

The iPad needs a local and remote backup solution.

I worry about my data. Too much, obviously. My Mac runs the classic 3-2-1 backup system (three copies of your data, two local, one remote). iCloud backup could work, but a local Time Machine would be even better. Being able to restore just one file to what it was an hour ago is, at times, priceless. I’d say we are probably closest to having this, depending on the app you are using, but a system-wide, effortless, file-level backup and recovery system would be fantastic.¹

I may be able to switch to an iPad before all these three things happen, but it would be so cumbersome and difficult that my work would suffer as a result.

What I don’t want to do is jump on the “it’s not a real computer” bandwagon. That’s the same argument that was used against Macs for years, back when my Mac was the only one in the company outside of design. The Mac was derided for years as an expensive toy by IT departments and PC enthusiasts. They were wrong then, and those saying it’s impossible to get any real work done on an iPad now are wrong. What I’m saying is that for now, it’s impractical for me to use an iPad for every day work, but I don’t think it’ll stay that way forever. For now, there simply is no alternative to the command line to do what I do. In the future, that might not be the case.

I’ve found it interesting to look at how work was done before computers became commonplace. Writers used typewriters, which served as the models for how computers first evolved, but I think the more interesting occupation to look at is that of an architect working at a drafting table or a drawing board. They might have done some sketching or taken down some ideas in a notebook, but the real work happened with an expansive canvas in an environment that was conducive to long periods of uninterrupted work.

The iPad Pro right now is a professional notebook. I’m waiting for it to be a drafting table, something similar to the Microsoft Surface Studio, but without the suck.