because every new challenge hides an opportunity

Days ago I came across an article from the series “The long read” of The Guardian. The article, titled “Crash: how computers are setting us up for disaster” analyzes the downsides of overly reliance on computer-controlled systems and automation in general. It’s an incredibly well written essay and I wanted to contribute my own two cents to the topic.

This is not an article about how you can work with JSON in Go: you can easily learn that from the articles and web pages in the bibliography. Rather, this post is about the concepts that you must understand clearly before you set yourself for the task. Don’t sweat, it’s just two concepts two, and I’ve tried to explain them here.

In the last few weeks I have worked together with a colleague to write some automation with Golang and the Atlassian Crowd API. With several separate user databases (and, at the current state, no hope to unify them in a smart way) it would be very handy to take advantage of the APIs offered by, say, G Suite to fetch all the email addresses related to a user and use that information to automatically deactivate that user from all systems.

Coming from a Perl 5 background, I was hoping that decoding and encoding JSON in Go was as simple as it is in Perl. But it turns out that it wasn’t, and it’s obvious if you think about it: as Perl 5 is weakly typed, decoding any typed data into an “agnostic” data structure must be simple. Encoding a weakly typed data structure into a typed format may be a bit trickier, but as long as you don’t have too many fancy data (i.e., in this context: strings made of only digits or non-obvious boolean representations) this will also work well. But with strongly typed Go and struct field names having side effects depending on upper-/lowercase, that’s a different story.

As it often happens in cases like this, you will not find all the information you need in a single place. This is my attempt to collect it all and hand it to you, so that you won’t have to waste as much time as I did. You will still have to read through stuff though.

In my quest to learn the Go language I am currently in the process of doing the Go Code Clinic. It’s taking me quite some time because instead of going through the solutions proposed in the course I try to implement a solution by myself; only when I have no idea whatsoever about how to proceed I peep into the solution to get some insight, and then work independently on my solution again.

I have attended the Config Management Camp in Gent this year, where I also presented the talk “Promise theory: from configuration management to team leadership“. A thrilling experience, considering that I was talking about promise theory at the same conference and in the same track where Mark Burgess, the inventor of promise theory, was holding one of the keynotes!

The quality of the conference was as good as always, but my experience at the conference was completely different from the past. Last time I attended, in 2016, I was actively using CFEngine and that shaped in both the talks I attended and the people that I hanged on with the most. This year I was coming from a different work environment and a different job: I jumped a lot through the different tracks and devrooms, and talked with many people with a very different experience than mine. And that was truly enriching. I’ll focus on one experience in particular, that led me to see what the future of configuration management could be.

2017 was also an year of change. In November 2016 I have left Opera Software and joined Telenor Digital as Head of IT. I have more “managerial” tasks now, less time for “operations” and the scale is definitely different than the one I was managing in Opera. That had an impact on the contents I was able to post in this blog, both in terms of topics and amount. Whether the new course is better or worse, only time will tell.

Can Promise Theory help you shape a better, effective leadership style?

Promise-based leadership will be the topic of the talk I will hold at two conferences. The first one is the Config Management Camp in Gent, Belgium, and it’s pretty close: February 5th. The second conference is the glorious Incontro DevOps Italia 2018, the Italian DevOps Meeting in Bologna, on March 9th.

When I joined Telenor Digital as the Head of IT I had to find an unconventional leadership style, as circumstances didn’t allow for a traditional one based on the “line-of-command” approach. After so many years spent with using CFEngine it was quite natural to me to use Promise Theory to model my new “reality” and understand how I could exploit exactly those peculiarities that were making the traditional leadership approach pointless.

Promise-based leadership has clear limits in applicability. It requires the right attitude in leaders and the right culture in the company. Where the right leaders and the right culture are present, I am confident that it provides significant advantages compared to the conventional approach based on top-down imposition.

I have been doing promise-based leadership for a bit more than one year now, regardless of people being direct reports or simply colleagues at any level of the hierarchy. My talk is a report of the experience so far. I don’t have definitive answers yet and there are several unanswered questions. I will be a bit tight with my talk schedule and I won’t be able to take many questions, but I hope to have several interesting conversations “on the side” of the conference events 🙂

One fun fact for closing: when I submitted to Config Management Camp I wasn’t really confident that my talk would be accepted because, I thought, the topic was kind-of “tangent” to the conference’s, so I didn’t even plan to attend. Later on the keynotes were announced, and one of them will be held by Mark Burgess, the inventor of Promise Theory. A few weeks more and I was informed that my talk was accepted and they actually liked it. So I will be talking of promise-based leadership at the same conference, in the same track and in the same room as the inventor of Promise Theory himself. Guess how hard I am working to put together a decent talk in time… 😀

I have been using Perl for more than 20 years now, seen Perl 4 bow out and Perl 5 come in and develop in that fantastic language that has helped me uncountable times in my professional life. During those years I’ve also considered learning another language, but I have been unable to take a stand for a long time.

And there came Go and the hype around Go, just like years ago there was a lot of hype around Java. But while whatever written in Java I came across was a big, heavy and slow memory eater, most of the tools I came across that were written in Go were actually good stuff — OK, still a bit bloated in size, but they actually worked. The opportunity came, and I finally gave Go a shot.

Everyone get so many unsolicited commercial emails these days that you just become blind at them, at best. Sometimes they are clearly, expressly commercial. Other times, they try to pass through your attention and your spam checker by disguising themselves as legitimate emails. I have a little story about that.

A couple of weeks ago I got yet another spammy mail from. It was evidently sent through a mass mailing and, as such, also included an unsubscribe link, however the guy was trying to legitimate his spam by saying that he approached me specifically because a colleague referred me to him; in addition, I felt that some keywords were added to his message only to make it sound “prettier” or even more legitimate.

I usually don’t spend time on spammers, but when I do I try to do it well. And in this occasion I had a little time to spend on it, and I did.

In the past months I have made several attempts to explore Docker overlay networks, but there were a few pieces to set up before I could really experiment and… well, let’s say that I have probably approached the problem the wrong way and wasted some time along the way. Not again. I have set aside some time and worked agile enough to do the whole job, from start to finish. Nowadays there is little point in creating overlay networks by hand, except that it’s still a good learning experience. And a learning experience with Docker and networking was exactly what I was after.

When I started exploring multi-host Docker networks, Docker was quite different than it is now. In particular, Docker Swarm didn’t exist yet, and there was a certain amount of manual work required in order to create an overlay network, so that containers located in different hosts can communicate.

Follow me on Twitter

Meta

Disclaimer

The postings on this site are my own and don't necessarily represent my employer's positions, strategies or opinions!!!

The original contents of this blog (posts, photos,... anything created by the author) are (C) Copyright Marco Marongiu, 2010-2018. Unless a different license is specified in the entry's body, the following license applies: "Verbatim copying and distribution of this entire article is permitted in any medium without royalty provided this notice is preserved and appropriate attribution information (author, original site, original URL) is included".