My Setup

Over the years I have dialed in my writing process. I started typing posts in a textbox on Zoomshare; nowadays, I write in a powerful text editor, track changes with version control software, keep redundant backups, and serve this site with a back-end I wrote myself. I have set myself up well with a pretty neat workflow, and today I want to share it with you.

My Devices #

At home, I write on a late 2013 15" Retina MacBook Pro. Although Apple updated this line a few times after I bought mine, I have no reason to get a new one. I write, code, and build 3D models on it without a problem. The battery lasts long enough for hours of work away from my desk. I plan to upgrade someday, but see no reason to anytime soon. Those in the market for a new computer ought to consider that: how many six year old PCs still work today, and out of those, how many still run well? My DELL laptops used to have a thirty-six month life cycle. I have little interest in the Mac vs PC debate anymore, but I will say that the longer lifespan of an Apple computer makes the annual cost of owning one much lower, and means you will have a well-functioning device for much longer than you would a PC.

Away from home, I create on my iPhone. For the last year or so before I stopped writing, an iPad also played an important role in this process. I used the same workflow there that I use on my iPhone today, which I talk about below, to create almost everything I posted. I liked that setup: its simplicity and portability, and the focus it imposed, worked well for me. Since then iPads have become much more powerful, so I can’t wait to revisit this soon.

My Editors #

Recall that I write in plain text, formatted in Markdown, and that I proof everything before I post it. On my home computer, I prefer Sublime Text. Cross-platform, fast, and feature-rich, I use this editor to write the articles that appear here, and the code that generates the site behind the scenes. It does everything I ask of it so well, it feels like a tool purpose-built for the job at hand — every single time. I cannot recommend this editor enough.

Before I post, I proof everything with a program of my own design. I once used Marked 2 for this, but grew out of the app, so I created Proofer. Proofer takes a much more granular look at flaws in my writing, generates more statistics, and creates a live preview using my blog’s exact layout. This program has become an indispensable tool in my writing toolkit, so I made it available over on my projects page for anyone who wants to check it out.

On my phone, I love Drafts for capturing notes and article ideas. Its fast, simple interface makes that easy. I just open it and write. Most of the time I turn those tidbits into new posts on my computer, but every once in a while, I use Editorial to create articles or edit ones I already have in the works. This app can access, edit, and save plain text files to the Dropbox account synced with my home computer, so I move my work from Drafts to this app before I spend any time developing it. Working in Editorial means I have a local copy and a versioned cloud backup through Dropbox in case something goes wrong, and gives me access to a host of helpful Markdown automation tools. Drafts’ sister app, Terminology, also comes in handy whenever I write in the go. Together, these three make it easy to capture new ideas, and streamlines their development into the articles you see here.

My Backups #

I spend a lot of time, energy, and effort writing, so I cannot abide the thought of losing anything. To lower that risk, I use a tiered backup scheme. This means everything I write exists in at least two places at all times; by the end of each day, that number goes up to six. I have four different off-site backups, one on-site copy on a local external drive, and the original on my local machine. Thanks to some neat automation work, none of this takes more than a few minutes.

Dropbox #

Dropbox does not count as a backup. In brief, at the free tier it stores deleted files for just thirty days, and it propagates all changes — even mass file deletions or corruptions — in real time. With that said, it can still fill an important niche as part of a broader backup scheme. By monitoring your files and sending changes to the cloud in real time, Dropbox enables short-term recovery should you spill a drink on your computer, for example, or want to reexamine a first draft of a document up to thirty days later. This service does a great job of covering the gap between the permanent backups below.

Version Control #

I use version control for all my coding projects, and for writing, too. In the software world, this allows many developers to work on a single project at once. Anyone can change a file, add a note, and then send it to a central server where his or her colleagues will see the change. Every time I hit a milestone while writing, I add a note, then commit it to private repositories on GitHub and Bitbucket. This accomplishes two things: it gives me two off-site backups, and lets me view older versions of an article anytime I want to. These repositories will also store every version of my files, even if I delete them, as long as GitHub and Bitbucket stay online. I rest easier at night knowing I can recover everything I have ever written, no matter what happens.

It does not take much to annotate and commit a changed file, and Ire Aderinokun makes it even easier with some helpful aliases. I took this a step further with my GitBackup project, which monitors a target directory for changes and then commits the new files with a generic message. I can still choose to do milestone-based versioning, but GitBackup turns these version control servers into a second real-time backup to two more off-site locations — like Dropbox, but without Dropbox’s time-based limitations.

Backblaze #

Version control backs up my files on a per-project basis; Dropbox covers more of my system by monitoring an entire directory, but Backblaze tracks every single file on my computer. I pay $5 a month, and the company keeps a copy of my entire machine on their servers. Due to the volume of files it has to process, Backblaze catches changes about an hour after I make them. Thanks to Dropbox and version control, though, I can live with that gap. This service brings the number of off-site copies of my data up to four.

Time Machine #

I also use Time Machine. Time Machine backs up everything to a local drive in my house. Although this will not save me from a fire, for example, I can use it to recover files if something happens to my computer anywhere else. Including this, my data exists in four off-site locations, one on-site drive, and on my home computer. Since everything except my local backup runs 24/7, I just have to plug one USB cable in once a day; in exchange, I get a comprehensive, overlapping backup schema that ensures I can recover my most important files no matter what happens, all for the low price of $5 per month.

My Site #

We have gone over the devices I use, the editors I write in, and the backups that keep it all safe; now I want to focus on this site. I have not talked about First Crack in a long time. Over on my projects page, I explain that I no longer publish updates to the source code, but hope to start again someday. That day has not yet come, but as I continue making major changes to the system, know that it will soon.

For those unfamiliar, I created First Crack in 2012. Powerful engines like WordPress and Joomla had dominated the space, but I had no use for the majority of their features. I wanted a lightweight blogging engine that would take plain text files formatted in Markdown, and turn them into a simple and fast static blog. Nothing fit the bill, though, so I created something that did. First Crack will turn a thousand articles into a fast and full-featured site like this one in less than two seconds. I take a lot of pride in this project and the progress I have made over the last seven years. Again, I will start publishing the source code soon.

Once First Crack builds the site, the Firebase CLI handles everything else. I can preview my site on any device in my local network with firebase serve, and then make it public with firebase deploy. It’s that simple. Look for a more in-depth article on this soon.

I also use tmux. I have three Terminal windows open on a normal day: one to commit changes to First Crack, a second for managing version control as I write, and a third for miscellaneous tasks while I work. tmux adds panes to a single Terminal window, all with their own bash process. In practice, this lets me take three windows and condense them into a single one. Crafting the command to create that environment took a bit of work, but I figured it out. Now I store it in my .bash_profile file, which creates this environment every time I type in the letter t. The snippet below shows a more complex, five pane interface I used for an old development and writing environment:

This gave me a five pane Terminal window, started the Node.js server, and checked the git repositories for changes to First Crack, the site’s content, and the Proofer and GitBackup code bases. From there I can start working. It also helped to turn on tmux’s mouse mode, and create a second alias to turn everything off: alias kt=“tmux kill-server”. I also find it helpful to have TeamViewer Host installed, just in case I need GUI access to my server.

Together these systems, programs, and services give me the ability to write anywhere without worry of losing my work, and manage this site from any machine with a shell. I can start working on my phone, finish an article on my home computer, and then use my phone to post it on the road. Whatever I want to do, I can with this setup. I have put a lot of work into it in over the years, and I believe I have created something to be proud of.