[ Music ] >> So I am the cloud. [ Music ] >> What's with the giant pumpkin? [ Music ] >> So two guesses as to who made that? This is CS 50, the start of week ten. And that is indeed just one of the seminars on the horizon. For those of you after final projects who would like to continue on with your final projects or some other idea all together, know that this hack Harvard group started last year is available to you. If you go to hackharvard.org/app, you will be presented with an opportunity, potentially, to come back a little early over J term and work with friends or fellow-minded students on your own entrepreneurialship activity. We, quote unquote, are a hub of tech entrepreneurs on campus with a mini incubator during optional winter activities week, January 13 to 22. We offer everything the aspiring entrepreneur or hacker needs to build cool projects. If you would like to join and apply to that group head to that URL there. So this week is ultimately about CS 50 shuttle, and I dare say one of the most exciting aspects of this week is that it's your last set of CS 50 Problem Sets ever. We like to think it's also fun. You will recall perhaps from Week Zero that in Problem Set 8 you have the ability to start driving around campus picking up teaching fellows, CA's, and a few Easter eggs along the way. Where did he go? Well, and when you come up close to one of the staff members can you click this pick up button at top left or drop them off at their appropriate house, and there's also opportunities to build in some Easter eggs of your own. For instance, those of you who grew up playing Nintendo might recall the Kunami code. Up, up, down, down, left, right, left, right, B A. If you actually type that into the staff solution, you will also acquire the ability to fly. So there you have it. CS 50 shuttle, framework for which we provide you with, and you then begin to fill in some blanks. So without further ado, today is about introducing the concepts and the techniques with which you can start implementing this as well as your own final projects. And thus enters into the picture JavaScript. So JavaScript is a programming language like C, like PHP, but unlike those languages it is executed entirely client-side, generally within a browser, although these days server-side options do exist. And like PHP, it's not compiled. So there's no process of running GSS or particular with JavaScript. Rather, you write JavaScript code, you store it inside of your HTML files or PHP files or in separate dot J S files. And then when the browser downloads that JavaScript code it executes it. So the CS 50 shuttle implementation is an amalgam of a plug in that you did have to download separately or will from Google earth. But also the Google maps API, application programming interface, as well as just some HTML and JavaScript and CS S that we wrote, and we wired, so to speak, all of these various tools together so that you ultimately can focus on the logic and on the usage of these tools to make something much more interesting than just Google Earth or just Google Maps Standing unto itself. So a few background details. You recall we talked about some of these status codes, 401, 403, 404, 500. Generally, these are bad things. If you are seeing this when working on some project of yours you murder in the second degreed up somewhere. Or if you're on a web and you come across a 404, it means someone else has messed up. And just to be clear, where these messages are being communicated, notice that we can simulate this as follows. We'll see how far we get by being on auto pilot there. Another feature of the staff implementation. Let me go over to my terminal window inside of the appliance. I'll just inside of public HTML. And let me go ahead and run -- I'm just going to create a file. And you can create files with the command touch foo dot HTML. And if I now do L S dash L, notice that I have already screwed up. Even though my other files in this directory are [Inaudible] correctly, foo dot HTML is only readable by me. And that is a problem if I want it to be accessible via browser. So sure enough, if I go over to a browser, I reload, I can see it in my directory. Because at this point in the story my public HTML, I've actually given readability and executability permissions to which command But if I click foo dot HTML you see the familiar forbidden message. And if you really look close in the title bar you'll see that 403 forbidden does somehow indeed relate to command. But because we're now looking underneath the hood, let me also click on Firebug. Recall that's the free plug in, at top right. Let me go ahead and click here and reload. But with Firebug's net tab selected. So in the past when we played with HTML, you might have played with others, but notice that these other several tabs including console and net and more are all quite helpful. And you can see in red here that we tried to get foo dot HTML. But it just didn't work. In fact, if I click on that I can see a nice user-friendly, nice bold-faced in gray scale version of the headers. But if I click view source over here, this shows me the actual HTTP headers that were sent. Whereas 200, where we said was good, 403 are almost anything other than 200 is bad. And this is how web sites are communicating that information, okay? Safari is getting lonely. So let's go back to safari. And time it up. So that's a feature, too, of the staff's implementation. So this is just to point out that underneath all of your typical web usage there's some additional somewhat arcane information that we programatically are now going to have more control over with this language called JavaScript. All right, so without further ado, this is where you can learn about JavaScript. This is actually a really nice tutorial, but this, like PHP, is going to be a bootstrapping process, where today and in yesterday's walk through and this week's sections we'll introduce you to the fundamentals, some of the concepts and the like. But ultimately, it will be up to you with the P sets and with your final project to explore further. And this is one particular language guide that points out JavaScript is actually pretty familiar. So just as with C and with PHP, we have functions. But with PHP you don't strictly need a main function any more. If you want to start writing code all you'll need, we'll see, is an HTML code called script. So main won't be necessary, but functions will still be at our disposal. We'll see that conditions, syntactically, look again exactly like this. This was pseudo code from week one. We stole it two weeks ago for PHP. It's exactly the same in JavaScript for conditions, for boolean expressions, for switches, for loops, for while loops, for do while loops, and yet more. So we only start to see some differences with JavaScript as follows. But variables have a slightly different syntax. You do not specify their type, just like in PHP. But unlike PHP there's no dollar sign any more. So it's actually a little more succinct. But you do need to say in JavaScript, generally var, for variable. So this one line of code means give me a variable S and assign it a value of quote unquote, hello world. Because it is quoted in this way this will be an implicit data type of string, so Java script does have data types of sorts, but you don't need to explicitly mention them. So here we have a variable S as we've had many times before. Now arrays. And this is where JavaScript gets interesting, and frankly powerful and convenient, because syntactically it makes a lot of things easier. If we want an array called numbers, I just say var numbers, I don't specify in advance that it's an array, but rather I determine as much by assigning it an actual array. And in JavaScript if you want an array, in this case, of integers, all you need to do is open square bracket, close square bracket, and then a comma separated list of the numbers that you actually want to store in this array. You don't have to preordain its size, you don't have to call mal loc, you don't even have to call PHP's array function. If you want an array you can simply use the square bracket notation, and viola, you're on your way. Moreover, arrays in JavaScript are generally what we call vectors. They're not arrays in the C sense, they're more arrays in the PHP sense in that they can be resized. You can add more things to them, you can subtract things from them, and there's none of this headache of malloc and realloc and the like. The size, the length of an array will grow dynamically. And then we have some new constructs too. So recall that in PHP we introduced a for each construct, which you might have found or may find useful. In JavaScript there's something similar, it's the four element in array syntax. So if you've got an array called array, and you want to have a temporary variable called element or foo or bar or whatever, you simply say for, and then in parenthesis, local variable in array's name. And that will in every iteration just as in PHP's for each construct, update on each iteration on element to be the next thing in that array. That's just a handy and popular construct. But perhaps by far the most powerful or most frequently used feature of JavaScript these days is its notation for objects. So indeed, this technology we'll start talking about today called Ajax has really been popularized through the use of something called JavaScript Object Notation. Otherwise known as JSON. And this simply a syntax whereby you can declare an object with the simplest of characters. If you want an object, think back to C, an struct, and you want that structure to have three fields. Let's call it ID, and house, and name. All you have to do is open this object with a curly brace, close it a curly brace and semicolon, I and then inside of it you can have as many key value pairs as you want, all separated by commas. Where the key is to the left of the colon and the value is to the right of the colon. So again, think back to our declaration of student with a type def and an struct way back in C. Well, this is the exact same idea. But if you want it to be declared it's as simple as saying give me an object, call it student, and inside of it here are going to be these three key value pairs. To be clear, what is an object? Well an object in JavaScript will eventually take on even more meaning than we'll look at today, in that it can have functions inside of it and the like. JavaScript is an object-oriented programming language, even though it doesn't have something called classes, which some of you might be familiar. But this here allows us to encapsulate inside of some big variable multiple data fields. And so in this way are we going to be able to format data and exchange data, especially over the Internet, particularly easily. For instance, this is just one student object. It's not all that interesting in a vacuum, but if you actually wanted to have an array of students, we might say var students equals, and then open square bracket, because recall back to notes here comes an array. At the bottom we have another close square brackets, so that's the end of the array. And then inside of it, again, as promised, we have a comma separated list of something. But in this case the something is an actual object. So the curly brace means here comes an object, key value, key value, key value, and then the same thing here for Tommy. And so now we have this very clean syntax, arguably, for bundling up lots of information, still semantically tagging it so I'm not just sending the number 123 Matherhouse, David, Mallon but rather I'm associating some meta data with it, these keys that just tell me, the receiver, what these pieces of data actually are. And notice too, I don't have to mention any type of data type here. These are very, very generic objects. Notice there's no mention of student with a capital S. No mention of an actual struct name or type def or object. Rather, these are really generic objects. So for better or for worse, JavaScript's notation allows us to very easily bundle up together lots of pieces of data like this. But once we now have these basics it's more fun and it's more compelling to actually now start using these basic new syntactic features and this client-side language like JavaScript. So without further ado, let me go ahead and open up, let's say this past example here. This was a very, very simple snippet of HTML from a while back. And it was nice just because it had some basic building blocks, an HTML head, a title, a body, and then two tags inside of it, one of which had an attribute. And recall that we drew this thing with a picture like this. And what did we call this tree-like structure? Anyone recall? Yeah, DOM, I heard someone [Inaudible] so DOM, Document Object Model. And that's just a fancy way of saying that if you were a computer or a browser reading this HTML from a text file into RAM, how might you represent it? Well, you could just represent it as a huge string. But if you actually want to do interesting things with this web page and manipulate parts of it, add content, subtract content, well, you would instead want to be able to traverse it hierarchically like this picture here suggests. So this is what really happens. When you download a web page with a browser and it contains HTML like this, one of the first things the browser does is parse it. It analyzes that HTML code top to bottom, left to right. And every time it sees a tag it creates what we'll called a node, one of these rectangles on the screen here. And every time it encounters another open tag inside of an already open tag it assumes that that new node or new rectangle is a child or some kind of descendant of the previously open tag. So in short, with the right logic and with the right code can you read this file top to bottom, left to right, and just call the equivalent of malloc, malloc, and wire these things together much like you did in P set 6, a hash table, or tree, or a try, or any of these data structures that were somehow interesting in memory. So what's neat about JavaScript is you have the ability now programatically to change what was sent to the user. So even though you might send them that HTML, you can keep sending them more HTML, or you can keep sending them -- we'll say JSON data, and add more and more content to the screen, or even remove it. Case in point, Facebook, right? Now with the wall -- with the news feed on the front page you can constantly see new status updates. You don't even have to click anything, it will just tell you when status updates. And you don't have to click anything, it will just tell you when new status updates are available in a little pop up in one of the corners of the screen. Well, how is that? Well obviously Facebook can't foretell the future. When you download the homepage for the first time at like, 12 o'clock, well, they don't know what new status updates are going to come, and they don't want you sort of 1990's style to have to reload the whole page. And so they push additional updates to you in some manner. So they send you more HTML, or more JSON type data, so their own JavaScript that came with the original web page can read it from the Internet and then insert it more into the web page. And I would be remiss if I didn't mention that Mark Zuckerberg is indeed at MIT right now, not at CS 50. But we will be joined today by Jocelyn Goldfine to the end of class who is Facebook's director of engineering. So these references to Facebook right offer some interesting opportunities for how the real Facebook actually works rather than my own made-up stories about how it might work. So more from Jocelyn in a bit. But for now let's actually transition here and start using JavaScript in some way. But let me point out one thing, so think way back to week 0. We had the notion of events in scratch, and you could broadcast an event, and then you could wait for an event. And we had that very simple Marco Polo example way back when, in week 0, where when you hit the space bar Marco would say his name and broadcast an event, and the girl that was also a separate sprite would wait for that event. Upon receiving that event she would then say polo. So events were this way of having two different programs or two different sprites, in that case, community. Well similarly, as web programming, asynchronous. You have lots going on, on modern web pages, and you don't necessarily want to wait for the user's input for something to happen or something to change, you the web site might want to push more data to the server and say here's a status update, or Gmail, here's a new e-mail that you have. And so you have in HTML associated with all of these elements we've been using thus far. Anchor tags and div and paragraphs and inputs and select menus. You actually have a whole suite of events that can be triggered. And this is a non-exhaustive list, but some of the most common ones. And most of them kind of are self-explanatory. For instance, on mouse over is an event that is triggered on any HTML tag when you so much as hover your mouse cursor over that element. Now typically, if you just wave your mouse over a div or over a paragraph of text on a web page that you made for say, P set 7, nothing happens. But with JavaScript can you tell the browser I would like to listen for this mouse over event. And you might recall on many web sites, any time you hover over some text or graphic, what sometimes happens? Before you actually click. Right, something changes, right? It might become highlighted, it might change to another graphic, it might become bold, something might change. And that's because of JavaScript, typically. CSS can work some of these tricks these days too, but with JavaScript you can do anything, because you can detect the fact that the mouse is now over some elements in the page, some div or some paragraph, or some button. And you can do something. And you can even then detect when the mouse is out of the range of that tag. So you can have things become big and then small or black and then white, or any kinds of changes you might want to have happen. You can listen to key strokes, on key down, on key up, on key press, these are actually used by CS 50 shuttle, so when you do hit the arrow keys or the U or the A or the like, we, the JavaScript code in that implementation are listening for those events. And when we hear you pushing the up arrow, just like in scratch, we do something. We move the camera or we move the shuttle, in that case. And there's yet others on submit, on select, on resize, on click, and so forth. This means that we can listen for all of this. So let me go into the appliance here and open up G edit with a file called form 1 dot HTML. And this is going to be a very simple form that submits only to a file called dump dot PHP, which does nothing interesting. I just wanted a page to which I could submit all these forms that would just show me what fields had been submitted. So it's not really a dynamic web site, it's just some diagnostic output. So let me go ahead and look at what this thing looks like. If I go into form 1, dot HTML. We will see a little form like this. So pretty typical, e-mail field, password, again password, and then I need to somehow agree to these Terms and Conditions. Unfortunately, if I submit this form right now nothing actually happens in a good way. Because it does submit the form, it submits no values for those three fields, it doesn't even send the check box field because it wasn't checked. And so what could I do? Just like with the from my "am" examples last week, I could yell at the user, right? This PHP file could notice this field equals, equals, the empty string. This field also equals, equals, the empty string, quote unquote. So let's yell at the user in red. But JavaScript is nicer because we can detect this even before you click submit. And this is increasingly compelling, because you don't want to have to submit. Maybe wait a second or two while your slow laptop or slow internet connection actually sends the form to the server, only then to be told, sorry, you screwed up, try again, it would be much nicer if we could instantaneously tell the user, wait a minute, you forget to do something important. So you can add a bit of client-side validation. In version two of the form, let me try that same thing where I submit a blank form. And notice the web site's yelling at me. It's sort of using a very coarse trick using an alert menu, as it's called. But it's now at least preventing me from submitting the form and it's explaining why. So I click okay. And notice, I did not end up at dump dot PHP. I'm still at the original URL. So it seems like when JavaScript you can listen for an event like on submit. And if you decide wait a minute, I don't want to submit because you have not figured out -- you have not inputted everything I want, you can short circuit that connection. And increasingly these days, you have android phones, windows phones, iPhones and the like, these are not the fastest internet connections, especially when you're on 3 G or similar. So the avoidance of this round-trip time that could be 2, 3, maybe even 5 or more seconds is increasingly compelling to try to do it all on the client side. To speed up the user's experience. So let's see how this is actually working. In form 2 dot HTML we'll see the same HTML as was in the other form. So let's just look at this version, because it's identical -- almost identical to B 4. And now notice we have a body tag, we have a form tag whose action is as promised dump dot PHP. We're just using get, because it doesn't really matter for this. But notice I've given this form a name. So that's a little new. So name equals quote unquote registration. Because this is a registration form. Does the notice this too, another HTML attribute. On submit equals, quote unquote, return validate. So we seem now to be calling code inside of an attribute's value inside of HTML. And we'll see that there are actually cleaner ways to do this, and we'll get there, but for now this seems to be saying call a function called validate with no arguments, and then return its value. And then what HTML is designed to do, if this function validate returns false, what's going to happen? The form will not, in fact, get submitted. Only if that function runs true will the form proceed to go to the server. Now the rest of this is old hat now. So we've got an e-mail field, which is type text, password field, which is type password, another one for password, and then an input type equals check box. So everything else is the same, but I do have a submit button. So indeed when the user hits enter or clicks that button, that function validate is going to get called. Well, if we scroll up notice that we introduced a new feature into the head of this web page. Inside of the head, usually; not only the title -- is the title tag, but now we also have a script tag. And the default language these days is assumed to be JavaScript, although back in the day others were sometimes used, but for now this is pretty much the de facto standard. And inside of this script tag we actually have programming code, not C, not PHP, not HTML, this is now JavaScript. And this is more verbose than we're going to need to be, ultimately, but let's see what this function does. So just as in PHP you must literally say function and then the name of the function. And it takes no arguments in this case. Then we have the promised syntax of if conditions, which look pretty much the same. But this is a little new. So it turns out that per this picture here, whereby you have a so-called document node at the very top, sort of the grand parent of this whole tree structure -- similarly in JavaScript, you have access to a special global variable called document. And it's specifically an object. Which means inside of document are a whole bunch of key value pairs. For now, you can simplify this. Inside of the document object is another object called forms. And this forms object is just an obtaining any of the HTML forms that are in this web page. There might be 0, there might be 1, in this case there's 1. And if you then go dot registration, this means give me the form whose name is registration in this particular web page, and then you can kind of continue the logic fair intuitively. Dot e-mail means get me the e-mail field in that form called registration in this web page, and then lastly, because the e-mail field is really referring to an input element we really care about its value. So value equals quote unquote something. So we say dot value. And finally, after traversing this very long hierarchy of objects, but arguably intuitive hierarchy, we're checking does that value equal, equal the empty string, because if so we want to yell at the user. So a very simple way of yelling at the user, even though it's not the prettiest way, because different browsers create different aesthetic windows, alert literally just alerts the user with a modal window, which means you can't do anything until you click okay in this window, and I'm returning false, moreover, to make sure not only if I yelling at the user, I'm short circuiting the form submission. Now the rest of these are somewhat intuitive based on that explanation. So even though the syntax is again a little verbose, document dot forms dot registration dot password one, this was the first of my password fields, dot value equals quote unquote nothing. I'm going to yell at them for not providing a password. But just like most web sites, if the user screwed up their password a second time and I did not type the same value for password 1 as I did for password 2, I'm going to yell at them again, but slightly differently. You must provide the same password twice. So again, this is just basic logic now that we might have used in C a few weeks back. But notice the difference, in PHP if we want to compare strings we do not need to jump through the strings of something like stir comp. Where recall we had to avoid this issue of pointers in C and comparing pointers instead of strings, very nicely in PHP and JavaScript and in a lot of these so-called higher level languages when you say equals equals, then you're comparing strings, that's going to do a literal string comparison in the manner you would have expected. And then lastly, notice this. It's slightly different from a text field, but I'm saying else if it's not the case that document dot forms dot registration depot agreement, agreement is the name I gave to the check box, dot checked -- so if it's not checked -- that's a check box, so it actually has a boolean property called checked, which is either true or false. So if it's not checked I'm going to yell at them for not agreeing to our terms and conditions, return false. Otherwise, if they passed all of those tests in that gauntlet, I'm going to go ahead and say return true. And what happens then? The user submits the form okay. Yeah? [ Inaudible audience comment ] >> Do you have to specify the return type of a JavaScript function? No. Just as in PHP, it's very loosely typed so you do not specify the return type. You literally say function, and then the name of the function. You can. So PHP and JavaScript are messy in that, as you point out, you could return true or false or 3 or 5 or quote unquote hello. You can indeed return different data types in these languages. Sometimes that advantageous, PHP takes great use of this. But it's also potentially a bad thing. Especially when you want to return a number like 0, but you might also want to return false, you get into interesting predicaments if you don't distinguish those two cases properly. But for the most part, it tends to expedite development and generally be a helpful thing, even if inelegant. Yeah? [ Inaudible audience comment ] >> Good question. None what so ever. So I was just being kind of anal, trying to keep it clear to me that only one of these is really going to matter. But because we are returning false immediately we could get rid of those else if's. Either way would be fine. Yeah? >> When you return false, does the [Inaudible] typed? >> Good question. Thankfully, no. So the question is when you return false does the browser clear the form? No. It leaves it exactly as it is. So this is in contrast with some behaviors of web sites whereby once you submit then get to the next page, you get yelled at, you click back, sometimes then if the page has not been designed to be cached you would lose all of your inputs. This leaves everything the way it was. Just doesn't allow the form submission. So you might be thinking now, all right, this is great, right? I don't have to jump through these hoops like we did last week with all the from I am examples, in CS 50 finance I didn't have to do all of this error checking server-side and make sure that the user didn't type in negative numbers or bogus symbols or the like. So why not just do all of your checking client-side? Well, unfortunately, anyone with an internet connection and Google can go up to, for instance, a web page like this, and let's say -- where is it -- tools, and tools, edit, preferences -- oh, let's do this actually. Disable JavaScript. All JavaScript. So now let's see what becomes of my error checking. So this is my form 2, which before did yell at me when I didn't submit anything. I'm going to go ahead and again not submit anything, and unfortunately, disabling JavaScript does exactly that, it disables JavaScript all together. So then what is the point? Right? If you can do this error-checking client side and yet it's so easy for anyone with a freely-available plug in to disable your error checking, what's the value, arguably, still, of these techniques? It kind of feels like a waste of time now, yeah? [ Inaudible audience comment ] >> It is, it's still faster, and increasingly, right, we're in this web 2.0 or web 3.0 era, right, where expectations have risen of web pages and one of the reasons that G mail is so popular and well used even in a mobile context in the web browser is because they created the context of the illusion of rapid responsiveness. Even if you're a super-slow 2 G or 3 G connection your G mail interface, if you pull it up in Gmail.com on a browser on a phone, it's actually still pretty zippy. You can expose a message, hit send and go back and forward. But that's all JavaScript. What Google's doing in that case, if you've used the mobile client, the mobile web site for Gmail is they're hiding all of the latency, all of the slowness for you by doing it effectively in the background. So with JavaScript we can at least improve the user's experience even though this really now just means more work for us. Yeah? [ Inaudible audience comment ] >> Good question. Is there a way to detect if a user has disabled JavaScript. Yes, so you could, for instance, have a piece of code in your page that is supposed to, like, plant a cookie on their browser. And if the next time the user visits, next page, after clicking, you see there's no cookie, it must be logically that your code never executed. Ergo, it's been disabled. So you can do tricks like that. But really the lesson here is that JavaScript is not an alternative to server-side error checking. And server side validation. And one of the most common ways for web sites to be compromised these days is because developers think, oh, well, I've got my JavaScript checks here. The user can't submit a field that's more than 100 characters long, so I don't need a MySQL column that's more than 100 chars long, and yet they don't check for the same thing server-side, and bad, unanticipated things can happen. Yeah? [ Inaudible audience comment ] >> That is up to you. So if you're doing client-side checks will the server side checks still execute? That's entirely up to you. So if I melded last week's from I am's example with this week's registration forms examples we would have a much more robust solution that's very zippy, I immediately get yelled at if I screw up. But also if I somehow get through and circumvent these error checks the PHP code is still going to yell at me. So one of the nice things too that we'll talk about later this week and beyond is these various frameworks and libraries that I keep alluding to. And we'll look briefly perhaps today at one of the most particular. So increasingly, are there tools, frankly, that eliminate this redundancy, whereby you the programmer can write something just once, server side, and you can even have JavaScript code automatically generated for you that does the client-side checks as well. So realize when you do it by hand, though, there is this additional layer. So let's try to take things up a notch here. This was version 2. With version 3, let's go ahead and just show a different way of achieving the same task. So we'll do -- introduce one other concept. So this is version 3, and the only difference here for the moment is this. I -- literally, I am now calling a validate function, but passing in an argument that's a special keyword. Some of you with Java backgrounds might remember this. This is a pointer of sorts. It's technically a reference, and in this context because I'm using a keyword this inside of double quotes, which map into a form element, this is like a pointer to that from element. What does that mean? Well, even though at this moment in time just text, and it's just HTML, when a structure like this is built up in memory and that line of code executes, this will be literally pointing to whatever the form element is. One of these rectangles. So via the this keyword you can pass in a pointer or reference to a specific node in the tree. And you can do so via your HTML. So now if I scroll up here my code has changed ever so slightly. And this way isn't necessarily better, but it just demonstrates how we can pass nodes from our tree into code that we write. Now notice this time I have function validate, but now it takes a parameter, F. I am not specifying a data type, you don't need to do that, just a name. And I call it F for form, and now notice I can have slightly shorter notation. If F dot e-mail dot value equals equals nothing, yell at the user. Else if, else if. So the take away here is that this is now allowing me one, to shorten my syntax, but that's not all that compelling in this case. But it is allowing me somehow to pass these nodes around as if they're indeed objects in a tree. And that will become more important as the code gets more sophisticated. Well now, we can do one other thing. Let me go ahead and open up with my browser version 4 of the form. And notice that it has this feature that you might have seen on various web sites. But now we can see how to do this. So notice that no matter how hard I try, I'm clicking on my mouse here, I cannot submit this form. Because it turns out that HTML has an attribute for buttons called disabled. And you can disable the clicking of a button, as simple as that. So now it doesn't matter if the user doesn't type in anything or types in something completely bogus, if I try submitting nothing's actually going to happen. But again, here, right? We've all -- we all know that we have tools like Firebug. If I right-click on this and I choose open up Firebug, open up the HTML, long story short I can open up all of my HTML here and then I can actually remove the disabled property, if I scroll down. Let's zoom in. And scroll down here. So let me just go ahead and remove this. All right, so we did this before, when we implemented fake Google. Viola, there goes your error checking. Now no reasonably human is going to do this, they're only wasting their own time if they're going to do this. But it does again send the message that you're still going to have to be having these checks server side. So what did we do in the code to actually do this? Well, actually, let me go back and show the proper behavior. Let me reload this page before I tweaked it underneath the hood. Go ahead, reload. Let's try this again. Form 4. So there it is. Disabled by default. But notice when I check this box and oh, wait, that's why. JavaScript is skill disabled. Most of these demos won't work then. All right. Let's go back here. Form 4. All right. Click this. There we go. So notice we now have programatic control over the DOM of our page so that I'm probably listening for that event called on click. When I hear it, I'm grabbing a pointer or reference to that other node in the tree, the submit button, and toggling programatically that disabled state. So let's go ahead and see this here. Let me scroll down to this form. Notice I again have the validate function here. But I have another one. I have another event handler here called on click, where on click equals, quote unquote, toggle. And this is otherwise just associated with this text box. Let me scroll back up to the top here and see what's going on. Well, up here not only do I have a validate function, I also have another second function also inside of my script tag. And it's actually pretty simple. A little verbose, but intuitive none the less. Function toggle when it executes, it executes this branch. So if document, dot forms dot registration dot button. So what is button? Let me quickly scroll down to the bottom again. And now notice I've been giving these things names as I want to refer to them. So let me scroll down, down, down. There it is. I literally gave this input element for the button a name of button. But I could have called it anything. So now if I scroll back up to toggle I now have if the buttons disabled boolean property is true, because that's all in one big parenthesis -- set of parentheses, then go ahead anisette the same thing. Document dot forms dot registration dot button dot disabled to false, else set it to true. And simply by tweaking these properties inside of these objects on the page I'm able to change the aesthetics of the page and also the functionality. So again, we have now programatic control of the DOM based on these event handlers that I'm now listening for. So let's look at now version 5. Version 5 is kind of sexy, because I'm finally not just checking if the user has typed in an -- times in something for their e-mail address. I'm now using a feature called regular expressions. And some of you might have stumbled across these already for P set 7, although it wasn't expected. But for your final project you might indeed want to be able to not only look at a user's input but also check does this match a pattern that I want to see, right? Back in the day, in Facebook, would restrict access to people only with a Harvard.edu e-mail address. So this suggests that you want to be able to look at a user error's input and not just check if it's quote unquote or something else, but you actually want to analyze its pattern. Well, you can actually do this relatively easily in JavaScript and in PHP, and in JavaScript the syntax is this. So notice this expression now. If it is not the case that document dot forms dot registration dot e-mails dot value, so here's another new lesson, whereas in C, once you have a variable like a string, that is a data type. You can only look at its chars and the like. But there's no functionality built in. Notice here that e-mail is the name I gave to my input called e-mail. But I apparently am going one step further, and I actually am calling a function, dot match means go inside of this DOM node, inside of that rectangle, and call the function called match. So this is an example of this thing called object oriented programming. Again, Java has this, C does not. PHP does, but it's not always used by folks. So this just means match the value of whatever the user typed in against this expression. And frankly, this looks more cryptic than it really needs to. But the slash there and the slash there just means here comes a reg ex, a regular expression. And what is that expression? Regular expression is just pattern. The pattern here is dot, and dot generally denotes anything, some character, plus denotes -- anyone know? At least one. So plus means one or more. So this expression dot plus means some character, whatever character, one or more times. And it doesn't have to be the same character. It just has to be a character, a one or more times. At sign means the at sign. Then we have dot plus, which is the same thing again. It doesn't have to be identical to the characters, but it means one or more characters here. Back slash dot means probably what? Literally a dot, right? We have a little problem now, dot means something special. But we want a dot, we need to escape it as we did in C with new lines and things like that. E D U means E D U. And then dollar sign is a special token that just means match all the way to the end. Frankly, there's no -- I've never come up with a good intuitive explanation of this. But dollar sign means that dot edu has to be at the end of the string that you're matching. And the opposite of that for those who are curious is a carrot symbol, of all things. They're not really opposites. But for now, all I'm asking the question, just like Facebook version 1.0, was did the user register with some address ending in at something.edu. So not even Harvard, in this case. Now of course this is not perfect, because this would allow the user to do crazy things like my name is Malon at mather at Harvard at -- right? You could do some crazy things, so long as it ultimately ends in dot E D U, but there are more rigorous regular expressions you can use, and frankly, these strings, the patterns get so long and complex, generally you would then start using a library. Someone else's code who has figured out all of the nuances of possible e-mail addresses in order to validate them. But you might find, especially if you're using your college address -- has anyone ever gone to a web site, tried to register with, like, user name at college dot Harvard.edu only to be told that this is an invalid e-mail address? Anyone? This happens to me once in a while. So why is this? Because some programmer decided that every e-mail address on the planet is in the something at something dot something. They didn't even think about sub domains, which are quite common here at Harvard, at post, at college, FAS and the like. So there's nothing more infuriating than not -- well, if you're really up tight, like me, than trying to register with a legit e-mail address and the programmer just hasn't anticipated it. But why, what explains that issue? Most likely it's a client-side JavaScript check or server-side JavaScript check that is using a bad regular expression. But at least now we can check if they actually gave us something that looks like a .edu e-mail address. But we can even do better. So in version 6 of this, now, I just wanted to introduce a little library, something called J query. So J query is often conflagranted for JavaScript. This is a third party library, so freely available code that other nice people have put together that's incredibly common. So such so that these days almost anyone who uses JavaScript uses J query, because it simplifies the kinds of things we were just doing, right? Even I was getting board verbally of saying document dot forms dot registration -- this is very tedious. And it's not fun programming as you might already know, when you're just typing stupid stuff all the time. So J query really tries to simplify the syntax and make it more concise. So how can we use J query? Well, notice this form of the script tag. So this is version 6 of our forms today, PDFs and code are on line if you want to play along. But in the head this time notice that I have another script. This time it's not immediately closed. Instead it has a source attribute. And that source attribute is to this URL, J query latest at some URL. Let me go into my browser and let me open a new tab and paste that in. So this is J query. And some of you might be using it but might not have ever looked. This is just a whole lot of JavaScript code that again, some really nice, smart people wrote, maybe freely available so that all of us can benefit -- it's a lot of code they wrote -- from the -- really a lot of code they wrote -- never actually done this. There's a big library. Oh my God. All right, so not the point though. The point, though, is that there's -- woo, a lot of functionality built into J query, and you can start to do really fancy, really sexy things without having to reinvent the wheel yourself. Right? You know from Facebook and from Gmail and all these popular web sites that there's very popular paradigms right now, little buttons that glow or have gray scale effects, drop down menus that don't look like the 1990's drop down menus any more, little auto complete widgets that show you who your friends might be when you're typing in the search box. All of these features that are entirely written in JavaScript, but if they're this common it's really nice to be able to stand on the shoulders of other people, use their widgets or their libraries, much like J query here. So just a quick example of how J query works here. Let me zoom in on my HTML, and we'll see that things like J query and more generally JavaScript let us do -- write better code. Now I have here in my HTML no mention of JavaScript. Frankly, it's a little messy that we're already co-mingling sometimes CSS with HTML, which is a different language inside of double quotes and style attributes. Now we had introduced a moment ago all of these function calls like validate and toggle inside of our HTML. And this really kind of violates good design principles, which generally say keep your data separate from your presentation thereof. Keep your aesthetics separate from your logic. In other words, do all of the interesting coding and the computer science-like stuff in one file and relegate things like aesthetics of HTML and CSS to separate files all together. And that's kind of what we've done here, inside of this HTML form now is no code, is no logic, but if I scroll up here let's see how I'm none the less validating user's input. So it's very important that I'm loading the J query library first before my own script tag because that library has to load before my own code executes. So there is -- it is the case in web pages that URL's are loaded in the order in which they appear. And so in this case here for the script tag, this means J query will be available to me. All right, so what am I going to do here? Well, this is going to look a little cryptic, since we already introduced one language today. This is JavaScript, but it is now using a library, and this is the very common paradigm. So rather than say literally document, we have to pay a slight penalty syntactically. Dollar sign, open parenthesis document, close parentheses, is essentially identical to just the keyword document from before. But there's going to be some fancier features that we get as a result. But now I'm saying this. Dot ready. So ready is a special function that comes with J query that says once the whole DOM has loaded into memory, do the following. And this is important, just as URL's are loaded top to bottom, so are your nodes in this tree, loaded top to bottom. So it's actually problematic if you start writing code that tries to check boxes or validate form fields or does anything interesting to a DOM, if only the first two or three nodes have been loaded. So really, you generally want your JavaScript code only to execute once the whole web page has loaded. And that could take a split second, to take a few seconds if there's lots of Flash files and video and sounds and the like. But ultimately, we want to wait till that has at least happened. Well, now, what this is saying is when the whole DOM is ready do this. Now, unfortunately, to do this we need to create a function on the fly. And this will only scratch the surface of this feature today, but what's really nice about JavaScript, and you can do this in PHP but it's a little nasty, the syntax for it, function open parenthesis close parenthesis gives you a function. But it doesn't give it a name. And in fact, when I do function open parenthesis close parenthesis curly brace, what I'm essentially doing in all of the lines that follow per the indentation here, that implies they're all part of this function, is I'm declaring what's called a lambda function, L-A-M-B-D-A. Or an anonymous function. And the latter name is a little more straight forward. It just means a function without a name. Because I don't care what this function's called at this point in the story. I just want a whole chunk of code to execute when the DOM is ready. So by creating this anonymous function I am handing to the ready function an argument that is only going to be executed when the DOM is ready to do so. If I didn't wrap it in this function just like in C and PHP, if I just start writing lines of code they would be all be executed right away and that's bad, potentially. Again, I want my whole DOM loaded into memory. So for now, even if that's a little unclear, just take on faith this means when the DOM is ready, go ahead and call this code. That doesn't need a name, because I'm only going to call it once. I don't need to call it again and again. So now notice this line. Dollar sign parentheses, quote unquote, sharp registration. So recall from CSS that you can give unique ID's to various elements in an HTML page. And if I scroll down to my form here, notice that I have a registration form, and I didn't give it a name this time, I gave it an ID. And this again is a very common paradigm in JavaScript and in CSS. If you want to be able to hone in directly on a specific node in the tree you might as well give it an ID which by nature is supposed to be unique. These are unique identifiers. And I can call it anything I want, but I called it registration because this is a registration form. Now if I scroll back up in my code, let's see what I'm doing. Rather than have HTML and say, an attribute of on submit, I'm now doing this programatically. So this again suggests better design. It's more complex at first, but better design. So this means in J query, go get the DOM node whose ID is registration. And the fact that I used the little hash symbol means go find the ID matching registration. And then dot submit is a special J query function that simply says when that element is submitted call this function. And again, I don't care about the function's name, it can be anonymous. And so I just say execute all of this code here. Now I could go back into a previous example and just copy paste the if else, if else, if else, if else from before, and it would work, but I can do a little better now. I can shorten that syntax and do it a little more elegantly, even though, again, it's going to be -- elegant is in the eye of the beholder, perhaps. I'm going to first check if it is not the case that the e-mail nodes value, so this is a J query function, get the value of this node. So again, sometimes this feels a little stupid, we previously would have just said dot value, now we're saying val? But so be it for now, you'll trust us that more interesting things will come from this, if it matches this regular expression, well, yell at them. If it does not match that regular expression, yell at them, because they have to provide a dot edu email address. Similarly, if the value of password one is quote unquote, yell at them. Else if they're not equal, yell at them. And the like. And the take away here, even though this is a lot of syntax, is that now all of this code has been decoupled from the actual HTML. So just as the J query folks factored out all of their huge source code into a separate file called J query latest dot JS, so could I do that. I could highlight all of this, as I've done. Click command X to cut it, paste it into a new file called lecture dot JS, and include lecture dot JS with another script tag with a source attribute like this in order to actually factor out my code entirely. And so indeed, when you go to web sites, and we can see this here, like Facebook.com, and we open up something like Firebug and click this time on its script tag, and you'll have to generally enable these things by default, you'll see all sorts of scripts that have been downloaded in the page. And I'll just glimpse just a couple of here, all throughout modern web sites, you'll see either in the page itself or an included pages script tags. And then link tags for CSS files and the like. And that's because much of the JavaScript that drives Facebook is in these external files, that are either downloaded when you first visit the web site or over time as you try to click on other features of the site. Well, let's look at just one seventh and final example here. This is code that I did not write, this is from J query's own tutorial. It's written in a slightly different version of HTML. This here is called H -- this is HTML 4. So it's a slightly older version, and it's been cleaned up. You used to have to write crazy things like this. Not so in HTML 5 any more. This isn't the best style, frankly. This code is kind of all over the place. But let's see what it actually does. Let me pull up version 7 of this. And we'll see here that this too is using J query, but much better, much more compellingly than my own limited web skills, you now see here in this HTML form one, a visual clue that these fields are required, apparently, based on the stars there. But you'll notice too, that if I click submit, notice what immediately happens is -- nothing. Nothing. David -- all right. Stand by. What a perfect note to end on. One -- ah ha. J Harvard forms. Form 7. Okay. Well now I look like an idiot in front of our special guest today. All right, so what would have happened, and stand by, can I recover from this? That is correct, J query latest. Oh, I'm just going to have to pretend. Okay, so what you would have seen is immediately upon hitting submit, you would see unlike -- as is the case on a lot of web sites you would see red text to the right of these form fields yelling at you, not in the form of this sort of annoying little pop up menu, the thing called an alert menu. But rather you would see it in line in the text. And that too is using JavaScript to actually manipulate the DOM. Let me see if I can simulate this by going to the actual Facebook.com. Let me click sign up here. Ah ha. So this too is now JavaScript. Oh, nice save. So you must fill in all of the fields. So Facebook got this right, even though I did not. so with that said, let's go ahead and take a two minute break. And in just a moment I'll introduce our guest for today. All right, so we are back. So it is my pleasure to introduce Jocelyn Goldfein of Facebook, the director of engineering, who was formerly at VMware, a company that works on virtualization products, not unlike our own virtual box. Jocelyn is here tonight -- today -- with Mike Strepper [Assumed spelling] and soon Mark Zuckerburg on campus to chat with CS and aspiring computer scientists everywhere later. So Jocelyn, welcome. >> Thank you so much. [ Applause ] >> I want to tell you that at Facebook we have a tradition of doing it live. So I have now respect for the live demo, so I have respect for the live demo, even if it doesn't go perfectly as intended. So the beauty of building web software is if things don't go exactly how you want it, it's very quick to fix it. Maybe some quick mutual introductions first. So I know you guys are all students of CS 50, which means right away you're doing something really good with your lives. I don't know if you all remember the Internet name -- you are. I don't know if you remember the Internet name from a few years ago which was a commencement advise, which advised new graduates, you know, a lot of advise, but above all else wear sun screen. So my amendment to this advise would be above all else, where sun screen, and learn to program in your life. I think it's a really important part of whether or not you become an engineer or major in computer science or want to build software over the long haul, I think mastering these basic principles is actually applicable to any and every job you might do with your life. So that's the one thing I know about you, and it's already a great thing. Give me a show of hands, how many of you are thinking of majoring in computer science? Okay. Or in any other engineering discipline? Okay. How many of you are sure you're not going to be engineers? Still smart to take this class. How many of you are freshmen? Sophomores? Juniors? Seniors? Grad students, any? Buehler? All right. Still smart to take this class. Excellent. A little bit about myself. I have had a -- a varied and interesting career. I was a computer science major myself, lo these many years ago. I graduated from a left coast university, Stanford, and I've worked at -- sorry -- I worked at a variety of interesting companies, but for our purposes maybe one of the most interesting is -- that I founded my own start up with a couple of my coworkers, and did that for about 18 months. And I stopped doing that after one too many strategic pivots. And also because I was in Austin, Texas, and I really wanted to get back to California. At that point in my career I had figured out that I had as much of a jones for building teams as for building software, and so I went into VMware as an engineering manager, as a manager of teams of engineers. And when I joined VMware it was about 350 people, and that was really the beginning of a rocket ride for VMware which grew -- which doubled head count every year for the next five years. And when I left VMware a little over a year ago it was pushing on 10,000 employees. So power of compound interest at work. And when I left VMware I was pretty determined to get back into the start up environment, and I was really only talking to very small companies. I ended up interviewing with Facebook kind of as an afterthought, kind of as a favor to a friend who was working there. And I just kept having these interesting conversations with Facebook employees, and I finally decided that Facebook had more of the qualities of -- that I was looking for in a start up than a lot of the start ups I was talking to. And among other things had -- kind of a trite observation in hindsight, but far and away the most impressive founder, that being Mark. So I happily accepted employment with Facebook a little over a year ago, and have not looked back since. It's been a wild ride. If I -- trying to sort of compose some remarks in my head and think about what would I have wanted to know when I was an undergraduate taking an intro programming class, trying to decide whether or not I wanted -- you know, what I wanted to do with this and would I continue on. And I think the thing that would have been really valuable for me to hear about was what exactly is the life of a software engineer like? Because you know, we don't really get exposed to that very much, you know, it's not like -- I think we all have some idea of what doctors do, they go to the doctor's office. We have some idea of what teachers do, we encounter them every day. But I didn't really know what software engineers did. And the media representations I got were like all about hacking into the FBI and starting World War III, which -- you know, turns out is not the -- the bread and butter of the working software engineer. so what is it? And you know, I think that above all, the quality that defines the software engineers that I have most loved working with is that they really love to build stuff and they really want to make something from nothing. And if I think about the traits that Facebook looks for in the software engineers that we hire, the first trait we look for above all else is passion, a degree of excitement about what you're doing. And I think this maybe applies to all engineering domains. Whether you're in, you know, think about things that you love using and who must have made them, and think about buildings and bridges. But also cars and phones and software. And you kind of know when you're using something that someone just sort of phoned it in. And -- and you kind of know when you're using something that someone worked on that they were just in love with what they were building, and wanted to make it awesome. So I think that quality of being in love with making things, and wanting to make awesome things for other people to use, that I think is the quality that at heart unites us all and makes us engineers. Second that, of course, Facebook wants people who are really good at what they do, who are smart and very capable. And I think that one of the qualities also that makes software engineers really good at what they do is actually sort of a willingness to roll up their sleeves, dive in, and get things done. And you know, Facebook in particular values just doing it live, like trying something, see if it works. If it doesn't, fix it, move on. And really, we have seen over and over again the virtue of trying something quickly, making a difference, and learning from that, rather than spending forever kind of planning or thinking about what it should be. So we tend to -- we tend to have really broadly three sort of categories of work that Facebook engineers do. Ranging from systems work, so if you think about the kind of systems problems Facebook has, we probably have built sort of the single-most well-used application that exists. One of my teams is the new street team that owns the Facebook homepage. And I think there's a pretty good chance that that piece of software gets more hits per day than any other piece of software in existence, which is a little humbling, when we think about submitting code and changing that page. And yet we do that every day. Usually not on weekends. Every week day. And so -- so that's kind of -- you know, that kind of systems challenge requires -- is I think the defining distributed systems problem of our time. So if you think about distributive systems, if you think about cloud scale, if you think about the ways that we divide and conquer large work loads, Facebook is -- Facebook is doing some extremely cutting-edge work in this area. And I'll give you just one, for example. We actually now custom design our own hardware. We no longer buy off the shelf parts, because our hardware is so tuned to our workload. But we have put so much energy and inspiration behind the designs of our custom -- of our proprietary skews that when we actually go take commercial benchmarks that are, like, performance workloads and power efficiency workloads, the Facebook design skews actually out perform the commercial skews. So the server designers at Facebook are actually designing better servers than people whose job it is to design servers for a living and sell them to other companies. So that I think is kind of amazing, and crazy-interesting. We have a class of work that is algorithmic in nature. That, you know, any time on Facebook, you know, we know for sure that making people think is always -- that if you force people to jump through hoops and make people think, they're going to have a worse experience. So we always want to try to present to users what it is they want to see by default. And so there's a variety of ways where this comes into play. When you're searching on Facebook and you're searching for a person, we do our best to figure out exactly who you mean and bring that result to be first. When you're reading through stories in our news feed we do our best to try to figure out what are the stories you are going to be really pissed if you miss, and pull them out of order and stick them at the top so you don't miss them. There's a variety of other places where behind the scenes we try to show you the right result first. And so collectively, that is -- there are a large number of functions at Facebook that are doing real interesting machine learning work, essentially, to try to divine what is it people are trying to do, and let's put it at their finger tips. Last but not least, and closest to my own heart is what I would consider sort of product -- pure product development. And when Facebook says product, what we mean are features our end user is using on the site. On Facebook.com or in our mobile applications. And that kind of feature development is really, if you like the -- I'll say the top of the food chain, where it all comes together and gets exposed to users. And so maybe I'll talk a little bit more in detail about what you do if you're an engineer, if you're building a product at Facebook. So it starts with an idea. And ideas for a new product or a new feature at Facebook come from all kinds of places. We're famous for our hackathons, every couple of months we'll declare it to be a hack night or a hack day, and we'll basically take the next 24 hours and people will set aside everything else they're working on, and they'll just work on an idea that's interesting to them. And you know, it's -- it's very rare, it's next to impossible that you're going to build something in 24 hours that we're going to ship on the site the next day. But what comes from that hack culture is you have a chance to set aside kind of the nitty gritty, you're in the trenches, you're very focused on what you're doing. And you have a chance to step back and dream big. And ten hours of solid coding without interruptions, without interviews, without meetings is actually an opportunity to really build a prototype. Especially if you grab three or four other people into your project with you. To build enough of something to show people the concept to get them excited about it. So some of our best product ideas have come from those hackathons. Sometimes they come from the outside, they come from users telling us things they'd love to see on the site, they come from an individual with a great idea. But I think engineers with an idea have sort of a built-in advantage over anybody else with an idea, because an engineer has the power to flesh their idea out into a proto type. You know the saying, a picture speaks a thousand words? Well a prototype speaks a thousand pictures. And so that -- that power -- seriously. And so you know, Silicone Valley is full of people running around [Inaudible] saying I have a great idea, will you give me some money so I can hire some programmers. The VC's tend to say no. Because everybody has an idea -- like, tons of people have ideas. The value is not in the idea. The value is in actually expressing the idea and building the idea. So VC's tend to fund founders that are technical and are going to build their idea, or who have built something, and have something to show, more and more. So engineers have this kind of built-in advantage to help their ideas get traction. But something else that makes [Inaudible] an engineer more likely to be successful at Facebook is if you are good with words, if you're good at selling your idea, if you're good at bringing other people along with your idea. Even if it's just convincing your two coworkers that they want to work with you on hack night and prototype out what you're talking about. So once you have an idea it starts to gather momentum, we'll tend to put together a team around this idea. Whether it's a development of an existing feature or a brand new feature. And a product team at Facebook is -- we run some of the smallest product teams that -- that I have exist in the industry. And so a new feature like a significant new feature on Facebook, like, the new questions product we shipped last year was actually built by two engineers. Something big like the new homepage roll out was maybe 10 or 12 engineers total. And probably essentially 3 or 4 on the UI, what you actually encounter who the homepage. A lot more on the back end. So these are relatively small teams, which means every one of those people have enormous leverage. There's usually a product manager in the mix, there'd usually a designer in the mix because we want our products to be beautiful. And so there's someone that is moving pixels around in Power Point -- sorry, not in Power Point, in Photo Shop. And making this look lovely. And so -- and then it tends to be that you know, our cycles are almost un-- I cannot tell you how long it takes to develop a new product or feature at Facebook. I wish I could, but in the -- in the 15 months I've been there it seems like each one is different. And what tends to make them different is our approach is extremely iterative. We don't ship features on a schedule, it's not like VMware. VMware made money selling software. And so if we were going to ship Fusion 2.0 in Q 3, we were going to recognize the revenue for it in Q 3 and if it wasn't ready to ship -- you know, we would ship it in Q 3, and if we had to cut features to make it fit we would. Facebook's revenue does not come from selling our software. The service is free, it always will be. And what that means is we can take our time and make the feature be right, or we can also sort of go in a hurry and see what the reaction is, and fall back very easily. And it tends to be most of the time that we're building features we're actually building them in the production code base of Facebook.com. So if you -- the web servers that serve up Facebook.com to all of you are actually also running the code for all of the features that we're developing right now and that will ship over the next 2 to 6 months. And those are simply -- and if you're wondering how could that possibly be? You already know the basic programming structures that enable it to be possible, right? You can imagine a system where the code is running and it has some series of checks. If you're a Facebook employee, if you're in this beta group, run this code. Otherwise, if you're a production user of Facebook, run that code. And so that system which we call gate keeper enables us to develop our products in the live -- in the live Facebook.com. And really experience it and use it as our users would use it. And it also gives us a lot of power to sort of turn it on for a small number of users and see what the reaction is, and then turn it off again. And so primarily, the -- the process of developing a product doesn't start with a very fully realized spec. It starts with an idea, it starts with some engineers building prototypes. It may start with some photo shop mocks of what it could look like. And then we just start building it. And then we sit with it, and we see what it feels like to us. And you know, it -- the principle actor here is at Facebook very much is the engineer. Because as much as you can look at a photo shop mock and say oh, that would be awesome, I would love to use that, it's only once you get it live and actually powered by your own social graph and your own friend data that you start to feel like oh, maybe this is not so good. The homepage that we just shipped in particular, we probably went through five really major different conceptual takes on what we wanted to do with the homepage. And it was -- and so we probably sunk two months into each of those, anywhere between two months and two weeks on those iterations. The two month ones were the most heartbreaking, honestly. But that's maybe another thing that you have to have as a software engineer, is a certain amount of resilience, and a willingness to say, hey, this didn't work. I'm going to walk away from that [Inaudible] cost and try again. And so over this time we both were -- we both had a set of people working on the back end for a news feed that were making -- were making scaleability changes that were creating the ability for us to do much more interesting aggregations of stories. Something that, you know, may or may not be that noticeable in the new news feed is there are many more clusters of stories. We're trying to put stories together in a more dense way for you. And that was something that required significant back end changes. And we had a lot of people working on the algorithms to recommend top stories. But the UI -- and that work kind of sort of progressed linearly forward. Although we made a lot of changes to ranking and the pacing and the volume of the stories. And it really was just a process of trying lots and lots of experiments. Some of which we only ever turned on for Facebook employees. Some of which we turned on incrementally for a small number of users. Well, large number of users, but small percentage of users. Sort of very common test group size for us is half a percent of active users. And that doesn't sound like very many, but when it's half a percent of 800 million it's actually a lot. But the nice thing is you can turn on that test and have really good data within a couple hours. So it's a very high-leverage place to build products, if that's what you like to do. And as we got closer and closer to a product that we really felt good about, then we kind of entered a phase of refinement and polish, and really sort of opening our selves up to criticism from a lot of employees and a lot of beta users, and taking those to heart, fixing bugs, and really supplying a level of polish that made us feel good about our creation. And then last but not least, announcing it and launching it to users. So that's kind of the life cycle. And actually, that's not last. It's neither least nor last. Because as soon as you turn something on you find out things that you didn't really know before you turned it on. And so there's very much a part of the Facebook product launch process which is continuing to iterate even after you ship and making it better and better, even after we ship. And that's a process that continues to this day. So I feel like I've been talking for a long time. So I would actually love to pause here and maybe take some questions from you guys. What can I tell you about software engineering, up there in the white T-shirt. What are the major ways in which Facebook generates its revenue. We're an advertising company. We make our money mostly from ads. We also have -- we also have a system called Facebook credits, which you can purpose virtual currency mostly for use -- for virtual goods only, mostly for use in Facebook games, essentially. But it's primarily an ad company. And by the way, if you think of the most successful consumer driven properties, you know, on line, they've all been on supported businesses. Any other questions? Over here, nope, just stretching. Yes? [ Inaudible audience comment ] >> What is the male to female ratio at Facebook. Not a public number, but I will say it's not good enough, and it's something we're trying to make better. I think that anecdotally, Silicon Valley is not -- you know, part of the reason we don't share these numbers is we don't want it to be a self-fulfilling prophesy. And so -- and so I think a lot of Silicone Valley companies are caging about sharing those numbers. Precisely because we don't want to discourage women. Anecdotally, what I think I will say -- what I will say is I think Facebook is doing much better than most other Silicone Valley companies in terms of having women in actually coding positions and manage positions, like mine, rather than kind of auxiliary functions like QA and tech support. I think Facebook is doing really well at is acceptance rate for whatever reason, one of the things that I did when I start -- so I am passionate -- if you Google me, you'll find me talking about getting more women into computer science and getting more women at Facebook. It's one of my passions. I think the world is missing out on half of it -- literally half of its software engineers. And -- and so one of the things that I did when I got to Facebook was to really go through our whole hiring pipeline with a fine tooth comb, looking for discrepancies between men and women. And actually, the only major discrepancy I found is that women accept our offers at a higher rate. There's about a 10 percentage point spread. Yeah? [ Inaudible audience comment ] >> If you're a minor employee, you mean under 18? [ Inaudible audience comment ] >> The question is if I'm a minor employee how important are my ideas. Minor meaning just an individual contributor I think you're trying to say? I think -- I want to say to you something that is going to sound cheesy, but I think is demonstrably true, which is that there aren't minor employees at Facebook. And that everybody's ideas have impact. And I think the best way to -- to at least in engineering, I can't speak for every function in the company because I haven't experienced them all first hand. But what I would say about engineering is that if you look at the leverage of being an engineer at Facebook, it's almost unique in the history of the software industry. So if you think about the spectrum of the impact you're going to have in the world -- and we think a lot about this, because I think one of the core values at Facebook is making a big impact and doing things that are very high leverage. A lot of people when they think of having a big impact they think about going to a very small company, right? You know, the -- where they are going to be one of very few people in the room and where they are going to be involved with every aspect of the business and make a ton of business. Man, when I did my start up, there were four of us. I was involved in every single decision whether it was, you know, what was our product strategy down to, like, what sodas are we going to buy in the kitchen this month. And you know, so if you're somewhere very small you're going to have a big impact on your business, but the nature of working at a five person or a twenty person start up is that your start up is the standard start up experience, very few are successful and break out of this. But the standard start up experience, especially at first, is that your -- what you're doing effects very few people in the world. You just don't have that many users yet. And so your impact on your company is large, but your impact on users, on people, is small. Then you can kind of go to the opposite end of the spectrum, and I think this is the experience you're talking about, where you have these sort of very large, well established companies that are having a ton of impact on people in the world. Think of Microsoft, think of Google. And or for that matter, think of IBM and Cisco, Intel, really giants of the high-tech industry. And they have hundreds of millions of users. They have saturated the market. They have every user you could imagine. And yet at the same time, they have tens of thousands of employees. And so the impact that each individual employee, that each individual engineer can have on those people of the world is also pretty small. Right? Sort of getting back to the thrust of your question, like, I'm just a little cog in a wheel somewhere. I can't -- like, Apple may be changing the mobile phone industry, but like one engineer on the iPhone probably cannot. But I think that if you picture a graph which has a number of engineers on the X axis and users per engineer in the Y axis, I think the graph actually looks a bit like a hill. And I think Facebook is sort of close to unique in being, you know, very close to the top of that hill. I think we're approaching the top of that hill, where we have 800 million users, we have fewer than 800 engineers, and so the ratio [Inaudible] users to engineers is -- is literally more than a million to 1. And so every single -- like, we have so much more work than any individual could do. And so every single person at Facebook has to think about what is the most impact I can have on our users. What is the highest [Inaudible] that I can be and do. When you think about building a new feature like questions with just two engineers, when you think about -- and by the way, those two engineers weren't like, you know, senior staff principle engineers. One of them was three years out of college and one of them was no years out of college, because he was a summer intern who had dropped out and stayed. And so -- and those two guys built the whole thing. And -- and trust me, they had more impact and more say over that feature than anyone else involved. So you know, are you necessarily going to be able to, you know, walk into Cheryl Sandburg's office and say I think the sales plan should be something different. No, like, your impact is going to be felt in the area of your expertise, of what you're working on. But in that area it's huge. [ Inaudible audience comment ] >> How do we cope with the fact that for at least two weeks after a new Facebook comes out most people hate it. It takes some coping. [ Laughter ] >> I'm not going to lie. Not one of my favorite parts about Facebook. Actually, it seems like it's mostly homepage that people -- that -- that draws that response. In fact, like, we've done this sentiment analysis, and we do sort of this graph of positive versus -- where [Inaudible] people's public status updates that include the word Facebook. And positive spikes are like positivity sentiment spikes are usually things like, you know, holidays where people are saying, you know, happy mother's day to all my Facebook friends who are moms. So those are not about us. But the negative ones -- the negative ones are, you know, bring back the old Facebook. And almost all of the negative spikes are correlated with homepage roll outs. It's -- you know, if anything, the fact that it does happen very predictability makes it easier. Like going into rolling out a new homepage we kind of were, you know, a little bit braced for impact. But you know, it also -- every time people complain there's almost always -- like, sometimes yes, I don't like change. But there's generally a lot more at the root of it, right? I think the complaints about the homepage this time, you know, had a lot of legitimacy to them. I mean, you know, I think it's -- I think it's true that if -- if people are really happy with your service, and that's the most heartening thing, frankly, that people wouldn't be complaining this much if they didn't care so much, right? If they weren't passionate about Facebook, if they weren't passionate users of my software. And this is so much better than working on something that just doesn't matter. But, like, also, people are going to complain about change. But the thing they complain about is going to be the thing that you need to fix, right? Or is going to be the thing that you strategically chose to do and you're going to stick to your guns about. And so there are -- well, no, I'm serious. There's -- maybe the most illustrating story, actually, this is a good story if you haven't heard it. Facebook first rolled out news feed in 2006. So this is heresay, I was not at Facebook at the time. But at the time, Facebook had about 50 million users. And when they rolled out the news feed the outrage at the existence of the news feed -- because before, you had to visit someone's profile to see what they were up to. Right? You had to stalk them. And -- as you may recall, if you -- any of you using Facebook in 2006. And -- and the news feed all of a sudden, all this behavior, all this activity people were doing on Facebook was visible to their friends before, but they kind of felt like they had security to obscurity. Only people who cared would go and look. And now that was all being pushed out to the world or out to their friends. And so the out rage, literally 12 million people, 12 million Facebook users joined a protest group protesting the existence of the news feed. 12 million out of 50 million users. Like, an insane percentage. At the same time, our servers were going nuts. And we had data showing that the same -- of our 50 million users almost all of them were using the site much more frequently, were spending more time on the site, were consuming the stories, were visiting each other's profiles more often, were friending more people because they were discovering more. So we could tell even through the complaints, that gave us the courage to stick to the strategy change, to stick to our guns. Because we could see that users loved it and that it was giving them value. And everything we do is for the purpose of creating value for users. Yes, secondarily we want to be able to monetize that so we can continue our mission. But if we just wanted to generate advertising dollars there's a lot of things that we could do. We can make ads bigger, whatever. The number -- the worst thing we could do for our revenue would actually do something that made people visit the site less or friend fewer people or -- or switch. So users are always -- users and user engagement are always at the heart of our strategic decisions. And revenue is kind of something that's kind of an afterthought. It's literally a separate organizational function, because it will follow if we make users delighted. So -- so in the case of these changes that me make, something that gives us the courage to stick to our strategic guns is if we see that users really love the features. That they're really using them, that it's really making a difference and helping people. And it also helps to actually just pay attention to what people say and realize that, oh, we actually could fix that. It's in our power to solve a problem that the new interface has created for you. And so we do that too. And I suspect I'm running out of time. >> Indeed. But I think you can stick around for a bit and answer questions one on one? Well, thank you so much, Jocelyn, for joining us today. >> My pleasure. [ Applause ] >> Thanks so much. This is CS 50. We'll see you Wednesday. And Jocelyn will be up here, up front for a while. Thank you.