Xaprb

One of my colleagues, Ryan Lowe, has just heard that his session on PCI compliance with MySQL has been accepted at the upcoming MySQL conference. Ryan is highly qualified to present this topic, and not many people can say that; I certainly can’t claim that title myself. If you’re looking to learn how to make your MySQL installation PCI-compliant, there’s also not a lot of trustworthy information online. Personally — and really, no bias just because he’s my colleague — I think this is a great session for the MySQL conference, which I sometimes thought didn’t have enough diversity of topics in past years. We need more stuff like this to give people a reason to return after they’ve gone for 2 or 3 years in a row.

I’m speaking at the O’Reilly MySQL Conference 2010. I hope I don’t lose my voice, because I have four sessions!

• Diagnosing and Fixing MySQL Performance Problems
• EXPLAIN Demystified
• Read-Write Splitting: Techniques, Challenges, and Solutions
• MySQL Graphing and Trending with Cacti

You can click through on the links above to learn more about each session. I’m also looking forward to the other sessions. Here’s a sample of a few that I have my eye on:

• Linux performance tuning and stabilization tips by Yoshinori Matsunobu
• MySQL Proxy meets: Memcache by Jan Kneschke
• PHP Object-Relational Mapping Libraries In Action by Fernando Ipar

The schedule is far from complete, because the conference committee is still working on it, but the proposals to choose from are impressive. Stay tuned as more talks are approved and the schedule fills out, and don’t wait too long to register and book your flight! This is going to be a banner year.

I’m on the MySQL conference committee again this year, so I’ll be reading and voting on your session proposals. My past experience is that reading 400 session proposals is a mind-numbing job, and I will be optimizing it to save my time. That means I will be scanning your proposals and deciding very quickly how to vote. I wrote before about how to submit a great proposal, but I’ve refined my opinion since then. Here are my suggestions:

• Write for two audiences: reviewers and attendees. Both of us want the same thing: to decide as quickly as possible whether your session will be good.
• Write a strong title/headline. Don’t know how? Here’s a good start. The title or headline is your best chance at getting accepted. But don’t be too clever.
• Make it short. Please! Your description should be a few sentences, and your abstract should be a couple of paragraphs. If you think you need more than that, you need to learn how to write succinctly. Tutorials can be longer.
• Avoid being cute. No puns on programming languages, for example. No matter how funny you think it is, just get to the point. People can appreciate your wit in person.
• Get it right the first time. You can go back and edit it later, but I will not be re-reading and re-voting. If necessary, get a trusted friend to edit your proposal before you submit it.

• Don’t lead off with generic or banal truisms, or set up a “describe the problem, build the suspense, dramatically introduce the solution” dynamic. It doesn’t work. With due respect, this example from last year’s conference is a study in what not to do:

  With the increase complexity of software architecture and database design the amount of data stored in databases systems grows rapidly. Additionally, data security and international regulatory laws require that data changes are audited and restorable to any point of time. The revision engine implements automated auditing of data transparently as a storage engine.

  That proposal wastes the first two sentences stating obvious things, instead of talking about the session itself. It is asking too much of the reader to plow through all of that. The proposal should get to the point: “The Revision Engine automatically saves all old versions of your data…”

• A cool topic cannot save you. You have to demonstrate a clear thought process with a well-written proposal. If your proposal is badly written, I have no choice but to believe that you can’t create and deliver a good talk.

My suggestions from the 2008 year still stand, too:

• I will not give you a favorable vote because you or your employer are famous. Your session proposal has to carry its own weight.
• You need to write a detailed enough proposal to convince me that you’ve put some effort into it. I won’t vote for “accept this talk, and then I’ll fill in the details.” Do the work and take the risk that you won’t get accepted — protecting yourself against rejection is a good way to get a low vote from me.