HTML, CSS, app engine API (Datastore, webapp, Jinja, BlobStore, URL Fetch, Image), Python, JavaScript, jQuery, DOM, AJAX, canvas, etc, etc.
The main challenge in teaching this class is that it is simply impossible to cover all the details of all the technologies involved in lecture: 1000 hours of lecture would not be enough. Thus, all I can do is provide an overview of how the new technologies work and then give the students a weekly homework that uses those technologies. Once they hit a wall trying to use the technology they can come back to me with their problem.
One-on-One Friday Classes
Of course, many times the problem they have has nothing to do with the technology at hand. For example, a homework on using the Datastore might not work because the student does not know that None != "" in Python (or, any one a million other bits of knowledge).
This is partly why I set up Friday classes to be an exclusive one-on-one session between the students and me, where they can ask me any questions about the project and I will debug it for them. I was also always available via email, IM, and SMS, and several students took advantage of this opportunity.
Attendance to the Friday one-on-one sessions was very low, around 25%, usually the same few students. The no-shows included some that did well in the class, and some that did not. Some od the no-shows were actually very active via email/IM/SMS, which is probably a better way to get help (except that I go to sleep and wake up much earlier than most students).
So, I think Friday classes worked out OK, but next time I will be taking attendance. Sometimes, you gotta cajole people into doing what is good for them.
Github
This was also the first time I required the use of git+github. The students had to push their weekly homeworks to github so I could grade them.
I was a bit worried that they would get lost with the complexities of eclipse+egit+github, but after having a lecture and making a video on it, and helping them get it all installed it worked out very well. I used the simplest possible workflow: just commit to master and push to github when done. That is, all they had to understand was Team->Commit and Team->Push.
Still, there were a couple of students who had problems with their repos up until the end. I think because they were (accidentally?) using git commands they did not understand.
Also, most of the students were still just making one big commit just before turning in the weekly homework, even after constant reminders in class that they should be committing after each bit of functionality is implemented. But, I expected this. The same thing happens when I force students to use source control in 492.
Github really shined in helping me provide email/IM help to the students. Many times a student would email me saying that their program did not work. I could then just tell them to push it to github where I could see it all and figure out what was wrong. If needed, I could pull it and run it on my laptop. This is especially useful because most programmers at this stage suffer from what I call premature certainty, where they are sure the bug is in part X of the code, and will email you just that part of the code because that is where the bug is, when in reality the bug is in some other part of the program.
Project Complexity
The previous time I taught this class nearly all the students complained that it required too much programming. This time, I asked the students to do even more programming than last time. This is not because I enjoy their pain (I do) but simply because the contents of this class are guided by real-world demands, not students' desire for an easy A. Still, students did better. I think this is due mostly to self-selection. Last time there were still a few students that thought that building a webapp was just 'some HTML stuff'. Most students now know that building a webapp requires lots of programming (I think, because of that facebook movie) so most were ready to put in the time.
The amount of knowledge required to build modern webapps grows every year. Some things get easier to do, but this just results in a raising of the bar so more sophisticated webapps become the norm. This year I decided not to require the students to use backbone.js, or some other MVC framework, or to create persistent connections to the server, or use Memcache, or SASS, or build a responsive website, etc. But I will probably include some of those technologies next time simply because they will be the norm in webapp development by then. I am also hoping to use node.js instead of the appengine, if someone makes it easy to deploy and manage node.js applications. Can't wait!