Facebook is showing a real time like count on Mark Zuckerberg's status updates | Hacker News Reader

Facebook is showing a real time like count on Mark Zuckerberg's status updates

facebook.com

57 pointsschlichtm43 comments

This has worked for a while, it's just much more apparent on his posts:

https://www.facebook.com/note.php?note_id=496077348919

ahupp - That is referencing the real time comments (where comments are pushed to you without reloading the page).

This is different. Facebook is showing the actual like count change in real time. This is fantastic feedback for big brands.

You might want to check the credits at the end of the post ahupp linked to. :)

"big brands"? What brand is getting enough traffic to justify the overhead of truly realtime like updates, besides Facebook or Zuck?

Wolfram Alpha shows 9993 days.

http://www.wolframalpha.com/input/?i=May+14%2C+1984+to+today...

That's wrong if you do the math yourself. Try this: http://www.wolframalpha.com/input/?i=Sept+30%2C+1984+to+toda...

It says 9855 days, which is 365 * (2011 - 1984), which is obviously not right and missing leap years.

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.

This has to do with when you take the starting point for the day I would assume. Also, I got the number from Wolfram:

http://www.wolframalpha.com/input/?i=May+14+1984+to+Septembe...

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.

I think what he actually wanted was http://www.wolframalpha.com/input/?i=May+14+1984+plus+9999+d...

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.))

Python 2.7 shows 10,000 days.

    >>> datetime(2011, 9, 30) - datetime(1984, 5, 14)
    datetime.timedelta(10000)

Also, Ruby 1.9.2 shows 10,000 days.

    irb(main):017:0> (Time.utc(2011, 9, 30) - Time.utc(1984, 5, 14)) / 60 / 60 / 24
    => 10000.0

So does PHP!

    echo date_diff(date_create('1984-05-14'), date_create('2011-09-30'))->format('%a days');
    => 10000 days

Is this silly yet? ;)

By subtracting the day he was born you're not counting it. You're making it 'day 0'. 2 days - 0 days = 2 days.

Wolfram Alpha has a bug.

http://www.wolframalpha.com/input/?i=May+14%2C+1984 shows it being 10,000 days ago (if you view it before midnight on the 1st), but performing explicit ranges shows a different number.

If I were to say 1 day ago, I would mean yesterday, which would mean we were on day 2. Thus yesterday would have been day 10001.

It's right:

http://nerdiversary.com/1984-05-14

What units are "[specific date] to today" in? Does converting that to days take into account leap years? A more natural query:

http://www.wolframalpha.com/input/?i=days+since+May+14%2C+19...

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!

Could this be because some people (at 120,000 now) are unliking and dropping the count for a moment?

More likely a propagation/aggregation issue.

It's probably just because it's firing off a ton of ajax requests and just displaying the results as they come back, regardless of the request order.

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.

Zuck maybe wrote it himself for fun?

Stop kidding yourself.

Amused that my comment was down-voted when It's widely known that Mark would work 'hands on' on the codebase [1] as recently as last year.

[1] http://techcrunch.com/2010/04/14/apparently-mark-zuckerberg-...

http://kottke.org/11/09/zucks-gonna-write-code

This excerpted anecdote indicates it was mainly a leadership gesture to rally the troops. Still pretty cool that he'd bother, 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.

"most browsers"?

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.

I don't have a Facebook account, does it only work for logged in people?

Probably, I don't click anything with Facebook in the URL.

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.

But they won't and can't. These sorts of hyperbole are getting really old.

In 20 years, they'll have quadruple the number of people that have ever lived!

On my client if js is disabled then yes the count is "real time" otherwise nothing happens.

Seems buggy to me; it doesn't register my like and unlike very well.

cute little easter egg

way to toast yrself zuck

Reply on news.ycombinator.com