Ada Lovelace Day profile: Robin Jeffries, Her Systers Keeper Emeritus and HCI expert

Ada Lovelace Day aims to raise the profile of women in science, technology, engineering and maths by encouraging people around the world to talk about the women whose work they admire. This international day of celebration helps people learn about the achievements of women in STEM, inspiring others and creating new role models for young and old alike.

When I first met Robin Jeffries, I had no idea how important she was. My friend Jen said, "hey, you need to talk to Robin about this" and the three of us sat down and chatted about technical stuff for an hour or so in the middle of a busy conference. It didn't hit me until much later that I'd just spent a time geeking it up with a woman who half the women at GHC would have loved to shake hands with, let alone get a whole lunch with.

Robin has just retired as Her Systers Keeper, a role she took over from Anita Borg when Anita's health was failing. She's not wrong in calling managing a community like this a job of cat herding, but with her guidance Systers has long been a list with an unusually high signal to noise ratio, and one that many technical women turn to when they need advice, want to share a story, or want to rant about the latest news piece about women in computing. I started realizing how much of a role model Robin herself has been to so many when I'd mention her and people would go, "wait, you know Robin Jeffries? I've always wanted to meet her in person!" These were women who were inspired by the stories she shares and her ability to get to the heart of the matter when it comes to the experience of technical women.

I've been fortunate enough to work with Robin doing Google Summer of Code mentoring for Systers, where we've been doing modifications on an open source project dear to my heart, GNU Mailman. She's got an uncanny ability to find good chunks of technical work that our students can manage, a knack for inspiring the people she works with, a good system for managing us all and keeping us to our deadlines, and every time we sit down to talk about how to fix a problem she impresses me with her insights into better architectures and designs. I've rarely had the chance to work with someone of Robin's experience in human computer interaction (read her bio, but in short, she's crazy accomplished and I probably would have been way intimidated if I'd known how much so when I first met her). I'm constantly in awe of how easily she not only applies that experience, but how good she is at conveying it to others and how willing she is to share her skills.

We're probably all benefiting from her knowledge as she applies it to her job at Google, but it's the more direct personal experiences that really get me. For example, despite being in great demand with the Systers 25th anniversary celebrations at GHC12 this year, she came out to help me run Open Source Day activities for women interested in hacking with Systers and Mailman, quickly adopting a whole table of prospective volunteers and walking them through the first stages of evaluating and contributing to an open source project. She regularly makes me wish I'd spent more time studying HCI myself, and forces me to re-evaluate how I design software. We've got one big feature we want to see in Mailman and I'm really looking forwards to working with her on making it happen.

I admire Robin for her amazing technical expertise, for her support of women in computing, and for her ability to balance the two as part of her own busy life for so many years. It has most definitely been my privilege to work with such an amazingly talented woman, and I hope that some day I can approach her level of professional and personal accomplishment.

Moving files you found with grep (and the joy of for loops in bash)

Back in one of my early, unpaid co-op jobs, I discovered that my otherwise reasonably experienced boss hadn't ever used tab completion, and it got me thinking a lot about how I learned a lot of command line habits through a combination of word of mouth and a personal conviction that the computer should be able to do anything I found repetitive (alas, I have not taught it to load the dishwasher). But the real take-home message is that there's a lot of little linux tricks that aren't really obvious to everyone. So in that spirit, here's an incredibly tiny script I wrote today that might be useful to someone else:

Moving files found with grep

I had a bunch of output files from my experiments, and I wanted to know at a glance which ones had failed, and then move those files to a subdirectory, leaving me with a smaller list of successes to evaluate in more detail.

Here's the script as a one-liner, the way I'd enter it:
for a in `grep -l -z "No repair found" repair.debug.*` ; do echo $a; mv $a notfound/; done

And here's some explanation:

grep -l "No repair found" repair.debug.*

My particular experiment prints a line "No repair found" when the run fails, so that's what I'm searching for in the output files it generates (repair.debug.*). The -l makes grep print just the filenames so I don't have to do any special work to parse them from the output. (You can also use the longer but easier-to-read --files-with-matches. I'm guessing -l was intended as "l for list" but I don't know.)

When I was googling for the -l flag, I did find some people with fancy xarg stuff you could do here, but seriously, if all you need is the filename save yourself some hassle. If your filenames have spaces in them, you may find it useful to do that and some fanciness with -z to change the delimiters to be \0s, but I didn't need to do that.

for a in ` ... `; do ... ; done

This is my favourite little bash for loop with the functional bits cut out. It iterates over whatever you gave it in ` ... ` putting each item in $a as it goes through. In this case, each $a is one of the found filenames. You can do away with the backticks all together if you just want a list of filenames that you could get from ls, though. If I'd wanted to move all my repair.debug.* output files, I could have done for a in repair.debug.*; do mv $a output/; done -- no backticks! I do this all the time for moving files out of my way before I start a new experiment, using directories with the date to keep track of what ran when.

Another useful command to put in there other than a grep is `seq 10` which will give you a standard counted for loop that goes up to 10. Very useful when I want my computer run an experiment 10 times while I go to lunch!

echo $a
I almost always run a version of the loop with *just* "echo $a" in the middle before I make one that does anything, just as a sanity check to make sure I got the expression right and I am actually doing stuff to the right files. I usually leave it in the final version so I can scan the output easily and see what was done. Sometimes I actually output the whole command as an echo for debug purposes

mv $a notfound/

The easy part: moving each file that matched into my notfound/ directory.


And... there you have it! A quick way to move a set of files out of your way and a little bit about how to automate other repetitive tasks on the command line. Probably obvious to many, but who knows, maybe this is exactly the script that someone else needs.