A few weeks ago, I decided to start a new project. Here I share some thoughts about why, what I am going to do, and how I plan to do it.

Why a new project?

Not primarily because I had a bright idea or wanted to create yet another implementation of X. My primary goals with this new project are:

1. Having some fun. It’s been a while since I wrote more than a few lines in my free time. At work I am currently doing lots of different things, neither of which has to do anything with C++. I’d just like to have a slab of C++ code to work on, so I’ll create my own.
2. Learning new things. I feel I need more practice in using the newer features of the language. I want to try out new techniques and tools and play around with new libraries. After all, learning interesting new things is fun, too.
3. Topics for the blog. It gets hard to come up with a new C++ topic every week if you haven’t touched C++ code for months. So if I learn new things and gather new insights, there should be some blog post material in it.

The project

So what kind of project should that be? It should not be too small or trivial, because there is no fun in that. It shouldn’t be too ambitious either, because nothing leaves a worse feeling than abandoning yet another project. So the best would be something where the minimum viable product is small, but where there is potential for more features and more things to learn.

Searching for an idea, I remembered someone who had posted an interesting question on Twitter: They were looking for an issue tracker that would be small enough to run on devices like a Raspberry Pi. In addition, it should be able to store its data in a Git repository. If I remember correctly, the Raspberry Pi would be used as a local Git server.

So that has become my project: writing an issue tracker that stores the issues in a way that can be handled by Git. Basically that means plain text files as storage medium for now, since anything else would require me to implement a merge algorithm as well. The name of the new project is Fix.

Technologies

Since a later goal for Fix is to run side by side with a Git server, I decided to write Fix in the form of a small web server. We will be able to create and manipulate issues either by communicating with a RESTful API or via a simple JavaScript Webapp which does the REST communication for us.

We will be able to have our Fix data in our Git repositories locally. Since the command line still is the most used way to interact with Git, there should also be a command line interface for Fix. I plan to deal with that later, but I’ll have to keep it in mind when I design Fix.

So, for now, Fix will basically be a web server with a REST API that manipulates files. I’ll use C++ for the implementation not only because that’s one of my goals in with the project. I also think that, using the right libraries, Fix will leave a considerably smaller memory footprint than e.g. a Java implementation on top of a Tomcat and a JVM.

In my last jobs I had to use older compilers which gave me little opportunity to use newer C++ features in productive code. Therefore I will use C++14 and the newest compilers available.

TDD

I have used test driven development (TDD) before, but I still have to practice and discover a lot. TDD is mostly based on unit tests which forbids I/O, because I/O based tests tend to take longer. This would harm the time needed for the typical red-green-refactor cycles in TDD which involve multiple runs of the unit test suite.

On the other hand, a web server manipulating files means I/O on both ends. Using TDD in such an environment means that the actual web server and the file operations should reside in their own small tiers. That way the logic of the application can be tested independently of the I/O operations.

BDD

Even if the I/O operations reside in very dumb components, they still have to be tested, as well as their integration with the application logic. That’s where automated integration and acceptance tests come in. Broadly speaking, the equivalent to TDD on acceptance and integration test level is behavior driven development (BDD).

I plan to use Cucumber for those tests. While there are C++ frameworks that support Cucumber, I chose Python for that job. It would be relatively tedious to create the simple REST clients for the tests in C++, and – you might have guessed it – I want to learn more Python.

Conclusion

After I have touched much theoretical stuff in the last months, I have at last a project where I hopefully can extract some more practical topics to share with you. That said, I still will continue to write about basic and modern C++ features and the occasional refactoring session. I hope you’ll enjoy reading more about Fix in the future.