This post describes how the mobile team at Blacklane works with documentation. We don’t claim that writing a documentation makes everyone’s work better however the documentation we write and maintain definitely makes our own work better and easier. When you do something long enough, you can see how your practice evolves along with your progress. As of the time of this writing we know what is it like when:

  • your app has close to 100% documentation coverage
  • when every team member understands the value of documentation and has good technical writing skills
  • when in almost every case it is enough to find an answer to a question outside of your direct expertise without asking other team members.

We got there as a team and now we want to share our practice and insights to the developer community.

Welcome to the third part of the series - you can find the first part here and the second part here.

In this part I will again focus on some other highly interesting gems Mutant uses, in particular the Abstract Type gem and the Adamantium gem.

Welcome to the second part of the series (you can find the first part here).

We’ll continue to look at some other highly interesting gems Mutant uses.

Initially I had planned to cover multiple gems again, but after starting to look into the IceNine gem I realized that this was big enough for its own blog post.

I recently started looking into Mutant and related gems for an upcoming presentation about abstract syntax trees I am working on at the moment.

While browsing the source code of Mutant and of the gems that Mutant uses I realized that those codebases are among the cleanest code bases I have ever seen in Ruby land with an amazing overall architecture and I’d love to share what I’ve seen and learned reading their code.

I intend to make this a series with the first part of this series not covering Mutant itself but the gems it uses.

Let’s get started with Mutants gem dependencies.

We all know that the API has a specification. We all write tests to cover “happy paths” and to cover “unhappy paths” when work with the API.

It may seem that we’re pretty safe if we have tests and follow the specification. Well, actually no. Usually it works well in theory, but doesn’t really work in practice.

We can write as many tests as we need to cover all edge cases, but that is both time consuming and error prone. The best choice would be is to automate this process.

How to design and implement a service for creating a Google Form, using the submitted data for filling in a spreadsheet template, generating a PDF from it and emailing the result to the Google Form submitter. It is assumed throughout this post that you are familiar with the basic Google products.

This is a long Christmas post: be sure to wrap yourself in your favourite blanket and have some amount of Glühwein near you.

This is the summary of our testing practice that we have at Blacklane GmbH by the end of 2015.