Advanced friction logs: Empathy Sessions
What do you do if a friction log isn’t convincing your stakeholders or they need to urgently address developer pain points? That’s when I set up an empathy session.
I have a relatively simple problem, my cat, Nick, can open our front door and let himself out. Since he’s a strictly indoor cat, this is a problem. In true computer nerd fashion, I way over-engineered a solution to lock the doors automatically after a specified delay to prevent Nick from escaping. My solution involves the Ruby Functions Framework, a container, Google Cloud Run, and Google Cloud Tasks.
A couple of months ago, my coworker Mark Mandel asked if anyone had a way of visualizing dependencies in Cloud Build. As you’d expect, several of us jumped at the problem. I wrote my solution up in Ruby using the graph gem.
Earlier this week I got to help host a group of girls visiting Google. They are middle school students in an after-school program focused on engineering, mathematics, and science. My role during the day was to lead computational thinking activities from CS Unplugged. Based on advice from co-workers the group completed the Error Detection and Sorting Networks activities. It was during the sorting networks activity that the kids taught me how vital even subtle parts of UI could be.
There’s a good chance you have some kinds of tests for your code. You probably have some unit tests and you may have higher level integration tests. Maybe your integration tests are written in something like cucumber or a record/replay test automation tool. Now, the hard question, do you run these tests against production? Most folks I talk to don’t. They think of testing as something that happens in pre-production environments. If you have a QA/test team working on your project you may even think of testing as something that delays the push from development to production. As a former tester, I’d like to propose that you run at least some of your tests against production.
Earlier this week, a conversation on the Seattle.rb Slack reminded me of one of my favorite hidden Gems in Ruby, the case
statement. Most languages have syntax for multiway branching. Java calls it switch
. Lisp uses cond
. Ruby calls it case
which relates back to the mathematical roots of this construct. Ruby’s implementation of this feature is particularly flexible, and many folks don’t realize all the things you can do with it.
This year there have been many problems that require writing an interpreter for a simple language. My favorite of these has been day 16 which had you execute some dance moves that modify an array. One of the dance moves is ‘spin’ which involves rotating the array by a constant. Another is ‘exchange X Y’ where the elements in the array at X and Y change places. The moves themselves aren’t complicated. The parsing of the input file isn’t complicated either. The problem gets hard though when you are asked to execute the entire sequence of dance moves 999,999,999 times.