I've always worn a helmet, but have still been sort of sympathetic to those who say that it's not necessary and won't necessarily help you that much in an accident. Maybe. Depends on the accident.

A couple weeks ago I slid on some black ice making a turn onto the street where I live and BAM, pavement-kissing time. It had been rainy that day and the night temperatures had fallen just below freezing, making it prime weather for unexpected ice.

This poor helmet's been retired now after a job well-done. Note the crack in the foam and the road-imprint above it. I had a headache the next day, but was back up to 100% normal within 36 hours. One of those things that could have been way worse.

If I wasn't a helmet evangelist before, I am now.

At the FSF's Libre Planet conference this year in March, there will be a track focusing on increasing the participation of women in free software.

If you are able and support this cause, consider donating to fund additional women's travel to this event. Being able to meet in person with other people like you is such an energizing opportunity. Give this gift to someone who wouldn't otherwise be able to make it!

This spring I'm taking a class that does all its programming assignments in MIT Scheme. The last time I had to write Scheme for class, we used PLT Scheme, and thus the DrScheme editor. This time, with that option out, I've decided to do the assignments in Emacs. It is, after all, an editor built out of lisp.

I've used vim for the last five years or so. Some people ask me why this is so—I do go to MIT after all, where Emacs was originally written. The answer to that is simply that Debian got to me first, and at the time at least, the people I knew there used vim. I've heard Emacs is good, but up until this point every time I've tried it I've thrown it down in frustration and then couldn't figure out how to exit the damn thing. This time I was more determined, and made it through the initial hump of being completely useless at the editor.

Here are a few of my observations so far, after mucking around for a couple days over a period of about two weeks:

• The movement commands seem much more awkward to me. Since I'm using the Colemak keyboard layout, I have backspace bound to Caps-Lock, and it is not available to be a Control key. It may be that I just need some more time to get used to emacs not being modal.

• It's awkward to switch between split windows using C-x o when I have 4-6 open at a time. I'd like to be able to jump between specific ones directly.

• C-x 3 will always split the window containing the current buffer evenly in two, which makes it difficult to, for example, create three equally sized vertical windows, side-by-side. Vim defaults to creating evenly sized windows even when you invoke a split twice in a row.

• The paradigm of being able to have e.g. a scheme buffer or a shell as one of my split windows is nice, though I haven't yet gotten used to having to use emacs special bindings to interact with those buffers rather than what I'd use if I'd just invoked the command from a terminal.

• I noticed that emacs automatically detects the VCS in my directory. It seems incredibly bizarre to me to interact with my VCS from my editor. Do people actually do this?

• Emacs's use of the tab character to perform code indentation is interesting. It does solve the problem of code being auto-indented when you don't want it to, which sometimes happens to me in vim, but I wonder if it actually ends up saving keystrokes in the end, since I think not auto-indenting is the exception rather than the rule for me.

• There seem to be two different methods for completion: "dynamic abbrev" expansion, which I believe is analagous to what I'm used to in vim, and M-TAB (what a horrible keybinding, as most window managers will grab this for window-switching), which seems to be some sort of language-specific completion. I haven't yet seen how this can be harnessed since the symbolic completion seems to be irrelevant for scheme.

• Emacs's syntax highlighting gets at least one thing right about scheme that vim doesn't: extended comments between #| |# patterns.

• Bookmarks seem waaay more verbose/awkward than vim's marks. C-x r m NAME huh? I like being able to have a very short pattern to mark and jump back to points in a file, like vim's m/` syntax for marks. Maybe I'll need to bind the bookmark functions to something else.

I'm pretty sure at this point that I'm still trying to bend emacs into being vim with different keybindings instead of figuring out how emacs wants to be used. It's also difficult to compare and contrast between the two editors in that my .vimrc contains years of tweaks and customizations whereas my .emacs started out as a clean slate.

There are two things I'm doing to try to mentally separate emacs from vim, to avoid my fingers' muscle memory from becoming confused:

1. I'm always using emacs in an X window with dark-on-light text, whereas I always use vim in a terminal with light-on-dark text.
2. I'm only writing scheme in emacs. No other languages so far.

I'm planning to keep working on these programming assignments in emacs, despite it being annoying slower than I would be in vim. Tips and pointers for improving my experience are welcome.

I recently read Mihaly Csikszentmihalyi's seminal work Flow. It's been on my list of books to read since I heard about it last summer, since I've heard for ages that the state of flow is the state in which we are most productive. And besides that benefit, it feels great to lose yourself in your work. So, the idea of finding out what we know about the conditions that produce flow is very appealing to me, and probably is to others as well.

I found that my own distinction of flow as being a state that one achieves only when doing knowledge-type work to be far too narrow. I associated the word "flow" with writing a paper and having the words just roll off the keyboard almost effortlessly, with losing myself in writing some code, with designing and problem-solving. Post reading the book, I see that flow can be achieved in many other contexts, such as in conversation with friends, when playing a sport or a game, or reading a book. In many cases, flow may be easier to achieve in conditions other than work.

Csikszentmihalyi's basic premise is that we are most happy when we are in flow, and that flow is produced when a person is engaged in a goal-directed, rule-bound activity that has ready feedback on how he is doing, and is faced with challenges that are suited to his ability level. Flow can occur spontaneously, but it is more likely that it is the result of a structured activity such as a game or work or of a person's ability to make flow occur. For example, surgeons often report that their work is a source of great happiness and optimal experience for them, and that they wouldn't give up being surgeons even if they weren't well-payed for it. A surgeon's job is practically designed to produce flow experiences. The surgeon has a very specific goal--to perform a certain operation, and has instant feedback as to how well he is doing. He has certain procedures that provide a ritualistic way for him to get in the mindset of concentration and allow him to forget external worries for the duration of the surgery. Flow activities "transform the self" by "making it more complex"—flow activities push us to higher limits and allow us to experience states of consciousness that we have never before experienced. In this way, they are more satisfying than diversions such as watching television, which capture the mind's attention and alleviate boredom but provide no challenge to the self.

While the structure of certain activities makes it more likely for flow to occur for those engaged in them, there are some sorts of people who are able to produce flow experiences despite their surroundings being ill-suited. Csikszentmihalyi says that these people have an "autotelic personality". These people are able to alter their own consciousness to produce flow, regardless of external factors. He gives examples of Nazi prisoners held in solitary confinement who were able to find growth and sanity by inward thought despite horrendous external conditions, and a blue-collar factory worker who was able to turn his assembly line position into a challenge where he was always trying to beat his previous speed records. While some people seem inherently better at being happy and finding flow in inideal situations, we can all improve our ability to control our consciousness and find flow.

One point that I found striking in the book was that, despite people generally feeling that when they are at work they would prefer to be home, people report more optimal experiences at work than they do at home. Sunday morning is the time that people are most likely to feel depressed. I can identify with this premise from experience--when I feel down it's most likely to be a Saturday or Sunday, or another day where I am excused from my normal daily routine and am less likely to leave the house or make the decision to commit myself to an activity. In our culture it is popular to view work as manacles on our freedom of choice, when in reality it provides structure and goals for us. While we can in fact provide this structure for ourselves, and thus have more control over what we are doing and who we are helping achieve their greater goals, work often does provide an easier way to achieve flow without having to realize ourselves how to create it.

Despite being as old as I am (it was written in 1988), I found Flow to be thoroughly informative and enjoyable. Its lessons are clearly still applicable, and not as widely known as they deserve to be.

I received a surprising 13 responses to my previous post, which was certainly more than I expected and is one reason it's taken me a few days to follow up on it. (How do you pick someone from a group of 13 people based on just a paragraph or two? Clearly I'd like for someone to help all of these people get involved in Debian, but to do so solely by myself would be making a commitment that I just don't have time to come through on. So, it ends up being quite arbitrary. I pick who I think I'd most like working with and could make the most out of the opportunity, and even that is an arbitrary judgement based on very little.)

One question asked by one of the people who emailed me was, "Why did you ask for someone who isn't involved in Debian already and who doesn't necessarily have the technical skills needed?"

The answer to this question has several facets.

For one, people already involved in a free software project tend to be busy people. The workload in projects tends to be concentrated in few hands, and many of those people who are already involved in a project don't need or want any more work. So, asking for someone not already involved in Debian increases the pool of people who might respond to such a request and actually be able to follow up on it.

While this a valid reason, it still doesn't explain why I didn't just say, "it's okay if you're not already involved in Debian or don't know python" and not state a preference as to the skill level of the person who would respond to such a request.

I did, however, have a specific reason for stating my preference. I asked specifically for someone who wasn't already involved in Debian and who didn't necessarily know python or consider themselves a competent programmer because I wanted to encourage people who don't consider themselves to already know enough to be a useful comaintainer to contact me. I've picked up a lot from following Geek Feminism on what sort of language turns minority groups like women away, and I wanted to ask in such a way that it didn't turn away people who aren't good at self-promotion or who are less sure of their skills, or who don't yet have the skills, men and women alike. Even I still sometimes internally question my own competence as a programmer, and my self-confidence has increased over the past few years.

(For the curious, the responses I received were, at my guess, 85% male, 15% female. Whether that's a success or not depends on the demographics of those who read the post, but it is better than the ~98% male involvement in the FLOSS world altogether.)

And I do think it's more of a contribution to the project to help someone new get involved than to try to convince someone who's already overcome the barrier to entry to take on some more work. We'll see how it turns out in the end. I have high hopes. (No pressure, soon-to-be-selected mentee.)

Quodlibet is a GTK+ audio library manager / player. In Debian, it makes up four binary packages: quodlibet, quodlibet-ext, exfalso, and quodlibet-plugins. It's big/popular enough to get a few bugs filed against it and for people to yell when things break, but not so big as to be overwhelming.

Since the previous comaintainer has been inactive for some time, I've been thinking that it might be nice to have a comaintainer again. During my academic term at MIT or if I'm on vacation, I don't get to things as quickly as I should. The package has also gone through a period of inactive Debian maintainers and a period of inactive upstream maintainers, so it's accumulated a fair number of ignored bugs in the BTS. And in general, having others to fall back on is a good thing, as long as it doesn't lead to no one taking responsibility.

So, here's a deal: I want a comaintainer. There's a catch, though: this person doesn't need to be already involved in Debian. In fact, I'd prefer it if she weren't. If you have a good grasp on the English language, enthusiasm for Debian, and a willingness to learn some technical skills, contact me, preferably via email, and let me know who you are. Quodlibet is written in python, but I'm explicitly not saying that you need to know python in order to help out. You'll gain the benefit of having someone willing to answer your questions and direct your efforts and an automatic sponsor for uploads you prepare.

I can't say I have a ton of time to put into mentoring someone, but I'm willing to put in some, so hopefully such an arrangement will turn out well for all parties involved: you, me, upstream, and Debian.

I love unicode. You should too. For the unicode-lover out there, Joachim Breitner recently created an xscreensaver hack called unicode and uploaded it to debian. [1] I didn't like the default colourscheme of black text on a white background, so I hacked it to support colour configurability. The patches are in the Debian package as of version 0.2-1.

If you're using xscreensaver, you can configure it using the xscreensaver configuration dialog for a subset of the available colours. If you want different colours, you can edit ~/.xscreensaver by hand.

Gnome screensaver, however, does not have a configuration UI, opting instead to present a simpler interface and also allow administrators to lock down the screensaver configuration if desired. You can still configure the screensaver on unlocked systems without a GUI. Here's how to do it. [2]

At a terminal:

mkdir -p .local/share/applications/screensavers
cp /usr/share/applications/screensavers/unicode.desktop .local/share/applications/screensavers
editor .local/share/applications/screensavers

There's an Exec line in the file that should look like this:

Exec=/usr/lib/xscreensaver/unicode -root

Change it to look like this:

Exec=/usr/lib/xscreensaver/unicode -root -background <bgcolor> -foreground <fontcolor>

Swap the two colours with any X11 colour of your choice. Make sure to quote any multiple-word colour names. I like black as a background, with white or firebrick or another non-jarring bright colour as the font colour.

If you want, you can also change the "Name" field in the file, but it's not necessary for things to work.

Now, open up gnome-screensaver-preferences and select the new screensaver.

Lastly, leave your laptop strategically with the screensaver on to geek out all your friends with your unicode prowess.

[1] Thanks Joachim!

[2] There is actually another way to do it, if you prefer to interact graphically. For the other method, get /usr/share/applications/screensavers/unicode.desktop, edit it to your taste, and then drag-and-drop it onto gnome-screensaver-preferences, which will automatically put it in the right place in .local. You may need to restart gnome-screensaver preferences in order to see the new screensaver in the selection box. The feedback isn't very good.

On the train to my parents' house for Christmas I finished up a wild run through the book Coders at Work. The book isn't even mine, but I'd been borrowing it very often, sometimes to the chagrin of its owner, because I could barely put it down.

The book is a collection of interviews with 15 great programmers of our time, starting with Jamie Zawinsky and ending with Donald Knuth. It's written in an interview style—each interview starts with a brief introduction to the person being interviewed, summarizing what the person is known for and what he or she has accomplished and a few of the highlights of the interview, and then a transcript of the interview follows, with the author/editor, Peter Siebel, will saying something or asking a question, and the interviewee responding. I was skeptical about this format at first because I feel like it can be an easy way out of good editing and make the reader have to do the work of the editor, but on finishing I think that Siebel uses the format to his advantage in this case.

For one, the speech format allows the reader to really form a picture of how the person being interviewed speaks and would act in a conversation. Jamie is somewhat bitter and pretty informal. Brad Fitzpatrick is flippant and energetic, his speech littered with profanity and colloquialisms. Others seem more stately and verbose—Joe Armstrong's responses can go on for a page or more. In this way, not only do readers learn something about what these greats have learned about programming, but we also feel a bit more like we've met or know them, and can connect to them more as people.

I always have this problem where I want to read computer books, but often computer books seem inextricably tied to the computer, so there's this dynamic of reading a bit and then wanting to get on a machine and try something out, write some code, play around—especially with books focused on a specific language. Coders at Work retains some of this computer-book dynamic in that I constantly encountered things that I want to investigate or play around with more: Erlang, OCaml, various papers and essays, Knuth's literate programs, and books such as Higher Order Perl and others. Siebel makes a point to ask each person what her short-list of books and papers programmers should read are, so this book is a great source of pointers to other reading material. Unlike a more specific book, however, keeping a list in a notebook was enough to settle the mind to read away-from-a-computer for chapters at a time.

It's obvious that despite the interview format, Siebel has done some serious editing. None of the prose is boring to read, and I can't imagine that the text is a straight transcript of how the interviews went. He also has arranged the interviews in an order such that different interviews play off each other. In Branden Eich's interview, for example, he disparages the book Design Patterns:

I never bought the Gamma book. Some people at Netscape did, some of Jamie Zawinski's and my nemeses from another acquisition, they waved it around like the Bible and they were kind of insufferable because they weren't the best programmers.

In the next chapter, Joshua Bloch names it as a book he thinks programmers should read:

Another one, which I have slightly mixed feelings about but I still think everyone should read, is Design Patterns. It gives us a common vocabulary. There are a lot of good ideas in there.

Similar plays, such as Ken Thompson and Fran Allen disagreeing on the badness of C, happen in later chapters, tieing together the different chapters and illustrating how even really good programmers disagree on the Right Thing all the time. Clearly the craft of programming is no settled thing.

Besides the general structure of the book being well thought-out, the material is generally thought-provoking and interesting. One thing that stood out to me was Joshua Bloch describing what he called the "empathy gene", which is what a programmer has to have if he's going to be able to design good APIs and programming languages—he has to be able to put himself in the shoes of the person who will be using the language or API. This is one thing that differentiates how different programmers can be good at different things.

Another thing that stood out to me is that many of those interviewed stated that they don't use much in the way of modern tools and IDEs—Joshua Bloch and Simon Peyton-Jones both touch on this, just to name a couple examples, even though some say that they think using these tools would make them more productive, especially when it comes to refactoring. This is a testament to the power of inertia—sometimes there is just no chance to be unproductive now in order to be more productive later. Or perhaps just a sign that a programmable text-editor can stand on the same level as a heavier tool in terms of productivity in the right hands.

I could go on with examples, but the conclusion here is that I thoroughly enjoyed Coders at Work, and I think it is a book that is well-worth the time spent reading the entire thing.

A python example in ipython:

In [1]: for i in range(10):
...:     print "i in loop:", i
...:
...:
i in loop: 0
i in loop: 1
i in loop: 2
i in loop: 3
i in loop: 4
i in loop: 5
i in loop: 6
i in loop: 7
i in loop: 8
i in loop: 9

In [2]: print "i out of loop:", i
i out of loop: 9

This bit me last night while writing some code for a digital communications lab assignment. I typed the wrong variable name, which was from an inner loop when I meant to use the element from the outer loop. Is there actually a sane reason for a loop variable not to go out of scope when the loop ends? Tell me there's a good reason for it. It took me completely by surprise.

I was one of the participants invited to the FSF's Women in Free Software mini-summit which happened on the same day as Software Freedom Day this year. That was this past Saturday, September 19th.

I was feeling hesitant going in, given the controversy over "why would the FSF run a closed event about such an important topic" and just a general burnt out feeling about the subject on my part. Honestly, I've tended to avoid being much of a feminist in the past and simply hope that people will stop bickering and leave me to my code, especially in the aftermath following well-publicised incidents. This is despite the fact that the thing that got me involved with free software originally was Debian Women, back in late 2004/early 2005. I needed a hook, and yet I haven't felt confident enough to reach out to others now that I'm in.

I see now that there are valid reasons for having an event that is purposefully small. We all fit in a nice conference room at the FSF office, the atmosphere was very intimate, we got to learn everyone's names (and even remember them). I met some great local free software people who I hadn't met before. Food was take out from My Thai, an excellent vegan restaurant in Boston's Chinatown. While it sucks to be exclusive, in my opinion the small size really had an effect on what we got done and how we felt at the end.

The official minutes from the meeting are online here, and there's a picture and brief blog post from Deborah here. The picture was taken using Cheese! I'm in the middle wearing my ever-popular Best Practical "my free software runs your company" t-shirt.

There are only a few things I want to highlight myself.

1. It was a great idea to invite someone who is involved in freedom movements but is not necessarily heavily involved in free software in particular. Hillary brought fresh insights and helped us draw parallels and come up with ideas that I don't think we would have thought of otherwise. It's easy to get used to parts of a community as being "normal" and I am so happy that we have allies who can show us where we've internalised or just have learned to ignore sexist parts of the community. Women in free software are already in free software—and we need to learn to reach out to others who aren't in already.

2. Cooperative power. There are groups of people that just aren't attracted by FOSS marketing that challenges you to "prove yourself the best" or similar. Just because someone doesn't like coding at 3am doesn't mean he doesn't like coding. If we want to succeed at our mission, we need to stop thinking win-lose and start thinking win-win. This applies to being more inclusive in general, not just for women. It also applies to valuing contributions from those who don't code. We need them too.

3. There are times when I don't speak up and I should. There are times when I don't blog (or participate in discussions via other media) because I don't feel like dealing with potential community backlash. I am very careful about not stepping on peoples' toes, because I've seen other people get trampled on and am not particularly excited about experiencing that myself. While I'm trying to cultivate courage in myself, it was good to have a reminder that it's not just me.

The current plan is to hold a bigger event that is open to all in the spring. I am so excited about the momentum we are building! I think the biggest thing that I took out of this is that there are still things wrong with the community and that I shouldn't be afraid to speak up and be an activist. Watching people like Deborah and Hillary talk perfectly seriously about making very long-term plans and reaching parity was incredibly empowering.

We can do so much better. The time to do it is now.