There’s been a lot of buzz about Drizzle lately. Need to check that out some time.

However, Cherokee didn’t always try its hardest to serve us well: sometimes it decided to pull the server’s load to a performance-decreasing number, configuration of much needed features was “not yet implemented” or buggy and the software is overall not done yet. Also, the developers have, weirdly, decided to use exclamation marks as separators within the configuration, which is just plain annoying.

So we started looking towards other solutions. And we decided to go back to our other option before we chose Cherokee: Lighttpd. With Lighty, as it’s pronounced, we can apply these performance rules:

» Add an Expires or a Cache-Control Header
» Gzip Components
» Configure ETags

I’d like to show you which configuration options we used. The following applies to a default Lighttpd (version 1.4.19) as shipped with Ubuntu 8.10. If you’re using a different OS or if you’ve downloaded Lighttpd yourself, I assume you understand enough of it to translate the following to your own situation.

Add an Expires or a Cache-Control Header
For this, we need mod_expire. With that module, we can instruct Lighttpd to include both the “Expires” and the “Cache-Control” headers in the response. To enable the module, we uncomment this line:

# "mod_expire",

This line is mentioned in a list of modules at the top of lighttpd.conf. If it’s not, you should look for the list somewhere else in the file and uncomment the line or simply add it, but without the hash sign.

Next, look up a line that says ‘expire.url’. It should be there and commented by default. Uncomment it and configure it to do what you want it to do. For us, Lighttpd is entirely dedicated to serving static files, which all need to be cached by the client for a long time. Let say, for documentation’s sake, we choose two weeks as the caching time. This would then be our configuration:

expire.url = ("/" => "access plus 14 days")

This leads to these two headers when a URL from the Lighttpd-server is requested:

Expires: Thu, 25 Dec 2008 13:30:31 GMT
Cache-Control: max-age=1209600

And that’s it! Enable the ‘expire’ module, configure the expire time, and you’re done.

Gzip Components
To apply gzip encoding of the repsonse body, we use mod_compress, which is enabled and confgured by default. However, not everything we want to compress is actually being compressed, so we change this:

compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css")

into this:

compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css" ,"image/jpeg","image/jpg", "image/gif","image/png")

Over time, we might add other mime-types we forgot to include, but the above covers most of the requests.

When requesting an image with any regular browser, it will be sent to us, gzip-encoded. If you’re using FireFox with the Live HTTP Headers extension, you can find these in the response headers:

Vary: Accept-Encoding
Content-Encoding: gzip

This confirms that it’s working.

Configure ETags
This is the easy one. In our default installation, a request to the server gave us this as one of the response headers:

ETag: "2832627283"
Last-Modified: Wed, 10 Dec 2008 13:16:32 GMT
Content-Length: 1395

Because we currently use one server for the static serving, this is all we want. So we’re done.

And that concludes the confguration of Lighttpd as the optimal static-files-webserver.

We’ve come across many webmasters who, like our friend, believed that static or static-looking URLs were an advantage for indexing and ranking their sites. This is based on the presumption that search engines have issues with crawling and analyzing URLs that include session IDs or source trackers. However, as a matter of fact, we at Google have made some progress in both areas. While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking. Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static.
Google Webmaster Central Blog

Not only does Googlebot read dynamic URL’s just fine (and now I think of it: why wouldn’t one of the largest tech companies make any progress in this area over all these years?), they actually favor it if a dynamic URL is the ‘original’ of your URL scheme. Googlebot will figure out the parameters and do the indexing the right way.

Of course, static-looking URL’s are still nicer for a user to look at, and sometimes a URL that doesn’t have querystring-parameters can still be dynamic, but for Google’s sake: don’t rewrite it just for them. Good to know!

Working:

• Main machine: MacBook Pro. I have an Ubuntu PC, but that’s just ‘extra’. I do everything on my Mac, from working to living.
• Editors: Zend Studio 6 for all the main development tasks, completed by TextMate (and the handy ‘mate’ cli-command) and vim for serveral minor things.
• Transmit: used for access to (s)FTP code locations, and to manually check whether (s)FTP import applications do what they should
• iTerm with usually about six tabs. I traverse folders, grep through them, use CVS/SVN commands and access MySQL from the commandline. And of course I connect to development and production servers using ssh, but that goes without saying.
• MySQL Query Browser: I can usually do what I want by just using the commandline client, but every now and then I need a little more visual help.
• Zend Core: used as an all-in-one package for Apache and PHP. I also use MAMP to run a good old PHP4 environment because at one of my employers we’re still in the midst of upgrading to PHP5 (I know, shut up).
• Xdebug: I use it for profiling and I love the way it adapts var_dump() to a more usable way of displaying variables
• FireFox and FireBug: very important indeed. I can’t image having to work without FireBug. I still remember trying to think really hard about my HTML/CSS and placing alerts in my JS as a way of doing some poor-mans-debugging. FireBug is a godsend.
• YSlow: a man needs performance, and YSlow helps me determine what to do. Very nice!
• CSSedit: editors for CSS don’t do a lot more than text editors, but they help a little and a little is enough.
• OPML Editor: I keep my notes, todo’s and more in outlines. The best outline editor used to be the one from Radio UserLand, until Dave Winer took the tool and released it apart from the weblog editor.
• VMWare Fusion: although I love working on my Mac, I’m still missing what I already mentioned before: the combination of Krusader and Kompare (and to a lesser degree, Cervisia) for development work. For that, I am trying out using an Ubuntu virtual machine which uses the three beforementioned apps and sshfs to mount the (development) servers I’m working on. Works like a charm!

Living and working:
I take my Mac everywhere. I work on it at work, even though it is a private machine. At home, I use VLC to watch video’s and DVD’s, NetNewsWire for the daily read, Celtx for screenwriting, Mail.app for.. well duh, RealPlayer to listen to BBC Radio 1 or iTunes for my music collection, Twitterific for Twitter and Unison to eh, browse newsgroups.

Well, that’s most of it. What about you?

So last weekend I went to the Dutch PHP Conference. I went last year, and I liked it, so attending this year’s edition seems logical. But after a day of listening to some interesting talks I’m wondering: who is the indented audience for this conference? Am I even in it?

Let me explain by walking through the day. After @ijansch‘s opening, we were welcomed into the history of PHP by Zeev Suraski, one of the founders of Zend and with that, one of the people who made PHP what it is today. It’s nice to hear the story from someone first-hand, as opposed to reading it in the PHP Manual.

He gave his view on PHP today: it’s mostly done, and our focus as a community has been, and still is, shifting to frameworks. In a way that’s like saying “we’ve been building the car for a few years, now it has become time to do some driving”. And he’s right. PHP is never truly done, of course, but it is fairly done, and now it’s up to the frameworks to mature and become the highly useful, production-ready toolkits we all need (yes, need, even though some of us might not know it yet). In my view: some parts of frameworks wille eventually become more attached to the core of PHP, as often-used parts will grow into the extensions area.

After Zeev, Marco Tabini, publisher of php|architect (which I’m subscribed to), explained how important mayo is to the PHP world. No, wait, that wasn’t it. He wasn’t very PHP-specific, but his keynote was quite interesting nevertheless.

Lunch came and went, and the breakout sessions started. I attended the ones presented by Gaylord Aulke, Lorna Jane Mitchell and Ivo Jansch.

Gaylord talked about how you would go about creating, maintaining and using an infrastructure when you’re working in a team. He explained about development locations, version control management, test- and staging servers and deploying your work to a live server. This very much connected with Lorna’s talk, which focused on deployment in general, and on doing that with subversion in particular.

Both talks were interesting, but only small bits of it were giving me new information or a perspective I didn’t think of before. Both gave me the impression that the intended audience would not include people already working in teams, with version control already very much in place and several live projects to maintain. Those people would already have invented (and/or implemented) the proverbial wheel for their own situation. Which is the case for me: at both of my jobs, an infrastructure is in place and working nicely. Nevertheless, both talks were interesting, and some viewpoints offered, along with a nice feeling of confirmation, some food for though and/or Googling.

After the break, the choice was to be made between Stefan Priebsch’s session on the upcoming PHP releases, a session by Matthew Weier O’Phinney about best practices within Zend Framework (this description is not as accurate as it should be, but we’ll get to that) and Ivo Jansch’s presentation about Enterprise PHP.

Because information about PHP 5.3 and 6 can be found on the mailing list, wiki pages, blogs and the slides Stefan posted before the conference, that one was an easy choice: no need to attend. The session on Best practices within Zend Framework would only make sense if you were actively using ZF, I thought, so that would not be very practical at this very moment (I was wrong, as you can see by reading the actual description on the site, it’s not ‘within’ Zend Framework, but ‘inspired by’ it, if I understand correctly). So I entered the room in which I would be very cautious about product placement (kidding).

Ivo’s session had ‘Enterprise PHP Development’ as its title. Because I work in a couple of teams/environments where the label ‘enterprise’ might, in some way, be a suitable one, I thought I’d attend this session. It’s always nice to get some tips, attention points and such. But, the session was basically about the same as Gaylord’s and Lorna’s. Not that he covered the same topics, but again I felt like I knew a lot of it already. He covered ten main points you need to be thoughtful of when working on your projects, of which some were very obvious, and others inspired some thinking while in itself not being new (to me, at least).

After all this, my colleagues and me were interviewed for a Bachelor ICT video, in which we expressed our concerns about the lack of depth in the sessions. Terry Chay had already started his keynote by that time, so after missing the beginning, we hurried in and stood in the back, while listening to a very interesting and nice keynote. Chay is a wise man, I said to myself.

Looking back at the day in its entirety, I think I expected more. I already called my feeling about the sessions a ‘lack of depth’. This of course isn’t necessarily a bad thing. A PHP Conference, especially one in a community that’s still growing and has a lot of people still learning how to be the best, should be aiming for a wide audience and not exclude beginners. However, if some f the sessions would last longer, maybe the contents could become more hands-on and give you more the feeling you’re walking away with lots of information to research in the days or weeks after the conference.

I’ll probably attend next year’s edition, but can I silently hope for some more advanced content?

Adding to that, I thought I’d just share them with you, so here is my to-read list:
» Q&A and Recording of the Memcached Webinar
» How would you compress your MySQL Backup
» Please Give Us Your Email Password
» Give Your Site a Boost With Memcache
» MySQL Proxy: debug plugin
» MySQL Cacti templates 1.0.0 released (screenshots)
» Tools to use for MySQL Performance Review
» Designing For Evil
» Videos in the Flickr API

There. Now I can clean out some items in my aggregator. I’m gonna do this more often, by the way.

But there’s one thing missing: although Mac OSX is a very nice OS, probably the best I’ve worked with, I still need Linux to complete my wishlist. The combination of Krusader and Kompare, for instance, is a golden one if you need to organize your development projects. Krusader is a two-pane file manager, with the option to use FTP and SFTP or just local files. Whenever I need to examine the difference between two versions of the same file (and I need to do that a lot: before commiting my changes to version control, I want to know exactly what I’m doing), I set up Krusader to have a folder with one version of the project on the left and one version on the right. I then select the files I want to compare and the magic happens: Kompare starts.

Kompare is a frontend to the diff tool and as such not that special: if I just want to quickly see the difference between foo.php and it’s current state in CVS I can just use the built-in comparison tools from Zend Studio for Ecplise. But: Kompare is so much better! It has coloring to differentiate between additions, removals and changes, is more precise (due to the tried-and-tested diff being the backend) and has the ability to apply some of my changes to the other file, which enables me to be more exact in what I commit (you know, sometimes you have several changes in a file, but just a few of them belong to that relevant bugfix and the others are for that new feature that’s still unfinished, so you want to do a partly commit).

So, I need Linux next to Mac, because those tools don’t run on Mac OSX. When at home (for Job #1), that’s no problem. My only PC is an Ubuntu machine. But at work (at Job #2), I have an old PC which is kinda slow which I use for this. And the slow part, that’s annoying. Because whenever I need to use Kompare, I need five to ten minutes to boot the thing, and every action after that needs a lot of patience.

But, I share my desk with a colleague who sits there when I’m at Job #1. And he has his own PC, stalled under the desk next to mine. A new, fresh one, nice and fast, running Windows, and I already discussed making that one a dual-boot so we can share not just the desk, but the PC as well. But I don’t have the time to go and install Ubuntu next to Windows, carefully selecting partitions, making sure I don’t nuke his installation, and whatnot. So even months after “Hey, can I make that one a dual-boot?” – “Sure!” I’m still working on the slow machine.

Enter Wubi. Shipping with Ubuntu 8.04 next week, it’s an Ubuntu installer for Windows. And it does exactly (exactly!) what I need:

When I rebooted my machine, an option to boot Ubuntu was added to my Windows boot list, and after selecting it, Ubuntu started loading just as it would if installed on a dedicated drive. I was even given the normal GRUB menu.
(Linux.com)

So now I can just boot my colleage’s machine, put in the Ubuntu CD, click through the installer and enjoy Ubuntu. No need for me to run the Ubuntu installer, carefully selecting drives, doing all kinds of stuff that costs me time. Just click-click-install, the Windows way.

Life really does get better with every Ubuntu release.

That’s good news! As a MySQL developer and DBA, I’m very interested in knowing every piece of information about how to make MySQL perform well, and as soon as I can, I’ll order a copy.