Using Google to host your jQuery (or other applicable content) has several advantages over hosting a version on your own server including better caching, decreased latency, and increased parallelism. There are plenty of other articles to discuss the merits of decreased latency benefits of a CDN or the effects of parallelism on browsers so it wont be covered here.
Perhaps the most compelling reason to use Google to host your jQuery is that your users actually may not need to download it at all. If you’re hosting jQuery locally then your users must download a copy at least once. Your users probably already have multiple identical copies of jQuery in their browsers cache from other sites, but those copies are ignored when they visit your site.
When a browser sees references to a CDN-hosted copy of jQuery it understands they all refer to exactly same file. The browser trusts that those files are identical and wont re-request the file if it’s already cached.
So, now that we know that Google is a good place to serve up our jQuery from how are we going to do it? I believe the best way is also the simplest:
<script>window.jQuery || document.write(‘<script src=”js/libs/jquery-1.7.1.min.js”><\/script>’)</script>
This will point to Google to host the jQuery library, but fall back to local hosting in the event of connectivity issues.
EMERGENCY PHP UPDATES
We will be applying a PHP update to the servers later this evening.
This will take the primary PHP install from v5.3.9 to v5.3.10 and will resolve a vulnerability that has been patched in the 5.3.10 release.
The vulnerability present in 5.3.9 allows for the possibility of remote code execution depending on how large numbers and arrays are used.
As this is a security issue we will be performing emergency maintenance between midnight and 3am (GMT).
There should be no interruption to service however, as the work is being done on components critical to PHP based sites, this period should be considered at risk.
The work will cause slightly higher than normal load on the servers and may involve a restart of the web server.
In the worst cast scenario (such as a failed compile) the installer will restore a backup of the current working configuration.
No module or configuration changes will be made to the PHP stack and scripts should notice no difference.
You can view the change log on the php.net site: http://php.net/ChangeLog-5.php
Sometimes MySQL doesn’t come up again when attempting to start MAMP, – it just hangs after starting Apache. If you don’t want to have to reboot (and shutting down and restarting MAMP hasn’t helped) then quit MAMP, open a Terminal window and type:
ps aux | grep mysql
killall -9 mysqld