Torrential Web Dev

I recently commented on a post from Joshua Eichorn looking at caching javascript files. In the post he highlights the savings that can be made in terms of bandwidth.

What can you do though if you want to prevent javascript from caching? The php manual has some useful suggestions. Continue reading "Preventing javascript files from caching"

I've just found out about the 'Future of Web Design' conference in London on the 18th April via the Signal vs Noise blog at 37signals.

The speakers cover a fairly diverse range of topics and being in the UK I'm tempted to attend. The only problem is I know I'm going to be busy towards the end of April (the conference is on the 18th). Still, the change of scenery may do me good.

There was an interesting post on Wednesday from Joshua Eichorn. Briefly he runs through a method for caching compressed javascript and css files prior to hosting them on a web server. He makes this all work with a few lines in a .htaccess file.

It is a good post but I think he misses something

There are a lot of various approaches for cutting down the size of JavaScript and CSS. Some of the common ones are removing whitespace and comments for JS and CSS, or using scripts which use alternate smaller syntaxes. There are a couple problems with this approach first it just doesn’t save as much space as I’d like, you can cut 60K of JavaScript down to 30K but not 10K. Second it makes debugging horrible, every JavaScript or CSS error comes from line 1 or the file.

Compacting and compressing javascript and css files is not mutually exclusive. As I showed in an old post looking at compacting javascript and css files 33% reductions in file size can be achieved by compacting these files even if you then compress them. To my mind that's worth doing.

His second point I understand even less. My experience with javascript I will freely admit is not as extensive as I would like but if some code works before compacting then it works afterwards. I sort out any bugs in development and only when my work is ready for deployment do I compact my css and javascript.

On a recent project I wanted to cache data and remembering how easy Cache_Lite was to use in my recent article on displaying a google pagerank I decided to use it again. Unfortunately I ran into a problem, it seemed to only allow you to cache strings and I wanted to cache an array. No problem though, I just serialized the data and then cached it.

Turns out though that Cache_Lite can actually handle this automatically. All you need to do is change the 'automaticSerialization' entry in the options array to TRUE and it's good to go.

This is slightly slower than just caching a string so you may want to check whether it is still faster than accessing the resource directly, particularly if the array is large, but I think in most instances serializing and caching will still work out faster.

Keeping with the theme of data security Stefan Esser has just made a post at the php security blog highlighting a XSS vulnerability with the adobe pdf plugin in firefox.

Although he presents instructions for how to protect yourself as a web user he does not offer any tips on how, as website developers, we can protect against our visitors data being compromised. The reason for this is simply that nothing, short of removing all pdf documents from a site, can be done to protect against this. The query string isn't transmitted to the server so we can't know that it is even present.

The only possibility is that there is some option available during the creation of a pdf document which will prevent javascript being run. I've no idea whether such a functionality exists though.

Until then though we'll have to wait for our users to update to version 8 of the plugin - a comment has been posted suggesting it is not a problem in the 8th version of the plugin.

---

It looks like our contact lists are now being handled more securely by google.

Apparently it was a problem on a few of their sites, video, groups and notebook are mentioned but solutions are now in place - though in some instances only temporary fixes until more permanent solutions come online.

This is slightly shocking, if you are logged in to google then your contact list can be harvested by any site you visit.

This makes my tutorial on getting a visitors gmail contact list where you actually have to get permission from the visitor seem somewhat redundant.

Hopefully google will fix this fairly quickly.

---

The package used a little while ago in an article explaining how to check the spam blacklists has recently been updated. Net_DNSBL 1.2.1 is now available. It looks like there haven't been any big changes but if you want the latest and greatest feel free to update.

Taking a look at the trackbacks to the package brings up an interesting article looking at doing the same thing as in my article but from the perspective of someone running their own smtp server.