C (by alaric)

I spent a lot of time programming C in my youth. I went through the canonical route; BASIC on an 8-bit home micro, moving up to Pascal then C when I managed to obtain access to implementations of either. At the time, conventional wisdom was that C was the best language about; the easy access to the underlying model of memory as an array of numbered bytes allowed the programmer to write efficient code to perform low-level data processing operations. The mantra was that there was a tradeoff between expressive power and safety; languages like Pascal made it harder to shoot yourself in the foot, at the cost of preventing you from doing interesting things.

But, with the advent of an Internet connection, I gained access to non-mainstream languages, and my explorations of the wider world of programming language technology began. I still dabbled in C or C++ from time to time, when the situation demanded it, but never on very complicated projects.

Recently, though, I've been working on a large C project. And I've found that I'd quite forgotten just how horrible it is in comparison to the languages I've been using recently...

Read more »

Moff! (by alaric)

We picked Jean up on Saturday, and she's staying with us again now. Since we have the van, we can manage her and her stuff, even though we're still staying with friends in London...

Apparently when she saw the van appear outside Sarah's parents' house, she was all excited and was asking if we were there, since she associates the van with us, then was sad that we weren't. But we turned up a bit later!

However, we were puzzled that, when she disapproved of something (an inedible stone or stalk inside a bit of fruit, for example) she's scowl and shout "Moff! Moff!"...

But then Sarah's parents explained that Jean had been upset by a big moth that had landed on her foot and scared her, and ever since then, anything nasty has been referred to as "Moff" 🙂

Replicated data (by alaric)

The project I'm currently working on is to build a replicated database; and, of course, this gets me thinking about TUNGSTEN, my own replicated database design.

Now, a fully-replicated database like the one I'm writing works by multicasting write operations to every node, so that each node has a copy of the entire database. This means that you can increase your read capacity by just adding more nodes and spreading the work between them. Each node can read its local database independently of the others, so there's no inherent limit to how many reads the cluster as a whole can do in one second. As long as you have unbounded money and space to keep adding more nodes.

However, since writes get multicast to every node, there comes a point at which your write load is the highest the weakest node in the system can keep up with. Adding more nodes doesn't help, since every write still happens on every node. The cluster as a whole has a maximum write capacity, regardless of the number of nodes.

So this system will do for now, but the next big bit of work on it will be to increase the write capacity - by partitioning the data set.

Read more »

MySQL Proxy: Oh, no… Why did they have to go and do that? (by alaric)

The MySQL folks have a new tool, MySQL Proxy, which looks like a MySQL server to clients, but actually just passes incoming queries to a user-supplied Lua script which can pass them on to other MySQL servers, process them itself, rewrite queries before passing them on then rewrite the results, etc.

Which is fine in and of itself. I can think of a few uses for such a thing: it'd be great for query logging during debugging, especially when you're examining the interactions of queries from several sources, so just logging on the client wouldn't help. And it'd be useful for distributed database stuff, too.

However, there's a tutorial prominently linked, Getting Started with MySQL Proxy.

And what examples of the uses of the proxy does it give?

• Pass it along unchanged (default)
• Fix spelling mistakes (ever written CRATE DATAABSE?)
• Filter it out, i.e., remove it altogether
• Rewrite the query according to some policy (enforcing strong passwords, forbidding empty ones)
• Add forgotten statements (autocommit is enabled and the user sent a BEGIN WORK? You can inject a SET AUTOCOMMIT = 0 before that)
• Much more: if you can think of it, it's probably already possible; if it isn't, blog about it: chances are that someone will make it happen

Am I the only person who feels that setting up a proxy in front of an SQL server to catch spelling mistakes and semantic errors and Do What I Mean rather than reporting an error so the developer fixes their code will just lead to endless pain... like every past DWIM system? And is an SQL query proxy really the place to enforce strong passwords, as opposed to in the application code or in the database itself?

I think proxies for just about any protocol can be useful, but condoning such practices as listed above is rather irresponsible...

In London! (by alaric)

We're in London. After the last run of bad luck, a lovely client said "Come and work in my offices, so if any more bad luck happens, I can fix it, so you can keep working and get my project finished on time" 🙂

We'll be here for a couple of weeks.