Axon Flux // A Ruby on Rails Blog

Cross-domain policy files (crossdomain.xml) are forgivingly parsed by Flash. If an attacker can construct an HTTP request that results in the server sending back a policy file, then Flash will accept the policy file. For instance, imagine a university website that responds to a course listing request:

http://www.example.com/CourseListing?format=js&callback=<cross-domain-policy><allow-access-from%20domain="*"/></cross-domain-policy>

...with the following output:

<cross-domain-policy><allow-access-from%20domain="*"/></cross-domain-policy>() {  return {name:”English101”, desc:”Read Books”}, {name:”Computers101”, desc:”play on computers”}};

Then one could load this policy via the following ActionScript? code:

System.security.loadPolicyFile("http://www.university.edu/CourseListing?format=json&callback=<cross-domain-policy>" + "<allow-access-from%20domain=\"*\"/></cross-domain-policy>”);

This results in the Flash application having complete cross-domain access to www.example.com.

Resque is our Redis-backed library for creating background jobs, placing those jobs on multiple queues, and processing them later.

Background jobs can be any Ruby class or module that responds to perform. Your existing classes can easily be converted to background jobs or you can create new classes specifically to do work. Or, you can do both.

This goes into great detail into the tradeoffs and problems with existing delayed job queueing systems. Brett was mentioning -- this post reads like a laundry list of stuff we've dealt with!

Resque is a Delayed-Job-like queue that is built on Redis instead of MySQL. Brilliant.

XML is like violence - if it doesn’t solve your problems, you are not using enough of it.

Heh, I guess a lot of things are like violence.

As of this writing, Internet Explorer holds about a 65% market share combined across all their currently used browsers.

Finally a pretty good resource on all CSS bugs on IE.

If I ruled the world, IE would not be used by people. Since that is not the case, we need to put these rules to memory.

Facebook takes a Pull on Demand approach. To recreate a page or a display fragment they run the complete query. To find out if one of your friends has added a new favorite band Facebook actually queries all your friends to find what's new. They can get away with this but because of their awesome infrastructure.  

But if you've ever wondered why Facebook has a 5,000 user limit on the number of friends, this is why. At a certain point it's hard to make Pull on Demand scale.

Another approach to find out what's new is the Push on Change model. In this model when a user makes a change it is pushed out to all the relevant users and the changes (in some form) are stored with each user. So when a user want to view their updates all they need to access is their own account data. There's no need to poll all their friends for changes.

Really interesting article at High Scalability on ways to approach scaling your data store.

We use push on change as well, particularly for your reading list subscriptions. To be honest, it's cheaper. You use disk space to pre-compute things that would be expensive to ask the database repeatedly. It allows you to just add disk -- even though disk is orders of magnitudes slower than RAM.

The Facebook approach is *really hard* to get right. It's costly because so much info just has to live in RAM, and could be one reason why it's much harder for Facebook to reach profitability than most other sites. If you have to add RAM to keep all user data in cache, that's a lot of hardware to keep going.

But when it comes to realtime, Facebook is as realtime as they come. They are some real engineering badasses.

Tracking my ranking over the past year [Pro Javascript Techniques] been consistently in the 10-20,000 range, with occasional dips into the < 10,000 range. JavaScript: The Definitive Guide is always < 5,000 (for comparison).

Really? That is some really really weak sauce. Pro Javascript Techniques rocks. It's a great book, and totally useful.

Javascript: The Definitive Guide, on the other hand, is a piece of turd. It routinely assumes you *already know* javascript and its prose is almost unreadable.

I wonder why Resig's awesome book is completely dominated by sales of the abysmal O'Reilly book. Probably for two reasons: a) the title (one is way more universal and likely to be bought by aspirational JS developers) and b) O'Reilly doesn't usually put out crap, so its very surprising when it does.

Rave: A Google Wave robot client framework for Ruby
There are several parallel efforts to create a Ruby implementation of the robot API. The rest of this post is going to focus on Rave, but I just wanted to link to the other implementations that I'm aware of:

• Sam Ruby's Wave Robot Ruby Client
• Jack Danger's Wave
• Mike Sofaer's Wave Robot Sinatra Template