DAVID MALAN: So why don't we go ahead and begin our 1:00
PM to 2:00 PM Eastern session--
an overview of the classes that you can teach before or after CS50AP.
This, like a lot of CS50, will be a bit of a fire hose-- a lot of information.
But it's really just meant to give you a taste of what is available to you
optionally.
Indeed, over the past few years, though we
began with just CS50 the course, which composes
much of our discussion in the past few days,
thanks to Brian and Colton and other colleagues of ours,
have we begun really building out a curriculum of sorts that's
particularly well-suited for high school and/or middle school students,
so that teacher is teaching CS50AP don't just
have one curriculum at their disposal.
But they have more runway for their students.
So students might take one class before CS50AP,
one or more classes after CS50AP, or just CS50AP,
or one of these other classes themselves.
It really is up to you how you might like to assemble
any of these building blocks.
So we thought we'd give you a whirlwind tour of six other courses, one of which
you've seen already, and three of which are related to one another.
So it's not quite as much as it might seem.
Brian, you know.
Allow us to have our colleague Colton say a formal hello,
so you know whom to expect in a few minutes, too.
COLTON OGDEN: Hi.
Nice to see everybody here.
Hope you're all staying safe.
DAVID MALAN: Colton will be introducing in just a bit
our game development class, which is particularly
well-suited for a lot of high school students' interests.
So here on the screen, you should see next to me
the list of six other courses that are currently in our curriculum.
All of them have a single or one or two characters that describe them.
CS50B is a course for computer science for business professionals.
CS50L is CS50 for lawyers.
CS50T is understanding technology.
And then we have three follow-on classes, CS50AI,
which is an introduction to AI with Python; CS50G, taught by Colton,
an introduction to game development; and CS50W,
like CS50AI, taught by Brian, Web Programming with Python and JavaScript.
And I think if of any interest to you in teaching these classes, be it
this coming year or down the road, hands down,
I think the best preparation for doing so is
to simply take the courses themselves.
They're freely available as OpenCourseWare.
We'll provide all of the URLs as we go here.
But they're also centrally located, if you would like, on edx.org, where
you can sign up for free for audit status
and follow along at your own pace, if you
might want to prepare over the summer or some future year
for any of these curricula.
And indeed, that's much like our own teaching fellows
become teaching fellows because they have quite simply taken successfully
any of these classes.
To help give you a mental model for how everything fits together,
if you think of CS50 itself or CS50X, the OpenCourseWare version
of the class, as the backbone or the main class
that students have long taken at Harvard,
these other courses now fit into that pipeline
either as predecessor courses or follow-on courses.
So a possible model would be for a student to take CS50b or L or T,
and then CS50X, and then to take CS50AI or G or W
or even multiple combinations thereof.
The first three courses on the left, B, L, T,
are essentially mutually exclusive.
We'll see that there are differences among them,
so they don't need to be taken one or the other.
The three follow-on courses can be taken in their entirety.
So you could imagine, for instance, at the high school
level, perhaps a student starts out freshman year with CS50T.
Maybe sophomore year, spends time on CS50X or really CS50AP.
And then maybe junior and/or senior year,
has an opportunity to take something like the AI
class, the games class, for the web class.
Of course, two of these we're now well familiar with.
CS50T plus CS50X compose what we've been calling CS50AP.
So please interject at any point if you have any questions.
And if I miss a hand, Brian or Colton, please do just
chime in and call my attention.
But why don't we dive in first, just more
formally, to CS50T, which we've been taking
for granted as just part of CS50AP's curriculum.
But again, factoring that out and maybe having
less comfortable or younger students simply start with that piece,
as opposed to diving into CS50AP itself, is one viable option.
So here comes the whirlwind tour.
The syllabus of this class is essentially divided
into these six large topics.
The goal of this class ultimately is to provide students and of any age
with really an understanding of the technology
that they see and hear about every day, but don't necessarily understand.
And we break the course down into these six components.
And let me give you a quick tour of each of those.
So on the hardware front, we start, not unlike CS50 itself,
with a look at binary, and more generally,
representation of information.
But we focus a bit more on hardware than we do in CS50 itself,
looking more at things like CPUs, the brains of the computer;
hard drives, and how data is actually stored underneath the hood;
and even talking about peripherals and connectors,
the plugs that you see on the back of the computer.
Colton might remember this throwback from a few years ago
when we filmed this.
The course also, albeit on video, has this lab component
where we take things apart.
We show students on camera pieces inside of a computer.
And so what's especially fun about CS50T,
really, in isolation, if it were taken or taught as a course unto itself,
is if you have access to an old computer, a PC or a Mac,
that you can take apart, it's actually a lot of fun
to enable students to play more hands-on with what's inside the computer,
or conversely, to have them build up a computer based on those same parts.
We then focus in CS50T on the internet and what it is.
And we talk about things that many students will take for granted.
If they're fortunate to have internet access at home,
we contextualize what that cable modem is from Comcast or any other provider
and what all of those wires actually do and mean.
We show them on their Mac or PC incarnations of how
they're connected to the internet.
So we talk about IP, IP addresses, and DNS, and DHCP.
And if you yourself aren't familiar with that alphabet soup,
that's totally fine.
Again, taking the course is perhaps the best preparation.
And here is just a similar view on Windows.
And then, again, we keep this in context with which
students are familiar-- talking about home networks that
might have WiFi, that might have wired devices, that might have phones
or laptops or television set-top boxes, and try
to help students understand the technology they see
and/or use every day.
We spend time, too, on multimedia in this class.
And we introduce students to audio, video,
and other forms of multimedia as well.
And we give them a sense of how, for instance,
music might be synthesized, talking about formats like Mitty, which,
if unfamiliar, is a way of encoding music digitally,
so you can interact with it with a computer.
We talk about how images are represented.
Here's a 1-bit image of a smiley face using
just a single bit for black or white.
We talk about image compression.
So given an image like this, let me actually
ask the group, what might the opportunity here be
to compress an image like this if it's stored in a digital file format?
How might you go about compressing this apple that you see on the screen
here against this blue backdrop?
Any ideas or intuition for where the opportunity is?
Brett?
AUDIENCE: Yes, you could condense and consolidate the colors.
DAVID MALAN: Consolidate the colors?
Yeah.
AUDIENCE: So like all the same blue color
could be combined and just repeated.
DAVID MALAN: Yeah, exactly.
There's a lot of redundancy here.
There seems to be some common red, some common blue.
So you could effectively store that same image
by factoring out a lot of the common blue.
And instead of saying the digital equivalent of blue, blue, blue, blue,
blue, blue, blue, blue, blue, blue, blue, blue, and so forth,
you could just say blue 10 times, blue 10 times.
And just like it sounds faster, it would similarly take less space in memory.
Here's a clip from, for instance, a video.
And you have a bumblebee on top of some flowers.
And you can see that the flowers are not moving, but the bumblebee is.
And so here might be an opportunity to get
students thinking about how you can save space
by not repeating yourself as much.
And maybe you could in a video file format do something similar in spirit,
but only track the movements of the bumblebee.
And don't worry about redundantly storing those flowers because, again,
they appear again and again stationary.
Of course, it's quite common in TV and movies
to see ridiculous scenes like this.
This is taken from like CSI something or other.
And of course, the police or investigators
are able to zoom in on that glint in the person's eye
and figure out who the suspect is.
We point out to students that they're just
going to see generally a blurry mess.
And if you can see this on my screen, albeit a bit small,
there is really little identifying information of who the bad guy is,
at least from that frame in the show.
So we talk, too, in this class about security and passwords.
If you see any of your own passwords on this list, you're part of the lecture
now because these are the top 10 most common passwords as of a year
or so ago.
They're not particularly secure.
And so we talk to students about why they're not secure
and how they might use things like two-factor authentication
or other techniques to keep them secure, whether it's with their accounts,
or whether it's in WiFi.
And we also talk about issues of privacy, for instance,
by way of cookies.
You've probably heard that cookies somehow can
be used to track you on the internet.
We help students understand technically what that means
and why they're not all bad and actually do solve technical problems.
And then, toward the end of the semester in CS50T,
we introduce students to a little bit of web development.
And we start with HTTP, the protocol that moves the data back and forth.
But we also introduce them hands-on to HTML and CSS.
And we help them understand, too, really as a stepping stone to something
more like CS50 itself, that there's ways of representing
this information in different ways.
Just like you have a family tree where you might have these nodes,
and a graph with edges and circles or squares or the like,
we can see something like HTML code and start
to think about it in different ways, setting
the stage for more sophisticated discussions in a higher-level class.
And then lastly, we focus on programming with the students.
And we introduce them to pseudocode and searching the phone book, for instance,
algorithmically.
But we spend a good amount of time on Scratch.
And that is their only language in this course with which they experiment.
But they have an opportunity to apply those same ideas.
So if you're curious--
and again, these slides are on the website--
you're welcome to go to this URL if you'd like to see a sample assessment.
I'll go ahead and paste this into the chat window.
Actually, let me add the HTTP.
That's a sample assessment, but there are other assignments week to week
throughout the course, not just this end-of-course assessment.
But that'll give you a sense of the summative questions
that we tend to ask of students.
And they're similar in spirit to CS50's own in that they're
meant to be short answers or the like.
Before I give you a whirlwind tour of CS50B,
[? Hani, ?] any questions or comments?
AUDIENCE: I'm sorry.
This was back to the image compression.
DAVID MALAN: Oh, sure.
AUDIENCE: Of course, if you save the difference
between the pixels instead of the pixels themselves then you can save a lot.
DAVID MALAN: Yes, indeed.
So opportunities to talk about different forms of representation,
too, of the format itself.
So CS50B, for business.
So this course has a lot of overlap with the course's content,
but the target audience is a bit different,
and the mindset is a bit different.
So generally speaking, this course is taught to older students,
be they adults or students at Harvard's Business School.
But the goal there is not to just understand technologies that we see
and use every day in a consumer sense, but to understand technologies
on the basis of which you might make this decision.
So if you happen to be running a company,
or you're the CTO or the CEO or a manager or someone that
works with technical people, but isn't necessarily as technical themselves,
what do you need to know about technology in order
to just get real work done and hold your own in conversations
with more technical people?
So as such, it can be applied to younger audiences, certainly, as well.
So the six categories into which this course is structured
are a little similar in spirit, but these six here.
And let me give you a quick tour of those.
So we begin with computational thinking, not unlike CS50 itself.
And we help students think about how you take inputs,
and your goal is to get outputs, and in between there
are these things called algorithms.
But in the business version of the class,
we spend a bit more time on sophistication
of concepts like this-- so running time, and how
you think about not just whether or not an algorithm will
find Mike Smith in a phone book or solve some problem correctly, but does
it do it well?
Does it do it quickly and efficiently?
So you can start to think, as a business person might, in terms of cost,
in terms of time or money or the like, thereby
having all the more building blocks at your disposal for discussions
of trade-offs.
We talk about programming languages.
So here, we give students a sense of what's out there.
We don't teach them any of these languages in any detail.
We show them simple snippets, just so they
can understand what features exist in programming languages.
But as with the technology class, we use Scratch
because it allows us to explore a procedural language, as well
as a number of topics that they'll encounter in the real world.
Scratch, of course, supports things like events.
And anytime you and I use our phones these days,
anytime you touch your tap or swipe, those are all events.
And so we help students understand how these paradigms of programming
map to actual technologies they use.
We talk again, as in T, about the internet.
But we go into a little more detail into the alphabet soup
so that they understand the kinds of jargon that
might get thrown around by their own engineers,
whether they're a startup or a larger company that
just uses IT Infrastructure.
We introduce them to web development.
The goal is not to turn them into web designers,
but just so that they know what this HTML and CSS and other such tools are.
So we show them and allow them a hands-on opportunity
to play with HTML again.
But we also spend a bit more time translating Scratch to something
like JavaScript, a language that's commonly
used in the context of web programming.
So there, too, the students of CS50B have a mental model
of how more pieces of the puzzle--
no pun intended-- interconnect.
And then, quite different from CS50T, we talk about so-called technology
stacks--
like how all of the various technologies and acronyms and languages
and protocols somehow fit together.
And we break things down into front end, so to speak-- the part of the interface
that humans see.
And we rattle off, and we give them just some sense
of what's out there and in vogue these days in terms
of libraries and frameworks for front end technologies.
We do the same for back end, giving them a sense
of what languages are in vogue, what frameworks are in vogue-- not so
that they know themselves how to use them,
but just so that they know that, one, they're out there.
And two, if there's another one tomorrow,
it's not really that big of a deal because it
fits into a paradigm with which they've already had some comfort.
We talk, too, about databases.
And so middle tier architectures or, depending
on how you might want to think about the tiers.
And, again, some big-name products that they might know of in Oracle,
in MySQL, in others as well, just so that,
again, they've been exposed to these things.
Then we talk about mobile, too.
Especially in the context of businesses, it's
often a decision whether to have a website or a mobile website,
a mobile application.
Should it be Android or iOS or both, and the like?
And we help them think about the non-trivial costs--
again, in terms of finances or time or humans--
in developing solutions to all of those various platforms.
And we talk, too, about data itself and how you go about structuring data.
For instance, a spreadsheet, with which most business types might be familiar,
but we introduced them to SQL, which we don't do in the technology class.
And we introduced them to NoSQL, again, at a high level,
but so that they understand that it allows you to store,
for instance, in this case more structured data, and not just flat
row-by-row based data instead.
Cloud computing-- a topic, too, that's distinct to this class.
And we talk about some of the biggest players out there.
What can Amazon, Google, Microsoft, and others do for you and your business?
And we talk about some of the technologies and principles
that underlie cloud computing that someone has to understand.
And so we talk about scaling and replication and containerization
and virtualization-- a lot of the alphabet soup here--
so that, again, when it comes to asking questions of their engineers
or trusting in the correctness of their decisions,
they at least understand how their own servers or applications or products
work.
Even if it's at this level of abstraction,
they're not completely dependent on the technical savvy only of others.
So I'm a little worried this URL is not going to work either.
But allow me to--
oh, this one does work.
So this one is a sample assessment from the end
of this business-oriented class, if you'd like to take a look.
Again, I'll open up the other one in just a bit.
But again, the goals of the class are a bit different.
To recap, T is more about technology for everyone from more of a consumer angle.
B is more about business-type mindsets and how you might use technology
to make better decisions.
But the audiences can certainly be one and the same.
Before I forge ahead to a third and final precursor to CS50 itself,
any questions or comments here that I can answer?
No?
All right, seeing none, allow me to give you the third and final short-form
course that might proceed CS50--
CS50 for lawyers, so to speak.
So this course of the three we've now discussed
is a bit longer than the others with more detail
and goes into more discussion of topics that intersect technology with society.
The original target audience was, indeed, law students or lawyers.
But here, too, there are wonderful opportunities
I think for high school or even middle school level
to focus on some of those exact intersections.
And I'll give you a few examples of those.
In terms of the syllabus, it's a little longer,
and it's structured along the lines of these topics here.
But as with the business class, we begin with some commonalities.
We introduce students first to computational thinking, as before.
But we get them thinking more about representation of not just
ASCII or English, which had its start with just seven bits.
But we get them thinking about Unicode and larger character sets
and the implications for internationalization and representation
of other languages as well.
We talk about algorithms, but we also spend a bit more time
helping them think about some of the primitives that might
underlie how you implement algorithms.
For instance, we spend more time talking about abstraction.
On the screen here is, of course, what?
What does anyone see, if you'd like to shout it out or raise your hand?
Anyone?
Not a trick question.
AUDIENCE: A cube.
DAVID MALAN: A cube, I heard.
So it's indeed a cube.
And really, you know that, you say that, because we all have in our minds
the definition of some abstraction of what a cube is.
But frankly, what I am seeing is maybe three diamonds
that are all touching each other.
Or what I'm seeing is a diagonal line and another diagonal line
and two more diagonal lines that connect with each other.
And you can imagine really getting into the weeds of describing what you see.
But thankfully, as [? Momadu ?] notes, we have an abstraction known as a cube.
And so we get students thinking about the utility of these abstractions
versus the price you pay by not getting into the weeds of what
it is you're trying to say, and appreciating what computers can do
and can't do when it comes to following commands.
We talk about programming languages as before,
but we go into a little more detail in the context of the law class,
looking first at a higher-level language like C,
looking at a lower-level language like assembly language,
and looking at the lowest of languages, like machine code,
which is just 0's and 1's.
And we do this so that aspiring attorneys down the road
actually have a better understanding of intellectual property, what
it might mean for someone's code to be similar to another, what it might mean
for someone's algorithm to be identical to another,
just to that they have this bottom-up understanding of those principles.
And they don't have to just take for granted
that, oh, an algorithm is step-by-step instructions for solving some problem.
But what does that really mean when computers
and companies and owners and intellectual property gets involved?
We talk about the limitations of computers.
1999 was a problematic year, a.k.a.
Y2K, because so many companies and so many products
were using just two digits to store years instead of four.
And so bad things might have very well happened on scale.
We talk about floating point values--
numbers that have decimal points in them--
and give real-world examples where failure to appreciate
or failure to protect against these realities of computing
can lead to potentially catastrophic failures.
Here's a Boeing 737, I believe, that essentially would turn off
after 248 days in the sky because a 32-bit counter, a variable in memory,
would overflow potentially.
And bad things would happen.
And the solution in the short-term from Boeing
was literally reboot your planes every 247 days.
So we get students thinking about how software decisions and hardware
limitations might have very significant real-world ramifications.
We talk in a bit more depth about algorithms and data structures--
more similar, if you will, to CS50 itself and CS50AP.
We go into things like bubble sort, for instance, or selection sort,
for instance, or really sorting in general.
We talk about data structures as they are incarnated in languages,
like Python having dictionaries and lists and other such things.
And then we go into more detail on cryptography.
We, of course, spend a bit of time on this
in CS50 itself with Caesar or Vigenere or few such problem sets as well.
But we spend a bit more formality on this,
getting students thinking about what it means to encrypt information,
whether it's with substitution ciphers, whether it's
an attack on the same using so-called "frequency analysis."
And we get students thinking a little more adversarily about some
of the technology that they might build in CS50,
but might not necessarily think twice about at that point in the course.
We talk about what it means to hash passwords.
Not just encrypting data, but hashing them in one direction,
and what it might mean if a company's database is hacked or compromised,
and what the threats to a customer's privacy might be.
We talk about encryption a bit more mathematically, a bit more formally,
in the context of, say, public-key cryptography, if you're familiar.
And we talk about digital signatures, which
is sort of an opposite application of the same technology,
in order to prove mathematically that I am who I claim to be.
We intersect with more modern technologies like Blockchain
and cryptocurrencies like Bitcoin and the like and help students
understand what is interesting about those technologically
and what kinds of problems they can actually solve.
And we talk about cybersecurity in much more detail,
too, when we talk about how hardware itself--
what various hardware components inside of a computer do,
and which of those are potential threats to one's privacy if, for instance,
someone has physical access to the memory or some other device.
We talk about deleting files, be it on Mac OS or Windows.
And just emptying the recycle bin or trash can
is not really the best way to cover your tracks
or to remove sensitive information.
And we help students understand why.
We talk about how you might intercept network traffic--
everyone uses WiFi or mobile networks these days--
and what it might mean to use things like HTTPS for encryption.
And then we spend a bit more time intercepting things
like the primitives that underlie internet technologies as they
relate to bigger-picture uses of cloud computing.
And we talk quite simply about how you get data from point A to point B.
But then we start talking about how you get a lot of data from point A
to point B, maybe with one server initially,
or a bigger server as load scales.
And we talk about horizontal scalability, vertical scalability,
and the kinds of approaches you can take to solving some problem, even
if you're not an engineer yourself.
Maybe you're just the one with the checkbook.
But you need to decide, are you going to get a lot of really cheap machines?
Are you going to get a few really beefed-up machines?
And what are the trade-offs, being the operative word, going to be?
And then, again, we talk in a bit more detail about very modern technologies
like virtualization and containerization-- which, as an aside,
if unfamiliar, you've been using for some time.
Whether you use CS50 IDE or any other tools, they're out there.
And we help students understand those building blocks.
And then lastly, at the tail-end of CS50 for lawyers,
do we introduce students-- as often we do-- to a bit of web development
and helping them understand HTML.
We spend a bit more time on JavaScript and that event-based model
I alluded to before, clicking and dragging and changing things
on the screen, and how you write code to interact with humans.
We talk a bit more about database design--
so not just using SQL, but using it efficiently,
designing and choosing the types of your language more aptly,
and even more sophisticated techniques like transactions and locks.
How do you assure the integrity of your data,
especially when you have a lot of it coming in,
especially for popular websites and tools?
And then at the very end of the semester,
do we revisit and reconnect some of the topics,
talking about things like denial of service attacks on scale on the cloud,
talking about defenses or potential weaknesses like SSL or TLS,
talking about more precise attacks using code-- cross-site scripting attacks,
where someone tricks you into executing code in your users' browsers
that they provided to you.
Or something like a cross-site request forgery,
where you trick a user into sending a request to a website
that they might not have even intended.
And we talk, of course, about databases as well, and hashing those passwords,
and what that really means.
We talk about SQL injection attacks, threats against the same.
We talk about Man in the Middle attacks.
We talk about phishing and really a whole lot of technologies
intersecting with society.
And indeed, what we do at the end of the course,
particularly by way of a colleague of ours, Doug,
we start talking about really the real-world ethical issues
and the legal issues that result from these intersections.
And so we consider implications of open-source software and the licensing
thereof and what you need to be mindful of,
and what the trade-offs are of open-source software
that everyone can see, or closed-source software that no one can see.
Talking about disruptive technologies and things
that the law hasn't even caught up to yet.
For instance, being able to 3D-print guns that aren't even metallic
and can't be detected anymore-- what are the implications for society when
now, anyone on the internet can download something like that
and, resources permitting, just create their own threats?
Digital privacy and tracking certainly in the news,
and ever more so today when it comes to social networking
sites and the implications for humans.
AI and robotics are very much on the horizon.
And indeed, Brian, will soon introduce a course on the same
and what the implications are for users in society.
GDPR and data privacy laws here and abroad are germane as well.
And then Net Neutrality, which keeps coming up
from time to time, particularly within the US,
and what that means technologically, and what that means for users.
And here, too, I'm going to cross my fingers
and see if I gave the right permissions for this one.
This one, too, is successful.
So I got two out of three.
Let me give you this sample assignments as well.
And you'll notice the overlapping.
So, in fact, allow me in closing, before I turn the reins over to Colton,
just to give you a sense now of the similarities and differences here.
We've looked at CS50B and L and T here in succession.
And here is the same syllabi from each course, this time laid out
from left to right in the order in which we saw it.
And I did my best to color-code this to show
you the similarities and differences.
I realize the colors won't necessarily stand out well
for your eyes or your screen.
So we'll document this in another form, too.
But essentially, I used the same colors in each course
to indicate that there is significant overlap in those topics.
So both B and L, for instance, in pink, spend a good amount of time
on computational thinking, as they do on programming languages,
as well as programming.
So sometimes, the titles might differ, but the concepts are the same.
And so ultimately, each of these three courses
is available to be taught as OpenCourseWare, either as maybe
a freshman class, a middle school class that introduces students
to the world of computing and computer science,
or, as with any of the classes, you can pick and choose things off the shelf
and integrate them into your own class, be it CS50AP or something else.
But generally speaking, these are more conceptually-oriented classes,
more societally-oriented classes, and more introductory than something
like CS50X or, really, CS50AP itself.
Any questions or comments before we turn our attention
to what students and teachers can do after these on ramps?
AUDIENCE: I was just thinking that if there is a CS50 course for medicine,
my students would love it.
DAVID MALAN: So the one course we don't have, OK.
But we've actually been thinking about that, if only because Harvard does
have a Medical School.
But it does not, I'm afraid, exist yet.
Other questions or comments?
No?
Colton, would you like to take the floor?
COLTON OGDEN: Sure thing, awesome.
So thanks, David, for the introduction.
I'm going to talk about CS50G, or GD50, as I like to call it--
Game Development 50.
I'm going to switch my screen over here just
to have a slightly better view of the slides, here.
So GD50 is a continuation after CS50.
So the expectation by this point will be that students
do have some programming experience, be that through CS50
or through other equivalent courses.
And GD50 or CS50's Intro to Game Development is all about 2D
and 3D games.
So we spend a good chunk of the course going
through a lot of really famous titles that you probably
see around the screen like Super Mario Brothers, Legend of Zelda,
Angry Birds, Pokemon.
But we also do a little bit of 3D game development
at the very end in Unity Game Engine--
Dreadhalls, Portal, and a helicopter game in 3D being examples thereof.
And this course uses a couple of different programming languages.
And I think this is actually pretty important
because in real-world industry, it's pretty common
that between companies and even within the same project,
you'll be expected to use-- and even within the same game project,
for the sake of this course at least, you'll
be expected to use not just one language, but multiple languages.
So here, we have Lua and Love 2D.
That's what that symbol is there on the left-hand side
to represent the 2D section of the course.
And on the right-hand side, we have C # and Unity,
which represent the 3D side of the course.
So we start things off with Pong.
And this is a very quintessential, classic game.
But this really is students'-- we can presume many, for them,
their first dive into something as graphical as this.
And it made sense to take things in a progression
from really, really simple to more complicated.
And pong is a very suitable first example
as well because it's the grandfather progenitor of the video game industry.
So the sake of this example, really, is to showcase very basic things
like getting something visual on the screen
to begin with, where students may only have thus far done
textual CLI-based programming.
We have text being rendered on the screen, but not through a command
prompt.
And we have various things like game state, so managing what we're doing,
whether it's the beginning or the end of the game.
And this is a very common theme in programming.
And this is-- effectively, state machines
are an important concept in computer science, generally speaking.
We transition from that to something a little more visually interesting.
So this is where we can start to have students actually use their own art
or at least get a sense of how to do that
and have it actually move around on the screen.
So we cover things like delta time, which
just means the difference between two frames in milliseconds, which
allows us to then calculate things like gravity,
which is a frame by frame calculation.
After that, we go to breakout, which is a continuation of one and two--
rather, lectures 0 and 1--
Pong and Flappy Bird, where we've taken the basic idea of Pong,
and we've taken the idea of adding in sprites.
But we've also made the game a lot more complicated.
And this I like to use is an example of what's called procedural generation.
So we're doing things, not just necessarily putting
graphics on the screen, but talking about algorithms
that let us generate data or information to make games playable,
one iteration after another, which I thought was an interesting thing.
It's something that I'm personally attached
to with games and with programming.
And it makes things a little bit more, I think, rigorous.
And ties it to something that's not, strictly speaking, necessary to games
because you can do the same thing with a database.
You could generate your own database information
if you were testing something on the web, for example.
We go into match 3, which is a discrete style--
not really a board game, but it's a discrete style game where
you swap tiles and try to get matches.
And this illustrates a different kind of programming,
where you're looking at a finite space and trying
to calculate whether a particular rule or condition is met,
and then changing the game board, one iteration after another.
So it's just kind of--
at least with this example, I liked it because it was a popular thing.
Again, the whole idea or philosophy of the course
is that it should be a case study approach
to the course, where we have a full corpus of source code
that you dive into.
But it's also varied so that the students aren't necessarily
getting the same type of game throughout the whole course.
They're getting to sample the landscape, which
was a major design philosophy of GD50.
DAVID MALAN: Angela asked earlier, how many girls play these games?
And does the course cover the work issues that face game designers?
COLTON OGDEN: I imagine--
I haven't done the research to know the gender distribution.
I believe I read stats on mobile games-- in particular,
things like Candy Crush and many other types of games on mobile were very--
actually, I think more women played those than men, if I
remember reading a study about that.
I'm not entirely sure.
I don't want to say anything incorrect as regards that.
I feel like the games industry is a little bit more male-skewed.
Although I think within the last five to 10 years,
it seems like it has gotten a little bit more balanced.
But there's still a bit of a discrepancy for sure.
In terms of the workplace considerations,
we don't really cover that as much.
It's an interesting thing that would be maybe worth adding to the course,
actually.
But currently, no, we do not talk about that-- at least not in detail,
as far as I recall during lecture, unless it was asked as a question.
Sure.
DAVID MALAN: And Colton, [? Amira ?] asked,
is this course considered to be advanced?
COLTON OGDEN: I would say it'd probably be intermediate level.
It's hard for me to put a specific label on it.
Certainly, it's more advanced than-- well, I
didn't want to say it's more advanced than CS50 is because CS50's relatively
advanced for an entry-level course.
I would say it approaches the level of difficulty
maybe as the later stages of CS50.
In some regards, maybe slightly more difficult because we're dealing
with larger code bases on average.
Actually, most of the code bases in GD50 are
upwards of 1,000 lines-- maybe 2,000 lines of code.
And this was deliberately the case, because at least with the design
philosophy that I had going in, I did not want--
or as I was learning game development, it
was very hard for me to find large code bases
like the complete picture of what a game is
and how all the pieces worked together.
I could very easily find tutorials online
that would illustrate one concept, like how to move something on the screen
or how to transition between two different scenes, maybe.
But very rarely would I actually have a full code
base that was representative of what an entire game might look like,
or at least a proof of concept there that was relatively fleshed out.
And you could easily add more content to it to make a proper, full game.
So yeah, in that sense, students will be expected to navigate large code bases.
And the assignments therefore are a little bit smaller than obviously
implementing an entire code base.
They're usually adding a small feature.
For example, in Pong, the objective for the student
is to just simply add an AI to the paddle
on the right-hand side that lets it track the ball
or have some behavior that the student wishes, whether it's
to make it behave somewhat like a human or to be infallible,
which is often the case.
But, yeah, generally, that's the case--
large code bases to navigate, which might be a difference from CS50.
But the assignment rigor in and of itself
is probably comparable to mid to late CS50 in difficulty.
DAVID MALAN: And Steve, to your point about it being too advanced
for middle schoolers, it does assume, to be clear,
as will Brian's classes, that students have taken
CS50 itself or some equivalent.
So it assumes that degree of comfort and sophistication out of the gate,
to be clear.
COLTON OGDEN: Indeed.
DAVID MALAN: Colton, back to you.
I think we caught up.
COLTON OGDEN: Awesome.
Thank you so much.
So I was talking about Super Mario Brothers,
which was the influence of the course from the very beginning.
I probably mentioned all of that stuff.
But the big thing that I wanted to hammer home
was the idea of illusions-- how games in and of themselves
usually are meant to trick us into thinking
that we are in a particular place or doing a particular thing
as a particular entity.
In the case of Super Mario Brothers, in this case,
at least we are typically rendering the entire thing at once.
But typically with games, outside of the camera bounds,
you will not have tiles being rendered to save on memory
and to save on rendering-- for the GPU you to not have to render more texture
or bits of textures.
In the case of Flappy Bird, if you were to zoom way out
of the example of Flappy Bird, you would see these long weird pipes,
and then just a simple image that was infinitely scrolling to make us
feel like we're actually moving through space.
But in fact, we're not.
And actually, the pipes are getting generated and shifted back and forth
around the screen as needed to get the effect that we're looking for.
So that was it for Super Mario Brothers.
Now, let's go over to Legend of Zelda.
So Zelda is a another game of that era where it was released for the NES.
And it has a similar almost aesthetic of the era.
But this gives you really a top down games.
And the real purpose of this lecture, amongst a couple of little minor things
that we talked about graphically, was that we
wanted to discuss how we could model things like creatures as data.
So we could have these things like these ghosts and these spiders
and these slimes actually modeled in a config file, more or less.
And we would just dynamically load them in, rather than
have to write a lot of different logic or repeated logic
or use a particular inheritance in the object-oriented sense, an inherited
class, to model all of these individual creatures.
So data-driven design is a big aspect of this lecture.
And I want to believe that that applies to a lot of domains,
just like a lot of these other concepts do,
beyond the world of game development, like in web development, for example.
We transition completely in a different direction
here to Angry Birds or an Angry Birds style game using physics, 2D physics.
Box 2D would be the name.
And this was more to give students a taste of a different outlying genre
and a different way of building games because building games with physics
objects is very different than a lot of what
we've covered earlier in the class.
So this is, again, part of the idea of giving students
just a wide taste of the landscape as befits game development.
And here, they learn things like how to model different types of shapes
and how they interact with each other.
In this case, we have this little barricade here,
represented by these wooden boxes.
And then we have the characters themselves,
with a model trajectory here, in which case they'll collide with that.
Following that is our last 2D game, which is Pokemon, or a version thereof.
Again, everything with this course is all public domain sprites by design
because we don't want to infringe on anybody's copyright.
But here, this is very similarly modeling
off of Pokemon, which was a very famous game in the late '90s,
where you capture these little creatures.
And you can fight them back and forth.
And this was to help with a few different things, particularly events
and callback functions, which is a big aspect of asynchronous programming.
And also higher order or functional programming,
which was a different paradigm that students might not
be super-subjected to until they've maybe taken CS50,
because I believe with CS50, and at least JavaScript, there
is a bit of that.
But here, Lua, because it's a dynamic scripting language,
it does have these features actually very similar in a lot of ways
to JavaScript.
So Lua gives us the option.
We can both test not only turn-based combat systems
and the idea of two entities taking turns and making decisions
back and forth, but also a different way of thinking about programming, which
I thought was important to illustrate.
And then following that, we actually transition to Unity 3D.
And this was by design because it was a nice way
to get students to use a real-world toolkit.
Not that Love 2D isn't real-world, but Unity in particular
is not only a game engine, but also one of the most widely used game
engines in the modern game development ecosystem.
And by doing that, we let students actually
use the tool that's highly in vogue and get real-world skills,
not only just use things that are in a model or mock environment.
And that's also, again, by design throughout the entire course
to give them a larger code basis to work with.
So here, we are creating just a simple helicopter game.
It's actually almost like a 2D game in and of itself.
But we have helicopters and planes and the like moving around.
So we're using models.
We're doing basically just a tutorial on how to use Unity for the most part
and get our minds thinking in 3D and using models
rather than using 2D and sprites.
Following that, we do a first-person horror game.
So this is Dreadhalls, which we actually played in the office
on a VR headset, which was a great time.
And here, we talk about first-person games.
And this is very different, obviously, from anything
that we've done in the course.
Now we're actually doing or beginning to do something
that's unique to the realm of 3D games.
It's something that we couldn't-- unless we used faux 3D--
2D-style implementations, something that we could not
do in 2D that we can now do using Unity and 3D--
that idea of navigating a world, an actual world, and feeling like we're
an actor or an agent in that space.
And here, it's really just a horror game, and then to model that idea.
But it's a big step.
And we can talk about things like how to model
a character moving around and interacting with things
and colliding with things.
And this is applicable to all kinds of different things.
I even taught a seminar on--
a workshop on how to use a lot of these same ideas
just to create a museum navigational tool, which
illustrates just how powerful Unity is, even
outside the world of game development.
So if students want to maybe learn the principles here,
they could take this idea and apply it to all sorts of domains.
This doesn't have to necessarily strictly be creating games.
It could be any type of multimedia.
And then the final lecture of the course is a evolution
of that last process, where we're actually implementing a first-person
shooter, but not in the traditional sense of the term,
but rather a clone of the game Portal, which involves a portal gun, which
shoots just these portals on flat surfaces
that you can then walk through and then jump out the other side.
This was meant to involve the player in a little bit more
of the technical aspects of using Unity-- things like rendering textures,
casting rays from the point of view of the camera,
and then finding what the nearest collidable surface is-- things that
would allow students to not just simply create a thing to walk around,
but that can actually interact in dynamic ways
with the surfaces in their game world.
And that's basically it in terms of the curriculum for the games course.
Again, it's meant to be a case study approach,
where the concepts and the ideas and the curriculum or the subjects
therein are introduced in an organic way to make it feel like they're navigating
the process of becoming a game developer,
less so than they are maybe learning it in a traditional, more
austere sense of the term.
It was a philosophy that I personally wish
existed when I was learning how to game program.
And so I figured it would be a nice thing to try out.
So yeah, that was it for the game syllabus.
And I think Brian is next, but I'm happy to take
any questions if anybody has any.
SPEAKER: Some questions that came up in the chat, Colton--
Peter asks, "What development environments
are used for the courses on CS50 IDE?"
COLTON OGDEN: So currently, no, it's not in CS50 IDE.
We expect the student, at least for the Love 2D section,
and even for the C # and Unity section, to use a tool called VS Code,
which is a very popular text editor which has actually integration with
Love 2D, where you can just press Alt L or Command L,
depending on whether you're using a Mac, to actually fire up Love with
your current project loaded immediately.
So you just very quickly test back and forth whether your code is working
or not, which I personally really enjoy.
And I use that almost exclusively.
And Unity has its own built-in IDE, more or less, with at least all
of the visual aspects of things, although it still
defers ultimately to a text editor for you to write your code.
But you can set it up to use anything you want to,
whether that's VS Code or Sublime Text or the like-- even Text Edit,
if you are so inclined.
SPEAKER: And prior to that, also from Peter, "Love 2D has been updated.
The distro in the course, this is an older version.
[INAUDIBLE] update with the course plan?
COLTON OGDEN: That is correct.
Yeah, the current distro that we are using is for 0.10.2,
which is mentioned in the assignment.
Although we will be making an update to the upcoming semester
that makes it compatible with 11.3, which
is just a series of essentially copy and paste across all of the source code.
SPEAKER: And Ty asked, "Are you planning to teach programming in Minecraft?"
COLTON OGDEN: Programming in Minecraft?
You know, that would be fun.
I am personally a fan of Minecraft and all of the crazy things
you can do in Minecraft.
You can use-- you can do it the crazy way,
which is where you actually build computers
using redstone or using electricity or electrically modeled blocks.
And that will take you a tremendously long time.
Or you can do it through something like ComputerCraft or CC--
I forget what it's named these days.
But it's essentially-- it actually does run, if I remember correctly,
a Lua interpreter in one of the blocks in Minecraft
that is actually a computer.
That lets you interact with things in the game.
So it actually is an excellent way, I think,
if you have the right environment and the right exercises,
for a student to learn.
Haven't thought about using it for CS50, but maybe it's
something to think about.
DAVID MALAN: And Joanna, in answer to your question
about using Scratch for games, it's not something
that we use in the games class.
It's something that can certainly be used in the technology class,
for instance, or CS50 itself.
And then Angela, your question, "Is there
a discussion about the violence and illustration of women in games?"
Not something that's covered in this class, which takes
a purely technical approach to it.
But those would be the kinds of materials
that we're working toward building out for more discussion-oriented classes,
as teachers might use it in high schools or college classrooms.
COLTON OGDEN: Yeah, good point.
And yeah, the course does not have any of those topics.
Also, I included all the games that are very family-friendly.
DAVID MALAN: All right, Brian, should we turn the reins over to you?
BRIAN YU: All right, thanks, Colton.
So the final two classes that we'll be talking about--
one is about web programming, and one is about artificial intelligence.
Both of these classes are designed to be taken after students
already have the prior experience from CS50 itself.
These classes build on top of CS50 and explore a little bit
further what you can do with programming and what
you can do with computer science.
So just a whirlwind tour of these classes.
First up-- and it looks like we'll probably
go a couple minutes past 2 o'clock Eastern, if that's all right.
But we'll try not to go too far over that time.
But as for the web programming class, the topics
that we cover, we start by introducing HTML and CSS in much the same way that
CS50 itself does, but also introducing some
of the more recent features of HTML with regards to video
and with regards to handling large amounts of data,
just to make the process of building websites a little bit easier.
After that, we turn our attention to Git,
which we've mentioned a couple of times now throughout the workshop.
Just a version control tool popular across all of programming,
but web programming especially, just for keeping track of changes
you might make to a web application over time--
how to do that effectively and how to be able to manage different parts
of the program at the same time.
After that, we introduce students to Python in particular,
taking a look at the Python data structures
that you can use in order to represent information in programming,
taking a look at things like lists and dictionaries and sets
and how you can write functions to manipulate these data structures.
And then, in particular, in the next part of the class,
we introduce a programming framework called django.
So if you've taken CS50, you might be familiar with Flask,
which is a web framework.
Django is a very similar framework, but has--
it's a little more full-fledged, has more features to it,
especially when it comes to building web applications
that deal with storing large amounts of data.
So when you're dealing with applications that
have lots of users that have accounts, where those accounts
are storing information, django makes it very easy
just to set up a web application so that you
can focus on the interesting parts of building the web
application without worrying too much about the underlying details
and implementations there.
No relation to the movie in the name of this framework.
After that, we take a look in particular at SQL
and how you can use SQL to be able to build a database that
works with your web application.
And here, we talk about the various different parts
that a web application might have-- the front end that the user sees,
some of the more controller code that operates how the web application really
works, and then a database that web application might be connected to.
And we explore some of the tools and ways
that you can have web applications that interact with those databases.
Following that, we introduce the second of the programming languages
that are covered in the course--
JavaScript.
In particular, using JavaScript to build user
interfaces-- so using JavaScript on the client side.
In other words, running inside the user's browser,
whether that's Chrome or Safari or Firefox,
to be able to make web applications a little bit more interactive so that
things happen when a user clicks somewhere.
So that when a user gets a new message, for example,
they might see a notification window pop up, talking about some animations.
Things like infinite scroll-- if you're scrolling through Twitter or your news
feed, you'll often see new data appear as you continue to scroll.
We talk about some of those implementation details
and how some of the modern web works.
And then after that, we go into some best practices
for building web applications-- things like testing and CICD,
Continuous Integration and Continuous Delivery,
which are ways of allowing it such that when you're building your website
piece by piece, your web application doesn't need to just update
once a month or once a year.
But you can continually update your web application so that every time you
make small, little changes, your web application
can update for all of your users as well.
And then finally, we talk about what might happen
as your web application starts to grow.
Talking about issues of scalability and security,
thinking about when your web application gets too big for just one web
server to be able to handle all the users.
How might you scale that up to have multiple servers
and balance between those?
And what are the security implications of doing
that sort of thing and security ideas that you have to be mindful of?
This is a very project-driven class.
So throughout the class, there are various different web applications
that students create.
So they start by re-implementing something like Google--
just a search engine where people can type in something
and see a whole bunch of search results.
And each of the course projects in this class
is modeled after a popular web application
that students might have seen or interacted with before
so that they get an opportunity to try and better understand
how the web applications they interact with really work.
So next up, they build a wiki, sort of like Wikipedia,
where users can edit new pages, create new pages,
and search for various different wiki pages that might be on the internet.
After that, they build an e-commerce website,
sort of like an Amazon or an eBay, where students
can build a website where users can log in, put up items for auction,
and bid on those listings.
And then the highest bidder wins at the end of the auction period.
Then they implement a variant of Gmail, where they effectively
build a mail client where you can have an inbox of all your email messages.
And then you can send emails and receive emails as well,
before finally building a social network, effectively like Twitter
or Facebook or something like that, where users can make posts
and comment on those posts and heart other posts,
for example, just to get a sense for the various different types of web
applications that are out there and the types of things
that you can do with those web applications.
And then at the end of the course, we have
students build a final project of their own choosing, where they just
pick some web application they would like to create.
And we give them the tools and the resources
to go and create that application, at a database to it, add a front end to it,
and try to make it a little bit more interactive.
So that, then, is a brief tour of the web application course.
The question is, how long is each of the courses?
Generally speaking, the courses are designed at Harvard to take
a semester-- so something like 12 weeks' worth of time.
But certainly, they can be adapted to work at other paces.
So often, even though CS50 and the web programming class and the AI class
are all designed to take a semester here at Harvard,
I know that oftentimes for CS50 in particular,
you might stretch that out to cover one year or even two years, potentially.
And so that can make things a little bit more manageable--
the pacing is a little more easily.
Are tools like submit50 used in these courses?
Yes, you can use submit50 with these courses
as well for submitting work and collecting that work.
Where are the databases and the website hosted?
Ultimately, there are multiple possibilities,
though the popular one that we recommend is
a service called Heroku, which just happens to be
one of the easier services to set up.
You can set it up for free, just to take a web application and a database
and put that online.
But there are other options available, and we talk about some
of those in the web programming class, too.
We don't talk about Firebase, though we do talk about other libraries.
In particular, this version of the class talks a little bit
about React for front-end development and for designing interactive user
interfaces as well.
All right, and with the last few minutes,
I'll just go ahead and talk about CS50's Artificial Intelligence
with Python, CS50AI, another course that's designed to be taken after CS50.
And the important thing that I'd like to mention here
is that while most artificial intelligence courses, if you find them
online, require a fair amount of mathematical sophistication
and background-- require knowledge of calculus,
require knowledge of linear algebra, which is involved
in a lot of artificial intelligence.
We made the intentional decision in this class
to create an introductory artificial intelligence class that doesn't
require that mathematical background.
So there's no need to know calculus or linear algebra
to be able to go through the curriculum in this class.
The prerequisite really is prior experience programming
in Python, which is assumed for the class.
But we introduce the mathematical details.
There is some math we talk about.
We talk a little bit about formal logic.
We talk a little bit about probability and statistics.
But we introduce those ideas in the class,
and we don't assume any higher level math that other artificial intelligence
classes you might see do.
So the topics we talk about are, first, how to search for answers to problems.
How does AI do that?
How does it look for how to win in a game,
for example, considering all the possibilities in that game?
Then we turn our attention to the question
of how it is that artificial intelligence can represent knowledge.
How can AI store information?
And how can artificial intelligence use that information
to draw new conclusions?
So we talk about things that AI can be certain about.
But we also talk about things that AI can be uncertain about.
If artificial intelligence might know something with some probability,
but not be entirely sure, how does it deal with uncertain events
and trying to deal with that?
We then turn our attention to optimization.
So if there are many possible ways to solve a problem,
how can our AI find the best solution?
If there are many possible ways to--
this is useful for things like if you're planning a city, for example--
trying to plan where the hospitals should be.
How do you optimally place the hospitals,
so they're in a useful and practical location?
These are the sorts of problems that we try to take a look at.
And then in the latter half of the class,
we turn our attention to machine learning.
So we talk about machine learning, what it is.
What are the different types of machine learning,
the different types of problems you can solve using machine learning?
And in particular, talking about the sorts of tools that are often
used in machine learning, in particular focusing on things
like neural networks, a very popular model in machine
learning where you try and design an AI system that's modeled on the way
the human brain works, with these neurons
that are interconnected and connect to each other in order
to try to draw conclusions.
And then finally in the class, we turn our attention to natural language,
thinking about how do we get artificial intelligence
to speak the language of humans?
To be able to understand our language?
To be able to respond to our questions?
And how things like Siri and Alexa and other voice assistants on your phone
or on your computers might work.
In the process, we introduce students to a number of tools.
Of course, the Python programming language, which we
use for the entirety of the course.
But also, introduce them to some common Python
libraries that are used for things like machine learning,
such as scikit-learn, a popular Python library for machine learning,
as well as TensorFlow, a popular library for building neural networks.
And the advantage of this is that students
get an opportunity to build their own neural networks
without needing to implement all of the math behind the neural network.
That normally, to build a neural network,
there is a lot of linear algebra and optimization involved.
And here, students can really just focus on the problem
that they're trying to solve, without having
to get too deep into the mathematical details that are underlying it.
So just to give a taste for some of the projects that students complete,
they start by building a game engine.
We have them build a tic-tac-toe player so that they can
play against the tic-tac-toe player.
And ideally, they should be able to build
a tic-tac-toe program that never loses.
It should either win, or it should be a draw.
But the tic-tac-toe player should never lose.
We then introduce some logic-based thinking,
trying to build an AI that can play a game like Minesweeper
to try and logic their way through where the mines might be
and which cells might be safe, if you're familiar with that game.
Then we have the AI do some things that are more creative--
have students build AIs that write a crossword puzzle, for example,
to be able to fill in words into the appropriate places
and to try to do so effectively.
And then when we turn things to machine learning,
things get even more interesting.
And we have students think about self-driving cars and the implications
of those and what might go wrong.
In particular, asking students to build just a small part of self-driving car
software-- building software that can look at a street sign
and identify what kind of sign it is based on the street sign.
So learning to look at an image and try and learn from that image
to figure out what that image might be.
So that was just a whirlwind tour of what's
covered in the artificial intelligence curriculum.
But in short, we use Python throughout the entirety of the course
to try and build these artificial intelligence systems.
With all of the projects, we give students
a fair amount of distribution code.
So they're not building the entirety of the project
from scratch, which might be quite a lot.
But usually, we give them the framework and the structure,
where students are then adding in the functionality and the capabilities
into the program to make the program a little bit more intelligent.
So I'll pause now, if there are any questions about the web programming
class, the artificial intelligence class, or really, any of the classes,
now, as we get ready to wrap up this session.
DAVID MALAN: Brian, Bret asks, "I understand
the AI program is intended to occur after CS50X,
but would it be possible for students to go through the topics
without that background?"
BRIAN YU: Potentially, yes.
So the projects all require Python and will
expect that students are writing programs in Python
but the lecture is material is all designed such
that you don't necessarily even need to know
how to program to be able to watch the lectures
and just get an understanding for how it is that this AI works.
So I could see multiple different approaches, here.
You could use the curriculum as just a way
of introducing the principles of artificial intelligence--
what machine learning is, how some of these artificial intelligence
things that you encounter in the real world might work,
without having students actually get into implementing
the AI for themselves.
But for students who are a little bit more
advanced, who might have a bit more programming experience,
we do have these projects available just to allow students the opportunity
to create AI of their own, if they would like to.
DAVID MALAN: And Glen, ask--
he has a similar question.
"Is it possible to run one of those classes--
web AI, game dev-- as a quick intro, and then
maybe cover fewer projects to make up the difference?"
BRIAN YU: Yeah, absolutely for both--
for, actually, all of the follow-on courses,
really, they're very much divided into different topics, such
that it is possible to pick and choose certain topics that you'd
like to talk about without using the entirety of the curriculum.
So certainly, all of the curriculum is available as OpenCourseWare.
But you can pick and choose what you like and adapt
the course in the curriculum for your own liking as well.
DAVID MALAN: And John asks, "Any words about CS50M?"
which is a mobile app development course that a colleague of ours
taught a couple of years back.
We're probably not planning to bring that back too soon.
That material, more so than any of the classes,
has drifted out of date the fastest by nature of the tech industry evolving
so quickly.
There's also more challenging issues of access
to hardware for that class for students, or requiring that certain software be
installed, which is not necessarily within the grasp of teachers
with system administrators and schools.
So it's probably not coming back too soon.
But we have not ruled it out entirely.
Gloria asks, "Are there any promotional materials that show
sequences and course descriptions?"
We do have introductory videos for each of the classes.
We will share those out via email, if we may.
They're also on all of the OpenCourseWare sites.
So I'll probably send over those URLs as well.
All right, well, I think we're indeed running a bit late.
My apologies.
But coming up next in just under an hour will be our final session
all together--
Teachers Teaching CS50, with Margaret, with Jenny,
and Douglas, all teachers themselves, moderated by Jason.
And we'll use that time for Q&A as well for some final connections and closure.
And then we'll be sure to stay in touch in the days to come.
So why don't we go ahead and officially adjourn here?
Please feel free to stick around.
We'll turn on some music if you'd like to ask
us questions or chat with each other.
But we'll resume at 3:00 PM Eastern.
Thank you to Colton and Brian.