Productivity suggestion: keep lab notes

I’ve recently been getting into various discussions about science and faith with friends at church and on Facebook, and one of the things I’ve been doing is explaining to them exactly how the scientific method works. This got me thinking—there are some aspects of the scientific method that we don’t always apply to software development, that maybe we should.

People with no scientific training often don’t appreciate just how rigorous and exacting the scientific method is. It has a lot of very strict protocols to ensure that research meets stringent standards of quality control. One of these protocols is keeping detailed laboratory notes. In other words, you document everything you do. In meticulous detail. As you do it—not after the fact.

There are several benefits to keeping a detailed record of everything you do in this way. It helps you to keep focused on the task at hand. It gives you something more constructive to do during slow edit/compile/test loops than reading Reddit. It helps you to pick up where you left off after your lunch break or when you get into work first thing in the morning. It jogs your memory for your daily stand-up meeting. It provides you with a searchable audit trail that you can consult to figure out where to find things, why things were done in a certain way, or what exactly happened when you tried X. It provides source material for when you need to write up the documentation proper. And it covers your back. For example, if you’re working from home, it provides evidence—should you need it—that you were actually working and not slacking off.

Of course, if you’re a fan of the Agile Manifesto, you are probably cringing at this idea. Aren’t we supposed to favour working software over comprehensive documentation? In fact, the whole idea no doubt sounds like anathema to many software developers, who hate writing documentation with a passion.

But if we were research scientists rather than software developers, we would be doing this as a matter of course, and we wouldn’t think twice about it. Besides, as Martin Fowler says, if it hurts, do it more often.

Sharing data between Terraform configurations

I’ve been doing quite a lot of work with Terraform lately, Hashicorp’s excellent infrastructure-as-code software, to provision some infrastructure on AWS.

When designing your infrastructure, it is often necessary to break it up into different configurations. For example, you may want to have one set of configuration for your data (databases, S3 buckets, EBS volumes, and so on), and another set of configuration for various compute resources (EC2 instances, ECS containers, AWS Lambda scripts, and so on) — for example, to allow you to tear down your development environment when you are not using it in order to reduce costs, while preserving your data. Or, you may want to reference your DNS hosted zones in multiple different configurations.

When you do this, you will inevitably need to pass state information from one configuration through to the next — for example, EBS volume identifiers, IP addresses, and so on. If you are using remote state, you can do this quite simply using a remote state data source.

In this example, I’ll assume that you have configured Terraform to use remote state hosted in an S3 bucket, that you are using a separate configuration called “dns” for your DNS hosted zones, and that you wish to reference them in a different configuration.

First declare the values that you wish to reference as outputs:

output "zone_id" {
    value = "${module.dns.zone_id}"
}

output "zone_name" {
    value = "${module.dns.zone_name}"
}

In your target configuration, declare the remote state data source:

data "terraform_remote_state" "dns" {
    backend = "s3"
    config {
        bucket = "name-of-your-S3-bucket"
        key = "dns"
        region = "eu-west-1"
    }
}

Then, whenever you need to use any of the remote values, you can reference them as follows:

resource "aws_route53_record" "www" {
   zone_id = "${data.terraform_remote_state.dns.zone_id}"
   name = "www.${data.terraform_remote_state.dns.zone_name}"
   type = "A"
   ttl = "300"
   records = ["${aws_eip.lb.public_ip}"]
}

Note that you will need to run terraform apply on the source environment, even if you have not made any changes, before you attempt to do anything with the target environment. This is because you need to make sure that the outputs have been written into the Terraform state file, and are available to the other modules that depend on them.

Hat tip: Thanks to Paul Stack for pointing me in the right direction here.

Password hashing as a microservice with Docker Compose

So you’ve stopped breaking the law by storing your passwords in plain text, and you’re aware that MD5 doesn’t cut it any more in a world of GPU-based cracking tools, so you’ve started using bcrypt instead. But can you make your passwords any more secure? Can you even protect your users who have chosen passwords such as “password” or “qwerty” or “123456” or “letmein”? And since bcrypt is so computationally expensive, how can you stop an attempt to brute force your admin password from bringing your entire site down?

Here’s what you can do. Use a microservice.

This gives you two advantages:

  1. Your passwords are stored in a separate database from your user accounts. The “password” field in your users table only contains a randomly allocated identifier; without the password database as well, this tells an attacker nothing. Nada. Nichts. Bupkis.
  2. Your password hash algorithm can be scaled independently from the rest of your site. It can be run on completely different hardware. A brute force attack on your admin site won’t end up DOS-ing everything else, no matter how slow you make it.

Over the past week or so I’ve been experimenting with an implementation of this approach. You can find it on GitHub here.

How it works

Since it’s 2016 and Docker is all the rage, the password hashing microservice, the main web application, and their respective databases, are all in separate Docker containers, managed as a group using Docker Compose and defined in the docker-compose.yml file. Tools such as Docker Swarm or Kubernetes make it a breeze to scale up and down as needed.

The password hashing microservice is in /passwords in the Git repo. It is implemented as a very basic Flask application in passwords/serve.py, storing the passwords in a MongoDB database. It exposes three methods:

  • POST /password: hash a password, allocate it a random ID, and save it.
  • POST /password/test/<id>: test a password against the saved hash with the given ID.
  • DELETE /password/<id>: delete the hash with the given ID from the database.

The POST methods both take the password in a form field called password. The password ID returned by the first method is a randomly generated GUID.

The sample web application is a Django application in /web in the Git repo, backed by a Postgresql database. The file web/webapp/security.py contains a custom password hasher which saves the GUID returned from the microservice in the password column in the users table. The password ID thereby acts as a proxy for the password hash, but since it can not be derived from the hash, the password can not be brute forced from it.

The docker-compose.yml file also puts a Træfɪk proxy server between the web application and the microservice to act as a load balancer. This allows you to scale the microservice as necessary simply by typing docker-compose scale passwords-svc=<n> where <n> is the number of containers you wish to spin up.

Ramping up the security even further…

To make things even harder for an attacker, the hashing service combines both the password and its identifier with application-specific secret strings before saving them into the password database. These secrets will frustrate anyone who manages to get hold of both the user database and the password database, as unless you know their values, you will not be able to brute force the passwords, nor will you be able to tell which password hashes correspond to which users in the database.

These secrets are stored as environment variables called PASSWORD_SECRET and KEY_SECRET and are defined in this example in the docker-compose.yml file. Naturally, you should change them in your own application to other, similarly complex, random strings. If possible, you should load them in from a dedicated secret store such as Hashicorp Vault.

Unless the attacker has access to the user database and the password database and both these secret keys, they aren’t going to be able to crack any of your users’ passwords. Even if your users have used silly passwords such as “password” or “123456” or “arsenal” or “chelsea” their credentials will still be safe.

This is what microservices are for.

There’s a lot of debate going on at the moment about how to use microservices. Should you keep your application as a single monolith and only extract out certain tiny pieces of functionality, or should you break it down into a large number of separate microservices? In each case, just how much should each microservice handle?

Password hashing, as we’ve implemented it here, is a great example of where microservices are appropriate, and how much they should try to achieve. We’ve identified some very specific problems. There is no speculation, guesswork or YAGNI involved. Most importantly, we’ve seen that they provide well defined real-world benefits.

The Continuous Retrospective

The sprint retrospective is one of the most important ceremonies in Scrum. At the end of every sprint, the team meets together to discuss what went well, what went badly, and how you can improve your processes  and working practices.

Effective as it may be, the end-of-sprint retrospective isn’t perfect. It’s very common to encounter problems during the sprint, only to get to the retrospective and  find that you’ve forgotten what they were. On the other hand, you can end up wasting a lot of time complaining about things that you aren’t able to do anything about.

To resolve these problems, we have recently implemented a “continuous retrospective” within our team. Instead of waiting until  the end of the sprint, we can highlight problems as and when they arise, and action them accordingly.

continuous retrospective

Besides the fact that issues are less likely to be forgotten, there are several other advantages to this approach. It is less formal, and a better use of people’s time. It improves communication. It can also improve visibility and transparency, allowing people to see that you are aware of, and addressing, issues that you are encountering.

A different approach.

This is a different approach from your traditional, end-of-sprint retrospective. For starters, it is less meeting-oriented. You simply set up a kanban-style board in your team’s working area, where you can add Post-It notes for things that are going well, things that need action, and things that need further discussion, perhaps to reach a team consensus.

Write things down as soon as you think of them — don’t wait until the end of the sprint, or even until the daily stand-up meeting. You should aim to discuss them with the rest of the team as soon as possible, and reach a consensus on what action to take. Actions may be, for example:

  • Creating backlog tasks for the items you bring up
  • Updating documentation
  • Communicating problems or findings with other teams or the wider software development community as appropriate (e.g. through email, Twitter, blogs, or forums)
  • Flagging issues to raise with senior management.

Don’t just limit items to things that are within your team’s remit. Anything that needs attention or can be improved is fair game — the appropriate action may be to raise it with other teams or senior management, for example.

Do you still need an end of sprint retrospective?

Maybe, or maybe not. It depends on your team.

Some teams may find that a continuous retrospective renders the end of sprint retrospective mostly superfluous. Others may find that the end of sprint retrospective still provides value — for example, by allowing you to check your progress, or to prioritise issues that have proven to be more complex to address.

But regardless of whether we retain the end of sprint retrospective or not, our goal is to make the continuous retrospective, as the sprint is in progress, the main driver of our team’s improvement. Agility is all about keeping your feedback loops as tight as possible, and like continuous integration and continuous delivery, continuous retrospectives are another way to achieve that end.

Thanks to Steven Wade, Vinitha Devadas and Dan Barrett for their contributions to this post.

The three essential files required by every Git repository

There are three files that you should add to every new Git repository, right from the outset. Unfortunately I frequently see projects that don’t have all three of these files, for whatever reason. These are they.

.gitignore

This is the one you’re most likely to have. However, you may be doing it wrong.

You’ll no doubt be aware what .gitignore does—it specifies a list of file patterns to ignore. However, did you know that GitHub maintains a repository of technology-specific .gitignore files? Or did you know that there is a website called gitignore.io that lets you combine two or more of them into one? So for example, if you are using Visual Studio together with Node.js, Python and Visual Studio Code, you can request a .gitignore file that contains all four sets of patterns.

This should be your starting point when you’re setting up your .gitignore file. Some platforms, such as Visual Studio, have some pretty complex ignore requirements, and it’s all too easy to end up ignoring too much, or too little. But since these ready-made .gitignore templates are peer reviewed and have proven themselves in numerous projects, they save you a lot of guesswork. Additionally, because they cover most if not all of the cases that you need, they are generally a case of “set it and forget it.”

.gitattributes

As you will no doubt be aware, Windows handles line endings differently from Unix or OS X. Windows uses the ASCII control characters CR and LF (0x0D, 0x0A) to indicate an end of line, whereas Unix and OS X use only LF (0x0A).

To allow users of different operating systems to work on the same codebase, Git can be configured either to normalise line endings on check-in and check-out, or to leave them as-is, using the core.autocrlf configuration setting. However, not everyone configures Git the same way, and this can cause confusion (and unnecessary merge conflicts) if you’re not careful, as well as confusing certain text editors such as Notepad or gedit. To avoid problems here, you can (and should) override the core.autocrlf setting for your project using a .gitattributes file. This should contain just one line:

* text=auto

You can set other options with .gitattributes, but this simple example will be sufficient for 99% of cases. It will ensure that text files are checked out on Windows with CRLF endings and on Unix/OS X with LF endings.

In some cases, you may need to make sure that code is checked out with Unix (LF) line endings on both platforms. This can be the case if your files get shared between Windows and Unix systems by mechanisms other than Git — for example, using tools such as Vagrant, Terraform or Docker. In this case, use the following line:

* text=auto eol=lf

Note however that if you are using git-svn against a Subversion repository, you want to make sure that line ending normalisation is turned off, otherwise both Git and Subversion will attempt to handle line endings, leading to confusion among Subversion users who aren’t using git-svn. In this case, you should use:

* -text

README.md

The third file does not actually affect Git’s behaviour. However, it is every bit as important. Your README.md file — a Markdown document located in your root directory is the home page for your developer documentation.

I say this because it is the first place that anyone working on your project will see. GitHub, Bitbucket, GitLab and most other modern Git hosts render it when you visit your source repository’s home page in your browser. As such, even if your actual developer documentation home page is elsewhere, you should at the very minimum have a readme file containing a link pointing to it. This is a well-established standard, and by sticking to it you will make your documentation much easier to find.