Tools of the trade

Hey guys, hope you’re doing well. I was aiming to have the next raft of changes to the site ready by now but life got in the way. Unexpected travel as well as being sick kept me from doing as much as I would have liked in February. I’ll be aiming to have things done by mid-March or, at the very latest, the end of the month so look forward to that.  

In the meanwhile, I figured it would be a good moment to talk a little bit about the the development process and the tools I use. Feel free to skip this one if you’re not very technically-inclined or curious about this sort of stuff as I’m just going to be talking about my personal work process. I’ll be including a few links in case you want to learn a bit more about the tools I mention.

Right from the very beginning I’ve made sure that there were daily backups to the site. A cron job set for a specific hour runs a bash script on the server that creates a dump of the current database and then compresses it. A script on my desktop uses rsync to synchronize the database dump and download it to my computer and then do the same for images and html files in the web server’s root directory. It used to be that another device I controlled would do the same, creating redundancy, but due to various reasons that’s no longer the case. Instead, I now backup the latest few daily database dumps onto an external drive every couple of days. I delete the old database dumps every once in a while, making sure to keep a few snapshots around just in case. All in all, it’s a fairly seamless process.  

Though I’ve been diligent in keeping the core of the site backed up, it’s been a more checkered past for the site software itself. Many a quick fix or modification to the board software was made over the years by people (helpful types who wanted to contribute or me from time to time) and it was usually just dumped up on the server without version control. Basically, everything up until my more dedicated changes in the last few months has been ad hoc and without a proper management. As they were relatively minor changes or outright additions in new files (like the storylist) it wasn’t as terrible and messy as it could have been.

Since I’ve started making changes in the last year or so, however, I’ve made sure to keep a much more rational work flow for changes. I’ve used git to keep track of all the modifications made to files and have made damn well sure to comment appropriately changes so that it’s easy to figure out why things were done a certain way and how. Initially, I had a git core service running on my local machine. I migrated over to gitlab after a while because they offered private repositories and it made the data more redundant to have it hosted elsewhere as well. Being able to easily access the repository from anywhere is also a plus.

When it comes to actual modifications to the site’s code, I currently have two branches in the git system. One is the main branch, which I have the site pull from whenever I update the board software. Only small changes are made directly there like typos or code comments. Everything else first gets trialed in an experimental branch that only gets merged once I’m satisfied that things are stable enough. I do have milestones/issues labeled and highlighted so I don’t forget my general roadmap but I try to work on only one thing at the time. That said, “one thing” can be a bunch of interrelated code that requires changing a lot of features or writing new bits so it can take a while.

In order to keep the overall sanity on the project, I also develop with portable virtual machines. I use Vagrant to create and manage virtualization, so that I can mess around with software similar to the server’s without fearing that I may mess something up. I can just clone a virtual machine and deploy it elsewhere, without having to fiddle with settings every time. This is not foolproof, however, and there are certain idiosyncrasies that happen in the real server or virtual environment that can be hard to replicate. For the most part though, it works well and is easy to deploy.  

You can forward ports to a virtual machine easily, too, so all it takes is typing an address in my web browser to see my development page. I can see what changes I’ve made and if things are working well instantly. For the most part this eliminates most of the uncertainty in coding new things as it’s trivial to dive into the virtual server’s logs every time I encounter an error. With my development code in its own virtual machine and with its own git branch, even things that are basically trial and error are significantly less tedious to do.  

This brings us to the matter of an actual coding environment. Some men swear by Emacs, others by Vim. Others still prefer things like atom or something more feature-rich. Personally, I’m pretty flexible. I’ll happily code directly in nano with syntax highlighting if I have to (as sometimes is the case if you’ve only got ssh access to a box) but I prefer some of the lightweight IDEs when it comes to productivity. I used to use Bluefish but as of late I’ve migrated to Geany, as it’s quick, highlights what I want it to and has a few nice plugins. Things like keeping track of what sections I’ve committed to git is handy and it does so without being obnoxious or resource-hungry.  

I’m sure that if you’re a developer yourself and you're reading this, you’ve likely got your own preference. If you’re not and are wondering what might work for you my advice is to just try different programs. Everyone has their own workflow though I’d suggest something crossplatform as you never know when you’ll be on a different operating system.

Well, I think that just about covers it. Hopefully next time I write up one of these I’ll have more to share about changes to the site. Take it easy and if there’s anything else you would like to know about the tools I use or the development process, let me know in the comments and I’ll reply as best as I can.