A few weeks back, I got a chance to teach a Flask class to my local PyLadies chapter. Normally, when I run a class, I spend a lot of time typing into the shell and into an IDE, then waiting for the students to do the same. My co-teachers and I then run around trying to correct typos, indentation errors, and syntax. The end result is aching backs and feet, and quite a bit of lost time.
I began to wonder if there was a way to get that time back. Could I take typing out of the equation while still giving the student the power to play around with the material? I realized the solution was in something I touched every day: Git.
Rather than have students type examples in, why not have them check out a specific commit from the class materials and run that? They could mess around with the code, reverting once they were ready to move on. `git diff` would tell them what had changed between commits, so they could see how the new functionality had been added.
After a few weeks of outlines and careful commits, I finally had something I could use to teach a class. I decided to test it on DC PyLadies.
Teaching a class this way does require a bit more set-up than usual. We couldn’t just install Python and go. We had to install:
- All the stuff that comes with Flask
Because we only had four hours, I skipped over virtual environments, promising that we would teach that next month.
I did cheat a bit by bringing in the Flask chapter from Python in 24 Hours, since that goes through installation of almost everything above. Still, that didn’t save us from having to put fingers on keyboards. On Windows machines, we had to fix paths. Some of the Macs were finicky. I would say, all told, we spent an hour getting everyone rolling.
Starting the class
I had thought about making slides, but ran out of time. This ended up not being too much of a problem. I simply spend most of the time live coding in front of the students.
The process was simple.
- We checked out the code from my repo
- Ran git log --oneline to look at the commits
- Checked out a specific commit (starting with the second one)
- Then, we used git diff to see the difference between that commit and the last.
- Sometimes, we monkeyed around a bit.
- Finally, we’d reset and pull the next commit.
The first few commits were the hardest. There was a ton to explain, such as what a decorator was, what “starting a server” meant, what __init__.py was doing, where the heck the HTML was coming from (we hadn’t created any templates yet), etc. Even with almost minimal code, we probably spent the first hour just going over the first three commits.
Once we were over that hump, however, commits moved quickly. I’d check one out, go over the diff, and almost immediately, everyone got it. In fact, in later commits, I almost felt like I was moving too slowly.
Even with the speed-up, I still wasn’t able to cover all of the material. I had expected this, though, since the class was really meant for a longer workshop. Still, everyone left with working knowledge of Flask and a nice introduction to git.
What will I change for next time?
First off, I will most certainly factor in more time for setting up. I tried to get students to set up their own environment beforehand, but there’s no way to make sure that everyone does that. Some get stuck on an install. Others install the wrong thing.
What I’ll probably do is have a dedicated set-up time before the class starts. So, if the class starts at 1, then the set-up party starts at 12.
I’d also have someone dedicated to setting up stragglers, and make sure they do it outside of the classroom. This, of course, means I have to get a volunteer who knows Windows as well as Mac OS and Linux.
I’m also investigating doing all of the installs off of a thumb drive. We were lucky that the library’s wifi held up, but there have been some meetings where no one could get more than a trickle of bandwidth. Being able to install Flask (and all of its dependencies) without needing wifi could save a bunch of time in a pinch.
One of the things I skipped was hacking on the code together between commits. The original plan was to propose a small change, then let the students do it. Then, I’d check out the next commit to show how I did it. The room we had and the time we had were both too small, though, for this much interaction.
The code I have isn’t finished, yet. I’d like to get Flask talking to a database. I’ll probably add another project so that I can more naturally add in things like text search, pagination, and reusing data in several views (maybe a blog app? Everyone needs to write a crap blog app, so we might as well get that out of the way).
I’d also like to cover using Python Anywhere to get your site out in the wild, and perhaps even deploying to your own server (something I think everyone should know how to do).
Finally, I should add a section on tests, since this would be a good place to teach when you should write a test, and when you shouldn’t.
Want to help?
My repo is here! I’m more than happy to accept suggestions through issues and code through pull requests. All I ask is that you comment clearly in your commits so that it’s easy for anyone to know what exactly they’re going to be demoing next.
Also, try moving in baby steps. If someone wants to run the class at a faster pace, they can always skip commits. And if you want to run the class? Please do! If you can, let me know how it goes, and what would make the materials work better for you!