I downloaded the most current release of Visual Studio Code (the app receives updates monthly) and then installed a few specific extensions to make my drafting process easier: Perform the usual Ubuntu security-hardening steps, and voila. Good to go. It took roughly 10 minutes to fine-tune the GitLab installation after the droplet was set up.
And if you don’t like running your own GitLab server, the free GitHub ecosystem works just as well.
Using GitLab in a browser offers a great solution for people who write during downtime at work but they cannot visit certain websites or install applications on work-based computers.
Less tech-savvy collaborators may simply use the built-in Web editor to work, without having to download or install or configure anything. This approach is significant because I can add new users to my GitLab environment with permissions to participate in one or more projects as collaborators, without having to email Word documents back-and-forth. I use DO to host this website, and the domain name, so I mapped the new droplet to a subdomain.
I’m paying $10/month for the DO droplet (a droplet is a virtual server, in this case, an implementation of Ubuntu Linux that already has GitLab CE configured on it, so I didn’t have to do any tedious manual installations).
GitLab CE is a free, open-sourced platform for storing and sharing computer code, with enhancements designed to make the code-writing job easier. The Setup ProcessĪfter initial testing seemed favorable, I created a DigitalOcean droplet with a one-click install of GitLab Community Edition. I’ll share how I set up this environment in the context of a book I’m writing about healthcare data analytics, and then why I think plain-text writing with version control makes more sense for complex writing projects. I’m now far enough into the process to have decided that I’m migrating all of my writing out of Scrivener and into my new infrastructure. And because VS Code does a great job of working with the git system, I implemented more robust version-control discipline on my text documents. Until recently, that is-for now Microsoft’s Visual Studio Code allows for multi-pane windows, even in distraction-free mode. I know multiple simultaneous buffers have always worked well in Emacs or whatnot, but my willingness to learn Emacs or Vim syntax remains too weak to justify the technical debt of mastering these systems just to write. So VS Code, which is much simpler, fills me with joy. (Usually after dark, in an unlit room, working with an amber-on-chocolate color scheme, with soft music playing and either the windows open to the breeze or a fire roaring in the fireplace.) Over the years, I’ve played with different approaches to writing in Markdown and AsciiDoc with a dedicated text editor, but these efforts haven’t proven satisfactory because the apps tend to take a single window and full-screen it, cutting me off from my notes.
My preferred approach to writing is to enter a full-screen, distraction-free mode. I hate it, though, because Scrivener’s full-screen editor is abysmal-the worst “distraction-free” implementation I’ve ever seen in any app that supports this feature-and because Scrivener projects are essentially a giant cluster of Rich Text Format files named by number and stored in a byzantine file-tree structure, separating me from my work by requiring the application to mediate my content. Scrivener supports many different compile settings, so exporting content is never a challenge.
I love it because it offers excellent outlining and note-taking features, plus it integrates with programs like Scapple for mind-mapping and Aeon Timeline 2 for timeline management. I’ve long enjoyed a love-hate relationship with Scrivener, the all-in-one writing platform for novels, short stories, textbooks and other written endeavors.