I was a TA for this class when it was first taught in January of this year. Back then it was an intense course that split it's time between Web Security and Web Programming.
The class has been split, and this is now just a Web Programming class. I helped design project 1 and project 7 (my screenshots are still being used :-)! Highly recommended for those who want a nice intro to modern web programming.
It seems to cover a lot of bases, too: a student's HTML must validate, she has to get her feet wet with at least a little bit of JS and Ruby, she'll have to open up Photoshop at least once--a pretty well-rounded picture of a project lifecycle.
It might be neat to add an additional project onto the end on deployment, so students would have to muck around on a command line a little bit, configure Apache, etc.
I think this illustrates fairly clearly one of the problems that I encounter in web app code all the time: prevention of SQL injection attacks is covered last. This makes novice developers think that it is an optional step or something that can be put off until the functional portion of the code is done. Instead it should be taught as soon as databases are discussed. Better yet, don't even give the student the option to write queries with unescaped data. Instead teach them that you have to use prepared statements, etc. and that's the only way to use databases. I would rather see secure code that's a bit obtuse, than a half baked concise code that leaves gaping holes or, worse yet, relies on silliness like PHP's magic quotes.
I do agree here. As I mentioned the first version of the class was both security and programming. The projects were intermingled giving students A great overview. Unfortunately in the 10 weeks of the quarter it's hard to cover both in great depth giving only a cursory understanding of both. There is a separate great intro to security class cs155 (which I also TAed). I believe the professors were thinking of creating a class entirely on web security at some point.
I will add however that as security gets baked into frameworks, students are not at least pickng up bad habbits.
Well, I can certainly appreciate a separate security based course. However, my point that preventing SQL injections should not be viewed as security. Just like you shouldn't write code that takes as input other code and blindly runs it on the server; or serves any file on the server without any sort of checks. Using prepared statements, or if you can't, at least manually escaping user data, is part of writing functional code. A program that does not do this is not functional and as much as writing down an example that shows how to do it breeds bad code.
The number of new hires (all but one, and that kid actually turned out to be a college dropout. Unfortunately the company got rid of him even though he knew his stuff because he lied about having a 4 year degree) that I've had to teach what a prepared statement was has been really rather ludicrous. In a basic CRUD web app, there should be no reason to be building string-based queries, ever.
The only case I can make for not using them is that in PHP the MySQL prepared statements API is very cumbersome. At my job, we use an ORM PHP abstraction model that could really benefit from prepared statements, but because of the difficulty of getting a simple associate array of data out of an executed prepared statement, it is nearly impossible for us to convert it to use them. But yes, the benefits clearly outweigh the drawbacks: you get security and performance.
Not really an excuse. Layers of abstraction are all about hiding difficulties with using APIs. If PHPs API for accessing prepared statements is cumbersome, then write a wrapper around it that solves the problem once.
Hell, I even did it for ADO.NET. ADO.NET is not that hard to use, but a surprising number of developers get a lot of the details wrong, such as when to open and close a connection (i.e. NOT once for every query) and when to dispose objects (at least at some point in the object's lifetime, please!). So, I wrote an ADO.NET wrapper that handles all of that stuff, providing an incredibly thin, simplistic interface. It's been very useful to me, and hopefully other people can find it useful, http://sqlsiphon.codeplex.com
I think there's a big space missing in learning to make web applications (this doesn't fill it). We often see material about the raw stuff (js,ajax,css), but we don't see material that focusses on HOW you should use that raw stuff. This is the most important part.
This course uses Rails, so I imagine you get a good overview of how you do stuff....but that's just how Rails says you should.
Does anyone have framework agnostic material that talks on a higher level about how we should be doing things?
I am working through this book right now, very slowly since I have a lot of other stuff going on right now. Links to my source code so far, as well as my running website-in-progress, are below.
I'm still at the part of the book where it provides guidelines for selecting tools (I chose Sinatra, Sequel, and Heroku), and exercises to become more comfortable with those tools. The next chapter is about planning.
Seconded. I just finished the first chapter of this book and it's really worth it.
I want to complete a project using Common Lisp. And I'm using Hunchentoot as a webserver, Postgresql as a database and the Postmodern library to interact with it.
Well, I wrote a simple blog engine after finishing the chapter
although I don't use a database here, the blog is saved directly to
disk (http://github.com/l0stman/Blog).
The biggest hurdle with Common Lisp is configuring the system
correctly because there's no out of the box solution. Although
there's a lot of library -- http://www.cliki.net is a great resource
-- figuring out how to use asdf-install is a bit painful. I took me
almost four days to figure out how to launch Hunchentoot as a daemon
at startup under FreeBSD
(http://github.com/l0stman/Hunchentoot-daemon). In my case, the lisp
server itself lays behind nginx as a proxy. The latter serves the
static pages too. Here's nginx's configuration:
server {
listen 80;
server_name localhost;
location / {
root /usr/local/www/nginx;
# Use absract URL for static pages
try_files $uri.html $uri/index.html $uri $uri.txt @fallback;
}
location @fallback {
return 404;
}
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;
}
# Tunnel all requests where the URI path begins with "/ht"
# to a Hunchentoot server listening on 127.0.0.1:8080
#
location /ht/ {
rewrite ^/ht/(.*)$ /$1 break;
proxy_pass http://127.0.0.1:8080;
proxy_redirect http://127.0.0.1:8080 /ht;
proxy_read_timeout 300;
}
}
Well...I haven't read the book, just skimmed through the chapters, but no, that looks more like a beginner book which focusses on the tools and the end goal rather than how to use the tools.
I see a whole lot of programming and absolutely no functional, technical, or graphic design. This isn't "learning how to create web applications", this is "learning how to be the last team member on a web application project."
This is a problem that I have with the current state of "software developer" programs at most of today's universities, be they Computer Science or Software Engineering degrees. They give the student the impression that they actually know the subject by the time they graduate when they've really only taught the easiest, smallest part--the programming, and usually rather poorly.
Most graduating computer science students are going to go into a software development position, probably web development, so it is good that Stanford is at least introducing students to the, erhm, "unique" challenges that crop up in web dev. But they're missing some of the most important lessons, like what a project life cycle looks like, why the principles of security must be the 1st consideration, not the last (how many times do people make a thumbnail project with no auth or permission mgmt and then graft it in after?), how to design a non-trivial database, how to make pages that look somewhat decent (and no, it doesn't take an artist, you can easily do a site survey and just ape the current trends, something any copy-pasta programmer should be able to do), how to approach a project as more than just a seat-of-the-pants hacker. Some programs touch on all of this stuff, but they never inculcate them as essential elements, they are all presented as tertiary to programming.
I strongly agree. Most of the time people base their first impressions on how an app looks, not what it does. That makes it pretty hard to be successful if you only know how to tweak the latter.
I would also argue that being able to design workflows is very important. If your app is simple to use and well thought out it's going to be much more sticky...
The class has been split, and this is now just a Web Programming class. I helped design project 1 and project 7 (my screenshots are still being used :-)! Highly recommended for those who want a nice intro to modern web programming.