Write Simple Code to Prevent Headaches Later

Consider the following code snippet:

someVar = false;

if ( anotherVar >= 1 ) {
 someVar = true;

Now, consider this rewrite:

someVar = ( anotherVar >= 1 );

Both snippets work as designed, so why is the second one better? It comes down to simplicity.

The first snippet includes an if block. It would be possible for another programmer to add logic into that block that, while not modifying the final result of someVar, increases the complexity of the code. This makes it harder to maintain in the long run.

The second snippet is very clear about what it does, and is more difficult to tack additional logic onto.

From Developer to DevOps: My Story

In late 2014, the sole system administrator for the Star Tribune Digital department (let’s call him John) turned in his two-weeks’ notice. Thus began a panic as we realized we had no idea how our infrastructure worked.

At the time, I was one of two senior software engineers there. I was in the middle of a large refactoring project for the mobile website. John had, thankfully, kept up an internal wiki that at least roughly documented how some of the legacy infrastructure worked. The new infra on AWS was very new and very undocumented, but at least we had a place to start. Continue reading “From Developer to DevOps: My Story”

Work in progress on the Amtgard O.R.K.

I belong to an international live action role-playing game called Amtgard. I’m a relatively new player at the time of writing this, with less than a dozen credits in the game. However, I’ve been spending many dozens of hours working on a web application we use called the Online Record Keeper. While not the sole source of truth for Amtgard game records, it has certainly become a popular tool among players.

The application is written in PHP and is backed by a MySQL database. It doesn’t use a framework or a caching mechanism. The source code can be found on Amtgard’s GitHub.

It has great potential. There is a lot of awesome hidden in that code. But there’s also a lot of things that need to be fixed, and others that need to be iterated on.

After several months of working (on Saturdays, usually) on doing a complete rewrite of the UI from scratch in Laravel, I decided that the better move would be to fully own the existing code and bring it up to modern standards. By doing this, I get more buy-in from stakeholders and build trust for the future, but more importantly, gain a much deeper understanding of how the system is intended to work, not just how it appears to work.

One of the ways in which I’ll be doing this is by blogging about the work I’m doing on the ORK from time to time. This is the first such post.

There are three big issues which I’m concentrating on first. Continue reading “Work in progress on the Amtgard O.R.K.”

Fixing the Ansible 2.1 Temporary File Permissions Issue

In Ansible 2.1 and later, Ansible will not allow the creation of world-readable temporary files. It does this for a good reason, but it’s a change from how it was before.

If you’re experiencing this problem, you’ll see an error when trying to become_user other than root, and it’ll look like this:

fatal: [12.34.567.8]: FAILED! => {"failed": true, "msg": "Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user. For information on working around this, see https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user"}

The documentation offers solutions. The one that worked for me was this: add the installation (and enablement) of ACL as part of your common tasks for a given playbook. Everything else will then work behind the scenes to make sure those temporary files are handled securely and silently.