If you didn't ignore the web for the past few years, you've probably heard it a million times by now: separate your content and presentation, use CSS for presentation, and say yes to semantic markup. There is no doubt that it's the right thing to do, given the sheer amount of benefits.
In a nutshell: it makes your life easier by lumping those pieces together which belong next to each other. It's somewhat akin to the proximity usability rule. It also keeps the noise down; if you want to change parts of the presentation there are no content bits in the way and vice versa. There is also a lot less overhead since those style sheets can be cached on the client side. In extreme cases it can save as much as 200kb of utterly pointless bloat. Additionally, proper CSS usage also paves the way for the ultimate killer feature: interchangeable presentation.
Just a few hours ago Google announced the latest feature of their chart API: QR Codes. I always thought that it might be cool to have some QR image of the current URL on my website. So, if someone happens to read one of my articles over at some internet café or at a friend's machine, a QR code might be handy for "bookmarking".
Writing a QR encoder with PHP didn't look like much fun though. And then there is the processing overhead, which can be addressed with caching, but that only means more work. There is also that random string DoS attack vector. Far too much hassle, really. But if Google takes care of all that, it's a piece of cake.
That's why I wrote a little test module for Drupal. It lacks width/height options, but apart from that it's fully functional (as far as I can tell).
I was tired of waiting for this to happen. It's simple stuff and the effect is pretty big if your content primarily consists of text. Well, it's not like this affects the text - that's already compressed by Drupal if you allow it to do so - what I mean is the compression ratio. If you serve megabytes of images, sound, and video, shrinking those few percent of JS and CSS won't have much of an effect.
However, if your site is more like this one you might be able to cut the size of the site in half. For people with a non-primed cache, that is. That's a really big plus if you get a sudden surge of visits. Nowadays the typical resource usage pattern seems to go from one spike to the next with rather little usage in-between. Take a look a Esoteric Curio's excellent article if you're interested in some more details.
As I previously pointed out even your regular visitors often won't have a primed cache, because the cache is simply too small for today's bloaty web. By the time they visit your site again the cache was already overwritten most of the time. Server-sided caching and compression to the rescue!
Just finished upgrading this site. The upgrade went well on my test server and fortunately it also went well here. There was some odd issue with phpMyAdmin's backup though. Everything is UTF-8, nevertheless the dump started with the following line:
CREATE DATABASE `foo` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
Swedish? Well, "latin1" was already totally off, but that? Uhm.
Well, it was good for a laugh. Fortunately the dump itself was still UTF-8 encoded and everything was fine - after getting rid of that really weird line, that is.
Lots of weird requests which resulted in 404s showed up in the log. Things like:
XX at http:/kaioa.com XX at XX XXathttp:/kaioa.com
Where "XX" stands for the node id. E.g. "36" for this blog post.
After investigating it for a bit I found the shocking reason behind this.
The offset for the next turn wasn't adjusted. Now it uses arrays and replaces the the whole lot at the very end. Well, weird code leads to silly mistakes. ;)
If there are any problems post em on the issue tracker.
I checked out the Video module for Drupal, but it doesn't really look like what I need. I prefer a 1:1 mapping for screencasts, which allows you to read menus and dialogs easily. Youtube doesn't really cut it. It's too small and the visual quality is pretty poor.
With the Video module I can only embed videos directly into the website, which isn't all that feasible since the videos will have rather big dimensions, which in turn may break the layout (or any future layouts). You can of course work around that with custom node types, which use a different theme. But that's way too fiddly.
The alternative? Grabbing a decent FLV player (I picked flowplayer), 21 lines of php and 3 lines of .htaccess. And that's it. Well, it's not that user friendly. I have to upload the FLVs plus some configuration file for each video manually via FTP, but I'm fine with that. The creation of a really short screencast with a length of 2-3 minutes takes already about 2-4 hours. One extra minute of fiddling won't hurt much. ;)
Download: SHJS Filter (6kb - same location)
The implication of the latter is that code, which was cut off (teaser view) will be properly highlighted and escaped. The cutoff is indicated via "[...]".
Well, the potential cutoff, that is. If you forget the closing </shjs> tag, you'll also get that "[...]" thingy. Maybe it will be possible to do that in a more sensible fashion with Drupal 6.x.
Download: SHJS Filter (4kb - same location)
A rough overview of the visible improvements:
Ye, I guess I'm pretty happy with it now. :)