Facebook PHP Source Code from August 2007 • Hacker News Board

Re: Facebook PHP Source Code from August 2007

#131

Post by inaccessible » Sun, Oct 13, 2013, 9:19 AM UTC

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 think it might be because if you write something like $PARAM_INT_sometypo that variable would be undefined, and it is easy to catch. But if you are using constants PARAM_INT_typo becomes a string[1]. That way you would have to do more validation about that, too.

But without more context it's not that easy to tell.

[1]: http://us.php.net/manual/en/language.constants.syntax.php (search for "undefined constant")

Re: Facebook PHP Source Code from August 2007

#132

Post by mkohlmyr » Sun, Oct 13, 2013, 9:23 AM UTC

lmm wrote: post #109

kaolinite wrote: post #90

Earlier quoted context omitted.

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?

If your first reaction when someone talks about security flaws in payments is 'will it make my business fail' rather than 'is this going to fuck my customers' you need to re-evaluate your priorities.

Re: Facebook PHP Source Code from August 2007

#133

Post by oneeyedpigeon » Sun, Oct 13, 2013, 9:52 AM UTC

moconnor wrote: post #36

Kiro wrote: post #13

Earlier quoted context omitted.

In my experience code become unitelligable not because it's fine tuned and advanced but because it's messy and rushed.

Or over-generalized with the logic split up and hidden in the interactions between a dozen (sub)classes.

Or under-generalised with the logic duplicated in a dozen places, ever-so-slightly differently

Re: Facebook PHP Source Code from August 2007

#134

Post by pearjuice » Sun, Oct 13, 2013, 10:25 AM UTC

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.

Reads like: my dad works for Sony and I have a Playstation 5 in my possession.

Re: Facebook PHP Source Code from August 2007

#135

Post by nilsjuenemann » Sun, Oct 13, 2013, 10:47 AM UTC

hazelnut wrote: post #116

nilsjuenemann wrote: post #80

Earlier quoted context omitted.

We had to solve scaling issues most of the time. VZ was running on a multi-tier platform with services written in Java, PHP, Erlang, C++ and Python. 17 million users with around 25 billion requests per month (without static content)... Some numbers from 2010: - 60.000 req/s (without static content) - 2.5 mio. memcache ops/s - 300k queries to the database tier We've built that platform with a team of around 20-30 engi…

I think Facebook had the same problems. Maybe a bit bigger ;)

Excactly. But you can't compete if don't have enough (and the best) people and enough budget for recruiting.

Re: Facebook PHP Source Code from August 2007

#136

Post by nilsjuenemann » Sun, Oct 13, 2013, 10:55 AM UTC

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?

I think the most popular social network is Facebook. But as others said, people are looking for small services to solve a small problem.

studiVZ wasn't cool anymore. We missed the point for a rebrand to open the plattform for other people. "studi" is a abbreviation for student. Our answer was a new brand called meinVZ (just another UI, same database). Together with the ability to provide new cool features (e.g. Apps, Activity stream, i18n) it was just a question of time until FB was getting the market leadership.

Re: Facebook PHP Source Code from August 2007

#137

Post by jmadsen » Sun, Oct 13, 2013, 11:21 AM UTC

There seems to be, here & on the "interverse", a battle on whether it will be more more hip to call this spaghetti code or to call it clean code. I don't see very much debate on whether or not it is GOOD code.

It isn't good code. It is cleanly written, especially for the time. But all the noise about how bad it is isn't "hipster" talk - this is 400+ lines of completely unmaintainable code; which is why it isn't part of the current code base.

As soon as they got some money & started trying to make it do more, they wised up and dumped it

Re: Facebook PHP Source Code from August 2007

#138

Post by uhohuhhuh » Sun, Oct 13, 2013, 12:06 PM UTC

tomphoolery wrote: post #65

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.

...do the credentials still work? :)

The db was most likely never listening for connections from the world at large anyway.

Re: Facebook PHP Source Code from August 2007

#139

Post by bobbydavid » Sun, Oct 13, 2013, 12:38 PM UTC

kaolinite wrote: post #90

g8oz wrote: 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.

This is a straw man, right? Not all bugs are payment security bugs. Not all bugs are harmful to users. And spending more time writing cleaner code does not mean you'll have fewer bugs.

Re: Facebook PHP Source Code from August 2007

#140

Post by filipedeschamps » Sun, Oct 13, 2013, 1:08 PM UTC

jwdunne wrote: post #17

Hehe, these lines made me chuckle. // Holy shit, is this the cleanest fucking frontend file you've ever seen?! ubersearch($_GET, $embedded = false, $template = true); In all seriousness though, I wonder how much of this was written by Mark Zuckerberg?

I don't know why, but I always love comments more than code itself.