Let me tell you a story: the why!

A year ago, one of those Sunday morning where spring starts to warm up the souls, I went, as usual to my favorite bakery. The family tradition is to come back with a bunch of “Pains au Chocolat” (which, are, you can trust me, simply excellent).

• hello sir, I’d like 4 of your excellent “pains au chocolat” please
• I’m sorry, I don’t have any “pains au chocolat” nor any “croissant” anymore
• what? How is it possible ?
• everything has been sold.
• too bad…

I think to myself: why didn’t you made more?. He may have read my thought and told me

Opening remarks

All my previous posts were about choreography, deployment, topology, and more recently about an attempt to include AI in those systems. This post is a bit apart, because I’m facing a new challenge in my job which is to implement BDD in a CI chain. Therefore, I’m using this blog as a reminder of what I did personally. The following of the Markov saga will come again later.

Introduction

Opening remarks

I’m not a Ruby developer, and I’m heavily discovering the ecosystem by now. This are my notes, and if anything seems wrong to you, do not hesitate to send me remarks.

The scenario

For testing purpose, I wanted to play with vagrant-aws and more generally with ruby on my Chromebook.

Vagrant does not support rubygems as installation method anymore (see Mitchell Hashimoto’s post) and of course, there is no binary distribution available for the Chromebook.

Introduction

In my last post I introduced the notion of choreography as a way to deploy an manage application. It could be possible to implement self-healing, elasticity and in a certain extent self awareness.

To do so, we must not rely on the certainty and the determinism of the automated tasks. Mark Burgess explains in his book in search of certainty that none should consider the command and control anymore.

Actually we grew up with the idea that a computer will do whatever we told him to. The truth is that it simply don’t. If that sounds astonishing to you, just consider the famous bug. A bug is a little insect that will avoid any programmed behaviour to act as it should.

Thanks to the company I’m working for (Techsys) I’ve had the opportunity to attend the configuration management camp in Gent (be) for its 2016 edition.

I really enjoyed those two days of talks, watching people present different ideas of a possible future for the infrastructure and deployment engineering. Beyond the technical demonstrations and the experience sharing, I’ve spotted a bunch of ideas

Among all, those that comes to me spontaneously are:

You don’t need configuration management, what you need is a description of the topology of your application - Mark Shuttleworth in its keynote The magic of modeling

I’ve read a lot about graph theory recently. They have changed the world a lot. From the simple representation to Bayesian network via Markov chains, the applications are numerous.

Today I would like to imagine a graph as a workflow of execution. Every node would be considered as runnable. And every edge would be a dependency.

It is an important framework that may be used to as an orchestrator for any model, and of course I am a lot thinkingabout TOSCA

From time to time, I’m involved into a trolling conversation when any linux kiddie tells me:

Bash is really the superior shell

I totally disagree, but as I’m getting older, I don’t argue anymore.

Anyway, in this post I will expose two arguments, or I should say two reasons, why I usually use ksh93 to run my scripts.

Note I’m really talking about the engine of the script, (the shebang definition). set I’m used to the bourn shell syntax therefore I also exclude any C shell from the comparison. My $SHELL for interactivity is zsh because it’s efficient enough and it has a bunch of really cool features I won’t discuss in this post (maybe later)