Because I started programming a long, long time ago, I have to admit that I spent most of my career without writing tests to accompany my code. It was only in recent years that I learned how to use a test suite to my advantage. In hindsight, I should have started earlier because having tests completely changed my life as a software developer.
Tests create peace of mind. The amount of confidence with which I now release my code to production is worlds apart from the trepidation of past deployments when I was on edge for hours waiting for the other shoe to drop. Beginning of this year, I wrote about this in my article “Test-Driven”.
I remember how difficult it was for me to get into writing tests. Honestly, once in a while I still struggle with building clean and efficient tests. That’s why I can relate to developers who are turned off writing tests by the additional effort it takes.
Decades of me coding without a test suite prove that you can not have tests and still do a decent job. However, that doesn’t mean that it’s a good idea. Or that it’s good practice in 2019. I’d even go so far as to state that building tests for your code has become basic professional behaviour.
Martin Thompson draws an interesting parallel to the medical profession on the episode “Protocols and Sympathy” of the Arrested DevOps podcast (link jumps right to the related point in the conversation):
“A surgeon will not consider performing an operation without washing their hands.”
But did you know that it wasn’t until the efforts of people like Ignaz Semmelweis in the 1800s that antiseptic procedures were even considered par for the course by doctors? Setting higher standards for hygiene transformed medical practice.
I’ve come to the realisation that spending time on writing tests before coding business logic is like washing your hands ahead of performing surgery. In the long run, it saves time and money because it make sure that “done” means “done”. Better hygiene in medicine reduced the number of deaths and minimised the need for antibiotics and urgent follow-up operations. A robust test suite will reduce the number of outages and minimise the need for workarounds and urgent debugging sessions.
In both cases, there’s going to be far less suffering for everyone involved.
I’m surprised that an article like “A Better Internet Is Waiting for Us” can be as enlightened as it is and still not mention the term IndieWeb or reference an alternative social platform like micro.blog.
PS: Is that CSS intro transition gorgeous or what?
PPS: I like to think that “You may not develop artificial or undesired entities for use in Photon Emission Products (PEPs).” is in fact advocating for ethical lasers.
Seth Godin: “The existence of DuckDuckGo doesn’t significantly change Google’s position as a monopoly able to dictate how most people experience everything on the web.”
I use to say that the weather in Ireland is much better than its reputation. But this week, it’s been really, really terrible.
I had this week off and mostly did what I felt like doing. The phrase “Right. Next, I’ll have to…” is how I put pressure on myself. And, as I’ve explained in my talk about resilience at DrupalCon, pressure can slowly turn into burnout. That’s why avoiding “I have to” and not trying to accomplish anything is actually good for me.
Speaking of my resilience talk: This week, I was invited to give my presentation via Zoom to the Drupal Scotland groups in Edinburgh and Dundee. I’m really happy with the outcome and I hope I was able to inspire more people to stop and correct course towards better mental health.
I ended my holiday week somewhat early by doing a pair programming session with Markus on Friday morning. I’m pretty sure we both felt that it was time to work on something as a team again. A “want to”, not a “have to”.
My Bose QC25 headphones got a Bluetooth upgrade and it’s glorious. I’ll write a separate post just on this.
Man, these unknown unknowns. I had no idea of the capabilities my iPad Pro got with its latest upgrade until I watched Christopher Lawley’s iPadOS video.
After hearing and ignoring the term many times over the years, I finally got the importance of the IndieWeb movement. Which information we find on the web and how others find the information we put on it should not depend on the goodwill of mega-corporations and algorithms. Huh, that sounds quite cyberpunk; maybe it was my recently rekindled interest in Shadowrun helped the coin to drop for me. But it was Tantek Çelic’s talk “Take Back Your Web” that pushed me over. I’ve already left Facebook a while ago and (obviously) revived my own blog. Even though I now wanted to integrate it with others using modern standards like webmention.io and microformats2, I felt I’d rather spend my time writing. That’s why I decided to save time and move my blog to the micro.blog platform. I used this opportunity to give my blog the simpler domain name “geewiz.dev”. Welcome to my new digs!
Writing workflow update
I’m now using Drafts not only for short notes but also for writing posts, email and other text. Most texts start as a quick brain dump of only a few keywords. When I get to write, I flesh them out more and more. When a text has matured enough, I copy it to its final destination such as a Jekyll git repository, the micro.blog web form or my email application. After a few finishing touches, I publish the content. Simple.
“My web team told me about your Drupalcon talk and I watched the YouTube recording yesterday. I just wanted to say that I really appreciated your talk, your honesty, humour, concrete advice, thank you.”
I can relate to DHH trying to drop the Stockholm syndrome. Apple machines are a very mixed bag. But they’re still the best desktop experience I can find. I’m now pairing my iMac and iPad with a Linux dev server and get both best worlds (i.e. desktop pleasure and open source power).
I haven’t written any weeknotes lately, so let’s catch up with things.
In my old office box, I found the old HP 28S calculator that I bought in 1991 and that converted me to RPN for life. It still works, despite one of the batteries I stupidly left in having leaked a bit. I wish I had more math to do at work because I’d love to use the this nice piece of hardware some more again.
The upgrade of my iPad Pro to iPadOS 13 got stuck and none of the recommended solutions worked for me. In the end, I resorted to restarting it in Recovery Mode and that got things rolling again.
I built my first two custom mechanical keyboards. That’s going to be a separate post.
At work, we’ve been using Notion as our knowledge base for a few months. However, it wasn’t until watching a recent Notion Office Hours video that I realised how powerful this platform can be. The article on the PARA method mentioned in the video inspired me to put a lot more information into Notion than just text content.
An email recently informed me that “You’ve been on Drupal.org since 10/10/2008”. Wow, it’s been a while! And I still enjoy being a member of the Drupal community.
I’ve downloaded all the videos of RailsConf 2019 to my Plex server so I can watch them at the office or, thanks to Plex Sync, anywhere I have my iPad with me. Right at the top of my list was “Programming Empathy: Emotional State Machines” by Coraline Ada Ehmke. Reflexively, I was about to skip that one because I remembered that listening to her on podcasts had made me feel uncomfortable. But I decided to challenge this reaction and I’m glad that I did. I learned a lot about empathy from her talk and recommend watching it.
At the end of last week, I was feeling pretty exhausted. That’s why I’m
publishing this weeknote late on the following Monday. I have to have high
expectations of myself, otherwise I’ll easily fall into slacking off and looking
at keyboard porn all day. But I have
to stop put too much pressure on myself. That’s the best recipe for burnout
because I’m setting myself up for frustration despite of all the stuff I
actually get done.
Speaking of keyboards, I’m still not sure if it’s self-improvement or
self-sabotage, but on top of the previous changes to my keyboard
layout, I’ve now adopted also the other
important improvement of the HHKB layout by swapping the Backspace and Backslash
keys using Karabiner Elements; now it’s much easier for me to reach Backspace
with my right pinky. I was even about to buy an actual HHKB, but faced with its
hefty price, I’ve decided instead to build myself two custom keyboards (one with
a plastic case for travelling, one with a heavy aluminium case for my desk) that
sport the “split backspace” (Tilde and Backslash) at the top right, with
Backspace below, and a “split right Shift” with a small Fn key at the right
edge. Until then, I’ll retrain my muscle memory with a software-defined layout.
So, in short, I’m obsessing over mechanical keyboards as a way to combat both
RSI and Alzheimers (that’s what I tell myself anyway). You can find my Karabiner
rulesets in my dotfiles
repository, by the way.
After returning from my holidays on Ibiza, I had lost all interest in playing
World of Warcraft. And it still hasn’t returned. The parts of the game that I
enjoy the most require group play, and good groups are hard to come by.
Especially for me with my very narrow window of disposable leisure time. And
people focusing on WoW Classic didn’t help my frustration either. Last month, I
canceled my WoW subscription (it’ll still run for a few months) and took the
opportunity to buy the three Shadowrun RPGs on Steam when they were offered as a
Humble Bundle. Being able to play at my own pace is neat but I admit that I
haven’t played SR much either.
Somehow, I’m finding live coding much
more appealing than playing any games. In one of my streams this week, I did for
the first time answer a question that someone had posted to my Discord server.
That was fun and I’d like to make this kind of live-coaching a regular thing. If
my brain wasn’t more or less fried come dinner time, I’d even do a few evening
sessions on top of my regular slots on Tuesday and Friday morning. My next goal
in this space will be to build myself an efficient toolchain that lets me churn
out screencasts that aren’t live but instead more polished.
Weeknotes could be an easy way to get back into writing more regularly. Friday will now be weeknote day.
Karabiner-Elements is an amazing tool for remapping a Mac’s keyboard. It not only provides me with a more useful keyboard layout, it now also forces me out of bad habits. Among other things, it turns the useless Caps Lock key into an easier to reach Esc (or Ctrl if held with another key). My right Command key has been promoted to Hyper (Ctrl+Shift+Option+Command) for a whole new layer of hotkey definitions. And as of today, the left half of my alphanumeric block doesn’t work with the left Shift key anymore.
Speaking of keyboards: If you’re looking for me, I’m down the custom mechanical keyboards rathole. This morning, I swapped the springs and lubed the keys of the Cherry MX80-11900 I got cheaply from Ebay. Now I can finally type on it for longer than 5 minutes. Lots of soldering and waiting for group buys in my future.
This week (geez, that T took me three attempts), I finally got to do my personal retreat for this year. For two days, I booked myself into a hotel, disabled most notifications and roamed the Mount Usher Gardens thinking about the really important stuff. I’m very happy with the results.
Doing my live coding late in the day to reach more viewers was a stupid idea. The quality of the little code I was able to produce recently (when my weary brain wasn’t blanking completely) is embarassing. From next week on, I’ll be streaming right after my morning coffee.
Almost all of the command line tools I use on my Mac workstation, on my development server in the cloud, and on my company’s Linux server infrastructure store their configuration in so-called “dotfiles” — files (or even whole directories) in my user home directory that are hidden from plain sight by prefixing their name with a period, for example .vimrc. (Like this example, actually quite a few of these files do end in rc. That’s why they’re sometimes also called “rc files”.)
Most of the dotfiles I use come from our shared team dotfiles repository. Having a big overlap in configuration settings between our SRE allows us to easily share and take over a terminal session via tmate without having to struggle with individual tmux or vim keybindings. Doing pair work in a terminal session has the huge advantage that it takes up much less bandwidth than screensharing via Zoom or Slack.
Some tools still allow a certain degree of individuality. For example, the shell prompt details can vary without causing confusion. You can also have your own magic shell and git aliases. That’s why I layer my personal dotfiles repository on top of the team one.
Another complication is that the BSD subsystem on the Mac sometimes behaves a bit differently from Linux. That’s why, for a few configuration files, I’m maintaining alternative versions. They’re stored in subfolders starting with tag-. The dotfile deployment then installs the right version depending on the host OS.
dotfile deployment
So how do you maintain a set of dotfiles in your home directory on hundreds of machines if they come from two overlapping, even conflicting, git repositories? The trick is to clone both repositories and then symlink the configuration files to where they are expected by their application. The key to keeping this process simple and error-free is rcm. It can handle multiple dotfile directories, each with its own precendence. You can also provide it with tag names telling it from where to source certain dotfiles.
I install rcm manually when I set up a new development machine (which only happens once or twice a year). On our servers, it gets installed automatically via our configuration management software Chef.
Here’s the script that I use to deploy my dotfiles:
#!/bin/bash
if ! which rcup >/dev/null; then
echo "Fatal: rcm is not installed on this machine."
exit 1
fi
os_type=$(uname -s)
# Remove oh-my-zsh
rm -rf ~/.oh-my-zsh
if [[ -d ~/.dotfiles ]]; then
cd ~/.dotfiles
git pull
else
git clone [github.com/geewiz/do...](https://github.com/geewiz/dotfiles.git) ~/.dotfiles
fi
if [[ -d ~/.freistil-dotfiles ]]; then
cd ~/.freistil-dotfiles
git pull
else
git clone [github.com/freistil/...](https://github.com/freistil/dotfiles.git) ~/.freistil-dotfiles
fi
rcup -f -t $os_type -d ~/.dotfiles -d ~/.freistil-dotfiles
As you can see, it clones the dotfiles repositories (after a bit of cleanup) and finally calls rcup using an OS-specific tag (“linux” or “darwin”). Thanks to a a post-up hook, it even launches vim to update its plugins from Github.
You can find the current incarnation of the deployment script in my personal repository as bin/dotfiles. Since its directory gets symlinked as ~/.bin and added to my shell search path, I can execute the dotfiles command at any time to update my local configuration.
As for the initial deployment on a new machine, I simply curlbash the script:
Video games good for building focus create environments that are fast-paced, interactive, adaptive and have complex reward and gaming structures. Like a brain playground.
So at my age it’s basically mandatory to keep playing WoW!
The concept of Test-Driven Development (TDD) isn’t particularly new anymore. But even after quite a few years of accompanying my code (regardless if it’s a Rails app or Chef infra code) with tests, TDD is still far from being second nature to me. I’ve recently watched a talk from RubyHACK 2018 which motivated me to get better at it.
In his talk “Some Truths About Some Lies About Testing”, David Brady explains why so many of us find it hard to start with building tests first and implementing the actual business logic second: Most of us learned programming in a way that immediately tackled the implementation. Actually, that’s how we’ve learned problem-solving in general: take a problem, break it down into manageable chunks and build up the solution piece by piece. In the end, the solution will deliver the desired outcome. Or maybe it won’t, and this is the time when we start testing to find out which of our pieces doesn’t behave the way it’s supposed to.
In his talk, David calls this approach “Test-After-Development” (TAD) or “Q3 Development”, because knowing the implementation but not what exactly the desired behaviour looks like is quadrant III between the two axes “Behaviour known/unknown” and “Implementation known/unknown”.
It’s quite obvious that Test-Driven Development is generally quadrant II: I’ve clearly defined the behaviour I want and am working out the implementation.
David also has a good explanation why I often have to force myself to spend effort on building tests at least for my implementation if not before my implementation. TAD gives you instant gratification. You see your code doing something that brings you closer, if not full way to the solution. The problem is that this development approach may start easy but gets harder as your codebase grows. David mentions how a change that resulted in a single line of code took them almost two days to implement.
TDD, however, pays off sometime in the future. Granted, it starts hard but it gets easier over time as you can more and more rely on your tests guiding you.
When I have tests, I can make changes if not more efficiently, then at least with much more confidence that I won’t accidentally break things. Compared to the pain of untangling code that seemed completely unrelated to my latest change but suddenly started behaving strangely nonetheless, the time spent building tests is a so much better investment. And the experience of deploying code with peace of mind every day is enough of a reason for me to move into quadrant II, step by step.
Watch David’s talk, I found it both entertaining and inspiring!
Earlier this year, I started live coding as an experiment in knowledge transfer for our team at freistil IT. You can read more about my motivation on the freistil Blog. In summer, I took a break to go on family holidays. But for a number of reasons (too many of them unpleasant), I didn’t pick up my regular schedule again until today. I’m happy to announce that Full Stack Live is back with a new concept!
I felt that a change of concept was necessary. Previously, the topics I picked for my live coding came from work that I had on my plate that week anyway. This was convenient because that way, the live stream didn’t take too much time away from my work tasks. However, the downside of this approach was that the live stream often offered only tiny windows into projects on which I mostly worked off-stream. And since that work almost always happened in private Github repositories, viewers didn’t even have the chance of catching up on my progress by looking at commits and pull requests. I thought that there was much unused potential.
In order to make my live coding more valuable for my viewers, I’ve decided to start a new project specifically for Full Stack Live. With Jupiter, I’m going to implement an old idea that I never got to execute on. I’m building a web application for IT infrastructure management. I’ll start with scratching my own itch, i.e. managing the many hardware servers on which we run our managed hosting platforms freistilbox and staqops. From there, I can see it extending to cloud providers like DigitalOcean or AWS as well.
I’ll try to do most of the interesting engineering tasks live on stream. And since Jupiter is going to be open source, the Github repository will allow everyone not only detailed insight into what’s going on but also the chance to participate. Everyone who finds the application useful will be able to file issues and even submit pull requests. To be honest, I’m pretty excited about the possibilities!
Here’s the recording of today’s session. I’m afraid it isn’t very interesting because for most of the time, I was only waiting for installation scripts to finish. Not quite peak entertainment…
But hey, it’s the inaugural session of a project that I hope in total will be very educational. So, here’s to Jupiter and season 2 of Full Stack Live!
Check out my live coding page for the schedule and where you’ll find the recordings. Don’t forget to follow the stream on Twitch to get notified when I’m going on air, and make sure to say hello in the chat!
When we worked on Next Generation, Brent Spiner and I would sit at our consoles on the bridge, and make up lyrics to our show’s theme song. I vaguely recall coming up with some pretty funny and clever stuff, but nothing that held together as perfectly as this
