Speaking at the Open Source Database Conference 2006

I will be a speaker at the Open Source Database Conference, which is held in Frankfurt from 6^th to 8^th November 2006, parallel to the International PHP conference.
I will present two sessions, one on Advanced Replication Techniques in MySQL 5 and the other on The MySQL General Purpose Stored Routines Library.
I submitted both proposals long before I started considering joining MySQL, so I will go there with the blessing of my current employer, but I will speak under my former affiliation, to avoid attributing to my current company what are my personal ideas.

Contributing to MySQL QA - Ideas wanted

MySQL has recently started a campaign of open contribution, inviting the community to participate to the MySQL project in many ways.

The next target, also considering the higer stakes coming from the MySQL Enterprise challenge, will be Quality Assurance.

Quality Assurance

Now what is Quality Assurance (QA)? If you think that it's just bug hunting, then you have a simplistic view of the software generation lifecycle. QA deals with all the steps in the software lifecycle, and at each steps there are actions that can affect the quality of the final outcome. QA components include (but are not limited to) failure testing, statistical control, process and performance control, best practice adoption.

MySQL AB has its own QA department. Those of you who attended the MySQL Users Conference may have had a chance to attend a presentation by senior QA manager Omer BarNir about Internal QA in Open Source Development, where he explains the challenge of being a QA professional in such a dynamic company (presentation slides ).

Software testing

Since MySQL is a software company, finding bugs is important, of course, and software testing is one of the main branches of QA, but the crucial part of finding bugs is not how many you can find, but when you find them. The earlier you find a bug, the less costly will be to fix it.

Looking for bugs as soon as a feature pops up in the development lifecycle is just part of the task. The way you look for bugs is different from person to person, depending on who you are:

• a developer with an intimate knowledge of the code may find low level bugs that nobody else can catch, with tools like code peer reviews and walkthroughs;
  
• a professional tester, even without development experience, may find functional bugs by testing the application with a methodical approach;
  
• the final user, who does not have to know any of the above, may find bugs by simply using the application and comparing the results with earlier expectations.

Of all these three methods of finding bugs, the first one is the most effective. Bugs found at that stage are the least expensive to fix. But of course one can't find all the bugs with code inspections. And then there are the other two levels, which catch bugs that will cost more effort to fix.

Obviously, the bugs that affect the final users are the ones for which you care most, and it would be of mutual benefit to find these bugs as early as possible.

Community involvement

From the above explanation, you can see what the problem is. No matter how skilled are the professionals at this job, finding all the bugs is impossible. You can take any book on this subject, and every one of them will tell you the same postulate: You will not find all bugs. One thought is especially discouraging for us. Although the QA professionals find a lot of bugs, those which you neve hear of, because they are fixed before you hit the download button to get the application, there are still the ones that affect you, the final user, the most important party involved.

Therefore, here is the idea. We want to involve the community of users in our Quality Assurance activities.

How can we do that? To tell you the truth, we have plenty of ideas on what we can do and how to promote it. After all, until one month ago I was still just one of the many community members, and I have some ideas.And there are many brilliant people in house who came up with promising ideas.

But at this stage I don't want to tell you what I think it should be done, but rather listening to what users propose.

The questions to answer are:

• how can MySQL involve the users in earlier bug finding?
  
• how can MySQL involve the users in its testing process?
  
• what else can community members do for QA? (hints: bugs verification, performance testing, standard compliance testing)
  
• What kind of incentive would make you (more) willing to cooperate? (hints: public recognition, free services, discount on services, contests with prizes)

If you have an idea related to this topic, even if it is not an answer to the above questions, write a comment to this post, or drop me a line (giuseppe {mind the spelling} at mysql dot com).

Thanks in advance!

Also published at O'Reilly Databases

Take the MySQL Certification in five steps

I recently took two certification MySQL 5 exams. At that time, I was on vacation, but now that I am back I would like to share with the community some advice on how to pass the exams.
Son't worry, it is not about cheating. But read on, and you'll decide if it was worth listening.

1. read the book

So much for the ones who thought I was teaching some tricks. Nothing like that. Let me tell you why you should read the book.

• You could read the (free) online manual instead. No questions about that. If you read the whole manual, you will know all is needed to pass the exam. But you will have to read twice as much as the book (about 1300 pages of user manual instead of 672 pages of certification book).


• The book will tell you what is important for the exam and what isn't. True, even if the certification exam does not mention it, it could be important (and usually is), but you really want to pass, don't you? So, the book is better.


• The book is organized by exams. There are four of them, and the book covers their subjects nicely in a very organized way. In the manual, you either read it all, or you will never be sure that you covered everything.

Notice that, although I am now a MySQL employee, I don't get any share from the book sales. What I am saying here is what I honestly believe. I bought the book long before an employment with MySQL was even faintly suggested. Actually, I should add that everything in this article is my personal opinion, and it is not the official take of MySQL AB.
Summing up this item: Read the book, because it will save you time.

2. Get some hands-on experience

Reading the book (or the manual, or both) is not enough. Even if you commit the whole beast to memory, it won't be enough to pass the exam. To pass it you need to apply your knowledge to some real world problems. I can't tell you the questions you are going to get in the exam, but I can tell you the gist of it.
During the exam you won't get questions like "what does the book say about this matter?"
Instead, you will get questions like "given this problem with this set of conditions, which of the following actions is most likely to solve it?"
If, in addition to reading the book, you have some practical experience, you will be able to apply what you learned and answer the questions. If you have a prodigious memory and remember every word of the user's manual but have never tried some of that stuff in the wild, chances are that you won't pass the exam.

3. answer the sample questions from the book

After you get some experience, then try to answer the sample questions from the book. Be aware that the book ask questions in a way that is different from what you get in the exam. The book my ask you to "list all the methods to solve a given problem," while at the exam you get questions like "which of the following methods will solve the given problem?" and you get a multilple-choices-list. So the questions from the book are actually more difficult than those in the exam itself. That's fair. If you answer all the questions from the book, the ones in the exam will look a lot easier.

4. Participate to a forum and answer questions

When it comes to practice questions, you can't get enough of them. After you answer all the questions from the book, you still feel that some more exercise could do you good. There's an easy way of practicing. Subscribe to a mailing list, a newsgroup, a forum dedicated to MySQL, and read through the questions that people ask every day. Even better answer some question yourself! Start with the easy questions, and then try tackling the though ones. You may not know all the answers, but you can find out, because you have read the book and you know where to look in the manual. If you don't, it's a good moment for starting. The real trick is this: whenever you answer a question about something that you know only in theory, spend a few minutes to do it in practice. This way, you will be sure that your answer is correct (and you'll avoid some embarrassment) and you will add some more experience to your bag of tricks. This whole process will boost your confidence a lot. After a few weeks of answering at least one question per day, you will be a celebrity in that forum of your choice, you will have made somebody happy, and many people will have thanked you. What better way of studying?

5. Play chess

Now, wait a minute! What has this to do with the exam? Don't worry. I am not out of my mind, and I will explain shortly what I mean.
During the exam, you will have to answer 70 questions in 90 minutes (the upgrade exams has a different timing, but if you go for it you will have already taken an exam, and you know already what I am talking about). This is a great source of stress. Having a clock that clicks your time away can have a negative influence on your answers. Talking to some other candidates who took the exam, the greatest concern was that time restriction. But you know what? It was not a problem at all for me. And the reason is that I am a chess player, and therefore I am used to taking decision with a clock ticking at my side, and telling me that my time is near exhaustion. In competition chess games, you are given a double clock with two buttons. When it's your time to move, your button is up and your time is running. When you have decided your move, you make it, and push the button. Then your clock stops and your opponent's start ticking.
If you are used to this stressful way of taking decisions in rapid (30 minutes for the whole game) or blitz games (five minutes!), a simple clock giving you 90 minutes for 70 "moves" looks like a joke.
So, if you play chess, resume your chess club card, or play some Internet game, and get some practice at time management. If you don't play chess, answer the above mentioned questions with a clock that rings after a given time.

Then, get a good night's sleep and take the exam

As a last piece of advice, remember that a certification exam is a stressful experience, no matter how well you have prepared. So you need all your strenght and energy for it. Go to the exam well rested and fresh. If you have to take more than one exams, don't do them in a row. Put at least a few hours before the next one, and in between take a walk, read a book, or do anything to recharge your spirits.

Good luck!

Are logins before download any good?

If you are used to open source products, chances are you have gone through this routine more than once. Search for what you need, find a suitable product, go to its web site, download it, test it. Then, if you like it, you start using it right away, otherwise you dump it without a second thought.
The whole process takes less than one minute for small packages. But anyway, even for larger packages, the total time that this whole business requires your attention is very low. Even if it requires a huge download, it can be left unattended and you can resume the testing task when you feel like it. The bottom line is that we got used to a quick try-and-use process of open source products.

Sometimes, though, while performing the above routine, there is a unexpected obstacle. The product maker requires a free login. You don't have to pay anything, but you have to go through the motions of filling a form that asks you everything about your precious self, your company, education, employment history, financial health, and so forth.
Filling these forms is really annoying for several reasons:

• You got used to the quick download-and-try business, and this sudden stop is not welcome
  
• You can't see any added value in this form filling. Actually, you are sure that your level of spam (both by email and by regular mail) will increase;
  
• You think at the waste of time this form is, especially considering that you may be throwing the whole product away after ten minutes.
  
• This is contrary to the whole open source spirit, where you achieve success by providing a good product. The register-bedore-downloading strategy, instead, tries to cheat into a let's-grab-a-potential-customer-as-soon-as-he-shows-up utterly losing attitude.
  

After this problem has bitten you once or twice, you start developing a strong defense strategy. The next time some site asks you for a registration before downloading, you start filling the form with fake information, using a temporary but legitimate email address, claiming to run a multi-million dollar business, and presto! you get away with the download, never to be seen to that site again, unless that product is really a earth-shakening tool (which seldom is, in those cases).

And so here are two reasons not to impose a registration before downloading an open source product:

• It's useless. If you want to cheat the unfair system, they can't do nothing to prevent it.
  
• It's damaging. If they want to propose an open source product, imposing a registration is like screaming: "Hey! We want to play the open source game, but we are totally and hopelessly unaware of how to play the game. Cheat us!"
  

Which I usually do.

Also published at ITToolbox