[ 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.