One of my recent weekend side projects, an e-ink / raspberrypi driven build status dashboard, was a great playground for doing TDD powered by visual snapshots. But let's rewind a bit.
What I actually wanted to achieve was the following: Build a semi-decent python class to draw a dashboard type interface, which I can feed to my e-ink display. I had already prototyped such a script, but it was a "make it work in the quickest possible way in 1 hour" mess. Nothing I wanted to maintain or even look at for even five more minutes. I also didn't want to start completely from scratch regarding the output, because I was happy enough with the result this script produced, which is shown here:
So how could I develop the code from scratch, while making sure I got the exact same output in the end? Right, creating myself a feedback loop that will quickly compare the reference image to the current output. To quote from jest:
Snapshot tests are a very useful tool whenever you want to make sure your UI does not change unexpectedly.
A typical snapshot test case for a mobile app renders a UI component, takes a screenshot, then compares it to a reference image stored alongside the test.
This is powerful, because how else would I test this? Things of visual nature are not unit-tested easily, which is why they are often simply untested. We usually don't test stylesheets, colors, images etc. However we can't say those things are unimportant. So I set out to do TDD with snapshots and iterate myself toward the reference result.
Lot of work left to do, sure, but that set myself up for about a two second feedback cycle. The process, which I packaged into a simple
npm test bound to
<leader>t in VIM so I can invoke it in one keystroke, is this:
- Run unit tests in python (This is just one dumb test for the constructor, I should remove it)
- Render current image to
actual.png in an "integration" test
- Create image diff with pixelmatch
- Open this diff in Preview so it jumps into my face
See the process encoded here, and yes, the irony of having a node based test invocation for a python script is not lost on me. Computers 🤷🏼♂️
Let's walk through one of my commits together. I really enjoyed working like this. A few minutes in, I had the rendering of the header, header title, project text to the left all fleshed out with minimal differences to the reference. I assume something regarding the font-rendering on the raspberrypi/debian vs. my mac is to be blamed for the tiny deviations around the text. No clue though. So here I was:
Lets add some code to render the badge text on the right:
<leader>t, and see this:
So obviously I got the alignment wrong. Lets fix it:
Re-run the tests, see this:
Less red! That's basically what I did over and over again. Feel free to have a look at the commits for more examples.
- Fast feedback is gold
- Even visual feedback is good
- I wouldn't have wanted to unit test this, so quick visual feedback is way better than no feedback. Let's remember that coding this up, syncing the code to the rasbperrypi, actually running the code and see the output on the e-ink display is a multi-minute process!
- Keep snapshot tests in your toolbelt, there is a place and time for them, and it's not only react!
- Updating the reference image is displayed really nicely in github
Danger-todoist celebrates 200k downloads#
Danger-todoist is a plugin for the excellent Danger ecosystem. More specifically for the ruby variant of Danger. What does Danger do? It is basically a kind of automated code / pull request review system. You create a pull request on github, and a bot account will recommend changes to the pull request. The changes it suggests are based on a freely configurable set of rules and suggestions, as codified per your
Dangerfile. The beauty comes as always through the flexibility of just plain ruby code and a set of plugins.
One of those plugins is danger-todoist, which I first published in September 2016. A things that makes me cringe is leaving
TODO: fix me comments all over our code, and of course then never fixing them. Makes one wonder if there really was something to do ... 🤓.
Danger-todoist helps you with this! It will duly notify you if you were to leave an unadressed todo comment in your changes. You can decide whether this is a show stopper (YES!) or if you want to leave it as a warning. Either way, this makes it much harder to let many of those pesky comments sneak into your codebase.
Since its first release more than a year ago, it has now amassed 200.000 downloads as shown on rubygems. This likely makes it my most successful peace of open-source software to date 🖖🏽, which I hereby celebrate.
Hack on, and keep that code clean, and check it out on github.
In 2017 I have likely listened to hundreds of hours of podcasts. Out of interest, lets do the math real quick:
50 weeks until now * 5 podcasts * 1h average length = 250h. So yeah, hundreds of hours it is. But I definitely don't consider that to be wasted time, but sometimes great entertainment, time spent learning, or a soothing tone to fall asleep to. Without much further ado, here's what I have been listening to in 2017, in no particular order:
- 2 Dope Queens: Phoebe Robinson and Jessica Williams are two friends hosting a hilarious live comedy show. They literally crack me up each episode and easily brighten my mood for quite a while. Funniest podcast I know.
- Scrum Master Toolbox Podcast: Each episode is around eleven minutes long and is a concise discussion about the daily work and struggle of the scrum master trade. Vasco Duarte does a great job in keeping those episodes short and to the point. Great way to learn some useful tips from more experienced agile coaches/scrum masters.
- Missed Apex Podcast: This was a new discovery for me in 2017 and made the formula 1 season so much more enjoyable. The f1 race reviews are both funny and informative. The host Spanners Ready leads a crew of journalists and f1 fans to produce these reviews but also more technical shows and interviews with people of f1 fame. A must listen!
- The Bike Shed: This has nothing to do with bikes, but is a semi-random conversation between Derek Prior, Sean Griffin, Amanda Hill and various guests on IT topics such as Ruby on Rails, Active Record, Diesel, mixed with stories on consulting work, rockets and anything else that might come up. I find it provides a nice mix of interesting technical discussions and light-hearted banter.
- Accidental Tech Podcast: The trio of Casey Liss, Marco Arment and John Siracusa do a great job of endlessly discussing the world of Apple and related surrounding topics. This is definitely the podcast I have been following for the longest time.
Living off of open-source#
For the second year in a row now I have participated in Hacktoberfest, an open-source initiative by DigitalOcean, a cloud infrastructure provider. What's the deal? You, fellow open-source contributor, just have to open a handful of pull-request during the timeframe of October 1st to 31st. DigitalOcean will be generous and send you a limited edition t-shirt for free (well, for your time spent on those 5 pull-requests that is). Here's the two shirts I got for my 2016 and 2017 efforts:
Needless to say, I find that an awesome initiative, seeing that the world builds upon open-source software. The five pull-requests that got me my t-shirt this year were:
To finish this off I can't recommend participating in Hacktoberfest enough, and thanks to DigitalOcean to appreciate this by giving you a t-shirt.
50 Million Lines of Bugs#
I often think about the following Mercedes-Benz advert:
In what world having whatever many lines of code should be something to brag about is beyond me. The tweet already hints at this nicely. But the marketing department seemed to have a different opinion in this case.
While I don't have credible numbers to back this, I think we can agree more code correlates with more bugs in some way. So Mercedes-Benz, please, try to keep the number of lines of code in your cars as low as possibly can be.Next page »