If you've been visiting this blog for the past half decade, then, firstly, wow. I haven't written anything new since 2009. I feel like I should give you an award! But if you did visit, and returned now, then you might notice a change of layout on this site. I thought I'd celebrate it by, well, blogging about it.

This blog sort of died somewhere between 2009 and today. It was running on Wordpress (after I migrated from Radio UserLand, which is even more ancient but still gets me excited about blogging and technology every time I think about it), because I didn't feel like adapting the home-brewed software I use on my Dutch blog to facilitate two blogs, and apart from the fact that I didn't write on it anymore, I fell behind in keeping the installation up to date. Wordpress has had some leaks over the years, and this site has fallen victim to some of those, causing the blog to be a big bad motherf*cker of a spam infestation. Not good.

But I always felt like I should whip up something new, migrate the content and restart the blog to have a place where I could write down some notes, every now and then. So I've done what I was always too lazy to do: adapted the Breuls.log software to run on multiple domains and run multiple sites from one CMS. It wasn't all that hard, after I rewrote the blog CMS last year to work in a well respected framework instead of using decade-old spaghetticode scripts. It took me litte over one saturday morning to export the entire blog from Wordpress (it exports in RSS, which is nice), write a script to import it into my own database and point the blog.breuls.org-domain to the new location. The blog you're looking at is now simply part of my other blog, and serves as an English language branch of it. And I can manage the entire thing from the same CMS. Me likes.

So here we are, brand new. Now to find something to write about...

Zend Developer Zone: "Drizzle is a new, lightweight fork of MySQL specifically designed for cloud applications. Although Drizzle is still under development, it's attracting a lot of attention from developers around the world. This article introduces you to Drizzle and shows you how to use the Drizzle PHP extension to perform queries, retrieve result sets and handle errors in your Drizzle+PHP application."

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

To increase performance at the site I work for, we started separating static webfiles from dynamic pages using a separate hostname and web server for static files a while ago. For this, we placed almost all of the images, style sheets and Javascript files on a separate server and installed Cherokee for light and fast web serving on that server. And it worked. Loading of images became easier, and we could apply some of the server-related suggestions from Yahoo!'s Exceptional Performance.

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.

It's one of those facts that you learn once and then always remember: if you want your URL's to be properly indexed: don't stuff them with querystring-data. Make them nice, like they're static URL's. That's what I always knew. Like riding a bike, you never forget it. But Google says this isn't exactly true;

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!

It's always fun to compare tools. Who works with what and especially, why? Following the example of Flickr and some others, let me list my tools, see if you match:

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?

I like conferences. They bring a combination of information, context, some discussion and all kinds of impressions to you in audible form. In a form that doesn't require you to browse through blogs or magazine articles. Also, you can reflect on the subjects with others during the break times. Or just reflect on it by yourself. In some way, it differs from just reading about the topics on weblogs or online manuals, it's got a different vibe. One I like.

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?

» MacGDBp - a PHP debugger using XDebug
» Dutch PHP Conference 2008 - The Video - I was interviewed. Did I make the cut?
» DPC'08 review by Rick Buitenman
» It's About Time You Learned Javascript (for real) - I think I'm gonna read that book
» The Top Ten Subversion Tips for CVS Users
» The Subversion Book
» Running multiple FireFoxes on your Mac
» PHP Performance Series: Maximizing Your MySQL Database
» Which is the fastest browser?

» Download FireFox 3 and install it on my Mac (my Ubuntu machine switched to FF3 weeks ago)
» Download this possibly very interesting PHP Debug thingy for the Mac

I've got lots of content in my RSS aggregator that I "want to read, but not right now". And I keep skipping over it, making sure I don't accidentally mark those items as read, and that is starting to annoy me. So I'll just do what every sensible guy does: make a note of those items and move on.

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.

When I work, I usually use two computers: an Ubuntu-powered PC and my MacBook Pro. Of those, the Mac is my main machine: I have all my development tools and environments running on it, I use it for mail and documents, my music is on it (because I can't work in silence), etcetera. It has this value to me because I can carry it to wherever I need to, which means I can use it at both of my two jobs, plus on location if I ever need to (and sometimes I do).

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.

According to Baron Schwarz the second edition of High Performance MySQL (the first edition being written by Jeremy Zawodny and Derek Bailing, which I read twice and still often use as reference) is in production, meaning that it's written and being prepared for print.

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.

Hmm, nice step: the Zend Framework will be included in the repositories for Ubuntu Hardy Heron, scheduled for release in April. Not that the average developer wouldn't be able to obtain a copy of ZF otherwise, but it's nice that it will be included.

Let's hope updates to the Zend Framework will be ported rapidly into Ubuntu, so Ubuntu/ZF users wille be able to truly depend on the packaging system.

It's those little things: in PHP 5.3, the constant __DIR__ will be available. Of course, this is the same as the output from dirname(__FILE__), but it makes life just that little bit easier.

The Dutch PHP Conference, which I went to last year, is getting its second edition. It's a bit more expensive than last year, but I'm certainly going to consider attending.

For the last two months, I have been using a new Zend product as my default PHP editor. I haven't blogged anything about it, because until last week, it was a closed beta.

At ZendCon '07, however, the beta of Zend Studio Neon (with Neon being the beta-name) was released to the public, inviting everyone who's interested to the party. So now it's okay to blog about it, and I would like to take this opportunity to name a few things that might cause Neon to become my default editor, permanently.

1. Custom formatting
In the classic Zend Studio, you can select a piece of code and have Studio re-do the indenting of that section for you. Very handy when you've messed up your code in some way, or several CVS commits from different people have thrown the structure out of whack. In Neon, this feature works even better:

I can configure exactly how I want my code to look: where I want my spaces, where the braces should be placed, how the code needs to be indented and lots more. I can configure the formatter to follow my personal coding standards, select a piece of code and have Neon apply my standards to the selection. Brilliant!

However, Neon doesn't remember my preferences, so I have to export them whenever I make a change and import them every time I start Neon. Also, a few bits of my prefs cannot be configured, such as the way arrays should look when you divide the declaration over multiple lines. But I expect Zend to be looking into that, as several of the closed-beta testers have already mentioned it in the testers group.

2. Easy compare and CVS-integration
When Neon recognises a project to be a checkout of a CVS-module, several options are added to the navigator (the outline of files and folders on the left side of the screen). To name a few:
- Every file that has been changed is visually marked as being different from CVS. This makes it easy to find what you have changed and might be ready to be commited into CVS.
- I can update and commit from the navigator. The classic Studio had this as well, but it was useless because the following feature was missing:
- Compare! I can right-click a file and compare it to the latest version from CVS, or a specific revision, or just compare it to another file I also selected. The ability to compare makes it possible to check if the file I want to commit is ready to be commited: I can see all the changes and if I left in some junk (an echo, some commented-out code, you name it), it shows up as a difference and I can edit it while still in the compare screen. Brilliant! I'm used to the way Kompare works, and frankly that one has a better overview of the changes, but Neon makes a good second best, especially when combined with the CVS options.
- Neon acts as a complete CVS client. I can change the revision of a file, create branches, browse the history of a file, commit several files at once and more.

3. It's more than a PHP editor
Apart from writing PHP code, I do a lot of work with Javascript, XML, Webservices and such. I can open a Javascript file and it opens in a specific JS editor, complete with a preview screen which exectutes the file as if it were loaded in a browser. Or I can open a .xsd file and the XML Schema in it is shown in graphical form, complete with all kinds of functionality for altering the schema. It even shows errors I made in either type of file. Very, very nice.

4. Choose the PHP version per project
In the classic Zend Studio, I have to change the PHP version from 4 to 5 and back when working with different projects. In Neon, I can configure this in the project-specific settings, instead of editor-wide. Quite a time-saver, as it prevents me from looking surprised at my editor, wondering why it thinks a bit of code has an error when it clearly doesn't.

5. Project-wide error checking
When I open a project, Neon checks all the files, both PHP and other types, for errors. When it finds them, the erroneous file is marked as such in the navigator, and so are all the folders above it. I can easily follow the path in the navigator to find the file with the error, fix it and when saved, the mark disappears. And of course I can commit it immediately.

The downside to this is a heavier editor, though. When a project resides on a remote server, and Neon startes opening and parsing them all, my computer gets very, very slow due to the heavy traffic. In fact, Neon already is very memory-consuming and needs to be shut down if I want to open something else that's big in memory (a video player, for instance). I really hope Zend is able to do something about that.

There you have it, five things I like. There are also things I don't like: the memory Neon consumes, the multitude of 'perspectives', editors, outlines and other screens I don't really 'get' yet, the fact that even a closed project shows up in the navigator and some other minor things. But those are all little bumps in the road, and as Neon is still in beta, I'm not really worrying about it.

Whenever I need to make large (laaaarge) changes in code that has been sitting in its place for a while, an exciting and a bit frightening thought enters my mind: "throw it all out and start from scratch". Exciting, because starting to build something that you know is gonna be great simply rocks. Fresh, clean code without months or years of editing history is just lovely to work with. Frightening, because you know how long it took to create the existing code, you know how long other rewrites took to do and you know that this is no exception. Also, you know you are gonna have to address all the problems you had in the first run.

But the feeling that you should start from scratch is always there. In my own forum software, Replique, I already did this twice (although the second was a partial rewrite). With reasons and, fortunately, the desired result: a better application. In a CMS that runs at a website I work for, we also did it twice. And it will probably happen again in a few years.

And this is why. Just this afternoon, I stumbled upon Derek Sivers's weblog, who tried to rewrite a website in Ruby but failed miserably. Rafe Colburn replied to his and linked to a piece by Joel Spolsky, from which I quote:

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It's harder to read code than to write it.

And that is so true. As is probably true for most developers, my coding style has evolved over the years. Indentation, the placing of braces, the naming of variables and so on, when I look at how I did in a few years ago I scare myself. Did I really write this? Yes I did.

And it's not just the style. Over the years, if you're (aiming to be) a professional developer, you learn more and more new stuff. And every now and then there's the urge to try out those new things. And every now and then one of those urges makes it into your code and stays there for years. When you look at it, years later, you know that you should have resisted the urge. Not that it's bad code, of course not, you're a pro. No, it's just.. silly. The old method of doing whatever it was that that code did was just as good. You didn't keep it simple, stupid. ;)

The Big Question you should ask yourself before starting a rewrite is: am I doing this because I want to, or because the changes I want to make need me to? Is it so damn hard to make the changes in the existing code? Does it hurt to just refactor the bits and pieces you are going to use? Will it hurt the performance when you don't do the rewrite? Okay then, do it. If not: just make the changes and be happy about it not costing you time you could use for really new, fresh projects.

I'm working on a piece of PHP-code, and I need to examine if there are any bottlenecks in it. It's not much code, about 170 lines, but there are quite some includes, object instantations, conditions, etcetera, and I can't easily oversee if there's anything that might cause a web server's load to rise too much if this particular piece of code gets executed hundreds of times a second (I know that that is certainly going to happen).

So, what do I do? I do a quick check: do I have any debuggers or profilers running in the background which I can use to learn about this code? And I find there's a Zend Debugger present, because I run a development version of Zend Platform.

Using get_extension_funcs() I know that the debugger has six functions I maybe could use, but I don't know what they do. Can they give me some useful information? I don't know. So I just call the functions to try them out. Nothing of use comes of it. So I decide to look up some documentation on these six functions.

Nothing on PHP.net. Nothing on Zend.com. Nothing on weblogs where Zend Debugger is mentioned. Nothing on forums. Nowhere can I find documentation on how to use Zend Debugger from my code. Doesn't anyone use the debugger? Is it only meant for use in Zend Platform and IDE's like the Eclipse PDT thing?

Does anyone know?

Paolo asks whether it's a good choice to start a promotial site for Italy with some flash intros. I think it's not. This is what I posted as a comment:

I don't like the flash intro. It has no use whatsoever and it makes me wait. So if they could drop that one, it would be great.

Second, I get the intro with the language choice. Now, that one does have a function, but I would guess that the majority of visitors speak English, so it's probably better to open with the English site and make it clear that an alternative language can be chosen.

I don't really mind the third flash thingy on the site itself. After all, it's a tourism site, so some sights of the country are okay, as long as all the information can still be easily found.

So to all you webdevelopers out there, pondering on the possibility of a flash intro: don't. Please don't.

Metadata as a ‘filing system’ - about using Spotlight and tags on your Mac.

Fixing AJAX: XMLHttpRequest Considered Harmful

Yahoo! Tech - Nerdy, gadgets, stuff, cool! (but damn, the site is slow)

Apparently, the MacBook Pro is too hot.

Keep your Mac(Book) safe

Google Importer - search Google with Spotlight

Linux for human beings - Yet Another Ubuntu Blog?

When testing my self-built aggregator (more on my Dutch blog, I will write about it in English when the time is right), I noticed that the feed of this blog doesn't provide full text. I like to have full text, so I went to the WordPress Options to enable it. To my surprise, the radio button next to 'Full text' already was checked. So I opened my feed to look at the source.

Turns out, WordPress doesn't use the description element to put the full text in. Sure, there is a description, but it contains no more than a summary. The full text is in content:encoded, an element similar to description. Why is that? I've seen several blogs use that specific element, and never have I seen just one advantage of using that element from a separate namespace instead of the standard RSS-provided description. Someone once told me it can be used to put non-encoded HTML in, enclosed in CDATA tags, but why not just encode it and put it in the description? Except for the encoding, there's no difference. And you can put the CDATA in the description as well.

Now I have to make a decision for my aggregator: when there's a content:encoded element, as well as a description, which one do I use? The fact that I have to make that choice is wrong. It should be clear what to use, without having to compare elements.

"Stop the nonsense of doing the ajax dance in every single possible place. You’ll end up being the party troll."
WeBreakStuff » Ajax won’t cook you breakfast

It's true, you know. Ajax is the new buzzword.

..to impress your friends. Some interesting web developer thingies.

Well, that was easy. I was looking for a way to fetch HTTP request headers in PHP, for the implementation of Conditional GET in an RSS module. PHP has this function, apache_request_headers(), which returns an array containing all the headers you could possibly need. Problem solved!

But; when the software you're working on (in my case a content management system) has to work on both Linux/Apache and Windows/IIS servers, there's a bit of a problem: Apache-functions won't work if there's no Apache to work with. Fortunately, you don't need functions to fetch specific headers: PHP has already gathered them for you.

When a client requests a PHP-driven page on your web server, you can check for request headers in the $_SERVER array. For instance, the If-Modified-Since header is stored in $_SERVER['HTTP_IF_MODIFIED_SINCE']. This will work for every header you can think of: PHP just converts them all to the right variable. A header This-One-Doesnt-Exist becomes $_SERVER['THIS_ONE_DOESNT_EXIST'] in PHP code. Just like that!

A good programmer has knowlegde of several languages. Need to learn Python? It takes 10 minutes to do it.

When you're a web developer, as I am, you might think this one is useful.

moo.fx is a superlightweight, ultratiny, megasmall javascript effects library, written with prototype.js. Very useful, I might say.

I'm a web developer, and every now and then I have to create the HTML for a site that, in its design, uses multiple columns. It's at those moments when I think: "I know tables are bad, I know I shouldn't be using them for this, but please, may I?" It's a real drag to get a columns-based layout using just divs and CSS.

The W3C understands this, apparently, according to this A List Apart article. With the multi-column mode in CSS3, you can divide the text within a div into multiple columns. That's nice. A real good beginning in solving the "I cannot use tables, so what should I do"-problem.

But, we're not there yet. A columns-based layout isn't about text in multiple columns, it's about the entire site in multiple columns, just like this blog currently has two: one with the text in it, and one with the navigation. It's no problem if those columns can both do their own thing. One column has text, the other has links, and every column has its own length. Fine. But: if both columns are supposed to have the same length, it gets more difficult. What if one column becomes longer? How will the other one know it's supposed to scale accordingly?

It won't. There's no way for a div to make it size itself based on another div's size. That is, if you don't use hacks. Will there be a solution to that some day?