# Wandering Autumn

Exploring change and the life that comes with it

# The Power of Simple

October 19, 2016

My first website was on Geocities. It was back in the halcyon days of the Internet, when no one really knew what the web was for, but it was fun spending time on it. As a result, personal webpages were an eclectic mess of people just trying different things.1

I don’t even remember how I edited it. It might have been an editor in-line—not WYSIWYG, like today’s blogs have, but just a plaintext editor—or using Notepad or something like that, manually uploading files.

It was entirely bespoke, and incredibly manual.

As I moved on to slightly-more-robust hosting, the heavily-bespoke method prevailed. Due to my inability to use vim, I would often edit the file on my local machine then FTP it up and see what it looked like. At least I migrated to tools like Notepad++ eventually, but it was still a huge manual effort. It helped when I figured out how to get my FTP client to monitor a directory and upload changes, but it was still slow going.

Slowly, though, my server copies would slowly get unsynchronized from my local copies. I might upload an image from somewhere else. Or toss up a text file for someone.

And if I ever accidentally deleted something, it was gone forever.

Source control changed my life. Even more was capistrano, and figuring out how to run nginx on my local machine. Finally! I could write PHP locally, and then when it was ready, I could just cap deploy and it would all work!

…except, not so much.

Though I enjoy developing software, I didn’t work on my websites every night. Sometimes I would go a long time before working again. So I would forget the dozen manual steps I needed to do to get nginx up and running such that it could serve PHP. And it was still an imperfect replica of my actual host, especially since PHP is…finicky at best.

As for capistrano, it was extreme overkill. Certainly, it’s a fantastic tool for people doing large-scale deployments, especially if they’re reasonably complex in terms of process management, and also server control. For some guy writing up a personal website, it was like trying to hammer in a nail with a jackhammer. It took way too long to set up, and way too long to build and deploy everything. Its difficulty was enough friction to dissuade me from working on things very often.

Both of these paths felt untenable: manual everything, and overkill deployment.

Then I met Travis.

My first introduction to make was in my halcyon days as a programmer, when I first started playing with CircleMUD.2 I was following the instructions and typed it into Cygwin, but I had no real idea what I was doing—a fact that became all the more apparent when I got errors that seemed particularly arcane to my callow self.

As I left behind those projects and went to college, it just never really came up. I either had an IDE do to the hard work for me, or I manually ran gcc. For my compilers class, our professor provided one for the compiler we were building, but I didn’t particularly understand what I was doing with it.3 It was just an arcane tool, like so many tools.

I would encounter make again at AT&T, when I found a stable team. It was a little less arcane this time around: I figured out how to modify a makefile to change the targets enough to do what I wanted. Though the standard makefile template we had on the team had an entire section at the bottom marked BLACK MAGIC - DO NOT MODIFY ANYTHING BELOW THIS LINE. True to my law-abiding self, I did not modify that code, nor even try to figure out how it worked.

Then I moved on to Asynchrony, where I entered the wonderful world of IDEs again, and life was grand. I moved on to working on iOS codebases, and learned a little more about the values of command-line building, but it was a manual struggle.

Then I met Travis.

I had joined the team shortly beforehand, and we were trying to clean up our Jenkins jobs to be more manageable—not to mention actually testing a lot of things we hadn’t been testing before. There was plenty of work to be done.

Travis was on that team, though he was out for medical reasons for my first few weeks. A little while after he came back, I was complaining about really just wanting a command-line system to manage a task dependency graph, where I could define command-line tasks and then make them dependent on each other.

“Why not try a makefile?” Travis asked.

I should make another point about this team: it is the reason I know how to use vim. I’d always putzed around in vim and could do some basic things, but this team was different. Everything was vim. We used tmux. Bash scripting was our lifeblood, the plumbing that kept our ruby application afloat. Our team dotfiles contained a series of scripts that would install all the things we needed, and set OS X preferences the way the team “agreed”. We held a team meeting to discuss our values, and the first one was “Automation over manual intervention”.

From this team, I learned the power of the command line. While I’m far from an expert, I no longer look at sed or awk with trepidation as some tool you hand arcane scribblings and it does what you want.4 The automation made me realize that not only did I want my dotfiles in git—I had done that two years earlier—but that I wanted a series of scripts to similarly define my own development environment. Certainly, I don’t get new computers very often, but I saw it as valuable documentation.

I’m digressing a bit, but I just want to emphasize the point: this was a team that thrived on automating as much as possible, using command-line tools through all of it.

The makefile solved my problem. Later, we were working together on another build automation issue, and we wrote a makefile—a lot of that solution has ended up on my Github.5 It was glorious. Writing a makefile and having Jenkins run it took us a fraction of the time it would have taken to do it manually in Jenkins, or putting tons of scripting in there.

I’ve since moved onto another team, and we’re using makefiles in much the same way, and it is glorious, Xcode issues notwithstanding.

Because of my renewed interest in conlanging, I started getting back into web development. This is largely because it’s useful to post language things online, where they’re easily found.

So I said, “can I do this by command line?”

I played with the idea of using Jekyll or capistrano for a while. But in one of our makefiles, we had just used a command-line ftp client to upload things. And my work on this blog had made me realize it’s so much better to write everything in markdown and then convert it to HTML later.

So I wrote a makefile. It runs mmd on markdown files, then rsync to put them on the server.

The first time I ran it, I wondered if it had even worked, it went so quickly.

In capistrano, it would have taken something like thirty seconds to deploy—not to mention the endless hours writing and debugging the Capfile—and something would have gone wrong.

With make, it took less than a second. Using guard, I can edit markdown files and have them regenerate in the browser by the time I press Command-Tab. My productivity has soared.

But what’s great is that it’s all in git. It’s all documented. It will work on any box, and is not subject to the random whims of ruby—except for guard, but I can live without that. And it’s fast, and my server never gets out of sync with my local any more.

So why do I say this is the power of simple? I should probably say something about command-line simplicity or something like that.

And it’s worth noting that gaining this sort of “automated simplicity” took work. For instance, I had to learn how to write a makefile. I don’t know all the arcane bits yet, but I know a lot more than I did. And I know what I need to know in order to do what I want to do. The first few times it took some tries, but dashing out one for my conlang website took almost no time.

Certainly, any tool that improves productivity has this learning curve. It’s about finding the tools that have the smaller curves for huge productivity gains. And about evaluating technologies to know what will or won’t solve a problem efficiently.

Though, as I have used more and more tools, what I have found is that in general the most effective tools—the fastest, most stable, most robust—are the old command-line tools. The ones written in C decades ago, that people mock other people for still using such “old” things.6 And likewise, the tools that flake out the most and are extremely slow at doing their jobs are almost unilaterally written in ruby and distributed as gems. There are exceptions,7 but it’s a pretty strong correlation.

Bolstered by my make epiphany with conlang things, I’ve gone and converted my other websites to a markdown/make backend.8 They’re now easier to work with and faster to build.

So when I say the power of simple, I mean the power of picking tools that do their job extremely well, and do it quickly. It simplifies things, allowing you to focus on what really matters.

1. I imagine it’s the case that my perception of the Internet of that time is colored by my youth. So take my description with a liberal grain of salt.

2. I never actually got all that far in making my own MUD. While I learned a fair amount of C from it, I never had the wherewithal to do anything more than run it locally.

3. About halfway through the class, I was really struggling to get one assignment to compile. It wasn’t because my code was bad, but because I wasn’t particularly familiar with how to do importing in C++ or (probably) get the makefile right. So I consulted one of my friends who wasn’t in the class, and he helped me get all that straight. I then told the professor a couple of days later, and he gave me an amused smile and said was perfectly okay. I still kind of felt like I was cheating, even so—but now that I’ve worked in the real world for a number of years, I think the lack of collaborative projects in college is a detriment.

4. To be fair, I still think the command-line arguments to sed and awk are arcane, but I’m no longer afraid of them.

5. Fair warning: this doesn’t work quite right with Xcode 8. We’re currently figuring it out on my current team. I plan on updating that repo when we get a good solution.

6. The project Travis and I wrote a makefile together for had someone else do the build for production. When we explained to him that all he needed to do to run the build was call make on the command line, his immediate reaction was “why on Earth would you use 1970’s technology?” Lo and behold, when it went off with fewer hitches than the teams who’d chosen fastlane or other manual things, he grudgingly admitted that we were on to something.

7. For example, guard is pretty decent.

8. It worked out because I had been meaning to sign up for Let’s Encrypt and secure it all with SSL, but doing so would break stylesheets and the like, so I had to make changes anyway.

❦     ❦     ❦