Tell the world about your first time impression - Usability Reports

MySQL, like most software companies, has a complex organization to deal with the creation and improvement of its products.
There is a well oiled machinery that evaluates the needs and decides where to invest resources to create new products or to expand or change existing ones.
Ultimately, what affects the decision is the users satisfaction.
However, funnily as it may sound, the best organized activity in our company is bugs processing i.e. the one dealing with users dissatisfaction.
I would like to see more positive input from the users, and thus I put together the guidelines for a Usability Report.
What is is?
In short, it is the account of a user first impression with a product or a feature. If you decide today to start testing, say, the Falcon engine, you could write a usability report to convey your experience to MySQL.
The usability report should be divided into sections, to make it easier for you to write and easy to read for the ones evaluating community feedback and taking decisions.

• product identification
  
• Expectations
• Clarity of documentation
• Ease of use
• Real world usage
• Bugs
• Missing pieces
• Level of satisfaction
• (optional) Test units

You can see an example in the Forge. It's a report that I wrote in August 2006, a month or so before joining MySQL. You can use my first experience with logs on demand as an example of how to write a report.
Want to have your voice heard? Visit MySQL Forge, and submit your first Usability Report.

Getting started with MySQL Proxy

Did you notice that there is a new component among MySQL products? No? Perhaps you have been on vacation, then.
MySQL Proxy is an exciting tool for anyone willing to get new features now without waiting for new server major releases.
Using the Proxy you can filter queries, create new commands, create customized logs, play with the operating system from any database client, and much more.
Interested? Read Getting started with MySQL Proxy

Finding Falcon hidden bugs - with a little help from my shell

There is a song that keeps popping on my mind when I test something difficult. Usually, when I can't get the result I am seeking with normal operations, and I have to resort to some trick, I hear Joe Cocker singing With a little help from my friends. My best friends when I test are bash, vim, and perl.
Today, I was testing Falcon on my Intel based MacBook. The last Falcon release does not compile on Macs, but it has been recently patched, and today with my delight it built smoothly.
Having got the binaries, I ran the test suite, because that's the fastest way of finding out if something is broken. Soon enough, something nasty popped up. Test "falcon_bug_29040" failed with timeout. Thus, I switched to full bug finding mode, and ran the test again.
Odd. When run alone, it succeeds.
I restart the test suite. Again, it fails, but it is executed after some 40 different tests. Apparently, there is a conflict. Either a previous test is not cleaning up after itself, or there is yet another bug to be filed.
Then the task is: how do I know which of the previous tests make it fail?
The solution is to run the tests before "falcon_bug_28040" one at the time, with the suspect one immediately after. When I get a failure, I know who the culprit is.
With a little help from my shell, the task is easy:

for T in t/falcon_bug_2[234567]*.test ; \
  do \ 
    TEST=`basename $T .test` ; \
    echo $T $TEST ; 
    ./mtr --skip-ndb --skip-im $TEST falcon_bug_28040 ; \
done

The tests before the one under examination are all falcon_bug_XXXXX, where XXXX ranges from 22089 to 27997. So I ask the shell to single out the tests in that range. For each one, I get the base name (without extension), and I pass it to the test runner. Total time to find the culprit: three minutes.
It took me much more to submit the bug report and to write this account of the facts!

Speaking at FrOSCon - Monitoring and logging techniques

If you happen to be in Northern Germany at the end of August, I recommend a visit to Sankt Augustin, a charming city near Bonn.
Apart from the friendly atmosphere and excellent beverages, Sankt Augustin hosts the second edition of FrOSCon, the Free and Open Source Software Conference, organized by a group of very dynamic and efficient enthusiasts.



I will present a topic for database administrators, Monitoring and logging a database server.

And of course I will meet a bunch of friends there. Someone I know very well, like Lenz Grimmer, who will speak about Opening the doors of the Cathedral, and Zak Greant, whose session about the age of literate machines sadly I won't attend because it coincides with mine.
And then there are those who I know only by email, and I will gladly meet in person, like Susanne Ebrecht, who will bravely cover the PostgreSQL vs. MySQL, or Venus vs. Mars debate.
The list is long, and the conference lasts only two days, so I will try to make the best of it.
See you there!

Bug processing disclosure - The busy bees of MySQL AB

Ever wondered what happens after you submit a bug report to MySQL?
Puzzled at the cryptic messages that tell you about your report going from verified to in process?
Who on earth are those Valeriy, Sinisa, Victoria, Miguel, Sveta, Tonci who comment on your report?
Wonder no more.

MySQL bug processing explained disclose in tiny detail who are the busy bees in MySQL hive and how do they get from the pollen of your bug report to the honey of a bug fix.

Building MySQL Proxy on Mac OS X

Version 0.5.0 of MySQL Proxy was released a week ago, and in the meantime there have been 25 revisions.
If you want to try the latest version in your box, you can get the sources from the svn repository and build it yourself.

svn co http://svn.mysql.com/svnpublic/mysql-proxy/ mysql-proxy

Then, you can build and install this way.

./autogen.sh && ./configure && make && make install

That works beautifully on my Linux desktop.

So far, the good news. The bad ones is that on my Mac OS X laptop, things are not so smooth.
First, aclocal complained about missing macros. Jan was online, and he helped me fix the problem with an environment variable.
Then ./configure could not find the right Lua settings. More options.
Again, ./configure could not find libevent.
In the end, I managed to build the coveted proxy with the following instructions, which I saved in a shell script, because I am going to need it quite often.
Here it is, in case someone gets stuck on the same problem.

export ACLOCAL_FLAGS="-I /sw/share/aclocal/"
./autogen.sh && ./configure LUA_CFLAGS="" \
   LUA_LDFLAGS= LUA_LIBS="-llua" \
   CPPFLAGS="-I/opt/local/include/" \
   LDFLAGS="-L/opt/local/lib/"  && make && make install

Update 2007-07-02: Version 0.5.1 was released today. Now that's a fast development cycle!