This is definitely in the CakePHP docs, but my random Googling of different terms didn’t turn it up, so I’m adding it here with a few keywords just in case it helps anybody else.

The CakePHP equivalent of Ruby on Rails’ created_at is created. The equivalent to modified_at is modified. Columns with either of those names will be updated automatically when a record is created and/or modified.

I tried stuff like “magic update columns,” “CakePHP created_at,” and “CakePHP created_at autofill” before I finally found this blog post and this CakePHP doc.

Hopefully, including some extra search terms around this content will give someone else out there a hand.

Just found a fantastic crash bug in the FireFox 2.0 line (I’m using 2.0.0.16 and it’s there). It seems to be fixed completely in FireFox 3.0 and up.

Basically, using Flash’s ExternalInterface to call a JavaScript function that removes the swf element from the DOM and also tries to set style properties on the element containing the swf is subject to timing issues (a race condition, really) that can cause a total browser crash. It seems to work this way: if the function called by external interface results in removing the swf before the calling function can execute all code inside it, the browser will bail out. (I’m not 100% sure if that’s the exact cause, but it seems to be supported by what testing I could do.)

How is this a problem? I was running a few animations that would call back a couple of times to closures inside them. If those closed functions wouldn’t have time to run before the swf was stripped out, things would explode. The solution: my final animation calls back and removes the swf; this seems to solve the problem entirely (as does removing the swf after a nice long callback that would ensure all the closure code completes). Perhaps this is a crazy bug that only shows up in this situation, with timing and closures? Like ExternalInterface needs all closures/JavaScript to execute before it can “safely” exit itself?

Very weird, but seems to be solved in later versions of Firefox. (By the way, I’m running Flash 9 and a swf that demands Flash 9, so it’s still a recent concern for newer versions of Flash.)

(Here’s a similar situation that got me in the right direction.

Tags: javascript, flash, external interface

The tradition of placing small, useful services on App Engine continues. This time, Adam Burmister has created img2json, a Google AppEngine service that extracts metadata from image URLs.The metadata can be as simple as width, height, mime type, file size, but it also extract EXIF metadata (camera make, manufacturer, GPS positioning, orientation, etc).

Ajaxian » img2json: get your image metadata via App Engine

Hmmm…using a web service vs. using a JavaScript-based, in-client approach. The webservice seems to be really fast and its based on Google’s distributed (?) app engine. I wonder if feeding this an asset that’s sitting on a content delivery network (Akamai, etc.) would combine with the Google’s App Engine speed to balance off loading that extra script? You’d still ostensibly need the same callback function.

Since you’re using a plain, old URL could you stuff the request URL in an img tag’s src attribute, then use the callback to do a quick swap once it loads? If so, that’s pretty darn effective. (I’d test it, but I’m lazy and kind of sure you’d see a broken image for a bit before it swaps in the good image; however, you could always set this up on a set of positioned or not-displayed images and achieve the same effect. I’m worried this would smack into the same origin policy and don’t want to do this on the server since it could be a blocking performance bottleneck.)

Nice to see App Engine paving the way for utility apps!

Tags: exif, images, javascript

A timeline showing Internet memes through the years. Please get your Lolcats out of my Katz. I’d like to see when the term "meme" first came into use to describe these things. Where in the heck is Real Ultimate Power???

Tags: memes