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

141–150 of 154 posts

Re: Facebook PHP Source Code from August 2007

#141

Post by Nitramp »

javis wrote: post #8

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

It's the exact opposite. The better code gets quality wise, the easier it gets to read and understand.

There are situations that require using somewhat surprising language features occasionally, but quality code will limit them to small areas, and document the hell out of what's going on there.

Re: Facebook PHP Source Code from August 2007

#142

Post by nikcub »

smsm42 wrote: post #98
elwell wrote: post #92

From linked article "It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue)." Does anyone know what he is referring to when he says this can happen via high load?

It is a myth. High load has nothing to do with it. However if you configure apache wrongly, it will serve .php files as text. Only connection to load is if you have one broken server among N proper ones, a number of times that the broken one is hit depends on load - I.e. on low load, it may be configured so that it is never hit at all. I guess the story about apache serving php source under high load came from the id…

this was a real issue, here is the bug:

https://bugs.php.net/bug.php?id=26810

there were many related bugs as well. it didn't get fixed for a while, and when it was fixed it was over a number of revisions and wasn't tagged.

Re: Facebook PHP Source Code from August 2007

#143

Post by nikcub »

elwell wrote: post #92

From linked article "It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue)." Does anyone know what he is referring to when he says this can happen via high load?

It was a rare bug in the 4.2.x and 4.3.x branches of the Apache module running on 2.0.x.

The real way this code was leaked was via a plain text version of the file being stored on the server that the hacker found by trying a bunch of URLs

I was speculating at the time, and had recent experience with the bug where source code would be exposed. I found out a little later how it was actually leaked, but then forgot all about it.

Re: Facebook PHP Source Code from August 2007

#144

Post by themonk »

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…

true PHP constants was a performance hit.

Re: Facebook PHP Source Code from August 2007

#145

Post by optymizer »

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…

define()'s were expensive in PHP

Re: Facebook PHP Source Code from August 2007

#146

Post by jalfresi »

benihana wrote: post #103
encoderer wrote: post #67

Earlier quoted context omitted.

By being careful? I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." It does require more time to develop and test, but then again, you're saving some time by not writing and maintaing tests. Again, I believe in automated testing because I think it hedges my risk but I'd caution against believing your own hype that there is only one way to do something..

> I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." What are some other methodologies that can let me change code with the confidence well-written tests give me? Would love to be able to employ them when automated tests aren't feasible.

I believe there is a rather apt quote by someone whose name escapes me right now (C.J.Hoare maybe?). It goes (paraphrasing): "There are two ways to write software. One is to write code that contains no obvious deficiencies, and the second is to write code that obviously contains no deficiencies. The second way is much harder"

I always took this as an argument for smaller, composable components that value simplicity over complexity, dumb over smart and composable over monolithic. I personally (not quite there yet!) try to write code in this manner. I find that the more straight forward and simple the code, the less need there is for tests because I can hold the whole of the code base in my head.

Re: Facebook PHP Source Code from August 2007

#147

Post by fingerprinter »

The comments on github are akin to 'my eyes! they bleed', but tbh, this is actually quite readable and I imagine wouldn't be all that hard to maintain.

I haven't touched PHP since about 2007 and it seems like it would be pretty easy to jump in and start making changes and edits. It is well templated, seems to use variables well and not have too many (if any, didn't look all that closely) hard-coded values. I've seen much, much worse in "cleaner" languages than this.

As a side note. I learned a lesson in my early 20s that has served me well to today.

Shipped code always wins.

I was a huge proponent (and still am) of good code, well architected blah blah blah. But, in the end, if your code never sees the light of day, it doesn't matter. I saw this when I took over a team responsible for care and feeding of a product originally written by the founder of a company. This company had just secured a series B on the original code (still). The product was ugly, the code was terrible, it was slow, it wouldn't scale, couldn't be configured and really couldn't be maintained. However, it got the company moving, got a series A & B, secured the first customer, and a second. It basically created a runway to build the thing right that wouldn't have been available had it not gone live.

Re: Facebook PHP Source Code from August 2007

#148

Post by wizzard »

asveikau wrote: post #77
TelmoMenezes wrote: post #18

Earlier quoted context omitted.

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 stud…

It's kind of funny to see two reactions here: * Reaction A: code is ugly, what a bunch of jerks! * Reaction B strikes me a bit as hero worship. Since we already know the outcomes, already some consider them geniuses; we must conclude every decision they made was a good one, and there is no room for criticism. Perhaps neither are great, but I think reaction B especially is a little dangerous. One must acknowledge that…

A false dichotomy if ever there was one. Anyone who doesn't think the code is ugly must just be blinded by hero worship?

How about the possibility that a1a is one of the people who just automatically equates "large volume of code" with "spaghetti"? In my experience there is a fair number of HN users (and devs in general) with this knee-jerk perspective.

In my very humble opinion any reasonable person who takes a few minutes to actually read through this code would never call it spaghetti. _Especially_ considering 1) the feature set of PHP at the time the code was leaked, 2) the immense scale of Facebook even at that time.

Re: Facebook PHP Source Code from August 2007

#149

Post by jafaku »

pestaa wrote: post #129
jafaku wrote: post #110

Earlier quoted context omitted.

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 co…

I know the CAP theorem, but that's not what is going on here. And now again you are saying that the data loss is a bug. It's not! Like I said, it's by design, they are probably using a fire-and-forget methodology for writing the comments. Do you seriously think there is a bug in PHP or their PHP code that is making a very little percentage of comments get lost? Besides, they have moved away from PHP long time ago for their backend. They are using a combination of Java, Scala, etc. Software that loses some data instead of crashing when under heavy load is not bad software. It has its uses, eg: massive amount (per unit of time) of unimportant messages that no one is willing to pay for.

Re: Facebook PHP Source Code from August 2007

#150

Post by [deleted] »

nikcub wrote: post #142
smsm42 wrote: post #98

Earlier quoted context omitted.

It is a myth. High load has nothing to do with it. However if you configure apache wrongly, it will serve .php files as text. Only connection to load is if you have one broken server among N proper ones, a number of times that the broken one is hit depends on load - I.e. on low load, it may be configured so that it is never hit at all. I guess the story about apache serving php source under high load came from the id…

this was a real issue, here is the bug: https://bugs.php.net/bug.php?id=26810 there were many related bugs as well. it didn't get fixed for a while, and when it was fixed it was over a number of revisions and wasn't tagged.

[deleted]
Post reply on HN