[Seminar] [Web Development: From Idea to Implementation]
[Ben Kuhn] [Billy Janitsch] [Harvard University]
[This is CS50] [CS50.TV]
[Billy] Hi, I'm Billy and this is Ben. >>[Ben] Hi.
We're going to be talking about web development today.
[webdev] [Billy Janitsch and Ben Kuhn]
A bit about us first.
Ben is sort of the back-end guy. He makes things work.
And then I go in and make them pretty.
I'm largely involved with more front-end layout design kind of stuff,
and Ben, on the other hand, knows what he's doing so he works on back-end stuff.
Together we've made a few things.
For instance, last year we worked on Gimblium which is an online game development studio.
That was our final project for the class,
and since then we've made Harvard Class
which is an online framework for browsing and shopping courses at Harvard.
>> We're going to start with this idea for our website.
We're going to make Facebook, but for cats.
Before you actually make this website,
don't make this website because it's not good; but we'll use it as a framework
and go through the process of how we take this idea
and turn it into a real website we can use.
We'll start by breaking the website down.
Like you've been doing in CS50,
you want to think about what are the actual components that go into this website.
Basically turning it from an idea which is just sort of an abstract concept
into a real, tangible thing that you could make.
We start by asking some questions.
What is this website? Why are we making it?
What is it going to be used for? That sort of thing.
In the case of Facebook Cat,
we basically want a website that lets cats social network with each other.
The idea being that they can post on each other's walls,
they can make comments, that sort of thing.
And that's where we come into the functional components.
We now have this sort of framework of--we have user profiles,
we have comments, and we can post.
Perhaps someday we'll influent likes and that sort of thing.
And we kind of want to prioritize these features going in.
We want to say like, okay, it's really important that everyone has a profile
and that everyone can post on each other's walls.
Secondary to that, comments would be nice.
Maybe later on we'll influent likes.
So, you want to have an idea of what's fundamental to your project
and what's sort of a more general feature that could be applied later.
You want to sort of have a specific list in mind,
but the project that you start with is not going to be the project that you finish with.
In other words, things are going to change while you're developing the site,
and you want to leave room for that.
I'll turn it over to Ben who's going to talk a bit about structure.
>> [Ben] I'm going to be talking about the more technical side of web development.
Let's just go over some basics first.
When you're doing a web app,
the main division that you're going to have to have is
you're going to have some stuff going on in the client side--
that is, the code that you're browser takes from the site
and the JavaScript, HTML, CSS stuff.
That's all on the client side.
You're going to have other code that runs on the server side
which keeps track of all the data that people send in to you,
decides who to give what, stuff like that.
This is just some terminology so that you guys are all familiar with what we're talking about.
Beyond that division it's good to think of your web app in terms of
a couple of distinct components.
When you're doing web development
one of the things that you should always be trying to do is to reduce complexity.
The more complex your code is the more chance there is to make bugs,
the harder it is to change later.
So, if you can break up your app into some distinct functional areas
that will--and you can reduce the sort of amount of cross-area communication--
that will help you a lot in the long run in terms of reducing bugs.
>> To be concrete, usually people divide up a web app into--
these are kind of buzz words now, but they're still useful.
You might have heard people talk about models, views, and controllers.
Models are the actual data that your app is going to deal with.
For example, in your Cat Facebook, your models would be--
you'd have a model for like posts, and a model for user profiles, stuff like that.
Your views are how you present that data to your users.
You might have 1 view for looking at a single post and all the comments
and a different view for your wall that has a list of all the posts
that are directed to you, and a different view for your news feed--stuff like that.
Finally, you have the controllers which are basically when people send you posts
and you make updates to your back-end system,
you increment a bunch of counters, and whatever.
Those are your controllers.
>> I'm going to be talking mostly about models.
Views are technically not that difficult and the issue is more with designing them
Controllers are going to be specific to whatever you're designing.
But there are some pretty general techniques you can use
to make your models nicer and easier to work with that I think are very helpful.
This is mostly going to be about how to deal with your web apps data in a nice way.
The main issues with models
are that they live on the client and the server and you have to figure out
a) how to get them--all the relevant ones--from the server to the client,
and b) how to keep them in sync.
Your users are going to want to make some updates.
They're going to want to make new posts.
They're going to want to like things and stuff if you have likes.
Those are the main technical challenges of dealing with models.
The first thing that you're going to want to ask yourself is
what kind of data goes in this model and what kind of queries are we going to want to do--
that is, how are we going to look at the models?
For your Cat Facebook example,
your post is going to have an author associated with it,
some wall post text, and a recipient of the wall post.
And then you might want to query that in a bunch of different ways.
You would want to look at it by who wrote which post,
by who received which post, maybe by the date they were posted.
But if you're going to do it by date, then you have to add another field to your post
of when it was actually posted.
These 2 factors--what data you want to use and how you want to view it--
you should think about them first because they depend on each other,
and it's going to be more difficult to add them later on.
>> There are some other considerations.
When you're thinking about how you deal with models on the server
what you want to look at is--
you basically want to make the server as simple as possible.
Doing stuff on the client side is generally much faster if you can do it purely on the client
without doing any sort of network request.
The idea is to do as many of the queries as you can on the client.
The only problem with that
is that if you request all of your data at the beginning
then that's going to take a long time to load.
So, the idea is to strike a happy medium between having enough data on the client
that you can do most of your work there but not just fetching everything at once
so that you get really slow load times at the beginning.
For instance, for your cat data
you would probably want to fetch a bunch of recent wall posts.
You wouldn't want to fetch all of them because that could go back a couple of years.
But you don't want to fetch them one at a time
because that would introduce a lot of network overhead.
>> It's often quite hard--once you have a database running--
it's often quite hard to change what data you have in it--
that is, add a new database column or something--
so one good strategy is actually just to keep a lot of your data in a text blob--
a JSON blob--JSON being JavaScript Object Notation--
The reason that's useful is because then you can add new properties
to all of these JSON blobs without changing your database.
The only downside to that is that if you have a bunch of fields
that you added later on--like hidden in that JSON blob--
then it's harder to query them inside the database.
For instance, if you later--if you had your post model that we discussed earlier
with just the author, the recipient and the text--
you could also have a JSON blob and then if you later wanted to add a date field
you wouldn't have to change your database.
You could just add dates to all of the text fields.
And then you would be able to look at those on the client side,
but you wouldn't be able to query them on the server side
because it's hidden inside that text.
>> The other issue that you want to think about
is how your client and your server are going to communicate.
You usually want to keep this as simple as possible.
You can just have like a get-me-this data request,
a create-a-new-object thing, and an update-an-old-object request.
And these would all be different URLs on a server that you--
that the browser would--you can use AJAX requests for all of these
and either receive or post data.
Again, for our Cat Facebook example,
you could have that URL to get an individual post,
and you'd have a URL for creating a new wall post
and maybe a URL for uploading your profile picture, stuff like that.
But again, that's to pre-fetch most of your data so that you don't have to keep
making network requests.
For that reason, you might not want to have that individual get request for a single post,
and instead you would just want 1 get request for the entire wall.
And then if you're trying to strike a balance because--
this is also going to depend on your application.
Because if you're expecting that people only have 10 or 20 wall posts
that will be fine.
But if you're expecting they'll have thousands then that request would take too long,
and so you might want to add a get-all-posts-since parameter.
>> For all of these you're probably going to want to sync your data in JSON--
JavaScript Object Notation.
Pretty much every language deals with JSON very well.
JQuery has this nice getJSON function that will do all of the hard work for you.
And on PHP there's also very nice JSON communication functions.
So, that's probably the best format for sending your models back and forth.
>> As an example of what we've talked about so far,
here's an example flow for your Cat Facebook application.
It starts off with your browser requesting the base website URL.
The server probably would send over static HTML and some JavaScript and CSS.
It's usually best not to do any rendering on the server.
You probably don't want to--
what the server isn't doing there is going down the list of wall posts
and generating some HTML for each one and sending that over.
It's usually best to do that on the client side because otherwise
every time you want to re-draw something, you have to make a server request.
And that very quickly gives you a lot of overhead.
It's usually best just to ship sends down static HTML
and then JavaScript and CSS that will do the rendering on the client side.
As soon as that stuff comes in,
then you can have--in JavaScript--you can do requests for the wall data
and stuff like that, and after that the server is basically just doing database queries
and checking permissions.
The only important thing is that it can't send over some other users wall posts
that you're not allowed to see.
It can basically be a very thin access layer to your database,
and then all of the showing the data--all of the views and stuff--
those can happen in your browser, and then when you want to make a post or something
you just send another request.
>> There's also some fancy stuff you can do on top of this.
In terms of more specific technical information,
developing in plain JavaScript can be a little bit painful,
so there are some libraries and tools that will help you a lot with that.
I think you've all probably heard about jQuery which makes doing HTML rendering
and manipulation a lot easier--have lots of fancy functions for fading in and out,
and doing zippy animations.
There's also this library called Underscore.js.
It has a lot of useful utility functions, stuff that you would expect JavaScript to have
that it really doesn't--things like shuffling an array,
removing duplicates from a list, or flattening a list of lists.
This is just a small code sample.
Underscore has a ton of these nice functions that you wish you would have all the time.
>> And then there's 1 more library that I'd like to spend a little bit of time on
called Backbone.js because Backbone really helps you deal with models on the client side
and a lot of the confusion that it can cause.
Backbone gives you this concept of models and collections
in JavaScript which are basically exactly like JavaScript objects
in JavaScript arrays but they have events when you change their properties.
Just like in JavaScript, you can have an event when a button gets clicked or something
these Backbone models and Backbone collections will broadcast things like
that when they change.
That means that you can just write something like this snippet of code here--
this says, whenever you add anything to the posts array you redraw the whole wall.
And this would say whenever a post's number of likes changes,
you notify the user that somebody liked their post.
Or whenever any property of a post changes you redraw the post.
Stuff like that will save you tons of complexity because otherwise
if you don't have some framework like this then every time in your code that you change
anything about a post, you'd have to remember yourself to call all the render functions
and stuff like that, and if you wanted to add something new that happened
every time you modified a post you'd have to go through every place in your
code that you modified a post and add that new thing.
A framework like this will remove a lot of that between-layer communication
that makes your code complex and hard to maintain.
>> There's a little bit about views also.
I'm going to leave most of this to Billy because they're technically not very difficult.
Use jQuery for your views. It's practically like a necessity at this point.
It just makes everything so much easier.
There are a lot of libraries.
If you have complicated user-interface elements,
if you want an auto-complete thing or like one of those fancy multi-selectors--
if you want anything like that, you should probably just search around
and you can find a good library that will do what you want.
Billy will explain more about the actually difficult parts of views.
Also, as a side note, Backbone has some functionality for making views communicate
nicely with models--look at the documentation for all of these libraries, actually.
Just look at the docs. They're very well written and easy to follow.
In general, you can pretty much just Google if you have problems.
There are a lot of people using them.
I think this is as a final note.
>> There are also some more advanced things that you can do
if you're looking to make your web app extra awesome.
You can do--the new HTML5 specification has a lot of fancy things you can do.
Local storage--which is you can store data in the browser--
rather than having to go back and peruse the server for everything,
you can keep some of it on the client and that even lets people--
in some cases it can even let you use the webpage offline.
There's this thing called websockets which are a different kind of network communication
where instead of just you make one request, you get response and you're done,
you keep open a connection to the server and so you can do things like
real-time updates.
So, if you were trying to make a chat app, you could use websockets
to communicate back and forth so that you wouldn't have to keep requesting,
"Oh, server, did anyone send me a chat?" every 10 seconds or something.
There's also an interesting HTML5 feature where you can make it look like
the URL of the page is changing without ever having to actually reload it.
You can use back and forward buttons without doing a bunch of network requests.
Stuff like that is really useful in terms of making it speedy but also work like a web app should.
>> There's also this thing called CoffeeScript.
CoffeeScript is a different language, actually, that compiles down to JavaScript.
You would write all your code in CoffeeScript, and then you run this compiler,
and it spits out a JavaScript file that you can include in your webpage.
The reason that CoffeeScript is nice is because it gets rid of a lot of the
weird cases that JavaScript has where equals equals,
and equals equals do different things, or like--
it has nicer syntax for dealing with arrays and functions.
This is a little snippet of CoffeeScript that produces a list of all the squares
from 10^2 to 1^2 in reverse order.
As you can see, CoffeeScript often lets you express in 1 line
what would take 5 lines of JavaScript.
It can make things a lot easier.
It's a little bit of new syntax to learn at first,
but it definitely will make you more productive in the long run.
>> You can also use other languages on the server than PHP--
languages like Ruby, Python, or there's even a project called node.js
that will let you use JavaScript on the server.
Personally, I really, really hate PHP.
I just don't enjoy working with it.
If you, too, think that it is an awful cluge of a language,
then you can use one of these instead.
In general, if you want to do something and you don't really know how you would do it,
just search the Internet.
There are tons and tons of resources especially on--
StackOverflow is a great one.
It's this website where programmers ask each other questions.
You might have run into it if you were having trouble on CS50 problem sets.
And there are tons of libraries for doing pretty much anything you would want.
If you want to do something and you don't know how to do it,
don't assume that it's impossible.
Just look around and you might find some good resources.
>> As a general wrap up,
the main takeaways are keep things simple.
The more complex your code is at the beginning
and the more you try and do fancy stuff,
the longer it will take to get something actually functional
and the harder it will be to change later.
So, do things the dumb, easy way first.
To go along with that,
don't be scared of throwing away old code or cleaning it up a lot.
In general, once you actually have something working,
it's much easier to think about than when you're still in the beginning stages
of how do I put this all together.
It's best to make the dumbest possible design that works
and then improve it iteratively than trying to get everything right the first time.
In terms of client-server division, try and keep your server very simple--
just a database and some authentication and don't do any hard work there.
Do all of your complicated stuff on the client side in the browser
in JavaScript as much as you can.
Look around for libraries that make your life better.
Always better to use code that someone else wrote
if you--and not to write it yourself.
There's a lot of stuff on the Internet. Google is your best friend.
Google is the programmer's best friend.
Yeah, definitely don't be afraid to look around for stuff.
All right. And over to Billy.
>> [Billy] Actually, before I start with some design stuff,
does anyone have any questions for Ben about anything that he talked about?
Okay, good.
Again, let us know if anything's not clear
or if you'd like us to go over something a bit more.
I'm going to step back a bit and talk about the more fundamental parts of design.
Ben mentioned the model called--sorry, the model controller view system
which is sort of the technical aspect, so I'm going to look at views specifically,
and I'm going to start with how you'd design a view that looks nice.
Here's kind of a really basic template for our Cat Facebook.
I think there are some fundamentals in modern UI design
that are worth picking up.
You can notice there's a lot of white space all over the page,
plenty of room for things.
Don't feel like you have to squash things into a page.
You want to leave lots of room open, and if you go to almost any modern website
you'll see there's white everywhere.
There's white in places you wouldn't expect.
You have this color palette, and it's wise at the beginning
to choose a color palette that you're going to work with and develop.
You also--it helps to choose a typeface, and that way you're sort of working with
these concrete fundamentals of design.
You have your type, you have your colors, and then you can kind of
fit everything else in as needed.
So, as I said, with your color scheme you want to use the bolder colors of your color scheme
sparingly. Headers are nice. Buttons are nice to have really big, flashy colors.
But in general, if you have a website that has colors everywhere,
all staring you in the face, it just looks cluttered, and it's no good.
You want to generally use light colors.
Try to, again, pick a pretty coherent color scheme.
You can have these little splashes of lots of color--
that can look pretty nice, but you want to use them pretty sparingly.
>> As I said, you want to be minimal. Less is almost always more.
If you can display something or not display something,
and you're kind of unsure whether it should be there by default--
probably you're best off leaving it out. You can always add it in later.
Yeah, keep things simple.
But most importantly, you want to consider multiple designs.
Don't think that when you make a site, you have it in your head that you're going to
make the site in a certain way, and it's going to look exactly like this.
It's going to have the blue header at the top and the blue side bar
and then the yellow sub-header thing.
You want to make multiple templates.
You can either--if you're good with Photo Shop, you can open that up and sort of
design a website as you like it to look.
If not, you can just use pen and paper,
but scratch up multiple designs.
You want to basically have a set up where you have lots of different designs,
and if one ends up working, then that's great.
If one ends up failing, then you always have another one to turn to.
In general, don't feel like you should be constrained
to whatever design you initially decide on.
Designs are very variable, and part of the importance of the model
controller view system is that you can swap in and out different views you want.
You can sway the data one way, and then decide, oh, actually, that doesn't work that well.
I think it's kind of too complicated or there's a part here that's not really working,
so I'm just going to totally abandon this view and swap in a totally new one.
We can still use the old models and the old controllers.
We can do everything on the server and client as we would before.
But the actual wave of the data as displayed is going to be slightly different.
>> As far as actually implementing the design you want,
once you have a few designs sketched out on paper or on Photo Shop or whatever,
there are a number of tools that are made available to you.
The first you're very familiar with which is your HTML, PHP, or whatever
language you're using just to code the static pages on your website.
You've worked a lot with HTML which kind of gives you these tags
that you can put things into, and basically it's a way of organizing your content.
For example, you have the header up there, so you're going to have a header tag,
and it's going to have some text inside of it which is probably going to be in another tag.
Then you have a sidebar maybe with some different links,
and those are going to all be in separate tags.
So, basically HTML at its heart is a way of dividing up the page how
you eventually want to format it.
So again, you've seen that before.
You're pretty comfortable with working with it now
given that you've done the last pset hopefully,
so that should be no problem.
>> Then you have CSS which basically handles all of the design static aspects.
It would handle all of the colors, all of the positioning of different elements,
where they go with respect to one another,
how big they are, the different kinds of positionings that you would have--
in other words, you can have things fixed so that when you scroll down they stay,
or you can have things relative to other elements.
All of that sort of stuff is in CSS.
Furthermore, you can do different decorations, you can have text colors,
text effects, all of that kind of stuff.
Ben gave a really good seminar on this last weekend,
and so I would definitely check that out if you plan to be doing some fancy things with CSS.
CSS3 is actually the newest version of CSS, and it can do all sorts of really nice things.
It can do gradients; you can have nice, rounded corners; you can do all sorts of stuff
to make your website look more modern and fancy.
>> The next tool is JavaScript and jQuery which Ben talked a little bit about,
but I'll get a little farther into.
JavaScript, as you've worked with it a little bit, or at least seen it in lecture,
is kind of a way of dynamically doing stuff in HTML.
HTML, as you know, is static, so once you have HTML you can't modify it.
But JavaScript, in some ways, is a way to be able to modify HTML.
So you can do that, and that's great, but JavaScript really is a pain to work with.
It's so long and obtuse and to do even the simplest things
requires lots of lines of JavaScript.
So, jQuery is basically a library for JavaScript that simplifies all of that.
It says, okay, if you want to have a square box come from the left
and fade into the page so that it's in the middle, in JavaScript that would take--
I don't know, a hundred lines to do, and it would be a pain,
and you come out of it hating everything about web programming.
JQuery you basically have the element-dot-fade-in, or something like that.
So, very, very simple functions that will let you do all kinds of cool animations
and that kind of thing.
The other thing that these 2 are really good for is just doing dynamic things
with the website.
So, rather than just having your HTML page--which displays some data but doesn't actually
do anything--JavaScript and jQuery will let you have buttons that you can click on,
and you can drag elements and re-order them and sort them, and have new elements
added or removed. You can add-delete, that sort of thing.
So, jQuery does tons of cool things.
And Vipul is actually giving a seminar on it today, I believe, at 5-o'clock,
so if you can stick around for that long, that would--5 or 4?
Four. Sorry. It's actually right after this, so I would recommend
sticking around for it if you can.
JQuery is super, super useful, and you'll be able to do lots of really nice things with it
for pretty much any web development project.
>> Now I'm going to get into kind of a distinction.
I've been talking basically about user interface.
User interface is just the design of the site.
But there's sort of another concept which is user experience.
The two are very different.
Interface is definitely part of the experience.
In other words, when you go to a site, you look at the interface.
That's part of how you experience the site.
But user experience is more than that.
User experience is about what the impression that the user gets from your site is.
So, obviously, interface is a part of that.
And it's definitely a necessary part, but it's not sufficient.
In other words, if you have a nice interface, and it's pretty and colorful and all of that,
that's great; but if the user goes to your site, sees a pretty layout and it's confused by
everything, has no idea how to do anything, then obviously you've made a really
poor website.
That's sort of where user experience comes in.
I'm going to talk a bit about UX design--UX is short for user experience--
and kind of how you can make sure that you have a good user experience.
The first point is that you may design a website where a user can do anything that
that user possibly wants.
But if the user can't figure out how to do those things--
in other words, if the user doesn't have a good idea when they go to your site of,
"Oh, if I want to update my profile, then I click this button, or if I want to post on
someone's wall, then I go to their wall and click on a little box."
If the user doesn't know that, then you effectively haven't actually
implemented that functionality correctly.
Part of implementing a functionality is that the users are actually able to use it.
And it might be frustrating--you might make a site, and it can do all kinds of
wonderful things, but then you'll have people test it and say, "It can't do this.
Why can't it do this?" and you'll say back to them,
"Well, it can. You just have to go into the 7th drop-down menu on this obscure
page that only is found by a link at the bottom-right-hand corner" or something.
Obviously, you don't want that.
You want it to be clear to your users what they're supposed to do,
and it should be simple and intuitive for them.
>> Another thing that you want to try to do is, if someone's going to go to your site
and 9 out of 10 times do action A, and 1 out of 10 times do action B,
you probably want to focus their experience on action A.
In other words, you want to make it very, very clear how to do A.
A should be front-and-center--go to the site, see it; oh, it's right there.
Whereas B obviously you want to be clear, but you can leave it a bit more
in the background.
David gives a good example of this in lecture,
which is the Boston T system.
When you go to the Boston T and you want to buy a ticket,
you have to get into 5 menus before you can actually purchase a ticket
for a $2, $2.50 value, which is how much it takes to ride the subway
in one direction.
That's a problem because most people who are riding the subway
probably just want to go to one place, buy their ticket, get on right away.
It doesn't make sense that they have to go through lots of different menus
to get there.
A better user experience would be a quick button on the first page
that just says, 'buy a one-way ticket,' and that would put in all of the standard
default values; and then if someone wants to buy a different ticket than that,
they still, of course, have the option to, but you've optimized for
the common-use case which is really important.
You can see examples of this on Facebook, right?
If you go to Facebook and you want to post a status,
it's right at the top which is what you often want to do.
As soon as you enter the page, you can do the most common things that
you want to do.
If you want to do slightly more complicated things like,
say I want to go to my friend's wall and post a picture on it--
which I'll want to do often, but not as often as posting status updates--
so in that case, I type their name in the box at the top, click on their profile,
and then, still, it's right at the top there once I've gotten to their profile.
Again, I've optimized in priority for the most common-use cases.
>> Another important thing is that often people will sort of try to get around this
by saying, okay, so I've made the site and people are finding it confusing,
and that's a problem, right?
Obviously, I don't want people to be confused by the content of my site.
But the way to solve that is not to have something pop up saying,
hey, I'm going to teach you how to use this site.
Step 1--click this button. Step 2--go here.
Sure, that's a way around it--it's a way that you can tell people what to do, but it's
really not the optimal way.
If I go to a website and suddenly I'm bombarded with this tutorial that's telling me
what to do and where to go and all of that, that's not fun for me.
It's not a good experience for me.
It's kind of a pain. I want to just start doing stuff.
People are going to close out of their dialog box,
or get out of the tutorial, not know what to do, and then complain because
you haven't told them what to do.
The way to solve this is not by giving any kind of tutorial or directions--
anything like that.
As much as you can avoid it, you really want to show the user what to do
just by the nature of how the website is laid out.
In other words, if I go to Facebook without logging in,
the first thing that I see on the main page--
it's a little login box. So, duh. I have to log in. It's right there.
Whereas, if I went to Facebook and I had to click a little link at the bottom
that said 'log in' and the rest of the page was just some kind of picture or something,
I wouldn't really know what to do, right? I would be confused.
So, it could tell me to go down there and click the button to log in,
or the log in button could be right at the top where I'm going to see it.
You want to always be showing the user what to do,
and that should be inherent in the page itself.
>> When you're thinking about designs and mocking up different ways of
expressing your site, you really want to think about what the users are going to
be doing and how you can show them what to do.
One last thing is testing is really, really important.
It is great to get someone--get a friend, get someone you don't know even--
who's never seen the site before to use the site.
Because you've been working on the site for hours, you've been staring at it,
and you know exactly what to do so obviously you're going to be testing the
things that you've been working on and that you know work.
But if someone else comes along and uses the site that has never used it before,
that's a unique experience because you have someone who has no prior knowledge
of the site going into it, so they're going to have effectively no idea what to do
or what kind of use cases are present for them.
That's great. That's unique because they're essentially a person with a blank for a mind.
They can tell you if something is confusing or unclear.
They can give you an idea of precisely what the user experience of your site is.
It can be very hard to tell that yourself, so definitely I would encourage you
as you're developing your projects--if you're doing web-based projects--
to get people using the site as early as you have some kind of functional demo.
>> Now I'm going to talk a little bit about how to manage a web development project.
We've gone over how you can do the technical back-end side,
how you can design a really good site,
and that's great if you're working by yourself but--
even if you're working by yourself and especially if you're working on a team,
project management becomes a big issue.
You've sort of heard about project management in different forms since
elementary school when you were told group work.
You have to cooperate, communicate, all of that.
That all still applies here, but there are some unique circumstances with
computer science that you want to be aware of, and you want to make sure you handle well.
I'll talk first a little bit about the team that you'll be in.
It's very important to pick the right size of a team to be working on,
and in your final project I think you have the option to choose
between 1 and 4 people if I'm correct.
You want to make sure that you're not just choosing the number of people
that you want to work with because they're your friends.
You want to choose a team that's a good size and that will get the job done.
There's a trade off in having more people versus less people.
If you have more people, obviously more work can be done
because you have lots of people, lots of code, lots of ideas,
and that's all great.
But it also requires a lot more management and a lot more communication.
In other words, if you have 4 people working on the same project
and they're all editing the same code, more or less they all kind of need to know
what's going on so it requires you--
if you add some new function you sort of have to tell people--I'm adding this,
I'm changing this in this way--especially if you get into the really deep stuff
like the models and the controllers that are actually going to influence how the site works.
The whole team needs to be aware of it,
so you need to make sure you're not choosing too big a team that's going to be hard
to make that communication.
You also don't want to choose a small enough team that you're not going to
be able to communicate because it's just you.
>> Another thing to consider is the balance of where people's skills are.
It's great if you're all really good programmers.
But if you're all back-end people, then your site isn't going to look very good
because you have this great database, and it does super-fast search queries--
which is great--but when you go to it, it's like a 1990's site with red and blue
everywhere, and that's no good either.
Notice that Ben and I working as a team are very nice because I'm sort of more
in the front end, we both interact in the middle-end, and Ben's really good with back-end stuff,
so that works really well because we can design any site and basically the holes
in that site that need to be filled can be filled by either one of us, or possibly both.
You want to make sure that there are no holes in your team.
It's okay if there's a bit of overlap.
In other words, if you have 2 people that are both good with back end,
that can be good as well because they can help each other with problems
that they are having.
It can be a problem if you only have 1 person who's responsible for a certain thing
and they run into a problem, so you do want to have a little bit of overlap
but you most importantly want to make sure that all of the possible holes are filled.
>> The last thing--and this should be obvious, but it's often not.
You really want to be having fun.
The point of this final project in CS50 and often the point of web development in general
is not to just do a job because it needs doing.
You really want to be having fun, and you want to be making something
that's motivating you to work on it.
If whatever you're making is a pain to sit down and work on,
then you're not choosing the right project.
You want to choose something that you find interesting,
you really want to see the result, you're excited when you get a new idea about
something you could do--so there's all kinds of projects there that I'm sure
you can find--everyone has something that would really intrigue them
if they're doing a web-based project.
I'll say it again right now.
If your project seems like a pain and you don't want to work on it,
choose another project. Choose something that really inspires you.
>> Ben mentioned this concept of iteration a bit, and I want to go over it a bit.
It's really important to work in spurts where you obtain something functional.
It can be great if you have this plan for a website that's going to do A, B, and C,
and eventually it'll get there.
But you're stuck in this phase where you're working on it and working on it,
but nothing's getting done. You don't have anything to see and a tangible, functional thing.
What you really want to do as much as it seems kind of a pain sometimes to
work on something and then sort of cap it off so that it's at least at a stable, running
version even if it doesn't have all the features you want.
And maybe there are some features that you really want to add but you just can't
because you want to get this site to a functional point.
And so you want to kind of have the whole development process look like that.
You want to start somewhere functional--or essentially start with nothing--
but you want to get somewhere very basic and functional.
And then again, make a sort of jump and get somewhere functional again.
You'll slowly build up, and it might go a bit slower than it would otherwise,
but in the long run if you're constantly stuck in this middle ground phase where you
don't actually have anything working, it can be a really big frustration
to work on your project because you're always so close to getting it working,
and it's never actually working.
You want to work in these functional spurts,
and you also want to do some reflection after each one.
In other words, once you're at a point where the site is now working--
it doesn't have everything you like but it does some things--
you want to think, okay, is this site accomplishing the goal that I set out to do?
In other words, if the site is going to do X, is what I have working in the direction of X?
Are all of the functionalities that I wanted there?
And moreover, is it serving the overall purpose that I want?
If you're finding that your site is starting to veer in a different direction
or maybe things just kind of aren't working out, it may be time to shift gears a little bit.
In other words, it's worth considering--it's worth throwing out ideas if necessary
and considering am I really working towards what I want to be.
>> I believe that's my next point. Don't be afraid to abandon ideas.
Just because you spent lots of hours working on a feature
and finally got it working but it really isn't going so well--
like it's not that useful or users are having trouble using it--that sort of thing--
don't be afraid to throw it away.
It sucks that you've spent a lot of time working on it,
but ultimately you don't want a site that's kind of put together by these pieces that
sort of work but aren't that well served.
Also, don't be afraid to embrace new ideas.
If someone comes along and says, hey, that site looks really cool but
wouldn't it even be great if it also did this?
Just because that's something that you didn't intend and something that's not in your
specs, something that you haven't set out to do,
don't be afraid to take it on and then work with it.
Because often the ideas that you run with throughout the course of development
end up being the really cool features of the website.
>> I've said this before. I'll say it again.
Testers are super, super useful.
Try to get people who have never seen the site before to log on and see what's going on
because they can not only test the usefulness of the site and the user experience,
but they can also test the functionality in ways that you can't.
If you make some feature that does a certain thing
and you know it's going to do that same thing correctly every single time, that's great.
But it can often be hard to account for corner cases where a user might
type something that you weren't expecting--precisely because you defined
the features yourself.
So, to have someone come on who has no idea how to use the site
and to just break it in whatever ways they can do is really useful because you
get an idea from a totally different perspective of what on your site is working
and what needs repair.
>> Last, I'm going to talk about some general good practices,
and you've seen a lot of these in CS50, but they also really, really apply in a project setting.
One is comments. Always comment your code especially if you're working on a big team.
It can be so annoying to just have a giant block of code that someone's written
and maybe it works, maybe it doesn't, but you have no idea what it does,
so you have no idea whether it's useful or not or whether it should be there or not,
and if you're working on something else it's even possible that you're working on
the same thing, so just be very, very careful to be considerate of your peers
and write code that's well documented.
You don't have to go so far as to do the whole thing where like if you increment
a counter have a comment that says, I'm adding 1 to this counter.
It doesn't have to be that detailed, but for any function that you're ever writing
you should have some documentation of what that function exactly does,
what its inputs are, and what it should return.
That way you can use other people's components of the site
and you can work towards building something big.
>> Another important thing is you want to do regular clean-ups.
Code gets messy. Don't feel bad if your code is just totally unreadable and a giant mess.
That happens in web development always.
You're adding new features, removing old ones. Stuff is going to be there that shouldn't be.
That's fine, but you want to make sure to deal with that regularly.
You don't want to let it build up to the point where you just can't find anything
in your code, and you have no idea what anything does.
That's the case with HTML.
Sometimes you'll end up with objects that don't contain anything,
and you'll want to get rid of those.
In CSS, you can be referring to elements that aren't there anymore,
so you want to get rid of that code.
In JavaScript, you might have removed something from the HTML.
So, you want to make sure that you're always cleaning up, making things pretty
as much as you can on a regular basis.
>> Another really useful thing that I don't think is outlined very much in CS50
but it's worth getting into is version control.
The idea of version control is when you're basically keeping track of all the progress
you've made towards your site and if at any point you realize, oh, this was working
a while ago but it's not working any more, you can go back to previous versions
and see what has changed since then and that sort of thing.
The primary way to do that is with Git, and Git is this whole kind of system that
I believe Tommy MacWilliam gave a seminar about last year.
If you go into the CS50 seminars for 2011, you can see his seminar on that.
The idea of Git is basically that at regular intervals you're making these commitments
which are ways of saying the site's in a pretty stable version right now so
I'm packaging it up and sending it away to a server, and then you can go to that server
and look at all previous versions of your code and see how it's progressed
and all that sort of good stuff.
So, that's basically it.
As far as web development, we're happy to stick around and answer any
questions as far as our presentation.
That's it. Thanks. >>[Ben] Thanks.
[applause]
>> [Billy] Staff, does anyone have any questions about things that we've covered
or things that we've not covered that they were hoping we'd cover?
We'd be happy to answer those. Anyone?
[audience member] What are the pros and cons of using Ruby or using Python?
[Ben] The question was, what are the pros and cons of using Ruby or Python
instead of like PHP.
The pros are that Ruby and Python are much better languages than PHP.
At least in my opinion, and I think in a lot of other people's opinions as well.
They were designed more for doing complex stuff,
and less for whacking together web pages really quickly with
a little bit of dynamic content.
The cons are that there's a little bit of--there's more of a learning curve
to get them set up.
That is, like in PHP, you can just have an HTML file and you write less-than,
question mark, and then you write some code, and then you write question mark,
greater-than, and then you're done.
In other languages like Ruby or Python,
you have to go through a bit more work to get the initial site running.
There's also--at least it used to be the case--that there's more documentation
available for PHP just because there are more people using it.
I think that's not as much of an issue anymore.
There's certainly very good documentation for stuff like Ruby on Rails
or Django for Python is the equivalent.
PHP is the one that everyone's been using for years, and you know how it works.
Ruby and Python are a little bit less mature.
>> [audience member] If you were to choose between one of them to learn or pick up,
which would you prefer?
Honestly, I think that depends on the person.
I'm sorry. The question was which would you pick for someone to learn?
I find Python the nicest personally.
There are a lot of people who--I did my first web dev project in Python and Django.
There are a lot of people who like Ruby on Rails also.
Probably more people who know Ruby on Rails.
Honestly, I would just go with whatever the people around you know
so that you have people to ask questions.
>> The question was--on shared servers is it kind of hard to work on Python?
That depends on your hosting.
There are a number of web hosts that will post Python stuff.
WebFaction does that, right?
WebFaction is one that Billy and I have used for some projects.
They're really great. They support most languages.
But it's true that PHP is much more widely supported.
So, if you're stuck on a web host that only does PHP, that's a good reason to use PHP.
>> [audience member] I just got into learning how to query some databases,
and I know my SQL is all over the place, but I recently got exposed to--
and you pointed it out. You see JSON and expandable databases.
My SQL is still all over the place. How do you see that happening?
Is there going to be a growing tendency for more expandable (inaudible)?
The question was--do I think there's going to be a trend towards non-SQL databases.
For instance, like MongoDB. I think that is definitely true.
My advice was mostly mySQL-related here only because mySQL is
industry standard.
Personally, I much prefer databases that don't have schemos like MongoDB
where you don't have the issue of, oh, I need to add another column.
Woe is me, like whatever do I do?
It's very hard to do that on mySQL, but when you have something like Mongo
it's much nicer.
The other nice thing about Mongo is that your records are actually JavaScript objects.
There's no sort of conversion step where you need to take these database rows
and turn them into a JavaScript object and then send them over the wire.
I think stuff like that is going to be very, very useful for rapid web development in the future.
>> [Billy] Something I would add which is just a general point is that
don't feel like you should have learned all of the languages we've discussed
from our seminar.
Obviously the point is to give you an idea of what's out there,
and if you're intrigued by any of the things we've mentioned you can Google them
and read up on them.
And as I mentioned, there are a few seminars that deal with precisely these things.
There are even more seminars that I haven't mentioned that probably get into
this stuff as well.
The idea is that if you want to work on something, here are the tools at your disposal.
Don't feel overwhelmed if you aren't really sure what these tools do exactly,
but know that they're out there and that you can make wide use of them
by Google.
>> [audience member] What kind of things do you need to do to make sure your website
looks good on mobile devices?
[Billy] Mobile devices are a little hard.
There's 2 ways you can approach it.
The first way is that you actually have a mobile website.
In other words, you perform some sort of detection at the beginning
when the browser is making the request to your website which either says
return this view--which will be the view for desktop or laptop browsers--
and this other view for mobile devices.
That's a place where views are really nice in that you can pretty much swap the
two out and have an interface that works really nicely on mobile devices
and have a completely different one that works nicely on browser devices.
The problem with that is it takes a long time because it means coding
a totally different interface.
The other way that you can do it is--
a lot of modern phones will display websites and try to render them as a browser would,
and they do their best.
You can kind of try to stay light on the amount of jQuery JavaScript you're using
which tends to be where things can go wrong a little bit.
This is sort of the way that you should use if you don't have that much time.
If you do have the time to work on a mobile interface, that's obviously your best option.
>> I think generally for CS50 projects, you're going to want to choose one or the other.
In other words, you want to make a mobile app or you want to make a desktop website.
And that sort of determines where you go with that.
But if you want to expand it out later, probably your best bet is
to make another interface for the other.
I have a little bit of experience in developing WordPress-based sites.
I hosted a personal website on WordPress for awhile.
Those kinds of frameworks can be nice just as very basic things.
Oftentimes you'll just run into a lot of customizability issues though.
You'll want to have something look a certain way or be a certain way
and you just can't because it's hard-wired into the system that
this is how you have to do things which can be a bit of a problem.
Since then I've kind of been more inclined to work with sites from the ground up.
For things like blog databases and that sort of thing it's really not that hard to build a framework.
If you're really stretched for time, you can of course use something like WordPress
or that sort of thing for a blog.
The kinds of things that blogs store and do are not really hard enough that
if you're running into any of those kinds of things, you're probably best just to
make an in-house version.
>> I think that's about it, so thanks again for coming.
We really enjoyed talking to you guys and hope that you learned some stuff.
[Ben] We're happy to talk--we have to go but we're happy to talk more outside
if you have another question. Thanks again. [applause]
[CS50.TV]