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.
Facebook PHP Source Code from August 2007
101–110 of 154 posts
Re: Facebook PHP Source Code from August 2007
#102Re: Facebook PHP Source Code from August 2007
#103Earlier 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..
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
#104Earlier 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?
Re: Facebook PHP Source Code from August 2007
#105Re: Facebook PHP Source Code from August 2007
#106I 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.
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
#107Earlier 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.
Re: Facebook PHP Source Code from August 2007
#108Re: Facebook PHP Source Code from August 2007
#109Earlier 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.
Re: Facebook PHP Source Code from August 2007
#110Earlier 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.
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.