Unlike Steve Jobs, unless you’re in the tech industry, there’s a pretty fair chance you’ve never heard of Dennis Ritchie.

Normally, I’m not one to be too taken with the death of a “celebrity” …

… but this one hurts.

We truly lost a titan of our generation. A man who became synonymous with the company he founded, and whose products made life more awesome for millions of people. As I look around my house, pretty much every room has some touch of Apple, and all of that thanks to Steve.

Rest in Peace, Steve Jobs. The world was enriched by your presence and is saddened with your loss. Thank you for everything you did.

I’m aware that the Mac oil price widget has quit functioning, and I’m aware of the cause as well. I’m working towards a more robust solution and should have something in the next week or so.

So with the landing of Atlantis, the end of the Space Shuttle program has finally come. And while it is bittersweet - I remember being able to watch the shuttle go up from my backyard (literally!) when we lived in Florida - you have to excuse me for slaughtering the sacred Huntsville cow.

The retirement of the Space Shuttle is long overdue.

Because there doesn’t seem to be a good, simple way to track oil prices on the Mac dashboard anymore since the previous widget I used quit working, I whipped up a quick little widget that allows me to monitor the price of Crude Oil on the New York Mercantile Exchange.

You can download it over on its own page.

PHP’s filter functions are really, really great. I’ve started using them almost any time I need to get input from a user and, personally, I don’t think you should use the old $_GET, $_POST unless you know what you are doing and there is some specific thing you’re trying to accomplish that you can’t with filter. Filter forces you to think carefully about what inputs your script takes and what format it takes them in.

But there are also some behaviors of filter that can bite you in the rear if you aren’t really careful. One of these is knowing which flags you need to pass and what the difference between validation and sanitizing, when is the right time to  use each, and what flags to use. I ran into a good example of this today where I messed it up.

I had configured filter_input_array to pull in a variable as FILTER_VALIDATE_FLOAT, probably because I wasn’t thinking like a user and instead was thinking like a developer. I’m the type of person that, when a form wants to know my phone number, I only enter 10 digits without parentheses or dashes. But users are different. They like friendly things. In this case, the user was entering “16,473.54” and the like into that box.

Now, I can look at that and say, “yeah, that’s a float” (actually, it’s currency). It should be considered a valid value. But FILTER_VALIDATE_FLOAT will throw this out because it has a comma in it, unless you pass FILTER_FLAG_ALLOW_THOUSAND. Then, and only then, does it return the above as a valid value (in this case “16473.54”).

But I looked at the code again. In this case, the value doesn’t need to be there except in a specific case, which I handled in error checking in the code, so I switched it to a Sanitize value instead. It’s probably a good idea to only use  FILTER_VALIDATE_* functions when your user has to give you a valid value and your script would fail if that wasn’t the case. If a validation returns false, you should fail the process and return a (nice) error message to the user. Sanitize functions allow you to accept a little wider range of data and still return a valid value from it. The docs have a great example of this involving email addresses.

So if you’re writing PHP these days, definitely use filter. Just be careful and mind the flags and the difference between validation and sanitizing.

I’ve finally put together a website for dystill:

www.dystill.org

I’ll continue to post updates about this project here, though.

I’ve also finished working on a plugin for Roundcube (the popular open-source webmail client). It can be found for download at the address above.

Version (do those really matter anymore? :P) 0.2 of dystill has been released.

This version brings a significant change to dystill. Namely, it breaks the unofficial association between dystill and Postfix that has existed since I first wrote it last year. I did this for a couple of reasons:

• To hopefully increase adoption. Dystill now (really!) stands independent of any MTA. Use it with whatever you want (sendmail, Qmail, etc). You actually always could, but you’d have to ape some Postfix tables. You don’t have to do that anymore.

• To make it easier to write web-based front-ends to dystill’s MySQL database, enabling users to add rules.

This was done by adding an “email” column to the filters table, updating that field with the recipient address, and dropping the old user_id field. Also, a “maildir_path” config variable was added to the config, specifying where the maildirs live.

There was also a minor bugfix I came across the other day where certain uncommon (but legal) characters could result in unreadable maildirs.

The recent announcement by Linus Torvalds that the next release of Linux will be 3.0 has provoked rather furious discussion around the Internets about whether or not the incrementing of the version number is warranted. Linus himself has said that “absolutely nothing” has changed. “It will get released close enough to the 20-year mark, which is excuse enough for me, although honestly, the real reason is just that I can no longer comfortably count as high as 40.”

This got me to thinking about the nature of version numbers. Once upon a time (when versions were driven more by engineers and convention, and less by marketing), a version number meant something. Major, minor, revision. A major new release that modified significant portions of the code from the previous release incremented a major version number. Version numbers less than 0 were beta releases.

Linux has been at 2.x since 1996, and at 2.6.x since 2003. Mac OS has been at 10.x since 2001 (even though the current version of OS X is significantly different from the original release in 2001).

Meanwhile, Google Chrome has blasted through major 11 “versions” in three years. Mozilla is planning to release versions 5, 6, and 7 of Firefox this year. You can’t tell me that they are going to change major parts of Firefox three times this year. In this case, version numbers are purely being driven by marketing. They need to “catch up” to Chrome and Internet Explorer.

But we live in a different world now. One where, arguably, version numbers are becoming less and less important. The growth of “app stores,” I think, is desensitizing your average user to a version number. While apps in the app store still have versions, I couldn’t tell you what “version” any of the apps on my iPhone are (other than the OS), and I bet you can’t either. Any of the apps I’ve installed from the Mac App Store I could not tell you the version of them. I just know that, when I see the number on the icon, I know I need to do updates. The updates happen, and I get a new version with whatever new features are there (or, in the case of the Twitter app, whatever features have been removed).

Then there are web apps which are versionless. What version of Gmail do you use? You don’t. You use Gmail. Sure, there’s probably a revision number or something in the background, but the user has no clue what version they’re using. And they don’t need to, because there’s no action they need to take.

So version are numbered in a wide variety of ways depending on the product and overall seem to be becoming less important as the growth of broadband, “app stores,” web apps, and automatic updates make thinking about version numbers less important. So why does it matter if Linus ups Linux to 3.0? Ultimately, it’s just a number.

So I came across an interesting quirk in MySQL the other day. Let’s say you have a table schema and some values that look like this:

+-------------------+------------------+------+-----+---------+-------+
| Field             | Type             | Null | Key | Default | Extra |
+-------------------+------------------+------+-----+---------+-------+
| page_id           | varchar(30)      | YES  |     | NULL    |       |
| clicks            | int(10) unsigned | YES  |     | NULL    |       |
+-------------------+------------------+------+-----+---------+-------+

+---------+--------+
| page_id | clicks |
+---------+--------+
|       1 | NULL   |
+---------+--------+

And then let’s say you pass the following SQL statement to MySQL:

update page_click_count set clicks = clicks + 1 where page_id=1;

If you come from a loosely-typed language such as PHP, you would probably expect clicks for page_id 1 to now be 1. But that’s not the case in MySQL. After the query is run, the table will still look like this:

+---------+--------+
| page_id | clicks |
+---------+--------+
|       1 | NULL   |
+---------+--------+

Not only does the query fail, but it fails with no warnings given. It appears that mathematical operations on null values silently fail.

There are a couple of ways around this. The first and most obvious is to set NOT NULL and a default value on the column. In the example above, this would work. The NULL value in that field becomes a 0 and you can to normal mathematical operations on it. But what happens if, for whatever reason, you can’t do that? We actually have this situation in a few places at dealnews, where NULL represents a distinct value of that field that is different from 0. In this case, you can use COALESCE() to fill in the appropriate value for the field.

update page_click_count set clicks = coalesce(clicks, 0) + 1 where page_id=1;

Edit: Brian Moon informs me that this is actually part of the SQL specification. So hooray for specifications. Still, it’s kind of arcane; in working with MySQL (and PHP) for a decade now, this is the first time I’ve ever actually encountered this. Hopefully this helps someone who was as confused as I was.