The like updates are timed improperly and the number keeps going down and then up and then down. I got a lot of shit at work for a similar bug on a JS ticker, I'm glad I'm not the only one!
Doing a little network sniffing this seems incredibly inefficient. Apparently the page is polling the server up to 8 times per second and getting back a 7-800 byte chunk of Javascript. The infrastructure to support this at Facebook's scale is mind boggling. This is the kind of stuff that Websockets was invented for.
web sockets or, in most browsers, long polling. long polling is easy to implement and they must already have the infrastructure built out since they have chat...silly Facebook.
[edit]
just took a closer look at the network activity. this really is the worst way to implement this feature. polling several times a second, sending back a bloated response, and updating much more of the DOM than necessary. this is just terribly hacky. probably done very quickly at the last minute though.
Why would he stop writing code? I can understand he might be too busy (and it might be getting too advanced?) but I code because I like it, not because it one day might allow me to make money. I do not plan on stopping whatever happens.
Because he was never a particularly talented coder, and because FB now has some top-tier talent that can do a far better job at coding that he can. Besides, contrary to popular belief, running a $100 billion company probably doesn't leave you with much time.
Not really. Between Firefox and Chrome's market share, the "right way" is far more in line with WebSockets. Facebook doesn't use WebSockets. It's not even an issue of browser support but rather the lack of proper progressive enhancement on Facebook's part. Also, sorry, but I laugh at the notion that "long polling is easy to implement". Even if it is on some level, it doesn't make the right strategies any harder (nor does it excuse the flaws or performance issues of current long-polling techniques), nor does it excuse the lack of progressive enhancement.
What's difficult about long polling? It's a solved problem. There's an abundance of battle-tested frameworks available and it's a proven technique. Also, Facebook already has the infrastructure in place - they have the expertise in-house. But even if this were a startup writing the feature from scratch it would only be slightly more complex than an async request.
Which would be 10000 days inclusive of May 14. (Wolfram says in this case that it was Sept. 29, which is correct. (ie Mark is celebrating the wrong day. But kudos to him for being aware of it in the first place. I celebrated mine July 23.))
The correct formula that Wolfram should be using here is floor((cur_yr - old_yr)x365.25), assuming you are interested only in the recent past where the 365.25 holds true.
As an aside, floor(365.25x(2011-1984))+138 gives 9,999 days elapsed which would make today the 10,000th day, as stated by Zuckerberg.
EDIT: this formula only works when you begin on a day after a leap day during a leap year, thanks hennypenny
Your formula doesn't work. There have been 7 leap days including 1984. The date of the leap day is relevant to your formula because if he were born on Jan 1 there would be a difference in your result. Also, May 14 plus 138 days would have been September 29, not Sept 30.
In the this case 'to' means 'through' and is inclusive of all the days. By adding the difference we do not twice count the number we arrived at from the first part of your calculation.
It has done the exact same thing for my friends posts for a looooong time. This isn;t specific to his account, its just more prominent because there are more people "liking" it.
If they keep adding people at the rate they are, in 10 years they'll have wired together the entire human race. I'm not sure if I should be scared or thrilled or skeptical.
https://www.facebook.com/note.php?note_id=496077348919