Conway’s recipe for DevOps (well, sort of)

This is basically an effort to rehash Conway’s Recipe for Success for DevOps:

Work on several problems at a time

Conway was working with six problems at a time as a means to battle depression by failing to conquer a specific problem. Six problems are enough to fit your daily mood. It is more than one per day anyway. In DevOps the software stack you need to coordinate just to make your app go live is so versatile that there is always something you can work on daily even if your primary focus seems stalled. Beware though since this is also a way to not make any work at all. You can eat an elephant but somehow we seem to attract hordes of them. And then you can just stare at the monitor Hopeless.

A good strategy to combat this is what I once heard “type A people procrastinate by doing other things”. Your stack has more than six components, you can easily have more than six fallbacks should you get stuck.

If anything, please try and don’t ever break your rhythm. Interrupts cost. Context switching too.

Pick your problems with specific goals in mind

This is one thing that I suffer a lot. Everything is cool. And I want / need to know everything. In acceptable depth. Today. But this is not feasible even if we have 25h per day and no sleep. So, IMHO (and I try hard to do so) the plan is to pick problems with two goals in mind: Your current job and “the dream job” you want to land on.

Big problem

The difficult and important problem for Conway. The Architecture problem in the DevOps case. Is your running Architecture OK? Does it need improvements? Do you need something completely new? Are you to invent the next lambda architecture? How are you going to make your dent in the circle?

Your contribution to the world.
Your contribution to the world.

(Yes, you have to try to make a dent in the circle even if you’re not pursuing a PhD.)

Workable problem

Big problems mean big delays most of the time. And in trying to solve big problems you need practice. So you need to have an arsenal of problems you can work on that you can solve. They may be boring or even need repeated tedious tasks performed by you. Automate yourself out of them if you can. Flex your brain muscle so that you can work on the big stuff properly warmed up. Your current setup always has clear steps that you can walk forward. Nothing fancy that you could give a speech about, but something that you can complete during the day and feel good about it.

Book problem

I do not have a book project on my own. But over the last 20 years there have been two books that I wish I could find time to revise. I have a friend though that just finished writing a book and he seems pretty happy with the result.

If you’re writing a book, consider this as yet another problem you’re working on. If you’re not writing a book, well write something. There is always less documentation than needed.

Read a book by the way. Make reading books your book project. That’s mine too.

Fun problem

You should always have at least one problem that you do for fun said Conway. Well I guess we have Github for that, don’t we? I think my current fun project will be cryptopals. Let’s see for how long.

Enjoy your life

“The trick in life is to find out what you think is play that the fools think is work so that they will pay you to do it.”

Happiness is the single productivity booster that one can think of. Grief and depression the best demoralisers. This post about Karojisatsu really shook me. And it came during a time that I was seriously thinking about DevOps inflicted depression.

I still have no generally applicable tricks about that.

Martijn on Dual_EC_DRBG

Good friend Martijn Grooten (twitter, blog) and chief editor at the Virus Bulletin was at Athens for a day or so yesterday and was kind enough to make a presentation about Dual EC DRBG and the possible involvement of the NSA on it. The event was hosted at the Hackerspace. It was a scientifically balanced presentation with a cool explanation of how elliptic curves are used in such cases and what kind of risks this entails.

Pizzas after the presentation were curtesy of the Greek OWASP Chapter.

Racket on the Mac

Since I’ve bought “Realm of Racket” I thought that I should install Racket on the Mac. The last time I seriously looked into it it was still called PLT-Scheme.

My first choice was to use a homebrew formula. Unfortunately this requires XQuartz and I did not feel like installing it too.

My second try was to compile it from the source. ../configure –disable-gracket && make worked, but make install failed. I really did not bother with why. I just wanted to install it and play around. This was not an installation for a lot of users after all.

So I got to download the precompiled Mac binary from the web site. 364M later it was all installed and happy.

Let’s see now if I’ll go through the book top to bottom…

PS: I remembered that I owned the eBook from this Ruby Rogues episode.

ERROR:gitosis.serve.main:Repository read access denied

[ I write this for I found the solution applied to my case at the 3rd link of the 2nd page of my Google search. I had never gone beyond the first page for years. ]

So there was this gitosis repository that lived on an Ubuntu server that had to move to a CentOS one.

Thankfully EPEL still carries gitosis and I did not built it from the source. I copied over the files and was done with it.

That is until I needed to change access to one of the repositories to add a user. Said user was denied any kind of access with:

ERROR:gitosis.serve.main:Repository read access denied

There are plenty of reasons for this occur (examples), but none seemed to fit in my case, so I brute forced the search results. And at the first comment that was posted on the third link at the second page Google came up with, the solution was found.

# cd ~gitosis/repositories/gitosis-admin.git/hooks/
# ls -l
total 48
-rwxr-xr-x 1 gitosis gitosis  452 Sep 11  2011 applypatch-msg.sample
-rwxr-xr-x 1 gitosis gitosis  896 Sep 11  2011 commit-msg.sample
-rwxr-xr-x 1 gitosis gitosis  160 Sep 11  2011 post-commit.sample
-rwxr-xr-x 1 gitosis gitosis  552 Sep 11  2011 post-receive.sample
lrwxrwxrwx 1 gitosis gitosis   61 Dec 21 09:53 post-update -> /usr/share/pyshared/gitosis/templates/admin/hooks/post-update
-rwxr-xr-x 1 gitosis gitosis  189 Sep 11  2011 post-update.sample
-rwxr-xr-x 1 gitosis gitosis  398 Sep 11  2011 pre-applypatch.sample
-rwxr-xr-x 1 gitosis gitosis 1578 Sep 11  2011 pre-commit.sample
-rwxr-xr-x 1 gitosis gitosis 4971 Sep 11  2011 pre-rebase.sample
-rwxr-xr-x 1 gitosis gitosis 1239 Sep 11  2011 prepare-commit-msg.sample
-rwxr-xr-x 1 gitosis gitosis 3611 Sep 11  2011 update.sample

Yeah, you’ve guessed it by now:

/usr/share/pyshared/gitosis/templates/admin/hooks/post-update

did not exist on CentOS but

/usr/lib/python2.6/site-packages/gitosis/templates/admin/hooks/post-update

did. Fixing the symbolic link fixed the problem.

/* Oh what fun it is to chase bugs into the night */

“Hack like it’s the last day of your life”

“Hack like it’s the last day of your life, cuz one day it will be.”

I had a neighbor who studied Movie direction. He told me that their final project was a movie that they would have complete responsibility on it, from the script to the final cut. They were advised to work on it like it would be their last movie, even though it was their first. Their teacher wanted them to do so for two reasons: Because for most of them that would be their last movie and he wanted them to put their best. And also because if this was not their last movie, they would never know which one would be, but they still had to put their best on the current project.

My neighbor had a career in the Health sector but he was always proud of his movie, even though very few people actually saw it. He had done his best.

PS: Just like Sid (whose death prompted Wim Remes‘s tweet), my neighbor is also dead.

EuRuKo 2013 – a few days after

A bit more of a week has passed, so let’s put my notes in order before memory and other notes hide them away.

Euruko →
Euruko →

From the very beginning this seemed it was going to be a good conference. And why not since by entering the venue I bumped into a close friend from the 1990s whom I had not seen for a few years due to unusual circumstances.

The day began with Matz giving a keynote. And a keynote it was. It contained memories from his first Sharp computer to switching to Pascal and then to Lisp and explaining why Ruby was influenced by it. Sapir-Worf hypothesis was also included since Matz as a person who loves programming languages tried to make us all design our own domain specific language. He made the (to the point) remark that every program that we create is in fact its own programming language with which we communicate with the system and direct it to do anything we want within its abilities. Matz urged us to become language designers (remember that every interface to a program is a language) by starting with a limited domain, locate patterns, solve problems in this domain and then expand. Perfection is the enemy of the designer he said, so he also found room to squeeze the Pareto principle in his keynote, just to make sure that one is not lost in details instead of delivering a result.

Picking from the keynote and the Lisp legacy Pat Shaughnessy continued with functional aspects in Ruby and his adventures of learning Haskell in order to make a comparison and learn something new in the process. Best lines for the talk were that “memoization is just another name for caching” and that in Ruby lazy evaluation is in fact lazy enumeration and one has to keep this in mind.

Konstantin Tennhard continued with his work with Ruby and NLP. He covered a lot of aspects of NLP and how it is done and work he did with the help of JRuby and OpenNLP which I had not head of until then. He also described a gem he has built and gave examples of its usage. I guess NLP people will find this work interesting.

One of the best presentations I’ve ever watched that include Mathematics and Programming was done by Xavier Noria. How common is it that you get to hear about a proof that the square root of 2 is irrational, about the continuum hypothesis, about set theory and stuff like cardinality of a set in a Ruby talk? By his sharp remark that “programmers are so used to integers and floats that they forget the use of rationals” he went on and gave a real life example demonstrating this as an application for a betting site. Arbitrary precision and no cent lost. One pointer though. Next time that you have ZF in your slides at such a conference, translate it.

Arguably the best presentation of Euruko 2013 for me was the one by Grzegorz Witek and Simon Kroeger. They came with a real life example that Unicorn could not handle due to high load, need for many deployments per day and requirements for the fastest user experience, showed alternative plans (Puma, Reainbow, ZBattery, Thin) and why these were not follwoed thtough and how they reached to picking the commercial version of Passenger Phusion to do the job and how well it did it. A “We did it and this is how” talk where you can only admire someone with a working production setup that brings money home.

Chris Kelly walked us through parts of the source code (and macros needed to understand how Ruby works) for MRI and how garbage collection works in general and especially in Ruby 2.0. Frequent mentions to “Ruby under a microscope” were made.

Hey did you know that an ISO standard for Ruby exists? It is ISO/IEC 30170:2012 and it is a hybrid between 1.8.x. and 1.9.x. This I learned from Koichi Sasada who proved live that when you have something to say, not knowing English well is not a barrier because the audience is willing to hear.

Rubinius was the subject of Dirkjan Bussink. He explained the design behind it and that it is a good choice when number crunching is in order. Rubinius people aim for concurrency, multicore and optimization for the common case so that the programmer does not have to deal with much outside the environment of his program. He closed his presentation with a few programming mantras that are always worth mentioning like “Be nice; write type stable code”, “Write small and simple methods” and “Always benchmark your code”.

Benjamin Smith talked about rails engines and how locating patterns in the codebase and implementing them as engines helped refactoring the code for a client with a small team while the main team was working on the product. If you are into locating patterns (and you should be) when the video is put online you must watch this. As he put it “In the long term engines work out” as long as you avoid circular dependencies between engines. You can read a lot about this stuff at the rails Archives.

Many times I’ve said that Redis is the kind of software I wish I had written. So when Javier Ramirez talked about it I could not miss it. It was a general introduction for Redis to the audience and I think everyone left the room with a clear understanding of what it can and cannot do (including pubsub).

Unfortunately I missed Steve Klabnik‘s talk on Functional Reactive Ruby but from the sound of clapping it must have been a hit. I did not watch a few more presentations and the lightining talks due to other engagements and am waiting for the videos to upload so as to complete the experience.

All in all the experience of the conference was excellent, the Jazz concert great, the volunteers did a great job and in the chosen Eurovision style of presenting the conference: 12 points guys.

PS: For those interested, EuRuKo 2014 will be held in Kiev.