More Presentation Sux

Besides a presenter not being great, another thing that kills presentations is when there are technical difficulties. If your talk is ready to go at 2:00, then it should go at 2:00. Nothing is more frustrating than sitting wondering why something that should simply work doesn't.

The good news is that I left, and went over to the session where they talked about contributing to open source. I think Stuart Holloway (hope I have his name correctly) is a great speaker. He pointed to some small piece of code in Rake, and how it bothered him, and how he strove to make it more beautiful. There was some agreement that it wasn't pretty, but not a general consensus on how best to fix it. Someone likened it to a bikeshed, where people could argue what color it should be.

I ended up skipping a talk on optimizing Ruby, and it seemed OK to skip, due to the quality of the presentation, not necessarily the quality of the content.

I'm now listening to a guy talk about "tightening the feedback loop". He's now doing a show of quick hands is that the Ruby community is heavily into testing. Apparently, there are two kinds of testing, some unit test and RSpec, which I heard during Railsconf, which is a unit test that looks like a spec. Apparently, the audience was split about half-half as to which they used.

He points out to something called autotest. Does this work in the background? Or run tests when you save?

He's now talking about something called flymake. Apparently does some on-the-fly syntax checking and shown within the editor (don't most IDEs do this?).

The guy wrote a e-lisp extension that does something similar to flymake with Ruby (flymake works with C). This highlighting works on tests, rather than on compiles. The code itself is highlighted in green and red, for good and bad.

Phil Hagelberg is giving the talk. The speaking rhythm could be a bit better. Some of it is not being particularly loud or into the talk. Not bad, but room for improvement.

Anyway, I decided to walk out on that one. I headed back to the open source development thing, but most people were coding, and nothing was being presented. I tried the next room, but got caught in the middle of something, and it didn't seem that interesting.

Did I mention how cool it is to be in the same hotel as the conference. When you aren't feeling it, you just go up to your room and rest. I took a quick shower, watched a touch of football. All cool.

Now I've moved to a talk on "maximizing productivity". I'm really hoping this will be a half-way decent talk. I'm telling you, a good talk is as much presentation as it is content. I know shy folks who don't like that, who are plenty bright, but have no idea how to engage a crowd. This is why they hire good actors for television shows than cast neighbors, because it would be nigh well unwatchable, even if what's being performed is intriguing.

Did I mention that conferences have another big issue? Because the rooms used to present are often combined to one bigger room, one big problem is that the floor is flat. That seems reasonable, but when you are watching someone speak, you don't want to be on the same level as the presenter. At the very least, you want the presenter to be elevated on a stage. As it is, without stadium style seating, you're forced to look over other people's shoulders, which is another reason I like to sit up front.

I was looking at the Rubyconf website. Compared to the Railsconf website, the content is minimalistic, only describing what the talks are. There isn't a wiki, places to go around town, ways to interact offline. Surely, with all the web development prowess in the Ruby community, someone would have produced a free version to handle conferences to give all these features, so it's trivial to set up. But apparently, these kinds of websites aren't particularly interesting to make?

This talk is being given by Eric Hodel. So far, his advice has been pretty straightforward, but one thing that's interesting is its simplicity. For example, being selfish, and just coding what you want, rather than solving everyone else's problems.

Eric is the second person who has mentioned autotest, which apparently is a tool that tests (on each save?).

Another key is having everything in sight. Code, autotest, test, and terminal as the primary windows, and a few other things.

He's the second person I've heard to mention something called heckle. Apparently, it modifies tests slightly and see if it still passes?

Another key is to automate as much as you can. Setup, migrations, and common tasks.

Spend time knowing your editor. That's usually a tough one because editors are complex beasts, and many people do the opposite. They find the fewest commands that allows them to work.

Apparently, releasing something is a bit of a pain. There's some involved process to create a release. There's a tool called "Hoe" that helps automates releases. It takes him about 5 minutes to do this.

One issue is that some people don't use bug trackers, and send bugs by email or as a comment in a blog entry. I would imagine that's because there's no uniform way to enter bugs. Each tracker does it differently, and people get frustrated.

Eric mentions "Hacking Night", which is something that happens at the Seattle Ruby Brigade. Apparently, this is useful to hash out ideas, or at least help other folks out, while avoiding your own problems.

Another goal is to write "pain-killers", which is code that allows you to do something less painfully.

So this was a reasonably good talk. I think the one thing that would improve it (other than humor) is volume.