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

I reset the time on our mailserver, because NTP wasn’t working (or at all running, I guess). Immediately my mail client started complaining about the connection. The above error message was the cause. It’s both funny and explanatory. I like it.

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.

I’ll be attending the London conference, after having been there last year, and I’m looking forward to it. Am I again going to be one of the few Dutch folks in the crowd?

You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a Low level.
You’re from the old school of programming and believe that you should have an intimate relationship with the computer. You don’t mind juggling registers around and spending hours getting a 5% performance increase in an algorithm.

You work best in a Solo situation.
The best way to program is by yourself. There’s no communication problems, you know every part of the code allowing you to write the best programs possible.

You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.

I’m a web developer, so the way I interpret the ‘Low level’ part is that I want to know what my PHP code does (through profiling and such), what actions my browser takes when I do something with javascript, and that I (for instance) use a packet sniffer when I really want to know what HTTP-requests are doing (very handy for ajax debugging).

I actually don’t think of myself as conservative. I like to try new stuff, be a bit adventurous, find new techniques to provide solutions, but in doing that I’ll always keep in mind that the end product needs to be well-performing, well-maintainable and, indeed, consisting of concise code.

Want to see what your type is? Have a look here. Thanks to @marcnext for the link.

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!

The book focused on PHP3, although PHP4 was already released. So, basically, I learned PHP with version 3. I started out writing scripts with a .php3 extension, something I still don’t understand; why was the version number included in the extension?

Anyway, not long after I started PHP’ing, my environments switched to PHP4 and I became a PHP4-developer. And I still am. One of my employers still uses PHP4 and although today is PHP4′s death date, there is no indication that there’s an urge to speed up the upgrade process (which thankfully is in place and being worked on).

The problem with PHP4 and PHP5 is that the upgrade process actually is a big step. For the software, because not everything ‘just works’ when you upgrade to 5, but also for the developers. Some of my co-workers still consider the features that were introduced or improved in 5 ‘new’, although they’ve now been included with PHP for years. And that’s understandable; when working heavily on projects in PHP4, and without having the opportunity to check out what’s ahead and trying to use newer features, you’ll never get a taste of it. Of course, developers should take those opportunities themselves, checking out new features and developments in their own time, but not everyone does that.

So today is the end of PHP4. Not really of course, because lots of developers will probably still spend months working on PHP4 code. It will work just fine and do just what you want forever, it just won’t have any updates anymore, But if you consider the fact that some servers (even those of my employer) still run a 4.3.X-version of PHP, that hardly matters.

I’m glad I switched the projects at my other employer to PHP5 at the start of 2008; not only are we up to date, but the new features (or simply the small improvements in existing features) make working with PHP a lot nicer. And we’re ready for the future; PHP6 is upon us, and I hope it will be adopted (and adoptable) a lot faster than its predecessor.

PHP4, you’ve served us well. You paved the way for PHP5. Thanks! Now get out, and stay out.

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?