After the shooting that happened last week and the subsequent revelation that online forums may have contributed to that bowl-cut-weirdo’s radicalization and subsequent rampage, several people I know have approached me to ask what website owners with discussion boards could have done that could have prevented radicalization. There are some options, but I’ll warn you, most of them are pretty terrible and have a tendency to be easily circumvented (or to backfire spectacularly). The architecture of the internet is intended to be able to route around damage (it was designed to assist with communications after one or more nuclear strikes, after all), and censorship mimics damage in an architectural sense. So, most fixes are not particularly useful, although there are some options.

As software developers, one of the main things we are tasked with is the automation of business processes. Typically, we’re given a task to do, with much of (if not all of) the process laid out and told to get it done. As a result of this sort of thinking, it tends to be our default mindset to either attempt to automate everything, or to avoid automating anything in our own workflows. The decision of when to automate is something a lot of developers struggle with, as it’s very easy to either put up with irritating, repetitive processes, or to get lost in the weeds trying to automate something that really isn’t worth bothering with.

In Part One I outlined the goals of this series. This article will go over what eventually happened when I decided to rework my source control system. As of the beginning of this process, I have a bit of a mixed architecture in regard to source control. For my open source project (which I’ll reveal in a later blog post once I’ve cleaned up the code enough for it to not be embarrassing), I use github, as I find it to be the best place to host that sort of thing. For my internal projects (hacky scripts for various things, websites for other people, utility code, etc.), I tend to use VisualSVN, which is currently running on my “server”. Finally, for an upcoming partner project, I’m using Bitbucket. All three approaches work rather well, but I’m mostly irritated with Subversion. I had initially intended to keep source control on my internal server, but after some thought, I realized that really adds a lot of work I’m not interested in doing. Specifically, the following are the issues I have with it.

I find that on many projects, the most psychologically draining part of the whole experience, other than the final sprint before the thing is completely finished is the first little bit of code to get started. It’s both simple and tempting to open a new project and just start slinging code, but it also frequently complicates things later on. Therefore, I’ve long since come to the conclusion that I should have a fairly standard way of approaching the setup of projects, both for myself and for external clients. I’m going to start writing a series showing how to implement the things you need to have a reasonably decent home development setup. I’m not going to cover what kind of desk or chair to get, as I’ve had the same desk for 14 years and pick chairs based largely on how comfortable they feel in the store with a reasonably similar desk. No, I’m go to get into the guts of how to get a working process together to develop software in your house with professional-grade discipline so that you can actually complete what you set out to do. I’ll be doing these piecemeal as I get a more regimented environment set up at my own house, so feel free to follow along and change anything that doesn’t suit your needs/desires.

I use Evernote as my software package of choice for managing to do lists, as well as for archiving the little bits of data I need here and there. Following (somewhat loosely) David Allen’s Getting Things Done methodology, I’ve created the following notebooks in my evernote account.

I frequently evaluate potential user interface layouts to determine which of a set is the most appropriate for the intended application. Usually I break this process down into three parts, all of which have to pass for the design to be considered acceptable. Frequently parts from multiple prototypes may be combined that are the best of the set in particular categories. These parts are as follows:

Today I finally went to the effort of setting up an account on IFTTT. For those not in the know, IFTTT stands for “If This Then That” (yeah, that acronym isn’t quite right, but the service works great). Essentially what you can do with this tool is set up various sorts of automation for tasks on the internet, using what IFTTT refers to as a “recipe”. A recipe has a couple of pieces: