Wed, 15 Feb 2012
On documentation
If you're going to write documentation, then make sure it means something. So that if I find some term in your UI that I don't understand, and I decide to look up the term in the documentation, I get something more than just the fact that the term exists and that I can switch the feature, whatever it does, on or off.
Because that doesn't help me squat, thank you very much.
Fri, 04 Nov 2011
Things not to do when validating email addresses
ERROR: WOUTER+TIMHOTEL@GREP.BE is not a valid email address
True, because I entered it in lowercase.
- Email address local parts (the bit before the @) are case sensitive. That means you can't just convert it to all caps and assume it will arrive.
- local parts can be composed out of any character from the following list:
- alphanumeric characters (a-z, A-Z, 0-9), and
- !#$%&'*+-/=?^_`{}|~.
This means that if you're trying to validate an email address by adding a regular expression that does more than check whether there's not exactly one @ in the address, you're almost always wrong.
Next time you try to tell me my mail address is invalid, go read the RFC first.
Morons.
Sat, 08 Oct 2011
Re: 8bitmime
Would people please stop using and/or deplying MTAs that are not 8-bit safe? I mean, it's the 2010s for crying out loud; not speaking 8BITMIME is very much frowned upon (page 16, paragraph 2, second sentence).
Thu, 08 Sep 2011
Why I think MySQL is a toy.
A commentor on my previous post asked why I think MySQL is a toy.
I've actually blogged about that a number of times, but when wanting to point that out, I found that most of those posts point out just one thing, rather than having one post that enumerates them all. So let's remedy that, shall we?
There are many things wrong with MySQL, including, but not limited to:
- In my personal opinion, the whole storage engine thing is a bad idea. It leads to dilution of effort (the MySQL developers need to implement stuff more than once), and makes users choose between disjoint feature sets, which will almost always result in suboptimal results. It also neatly allows PR people to claim that MySQL is 'fast' and 'ACID compliant', without mentioning that you can't combine both.
- One of MySQL's default settings is to truncate string values if they are longer than the field in which they're supposed to fit. This eats data. Hint: it's a database. While truncating strings might be appropriate in extreme corner cases, making it the default is so wrong it's not even funny.
- One of MySQL's default settings is to use MyISAM as a storage engine, which doesn't do transactions. This means you don't have atomicity, which eats data. Hint: it's a database. While telling a user "if the system crashes, I might write your entire data set to disk, or I might write just half of it, or I might corrupt the data set and I'm not going to tell you until you try to read again" might be appropriate in extreme corner cases, making it the default is so wrong it's not even funny. Update: as many people pointed out to me in the comments, apparently one of the first things Oracle did when they took over MySQL is to change the default from MyISAM to InnoDB, making this point no longer valid. I still think the replaceable storage engine thing is a bad idea, but with InnoDB as default, it's not as much of a pain anymore.
- If those two weren't enough 'mysql eats your data' arguments, note that most distributions routinely run a data recovery tool at MySQL startup, because not doing so caused problems in the past.
- I've seen MySQL crash and burn and segfault reproducibly when it encountered a corrupt table. Now I'm not saying that the database should be able to read data as if nothing happened from a corrupt file, but it should not crash and burn and segfault; instead, it should produce an error message.
- Fetching a result set can be done in two ways: either you call mysql_use_result() before calling mysql_fetch_row() which tells MySQL you'll be fetching the result one row at a time, or you call mysql_store_result(), which will read the entire result set into memory. So far so good. The problem, however, is that if you use mysql_use_result(), you're locking the tables from which you're fetching data, and no other client will be able to update any data in those tables until you're finished. On the other hand, if you need to process a large amount of data that can't be processed on the server for some reason, you may need to run a query that returns more data than you have memory. In that case, running mysql_store_result() is plain impossible. This isn't just a theoretical thing; I've seen cases in data warehouse situations where a database client needed to process multi-gigabyte query results. Trying this on MySQL is a pain.
- When compared to PostgreSQL, the MySQL feature set is immature. For
instance, here's a number of useful[1] features which PostgreSQL has but
MySQL, to the best of my knowledge, does not (corrections are welcome):
- table inheritance
- asynchronous notification
- full ACID compliance, in all cases. (MySQL only offers full ACID compliance if you pick a particular storage engine)
- asynchronous command processing.
- Very flexible authentication system, and real actual users. For instance, PostgreSQL supports Kerberos authentication, and understands that users may actually log in from different hosts (gasp!)
- SELinux extensions, called SE-PostgreSQL.
- Server-side languages are implemented using a plugin scheme, allowing stored procedures to be written bascially in any possible language. Someone wrote a PL/LOLCODE which, while not very useful, shows the flexibility; MySQL only supports one language for stored procedures and triggers—if the storage engine supports triggers, which not all do.
- Sequences (an AUTO_INCREMENT column is a reasonable workaround, but still not a sequence)
- window functions
- extensible data type system; of those, MySQL only supports enumerated types.
Against that list, MySQL can only pit "multi-master clustering". While I'm sure that's useful for some use cases, I remain unconvinced that it's a useful enough feature to have to deal with the administrative overhead that MySQL's multi-master clustering imposes upon you, or that it is worth losing all the above over.
So it's my opinion that any database which fails to store data correctly in its default settings can't be anything but a toy; or that a database which has a comparatively small feature set can't be anything but a toy. But maybe that's just me.
[1] No, I haven't used all those features; but I have used asynchronous notification, sequences (other than for primary keys), kerberos auth, custom data types, and (obviously) I have enjoyed the extra peace of mind of knowing that my database is ACID compliant, meaning that it will either accept my transaction as a whole, or reject it as a whole (but usually the former). In addition, I've seen customers use the table inheritance feature.
Sun, 06 Mar 2011
Legalities
This is legal:
So is this:
But somehow this is not:
Somebody please explain to Sony the basic concept of what a 'sale' is. And while you're at it, to politicians, too.
Tue, 15 Feb 2011
"Please send a patch"
On the gripping hand, Matthew, notice that patches written by someone utterly unfamiliar with the code in question aren't always welcome. While some people don't mind spending several days on something that may or may not be accepted to begin with, it's important to realize that talking about wishlist items before even thinking about possibly writing a patch is more likely to result in the desired behaviour than writing and submitting patches in a fire-and-forget manner. In that light, there are cases where 'please send a patch' can be quite demotivating, and it makes sense as a developer to engage in a discussion about a wishlist item, even if you're not immediately interested in implementing said feature yourself. Such a discussion could lead to either you implementing it, or someone else implementing it, or the other person finally understanding that your vision for the software in question doesn't match theirs, and that they should just find something else to spend their time on.
I guess the moral of the story is: as a user with a wishlist item, you should talk to developers, let them know what you think is important, and be prepared to write a patch yourself if needs be and you have the skill. As a developer, you shouldn't interpret every wishlist request as a question to 'please please please implement my pet feature', but as an opportunity to reconsider your views, and possibly implement some nice new feature that you hadn't thought about originally but which you think might be nice, too.
If people reply with 'please provide a patch' to each and every wishlist request, they're stupid; even more so than users who think they have anything to demand.
Mon, 15 Nov 2010
Secure file transfer
Unfortunately, for many people "File Transfer" equals FTP. I dislike this; but if the customer insists that "HTTP" is not a suitable file transfer protocol, then the customer is king. For all its usage and updates, FTP still requires the use of two TCP connections, which makes firewalling hell. Oh well; at least in this particular instance, the firewall is not my job.
At least the customer does have some clue, and insists that no passwords should be sent over the wire in the clear. On that, we agree. Now there are several methods of securing passwords when doing something for which the name involves "ftp".
- The most well-known is "sftp", a part of the OpenSSH package. This has nothing to do with the FTP protocol; it uses a tunneled SSH connection to get at files. This means that usually, in order to get people to files on a server, you must give them shell access too (although there are ways around this). Also, not all file transfer clients support sftp (though some do). The URI scheme used for this is, usually, 'sftp://'
- Another one is FTPS, which involves opening an encrypted control connection to port 990, and then doing FTP as usual—much in the same way that HTTPS uses a different port, too. The URI scheme used for that one is, clearly, 'ftps://'
- Yet another one is using the method described in RFC4217 (October
2005) which involves an AUTH TLS command. Clearly this is superior to
the ftps option (who likes to create more holes than necessary in their
firewall?). Two problems with this RFC:
- I haven't found what the URI scheme is.
- Since there does not appear to be an RFC for the second method above, the existence of an RFC for this method appears to confuse many people, including (but not limited to) some who should know better (SEE ALSO section) that it is about ftps, which it isn't.
The fun bit is that vsftpd supports the latter two; but because everyone confused FTPS with RFC4217, the version that's packaged for rhel 5 supports the latter but not the former, while most clients support the former but not the latter.
FTP, how I loathe thee.
Thu, 04 Nov 2010
MySQL "editions"
Dear Oracle,
MySQL is Open Source. By making it even more of a toy than it already is, you're just asking people to create a fork.
On the other hand, perhaps nobody will actually do so, and this will kill off MySQL for good. Which wouldn't be a shame; so if that turns out to be the case, then thanks.
Love,
Wouter.
Update: the above links to the non-GPL versions of MySQL only. There is still a "community version" of MySQL under the GPL. Seems I missed some things.
Whoops.
Thu, 23 Sep 2010
The best antispam feature, ever.
My comment form on my blog contains the following, right above the <textarea> element where the text can be entered:
<!-- To any spammers out there: Any submission to this form is moderated: this means that only I will see your URLs, and I will not visit them nor link to them. Thus, you can stop wasting our collective time. -->
That, combined with the fact that my blog comment system is a home-grown thing, has meant that I haven't seen a single spammy comment anymore in months.
The same comment form has shown the same thing since ages in a <p> element right above the <form> element, but that apparently was missed by some spammers. Since adding the above comment, however, I've not received a single spam submission to that form in over a year.
Who says spammers are stupid?
Wed, 08 Sep 2010
goudengids.be
... or, 'yellow pages.be'. Or something.
I like it that there is an on-line version of the Belgian yellow pages. Who wants to look up a phone number in a huge book, anyway? And that's ignoring the fact that it isn't any good for the environment.
I also like it that the yellow pages are now no longer distributed by default on paper. You can still get them, if you so wish, but you have to explicitly request them.
Of course, searching an on-line database is also faster than flipping through pages until you find what you're looking for. What's more, you can limit your search to your location rather than whatever shops just happen to be in the version of the book that is distributed to your house. That makes it much more efficient, since rather than all thousands of computer shops in the whole province, you'll find the computer shops in your municipality. Or the ones that are in a radius around your address, if you choose that option.
Rather, that would be the case. But for some unfathomable1 reason, truvo, the company behind the yellow pages, decided to make the option that gets you the names and numbers of companies that serve your region, rather than companies that actually are in your region, as the default. And since there's really n o limit to what companies can enter as the 'region' they serve, you suddenly get a name for a shop hundreds of kilometers away when all you wanted was to find the closest grocery store.
D'oh.
1 Yes, yes, I can guess that money has something to do with it. But whatever, that don't matter.
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|