Alex Kraker – Blog

Learn Python Quickref

Sun, 28 Dec 2025 00:00:00 +0000

This is my fairly opinionated quick reference on how to learn Python. This isn’t so much a guide as it is something to launch from. There are already plenty of guides. I’m writing this with the novice in mind, but the seasoned programming veteran may derive something useful here.

Learn by doing

Learn by doing seems to trump most other methods for learning a programming language. This is the most bang for your buck in my humble opinion. Minimum viable programming you might call it.

Books on learning Python

I’m kind of old school and I’m a book learner; not everybody is though. It’s worth trying different approaches until you figure out what works for you. Here are the Python books I most often recommend:

Automate the Boring Stuff with Python by Al Sweigart. FREE online!
Learn Python the Hard Way by Zed A. Shaw
Think Python by Allen B. Downy. FREE online!
This may be compelling to the academic; the treatment is through the lense of computer science.

Video series

Learn Python with Socratica

Python Development Environment

Install Python for your OS.

Python IDEs

I’m partial to VSCode for just about any type of development these days. For the novice, my advice is to learn one general purpose code editor (not necessarioy an IDE…) like VSCode and stick with it for a while.

VSCode + Microsoft’s Python extension is probably fine to start.
PyCharm if you really must have a Python IDE.

Python Interpreter

A quick note about the Python interpreter. I think this is an often overlooked tool when first learning Python. After Python is installed you should be able to just type python into a terminal and start the interpreter.

i❯ python
Python 3.13.9 (main, Oct 14 2025, 00:00:00) [GCC 15.2.1 20250808 (Red Hat 15.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
Ctrl click to launch VS Code Native REPL
i>>> message = "Hello World!"
i>>> print(message)
Hello World!
i>>> quit()

This comes in super handy to try stuff out interactively while you’re coding. In my opinion this is all the “IDE” you need to start with.

You can also just run scripts in the terminal using the python interpreter.

python on  main is 📦 v0.1.0 via 🐍 v3.13.9 on ☁️ (us-east-2)
i❯ python ./main.py
Hello from python!

I’m a big proponent of the Unix as an IDE philosophy. A little Linux CLI goes a long way; learning the Linux CLI is a bit like having developer super powers.

Supplementary resources

Python Tutor Visual Debugger and AI Tutor
Python Regex Tester
Awesome Python

General advice

I recommend picking 2-3 learning resources to use. When I’m learning a new programming language (or other IT skill) I usually pick a combo of some kind of hands-on learning like Exercism and a solid book resource. Even when working through a course or a book I recommend getting hands-on as quickly as possible to reinforce the learning that’s happening.

Technical Learning

Sun, 07 Sep 2025 00:00:00 +0000

Photo by Nick Morrison on Unsplash

Technical Learning

I’ve always been interested in what I like to call meta-learning or ways that I can be a more effective learner. This goes all the way back to my school days and I remember learning about ways that drawing mind-maps was more effective for visual learning and that da Vinci kept notebooks, and so I started doing that too. I started trying to capture notes in these tree-like mind-maps. I kept moleskine notebooks for years. I also read a book on speed reading, but I must confess even after lots of practice I was never very good at it. Maybe I just didn’t get it, but it felt like just glorified skimming to me. But I did pick up some habits around getting a sense of the overall structure of a book or chapter and making multiple passes at the information each with a different purpose. For technical learning I very rarely read every word on the page.

Technical learning

In terms of technical learning of skills used in software engineering, infrastructure engineering, cyber engineering… basically any of the term + engineering where the engineering being done is solving problems with computers, there’s a few techniques that I’ve picked up which have served me well.

Skip to the tl;dr if you’re short on time.

Spaced Repetition Memory

I first learned about spaced-repetition memory when I was experimenting with polyphasic sleeping, and the author of supermemo has also written about this subject. But, where I first learned about the power of using spaced-repetition memory in relation to learning a skill like programming was through this article by Derek Sivers.

Memorizing a programming language using spaced repetition software

Spaced-repetition software (SRS), I use Anki, is a force-multiplier when learning any technical subject. It’s particularly useful when studying for certification exams, I’ve found.

Type it out yourself

I can’t remember where I first received this advice, but when learning something like a programming language, type out all of the examples, exercises and labs yourself and get it to run. There seems to be a mind-body connection and muscle memory plays an important part in learning something like a programming language. This also forces you to slow down and really ingest and understand what you’re learning. I think the tendency is to want to just copy and paste examples from books or tutorials into the code editor, but a lot more value is derived from typing it out manually. This is the active learning required to really understand something like a programming language in a way that sticks with you.

I always learn this way when learning something like Ansible, Terraform, Python, etc.

Anki has a feature where you can type out the answer. I’ve found this really useful for memorizing terminal commands and syntax.

Labbing

There’s no substitute for real-world hands-on experience but working out engineering challenges in a lab environment is a decent facsimile I’ve found.

This is the “learn thing the hard way” approach that has become a marketing moniker for titles such as “Learn Python the Hard Way” or “Learn Kubernetes the Hard Way”. When choosing study materials I think at least one resource should follow this approach where the learner is encouraged to work through the examples or labs while following along with the material. If the material doesn’t have it you should invent your own.

Creating your own homelab can be a great way to learn hands-on, but you don’t need to. Most of the time I find myself spinning up VM’s in VirtualBox using Vagrant right on my workstation. All you need is a laptop and some VM’s. For learning some topics like networking, dedicated hardware is useful though.

I highly recommend automating building lab environments with a tool like Vagrant. There should be as little friction as possible between making a mistake that potentially breaks your environment and being able to just tear down and rebuild. It’s important to have the psychological safety-net to allow for experimentation, trying things, and knowing it can be easily rebuilt. The learning process can and should be a bit messy. Very much like the creative process. You have to break a few eggs to make an omelet sort of thing.

Project-based learning

In my experience nothing quite solidifies technical skills I’ve learned quite like working on a project using those tools. I’ve been fortunate in my work that often I’ve had something directly related to what I was trying to learn that I needed to build or fix. But in other cases I’ve learned a ton on my own either putting together some automation for my homelab build, adding a feature to an open source project or just building something I thought should exist.

It’s my opinion that you don’t really know a thing until you’ve built something with it. I stand by this.

No amount of book learning, certification exams, or fill-in-the-blank is a substitute for being able to build something with what you’ve learned. In fact, I think as soon as you can get your hands on a project to build alongside coursework, books, or tutorials, that’s the best way to learn. It also helps if it’s something you care about. Personal projects or work projects tend to be the best I’ve found.

I’ll often start a project before I’m done working through whatever learning materials I’m using for that skill. This quickly uncovers the gaps in my learning and it forces a different kind of attention to the source material that’s necessary to solve problems. The information becomes more sticky too as your brain starts to create a more accurate mental model of what you’re trying to learn as it makes links and associations with the hands-on project.

Treat primary sources like books, courses, or tutorials more like references. Project-based learning is where the real learning happens.

Don’t just take my word for it either.

Self-directed, project-based learning by Seth Godin

Take notes

I’ve been a religious note-taker going all the way back to my highschool days. Note-taking seems to be a common habit among all of the really high performing technical professionals I’ve encountered over the course of my career.

I don’t think it matters so much how you do it though, I’ve seen a variety of methods used. But habitual note-taking seems to be a differentiator.

I’ve already written extensively on how I manage my personal knowledge base if you’re curious to learn more about how I do it.

Quality primary sources

As with most things, quality matters. I also think it pays dividends to put effort in up front in sourcing quality learning materials. Often I’m working a full time gig while also trying to improve my skills and advance my career. I don’t have a lot of time to waste on inferior learning materials.

I think it’s well worth it to spend a little money on a book or a course if it’s well regarded. I’m a book learner, so I’ll often find myself purchasing at least 2-3 books on whatever subject I’m trying to learn. I typically base this on researching what are the most recommended or well-regarded books on that topic. There’s usually 1-2 that are widely considered the de facto standard on some topic.

In terms of book sources I think the material should be progressive and I think the best sources encourage the reader to follow along by doing the examples or labs themselves.

Ansible for DevOps by Jeff Geerling is one of my favorite examples that does this really well.

Another great example is The Kubernetes Book by Nigel Poulton.

(These aren’t affiliate links, I just really admire their work)

It’s not uncommon for me to bounce between 2-3 primary sources for learning something. I don’t think the learner should rely on just one book, course, or tutorial to learn a thing.

tl;dr

If I had to sum up the most effective way that I learn it would be:

Find 2-3 well-regarded primary sources to learn from whether it’s books, courses, or tutorials.
Work through the learning materials and type out the exercises, terminal commands, or labs manually yourself and get them to run.
Create a lab and automate it with tools like Vagrant and VirtualBox.
Pick a project you’re interested in to hack on and work on it alongside while you’re learning.
Supplement by taking notes and doing Anki flashcards.

That’s it. Have fun learning!

RHEL 9 kmod-kvdo bug

Sat, 02 Aug 2025 00:00:00 +0000

The kmod-kvdo module is used to enable VDO in kernel usespace. On RHEL it’s primarily used to thin provision logical volumes with LVM. See the links below.

Useful links

Upstream open source dmo-vdo/kvdo project.
RHEL 9 Introduction to VDO on LVM

Install & enable kvdo

Install kmod-kvdo:

dnf install -y kmod-kvdo

Enable kernel module kvdo with:

modprobe -v kvdo

Under normal conditions, this works to install and enable the kvdo module for RHEL, but as I’ve shown below, it’s broken for RHEL 9.6.

RHEL 9.6 kmod-kvdo bug

There was a bug opened that was closed as resolved for enabling kvdo for the RHEL 9.6 kernel:

https://issues.redhat.com/browse/RHEL-61201

But, I’ve found this bug is still unresolved in the latest version of RHEL 9.6.

I tried opening a new bug, but I don’t have access to the RHEL project in Jira, so I opened a developer feedback ticket:

https://issues.redhat.com/browse/RHDFEED-1283

Hopefully this get’s to the right place!

According to the Red Hat Bugzilla - Migrated Products page I’m supposed to be able to submit bug reports for RHEL 7/8/9 in Jira now. Do I need to submit a bug report about not being able to submit bug reports? If any Red Hat engineers happen upon this, let me know!

Steps to reproduce

Install or update to RHEL 9.6

dnf update -y

Verify RHEL release and kernel release. A reboot may be necessary to load the latest kernel.

[root@rhel9b ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux release 9.6 (Plow)

The system should be on the latest kernel release, 5.14.0-570.30.1.el9_6, as of this writing.

[root@rhel9b ~]# uname -r
5.14.0-570.30.1.el9_6.x86_64

Install kmod-kvdo which provides the kvdo kernel module

dnf install -y kmod-kvdo

Note the version of kmod-kvdo that’s installed:

[root@rhel9b ~]# rpm -q kmod-kvdo
kmod-kvdo-8.2.5.10-161.el9.x86_64

Attempt to enable the kvdo kernel module:

[root@rhel9b ~]# modprobe kvdo
modprobe: FATAL: Module kvdo not found in directory /lib/modules/5.14.0-570.30.1.el9_6.x86_64

Additional notes

One interesting thing I noticed while troubleshooting is that the kmod-kvdo package appears to have been compiled against the 5.14.0-568 kernel release:

[root@rhel9b ~]# rpm -ql kmod-kvdo
/etc/depmod.d/kvdo.conf
/lib/modules/5.14.0-568.el9.x86_64
/lib/modules/5.14.0-568.el9.x86_64/extra
/lib/modules/5.14.0-568.el9.x86_64/extra/kmod-kvdo
/lib/modules/5.14.0-568.el9.x86_64/extra/kmod-kvdo/vdo
/lib/modules/5.14.0-568.el9.x86_64/extra/kmod-kvdo/vdo/kvdo.ko

Note the /lib/modules/ path.

This doesn’t match the installed kernel:

[root@rhel9b ~]# rpm -q kernel-core
kernel-core-5.14.0-362.8.1.el9_3.x86_64
kernel-core-5.14.0-570.30.1.el9_6.x86_64
[root@rhel9b ~]# uname -r
5.14.0-570.30.1.el9_6.x86_64

In fact, there doesn’t appear to be a 5.14.0-568 kernel release available in the base repositories:

[root@rhel9b ~]# dnf repoquery kernel-core-5.14.0-568*
Updating Subscription Management repositories.

This system has release set to 9.6 and it receives updates only for this release.

Last metadata expiration check: 0:40:22 ago on Sun 03 Aug 2025 03:48:53 AM UTC.
[root@rhel9b ~]#

Workaround - build from source

Building from source seems to be a viable workaround until the Red Hat engineers have had a chance to fix the bug or an update to a newer release with the bug fixed becomes available.

Fetch the latest source tar ball from the dm-vdo/kvdo/release.

wget https://github.com/dm-vdo/kvdo/archive/refs/tags/8.2.6.5.tar.gz

Untar the tarball

[root@rhel9b ~]# tar xf 8.2.6.5.tar.gz

Compile and install

cd kvdo-8.2.6.5/

make

make -C /usr/src/kernels/`uname -r` M=`pwd`

Install

make -C /usr/src/kernels/`uname -r` M=`pwd` modules_install

Enable kernel module

modprobe kvdo

Verify that it’s enabled:

[root@rhel9b kvdo-8.2.6.5]# lsmod | grep ^kvdo
kvdo 860160 0

(Optional) Enable kvdo persistently across reboots

echo kvdo > /etc/modules-load.d/kvdo.conf

Local Development Testing with RHEL and Vagrant

Thu, 10 Oct 2024 00:00:00 +0000

Sometimes I need to be able to spin up a Red Hat Enterprise Linux (RHEL) server in a local development environment for testing. For many use-cases spinning up a free Rocky Linux image is sufficient to test in an environment that’s a relatively close facsimile to a RHEL-proper environment. But for those cases where you can’t get around needing to test in a RHEL environment then there’s a need for a RHEL image with a subscription attached. Red Hat’s Developer licenses are good here, with the ability to have up to 16 systems for developer testing. More on this later…

Vagrant is really handy for spinning up servers for testing. A primer on this tool is out of the scope of this post but if you’re not familiar with it I recommend Vagrant’s own tutorials to help get you started.

I use Vagrant + VirtualBox on my Linux Workstation as a local development environment for testing. I’ve found this really helpful for rapidly iterating over things like Ansible scripts among other things. Ansible is declarative and the idea of immutability is important when writing good code. Vagrant makes it easy to spin up and destroy servers so that I know I’m always starting with a system in the same state. Otherwise you could end up with some “configuration drift” as you’re developing…

Installing prerequisites Vagrant and VirtualBox

If you haven’t already, install Vagrant and VirtualBox.

NOTE: Make sure you install the Vagrant compatible version of VB.

Red Hat Developer Subscription

If you don’t have one already, sign up for a free Red Hat Developer Subscription:

Red Hat Developer Subscription for Individuals

NOTE: Make note of your username and password you used when you registered for your account.

Create your project

mkdir vagrant
cd vagrant

Initialize the project. This will create your initial Vagrantfile.

vagrant init

~/vagrant $ vagrant init
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Install vagrant-registration plugin

Install the vagrant-registration plugin. This is a plugin that we’ll use to automate registering/deregistering our RHEL box whenever we spin it up or tear it down.

vagrant plugin install vagrant-registration

Setup the vagrant-registration configuration

Edit the Vagrantfile you created with the following:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
 # vagrant-registration plugin settings
 config.registration.username = ENV['SUB_USERNAME']
 config.registration.password = ENV['SUB_PASSWORD']

 # RHEL box...

end

Configure your Red Hat username and password as variables in your environment:

export SUB_USERNAME="<rhnusername>"
export SUB_PASSWORD="<rhnpassword>"

Configure your RHEL box

Edit the Vagrantfile adding the following code after the registration block.

...

 # RHEL 9 box
 config.vm.box = "generic/rhel9"

end

You’re file should now look like this.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
 # vagrant-registration plugin settings
 config.registration.username = ENV['SUB_USERNAME']
 config.registration.password = ENV['SUB_PASSWORD']

 # RHEL 9 box
 config.vm.box = "generic/rhel9"

end

Spin up a RHEL 9 VM

Create and start your RHEL 9 VM.

vagrant up

NOTE: Vagrant automatically registers the new system with Red Hat.

SSH into the machine and verify the subscription.

vagrant ssh

sudo subscription-manager status

You can also see this server registered as an active system in your Red Hat Customer Portal - Subscriptions and then by navigating to the Systems tab:

Destroy…

You can destroy the VM when you’re done testing, or as many times as you need when testing. The vagrant-registration plugin should automatically deregister your instance whenever you destroy (or halt, e.g. vagrant halt) the instance.

vagrant destroy

That’s it!

Additional resources

If you’re interested in taking a peek at how I use Vagrant, feel free to puruse my vagrant repository.

References

My Personal Knowledge Base (aka "Second Brain")

Thu, 09 Nov 2023 00:00:00 +0000

Photo by Jan Kahánek on Unsplash

I’m a religious note-taker. Back in my school days, I kept lots of notebooks and I had a habit of always carrying around a Moleskine and jotting down ideas, writing notes, or journaling. Now many years later I’ve developed a habit of writing my notes in digital form. Mostly this was so that I could make them searchable. At first, my notes started out as a few text files but eventually, I started writing all of my notes in Markdown. They’re still text files, but Markdown is an easy-to-read and easy-to-write markup that renders nicely to HTML.

Here’s an example from my notes:

---
title: OSI Model
date: 2020-10-06 07:42
---

**OSI:** Open Systems Interconnection

1. [Layer 7 - Application](2020-10-11--16-57-07Z--layer_7.md)
2. [Layer 6 - Presentation](2020-10-11--16-52-39Z--layer_6.md)
3. [Layer 5 - Session](2020-10-11--16-46-48Z--layer_5.md)
4. [Layer 4 - Transport](2020-10-10--18-46-30Z--layer_4.md)
5. [Layer 3 - Network](2020-10-10--18-44-39Z--layer_3.md)
6. [Layer 2 - Data Link](2020-10-10--18-43-20Z--layer_2.md)
7. [Layer 1 - Physical](2020-10-10--18-41-00Z--layer_1.md)

Mnemonic:
_All People Seem To Need Data Processing._

## References

* https://www.freecodecamp.org/news/osi-model-networking-layers-explained-in-plain-english/
* [Wikipedia - OSI model](https://en.wikipedia.org/wiki/OSI_model)

Zettlekasten and Obsidian

At some point, I stumbled across how to maintain your own personal knowledge base as a Zettelkasten. I call mine my “second brain”. I’ve experimented with maintaining a personal wiki in Vim with things like vimwiki and wiki.vim, and even learned Emacs so that I could try to organize my life with org-mode.

If you’re interested in the Zettlekasten idea I recommend checking out:

Zettlekasten - Getting Started
How to Take Smart Notes by Sönke Ahrens

Text editing

These days I use Obsidian to take notes and maintain my personal knowledge base. After spending countless hours shaving yaks with my Emacs or Vim configs I’ve realized that the text editor you use to write and maintain your notes isn’t that important. It’s the activity of taking notes that is. Obsidian gives me most of what I need out of the box and I’m less likely to get distracted with tweaking vim configs. Obsidian has a vim-mode so that I can still use modal editing which is a requirement for me with any text editor. I think many Linux Sysadmins are similar in this regard. Obsidian also has a “mind-map” feature that I think is pretty neat but I don’t use it that often unless I’m showing others how neat I think it is. Ultimately what text editor is used to maintain your knowledge base isn’t that important. It’s more important that it makes taking notes relatively painless and doesn’t get in the way too much.

Writing notes in Markdown

Since all of my notes are just a collection of Markdown files I can easily port them to any text editor or knowledge-base tool that supports that. This website is a Hugo static site and I write all of my blog posts in Markdown. This is much easier than writing HTML and Hugo just renders the .md files into HTML for me in milliseconds when I build the site.

alexkraker.com on  dev [!?]
i❯ hugo
Start building sites …
hugo v0.116.1-3e1ea030a5897addaf9d113d0826709fe07f77c0+extended linux/amd64 BuildDate=2023-08-01T07:24:54Z VendorInfo=gohugoio


 | EN
-------------------+-----
 Pages | 18
 Paginator pages | 0
 Non-page files | 3
 Static files | 4
 Processed images | 0
 Aliases | 1
 Sitemaps | 1
 Cleaned | 0

Total in 83 ms

This also made publishing all of my notes online relatively easy… more on that later.

If you spend a lot of your time in the digital world like me I highly recommend learning Markdown and taking notes in this markup. Many platforms that are used in the digital world usually have some sort of Markdown support too. Jira, Zendesk, Google Chat, Slack, Discord… just to name a few that I’ve discovered support writing in Markdown syntax. I write Markdown everywhere I can now without really thinking about it.

If you’re interested in learning Markdown I recommend:

Markdown Guide - Getting Started
Daring Fireball’s Markdown: Syntax is the original spec.

Version controlled backups

Since my notes are all just text files I back them up to a Git repository in the cloud. Using Git also has the added benefit of version control for my notes and I can easily manage sharing my notes between multiple devices by cloning the repository to that device and using git pull and git push to sync my notes. My notes repository is hosted on GitHub and I’ve made it public so that I can easily share them with others if I want to.

There’s a community Git plugin for Obsidian that syncs my notes to my repository at regular intervals so I don’t even have to think about it.

Owning my data and portability

Because my notes are just simple text files I don’t have to worry about them being stored in some type of proprietary data format. My notes are portable and can be edited anywhere I have a basic text editor. I also own my notes data. Long-term I don’t run the risk of losing them if they’re stuck in a proprietary platform like Roam Research, for example. On long enough time scales most proprietary tools and data formats may not exist, just look at the Killed by Google for lots of examples. I’d hate to lose the countless hours I’ve spent on my “second brain”. In other words, it’s important to me that my notes are future-proof.

Structuring my personal knowledgebase

Before I learned about Zettelkasten I tried to organize my notes into folder structures and hierarchies. But after a while this becomes difficult to maintain and thinking and making decisions about the “taxonomy” of your knowledge base can become a barrier to actually writing notes. Nowadays my notes are all just a single folder. With a Zettelkasten you create links between notes. This is a bit like hyperlinking. This is more like how your brain works. The linking is what gives structure to your knowledge base and this develops organically over time as you tend to your digital garden.

After a while, some of your notes start to accumulate back-links from other notes that are related to it. In Obsidian these are called “linked mentions” at the bottom of the note.

Atomic notes

I try to keep my notes atomic and contained to one idea or concept.

Here’s an example from one of my notes on networking about IPv4:

---
title: IPv4
date: 2020-10-21 12:40:14
tags:
- 'networking'
---

**Internet Protocol version 4 (IPv4)** is the fourth version of the
[Internet Protocol](2020-10-10--17-59-03Z--internet_protocol.md) (IP). It is one
of the core protocols of standards-based internetworking methods in the
[Internet](2020-10-11--17-17-39Z--internet_layer.md) and other packet-switched
networks. IPv4 was the first version deplyed for production on SATNET in 1982
and on the ARPANET in January 1983. It is still used to route most Internet
traffic today, despite the ongoing deployment of a successor protocol,
[IPv6](2020-10-21--12-40-26Z--ipv6.md).

IPv4 uses a 32-bit address space which provides 4,294,967,296 (232) unique
addresses, but large blocks are reserved for special networking methods.

Source: https://en.wikipedia.org/wiki/IPv4

* Uses dotted-octet numbering system *(i.e. 192.168.0.1)*
 + 4 8-bit numbers 0-255, separated by '.', total of 32 bits.
 + 192.168.0.1 = 11000000.10101000.00000000.00000001

## Commands

* Windows: `ipconfig /all`
* MacOS: `ifconfig`
* Linux: `ifconfig` or `ip a`

Hub notes

Sometimes I’ll create a note that’s a hub with links to lots of other notes about a particular topic. A good example from my Zettlekasten is my hub note from when I was learning Python.

---
title: Python Notes
date: 2021-09-10 05:56
tags:
- 'python'
- 'dev'
---

# Python Notes

## Basics

* [Math Operators](20210910055642-math-operators.md)
* [Common Data Types](20210910201237-data-types.md)
* [String Concatenation and Replication](20210910201646-string-concatenation-and-replication.md)
* [Variables](20210910202050-variables.md)
* [Common Functions](20210910204323-common-functions.md)
* [Text and Number Equivalence](20210910210013-text-and-number-equivalence.md)

## Flow Control

* [Boolean Values](20210910210804-boolean-values.md)
* [Comparison Operators](20210910210949-comparison-operators.md)
* [Boolean Operators](20210910212715-boolean-operators.md)

### Elements of Flow Control

* [Conditions](20210911072918-conditions.md)
* [Code Blocks](20210911074141-code-blocks.md)
* [Program Execution](20210911074451-program-execution.md)

### Flow Control Statements

...

This is just the first 20 or so lines of that hub note, if you’re interested in seeing the whole thing, here’s a link to my Python Notes.

Other types of notes

There are other types of notes that you can take in your Zettelkasten and some of them are helpful for doing research. An example is “fleeting notes” which are something you jot down to capture a fleeting thought or idea that you will flesh out and categorize later.

If you’re interested in learning about the various other types of notes and how to use a Zettelkasten these ways From Fleeting Notes to Project Notes is worth a read.

Personally, I try to keep things simple and just focus on atomic notes and hub notes when those become unwieldy. Maybe if I decide to write a book someday I’ll get more into using my Zettelkasten these ways to accumulate research. It’s important to not get too caught up in methodology at first I feel. Developing the basic habit is more important.

From notes to “digital garden”

Photo by Filip Urban on Unsplash

A friend of mine that I used to work with published his technical notes about some tools we all used on his website. This inspired me to publish my own notes on a website so that I could share them with others. Some people like to call this online repository of their thinking, research, or notes their digital garden. I like this concept because tending to your notes is a bit like gardening. I’ve spent countless hours tending mine.

Here’s a link to my digital garden if you’re curious: Alex’s Second Brain

Sometimes if somebody asks how I learned something or asks for advice I’ll often link them one of my notes if I have one on that topic.

At first, publishing my notes online was a manual process, but I’ve since automated it so that all I need to do is write the notes and automation takes care of the rest. How I did this is probably a good topic for a future article, so stay tuned!

On Learning Ansible

Wed, 08 Nov 2023 00:00:00 +0000

Photo by Jonathan Chng on Unsplash

I recently had someone reach out to me on LinkedIn asking if I would mentor them on Ansible. Like many sysadmins I know I’m short on bandwidth and regretfully had to decline. But I did offer a book recommendation and a link to the Ansible Discord I sometimes frequent…

But this was enough to inspire me to write up some of my thoughts on learning Ansible.

0. Prerequisites

Learn Linux

In coaching a former colleague on Ansible who is a Windows Sysadmin I learned that it’s hard to wrap your head around Ansible if you don’t already know some Linux. You don’t need to become a Linux Sysadmin to learn Ansible, but the learning curve might be too steep if you aren’t at least proficient in the Linux CLI. Because Ansible runs on Linux to be able to learn it you tend to spend a lot of time in the Linux CLI running Ansible commands and trying things.

Learning the Linux CLI is out of the scope of this guide, but there are already a lot of great resources available for learning the basics. Here are some that I typically like to recommend:

Learning the Shell
Command Line Crash Course
From MIT’s “Missing Semester” course:
- The Shell
- Command-line Environment

If you aren’t already at least somewhat proficient in the Linux CLI go learn that first, then circle back to Ansible when you’re ready.

Learn some scripting

Whether it’s Bash, PowerShell, Python, or some other scripting language, having some scripting under your belt is really helpful for being able to wrap your head around Ansible.

Talking in terms of Bash. The Linux CLI is to Bash scripting what Bash scripting is to Ansible. Ansible is a couple layers of abstraction removed from running basic commands in the CLI.

Like climbing a ladder, it’s probably easier if you don’t try to skip the first few rungs. After you’ve wrapped your head around scripting, Ansible starts to make a lot more sense. You can skip learning scripting, but I wouldn’t necessarily recommend it.

Here’s my go-to recommendation for learning both the Linux CLI and scripting in Bash:

The Linux Command Line by William Shotts
You can download the book for free! But I recommend supporting the author by buying a copy if you can.

And if you’re a Windows Sysadmin who’s learning Ansible, it probably makes sense to learn PowerShell instead of Bash, but me being a Linux Sysadmin, unfortunately I don’t have something I have tried myself that I can recommend. I have heard some good things about Learn PowerShell in a Month of Lunches.

1. Book: “Ansible for DevOps”

Ansible for DevOps by Jeff Geerling is the best resource that I’ve found for learning Ansible. I highly recommend picking up a copy of this book and working through it. I recommend typing out all of the commands and code and running it. This is really all you should need to get started.

Jeff Geerling’s Ansible 101 series on YouTube is also quite good as a supplement to his book as it covers a lot of the same material.

2. Video: “Getting started with Ansible”

If you prefer video over book learning, Learn Linux TV’s Getting started with Ansible is also a solid recommendation. I’m a big fan of this channel for interesting tech videos and tutorials about Linux in general.

3. Learn by Doing

Most of the sysadmins I know are the “learn by doing” type and I’m no exception. My Ansible learning journey started this way because I needed to write some Ansible for work and I sort of just jumped right in and did it by writing some playbooks. This isn’t a bad way to get started and you can learn a lot by trying to make something useful right away.

The official Getting started with Ansible is a good entry point if choose to go this route.

In general I’ve found the official Ansible Documentation to be well-written with lots of helpful examples.

4. Ansible Discord

As a supplement to your learning, it’s helpful to know where you can go to ask questions if you get stuck. I sometimes frequent the Ansible Discord and I’ve been known to answer questions here and there when I need a break from working. (Yes, I enjoy Ansible enough that fielding questions about it in Discord is an enjoyable distraction for me… ;-)

I recommend asking questions the smart way for best results.

Conclusion

That’s all there really is too it. It’s hard to improve upon “Ansible for DevOps” as a learning resource and this is really probably my best recommendation for learning Ansible. Other than that, most of my Ansible skills I’ve acquired by building things with it. Some recommendations for acquiring some of the more advanced Ansible skills and other tips and tricks I’ve picked up along the way is probably a good topic for a future article, so stay tuned for a “part 2.”

DevOps Learning Resources

Mon, 04 Sep 2023 00:00:00 +0000

Updated 2023-09-16

This is a collection of recommended DevOps learning resources. Those with a ✅ green check-mark are my favorite resources for those topics.

DevOps

Online resources

Books

✅ The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim
The Unicorn Project: A Novel about Digital Disruption, Developers, and Overthrowing the Ancient Powerful Order by Gene Kim
The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations by Gene Kim, et al.

Cloud Native

AWS

Hands-On AWS Troubleshooting - A Cloud Guru

Azure

GCP

Virtualization

Containerization

Docker

CLI Cheat Sheet - Docker
Docker Mastery - Udemy
Docker Deep Dive by Nigel Poulton

Orchestration

Kubernetes

✅ The Kubernetes Book by Nigel Poulton
Kubernetes The Hard Way - Free Tutorial
KodeKloud.com - Learn-by-doing Platform
Kubectl cheat sheet - Kubernetes

Automation

CI/CD

Continuous Integration Continuous Deployment

✅ Implementing a Full CI/CD Pipeline - A Cloud Guru

Jenkins

Jenkins Quick Start - A Cloud Guru

Ansible (CaC)

Official Ansible Documentation

Videos

Getting Sarted with Ansible - LearnLinuxTV
Ansible 101 by Jeff Geerling

Books

✅ Ansible for DevOps by Jeff Geerling
This is the single best resource for learning Ansible that I’ve found.
Ansible Up & Running

Courses

Ansible for the Absolute Beginner – Udemy
Ansible Quick Start – A Cloud Guru

Tutorials

Getting started with Ansible – Ansible

Terraform (IaC)

Development

Programming, scripting, source code management (SCM).

Python

Python Cheat Sheet

Online Resources

Books

✅ Automate the Boring Stuff by Al Sweigart
Learn Python the Hard Way by Zed Shaw
Think Python by Allen B. Downey

Videos

Learn Python with Socratica - YouTube
Python Object Oriented Programming (OOP) - For Beginners - YouTube

SCM

Source Code Manegement

Semantic Versioning

Git

Official Git Documentation
✅ Git Cheat Sheet – Atlassian

Videos

Version Control (Git) – MIT: Missing Semester

Books

Pro Git – Git

Guides/Tutorials

✅ git - the simple guide by Roger Dudler
How to Write a Git Commit Message
gittutorial – Git
giteveryday – Git

Regular Expressions

✅ RegexOne - Online tutorial
This is a great intro to RegEx that you can probably get through in a couple of hours.

Networking

✅ Computer Networking: A Top-Down Approach by James F. Kurose
If you only consume one resource on computer networking, read this.
Professor Messer’s CompTIA N10-008 Network+ Course - Video Course
Networking for System Administrators by Michael W Lucas
Test-Out: Network Pro - Online Course + Labs
It’s important to do applied work to solidify skills and learning. If you’re studying for the Network+ the labs in this course are the closest facsimile to real-world experience that I’ve found. This course is all you need to get your Network+ if that’s your aim… it’s well worth the price of admission.

TCP/IP

The Internet Protocol suite.

Routing

NAT

What is NAT? - CompTIA

Subnetting

What is a subnet? | How subnetting works | Cloudflare - Cloudflare
Seven-Second Subnetting by Professor Messer - YouTube
What is a DMZ Network? - Fortinet

CIDR

Classless Inter-Domain Routing

DNS

Cloudflare has published some quality articles on DNS from a conceptual overview standpoint.

Start with these:

Systems Administration

The Practice of System and Network Administration: DevOps and other Best Practices for Enterprise IT, Volume 1 By Thomas A. Limoncelli, et al.

Unix & Linux

Tutorials

Linux Upskill Challenge
Level up your Linux skills to Jr. Linux Administrator in month’s worth of daily challenges. I’m a contributor on this project and am active on the Discord.

Books

Unix and Linux System Administration Handbook by Evi Nemeth, et al.
Systems Performance: Enterprise and the Cloud, 2nd Edition by Brendan Gregg
Sudo Mastery by Michael W. Lucas

Bash & Linux CLI

Windows

Learn Windows PowerShell in a Month of Lunches by Travis Plunk, et al.

Monitoring

Grafana

Prometheus

SIEM

Graylog

Knowledge Management

Documentation

Docs as Code

Markdown

Note Taking

Taking notes is akin to managing a personal “knowledge base”.

Making a habit out of taking notes is one of the single greatest force-multipliers for the IT professioal. Every exceptional developer, sysadmin, engineer, etc that I’ve worked with was a note-taker. The methodologies used doesn’t seem to matter so much, but taking notes does.

How to Take Smart Notes by Sönke Ahrens
The Zettlekasten Method
This is the method that I (mostly) use. See my second brain as an example.
Obsidian
Markdown note-taking tool. Supports Zettelkasten methodologies. This is what I’m currently using, although I’ve also used Vim, Emacs, and explored various other tools and text-editors in the past.

How I Became a Linux Sysadmin in Less Than 2 Years

Thu, 20 May 2021 06:36:32 -0600

In November of 2019, I started working as a Tier 1 support agent at a web-hosting company in the Denver, CO area. Just shy of 18 months later I was promoted to Managed Hosting Analyst, which is a Linux Sysadmin role. I retained a couple roles between then. I was promoted to Tier 1 Expert at about 3 months in, and around 9 months later I received a promotion to Advanced Product Support, which is basically a Jr. Linux Sysadmin role. On average I received a promotion around every 6 months.

If you had asked me years ago, if it was possible to become a Linux Sysadmin in 1.5 years, I probably would have thought you were crazy. I’m not saying this to toot my own horn. But, it’s easy to overestimate how long it might take to achieve a career goal become overwhelmed by the prospect, and fail to start. I’m hoping by writing this, some of what I did, might be helpful to others who are just starting out.

First a little background

Years ago, I had an interest in becoming a Linux Sysadmin or at the very least working in this space. At the time, I thought my foot in the door would be getting an entry-level developer role. I hustled and built a few sites for friends, taught myself HTML/CSS, Python, and a little JavaScript. A friend and I even landed a job prototyping a web application for a wealthy businessperson with an idea. That failed after about 6 months when we realized we had completely underestimated the project, and our employer took the job overseas for cheap programming labor. That was over the winter of 2015-2016. I’ve worked other jobs in-between that were unrelated to IT.

To be honest with you, I applied to the Tier 1 support agent role on a whim. I didn’t think I would get the job because I lacked qualifications and experience. I was honestly surprised when they offered me the job. I think this sense of imposter syndrome has followed me to this day.

Ok, so how did I move from a Tier 1 role to Linux Sysadmin in 18 months?

I think I had a couple things going for me out of the gate:

I was already familiar with and more or less proficient in the Linux CLI.
I had some coding experience and web-development experience under my belt.

But, I think if you’re sufficiently motivated, this would probably only set you back about 6 months, if you’re comparing to my timeline. These are skills that can be acquired.

8 Strategies That Landed Me That Linux Sysadmin Role

1. Study

I studied outside of work. A lot. There’s no secret to the quick succession of promotions I received. I put in a lot of extra time outside of work studying and learning the skills I would need to get to that next tier. If you want to grow quickly, you have to be willing to put in the time and effort.

2. Ask questions

I wasn’t afraid to ask questions, and for help. And I listened and observed. I was like a sponge. I think it’s important to identify a distinction between just asking questions or for help, without improvement. Some people consistently ask questions or for help, and don’t seem to get any better. When you’re the person they’re asking, this gets old. Don’t be that person. First try to figure it out on your own, try to find resources to learn about or fix the issue, then if you still can’t figure it out, ask for help and outline what you’ve already tried and where you’ve looked. Then take notes on what you’ve learned because you’ll forget. This is asking questions the smart way.

3. Learn to love solving problems

It’s important to have a keen desire to solve problems. I don’t think you’re going to like IT very much or get very far if solving technical problems doesn’t interest you on some level. One of my primary drives for moving into IT was that I genuinely enjoy solving problems. I love it (or perhaps I’m just obsessive?). I’m not sure what to tell you if solving problems isn’t one of your areas of interest, but perhaps it’s time to think about what you do actually like to do, and if that’s working in the IT space. Be passionate about solving problems, or at least learn to be passionate about it.

4. Be as helpful as possible

Be as helpful as possible. Not just to the customer or the client, but to your team, to members of other teams, to anybody really. People want to work with (and reward) people who are helpful and make work better and easier for everybody else. When COVID-19 hit, I was asked to man a temporary remote helpdesk, to assist people from multiple departments with getting connected and working remotely. I don’t think I would have been asked to do this if I hadn’t been voluntarily helping various people with their remote work setups already. Because I was one of a handful of people on this desk, I got to know all sorts of people on other teams and other departments. The director of my department personally acknowledged my contribution to the company. This put me on the radar of people in leadership of multiple departments. In the words of one of my colleagues, I was a “hot commodity” after that. No doubt, this helped when I put in for those other roles.

5. Solve problems for everybody

Become a meta-problem solver. If you solve a problem and it seems to be a common enough problem, solve it for everybody. If there isn’t any documentation for that problem, write the docs. If you can write a script that automates said thing, try to carve out time to write that script. I wrote guides on how to handle things that are common pain points when working in support. Some of these ended up getting passed around by others and eventually were merged into some of the training materials given to new hires.

6. Become a mentor to others

This goes along with being helpful, but be approachable. If you’re the person others turn to when they are having trouble solving a problem, guess what? You’re now a mentor. As your skills grow… coach, mentor, and teach what you’ve learned to others. If you asked questions the smart way, and worked to grow your skills, chances are you will have the opportunity to pay it forward. Someone did this for you, no doubt, it’s time to return the favor.

7. Have a good attitude

Have a good attitude. In a lot of ways, this goes with being helpful. But I can’t emphasize how important having a good attitude is when looking for promotions. Don’t be that person who complains all the time or has a negative attitude. Don’t commiserate too much with your co-workers (a little is ok, but we all know that person who seems to always be commiserating, you’re literally creating misery together. Don’t be this person). You want to be the person who seems like they can weather the storm and not get bent out of shape about it. You have a “can-do” attitude, don’t complain too much, have a positive attitude, and are reliable.

8. Take ownership and be accountable

Be accountable, take ownership of your work, and do what you say you’re going to do. I feel like this should go without saying, but it’s surprising how common it is for people not to take ownership of their work, show up to work on time, and follow through on things.

Make showing up to work early a habit. If you’re not 5-10 minutes early, you’re late.

Take ownership of your work. If you’re tasked with a problem, try to see it through, and take care of the issue as if it were your own. Don’t just kick the can down the road for someone else to handle. Go the extra mile, make sure you checked all the things, and make sure it’s solved so that it’s not a problem that’s going to re-occur (if at all possible). If you say you’re going to do something, do it. Make sure you notify others if you’re not going to be able to complete said thing, by the time you said you would. This builds trust and accountability. Your leadership wants to know they can rely on you to be doing what you’re supposed to be doing without too much oversight. It’s annoying to have to babysit (or worse, micromanage) someone because they’re not doing what they should be doing. If you want to be given more responsibility, you have to demonstrate you can handle it.

Closing Remarks

A lot of what I’ve said here can easily be applied to any line of work. It’s not unique to the IT space, or this career path. Some of what I said, like studying and solving problems, are somewhat unique to the IT space.

I also think that working support in web-hosting provides a lot of opportunity for growth. As a sector of the industry, web-hosting seems to value finding cheap labor and then training those people up rather than paying more up-front and hiring people who already have experience and education. It’s the perfect place for someone without a degree, but the interest and drive, to cut their teeth on learning these skills. The company I work for seems to value training people up and promoting from within, rather than hiring from outside. There’s no doubt that this has also helped in terms of my trajectory. But It wouldn’t have happened without the hard work and dedication I’ve put in. I can also say, that for being a Linux Sysadmin, I’m probably being paid under the market average. But, I didn’t need a degree, or any certifications to get hired initially. That’s probably the trade-off.

Also, keep in mind, this is only what has worked for me. Your mileage may vary. If you work hard, are dedicated, and persevere, you’ll get there. It’s only a matter of time.

Grit

Sun, 16 May 2021 18:39:24 -0600

I recently learned that the greatest predictor of success in an endeavor is not anything you would typically think. It’s not IQ, socioeconomic status… whether you grew up rich or poor, or whether you had good parents. Actually, it’s a difficult to define quality called grit.

To give an example, with enough grit you can overcome all odds and become a navy seal. Just take a look at David Goggins. I’m paraphrasing, but he came from a racist part of Alabama. He grew up poor. His father was abusive. He was overweight. He had just about every reason not to succeed. The one thing he did seem to have was grit. If anyone has grit, it’s this guy. He’s a certifiable badass. But he didn’t get there overnight.

I recently stumbled across this Ted talk by Angela Duckworth about this topic. Her research shows that just about the only significant predictor of success is having grit. It wasn’t IQ, looks, upbringing, or any of the other commonly assumed predictors of success.

Grit is having stamina and endurance. It’s being able to weather failures and difficulties. It’s working towards a goal day-in and day-out, over a long period of time, and not giving up.

Ok, so how do you build grit?

That’s a good question.

There doesn’t seem to be an obvious way to become grittier. Angela Duckworth talks about how some of the things that seem to correlate with being gritty are having a growth mindset and realizing that failures aren’t a permanent condition. It’s ok to fail if you learn from your failures.

A growth mindset is believing that weaknesses can be overcome by applying yourself and putting the work in. It’s the difference between believing that some people are just talented or smart, or that those things are skills that can be developed.

Don’t get me wrong; talent helps. Some people are more genetically gifted. It’s not an equal playing field. But I think what this shows, is that the gap between having those natural abilities and having grit is a lot smaller than we think. There are exceptions. It’s not enough to just have grit if you plan to be a world-class Olympic swimmer like Michael Phelps. He’s a freak of nature with a crazy wing-span. He has flippers for feet. But he also has grit. Phelps might have medaled at the Olympics, but I doubt he would hold 21 Guinness World Records if he didn’t also have the grit to work as hard as he did.

Ok, so being in the top 1% in your field might take both grit and god-given gifts; if you plan to medal at the Olympics. But how many people were there who are just as genetically gifted, or even more so than Phelps and aren’t a household name? That’s a good question…there’s probably a few of us. I think the point is, you’ll never realize your potential if you don’t start having some grit.

I guess I’m writing this as much for myself as for those of you who are reading. I’m not satisfied with where I’ve gotten to in my life so far, and I need to change that. It’s going to require hard work, perseverance, dedication, and sacrifice.

I’ll leave you with a quote from probably one of the hardest working athletes in football.

“Today I will do what others won’t, so tomorrow I can do what others can’t.”
– Jerry Rice