The way attributes get merged during the chef client run may appear troublesome in a situation when you need to overwrite an array of attributes.

Imagine you want to store an array of, say, memcache pool members in attributes. You’ve chosen to do it with array, so it looks like this (attributes file notation):

default['fooapp']['memcache'] = [ "memcache-a1:11211", "memcache-a2:11211" ]

Now you want to configure different memcache pools, for different datacenters. You want to overwrite default attributes from attributes file, you also want to be able to have different number of pool members (array elements) in each datacenter. Let’s try with a roles specific to each datacenter, like this:

"fooapp": {
    "memcache": [ "memcache-b1:11211", "memcache-b2:11211", "memcache-b3:11211" ]
}

What you’ll getting on a node in datacenter “b” is:

$knife node show somenode-b1 -a fooapp
fooapp:
  memcache:
    memcache-a1:11211
    memcache-a2:11211
    memcache-b1:11211
    memcache-b2:11211
    memcache-b3:11211

Oh, of course it’s merged! You didn’t want app from colo “b” to use memcache in colo “a”!

What you could do is remove default elements using special :knockout_prefix attribute allowing for subtractive merge. Elements prefixed with this custom prefix would get removed during merge. This is however not available since Chef 11 so I’ll skip discussing it.

The idea I got is to workaround it by keeping the elements in string instead of an array, like this:

default['fooapp']['memcache'] = "memcache-a1:11211,memcache-a2:11211"

and in role:

"fooapp": {
    "memcache":  "memcache-b1:11211,memcache-b2:11211,memcache-b3:11211"
},

And then split them in a template:

<% node[:fooapp][:memcache].split(",").each do |m| %>

It’s less elegant than using array but it works.

I love the way they bring fun to tech events. Especially if it has something to do with music. Last years DevOpsDays in Mountain View, it started with screening AC/DC’s “Let There Be Rock” video with vocals replaced to some custom lyrics with “Let there be DevOps” as a chorus. Music was leitmotif of the whole event. Crew wore Blues Brothers costumes. Later on, in the evening, there was jam session as a part of the event.

Great postscript to that is David Lutz singing “Packet Loss Blues” in his car. 🙂

Yeah, actually why not sing out your tech job worries?

Another frustrated admin helping himself singing it out – “Kill Dash Nine” by Monzy:

I have recently visited fun sysadmin quiz intended as a hiring tool. The toy was so popular that they’ve started second part just for fun. Cool! I hope they are not serious about hiring people this way though. This reminded me of some questions from Google SRE hiring process, like “What is the difference between hub and switch”. Good if you are looking for IT archeologist maybe. Another interesting approach to recruiting I remember is Matt Biddulph’s idea of Algorithmic recruitment with GitHub which I think is a masterpiece but still, no more than interesting code experiment or source of contacts for head hunters.

Both tricks mentioned above may help you find some skilled and/or experienced engineers. Will they help you hunting top talents? Will they tell you anything of the candidate personality? You still need a way to filter out an asshole from joining your team, right? Here’s why.

So use toys such as quiz or algorithmic searches for fun and as a additional source for your candidates base. Then, add following rules to your current hiring process methodology:

1. Don’t test technical skills in academic like tests. At least don’t rely on that tests. Try rather to challenge ones intellect.

2. Don’t rely too much on ones public activity (GitHub, Twitter, StackOverload etc.) of which I wrote recently. Imagine there are people who are truly engaged at work, not doing anything external to their work (you don’t want to hire person writing private blogs and developing their own apps when at office, instead of working, do you?). So should they blog, twit, code in their free time. Right. Except they may have different reasons to be detached from the computer, when home, for example they may have kids, or hobby, whatever.

There may be hidden unicorns!

3. Trust you gut feeling. If possible let the candidate be interviewed only be people entirely convinced to your team values, ones that contribute good to the workplace atmosphere, ones that can smell the unicorn. Attract top talents by letting them meet cool people from your company.

If you think you may not be able to smell the unicorn, invite someone, who you think is, to the help you with the interview process.

4. Value person’s attitude and passion. Some google’s managers say humility is what is essential,  “For one startup ascertaining humility is so important, it is the first filter in the interview process” says Tomasz Tunguz.

5. I like the tip of Rajat Taneja, to Hire for UNCOMMON strength. He says “Focusing on finding candidates who have the least amount of weaknesses will lead to mediocrity. Hire for uncommon strength and then put the person in a role that uses that muscle.”

Until recently I was considering writing blogs a waste of engineers time. But then I realized that because I’m benefiting from reading other peoples blogs, writing my tech blog is then, in a way, paying back to the community, same way like contributing to open source projects is.

One disagreement about blogging I had was: why all authors writing on the same subject don’t join their forces and contribute to the wiki on the subject? Well, apparently recognition is a human basic need. I just needed to grow up to accept that fact.