Month: September 2008

Joining in on the commentary

 

I think we’re very lucky that both presidential candidates have the potential to bring more intelligence to the position, and that the excitement seems to be getting more of us paying attention to what our elected officials are doing for (and against) us. I’ve certainly never been more interested in a presidential race, and access to information about candidates and issues seems better than ever.

That said, both campaigns and supporting organizations have ensured this will be another dirty race to the White House. Continue reading  

flock() blocking reads

 

(Sigh.) After applying recent upgrades to our Red Hat 5 server at work, suddenly PHP file locking blocks the script execution for exactly 30 seconds! Both a shared reading lock (LOCK_SH) and exclusive writing lock (LOCK_EX) do this. This was, shall we say, unpleasant to diagnose. Since we use Cache_Lite (which locks by default) to cache lots of stuff and sometimes in multiple layers, most of our pages suddenly took 30, 60, etc. seconds to load! Here were duration times from a test script:

  'write' => '0.00257301',
  'read' => '0.00039792',
  'write w/ exclusive lock' => '30.00274611', (file_put_contents w/ LOCK_EX)
  'fopen' => '0.00080800',
  'get shared lock' => '29.99504590', (flock w/ LOCK_SH)
  'read file' => '0.00034904',
  'close file' => '0.00005412',

Awesome. Now it is documented that flock() “will not work on NFS” (which we are on), but this has worked fine for over a year and continues to work on our unpatched server. The versions of Apache and PHP did not seem to change. Here’s how Red Hat listed them:

old: httpd-2.2.3-6.el5 new: httpd-2.2.3-11.el5_1.3
old: php-5.1.6-12.el5 new: php-5.1.6-20.el5_2.1

So… any ideas? I’ll have to turn off fileLocking in Cache_Lite to move forward, but I’d love to know what’s up. This especially troubles me because I recently added default cache locking to Minify. Locking is also the default in Zend_Cache_Backend_File, so it seems like the right thing to do.

Javascript humor

 

hasthelargehadroncolliderdestroyedtheworldyet.com has a news feed. It also has this in the source:

if (!(typeof worldHasEnded == "undefined")) {
document.write("YUP.");
} else {
document.write("NOPE.");
}

Folks without Javascript get a more definite answer:

<noscript>NOPE.</noscript>

Also appreciated:

<!-- if the lhc actually destroys the earth & this page isn't
yet updated please email mike@frantic.org to receive a full
refund -->

uTag: like snurl, but crappy!

 

A SitePoint blogger recently wrote about uTag. Like my favorite, snurl, it’s one of many make-a-shorter-link URL redirect services, but with a 90’s twist! When you click on these, instead of getting a page, you get a frameset with ads on top, broken addressbar usability, and, if you know how uTag works, the warm fuzzies that the jerk who put you through this annoyance got ad revenue while the site they deemed worth linking to doesn’t even get PageRank credit for the inbound link. The best part is that uTag encourages site owners to replace all their links with crappy uTag links, so when uTag folds your site can add to the collective link rot. Also, if more site owners do this, browsing their sites starts to look like this:

Surfing a wonderful web of uTag links

Tip: Unless you’re as established as about.com (hated for this practice), you probably can’t get away with annoying users this thoroughly.

Site owners, it may be time to dust off this snippet:

if (top !== self) top.location.replace(document.location.href);

Case of the NS_ERROR_DOM_SECURITY_ERR

 

Working on a bookmarklet, I ran across “security errors” in Firefox and Opera (may happen in others, I didn’t check). In Firefox the code threw “Security error (NS_ERROR_DOM_SECURITY_ERR)” and in Opera it was something similarly vague.

The culprit code was trying to access the cssRules property of a style sheet from a different domain (my CSS is on a subdomain). It appears browsers apply the same origin policy to the DOM CSSStyleSheet interface. Effectively, you can access the href property of a different domain styleSheet object, but not its cssRules. In Firebug, the cssRules property will be null, but attempting to even read it in user script causes the exception.

If your script is throwing NS_ERROR_DOM_SECURITY_ERR, check for code trying to access objects on a different domain.