Sometimes you may need to create a set of rspec specifications with pretty similar structure and small differences. I’ve got such situation in my project and decided to try to use Ruby’s dynamic code generation features to make my spec file shorter.

I have some multiplexing helper in my templates which allows me to use the same template for different similar pages. This helper returns URL from the set of params and a type. It could accept 5 different url types and raises an Exception when requested URL type is invalid. Without this dynamic code generation feature I would need to create 5 different specifications (one for each URL type) to be able to see each URL type test as a separate line in test results log. But with this simple technique my code looks like following now:

describe VideoHelper, 'when profile_video_url method called' do

  before do

    @user = mock('user')
…

I released version 0.9.8 of my MySQL UDF code generator yesterday and i finally moved development over to my own php-baustelle.de family of sites.

Continue reading "New MySQL UDF generator release, project moved"

Today I upgraded the blog software at sheeri.com (and sheeri.net and sheeri.org). Please let me know if you find something that doesn’t work as expected — awfief@gmail.com.

At the MySQL Users Conference, my good friend Mark Atwood (creator of the free Amazon S3 Storage Engine) mentioned that any site with a login should have OpenID as an option.

Mark, I upgraded for you! I was using Wordpress 1.5.2, now I’m at the “latest” version. Anyway, this is just to let folks know that if you so choose, you may now use OpenId if you wish to login and make comments.

Of course, I do not require login (and have a great spam filter) so that’s just another choice you have.

This is a hack I've heard about a couple times now:

Paul wrote a script that reads from the logfile the queries that are going to be executed moments later. He parses the queries and constructs new select queries that populate the cache with the data that speeds up the upcoming writes. He claims, if I remember correctly, a three to four times speed-increase.

Here's the problem in a nutshell. The master can write transactions in parallel but slaves can only write them in series. [1]

This means you have a lot of optimizations on the master (TCQ and NCQ being examples) that aren't possible on the slave.

What this patch would do is precache the data so it's already available in memory. Since you're pre-reading the binary log you can run SELECTs in parallel on the SLAVEs so that the cache is hot when …

Having just moved apartments, it’s obviously time to get on a plane again.

On Monday I fly off to Stockholm again to attend the MySQL Cluster team meeting. Somehow we’re going to squeeze everybody into the Stockholm office (I’ll post humorous cramped photos, I promise).

Of course the thing to do now is to prepare for the meeting… packing can be done on sunday night or something.

Of course, if you’re in the area, come for food/beer!

...is something that you influence what it will be.

The problem with replication is that we have so many things that we want to do, but we are not that many people. What we do is what everybody does when the to-do list is to long: prioritize. Since the replication features are developed for you (yes, you), we have added a quickpoll on the http://dev.mysql.com/ where you can pick the three most important replication features that you would like to see us focus on next (after the 5.1 GA).

Do you think that on-line checks for table consistency is for weenies that cannot write a simple little script to do that? Please tell us that.

Do you prefer to live on the edge and think that semi-synchronous replication is for safety junkies? Well, we'll be glad to hear your opinion.

Do you think that the YouTube …

We’re on the verge of releasing our code and we’ve spent a lot of time looking at other projects to see what works what doesn’t as far gaining widespread adoption and building a vibrant developer community. There were some obvious differences in the way some projects are managed: Some have paid contributors others do not. Some use OSI approved licenses, others do not. Some had rigid roadmaps set by a small group (or even a single individual) others were more consensus oriented with their planning. Outside of the obvious, it was all terribly confusing and difficult to glean any useful insight from our ad hoc analysis.

Last month when we were at the mySQL conference I was talking to Tony Wasserman of CMU West and he mentioned to me his work in this area. He sent me a draft of his paper titled: A Framework for Evaluating Managerial Styles in Open Source Projects (I don’t have a link yet). In it he analyzed 75 commercial and community …

I had dinner with Zack Urlocker (EVP of Products at MySQL) and Luis Sala (one of my very best hires, ever) last night in San Diego. We talked about a wide range of things, but spent a fair amount of time talking about the people at MySQL, and especially the management team. Zack has recently been sporting long hair (pictured at right) and was pretty open about the nature of the people with whom he works. He didn't say this, but the description I inferred from the conversation was "confident but humble." Those of you who know Zack, or Marten,... READ MORE

This is a hack I’ve heard about a couple times now:

Paul wrote a script that reads from the logfile the queries that are going to be executed moments later. He parses the queries and constructs new select queries that populate the cache with the data that speeds up the upcoming writes. He claims, if I remember correctly, a three to four times speed-increase.

Here’s the problem in a nutshell. The master can write transactions in parallel but slaves can only write them in series. [1]

This means you have a lot of optimizations on the master (TCQ and NCQ being examples) that aren’t possible on the slave.

What this patch would do is precache the data so it’s already available in memory. Since you’re pre-reading the binary log you can run SELECTs in parallel on the SLAVEs so that the cache is …

I’ve written before about how to make MySQL replication reliable. One thing I think you need to do to make statement-based replication reliable is eliminate temporary tables. I found an elegant way to replace temporary tables with real tables in the systems I maintain. This article explains how. The problem Temporary tables are anathema to reliable MySQL replica servers. If you have a temporary table and the replica crashes in between accesses to the temporary table, when you restart replication the temporary table no longer exists, and you are in trouble.