Why Python is a great choice for the Chaos Toolkit project!

Russ Miles and I started the chaostoolkit project about three months ago with the idea we wanted to express with code discussions we had been having on Chaos Engineering and its principles. I’ll leave you the opportunity to read Russ’s post about the Chaos Toolkit effort as I would like to focus here on the choice we made to use Python to implement that Open API for Chaos Engineering.

When we started the core implementation, we wondered which language we should pick up for the project. As a long Python developers, I have always felt faster and more at ease with it but I thought it would be wise to give the other existing languages a thought.

At its core, the Chaos Toolkit attempts to define a declarative API to drive your chaos engineering experiments. That experiment is serialized in a JSON file the chaos command ingests and validates it before executing declared activities sequentially.

It felt clear to us that we would be handling a lot of strings so we wanted to have something that was simple, yet powerful, when dealing with them. That alone is not a strong enough requiremement to make a choice. Afterall, most dynamic languages are capable with strings while static languages, although perhaps more verbose, would be able to as well.

We also knew we meant the chaostoolkit to be extended as widely as possible so we looked for a rich ecosystem with various capabilities. It also meant, we should pick up a language that would help us load extensions in a simple fashion (Note that the Chaos Toolkit API describes three extension mechanisms: Python functions, HTTP calls or process. This means that you do not need to write Python code when you want to extend the toolkit).

It was also relevant to select an ecosystem that was well spread to reduce the quantity of steps for users in order to get started.

On the other hand, speed never was a requirement per-se. Indeed, the Chaos Toolkit is a CLI that runs things sequentially from a single machine. There is no need for raw speed because the Chaos Toolkit runs things as fast as they actually need to be.

Language prowesses with paradigm X or Y didn’t matter to us as long as the language was sound and dependable.

Those requirements, if we can call them that, aren’t very strong nor well-defined but they served us as guidelines.

Having worked a little with a variety of languages this past two years, I kept wondering what to select. Afterall, languages such as Clojure, TypeScript or Go all fitted the bill fairly well.

I dismissed Clojure mostly because I didn’t know its ecosystem nor community well-enough and I could not afford the time to thoroughly explore it. However, should have I had known it more, it would have been a strong candidate if only because of its code-as-data approach felt appropriate. Nonetheless, I do wonder still about its ecosystem.

TypeScript was an interesting one because it does remind me of Python in many respects. Much like Clojure however, I left it out it because I wasn’t sure its ecosystem would be the right one for the sort of experiments that users would care for.

As for Go, it’s mostly the question whether a statically compiled language would fit the requirement for string handling. I don’t mean to say Go is bad at dealing with strings. I made the decision that if I had to end up with empty interfaces, I might as well directly rely on a dynamic language.

I realise you could argue it’s mostly a lack of knowledge of all those languages and ecosystems that made me uneasy about picking them up. Indeed, I certainly think they could all have worked out.

But I settled on Python. In fact, I picked Python 3 specifically. To me Python 2 feels legacy and new projects should not start there any longer (except in rare cases).

Python does check all the boxes the project needed. It’s readily available, has a massive ecosystem, with native libraries for platforms we believe the Chaos Toolkit will provide the most benefit to (such as Kubernetes), and has powerful string handling (specially with the most recent Python 3 releases).

I know most DevOps tools seem to be written in Go these days, but I strongly believe, Python is a sound choice depending on your requirements. Specially Python 3.

Will choosing Python over Go impact the Chaos Toolkit as a project? I certainly hope not and I worked hard to design the code base so that it is comprehensible and easy to ge involved with (well I hope anyhow ;)).

In the end, what tipped it over was that Python is awesome and absolutely fun to work with.

Python has a tremendous ecosystem made of high-quality libraries. The changes in the language in the past years have not just made it more feature-rich but also actually more sound and relevant to new scenarios.

But, at the end of the day, this is just for the little story really, what matters is that we are proud of the Chaos Toolkit and really enjoy using it. We do sincerely hope it will meet its community, so if you fancy a project for 2018 or want to experiment with Chaos Engineering, make sure to join it and say hello! We love a good chat.

Robot Framework and Sphinx: A suitable toolset for your specification by example

At work, we have been using Robot Framework for all kinds of tests for a few years now and it’s proven to be the good choice. Robot Framework’s simple syntax and grammar does not scare testers away (usually). At the same time, its design makes it easy to support complex use cases as well as simple ones through the power of the Python programming language.

One blind spot however, in my opinion anyway, is the way Robot Framework let you document your tests. It provides a section for this, with basic HTML support but it has always felt limited and not really friendly.

Luckily, in the recent releases, the Robot Framework developers have provided a built-in support for reStructuredText. Not that the documentation section supports this syntax, but instead, you can embed Robot Framework tests into a reStructuredText document, and therefore into Sphinx as well.

The gain isn’t so much visible in the Robot Framework reports since the reStructuredText sections won’t appear in those, but it means you can generate HTML documents which embed executable tests. Fans of doctests will be in known territory.

I think this is a powerful combination as it bridges the tests with the specifications and ensure they are both kept locally at the same place, imrpoving their chance to stay synchronised.  In my mind, it provides a great framework to follow the Specification by Example that Gojko Adzic described so eloquently.

Here is a simple:

Finally, a related powerful extension provides a simple mechanism to include Robot Framework tests into Sphinx documentation. We use it extensively at work as we wanted to keep our tests outside in distinct files without losing the ability to see them embedded into the generated HTML documentation.

CherryPy documentation new start

Early on this year, a discussion emerged on the CherryPy mailing-list about the project. Most people said they loved the project but had struggled with its documentation. Though rich and extensive, it was felt it left down the project somehow by being not designed in a way that was attractive to new comers. I took upon myself to rewrite it from scratch following some ideas exchanged on the mailing-list.

The general expressed wish was to make it friendliers to people starting with the framework whilst making easy to look for common tasks and patterns. This suited me well as I wanted to carry the work I started on the various recipes I keep on BitBucket.

Eventually, I quickly wrote a set of tutorials to guide people through the general layout of a CherryPy application. Then I developed upon the recipes idea by going through many of the most recurrent questions we have on the mailing-list. Finally, I wrote an extensive section regarding the core features of the framework: plugins, tools, the bus, the dispatchers, etc. Those features are seldom used to their best even though they provide a very powerful backbone to design your application in clean way.

The documentation is now online and seems to have been well-received. It will need to be completed but I believe they already make the project much more appealing and fun to work with.

XMPP and IronPython 2 using headstock, bridge and Kamaelia

I am glad to announce that IronPython 2 is now capable of running my XMPP
Python library: headstock.

.NET has already an excellent XMPP SDK called agsXMPP that is a native
.NET/C# framework. However I’m a Python developers at heart and I had
started quite a while ago writing my own XMPP library in Python using the
most excellent Kamaelia framework (designed for concurrency).

For a while IronPython had severe shortcomings that prevented it running
simple Kamaelia applications. Today I was able to run a simplechat demo
using a vanilla IP2 on Windows with only one single modification to the
logging module (thanks Seo). To be honest I didn’t expect it to go through
:)

The chat demo is simple enough but means more complex examples using XMPP
PubSub will work as well (they are all based on the same framework).

Now this isn’t production ready or anything. For instance the TLS support
is broken (hopefully something easy enough to fix) so you won’t be able to
connect to Google Talk for now.

Moreover I’m not sure the code is that fast considering how I had to
simulate an incremental XML parser atop System.Xml (this allows for a
XML stream to be parsed without requiring the full document or even
fragment to be read first).

This is a great news for me because it means I’ll be able to move ahead
with more work using IronPython 2.

They made me do it…

I had to.
More seriously though since the work I’m doing with XMPP and AtomPub these days, I thought it be a nice idea to try and plug into Twitter somehow. I guess I won’t be using Twitter much for anything else than testing. We’ll see.