Super convenient if you have something on top and would like it to
be on bottom and vice versa; or to switch left and right panes.
Usually not super helpful during normal use of tmux, but very
handy when streaming, e.g. when you have a camera view obscuring
part of the top panel (or on the left/right side) and you want
to switch panel arrangement.
In the long run I would love to automate spellchecking on
the slides, but there's a long way to go, with all the
custom lingo that we use... This is just the beginning of it,
on a few files.
It shouldn't be necessary, since it was basically specifying a
font that may or may not be installed on folks' computers (and
wasn't loaded from the CSS). Tiny simplification but I'll take it 😁
'keys' does not handle special keys (like ^J) anymore.
Instead, we should use `key`, which will pass its entire
argument to tmux, without any processing. It is therefore
possible to do something like:
```key ^C```
Or
```key Escape```
Most (if not all) calls to special keys have been
converted to use 'key' instead of 'keys'.
Action ```copypaste``` has been deprecated in favor
of three separate actions:
```copy REGEX``` (searches the regex in the active pane,
and if found, places it in an internal clipboard)
```paste``` (inserts the content of the clipboard as
keystrokes)
```check``` (forces a status check)
Also, a 'tmux' command has been added. It allows to
do stuff like:
```tmux split-pane -v```
In the Kubernetes courses, it takes a bit too long before we
reach the Kubernetes content. Furthermore, learning how to
scale with Compose is not super helpful. These changes
allow to switch between two course flows:
- show how to scale with Compose, then transition to k8s/Swarm
- do not show how to scale with Compose; jump to k8s/Swarm earlier
In the latter case, we still benchmark the speed of rng and
hasher, but we do it on Kuberntes (by running httping on
the ClusterIP of these services).
These changes will also allow to make the whole DaemonSet
section optional, for shorter courses when we want to
simply scale the rng service without telling the bogus
explanation about entropy.
The last 5(ish) times I presented DockerCoins, I ended up
explaining it slightly differently. While the application
is building, I explain what it does and its architecture
(instead of watching the build and pointing out, 'oh look
there is ruby... and python...') and I found that it
worked better. It may also be better for shorter
workshops, because we can deliver useful information
while the app is building (instead of filling with
a tapdancing show).
@bretfisher and @bridgetkromhout, do you like the new
flow for that section? If not, I can figure something
out so that we each have our own section here, but I
hope you will actually like this one better. :)
This was discussed and agreed in #246. It will probably break a few
outstanding PRs as well as a few external links but it's for the
better good long term.
