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.
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.
# this is needed so that we can still access the original ActiveSupport version of JSON encoding | |
# JSON gem is faster but does not support automatic unicode conversion for < and >, which can cause | |
# problems for </script> in JSON output (browser interprets as exiting the script area, and results in XSS exploit) | |
# | |
# e.g. EscapableJsonString.new('<no_xss>').to_json | |
# => "\u003Cno_xss\u003E" | |
# | |
class EscapableJsonString < String | |
def to_json(options = nil) #:nodoc: | |
json = '"' + gsub(ActiveSupport::JSON::Encoding.escape_regex) { |s| | |
ActiveSupport::JSON::Encoding::ESCAPED_CHARS[s] | |
} | |
json.force_encoding('ascii-8bit') if respond_to?(:force_encoding) | |
json.gsub(/([\xC0-\xDF][\x80-\xBF]| | |
[\xE0-\xEF][\x80-\xBF]{2}| | |
[\xF0-\xF7][\x80-\xBF]{3})+/nx) { |s| | |
s.unpack("U*").pack("n*").unpack("H*")[0].gsub(/.{4}/, '\\\\u\&') | |
} + '"' | |
end | |
end |
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.