The Problem

Ansible is a great configuration management platform with a very, very extensible language for expressing yoru infrastructure as code. It works really well for common workflows (deploying files, adding authorized_keys, creating new EC2 instances, etc), but its limitations become readily apparent as you begin embarking in more custom and complex plays.

Here’s a quick example. Let’s say you have a playbook that uses a variable (or var in Ansible-speak) that contains a list of tables, like this:

TL;DR:

Control + ⌘ + Shift + G Home button triple-click.

Why?

Exposing ourselves to bright screens at night while checking our Facebook feed or reddit posts might not be as harmless as it seems. Tons of research, like this and this suggest that viewing things on bright screens right before bed makes our brains think that we’re in daylight longer than we actually are and, consequently, prevent us from falling asleep sooner than we should be. This combined with our early-start culture has been shown to lead to fatigue, decreased concentration and, in some folks, depression.

Additionally, other research has shown that prolonged exposure to artificial light (like those in most offices or our phones) can, over time, damage our eyes’ ability to adjust to incoming light and weaken their sensitivity to it.

I didn’t notice any of this until a Slashdot post introduced me to Flux several years ago. Before using this application, I was usually tired and sore (I rode my bike much more often back then) most of the time, but didn’t think much of it. I went out often back then, and most of the people I came across were just as or more tired than I was, so I thought I was fine.

I was quite surprised to discover that thousands of people were members of the “Imposter Syndrome” Google+ group within my first month at Google.

I always thought that getting into Google was probably the best social proof of “making it” that an engineer could receive. The interview process is hard, gruelingly technical, relatively unforgiving and riddled with rollercoasters; many incredibly talented Googlers had to go through the process two or more times before getting in for good. (I went through it twice…sort of.) The engineering talent at Google is nearly limitless; many of the world’s most formidable and accomplished computer scientists, sysadmins and software engineers work or worked at Google doing all sorts of things.

So imagine my surprise when literally tons of engineers join a group expressing how they feel as if they aren’t good enough to be at Google or working alongside people with Wikipedia articles written after them. Perhaps it was a big joke that completely went with my head, but given the many, many internal jokes made about not being good enough to be a Googler that I came across (mostly thanks to Memegen), I had my doubts.

• Edit 2: I’ve made a few small changes to the way I’ve described Docker architecture. Thanks, /u/jmtd!

• Edit: I mentioned below that Docker containers can only run a single process. While that is true by default, it is actually not the rule. You can use Docker Supervisor to manage multiple processes within a container. Here is how you do that. Thanks, /u/carlivar!

Fact: There are at least 22 conversations arguing about the usefulness/uselessness of containers happening right now. For every person arguing about them, at least three blog articles will shortly appear telling you why containers are going to be bigger than the Super Bowl or how they are the worst thing to happen to computing since web scale became a thing.

This short post will not be any of those.

I believe in using the right tool for the job and I hate fads. I’ve also been learning about containers for the last few months and am becoming incredibly interested in figuring out how to bring them to Windows 2012 and below (Windows Server 2016+ will have them, but Microsoft will be lucky and probably scared if they saw anything above 20-30% uptake within its first two years), so here’s a short post describing what I’ve learned about them, how they work, and why they might or might not be useful for you and/or your business.

I was discussing the power of Goroutines a few days ago with a fellow co-worker. Naturally, the topic of “doing things at the same time in fancy ways” came up. In code, this is usually expressed by the async or await keywords depending on your language of choice. I told him that I really liked how Goroutines abstracts much of the grunt work in sharing state across multiple threads. As nicely as he possibly could, he responded with:

You know nothing! Goroutines don’t fork threads!

This sounded ludicrous to me. I (mistakenly) thought that concurrency == parallelism because doing things “concurrently” usually means doing them at the same time simultaneously, i.e. what is typically described as being run in parallel. Nobody ever says “I made a grilled cheese sandwich in parallel to waiting for x.” So I argued how concurrency is all about multithreading while he argued that concurrency is all about context switching. This small, but friendly, argument invited a few co-workers surrounding us, and much ado about event pumps were made.

I love writing code and building awesome stuff, but there are times where fighting the urge to Reddit for 14 hours feels like this:

When this happens, I break out my secret weapon: *The Pomodoro Technique. *The basic premise behind this technique is alternating your time between spending several minutes on nothing but working towards a certain goal (let’s call it the hot period) or deliverable and a few minutes on anything that isn’t work (*the cold period). *

Many developers and sysadmins starting out with Powershell will assume that this:

$arr = 1..10
$arr2 = @()
foreach ($num in $arr) { $arr2 += $num + 1 }
write-output $arr2

is the same as this:

$arr = 1..10
$arr2 = @()
for ($i = 0; $i -lt $arr.length; $i++) { $arr2 += $arr[$i] + $i }
write-output $arr2

or this:

$arr = 1..10
$arr2 = @()
$arr | foreach { $arr2 += $_ + 1 }

Just like those Farmers Insurance commercials demonstrate, they are not the same. It’s not as critical of an error as, say, mixing up Write-Output with Write-Host (which I’ll explain in another post), but knowing the difference between the two might help your scripts perform better and give you more flexibility in how you do certain things within them.

You’ll also get some neat street cred. You can never get enough street cred.

Computing is expensive. Desktops and laptops cost lots of money. Printers cost even more money. (Printers are really funny, actually; buying one or two isn’t so bad, but once you’re managing tens or hundreds or more laser printers and printing hundreds or thousands of pages per day, the cost of toner/ink and repair skyrocket like a SpaceX shuttle.) Desks cost even more money. Accessories cost even more money. The list goes on and on,infinitum ad nauseum.

Now that we live in an age where downloading high-def movies takes less time than starting up your car, leveraging the cloud and having people bring in their own devices has become a highly lucrative alternative. The bring-your-own-device, or BYOD, movement has picked up a lot of steam over the years, so much so that Gartner expects for “half of the world’s companies” to enact it. Over a billion devices are expected to be using BYOD by 2018, and as more and larger companies begin to take advantage of cloud computing, this trend will only accelerate.

I’ll spend the next three posts talking about three key components of most BYOD environment:

1. Virtual desktops,
2. Laptops and desktops, and
3. Mobile phones and tablets

I’ll explain who the major players involved with each component are, their importance in BYOD and some things to watch out for during considerations.

I’ve developed a system over the years that has kept my inbox mostly empty all of the time. It has worked for me even when I was getting 100+ emails/day, so I’d say it scales fairly well. It also works well even in the absence of Gmail’s additional feature set (I use Office 365 personally, but this worked when I used Gmail, Apple Mail and my own mail servers back in the day.), which is nice should you ever choose to use a desktop mail client.

This might not work for you. You might even be doing some variation of this already. If that’s the case, feel free to tell me off!

Finally, if you don’t want to worry about any of this stuff and don’t ever see yourself having to use Outlook or Mail.app ever again, try Google’s Inbox and tell me that all of this is useless in the comments!

Without further ado, this is how I email:

This Thursday, we’ll talk about a system that has been extremely critical (and extremely taken for granted) for shaping the Internet as we know it: the domain name system, or DNS for short.

Before I explain what DNS is, I’ll talk about something I try really hard to hate but ultimately can’t: Starbucks.

I go to Starbucks at least once a day. Given that Google has more coffee machines (and baristas!) sitting idle than my handy downstairs Starbucks does on even their busiest days, this is slightly embarrassing to admit. I love their drinks, but as a recovering coffee snob, I passive-aggressively hate that I love their drinks. My relationship with that Seattle staple is kind of like how a lot of people feel about Taylor Swift: they’ll hate on her forever but will never admit to playing 1989 on repeat.

Wait, that’s just me?

Okay. I can live with that.