Live data from Hacker News

Facebook PHP Source Code from August 2007

gist.github.com

101–110 of 154 posts

Re: Facebook PHP Source Code from August 2007

#101
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.

this was obviously computer misuse. although they didn't intend to show you, you saw the secret credentials. go straight to prison.

Re: Facebook PHP Source Code from August 2007

#103

Earlier quoted context omitted.

That approach only works in the short-term though. When you've got an already large code-base you just 'made work' but with no tests (code-coverage), how do you 'make it faster' or 'make it readable' without breaking things? Especially as you are likely under pressure to be adding new features.

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.

Re: Facebook PHP Source Code from August 2007

#104
post #91
post #30

Earlier quoted context omitted.

I must admit my comment was unneccessarily bitter, but my observation is completely different. Many friends and family members are now seeing data loss on Facebook weekly at least . I wouldn't call them tech savvy either, yet they can attribute the issue to Facebook, after having learnt the simplest basics of how the web should actually work.

That's probably by design. Would you prefer one unimportant message lost here and there, or be able to handle 1/1000 of the current traffic to make sure every single message is delivered?

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

Re: Facebook PHP Source Code from August 2007

#105
I like the variable naming in the code. It's good that they didn't use one/two letter variables that span more than five lines of code. Short, meaningless variables names--used for things other than index values is one of my big pet peeves. I had to use somebody else's code as the base for a project and it was full of two letter variables that didn't mean anything. Gave me a big headache working on it.

Re: Facebook PHP Source Code from August 2007

#106

I like the variable naming in the code. It's good that they didn't use one/two letter variables that span more than five lines of code. Short, meaningless variables names--used for things other than index values is one of my big pet peeves. I had to use somebody else's code as the base for a project and it was full of two letter variables that didn't mean anything. Gave me a big headache working on it.

Seriously, some of these variables are named so elegantly it's actually a little surprising.

Beginning developers could learn a thing or two looking over code like these (even though it's now clearly outdated and likely defunct). I've been programming for half a decade and my naming conventions are still horrid.

Re: Facebook PHP Source Code from August 2007

#107

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 can't speak to your subjective question but there's a lot of software without automated testing that people are completely capable of modifying without breaking. Ask me a real question and not one about the confidence YOU get from something and I'll see if i can't answer it.

Re: Facebook PHP Source Code from August 2007

#109
post #89

Earlier quoted context omitted.

Ship too late and none of it will matter.

I guess shipping is more important to you than the possibility of losing user details (or worse). Christ, I hope I never give my details to a company you found. Shipping quickly is important but it's also important to write quality code. Small bugs that can easily be fixed are fine but security problems or bugs related to payments, for example, are not.

How many companies have failed because of security flaws in their code?

Re: Facebook PHP Source Code from August 2007

#110
post #104
post #91

Earlier quoted context omitted.

That's probably by design. Would you prefer one unimportant message lost here and there, or be able to handle 1/1000 of the current traffic to make sure every single message is delivered?

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 get lost from time to time. Your family being a little annoyed made them money.

Also, when we say "important" in this context, is almost like asking "are you willing to pay for it?". Most people wouldn't pay a dime for ensuring the consistency of all their Facebook messages. So Facebook chose the right option.

Post reply on HN