>> All right.
Welcome to Computer Science 164.
So before we dive in with an overview
of what the course will be about this semester and a bit
of material in this first day, I thought I'd give you a sense
of how we spent last night.
It's not so much as server-side challenge we faced
but a client-side one.
So have any of you discovered this particular website just yet
or Canvas which some Harvard courses are now moving to?
So iSites is about to die a slow death if you've gotten attached
to it, it's likely to be replaced with Canvas.
And so we thought we jump aboard and be part
of this beta test using Canvas which is an open source tool.
It's sponsored by a company called Instructure.
So there's a corporate backing behind it.
But for the most part we're using it in this way.
But last night when we were trying
to get the courses website finalized, we ran into a lot
of frustrations because this is a learning management system
which means it's a piece of software
with which you can manage content
by using web-based interface.
You don't have to use arcane configuration files.
You don't have to know anything about databases,
it's pretty much point and click in a way Google sites
or something like that might be.
But as a result it was damn hard to do something simple like--
let's go to the courses website.
Now, just put Menu options in this left-hand side.
Case in point, there's nothing there actually right now
because the way the software is designed is that if you want
to install things in your left-hand menu,
you have to actually install these modules
or applications in the software.
And we don't want to do this.
We just wanted a link to like the syllabus.
We wanted a link to the staff.
We wanted a link to videos and the like.
So if you were faced with the websites,
it's from third-party website
but you have no control over the source code.
You have no access to the server, you can't SSH,
you can SFTP, all you can use is the local web interface
and you want to start changing
or altering the user interface via other means.
What might your first instinct be?
What questions might you ask of Instructure in this case,
the company so that you can kind of work
around these limitations like we did?
We want to add menu options
but we can't change their server code.
So what solution might that hint that?
Yeah.
[ Inaudible Remark ]
OK.
[ Inaudible Remark ]
Yeah. So we could consider something
like a Chrome extension.
If not familiar, a Chrome extension is essentially a piece
of software from the Chrome browser generally written
in JavaScript.
And it's just a way of injecting code typically JavaScript maybe
some CSS into a web page that you visit.
Whereby the Chrome extension is just constantly monitoring what
websites you visit and trying to detect.
Oh if you're facebook.com do this.
Oh if you're in isites.harvard.edu do this.
So those of you who might have used CS50's 2x plug
in that allows you to speed up videos is exactly that.
So that's interesting and it's kind of on the right track.
Because if you don't have access to the server, you just want
to somehow change the DOM the tree that the user is seeing,
you can pretty much only do it client-side.
Now of course an obvious catch
of using a Chrome extension is what?
Right. So not everyone is using Chrome and if feels kind of lame
if you sort of have to mandate that all
of your users can only use the website
and see Menu options if they have Chrome.
So what else might we might we want to ask Instructure?
>> So one thing is I guess you can probably add a text
on the website, right?
>> OK.
>> Find out if you can actually put HTML in text.
>> OK. Good.
So we could ask them if we could put HTML in the actual text.
So rather than post a textual announcement, can we add links?
Can we add images?
Can we add bullets?
Anything that we might want to do aesthetically.
And the short answer is yes.
There is indeed a sort of WYSIWG,
What You See Is What You Get editor that comes
with this particular piece of software
that allows you to edit.
Things like the home page with my name and Rob's
and Tim's and so forth.
And that got us part of the way there.
Unfortunately that doesn't let us put anything here
for instance.
That doesn't let us put anything here because we're constrained
by what the original authors wanted us to do.
So we're one step closer.
What else might we ask the company?
What are the other workarounds perhaps?
It's got to be solvable.
What else might you do?
So you were on the right track with this notion
of client-side JavaScript injection.
How else might we get JavaScript into the site perhaps, right?
'Cause once you have JavaScript,
you can pretty much do anything even if your experienced
with JavaScript is limited to 50 or some other prior experience,
you know, that you can traverse the tree
that is a web page, the DOM.
You probably recall that you can add nodes or remove nodes.
You can inject things into a web page.
In fact that's exactly what the CS50 2x plug in does.
It rips out the iSites' video player and puts
in a different all together.
So what if the company Instructure allowed you
to inject the JavaScript into your course website?
In other words, what if they allowed you via their GUI,
their WYSIWG interface to paste the URL of a JS file
and maybe even a .css file and then they took care
of the process of inserting it at the very top of every page.
So sure enough, this was the only way we were able
to achieve this.
If I view the page source here-- and let me zoom in and search
for cs164.net which is a domain we the course own.
Notice that via some series of steps, it took a while to figure
with their documentation.
We we're able to say, atop every web page what Canvas outputs
for this course, output .css file.
And if we do another command f and search a little further,
you'll see that down here,
nested with in some JavaScript code there's also mention
of this URL here.
So in other words, we sort of have tricked them
into injecting whatever CSS,
whatever JavaScript we want into the website.
So that then begs the question, what does it do?
Well, let's go ahead and just grab this source,
paste this up here.
It's forbidden because to simulate this,
I chmoded [phonetic] everything.
So let me give that back.
Read access and now reload.
So what did we do?
So, you'll get better at this particularly mid-semester
when we spend a lot of our time on JavaScript.
But what does this appear to be doing?
So one at the very top of this JS file which again is included
in every web page that the course now runs on the website.
We checked to see if the type of jQuery is not undefined.
So in layman's term what does that mean?
What would it mean if jQuery is undefined?
Well, you do have JavaScript loaded.
You don't have jQuery loaded.
So we're just hoping that Instructure,
the company actually is using jQuery themselves.
Otherwise, we would have to paste the jQuery library on top
of this file so as to have access to it.
And this isn't because I simply want to have access to things
like the dollar sign notation and other functionally
that comes with jQuery.
If you recall this library and if unfamiliar
or if it's been a while, rest assured we'll come to this
with in a few weeks time.
So what are the things we're doing here?
So for those that might recall, what does this syntax here mean?
When you just pass an anonymous function or lambda function?
In CS51 speak to the jQuery function like this.
When is this code going to get executed?
Yeah.
[ Inaudible Remark ]
Exactly. So this code by nature
of this default function call is only going to get executed
when the DOM so to speak is fully loaded.
All of the HTML top to bottom, left or right has been read
into memory and there's some tree structure inside of memory.
Now this is good because if I want to start playing
around with it and changing the Menu options, removing things,
adding things, I'd better wait
until at least the default DOM is in place.
So this is just standard jQuery syntax.
It's equivalent to saying when the DOM is ready.
And now it's really just a combination
of jQuery syntax and some HTML.
So for instance, I decided that this was just bothering me.
No one on campus says, oh, are you taking Comp Sci 164,
or Comp Sci whatever, you say CS164 or CS whatever.
So minor little nuisance, we want to change that,
so how might we do that with something like JavaScript?
Well, notice, if I go to the page here
and atop the page, previously was CS164.
If I open up Chrome, which is a useful browser
for doing DOM inspections and you zoom in here.
Notice that inside of this HTML was an element that had an ID
of breadcrumbs and that ID does what?
It uniquely identifies one of those nodes in the tree
and as soon as I have the unique identifier for some chunk
of HTML in the DOM, now I can do anything I want
with this web page.
I could delete every DOM node.
Every HTML tag from the page and put anything that I want
but needs we're fairly humble.
I simply wanted to for the snippet of code here.
I wanted to first find the section tabs header
which was one of the parent elements just above that.
And I wanted to go ahead and change--
I wanted rather change the contents
of that via this HMTL function to a link to CS164
and then I wanted to alter the CSS on it
to have a font weight of bold.
And we won't go into great detail on the rest of this here.
But notice this line here.
I did a global replace everywhere.
Essentially saying, anywhere you see a span
that has a class called ellipsible,
that's not a standard thing,
that's just what the Canvas software calls certain classes.
If it contains the key phrase COMPSCI164 go ahead
and replace the HTML inside of any such span with just CS164.
And the rest of this is fairly well commented.
But at the end result, what I'm doing is manually with Chrome
or any browser figuring out what the unique identifiers are
various DOM nodes in the tree and mutating them
in the way that I wanted.
And the end result, now that we chmoded things correctly is
that now I can put an arbitrary chunk of HTML over here.
I can rip out things like the footer.
I can rip out HTML over here and I should wave a huge disclaimer.
This is a complete hack
to be implementing a website like this.
But it sort of speaks to the thought process
that should toward the middle of the semester,
especially when we spend time on JavaScript get you thinking
about how you can solve various problems hopefully better
than in this way.
But the ingredients for solving a problem
like this really just reduced to some basics.
Opening up to something like Chrome's Inspector
and understanding what the DOM tree is.
Knowing what the CSS selectors are
for unique IDs or for class names.
Knowing some syntax whether it's in JavaScript pure
or in jQuery the library to actually change the DOM.
And at the end of the day, we're pretty much able
to bend the software to our will.
But there's probably a catch.
What's the price we're probably paying for this complete hack?
What's the risk?
Yeah.
[ Inaudible Remark ]
Exactly. If Instructure renames one of their classes
or renames one of their IDs or just rearranges their HTML
which is totally their prerogative,
all of this could break and then one of us is going to have
to notice it or one of you guys is going to have to report
and we're going to have to think over that again.
So maybe not a huge deal but still a threat.
What else could happen?
What else is bad about this approach?
It's less common these days.
Yeah. It's a little slower in that--
rather than just get the original source from the server.
You're now making additional changes client-side.
And indeed if we had a so much slow internet connection,
you would actually see most likely some flashes
on the screen as DOM nodes are changing.
We just happen to have a connection,
a pretty fast computer and so it's fairly elusive to the user.
But what if they have JavaScript disabled?
Now this is an extreme corner case these days.
Most people are-- the majority when they leave JavaScript on.
But if it's off what happens?
We don't see any of that whatsoever.
So in short, relying on JavaScript for something
like this gets the job done
but the takeaway is how we went about dong this.
And you can see for yourself just by viewing the source
and then poking around at any of the two URLs on cs164.net.
How we actually did this?
But its illustrative of how you can start building more
interesting DOMs and even in the case
of dynamically driven websites like the Facebook application,
or GChat or the like that are constantly pulling in more data,
how you can actually change that interface.
But now, let's look at the right way to start doing things.
So this year, the course, unlike two years ago
when you guys primarily in PHP for the first half
and JavaScript for the last half whereas two years ago,
we focused more on mobile with a bit of PHP, this year,
we decided to change things to focus more
on web-based applications.
Implemented not in pairs of people
but in teams specifically teams of four
and the motivations were several.
But among them were that,
with a team of four there's just a lot more pieces you can bite
off as a group.
Doing web developments tends to land itself to different aspects
of the project that you can then delegate among your team.
For instance, we'll likely have one or two of you
in a given team working on the front end, the JavaScript code,
the CSS, the aesthetics.
On that same project another one or two of you will focus
on the back end, the database schema design, the validation
of data, writing the API that the front end people will work.
And so we just got a lot more breath of opportunities
for people to collaborate.
And so you'll find if you've done projects
with just one partner in the past,
that with four it'll be a little more challenging,
more interesting but a lot more powerful to have all
of you guys collaborating together.
In terms of the prerequisites, we likely will stick with these
for the catalogue four prior CS courses.
And this is based on experience.
A couple of years ago as alluded to you earlier,
we pretty much allowed anyone who took just 50
or maybe some class in high school to take the course
but there was just such a spread of abilities and comfort levels.
It made it hard to have certain conversations and a lot
of students in the class struggled.
So we thought this way,
we can sort of do everyone a favor collectively.
So keep that in mind.
In terms of the team size, four will be the default
if you have three friends with whom you'd
like to partner, that's totally fine.
We will not mandate particular teams for you.
If you don't have any friends or partners in mind for the class,
no big deal, we'll keep that mind as well and try
to facilitate those kinds of partnerships.
In terms of the structure of the class, this is very anomalous.
The course will not be structured for the most part
around lectures and will not be structured
around you guys sitting there staring this way
and me talking this way.
Rather most of the class sessions will be
in the form of team meetings.
Either your team will gather here or elsewhere on campus
for a couple of hours on Monday afternoons or for a couple
of hours on Wednesday afternoons.
In the coming weeks, we'll figure out which day
and which time each folks will be.
If need to be, we can tweak the times but we shall see based
on a survey that you guys all ultimately fill out.
What happens in these meetings?
So the weekly meetings is
where you guys primarily present the progress
on various projects, more on those in a moment.
So at these team meetings, one of the teaching staff and
or myself will be present and the goal will be for each
of the four people in the team to report on milestones
that you have or haven't achieved.
Where the milestone will be defined
as researching something, implementing something,
designing something, thinking about something or the like,
defending design decisions.
So it's-- we meant this class
to particularly critical or challenging.
So its not just going to be talk about your day
and how you actually chose to implement this but I and Rob
and Tim who'll meet in a bit will be there to challenge you.
So that if you made a decision
and it is not necessarily the best that's fine.
If you actually have a strong opinion as to why you did that.
And in answer of the form, well, it works
but I'm not really sure is not what's really expected
at those meetings.
So it's really meant to be a bidirectional conversation
in which you defend your decisions and also convince us
that the path you've taken is ideally best
or it's an opportunity for you to solicit feedback from us
and even your partners
as to what you might be doing differently.
And then in particular these will be opportunities
for code review.
So you guys will be writing JavaScript code and PHP code
and other technical aspects of each project
and the goal will be in front of a big screen TV,
around the table like this for one of you to stand
up at a time whoever has been doing the most work
on some aspect of the project have laid
and to present the code.
And give us a verbal tour of the code and give us an opportunity
to say why do you have six nested loops implementing
something like that?
Or why don't you have indexes
in your database table various topics that we'll explore
over the course of the semester.
So occasionally we will have technical talks either
in the form of these in person style meetings
where we all gather together or via video
to make things a little asynchronous
for convenience's sake on particularly technical topics
and tools that we'll use during this semester.
Some popular JavaScript libraries
for instance are Backbone.js and Bookshelf.js and Express.js.
These are all tools with which you can make web-based
applications using JavaScript.
Not on the client-side though
but on the server-side using a framework called Node.js
which is an alternative to using something like Apache
or Microsoft IIS or other web server software.
So we'll actually write in the class JavaScript code,
both on the client-side as well as on the server-side.
We'll talk about tools with which some
of you are already familiar.
Things like Git.
We'll dive in deeper to things like SQL and constraints
and transactions and a lot of the details that certainly
in a class like 50, we kind of wave our hands up for times sake
but are evermore important
when actually implementing a project that's going to be used
by actual and hopefully large numbers of users
where performance is going to start to make a difference.
In the PHP world, we'll use a framework called Laravel.
This is an MVC architecture.
If know or recall that acronym.
And it's just a bunch of PHP code to make a lot
of jobs easier and to make it easier
to write more complex software particularly projects
that are implemented by multiple people.
For testing, we'll use tools like Mockery in PHP units
and we'll get into the habit of not just writing code and sort
of banging on it and anecdotally trying to trying to figure out,
does it work as you intended.
But rather does it pass certain tests.
So that especially if a friend of yours
in your group changes some code, you can be sure
that here she has not broken anything simply
by rerunning the tests
that you've already written for that code.
So that don't have regressions to buggy states of software.
In addition, the projects is
where we'll spend most of our time.
So there's no exams.
It is all driven by projects in this class
and there really just be two per team.
Essentially the first half of the semester will focus
on one PHP-based websites
that will have front end user interfaces both for desktop
and optionally mobile.
So this will be an opportunity, albeit tangential to the class
to actually do something like a web-based mobile interface
or if you're really determined, Android
or iOS would be perfectly fine.
Just realize that the learning curve there
if unfamiliar would be bit higher.
But it would play very nicely with the vision
of also having each project to have some back end API.
So that you can have a separation,
abstraction between what you are doing and what Alice and Bob
and Charlie in your group are also as well.
So that each of your front ends
or back ends can somehow intercommunicate.
In terms of the specifics, for the framework,
we'll rely on Laravel and Eloquent which is an ORM,
an Object-relation Mapper which is just a layer of software
that addresses the M in MVC, the Model.
It makes it a little easier especially for large projects
to query data from databases and to write data
and to represent real world entities without having
to write raw SQL code.
In the world of JavaScript, we'll again use Express
and Bookshelf which are analogues
in the JavaScript world.
But using instead of Apache using Node.js
which is increasingly popular and allows particularly
for applications involving real time interactions,
chart rooms and the like.
Node is much better than Apache when using--
when implementing projects like that
because you can send messages using models like pub and sub,
publish and subscribe, if familiar with those phrases.
So more on that toward the middle of the semester.
In terms of expectations, these are them for the course.
Attend or watch these occasional talks, technical talks.
The schedule for which will ultimately put
on the courses website.
Participate in all of the meetings.
So attendance is required at each of the team meetings 'cause
after all that's where the most of the course's instruction
and feedback and interactions will happen.
Weekly milestones, we'll use a tool that I'll make mention
of in a moment to generally assign you from one or two
of the staff members to each of the four people in the group.
Things to do and those things will come in the form
of why don't you vet go this option.
Why don't you go vet this option and figure out which
of those two implementation possibilities are better
between now and say next week.
Why don't you go implement this?
Or you design these database tables.
And so in short the schedule in the course is going
to be fairly organic depending on the projects
that each team tackles depending on what your findings are
when vetting some implementation option and depending potentially
on what the end users ultimately want the project to do.
And so toward that end, there are no fixed deadlines per say.
There will pretty much be in a rolling assignment
of deadlines every few days, every week based
on the conversations that you have with one or two
of the staff members at your table.
Ultimately, though what's due is the submission
of these two final projects.
In terms of what the projects will be,
the projects will be either proposed
and selected by you guys.
In fact, on the lottery form for instance you'll be asked
on what are one or more projects particularly that somehow relate
to campus that you think would be compelling to implement.
Since one of the hopes for the course is
that whatever projects do come
out of this course survive the end of the semester.
And so particularly if they're campus themes,
whether if that's another course catalogue, shopping tool
or events calendar or shuttle service or any number
of popular final projects.
The hope after the end of this semester is
that any such project live on.
And indeed toward that end,
what we thought we do is make it a little interesting.
And also sort of insight opportunities
for debates whereby for most any project that we
as a class tackle this semester,
there will be two teams assigned to that same project.
The general idea being that they're not really supposed
to talk about their various design decisions,
rather its meant to be more of a competition as to
who can ultimately produce the best design, implementation.
So that at the end of the semester, come May, we ship one
and not both of those solutions.
And we as a course will take care of the hosting and so forth
so that your legacy lives on at the end of the spring.
What do these applications do?
Can be anything, something for a department,
something for a student group,
something for students more generally that will be part
of the conversation in the coming week
until dive head first
after picking a handful of such projects.
In terms of the staff, let me introduce Tim and Rob
who would like to say hello.
And it's these guys who for one of the projects will be--
for both of the projects will be your primary adviser.
Essentially for one of the projects, Rob will be gathering
with you weekly for these chats.
For one of the projects, Tim will be gathering with you
for those chats and we'll swap roughly mid-semester
as we transition projects.
If you like to just speak near to this microphone.
>> Hi, I'm Rob.
I graduated last May from [inaudible].
I'm preceptor in CS here now.
Excited for the course.
>> And I'm Tim and I'm actually completely new to the area.
I'm originally from Philadelphia so I just started
up here a couple weeks ago and I'm really
into open source software.
I help out with maintaining the Backbone.js project where some
of you might be familiar with
and I also created the Bookshelf.js project
that David was mentioning.
So, I'm excited to see the projects.
>> Indeed.
For more information on Tim at least if you go
to the course's home page and click his name it will lead
to his GitHub repository if you'd like to look at some
of his open source tools and projects.
So in terms of grades, just 'cause this is an FAQ even
if sort of tangential to the bigger vision of a class,
how will final grades be determined?
So what we'll ultimately be fairly subjective based
on the interactions we you over the course--
with your over the course of the semester based
on your contributions both to code repositories
and to conversations that we have.
And in a nut shell, it will be based
on your contributions to projects.
The delta between the first week and the last week.
So not to worry if you have only four courses
under your belt whereas some other students
in the class might have eight,
we'll certainly keep that in mind.
The scope, correctness, design and style of your project,
so those familiar axes.
The degree to which you prepare for meeting.
So this really is meant to be an opportunity for us
to gather weekly and have intelligent and fun and sort
of ideally emotional debates.
At times where you guys do propose how you might solve
something and then defend what you might do and Tim's role
and my role and Rob's role will be to challenge you hopefully.
So that either you can be persuaded to go off
in some other implementation direction or can be confident
and feel pretty good about the fact that, yeah,
you think you have the best implementation possible
for this.
Particularly and so far as there'll be another team working
on that same project from their own individual angle.
In terms of the tools, so this will perhaps of all overtime
and you're welcome to use whatever is of interest
to for your own internal team.
But for the most part, we'll make use
of a free tool called Asana for task management.
You'll see more on this via email in the coming days
and it's essentially a tool via which you can work spaces
and projects for team.
So if your project is to implement full [phonetics].
Your four team members will be inside of that project,
in that folder so to speak.
And you and we will be able to assign milestones and to do's
and dates and comments.
And it's nice 'cause it's integrated with email.
So you can or can't visit the website it's totally up to you.
And you can also get an aggregate sense
of what folks are working and get a sense
of what's going beyond your own particular bubble
if your head goes down after a while focusing
on one particular thing.
For GitHub too, if unfamiliar, GitHub is one
of the most popular, if not the most popular repository
out there for source code these days.
We'll use that as a central repository for each team of four
so that you four and then we three have access to
and can comment in the form
of code reviews using GitHub's interface.
But we'll introduce you to that
if unfamiliar when the time comes.
And that's just a quick a glimpse of Asana.
Quick glimpse at GitHub and now let me pause for any questions.
Yeah.
[ Inaudible Question ]
Good question what do we think of Python or Ruby frameworks?
They could achieve the same goals in particular.
We happen to use PHP in 164 because a lot
of people's prior web experiences coming out of 50
which uses PHP right now.
But absolutely, could any of these projects be done in Ruby,
Python, even Java or other frameworks, Node.js certainly.
But we happen to use PHP and we happen to use Node.js
and we want to standardize those for both of the projects
so that it's a lot easier as a class
to have very similar conversations
and not have too many apples and oranges in the class.
Even though there will be discretion when it comes
to the particular add-ons in libraries that you might use
for either of those environments.
So, no claim that one is particularly better
than the other.
And PHP has a sort of an ugly history but it's gotten much,
much better in recent years.
So what lies ahead?
No homework or any such things tonight other
than to visit this URL if indeed of interest.
We'll post the link on the website
if you forget where that is.
The deadline for this is going to be 6 p.m. on Wednesday
so that Rob and Tim and I can sit down that evening
and review the submissions and figure out how best
to optimize groups and so forth.
We'll let you know by Thursday whether or not we've had
to lottery and if we have a spot
so that you guys can get study cards signed to figure
out what you want to do.
And in the mean time, if you have any questions,
go to the course's website.
Email staff at cs164.net.
When we come back on Wednesday, it will still be this format.
But likely starting mid-next week or the week
after where we divvy up into much smaller groups
with just four of you meeting at a time with me
and or Tim and or Rob.
Thanks very much to the team in back today.
We will see you on Wednesday.