@leo's

I slept in a real villa over the weekend.

Am 12. und 13. März findet in Bern erneut die Openexpo statt. Die eine Menge interessante Einblicke in die Schweizer Open Source Szene bieten wird. Mit dem Kernel Entwickler Alan Cox  konnte diesemal ein hochkarätiger Keynote-Speaker gewonnen werden. An zahlreichen Vorträgen und Ständen hat jedermann die Möglichkeit sich selber ins Bild zu setzen. Für Besucher die sich ängstigen von den anwesenden Nerds mit Fachchinesisch zu getextet zu werden, werden täglich Jungle Tours durch das Messegelände angeboten.

Mehr Infos unter http://www.openexpo.ch/openexpo-2008-bern/

Imagine the future nocks on the door of your valley and all your doing is talking about the ugly powerlines. I don't get it! The full story in german.

Some breaking news: After some rumors, it's public now. Sun Microsystem buys MySQL. Hopefully nothing bad for me as not-coffe-drinker. More on reuters.

First of all, be warned, this article has no pratical relevance. It even might guide you to bad code. But this week it just popped into my mind that I could use an array instead of a switch-case construct. So see how we can do this. This is the example for the switch in the php manual.

switch ($i) {
case 0:
    echo "i equals 0";
    break;
case 1:
    echo "i equals 1";
    break;
case 2:
    echo "i equals 2";
    break;
}

Now I'm able to implement this in a array, for that I put the code for every case statement in a arrayfield Afterwards I can access the field over the parameter and execute the code in it with eval.Here's the example: (Take care to not forget the semicolon in the code string)

$case[0] = "echo \"i equals 0\";";
$case[1] = "echo \"i equals 1\";";
$case[2] = "echo \"i equals 2\";";
eval($case[$i]);

Looks pretty, but what to do if you have to do the default statment. Nothing easier then that, we just have to look if eval goes ok and if not we do something after AND-short circuit:

eval($case[$i]) === false && print("default");

First of all: "PHP 4 is dead, finally!". There are only security fixes until my birthday (2008-08-08), nothing more. I read a lot about this in the last week on the planet (for example "So long, and thanks for all the fish!"). This article brought me to the statistic that only 25 percent of all php hosts run allread PHP 5, so a hell lot of hosts to update during the next months.

In this statistic it is also mentioned that only 50% of all internet hosts are run by asp or php so I tried to figure out how owns the other half of the cake. I tried to find out on netcraft and I didn't find it. But I stumbled over this article. It make me think. It's strange that domain parking decide about the market share of a webserver. This brings me again to "I only believe in statistics that I doctored myself" (which is defintly not from Churchill).

On the view of your database the worst thing you can do in your web app is paging. Paging is horrible in the view of performance. To explain let me take a little example:

SELECT SQL_CALC_FOUND_ROWS gb.*,
	u.username,
        u.uid,
        u.geschlecht,
        u.mitfoto,
        [... some more fields...]
FROM member_gold_guestbook gb
LEFT JOIN users u ON u.uid=gb.uid_from
[... some more left joins...]
WHERE gb.uid_to='22152'
AND visible='1'
LIMIT 0,10;

That's not that bad at all, but when you go to page 300 your database server will hat you for this. The database server has not only to calculate the 10 items you want to show but also all 3000 previous items.

Sure you may argue nobody will ever go to page 300. Somebody will not, but "googlebot" and his evil brothers will. And the bad thing is that you can, as long as you need paging, nothing do against it. There are just a few tricks that may reduce your server load a bit.

Optimize it!

A fast query that uses good indexes is just faster, no matter where you use it. But on paging where you might calculate thousands of lines it really does matter a lot.

Avoid ORDER BY and GROUP BY because you have to do this (depending on index use) on every line in your table, the limit can't help you here.

Cache it! But still the query has to be run once, especially for fulltext searches, even the first run of a query might put a lot of load on your servers.

YAGNI (You aint gone need it!)

Nobody will ever see page 300, so why you don't set an upper limit for you paging. Your user will not mind and I'm sure the bots will find another way to your stuff. If you really care about SEO, you probably can do a separate list for bots that perform with less operations on the database (remove unneeded joins, don't sort it).

Don't join tables you don't need, sure that might sound obvious, but I'm seen this too many times to not mention this here.

Count is evil

Never, never use SQL_CALC_FOUND_ROWS it's just equally slow then "SELECT COUNT(*) FROM table", but you have to do it on every page. The count(*) variant you can cache at last, so you don't have to do it on every page.

And there's even another way to avoid the count on paging. It's the way Facebook does paging on some places. Facebook don't give you the usually list of pages from 1 to n there, were you can click at any page. They just give you the page before, the current page and the next page, if there's one. On the application side it's very easy to find out if you have a page befor the current, when you on the second page there's one before (so no surprise here). But what's about the next page if you don't want to make a count. Easy stuff, let me predict you display 10 items per page, so query 11 items instead of 10 per page. This one extra item will cost you nearly nothing and now you can count the returned rows in your application. If you have more than ten rows you have a next page and you can happily throw number eleven away.

Die Nacht auf heute habe ich das erste mal in meiner neuen Wohnung geschlafen. Tolles Gefühl, auch wenns noch ein wenig kalt war. Ausser schlafen geht aber noch nicht viel, das Büro ist noch nicht eingerichtet, in der Küche liegt momentan noch das Büro meines Vaters und der Wohnraum ist noch eine einzige grosse Baustelle. Bis ende Woche werde ich dann wohl weiter sein...