Het Bijstere Spoor

In my work I have to look a lot at the IETF rfc documents, and I always have to jump through a bunch of hoops to find the document I want. Google often links me to the text version, and often I'm looking at obsoleted versions of documents when a new rfc has been published.

Well, so I created a simple OpenSearch provider to solve this. It does exactly what I need, and I only tested in Firefox. If it's useful to anyone else, you can add the provider from rfcsearch.phpfogapp.com.

It works with a simple hardcoded list of known keywords, and it will fall back to "Google's I'm feeling lucky" if it doesn't know the keyword. Feel free to fork it or laugh at my source code.

My PHP Advent article just got published. It's a list of best practices around dealing with dates and times in PHP. Have a read and tell me what you think. Also, be sure to follow @phpadvent or subscribe.

While profiling SabreDAV, I noticed a few times more than half of the request time was spent in the autoloader.

So instead of autoloading, now I prefer to unconditionally include every file for each package (there are 5 packages). For a while I manually maintained these files manually, but a while back I automated this process.

This is how you run it:

phpincludes . includes.php

This will generate a file such as:

<?php
 
// Begin includes
include __DIR__ . '/Interface1.php';
include __DIR__ . '/Class1.php';
include __DIR__ . '/Class2.php';
include __DIR__ . '/Class3.php';
// End includes

You can edit everything before "// Begin includes" and after "// End includes". Subsequent edits will only replace the lines in between those comments.

The script will automatically expand classes and interface dependencies and load them in the correct order. It also has support for a PHP 5.2-compatible syntax (dirname(__FILE__) instead of __DIR__).

If you like it, head over to github, or install it with:

pear channel-discover pear.sabredav.org
pear install sabredav/PHPIncludes

I've finally taken the plunge and moved the SabreDAV source from Google code to GitHub.

The main reason is that I'm hoping that people are more likely to fork and contribute. This was possible as well on googlecode, but I think people had a bit more trouble getting used to the feature.

Mercurial is still the best source control system, but I feel switching to Git was worth it, solely for GitHub.

You can find the source at https://github.com/evert/SabreDAV.

Interesting news today. The Olson database, which is used in countless operating systems and other software (including PHP) has been shut down due to a Copyright claim.

Details, which I won't repeat here can be found on Stephen Colbourne's blog.

While working on an application I ran across a huge bottleneck which I isolated down all the way to the use of the iconv_substr function. If you ever wonder which is better to use, this should help your decision:

Benchmark script

<?php
 
$str = str_repeat("foo",100000);
$time = microtime(true);
 
iconv_substr($str,1000,90000,'UTF-8');
 
echo "iconv_substr: " . (microtime(true)-$time) . "\n";
 
$time = microtime(true);
 
mb_substr($str,1000,90000,'UTF-8');
 
echo "mb_substr: " . (microtime(true)-$time) . "\n";
 
$time = microtime(true);
 
substr($str,1000,90000);
 
echo "substr: " . (microtime(true)-$time) . "\n";
?>

The results widely varied between machines, operating systems and PHP versions; but here are two results I recorded.

First, PHP 5.3.4 on OS/X:

iconv_substr: 0.014400005340576
mb_substr: 0.00049901008605957
substr: 3.7193298339844E-5  # Note the E-notation, this was actually something like 0.00003 seconds.

As you can see iconv took 0.01 seconds, while mbstring took only 0.0004 seconds. Already a significant difference (2800% slower), but the difference became more apparent when running this on a Debian box with PHP 5.2.13.

iconv_substr: 8.3735179901123
mb_substr: 0.00039505958557129
substr: 4.8160552978516E-5

Yup, it took 8.3 seconds. That's an increase of over 2100000%. So next time you're wondering which of the two may be smarter to use, this may help you decide.

Important to note that OS/X uses libiconv as the 'iconv implementation' and my Debian test machine 'glibc', so it looks like libiconv is much, much faster than glibc. mbstring still leaves both in the dust though.

I'm interested to hear what your results are, especially if they differ.

Interesting news passed by today, apparently a fraudelent SSL was issued by Diginotar, effectively allowing wrong-doers to perform MITM attacks for all google services. Normally fake certificates will clearly error up in the browser, but because Diginotar is a trusted CA (certificate authority) it won't.

This says something about how much we can trust SSL. All it takes is one corrupt employee at a trusted CA and it falls down. CNET has pretty good coverage of the story.

Over the last month I've been working hard at the Atmail office in sunny Australia to get CardDAV support built into SabreDAV; and I've finally completed all the steps to do this release.

So there it is, CardDAV. Unfortunately there are not yet a lot of clients who actually use it, and it mainly comes down to iOS and OS/X, but I've been asked about CardDAV a lot and suspect more people will become interested in this protocol (especially if more vendors start supporting it).

So that's pretty much it; head over to download page to fetch a copy. I've had to break a couple of minor api's, you can read about those in the migration document.

• Full changelog
• Migration document for 1.4.x users
• CardDAV documentation

I tried my best to write good documentation for the new stuff, but it's always very time consuming, and not as good as I'd like If you have time and the will to write more, let me know!

Lastly, a big thank you to Nick Boutelier for creating the new SabreDAV logo!

Well, I just checked my calendar and it turns out I've been blogging for exactly 5 years now. This is the only time I allow myself to make an off-topic post, so here goes:

An exciting year indeed, with lots of change. Moved back from Korea to the Netherlands, started a new job, spoke at a conference, and I've met lots of bright and interesting people.

I've been royally sucking at blogging though. Only 22 posts in the entire year. Worst year to date :) I really should get back into the game, but I steadily feel that the things I'm running into from day to day becomes less relevant to blog about, as there has usually been someone else with a much better description of what I'm really trying to say.

Maybe that's just an excuse though.. If you're still reading, thanks for sticking with me!

Although PHP's loose comparison type juggling tends to invoke some negative responses, I don't think it has really ever worked against me, and works quite comfortably in my opinion. As long as you make sure you always use strict checking (=== and !==) where you can, and fall back to the loose checks when you must.

As a PHP developer, I think it's very important to understand and memorize exactly how these work, whether you're writing new code, or maintaining existing code.

A few days ago on PHP-internals I saw a behavior that was completely new to me, and very much counter-intuitive.

if( '20110204024217300000' == '20110204024217300264' )
  echo 'equal';
else
  echo 'not equal';

Guess what the output is.

PHP will for loose comparisons always try to convert numeric strings, even when both sides of the comparisons are strings. Because the numbers are too big to fit in an integer, they are converted to floats. For both numbers this conversion ends up in the number: "2.0110204024217E+19" (give or take, based on the standard precision settings).

In my mind it makes sense to do this type juggling when a comparison is done with <, >, <= or >=, but it definitely feels like a bug when doing an equals check.

The moral is: always do strict checks when you are able to.

Thanks to Matt Palmear for pointing this out.