[MUSIC - FERGIE & Q TIP & GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY"]

FERGIE & Q-TIP & GOONROCK: (SINGING) Just one night,

all we got, just one nigh, all we got, just one night, all we

got, just one night, all we got.

A little party never killed nobody.

So we going to dance until we drop, drop, drop.

Mm, a little party never killed nobody.

Right here, right now, is all we got. skeeten-bod-op-bop.

[MUSIC - FERGIE & Q TIP &

GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY"]

(SINGING) A little party never killed nobody.

So we're going to dance until we drop.

Let's go.

A little party never killed nobody.

Right here, right now is all we got.

Oh, a little party never killed nobody.

So we're going to dance until we drop.

A little party never killed nobody.

[MUSIC - FERGIE & Q TIP &

GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY"]

MUPPET: [SNORING]

DAVID J. MALAN: All right.

This is CS50, and this is lecture 8.

And that was a look at the so-called CS50 hackathon, this annual tradition

with which we nearly end the semester that will start around 7:00 PM here

in Cambridge, will then end around 7:00 AM the next day in Cambridge.

And punctuating the evening will be quite a bit of work

on final projects, which is the overarching goal of the evening

to give students, both an academic and a very

social and collaborative environment in which to tackle

their final achievements in the course.

But also, as you gleaned there will be a bit of distraction, a bit of food

from Felipe's, typically, around 9:00 PM, a little bit of Domino's Pizza

around 1:00 AM.

And for those still standing as in the muppet there,

we'll treat you to breakfast at IHOP if you still have the energy.

Thereafter, we'll be the so-called CS50 Fair, the climax of everything

that you've done in CS50.

And more on that in the weeks to come.

So without further ado, where have we been these past several weeks?

Well, recall that, over the past couple of weeks,

we've been introducing web programming.

And most recently, did we try to tie together a lot of the topics

from the past few weeks.

HTML and CSS and JavaScript, and then Python, and then another framework,

another piece of software called Flask that

just made it easier and more possible to build web-based applications.

And the simplest example of that last week, recall,

looked a little something like this.

And this past week with the problems on similarities and survey,

have you been building your own web-based applications.

But they haven't quite had all of the pieces

that you might want to assemble into a web-based app.

And so today, we'll fill in those final blanks.

But recall that we've been trying to frame these applications, not

as one-offs or just tools that you built, but as part

of a common paradigm or a methodology.

And indeed, when you're learning computer science and software

engineering, you start to notice patterns in the software,

in the code that you're writing.

And humans tend to adopt these patterns because they save you time.

And then everyone can speak the same language, so to speak.

So MVC was the acronym we introduced last week, Model View Controller.

And that just speaks to this paradigm whereby

you organized certain type of code in one file, certain types of other code

and another file.

So your Python code goes in application.py.

Your HTML goes in your HTML files, your CSS in your CSS files, and so forth.

But what we didn't have last week was this thing here, really.

Model generally refers to your data.

And while survey, your most recent problem,

did have data, a CSV file that's arguably a model,

CSV is not terribly expressive.

You can pretty much just write rows to a text file, not unlike a spreadsheet.

But you can't really query it.

You can't easily insert or delete.

You pretty much would have to reconstruct the whole file.

And indeed, that's exactly what I did back in the day.

The very first web-based application I wrote back in sophomore or junior year

was the freshman intramural website.

And all I had available to me, both technologically and conceptually,

we're CSV files.

I had no idea what databases were, didn't realize how much easier they

could make my life.

So I stored all of the data behind these links here just

in very simple text files.

But today, will give you so much more power.

And especially, if you're coming into the class with an interest

in applying CS to other fields in medicine or the arts

or any world in which there's data, particularly,

in STEM and data science and the like, realize

that SQL has really become this incredibly powerful language

with which to solve problems in those and so many domains.

And ultimately, what your build, this coming week--

your very last CS50 problem set--

you have now peaked just about-- will be CD50

Finance, a web-based application by which you can buy,

or "buy" and sell stocks.

And so what you're going to do this coming week is write code

that implements a web application that resembles this whereby

your users and yourself will be able to register for an account,

log into that account.

You'll be given for free, thanks to us, 10,000 virtual dollars.

And then you can go ahead and buy and sell stocks via their symbol

using this application.

So for instance, if I go ahead and register myself here.

Let's say, username Malan, password 12345--

shouldn't have said that.

Go ahead and register here.

You'll see that, by default, I get this free $10,000 in virtual cash.

You know what, I'm going to go ahead and buy myself

a share of maybe Netflix, whose symbol is NFLX.

I'm going to go ahead and try to buy one share.

Voila.

And now you'll see that, not only do I have less cash left, about $9,600,

I now own a share of stock.

And if we reload this throughout the lecture, frankly,

the price might go a little up or a little down

because this web application you'll build

will also talk to an API, an Application Programming Interface--

so some third-party website that provides you with stock data.

So you ask it for the current price of a stock.

It gives you an answer in JSON format, if you

recall our short discussion of that.

And you'll integrate it, ultimately, into this interface.

So this will be the culmination of so many of the ideas

and the building blocks with which you've experimented.

But we need a few final pieces today.

So first and foremost, when I registered for this site, I created an account.

And indeed, I can go ahead and log out now.

And if I go ahead and log back in--

if no one's stolen my password yet, I can see my account and only my account.

But we haven't yet seen any mechanism in code

whereby you can implement this notion of logging in, right?

What is the underlying logic via which a website knows that you are logged in

or you're not logged in, right?

Clearly, when I went to this website just a moment ago,

it prompted me to log in because I was not because I had logged out.

But how did it know that?

And now that I am logged in, how does it know that I can click on "quote"

to get just the stock quote or "buy" just to buy a stock or "sell."

Why does it not prompt me every time I click a link to log back

in with my username or password?

What do you think?

AUDIENCE: Isn't cookies little files that

saves the data inside your browser's cache that let it know what's going on.

DAVID J. MALAN: Yeah, cookies--

little files that get saved by websites on your computer.

Now odds are, most everyone here has probably heard in some form,

cookies-- bad.

Maybe bad, privacy-invading, yes?

OK.

So true.

But most of the web would not work without them.

So someone else, what do you understand a cookie to be?

What is a cookie?

AUDIENCE: Basically saves your information

so you don't have to put it in every time.

DAVID J. MALAN: Yeah.

It saves your information so you don't have to put it in every time.

So in simplest form, it's exactly a combination of those answers.

Whereby, when I log into a website, you could

imagine that website just remembering my username and my password

by just saving them in a little file on my Mac or PC

so that the next time I visit a web page,

it just automatically sends them for me, so that the human doesn't

have to type them again and again.

Now let's find fault with that.

Feels like that would work, but what's a downside of that naive implementation?

What do you think instinctively?

AUDIENCE: The data is just out there?

DAVID J. MALAN: The data is just out there, right?

I have people in the office or at home or in a library

that I might not want to just be able to walk up to that computer

and just see this little text file planted on my computer.

Because then they could log in to my account by just digging around.

So it feels a little invasive.

Indeed, that's one of the threats of cookies.

So it turns out cookies or websites tend not to do that, at least,

if they're implemented well.

They instead just plant a really big random number on your hard drive

or in your computer's ram or memory.

So 1234567-- like, some really big number maybe with letters and numbers

maybe even some punctuation that uniquely identifies me.

And thereafter, any time I click a link on that same website,

after logging in, my browser, thanks to HTTP--

the language that browsers and servers speak that we discussed a few weeks

back--

just magically sends that same big random number

to the server again and again.

And so long as the server remembers that that big random number corresponds

to user name Malan, it can figure out whose account to show.

And why is it a big random number?

Why is it not just my password or my username?

Why am I proposing that it be a big random number?

AUDIENCE: Sometimes people can guess it by just using a random generator.

DAVID J. MALAN: Exactly.

In computer science, randomness is this incredibly powerful ingredient.

If you pick a big enough word or a big enough string

or sentence, the probability that some random adversary, or bad person

on the internet, is going to be able to guess or try

to guess that value is just so low, it's just not realistically

ever going to happen in your lifetime statistically.

And so random this gives us that capability.

And so you can think about this metaphorically in the real world

as being like a hand stamp.

If you've ever gone to an amusement park or a bar

or a club where you have to show your ID or you

have to pay for a ticket on the way in, sometimes they'll

stamp you with either visible or invisible ink.

And that's largely for efficiency so that, thereafter,

when you're in the amusement park, you can come and go.

And you don't have to repay or reprocess.

If you're in the bar or the club, you don't have to keep showing your ID.

They can check once, and then more efficiently let you come and go

as you please.

Because you're just presenting your hand or this virtual hand

stamp to the bouncer or to the gatekeeper at those places.

So cookies are exactly like that.

Unbeknownst to us all this time, anytime you visit a website into which you've

logged in, your browser is secretly but usefully

presenting a hand stamp to that server to remind it who you are.

Or rather, not really who you are, but of that big random number

so that, if the server remembers who that number belongs to,