Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook PHP Source Code from August 2007

gist.github.com

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Facebook PHP Source Code from August 2007

#121

Post by nwh »

encoderer wrote: post #69
nwh wrote: post #64

Earlier quoted context omitted.

That sounds grossly ineffective. Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.

Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum. If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes. Based on your comments in this thread you're out…

I still can't imagine not find an example of where anybody would want to return 500MB of results to PHP for processing.

Re: Facebook PHP Source Code from August 2007

#122

Post by eksith »

whalesalad wrote: post #120

The code looks pretty clean. I dig the two-tab spacing as well, but perhaps that was done after the fact. Anyhow, not sure if this makes any difference or not but i'm curious as to why true PHP constants are not used, and instead regular variables in all caps like $PARAM_INT are used. Anyone know why this might be? I ask because one of you PHP-gurus might inform me that there are certain use-cases where a true consta…

I'm not a PHP-guru, but it's entirely possible that they're playing around with some background configurations that would make performance tweaks in some sections of the code difficult if they're defined variables.

I guess this is an implementation of a semi-defined variable. It should probably be noted that there may be a tiny bit of performance improvement when calling isset instead of defined when checking for variable set. I'm not sure if that's one of the considerations since it would definitely be a case of premature (and ultimately pointless) optimization anywhere else, but since it's Facebook, they may have gone that far to squeeze every bit out of it they can.

Re: Facebook PHP Source Code from August 2007

#123

Post by MichaelGG »

asdasf wrote: post #113
MichaelGG wrote: post #75

Earlier quoted context omitted.

By that logic, no one runs any programming languages, since they all get translated to x64 or other instruction sets.

That makes no sense at all. The function in question sets the memory limit for the PHP interpreter. A specific piece of software. Facebook does not use that specific piece of software.

Your comment was ambiguous then. It sounded like your logic was "they don't run PHP because they wrote their own implementation"... which is still running PHP. I think you meant to say they're not running the normal PHP interpreter, so that particular functional call might not be implemented (but it could be, still...).

Re: Facebook PHP Source Code from August 2007

#124

Post by AaronIG »

nwh wrote: post #121
encoderer wrote: post #69

Earlier quoted context omitted.

Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum. If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes. Based on your comments in this thread you're out…

I still can't imagine not find an example of where anybody would want to return 500MB of results to PHP for processing.

I think Kiro meant 500, as in the HTTP status code, due to PHP running out of memory, not 500MB.

Re: Facebook PHP Source Code from August 2007

#125

Post by dools »

whalesalad wrote: post #120

The code looks pretty clean. I dig the two-tab spacing as well, but perhaps that was done after the fact. Anyhow, not sure if this makes any difference or not but i'm curious as to why true PHP constants are not used, and instead regular variables in all caps like $PARAM_INT are used. Anyone know why this might be? I ask because one of you PHP-gurus might inform me that there are certain use-cases where a true consta…

They might be simple input validation filters created using the create_function() function which allowed you to create anonymous functions of sorts in PHP prior to 5.3. You can't assign an anonymous function to a constant. An alternative would have been to include a big switch statement in the param_get_slashed() function but since the same validators are used in a bunch of places it seems cleaner to use anonymous functions and have each function that uses them loop through and call each function passing the parameter named in the array key in as an argument

Re: Facebook PHP Source Code from August 2007

#126

Post by thirdsun »

janulrich wrote: post #117
nilsjuenemann wrote: post #7

I remeber these days. I worked at this time for studiVZ - a german social network (still exist, but nobody is using it anymore) and this leaked was caused by a misconfiguration in their Apache setup. In 2008 studiVZ was sued by Facebook. They said we theft their PHP, CSS/JS "code". ( http://techcrunch.com/2008/07/18/facebook-sues-german-social... ). Indeed, the first version of studiVZ was inspired by Facebook. Our f…

Just curious, what social networks are popular in Germany now? And what led to the declining usage of studiVZ?

Both questions can be answered with Facebook. For messaging though, Whatsapp is very common here these days. I don't like the service at all, but you're almost out of the loop if you avoid it - well, at least among my friends.

Re: Facebook PHP Source Code from August 2007

#127

Post by dbloom »

micheljansen wrote: post #59
minifig wrote: post #55

Earlier quoted context omitted.

managed to save a copy of several files that appeared at the time - home.php, album, group, friends, photo, profile, readmessage ... code was an interesting read, as were the comments in it: // You fucking link h4x0rs just got pwned // Shortcut out of this CRAZY expensive garbonzle // What did we come up with? // don't display the Tuna album (aid=-1) // is this group a dummy meant to populate newsfeeds? // do not lis…

Can anyone explain the strange obsession with tuna? Even in this index.php: // make sure big tunas haven't moved around

Based on my secondhand knowledge, a "tuna" was a way to attach a wall (comments) to anything with a unique ID.

Re: Facebook PHP Source Code from August 2007

#128

Post by philfreo »

m0th87 wrote: post #34

Does anyone else remember the friend graph visualization feature facebook used to have? It was an oddity, both because it seemed like a strange but useful feature, but also because it was a perl script. One time I clicked it and got the source code to the file instead of the graph. It's somewhere on one of my hard drives, but it seems wrong to leak, especially since it has database credentials hard-coded into it.

I got the exact same thing on the graph PHP page. It had database credentials, but they we're canceled out and replaced by some other constants.

Re: Facebook PHP Source Code from August 2007

#129

Post by pestaa »

jafaku wrote: post #110
pestaa wrote: post #104

Earlier quoted context omitted.

This is exactly the problem. You do not know the message is not important. In fact, every message is important to someone.

In your first comment you implied that it was a problem with PHP. I told you they are doing it on purpose, and not because their code or language is bad, and you now agreed. So I don't know where you are trying to get with this discussion. They have to choose between maximum performance and perfect consistency. They can't have both. So what they are doing is saving money in infrastructure, and letting some messages g…

Actually the trade off is not between consistency and performance, but scalability and performance (CAP theorem). Although related, they are not the same concepts.

My opinion is that you can have both performance and consistency, and work your way toward scalability as required. I recall that Facebook has a very high server-per-engineer ratio (though I acknowledge that the user-per-engineer ratio is even higher in comparison to other startups).

I also realize it is not cost-efficient to write bugfree software, but saying they did it the other way on purpose is forgiving them too much. You never write bad software intentionally.

They didn't care, and the world should have relied and should continue to rely on better software.

Re: Facebook PHP Source Code from August 2007

#130

Post by aaron695 »

kaolinite wrote: post #51
sergiotapia wrote: post #19

Earlier quoted context omitted.

My mantra: Shipped code > Well architected incomplete features. Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.

You might ship faster but this can easily lead to poorly written, hard to maintain and insecure spaghetti code. In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.

> In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.

I think the unspoken secret here is the probability*loss for security issues is far less than the cost of missing features / delays.

Post reply on HN