analogous-devAnalogous Dev Blog2022-10-14T18:39:16.424Zhttps://github.com/nuxt-community/feed-moduleThe analogous developer. Technology topics for newcomers and experts alike.analogous-dev.pngfavicon.icoCole Arendt 2022analogies-help-us-learn2020-10-26T00:00:00.000Z **analogy:** _noun_. a comparison between two things. typically for the
> purpose of explanation or clarification
Note that some definitions explicitly note that analogies are a comparison of
two "unalike" things, thereby highlighting their similarities in a certain sense.
### Why analogies are great
Learning is defined as "the acquisition of knowledge or skills through
experience, study, or by being taught." We have all learned _many_ things
in our lives, and they are typically in areas that we have spent the most
time or have gained the most hands-on experience.
However, learning is sometimes hard to "transfer" into new areas. _Related_
areas come easily (i.e. good soccer players tend to be good at futsal, because
the two are very closely related), but _unrelated_ areas, not so much. Being good
at basketball does not necessarily transfer well to rocket science, for instance.
Enter analogies! Analogies help us take experience or learning from one _unrelated_
area to another, and thereby allow us to jump from basketball to rocket science!
We cannot expect to become experts purely by way of analogies, but it is a great
way to soften learning curves, simplify topics, and transfer our experience!!
Plus, they're fun!
### An example
I love math and technology, and am a bit of a nerd. Many of the people I care
about are either not nerds or are not nerds about math and technology. As a
result, I use analogies to help explain my world to them without requiring them
to become math/programming nerds.
For instance, I might explain that "Calculus is like Driving a Car." This is a
useful analogy I used when I was teaching calculus. To help give newcomers an
intuition about calculus, I would draw upon their experience driving cars! Need
help understanding derivatives? Think about the spedometer! Need help
understanding integrals? Think about the odometer!
None of us is capable of _really_ understanding things for which we have no
context, background, or logical foundation for. Analogies help us bridge that
gap and provide an easier entry-point based on similarities of otherwise unlike
things.
### How we use them here
On this site, we love to use analogies to explain tech topics and things that
are otherwise complex or tricky to understand. As a result, when sharing an
analogy, we will generally shoot for a few highlights:
- The analogy
- The high points
- The breakdown
#### The Analogy
We begin with an analogy! Most analogies will require a bit of
elaboration and qualification. At first glance, perhaps it seems strange to
relate calculus to driving a car.
#### The High Points
If the analogy is good, there are some very clear points of similarity that will
help explain the "less accessible" topic. The high points of an analogy are its
focus and primary value, so this is where you should spend the bulk of your time
when learning.
#### The Breakdown
Every analogy "breaks down" somewhere. We should always acknowledge the limits
of our tools, and every analogy has its limits. Generally, it is best to focus
on the high points of an analogy, lest we confuse newcomers with our
qualifications. However, in this context we will briefly mention our
shortcomings as a highlight for where you can dig deeper. Further, our
shortcomings can help us understand the desired topic by establishing
guard-rails.
To take our example, while driving a car gives you an _entry point_ into
calculus, it will not make you an expert. At some point, you _do_ have to master
the definitions and mechanics of derivatives and integrals. Also, I can't think of
any way relate an oil change to calculus, so let's not get too literal.
### Closing
It is worth noting that this site is named for analogies. Coincidentally, I
will often focus on them. However, I'm not very creative. As a result, many
posts on the site will not be about analogies at all. However, my aim is that
the theme of explaining topics in an accessible way will remain.
Next time you are trying to explain something complex, do some thinking to see
if an analogy will help you out! A well-thought-out analogy can be very useful
and a lot of fun! Of course, others fall completely flat, but that's fun in its
own way.
Finally, if analogies are ever actively hindering your understanding or just making
you more confused, _please_ drop them. If an analogy is relating to something you have
no context for, it may be better to try another or to just ignore the analogy altogether.
After all, the focus is learning!
]]>debugging-kerberos-is-like-hades2020-12-19T00:00:00.000Z Debugging Kerberos is like Hades
Hades is the Greek God of the underworld or sometimes a reference for the place
of the dead, generally. I promise, this analogy is not _completely_ out of left
field.
Kerberos is a computer protocal developed by MIT and used in many enterprise
settings for authentication and authorization. However, it gets its name from
Cerberus - the guard dog of Hades. As a result, feeling close to Hades when you are close
to Kerberos is reasonable at some level.
Although there are many aspects of Hades we could highlight for the purposes of
our analogy, we will focus on a few: heat, torment, eternal, inexplicable,
aimless, and generally terrible.
### The High Points
Why is debugging Kerberos so awful? A couple of reasons below. Particularly,
reasons that can encourage us how _not_ to make software:
- **No documentation** - Ok there _is_ documentation, but much of it is just too
theoretical to be useful. Further, much of programming in the 21st century is
search-engine-foo. Unfortunately, searching Kerberos issues generally leads to
Microsoft documentation from Windows XP. Despair usually ensues. If you have been
there, I promise you are not alone.
- **No logging** - The next best problem for software: no logging. Kerberos has
a knack for giving useless error messages or error messages that need to be run
through a universal translation engine (which does not exist). Good luck finding
out what a `Generic preauthentication failure` is.
- _TIP_: Set the environment variable `KRB5_TRACE=/tmp/somefile.log` when
debugging a Kerberos client. The
[client-spec](https://web.mit.edu/kerberos/krb5-devel/doc/admin/troubleshoot.html)
sends client debug logs to that location!
- **Little direction** - This goes alongside the previous items. If you have
theoretical docs and useless logging, the usual sources of direction and "next
steps" are lost. Internet tutorials and a general sense for what I want to
accomplish are about the only places I have found direction for Kerberos issues.
Keep at it! Perseverance _usually_ wins out in the end.
- _TIP_: As with most debugging, try to simplify your case as much as possible
first. Then slowly add pieces until you get to a working state.
- **Cryptic configuration** - To properly configure Kerberos, you typically need
to master a bunch of unusual terminology (realm, kdc, ticket, cache, keytab),
wade through a myriad of brackets, and pay particular attention to case. Not to
mention the importance of tricky UDP networking rules and the [directionless
failure](https://social.technet.microsoft.com/Forums/windowsserver/en-US/7fbece1a-9e72-4ed1-b8d6-1a08f633f0bd/trouble-joining-linux-server-to-ad-domain-in-aws-failed-to-find-dc-for-domain?forum=winserverDS)
you get if you misstep. Tread carefully! A slew of confounding error messages
are watching your every move.
- **Little tolerance for humans** - What is the difference between
"analogous.dev" and "ANALOGOUS.DEV"? As far as your browser is concerned,
nothing. As far as humans are generally concerned, maybe one reads more like
shouting? As far as Kerberos is concerned, `Realm not local to KDC while getting
initial credentials`. We humans need help doing software. Please help us,
Kerberos. Make your logs better.
- _TIP_: Yes, case matters in domain names to Kerberos. It feels like
flailing, but in some cases it can actually help!
Put all of this together, and what do you get? It may not be Hades, but it is
pretty close to eternal torment.
### The Breakdown
Now that I have completed that rant, Kerberos has some really nice things about
it. It is also worth noting that it has achieved success by being a pretty
brilliant piece of software.
- Pass-through authentication to backend services
- Granular access controls
- Minimal password usage
- Integration into Windows
- Integration with security keys
- Quickly expiring sessions
This makes the protocol highly desirable for security, particularly in the enterprise. However,
with the internet age upon us, browser-based paradigms like OAuth2 and JWT (JSON web tokens)
are shaping up to replace Kerberos for most of these purposes.
In many large enterprises and backend systems (like databases), Kerberos still rules the day.
### Closing
Although Kerberos is a necessary fixture in some peoples' lives (like mine) and
nonexistent in others, I am hopeful that it can teach us important lessons about
what makes good software and the interesting interplay of obligation versus
enjoyment.
At very least, community, empathy, and a bit of laughter can get us through our
struggles with this beast.
]]>devops-is-like-building-sand-castles2020-11-05T00:00:00.000Z Doing DevOps work is like building sand castles!
First, I'm not a _real_ DevOps person, but bear with me. When you build sand castles
at the beach, you are aiming to:
1. build something architecturally sound
1. build it on a decently realistic timeline (or else the tides will eat it for lunch)
1. build something that is close to destructive forces (waves). Or for extra
points, involves them (i.e. fill an epic moat)
1. do something productive (after all, you could just lie down in the sun instead)
1. defend yourself from an imaginary invader
DevOps is similar to these things! Of course, the primary component in DevOps
is enabling others (Developers) and making their work more productive.
_That_ part of the job is more like holding a ladder (more on that another day).
I am concerned here with mostly what a DevOps person _does_ or _builds_.
### The High Points
1. DevOps involves building and maintaining digital architecture (i.e. sand castles). Whether using
virtual machines, containers, or "infrastructure-as-code", the end goal is a castle.
1. DevOps engineers often work hard and work quickly, as their work is in high
demand by the teams that depend on them. Timeliness is important
1. Although a system without any users would be easier to maintain, the destructive
force that is "users" will assault the DevOps engineers' well-architected fortress.
1. Not any sand castle will do. DevOps engineers often care about building
things correctly. Like mathematicians, they also do not want to do the same
thing over and over again ("toil").
1. Often times DevOps engineers are concerned about _actual_ invaders... but to
prepare, they will load test their architecture with imaginary invaders (to be
sure it will work) or get their coworkers to test it out.
Some of these connections are very helpful. For instance, a load test becomes
"simultaneously building a sand-castle and trying to throw waves at it, to make
sure it is strong." Or deploying an update to a cluster is "automatically
reconfiguring 40 sand-castles and hoping all of them keep standing." Perhaps in
a moment of deep thought, "I can't figure out why my sand-castles keep crashing.
The waves aren't even that big today, and they did just fine yesterday."
A Docker container is a sand castle, let's say, and a docker _image_ is a
template that allows me to build new sand castles super fast when I need them!
The explanatory power is wonderful!
### The Breakdown
The most dangerous thing about this analogy is that it is quaint and accessible,
and could therefore easily be used to over-simplify or demean the work of DevOps
engineers. However, these engineers are building incredibly intricate
architectures that run some of the most lucrative businesses on the face of the
planet. It is work that should not be taken lightly! Just because sand-castles
rarely have a lucrative or serious purpose does not mean that DevOps work shares
that trait.
A related breakdown: the imaginative childishness of sandcastles coupled with
"digital" architecture that cannot be objectively seen can lead down a similar
path suggesting that DevOps work is not productive. It is worth remembering that
these engineers are actively building, maintaining, and improving the foundation
that the _entirety_ of most technology careers are standing upon. The
twenty-first century would not look the same without these contributors!
As such, I think this analogy is most productive when an engineer describes their
_own_ work this way. An observer proposing the analogy could come across as demeaning.
Perhaps a better way to think of it as an external observer:
> Wow. This person is building and maintaining multi-dimensional _real_ castles
in another universe that I cannot see with my eyes, or even understand, but
which I am dependent on for my twenty-first century lifestyle. Thank you
### Closing
I have tremendous respect for the Operations team that I work with. They do
amazing work and really keep the rest of the teams rolling smoothly! As someone
who occasionally dabbles in their area of expertise, I have seen that it can be
hard to explain the topic to others. This is my feeble attempt at explaining the
idea to those outside the field.
I have to say, it has been a recurring analogy in discussions with my wife, who
does an amazing job being interested in my digital playground. If you need me,
I'll be building sandcastles with the kiddos.
]]>linux-capabilities-are-like-superpowers2021-03-15T00:00:00.000Z Linux Capabilities are like Superpowers
The number of superpowers out there in the imaginations of content creators is
simply astounding. Just check out the [X-Men
universe](https://x-men.fandom.com/wiki/Category:Powers), if you don't believe
me! However, most people tend towards the common ones (flight, super strength,
invisibility, teleportation, etc.). There are also _real life_ super powers like
empathy, perseverance, forgiveness, and love... I digress.
**Linux Capabilities**, on the other hand, are a notion of providing "advanced
access" to certain programs on a linux computer. If you have ever heard of
"sudo" (short for "super-user do"), you are on the right track! The basic idea
is that most programs only get access to do certain things (walk, talk, sleep,
etc.), but _others_ can be given access to do _more_ (like restart the
computer).
If you are not familiar with "linux" just think about a normal computer. Linux
is a computer "Operating System," which means it is the foundation for all of a
computer's computering. Other common Operating Systems are Mac and Windows.
Linux is a lovely computer operating system with amazing support for using a
terminal (i.e. no point and click, no mouse, only typing). Believe it or not,
that turns out to be an _amazing_ thing for programmers!
The Windows analog to linux capabilities would be "Administrator" and some
notion of privileges (sorry, I am not a Windows expert). Where Windows is used
for most desktops, Linux basically runs most of the world's [computer
infrastructure (digital sand castles)](../devops-is-like-building-sand-castles)
for hosting websites, databases, etc.
### The High Points
- Super powers are special, which means they are not given often. (If they were,
they would not be "super"). In an ideal world, not many services would require /
have access to these privileged capabilities, so that your digital world is more
secure!
- Say a crime requires super strength, and the crime occurs. Who did it!? Well if only one
person has super strength, it is much easier to point the finger than if everyone does!
- To maintain the analogy, if nobody has super strength, the crime _cannot_ happen!
- Part of the value of containers (mini-sand-castles) in the modern world is
_precisely_ because of the isolation that they provide, often in terms of access
and *capabilities*. You can give [linux capabilities to containers
too](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities),
but most admins would rather not (see the previous point)!
- Super powers are widely varied. So are linux capabilities! One will let you
change ownership on random files (like being the title office for the computer -
`CAP_CHOWN`), while another will let you define the time (who wouldn't love this
in real life? - `CAP_SYS_TIME`), and another will allow you to awake the
computer at any time (`CAP_WAKE_ALARM`). Hopefully it makes sense why these
should be closely guarded. Just like you, the computer does not want
everyone to be able to wake them in the middle of the night for no reason!
### The Breakdown
I love the idea of super powers just as much as the next person. Ok, you're
right, my 5 year old probably likes super powers more. In any case, "real life"
super powers are generally more practical and useful than linux capabilities for
things like fighting crime, capturing criminals, and saving the world.
Moreover, they are definitely going to stick in your mind a lot more vividly
than `CAP_SYS_TTY_CONFIG`. And who knows what a TTY is?
([TeleTypeWriter](https://www.howtogeek.com/428174/what-is-a-tty-on-linux-and-how-to-use-the-tty-command/) - a place to type
commands - now you know!)
This is why software people _love_
[documentation](https://man7.org/linux/man-pages/man7/capabilities.7.html), even
if it is not pretty, because there is basically zero chance of my remembering
stuff like that.
### Closing
Linux capabilites may be less magical, mystifying, and memorable than super
powers, but for people (like me) who play in digital sand castles for a living,
they are definitely the next best thing.
After all, I may not be fighting crime and saving the world, but keeping the
hackers from having super powers just may prevent the need for crime fighting in
the first place!
]]>