Final Grades and Analysis

I emailed the final grades yesterday. I'm excited that more than half the class received A's. They managed to build a sophisticated webapp, and in the process learn the basics of:

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!

Your GitHub Repo is Yours Forever

The friendly people at github like what you have been doing. So, they offered to let you keep your github repo for this class as long as you like. That is, I will not be deleting these repos at the end of the semester and they will persist indefinitely.

Of course, I recommend that you make it public at some point so you can use it as part of your resume. You can make the repo public in the 'Admin' tab.

Webapp Project

I talked a bit about the following opportunity in class earlier in the Semester:

This project will be to build a website and service for students, professors and other scholars. A significant problem in some parts of academia is that important announcements are made via a variety of electronic media platforms and are rarely machine-sortable by keyword or announcement type. One announcement might come out over a list serve and be a job announcement (here’s an example), while another is a Call For Papers over an RSS feed (here’s a HASTAC announcement – they use RSS), while a third could be the table of contents of a new book, sent to the emails of particular people. In this project, students will build a website which will aggregate announcements from across the disciplines of History and English from numerous social media platforms. Users should be able to select specific criteria of announcements they want to receive, for instance job announcements, Calls For Papers, etc., or announcements with certain key words in them. The website should process the language in the pool of all announcements it has collected for keywords specified by users. Ideally, the website would itself offer users multiple possibilities for receiving this information – over Twitter, Facebook, an RSS feed, email, in digest form, etc. I envision that the user basis for this would begin small – say about 10-20 users in the first month, but could grow quite rapidly to many thousands or more within 6 months. There is a golden opportunity here to provide a far better means of information-distribution than currently exist.

Student on the project would work in collaboration with Dr. Colin Wilder and staff at the Center for Digital Humanities at USC. If the project turns out well, students might be able to continue working at CDH in the summer or fall 2013 as well on other projects.

There is no funding for this project, but you could do it as a 498 class this Spring (we could even count it as a 500-level elective for your degree) with me as the faculty advisor. It would look great on your resume, much better and an easy class, and it could lead to further employment (ask Mike Helms about that).

Email me if you are interested.

PubSub on Wednesday

On Wednesday, for our last lecture of the semester, we will have another guest lecturer. Jonathan Mayhak will be talking about messaging queues. Specifically, using the pubsub design pattern to decouple metric tracking code on the web server from the database.

See you then!