What I learned at YAPC::NA 2008

From AndrewMoore

Contents 1 The Talks That Motivated Me Most 2 Administrative notes for next year 2.1 How to Have a Successful Town Hall meeting 3 Thanks to the google guys for the good closing keynote 4 How Many Eyes Does it Take to Make a Bug Shallow?

I've gone to YAPC three times now, and each time I go I get highly motivated to improve the project I'm currently on. I also occasionally get motivated to work on another project that has been drifting around in my head for a while. This is not typically because I learn much new, but because I see other people implementing cool stuff. It's motivating to be surrounded by useful productivity. To show this, I'm first going to touch on a few of the most motivating talks.

The Talks That Motivated Me Most

Kent Cowgill gave a good talk on testing called Testing Code and Assuring Quality. He showed us how he can adequately test, including using Devel::Cover, on his Template::Toolkit code. He uses some pretty good tricks, including using Test::Module::Builder to build his on testing module. It never really seemed necessary, but now at least it seems very useful and handy.

I happen to be working on a codebase that uses HTML::Template, but I think I can pull off something similar. He has motivated me to try to more thoroughly test our HTML generating code. For instance, can I validate the HTML that comes out of it or try to perform functionality on it? These are the kinds of questions that always sit pretty far back in my head until I see somone pulling off something similar. Then, I'm motivated to try to do it.

Leonard Miller gave a brief introduction to Perl::Critic and Perl::Tidy. I'm rather familiar with both of those modules, and I know for a fact that Andy Lester is, too. But, when I checked my mail after the talk I noticed that Andy Lester had added a perltidy configuration file to the Ack codebase. I believe that just by sitting in on the thousandth talk that mentioned perltidy, Andy was motivated to finally start using it on Ack. That's proof that it's not always what you learn at YAPC that counts. Sometimes it's just what you're motivated to do.

Schwern gave a talk about Testing With the SIMS. I had spoken with Schwern about this before, and I've done something similar, but Schwern took it to a new level. He makes methods to generate random (or arbitrary) but valid data to populate his objects used during testing. This is pretty handy for uncovering corner cases in your code. For instance, if your Person object that you use during testing is always populated with the name "Test E. Tester", you're missing out on an opportunity. Schwern populates his objects used during testing with random data, so sometimes the test object has a firstname property of "There once was a man from Nantucket" or something similarly obscure. If you weren't expecting people to have spaces in their first names, POW! You've uncovered a bug. I'll probably expand the amount of randomness in my test suite. This could prove to be pretty useful.

There are a few tricks that were uncovered during this talk. One is that in order to allow you to reproduce these problems, save our output the random seed used to seed the random number generator. That way, you can run the test suite again with the same data and ensure that you fix any bugs that you uncover. Another is that in order to prevent the test suite from failing on an unrelated piece of code while you're working on something, you may want to use the same seed several times in a row. For example, if you always use something based on today's date, then you can ensure that during a test, code, test cycle that your failures are genuinely due to recent code changes, and not due to uncovering an unrelated bug with new data.

I was interested in getting Smolder working before I went to YAPC. Michael Peters talked a bit about it and described how to use buildbot to run your test suite and then send the results to a smolder instance for viewing. He even set up a test instance of it so that I could send my results there and see how it worked. Thanks, Michael! Smolder still seems a bit cantankerous, but after I get the test suite run regularly, I'll probably try to send the results to smolder so that I can gaze at pretty pictures.

Matt S. Trout's gave what was probably the most educational talk for me. Since he didn't give another "introduction" talk and made one instead that was pretty advanced, I actually got to see interesting uses of DBIx::Class. I have never used DBIx::Class before, but was really curious about it. Now that I've seen the cool, advanced stuff that It can do, I'm motivated to go figure out the easy stuff and see if I can use it in my project.

chromatic delivered his "How To Fail" talk, which was another one that really had an impact on me. He described a few things that teams can do to improve their process of developing software. The one that stuck out to me most was his argument for regular, time based releases. By releasing code each month, the parrot guys have vastly improved their project, and the argument is that this is not a fluke and you can improve yours by having time based releases, too. It sounds to me like some of the reasons are:

• to build the trust of your user base (and potential users) by demonstrating regular progress
• develop a rhythm in your project of knowing when big features will be checked in and when bug reports will pick up
• you get to practice the process of releasing and to automate as much of it as possible so that you can do it well
• forces features to be "done done". This is different that being "done" with some qualifications like testing, documenting, or something else. Features need to be "done done" for release.
• and others

He also touched on ways to make it easier for people to get involved in the project and contribute. Some of the ways are:

• make it easy to submit smoke test results. They have a Makefile target to encourage people to submit test results
• make it as easy as possible to install and try out
• manage the patch queue well. If a submitted patch is applied immediately, the instant gratification encourages more patches to be submitted.
• refactor your code to make it easier to use and modify. No one likes to contribute to maintenance nightmares.

chromatic is always highly motivating to listen to in spite of the fact that his delivery is not the high-energy type that a motivational speaker might have. He does things consistently well and encourages others to do the same.

Administrative notes for next year

• the coffee, drinks, and snacks provided were great this year. Those are important parts of allowing people to sit through hours of talks. Please keep it up!
• If the schedule is simlar, the last afternoon could be run better with an MC or moderator. Someone to introduce the next speaker, someone to tell us that lightning talks will begin in 10 minutes after we get the projector set up, and someone to tell us that it's time for the Town Hall meeting and possibly facilitate it. Perhaps someone will volunteer (or be nominated) for this role. If not, it may unfortunately fall back on someone like Josh McAdams, who already has enough to do.
• Encourage better use of the lunch hours. I'd love to pay for a boxed lunch and gather for the lightning talks or town hall meeting during lunch.

How to Have a Successful Town Hall meeting

The Town Hall Meeting was a bit of a let down in my eyes this year. Honestly, though, I eventually walked out after about 20 minutes, so it may have gotten better after that. It worked really well in Houston, I thought. What were the differences? Here are the ones I think may have contributed:

• There were more people in the room during the Houston Town Hall meeting. Perhaps this is because it started earlier in Houston because we ran so long in Chicago. I think having more people helps a bit. It seems we were also more spread out in Chicago, but I may be wrong about that
• In Houston, the IRC backchannel was up on the display. This really helped encourage participation from people who either didn't want to stand up and holler or had such a small comment that it didn't make sense to. It's possible that people not at YAPC also benefited from this. I specifically asked for this this year at Chicago and my request was refused.
• I believe that in Houston it was easier to get a microphone. Contributing to this kind of discussion is easier if people can hear you. This also goes back to my perception that we were more spread out in Chicago. It was simply easier to hear each other in Houston.
• Uri didn't dominate the meeting in Houston. Uri got on stage in Chicago, put on the only mic, and ran the meeting like a question and answer session. Each comment that someone made that was seemingly intended to start discussion or gauge consensus was responded to by Uri who thought it was directed at him because he was on stage. Since he couldn't really address most of them, he eventually would often tell people to direct their comments to the organizers for next year or to the rest of the crowd. That's who they were talking to in the first place.

How would I improve this for next year?

• In order to ensure a better attendance, try to not hold it so late in the day. This may mean move it to earlier on the schedule, like during lunch on the last day. Or, it may mean that we work harder to not let the lightning talks run long.
• Facilitate crowd participation among themselves. It may help to have a facilitator or a moderator. Uri was right to attempt to fill this role. Instead of wearing the microphone, though, he should have worked to get it into the hands of the interested attendees. We don't have good instructions for our Town Hall meetings, and perhaps we should draw some up.
• have more than one microphone, and plant one on a stand in the crowd somewhere easy to get to.
• put the IRC channel on the screen.
• If the auditorium or hall is sparsely populated by the beginning, encourage people to move closer.

Thanks to the google guys for the good closing keynote

Brian Fitzpatrick and Ben Collins-Sussman from Google gave a great talk on Wednesday about customer service, or making your software easier to use. It was just the right type of talk to hear on the last day. It was pretty light on technical content, very motivating, and really well presented. Thanks for coming and letting us listen to you guys.

This is not the video from YAPC, but it looks like a really similar talk. http://www.viddler.com/explore/Flourish/videos/4/

How Many Eyes Does it Take to Make a Bug Shallow?

One incident really stood out to me and struck me as odd. The auditorium was pretty full at one point, so there were probably about 100 really good perl programmers in the room. The talk was being given by chromatic, I think. Anyway, there was a slide up with some pretty trivial code on it. There were about 2 or 3 statements that called ok() to test whether a few things were equal. The slide was up for a while, maybe almost 5 minutes before someone pointed out that there was an error in it. Instead of ok(), is() should be used there to test equality. Apparently, chromatic had actually just copied this example from the actual test suite, so he said that perhaps the bug is there and not just in his slide. Larry pulled up the code, and sure enough, the bug was there.

So, what does this mean? Does it mean that even with a lot of eyes, not all bugs are shallow, even the really trivial ones? Does it show how much help the Parrot and Rakudo guys need? Does it show how easy it is to help them? Probably a little of all three. Anyway, I was stunned.

I'm looking forward to YAPC next year. I learn more every year, but most importantly, I get more motivated again every year.