Well, I’m thrilled to say that Quicksilver is back! In fact, a new release, b59 went out on April 24th. Quicksilver now has a new Web site, at QSapp.com, and a corresponding blog at LoveQuicksilver.com. Quicksilver is still free, with tons of plug-ins, many of which have been recently updated.

If you’re using a Mac, and aren’t already familiar with Quicksilver, Launchbar, or Alfred, you owe it to yourself to check one or more of them out. It’s totally diminishing to label these applications as just a launchers, although that’s the easiest label to apply. You can launch applications with these programs, or open files, but you can also do thinks such as: perform arithmetic, send emails, move and copy files and folders, and much more.

FontTester, as you might expect, lets you play with different CSS and HTML options to adjust what fonts you use and how they are formatted. The page starts with up to three columns of sample text at the top. Then you can edit the properties of the individual columns to compare and contrast different effects. Once you have the look you like, including color, line height, indentation, and more, you can copy the corresponding CSS.

If you’re new to CSS, you might want to check out CSS Basics. I think it’s a fairly straightforward, easy to understand introduction to Cascading Style Sheets. Once you’ve grasped CSS fundamentals, and found yourself wanting more, check out the exhaustive 84 Amazingly Useful CSS Tips & Resources. There are links to LOTS of good content there; just give yourself time to kill and don’t forget to take good notes!

Once you’ve got a site fairly well developed, you ought to do the professional thing and check its accessibility. This is a pretty easy step to skip, especially if you don’t have personal experience in accessing sites using non-standard tools. Sitepoint put together an article worth reading called 12 Tools To Check Your Site’s Accessibility. Some are software plug-ins that work with Dreamweaver, Eclipse, Firefox, or Opera; other tools are Web based, just like those used to validate a site’s HTML. Besides increasing the potential number of viewers for your site, making it universally accessible may even be something that’s mandated by the client. For example, I do a lot of work for educational institutions and the federal government, both of which insist on sites being accessible.

• Flex components (UI, containers, effects, validators, etc.)
• Services (data and network interactions)
• Cloud APIs (Amazon, eBay, Flickr, Google, Twitter, etc.)
• Mapping (Google, Mapquest, Yahoo!)
• Third-party tools

Most categories also have a “techniques” section, giving specifics for how to accomplish common tasks. There’s tons of sample code that are also visible in action, so you can easily understand how the code works in practice. And, of course, the related language reference is included.

Tour de Flex is available in both an online and desktop version (thanks to Adobe AIR for the latter).

Litmus also makes an application for testing how a newsletter will look in different email clients.

I don’t talk much about Windows, despite so many of you out there using it, so I thought I would pass this along.

To be clear, Ubiquity is still in a beta format, and it’s pretty geeky stuff. But if you’re the kind of person that likes cutting edge (but still useful) ideas, and/or, if you have some time to kill, check it out.

• Use a browser development plug-in, like Firebug and YSlow
• Learn JavaScript

This author also mentions using a reset stylesheet, something I wasn’t familiar with but is also mentioned in…

…the 10 Dirty Little Web Development Tricks article at Yongfook. That author also recommends using a versioning system like SVN (to control the different versions of files as you work with them), which I feel makes more sense if you’re working on something with a team. Along with recommendations to learn the jQuery JavaScript framework and the Zend PHP framework, the author also suggests you take a break, perhaps the best piece of debugging advice that I’ve ever also given (I always include that in my books). There’s also some best-practices there related to using frameworks and MVC approaches to sites.

New to me, and a slightly negative reflection on my site, was entity tags (ETags). An ETag is a unique identifier for a resource. A browser (and other software) can check a resource’s ETag to know whether or not to download the resource, somewhat similar to how expiration headers are used. An ETag can be any value that represents the resource and changes when the resource changes. Commonly the server might use the file’s modification time for this value, or a hash representation of the file as a whole (e.g., run the file’s contents through an MD5 function). My server was providing ETags for all but the main PHP page. This makes sense, because PHP pages aren’t like static HTML pages: my main PHP page is updated whenever the database it uses for its content is updated.

One fix would be to have PHP send an ETag header:

header("ETag: \"representative value\"");

As already written, the representative value could be any of the following:

• The modification time of the last database record used by the page
• An MD5 representation of the entire page, including the database-driven content
• An MD5 representation of just the most recent database record that’s reflected on the page.

And the answer I came up with was…just to ignore ETags on this PHP page. Coming up with any of those values would require a decent rewrite of the entire page, something I just don’t feel like doing right now. And, in my defense, my score turned out pretty well after I addressed the JavaScript and CSS compression issue…

Another reason I lost points was because two of the files being sent (the JavaScript and the CSS) weren’t being compressed. Most of my site uses PHP, which uses the zlib library to compress data sent to the browser. So PHP on the server compacts the HTML, it gets sent to the browser in compressed format, then the browser decompresses it and reads it. That’s great and generally recommended, but the JavaScript and CSS pages aren’t being handled by PHP. One solution is to use Apache’s mod_gzip or mod_deflate module to compress CSS and JavaScript files. To do that, add this code to an .htaccess or .conf file:

<IfModule mod_deflate.c>
<FilesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

That code basically says if mod_deflate is loaded, any file that ends with .js or .css should be ouptut using the deflate filter.

After I took all these steps, I got my YSlow grade up to a 98! I’m pretty pleased with that result. Also, in more concrete terms, if a user accesses my home page for the first time, they perform 4 HTTP requests and download just over 21KB of data. Subsequent requests of that same page require only 1 HTTP request and 3KB of data to be downloaded. That should make a big difference.

To wrap up this thread, I’ll mention two things. First, the YSlow plug-in and report is a very useful tool, but it’s not the only test or indicator of a site’s performance. I do think it’s a great place to start, though. Second, in researching some of these fixes, I came across several other sites where people did the same thing I did (tested their site using YSlow, then tried to address the problems). If you’re interested in this process, you may want to search online to read some of those other articles.

(As a post-script, I will add that one can improve the ETag score by disabling ETags in Apache, strange as this may seem. By doing so, it forces browsers to rely upon the caching headers. So if you can’t or don’t want to get ETags to work, turn them off and they won’t cause a problem.)

As always, thanks for reading and let me know if you have any questions.