Hosting a WordPress blog on Digital Ocean

I’ve been running since 2009. While the content has changed over time, the site has remained a blog. has gone from self-hosted on a Windows Home Server in my living room, to Blogger, and ultimately to WordPress. It’s been migrated to and from so many different hosting providers over time that I’ve lost count.

For a time all my sites were hosted on a single “shared” plan. This meant all the sites shared the quasi-dedicated resources of the plan. The problem came when would take the full allocation of memory and crash everything. Even with Cloudflare caching the top pages the traffic was too much. It was time to get a little more serious about hosting.


I like working from home… 🏠

I like working from home… but it feels different now. 

Clarification: I like working from home, when it’s my choice.

My ideal work/life choice would involve: splitting the week into 2 or 3 days of in-office and from-home work. The extrovert in me would get to talk to my coworkers, pair up and communicate freely. The introvert in me would get to focus with limited distractions, kill my commute time and get to see my family a little more.

Back in the day I worked fully remote for over 3 years straight but this time I no longer have the same choices to keep me balanced. My old office became the kid’s bedroom and although I love my standing desk it’s also in the dining room. Staying inside for most of the workweek used to be fine when I could go out to eat for lunch or dinner or spend time with friends. Those options are much reduced today.

However even as we retreat from physical interaction I’m reminded there’s still the possibility to learn and connect with others. This morning I was Skyping with a friend in the Netherlands who had just gotten off of a random Zoom call with 30+ Strangers for an happy hour drink. Someone posted a link, others joined and enjoyed an after work drink together!

And that’s the point. There are still choices to be made despite our shelter-in-place orders. I take long walks with the family after work and on occasion I fly my drone to explore my surroundings. This weeks goal is to start taking walking breaks at regular interviews where I’ll listen to my podcasts and perhaps say hi to people doing the same. Who knows, maybe I’ll host or join social hangouts for fun?

Lessons Learned from the Contributing to GitHub is For You Workshop

On April 11, 2018 I gave a workshop called Contributing to GitHub is For You is For You (abbreviated as C2GI4U) in Des Moines, IA to the Des Monies Area Quality Assurance Association (abbrevitated as DAQAA). Roughly 36 people signed up for the DAQAA event meetup and of those about 22 showed up. Scheduled for 3 hours (including a break in the middle for food) I set out to cover a number of topics around using Git + GitHub including:

  • Creating repositories
  • Branching
  • Submitting changes in Pull Requests
  • Merging, reverting, cloning, forking, and other common commands, etc.
  • Using git locally from the command line and GitHub remotely through the web

In a little less than 3 hours we were able to run through three quarters of the exercises, covered all of the basic git commands and many of the intricacies of using the Git + GitHub workflow. Everyone walked away knowing how to grab and contribute to a project in Github using Git in the command line. A few people were overwhelmed having to pick up terminal commands in addition to Git commands, but most were able to get through the exercises and commit jointly to the C2GI4U repository. By the end a few felt so empowered they were going to apply what they learned the next day at work. (This point made me feel quite well.)

Workshops (generally) are fun because we get to do hands-on technical things. They also bring up interesting challenges, some of which are expected and others not so much. For example I expected some people might have to learn to navigate the command line (or re-familiarize themselves). Although we split time between GitHub’s nice UI you can’t get away from the command line but with practice during the workshop many people became more comfortable. However there were a few things that I didn’t expect and hope to improve upon the next time:

  • Provide a list of git commands we will use alongside the exercises. I had a list of all the git commands we were using as well as a list of exercises BUT they were in separate places.
    • I included a few cheat sheets with a bunch of different git commands but these were too broad to teach from, especially for people brand new to git.
  • Include information about storing GitHub up credentials. Although this wasn’t a big issue (you get a prompt to login) I always forget this step since my credentials are saved in my terminal. Everyone ran into this problem.
  • Make sure people are aware of the location of their code. I was good about this up front, but I need to make it a part of the pre-requisities and slides. This is as simple as making sure you are in your Documents folder before cloning a repo.
  • Branching can get quite complex. I’m also not sure how much of a challenge this was for people to understand and perhaps because of this how exactly to address this complexity except by going through exercises (I even drew a few diagrams on a whiteboard). Ideally I’d have more information / follow up references and maybe another diagram or two. I don’t think I explained Remote vs local branches as well as I could have.
  • Not really an improvement but a general note of thanks: A few of the organizers from DAQAA had experience with git + GitHub and so I was happy to have had a few helpers roaming around. An unexpected but happy side effect was participants helping one another out which made my job that much easier.

The goal here was getting closer to the development workflow (like git + GitHub does) to help reduce the knowledge gap for testers, business analyst, other developers, etc. and help make them more comfortable with the technical aspects of software development. (There were a couple of attendees who were learning to program in Java and the course they were taking assumed they knew how to use Git + Github which they did not. This class helped them become more proficient.) Overall I think we achieved that goal.


Being a Distributed Tester was hard

As a new father, being able to work a few days per week from home has been a great way to help adjust to our wonderful new addition and the demands that go along with him. Days in the office are great for face time and collaboration and days at home are for getting shit done and helping with the kid:

In the past I’ve worked for a few companies where the development teams were distributed across the US, India, Ireland, Vietnam and the Netherlands. I took advantage by working from locations all over the world. It was (and is) a very freeing experience.

Yet working in distributed environments (where everyone works remotely) is not without its challenges. As Alister Scott pointed out in his talk on “The future of testing is distributed” things like loneliness, lack of accountability, focus, and work/life balance all become more of an challenge in addition to the difficulties around communication. I was fairly successful at adjusting to most of those challenges except for the difficulties around communication.

Perhaps the problem was both companies I worked for were not fully dispersed, only the development teams were. We had tools to help alleviate communication problems like Slack, Skype and daily standup meetings through video (like Google Hangouts). They were important but only partially lessened the communication problems. In both cases the development and product information was shared disproportionately among team members. I usually felt like I last to know (except I wasn’t the only one.) Sometimes decisions were made by small groups without input from the larger team and without socializing the impact of those changes prior to. It was a guessing game as to when someone would share important or valuable news (perhaps after a bug was filed).

There were other less subtle communication costs like how little I got to know my coworkers. Imagine working together every day for six months and knowing next to nothing about them. While this might seem like a non-communication problem I’ve found the less I know someone the less context I’m able to apply to our online conversations. I’ve had a few coworkers over the years whose chat conversation style was often terse despite their very helpful demeanor in person. Knowing this helped me better know what boundaries were real and which ones were made up.

For our future (and my future self) I hope it’s possible to be in a distributed testing position and not have these barriers (or have them lessened). For Alister Scott’s organization, Automattic, it seems to be working well. In the meantime I will continue to fully enjoy working some days at home and some days in the office.

I’d like to think it’s possible to be in a distributed testing position and not have these barriers (or have them lessened).