Labs are designed for learning. I learn by doing. While I can read, as they say in the local vernacular in my propinquity “Wicked Fast,” I don’t process read information to the depth that I need in order to retain it. I need to type in the code in order to learn. Here’s a technique I use to do that.
In my current lab we have a bunch of Kubernetes resources to create. These are specified as YAML files. The lab creator has made it easy for the student by making the heredocs, like this
cat << EOF | oc apply -f - apiVersion: hostpathprovisioner.kubevirt.io/v1alpha1 kind: HostPathProvisioner metadata: name: hostpath-provisioner spec: imagePullPolicy: IfNotPresent pathConfig: path: "/var/hpvolumes" useNamingPrefix: "false" EOF |
In order to learn this code, I type it in by hand, removing the first line (starts with ‘cat’) and the final EOF. However, as I found during this lab, it is very easy to add a typo in even a short file like this. Thus, you might be tempted to just run the heredocs. But that removes one of the key benefits of the lab: mentally processing the text that affects change in the system.
What I’ve been doing is typing in the sample code, and, before running it, creating a second file with an exact copy from the instructions. For example, the last one I did was for Node Network Configuration policy, stored in a file called nmstate.yaml. I copied the original code in nmstate.yaml.check and ran
$ diff nmstate.yaml.check nmstate.yaml 2c2 < kind: NodeNetworkConfigurationPolicy --- > kind: NodeNetworkConfitguraiotnPolicy 21a22 > |
As you can see, my typo was pretty easy to identify. Once I corrected it:
$ oc apply -f nmstate.yaml nodenetworkconfigurationpolicy.nmstate.io/br1-enp2s0-p |
I was able to successfully execute the sample code, and move on with the lesson.
This may seem like a lot of extra work, but it makes the lab so much more valuable. It also enforces the rule that I have learned and relearned in my time as a programmer: let the computer check your work.