Wednesday, March 20, 2019

Bias to Action

Prototyping in progress!
I’ve always wanted to teach. One of my favorite memories from my youth is that of teaching art classes to kids in 5th grade as part of my senior studio class in high school. I like the planning that goes into a good lesson, and the unplanned opportunities to connect with students as they learn something new. I know it’s a mild case of over-simplifying the demands on a full-time teacher given that I’ve only spent a day or two here and there teaching anything to anyone. But still, those rare occasions gave me more joy than two decades in IT.

Recently I took a turn teaching engineering to a group of students at my local homeschool co-op. It was the second of two classes I taught this semester: the first lesson was based on circuit design using the wonderful and inspiring materials from Chibitronics. The creative folks behind Chibitronics have merged technology with art, and have been around since the maker wave began earlier this decade. It’s cool stuff, and if you’ve got kids, you should look into their kits and create something amazing.

The second class was something different. I spent some time reading a lesson plan from Stanford d.school on the concept of a “bias to action.” You can read the whole lesson plan here. A summary of the lesson: the class forms groups of a few students each and use dry spaghetti and marshmallows to construct a tower. (In the lesson plan, they also include a length of tape and string, but I skipped that part to simplify the work.) Before anyone gets started, you talk briefly about a few important concepts: prototyping, failing fast, iteration, and the bias to action.

Prototyping

Prototyping is something that we don’t consider often in the infrastructure ops field, but the movement towards Infrastructure as Code promises to change that. We should build prototypes of scripts to deploy systems, of templates used to build applications, and of patterns to support web scale products. And we should hope that the prototypes fail, which leads us to the next concept: failing fast.

Failing Fast

Failing fast means you learn as soon as possible whether your proposed solution is going to work out or not. If your tower prototype collapses before your second floor is built, then you know that your foundation needs more work. You’d much rather the tower fall with two floors than ten. You prototype, fail fast to learn what didn’t work, and iterate.

Iteration

To iterate means to try again, but with the knowledge of your previous attempts (failures). Each iteration should be an improvement on your previous design. And the process repeats until you’ve developed a good solution (or in this case, a towering construction of carbohydrates). The improvement can be subtle; you're not going for a 1.0 to 2.0 release. You're looking for a 1.01a.

Bias to Action

So what’s the bias to action? That was the only bit that was new to me, too. And now that I’ve learned what it is, I find myself applying it to work ALL. THE. TIME. (Sorry co-workers, and get used to it.)

A bias to action is the tendency of an individual or group to try doing something instead of over-thinking or over-planning. It’s not a license to be reckless; it’s an approach designed to acquire empirical data quickly for the purposes of iterating on your design. An extreme counter-example would be to spend a year planning on building a 100-story tower, and then watching it fall when you build that second floor. You’ve just invested a year’s worth of time on a design that, had you prototyped it early on, would have failed fast and provided feedback for your iteration.

In other words, it's a "let's try it and see what happens" approach.


So now I’ve got a phrase to describe how we should all approach our work. Through prototyping, failing fast, iterating, and a bias to action, we can modernize any infrastructure operation.

Thursday, December 27, 2018

Back to Basics: Making nslookup more useful

As we forge ahead in to a brave new world or AI, ML, and AR, it's helpful to occasionally step back and consider some basic information technology skills that we should all possess. These are foundational skills that demonstrate functional understanding of IT principles. This post deals with one of the most basic tools in the administrator's kit: nslookup.

DNS is Everything

Thanks to DNS, we address our systems, sites, and services with human-reabable text. Without DNS, we'd be forced to recall the IP address of each system we want to connect with. Sure, you can probably memorize a few dozen /24s, but it's not practical to live without DNS. And it's always a reasonable suggestion to, when things on your network just went belly-up, check DNS. Because it's always DNS.

If ping is the first command junior IT admins learn, nslookup is a close second. And just like most IT admins are content to ping hostnames and IPs without ever looking into the richness of the command's syntax, nslookup's best tricks are reserved for those who want more from their query than a simple hostname or IP.

Before we get any farther, I'll note that for a short time nslookup was a deprecated utility. But the ISC reversed its course in 2004 and agreed to let nslookup soldier on. (Note change 1700 in the CHANGES log on the BIND 9.3 release page, which contains the all-business text that saved nslookup: nslookup is no longer to be treated as deprecated. Remove "deprecated" warning message. Add man page.).That's why you'll find it on every modern OS to this day (see this link for Microsoft's latest info on nslookup in Windows).

nslookup vs. dig

For starters, comparing these two utilities is like comparing an abacus to a TI-81: you wouldn't ever expect an abacus to produce a graph of the sine function. The same is true for nslookup: you wouldn't expect it to return a vast amount of information regarding a single host. dig is great at that.

But if you use Windows at work, and don't have access to dig, you can add a simple switch to your nslookup queries to make it return a wealth of dig-like responses for the most innocuous request.

The secret is to append -debug to your nslookup queries (if you're a one-at-at-time nslookup-er), or enter the nslookup utility with -debug for extended DNS query sessions. Instead of returning simple IP information for your hostname queries, nslookup will now return a whole host of information. That's a DNS joke. Yes, I'm sorry.

Making sense of this information will be covered in the next post in this series. In the meantime, nslookup -debug away!