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

51–60 of 154 posts

Re: Facebook PHP Source Code from August 2007

#51

Post by kaolinite »

sergiotapia wrote: post #19
a1a wrote: post #11

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.

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.

You might ship faster but this can easily lead to poorly written, hard to maintain and insecure spaghetti code. In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.

Re: Facebook PHP Source Code from August 2007

#52

Post by sebcat »

Keyframe wrote: post #40
sergiotapia wrote: post #19

Earlier quoted context omitted.

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.

Shipped code > Well architected incomplete features. Actually there is more wisdom hidden in this dogma. I'd argue you can't really well architect anything without iterating running code. So, it's more of a cycle. At least in my case. Proto, use, profile, refactor, proto new stuff into it, use, profile, refactor...

This cycle usually ends too early though, sometimes at the first iteration, and the code will be pushed to production. Usually the spec is lacking and the customer (internal or external) doesn't really know what he wants. After that, feature requests and bug fix hacks will deteriorate the condition of the code base to the point where things break if you look at it. Rewriting will be difficult because instead of formalising the requirements in a specification, with all the hacks and features added the existing code base is the spec. So you end up with something very fragile and not so agile. At the bottom lies a first iteration model which the original developer (who left the company a couple of years ago), have been given some time to reflect on things, now knows to be a model which can't possibly scale.

Sometimes (not always), it's best to release when ready. Shipping is important for a company, but for a dev team/individual it should be further down on the list and more importantly, development is not done after the first release and features don't maintain themselves.

I don't like the whole 'ship as soon as possible'-thing.

Re: Facebook PHP Source Code from August 2007

#54

Post by Blahah »

lelf wrote: post #31
Blahah wrote: post #25

Earlier quoted context omitted.

Yeah, and because the code is completely undocumented and obfuscated it's taking us biologists a few hundred thousand man-years to figure out what the hell it means. The only time spaghetti is a good thing is when it's covered in sauce.

It'd be somewhat weird to stumble across comments in that code. // TODO:

I quite often see words (or nearly-words) in protein sequences.

The best I've seen are (when reading DNA translated in all frames):

EVQLVE

LAMARCK

ELVISISGAY

SALTYSATAN

Re: Facebook PHP Source Code from August 2007

#55

Post by minifig »

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.

managed to save a copy of several files that appeared at the time - home.php, album, group, friends, photo, profile, readmessage ... code was an interesting read, as were the comments in it: // You fucking link h4x0rs just got pwned // Shortcut out of this CRAZY expensive garbonzle // What did we come up with? // don't display the Tuna album (aid=-1) // is this group a dummy meant to populate newsfeeds? // do not list the creator as harvard // keep track of tuna contexts // Merman's Admin profile always links to the Merman's profile

// NOTE: ok, at this point we know we are going to display the full // page, so it is time to do a PHATTY PHATTY MULTIGET of all the shit that // we are going to need to make this page, or at least the most common things

// Clear fire if desired

Re: Facebook PHP Source Code from August 2007

#56

Post by jonknee »

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?

With the header "@author Mark Slee" on that file, I doubt much if any.

Re: Facebook PHP Source Code from August 2007

#57

Post by robryan »

nwh wrote: post #33
Kiro wrote: post #14

Earlier quoted context omitted.

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?

I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?

They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.

Re: Facebook PHP Source Code from August 2007

#58

Post by Kiro »

blowski wrote: post #15
iand wrote: post #12

Earlier quoted context omitted.

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.

It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.

Re: Facebook PHP Source Code from August 2007

#59

Post by micheljansen »

minifig wrote: post #55
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.

managed to save a copy of several files that appeared at the time - home.php, album, group, friends, photo, profile, readmessage ... code was an interesting read, as were the comments in it: // You fucking link h4x0rs just got pwned // Shortcut out of this CRAZY expensive garbonzle // What did we come up with? // don't display the Tuna album (aid=-1) // is this group a dummy meant to populate newsfeeds? // do not lis…

Can anyone explain the strange obsession with tuna? Even in this index.php:

    // make sure big tunas haven't moved around

Re: Facebook PHP Source Code from August 2007

#60

Post by lifeformed »

How did someone "expose the PHP source code"? Did they actually find a way to make the code show up client-side, or was it just someone who managed to get access to the backend stuff? The way it's worded makes it sound like the former, but that seems unlikely...
Post reply on HN