Archive for July, 2011

Distracting examples ruin your presentation

July 26, 2011

At OSCON today, I went to a talk called “Why Know Algorithms” by Andrew Aksynoff. I was pleasantly surprised to see that the speaker was the author of Sphinx, a powerful full text indexing engine that I’m considering adopting for a project.

However, halfway through I was shocked, especially in light of all the problems with sexual harassment and sexist attitudes at conferences that have been brought to the fore lately, to see the example that Andrew used: Selecting women from a database, ranked by “hotness.”

Here’s the table layout he used (and I apologize for the blurriness):

CREATE TABLE usertest (
    id INTEGER PRIMARY KEY NULL,
    sex ENUM ('m','f'),
    age INTEGER NOT NULL,
    hotness INTEGER NOT NULL,
    name VARCHAR(255) NOT NULL,
    INDEX(sex,age,hotness)
)

His sample code revolved around ways to optimize this query:

SELECT *
FROM usertest
WHERE age >= 18 and age

The latter half of the talk discussed various ways of creating indexes to efficiently provide answers to that query, and which queries would run best with different indexes, in case you want to order by age instead of hotness, for example.

I was angry about two things. I’m specifically not going to address the crass sexism here. I know plenty of others can (and will) address it better than I can.

I was more upset about the effects of the sexism in the classroom. When I’m here at OSCON, I’m both teacher and student. When I’m a student at a session, I want to pay attention to the content, not wonder how the women in the audience feel about the instructor’s attitudes towards them. Are they offended, but afraid to leave? I saw no women leave, although plenty of men did.

Andrew clearly knew his material, and he explained it well. Strictly from a teaching perspective, Andrew’s problem was that the examples overshadowed the lessons to be taught. It’s the same frustration I had with Steven Feuerstein’s book from O’Reilly on Oracle 8 where his examples included a table of war criminals including Henry Kissinger.

When you’re teaching a class, don’t include anything that detracts from the message you’re trying to teach. A LOLcat slide is fine but include too many and that’s what people will remember rather than what you’re trying to teach. It should go without saying that examples that make the audience uncomfortable will also ruin your class.

Note: I will delete any comments that include personal attacks on anyone.

401 passwords Twitter won’t let you use

July 25, 2011

Twitter has a list of 401 passwords that they disallow, not because of content, but because of how commonly used they are. A common password is easier for a bad guy to guess. None of these are passwords you’d want to use anyway, because they’re so easily guessable by a simple dictionary attack. Bad guys have lists like this anyway, and Twitter is trying to make the most common and unsafe passwords unusable. I wonder how many people would use “111111” as a Twitter password if allowed.

The list is embedded in the JavaScript of the website. Search in the page source for “BANNED_PASSWORDS”. The list is ROT13-encoded, but with Perl that’s trivial to decode:

$str =~ tr[a-mn-z][n-za-m];

The list contains a fair amount of profanity and sexual language below, as you might expect, and geek words like “ncc1701“, “thx1138” and “rush2112“, but also plenty of sports teams like “steelers”, “broncos” and “arsenal”. Many common names like “jennifer” and “michael” show up as well. Note that shorter passwords like “asdf” aren’t included because Twitter requires a minimum of six characters for passwords anyway.

As I write this today, there are 401 passwords in the list, which is 31 more than were reported in 2009. It seems from that article that they weren’t ROT13ed at the time.

The full list (slightly expurgated) follows:

(more…)

Six tips for preparing to attend a technical conference

July 21, 2011

I’ve been going to technical conferences since YAPC::NA 2002, and next week I’ll be at OSCON 2011 talking about community and Github. Preparation is important to getting the most out of the conference with the least amount of hassle. Here are some tips I’ve learned along the way.

Bring power tools

Power cord, display dongle, cube tap and business cards

Not electric drills and saws, but tools for getting power. Conference organizers may not have planned adequately for the influx of laptops, and electric outlets can be a rare commodity. If you’re flying to a conference, it can be especially difficult to find a plug at the airports. O’Hare in Chicago is especially bad.

If you can fit a power strip into your laptop bag, good. If you want to go cheap, go buy a cube tap at your hardware store for two dollars.

Make sure you bring your cell phone charger and a USB cable to hook up your phone to your laptop, too.

Label your stuff

If your forget your laptop power cord in a room, whoever finds it isn’t going to know whose it is. At the Apple-heavy conferences I usually attend, everyone’s cords all look the same anyway. Label it with your name and cell phone number. Same goes for anything else that you might use and lose, such as display adapter dongles. It’s frustratingly expensive to realize you lost a $25 piece of plastic.

Plan what you want to see

If you leave conference talk planning until the day of the talk, you’re more likely to miss seeing the really good stuff. Amidst all the talk in the hallways and hanging out in the exhibit halls and hackathons long lunches with new friends, it’s easy to forget about that one talk you really wanted to see until you look back on the schedule and realize it ended half an hour ago.

The OSCON scheduler makes it easy to mark the talks you want to see, but for the most important ones, I suggest adding them to your calendar on your phone and setting an alarm.

Bring business cards

You’re going to meet people, so give them something to remember you by. I’m talking about making your own business card, not your company business card. Your card need not be fancy, but if you can get a graphic designer friend to put together something nice in exchange for lunch and/or a few beers, so much the better. At the very least, you’ll want to include your name, website, email address and cell phone number. I also put my Twitter ID and Github ID on mine.

My box of 500 business cards was only about $20 delivered to my door. It’s fantastic bang for your buck for keeping in contact with the people you meet.

Get a laptop bag with a shoulder strap

While you’re at the conference, you’re going to take your laptop with you at all times. AT ALL TIMES. Every conference, someone gets a laptop stolen. You’re not going to let it be you.

Do not trust the guy next to you to “watch this while I run to the bathroom.” When you go to the bathroom, or grab a drink, or whatever it is that you do that isn’t seated at a conference table with your laptop in front of you, you’re going to have your laptop zipped up in your bag, with the strap over your shoulder. This goes double for airports.

Bathrooms are an ideal place for a thief to take your laptop. I assure you that standing at a urinal trying to take care of business with a laptop tucked under your arm is not fun. If you’re in a stall, be aware of how easy it is for a thief to grab a bag from under the stall, or from reaching over a door and taking the laptop from the hook.

A laptop bag with a shoulder strap is the only way to go.

Clean your house

Wash the dishes. Empty the garbage. Take stuff out of the fridge if it’s going to go bad in your absence. A lot of nastiness can happen in five days.

Other tips

I asked on Twitter for suggestions for conference prep. Some replies:

  • Give a practice session of any talk that I haven’t given before. — @mjdominus
  • Make a checklist of all cables I need. Then research where to buy them in Portland just in case. — @rjbs
  • Get a lot of sleep the week before. — @adamturoff

What suggestions do you have? Please leave them in the comments below.

Toward ending RTFM marketing in open source

July 20, 2011

Too many times I’ve seen a conference announced once, and then never heard about it again. It’s what I call the RTFM method of marketing: Either you happen to know about the event, or you lose out. This year for YAPC::NA, the annual North American grassroots Perl conference, lead organizer JT Smith isn’t going to let that happen.

No sooner had the 2011 conference wrapped up when JT started daily postings about 2012’s event to the YAPC::NA blog. He plans to keep that pace going for the next year, until June 13th, 2012 when 2012’s event start. The goal is to keep people thinking about YAPC::NA in the next eleven months, and to keep everyone’s expectations high. “Everyone at YAPC 2011 laughed at me when I said I was going to do a blog post a day,” JT told me on Sunday, “but I’ve got the next 300 postings planned out.”

It’s not just frequency that’s different this time. JT’s writing about the details of the conference, and why you’d want to attend. His posts give tips about the best way to travel to Madison, and attract potential attendees with views of the conference location on the lake. A “spouse program” for the non-hacker members of the family is also high on his publicity list.

As JT and I ate lunch at the bar where he hopes to have a YAPC beer night, we discussed the mechanics of this ongoing communication campaign. JT has the next thirty postings written and posted to Tumblr with future publication dates, letting him create postings in batches, rather than every day. “I chose Tumblr for the blog because it has the best posting scheduling system,” he told me.

You can follow the YAPC::NA Twitter stream at @yapcna, or the blog itself at blog.yapcna.org.


I give “RTFM marketing” that name because it’s an extension of the geek notion of RTFM. “RTFM” comes from the rude geek response of “RTFM”, or “Read the F-ing Manual”. It’s used as a reply to a question that the geek thinks should not have been asked, because the information exists somewhere that the querent could have looked himself. It’s as if the rude geek is saying “The information exists in at least one place that I know of, and therefore you should know that information, too.”

The idea that one should just have known about a given piece of information applies to this sort of undermarketing as well. Project leaders seem to think that when information has been published once, everyone will know about it. The RTFM marketers expect that everyone know what they do, read the blogs they do, travel in the same online circles as they do. This is a recipe for failure.

This mindset can be crippling when it comes to publicizing projects and events. Organizers do their projects a disservice when they market their endeavors with the expectation that everyone will automatically know about something simply because they’re written one blog post about it.

RTFM marketers also don’t spread their messages wide enough. They advertise to the echo chamber of the circles in which they normally run. They’ll post to the standard blogs, post to the mailing lists they read, or discuss it in the IRC channels they frequent. This limits the potential audience for the project to the one with which the project leader is already familiar.

Tips for doing open source project marketing right:

  • Write & post frequently.
  • Write & post in many disparate locations.
  • Explain the benefits. Explicitly tell the reader why they would want to attend your event or use your software.
  • Change your messages. Don’t post the same thing twice.
  • Never assume that someone will have read your previous message. It’s OK to repeat something stated in a previous message.
  • You don’t know your potential audience as well as you think you do. Think big.

I’d love to hear stories and ideas about how you got the word out about your project.

“Building and Maintaining a Project Community with Github”, my talk at OSCON 2011

July 16, 2011

Here’s the OSCON page link to add to your schedules.

github.com has taken open source by storm, but it’s more than just a code repository with the latest hot source control system. It’s a new way of working with open source projects.

The web-based social aspects of github can change the human and technical dynamics of working on open source projects. Some of the issues I’ll discuss include:

  • Easier access to code means lower barrier to entry means more people submitting patches. This is a boon, and brings challenges.
  • People seem to expect patches to be accepted because of the ease with which change sets are created. These expectations may clash with project goals.
  • Watching the github fork network lets you see what other people are doing with their forks. It allows me as a project admin to see what people are doing with the code.
  • New workflows are required. A branch and merge strategy for development is crucial.
  • Projects need a guidemap to tell people what to do, because people may think it’s just a simple matter of creating a fork, making a change, and saying “Here’s my work, now integrate it.”
  • Project branches can easily become large, hard-to-handle change sets. Less care and thought is put into change sent back to the project because merging is so easy. Contributors still must work together to coordinate work.
  • Discussion of patches has moved from the mailing list to the change request itself. This can diminish visibility and discussion.

I’ll discuss these and other aspects of community and project management and give examples from my own experiences migrating existing projects to github.

The touch command does more than just create empty files

July 10, 2011

Beginners to Unix/Linux learn about the touch command as a way to create an empty file.

$ ls -l /tmp/foo
ls: /tmp/foo: No such file or directory

$ touch /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul 10 11:56 /tmp/foo

But there’s more to it than that.  The main job of touch is to modify the timestamps on a file.  Creation of a file is almost a side effect.

The -t argument to touch lets me specify a date and time to set on the file.

$ ls -l /tmp/foo
ls: /tmp/foo: No such file or directory

$ touch -t 201107010930 /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul  1 09:30 /tmp/foo

If I don’t specify a date and time, then the current date and time are used.

$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul  1 09:30 /tmp/foo

$ touch /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul 10 11:58 /tmp/foo

You can also use the timestamp from another file and apply it to another file by using the -r switch.

$ ls -l /tmp/someotherfile
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/someotherfile

$ touch -r /tmp/someotherfile /tmp/foo /tmp/foo2 /tmp/foo3
$ ls -al /tmp/
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/foo
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/foo2
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/foo3
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/someotherfile

man touch will give you all the details.

Don’t try to make things on your résumé sound more interesting than they are.

July 6, 2011

Did you work a cash register at one of your jobs? Then say that in your résumé and move on. Don’t try to make it sound more exciting than it really is.

If you try to fluff it up and make it sound “more businessy” or “more resume-friendly” than it is, the person reading the résumé will just roll her eyes. Maybe she’ll laugh at you, or call someone over and say “Hey, this guy worked a register and called it ‘Accounting for legal tender’! Ha ha!” We know when you’re trying to fool us, and we think it’s both funny and insulting.

Now, if your cash handling is a key component to your background, perhaps because you’re working to be a cashier at a casino, then by all means, play it up, by giving specifics: “Handled over $50,000 per shift with zero short/over”. That way you’re showing the scope of your responsibilities. But if you’re looking for a sysadmin position? Don’t bother.

A résumé is about telling a company about what you’ve done that will help them decide that you’re worth bringing in for an interview. Don’t try to BS us in the process.

I’ll be presenting “Just Enough C for Open Source Projects” July 19th at Software Craftsmanship McHenry

July 1, 2011

For programmers raised on high-level languages like Perl, Java and PHP, working on a C project can be daunting. Still, many open source projects work at a low-level in C to take advantage of the power and speed of working close to the machine. Whether it’s Perl, Postgres or Linux, C is what makes it run.

This session will provide a high-level overview of C, aimed specifically at the programmer wanting to get involved in a C-based open source project. We’ll cover:

  • Nothing in C is DWIM (“Do what I mean”)
  • Numeric types, strings and structures
  • Memory management: the heap, the stack, and pointers
  • Using the preprocessor
  • Understanding compiler warnings
  • Memory checking with valgrind
  • How to navigate a large C-based open source project (ctags, etc)
  • Security, or, how the Bad Guys smash the stack

Sign up at mchenry.softwarecraftsmanship.org.