Chet has me nearly convinced to move my site base to Dropbox. Today we’ll talk further about that and about moving the product forward.

As Chet and I chatted yesterday, I was describing how I have copies of my website’s source on both my home machine and my laptop, synchronizing them with Git and GitHub. We talked about the issues with synchronizing the generated site with the source, and the fact that my FTP app, Transmit, uses file size to decide what to push, since Jekyll recreates the whole site, setting all the dates to just right now, which makes them look new even if they haven’t changed.

It would be possible to create a manifest containing the names and dates of the input files, run Jekyll, and then we’d have the information we need to move exactly the right files. But since Git pull updates all kinds of dates to all kinds of random new values, this process would get confused when I switch computers. So, I’ve put a fresh copy of the site source into Dropbox, and moved the generated files out of the source folder, which has always seemed to me to be an odd place for them, into a plain vanilla folder on the local computer.

So here we are today. Tozier’s up to date. We anticipate that our tests will no longer run, since at least some of them look at _site. Let’s find out.

We are surprised to find that none of the tests access _site in my site source folder, so they all run. This is nice. Now we can decide how to move forward. I wonder what we’d like to do next …

First, we decide to try to build the site from the Dropbox folder. This fails because the rotating “classic” article doesn’t come up. A bit of scurrying discovers our plug-in, which creates a special JSON file that’s used in picking a classic. We update that Ruby program to point to the new site output folder. After restarting Jekyll, because it doesn’t reload its plugins, we see the local generated version of this file, this very file.

And it’s 10:40, which is close enough to the end of our programming day that we’re not going to try anything new. Something fascinating needs to be said about how easy it is to consume all one’s time with a little planning or a little work on infrastructure.

Summing up a few days later …

It’s Monday September 4th. I’ve been away from work since this was written last Tuesday, getting a stent put into my heart with all the associated excitement. Looking back at this, it appears we accomplished nothing, but that’s not quite the case. We moved the site source to a folder in Dropbox and made it build correctly, which included updating a custom Jekyll plug-in that we made long ago.

And we only got in maybe an hour and a half of “work” as opposed to our normal two to three hours. So one could argue that we haven’t really lost that much “real time” development.

Nonetheless, I think this is what often happens when a real team decides to upgrade some component of their infrastructure or to re-order the file structures or build scheme or whatever. Everyone can get slowed down a bit.

Chatting with Chet, it occurs to me that Docker, or a similar approach, might allow one pair from the team to build up the new environment, shake out the bugs, get the tests running, and then release the new image. Everyone else could (probably?) just take the new image, bring in whatever they were working on, and carry on without much hassle. So that’s an approach a team should consider as they look at changing out things in the infrastructure.

Of course, Tozier and I were that pair, building the new “image”, so our productivity was impacted. The rest of the team carried on. Unfortunately the rest of the team doesn’t exist, so they didn’t get much done.

The lesson, I guess, is that when infrastructure changes do need to be made, expect them to impact at least one development pair, and build up your infrastructure so as to ensure that it only impacts that one pair, with everyone else able to carry on with minimal impact.