I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
Facebook PHP Source Code from August 2007
11–20 of 154 posts
Re: Facebook PHP Source Code from August 2007
#12I really hope they cleaned that mess up or I feel very sorry for all the developers at Facebook. >ini_set('memory_limit', '100M'); // to be safe we are increasing the memory limit for search >tpl_set('simple_orientation_first_login', $get_o); // unused right now >// We special case the network not recognized error here, because affil_retval_msg is retarded. >all those undocumented(?) random error codes >mix between t…
What's wrong with increasing the memory limit?
A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)
Re: Facebook PHP Source Code from August 2007
#13When I see code like this, I'm always amazed that I can actually read it and (kinda) understand what it's doing. I always expect code like Facebook's to be so finely tuned and advanced that it'd be completely uninteligable to those outside the company and not an expert in the language.
In my experience code become unitelligable not because it's fine tuned and advanced but because it's messy and rushed.
Re: Facebook PHP Source Code from August 2007
#14Earlier quoted context omitted.
What's wrong with increasing the memory limit?
A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)
It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?
Re: Facebook PHP Source Code from August 2007
#15Earlier quoted context omitted.
What's wrong with increasing the memory limit?
A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)
It would seem that Facebook has been able to scale. Perhaps this line of code worked for them in 2007, and they changed it only when it started to be a problem.
Re: Facebook PHP Source Code from August 2007
#16I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
... unless your users actually care about messages being delivered, whatever being reported as saved being truly saved, et cetera...
There is a whole world out there where people want to rely on software to do what it says it does. I know Facebook can live in its own bubble and get away with every possible stupid bug a messy PHP spaghetti causes.
Re: Facebook PHP Source Code from August 2007
#17Hehe, these lines made me chuckle.
// Holy shit, is this the cleanest fucking frontend file you've ever seen?!
ubersearch($_GET, $embedded = false, $template = true);
Re: Facebook PHP Source Code from August 2007
#18I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
This piece of code is doing something very simple and sequential in nature: putting together the (then) Facebook front page. I'm not sure I agree it's spaghetti. Are there any complex relationships that become hard to follow because of an inadequate level of abstraction? It doesn't look that way to me.
Many programming methodologies are proposed these days, but the entire "field" smells of pseudo-science. Unless studies are done that can show statistically significant differences in relevant metrics (defect density, time required to add a feature, etc.), it's just a matter of opinion.
Re: Facebook PHP Source Code from August 2007
#19I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
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.
Re: Facebook PHP Source Code from August 2007
#20I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
... unless your users actually care about messages being delivered, whatever being reported as saved being truly saved, et cetera... There is a whole world out there where people want to rely on software to do what it says it does. I know Facebook can live in its own bubble and get away with every possible stupid bug a messy PHP spaghetti causes.
I remember listening to an interview with Markus from Plenty of Fish, where he essentially said that he didn't worry too much about site errors because most unsophisticated users would attribute them to things like their ISP, browser (if they knew what that was), or their own error more often than to the site itself.
Personally, I can't bring myself to not care like that, but it seems to have worked pretty well in the early days of many now-popular sites. Especially in 2007, when Facebook was still in real competition with MySpace, moving as quickly as possible was probably much more important than a few messages dropping through the cracks.