Noel Rappin Writes Here

RailsConf

Conference Prompts: Or How to Submit Proposals and Influence People

RailsConf, Speaking and WritingNoel Rappin1 Comment

I'm going to be conducting a few of the tracks for this year's RailsConf, specifically the Novice, Testing, and Crafting Code tracks. I'm very excited, this isn't an opportunity I've had before.

What I want from all of you is awesome proposals. I want to have to make hard decisions. I want to be inundated with all your amazingness.

Because I want to hear from all of you, here are some opinions on how to best present yourself in a speaking proposal.

Yes, You Can. In Fact, Please Do

In response to my initial round of begging for proposals on Twitter, somebody commented that they didn't think they were the most qualified person to talk on a particular subject.

To which I have three cheesy but true responses:

  • A conference that was limited to only people that really though they were the most qualified person to talk would be depressing, if not completely horrific.
  • You are absolutely the most qualified person to tell me what you think on a particular topic.
  • This is how you become qualified. You study something, you teach it to other people.

In other words, please don't let that stop you. If you don't submit a proposal, you have zero chance of being accepted.

(In a similar vein, here's a talk I once gave about how everybody has technical writing in them. Video's poor, but audio is okay.)

I can't speak for any of the other conductors, but I'm also looking for people who want to give shorter talks (10-15 minutes) with the idea that we might have a session that is 2 or 3 awesome shorter talks. If that interests you, definitely mention it when you submit.

What Should I Talk About?

Let's say, for the sake of argument, that I've convinced you that you should submit a proposal to RailsConf or the conference of your choice.

But you don't know what to talk about.

Here are some ideas. This is the kind of process I go through when I try to get ideas for a talk, though by writing it down I'm making it more systematic.

Think of these as prompts and use them as starting points to find an idea for a talk that excites you.

These are far from the only seeds for good presentations, but it's a start.

  • What is the last thing you spent more than 15 minute trying to figure out?
  • What is the last tool, process, or code you wrote that made you excited enough to tell somebody else?
  • What was the last question you asked a more senior developer?
  • What was the last question a more junior developer asked you?
  • What do you wish somebody had told you a year ago?
  • What was the last blog post or presentation in the community that you disagreed with?
  • Do you have a hobby or interest that informs your work?
  • What is the best line of code you wrote this week? How could you tell?
  • What was something you did for the first time in your last project? How did it work out?
  • What was something you did for the last time in your last project (or something you stopped doing for your last project)? How did that work out?
  • What is a tool or process you would like to learn more about?

Once you have an idea, try to answer these questions about it.

  • Who is the audience for this? It often helps to think of one specific person that you'd like to talk to.
  • Is there a story here? What is the beginning, the middle, and the end?
  • If a person watches this talk, what will they be able to do after the talk that they would not have been able to do before?

UPDATE 1/19 It seems worth pointing out that I'll be speakng at MountainWest RubyConf this year. The talk is on Smalltalk, and it's a direct result of a presentation I saw and wanted to respond to (I didn't actually disagree with the presentation, but I had another take on the topic). Also, I know for a dead certain fact that one of the other speakers is a much bigger Smalltalk expert than I am. And I am going to take may own advice and not let that bother me.

What Makes A Great Submission

I have opinions on the actual submission -- watch for updates after I dive into the actual submissions.

I'm going to share with you the first rule of submitting anything. This rule is applicable to any situation where a person has to spend a lot of time evaluating submissions -- resumes, conference proposals, writing submissions all included.

Rule One: The person reading these submissions is always looking for a way to save time. Don't give them a reason to reject you out of hand.

That means: if they have a format, hit the format. If they have a word count, hit the word count. Spell words correctly. Write in grammatical English. Sure, the reader might take extra time to figure you out if you bend the submission rules. But why take the chance?

Have somebody else read and edit you if you can. Find a buddy and read over each others. (I'm willing to be your editing buddy -- contact me via this web site).

In most cases, the talk descriptions on conference web sites are taken directly from the submission -- look through some, and see what makes them compelling.

Specifically for conference proposals:

  • Make sure you specify: a) who the audience is, b) what they should expect, c) what they will learn.
  • For a long time I was afraid to give out details of my talk in the abstract for fear of "giving stuff away". That was a bad idea. You need to give people an idea of what to expect. (The RailsConf CFP has a details field that lets you put in details for the organizers and not the abstract -- use that)
  • You don't have to explain why you are an expert, but if you have a particular reason why you might have insight into the subject, mention it. This reason is not at all limited to you having vast experience on the topic.

Good luck, and I look forward to hearing from you.

June 10, 2010: RailsConf-a-palooza

Capybara, Rails 3, RailsConf, SafariNoel Rappin2 Comments
Sorry for the involuntary day off yesterday. Lot of links, I'll try and be brief.

RailsConf and Related



DHH's Tuesday keynote is up. Presumably this is different from last year's keynote about Rails 3. The other keynotes will probably become available in the next few days.

David announced Rails 3 beta 4 at his keynote. It looks like we'll be getting a release candidate in another couple of days.

The Ruby Hero awards were given. Weirdly, I can only see the list via people who tweeted about it -- there doesn't seem to be an official list up yet. Winners are José Valim, Nick Quaranto, Xavier Noria, Aaron Patterson, Wayne Seguin, and Gregory Brown. Congrats to all.

Most speaker slides will be available at the RailsConf site.

Gregg Pollack has a screen cast series called Dive Into Rails 3. Which, if past performance is any indicator, will be very useful.

Online recaps include: JetBrains and Jake Scruggs.

Says here that DHH "was dismissive of an analyst report that did not reflect kindly on Rails". Ooh -- how'd I miss this. It's a survey from April that places Rails 11th out of 12 web frameworks in developer satisfaction. (Beating out Spring, with .NET on top). That seems... unlikely based on my experience. But hey, what do I know, I can't charge $600 for my reports.

And A Bunch of Other Stuff



Bowline is a new library for cross-platform desktop apps using Ruby.

Apple's official Safari Extension page isn't up yet, in the meantime, there's http://safariextensions.tumblr.com/.

Send Keys is a Capybara extension that lets you send keystrokes to the web page under test.

June 8, 2010: iPhone, iPhone, it's off to work iPhone

Neil deGrasse Tyson, Rails, RailsConf, Ruby, iPhoneNoel RappinComment

Okay, There's a New iPhone



Don't really have a whole lot to say beyond what's already been said. It looks very slick, and if anybody can actually pull off getting people to use video chat, it's Apple. The form factor of video chat from a phone seems at first glance to be significantly better than from either a laptop or the iPad, in that it seems easier to hold the phone in a position to get a good angle. And as much as everybody is kicking around Google vs. Apple, it sure seems like the company that lost big was Flip. (Oh, and I'm not the first person to say it, but there's now flash on the iPhone... well, an LCD flash for the camera, at least.)

And a new Safari



Safari 5 was released with a lot less fanfare. Big new features include an extensions system similar to Chrome, which will fully launch later this summer. There's also a nice Reader function which is similar to the Readability bookmark. So far, I find it very pretty, a touch flakey about what sites it decides to pop up on, and downright magical at automatically following next links to stitch together a multi-page article. It also adds support for a bunch of HTML 5 features and a new JavaScript engine.

Links



All the RailsConf keynotes are being live streamed at http://en.oreilly.com/rails2010/public/content/livestream.

Feature Flipper is a simple little gem to allow you to semantically tie certain features to certain environments, making it easy to have a specific feature live only in development until it's ready.

Oddly, this came up in conversation just yesterday. Chris Lowis points to a number of full Rails apps that are open source and can be used to learn how Rails apps are put together.

Quick snippet -- an Array#only method for when you know an array only has one element. I think I would actually use this.

Finally



Neil deGrasse Tyson, speaking off the cuff on a rant subject near and dear to my heart, namely how it's socially acceptable for otherwise lovely people to say "I'm no good at math".

May 13, 2010: The Rules of Agile Estimation

Agile, Apple, Estimates, JRuby, Kent Beck, Newton, Potterverse, RailsConf, iPadNoel Rappin1 Comment

Top Story


JRuby 1.5 is out. Highlights include improved Rails 3 support, better support for Windows, better FFI support, better startup time (yay!) and a lot of other tweaks and fixes.

Book Update


Still Cucumbering, hope to finish today.

The book is still on sale, of course. And I'd still love to see more comments in the forum.

I'll be talking at Chicago Ruby on June 1, exact topic TBD (let me know if you have a preference), but I'm leaning toward talking about how to avoid test problems and write good, robust tests.

And Then...


As an unrepentant old Newton fan, I loved this compare and contrast of a recent iPad ad with an old Newton ad. The Newton, flaws and all, was way ahead of the market back them.

If you are going to RailsConf, first of all have fun and wish I could be there. Second, if you are wondering about the difference between the two Rails 3 tutorials, wonder no more.

Kent Beck is publishing some old pieces again, including one about how the original XP book made the mistake of equating "the team" with "the developers".

Fred and George Weasley are marketing experts.

And Finally


The Rules of Agile Estimation:

1. Estimates are always wrong

2. If you think spending more time on estimates is a good idea, see rule 1.

3. On average, an experienced developer is not going to improve on his or her gut reaction by thinking it over.

4. Team estimates are important, one person may see something that everybody else missed. Just keep it quick.

5. People are much better at estimating size relative to each other than absolute time a task takes.

6. Separate the problem into smaller chunks, the more estimates you make the better the chance that the law of averages will help you.

7. Decomposition into roughly equal sized tasks is pretty much the whole ballgame.