Back in Action

I think that taking a break from things every so often is absolutely necessary to maintaining sanity and motivation. The past 2 weeks, I took a break from my 100 days of web projects. I spent that time camping with my family in New Mexico. It was really nice and we had a ton of fun.

Now it’s back to work. I finished the lesson on SQLAlchemy this evening. Wow, lot’s of information, and I don’t know how much I really understood. I definitely don’t feel like I could reproduce the application without re-watching the entire video series. As this 100 days of web program goes farther and farther, I feel like I am retaining less and less information. I think it’s mostly because it’s outside of my comfort zone. I really want to find a project to work on to hone my skills, but I’m hesitant to get involved with anything until after the full 100 days.

As for my curriculum plans, well I took a break from that as well. I’m still not sure how I’m going to do things with my CS 1 class this year. I got an e-mail from CodeHS about a new CS 1 for Texas course they’re rolling out. I want to take a look at it to see what they think CS 1 looks like. I may end up using their stuff which is in Javascript. My biggest problem with Javascript for new programmers is it seems to severely lack in the debugging feedback loop. Also, I really really like Python. I need to keep an open mind though. I suppose I could use Javascript in CS 1, then Python in Advanced CS, Java in AP CS, and then let students choose their language for CS 3? It’s worth exploring.

I received a nice binder from College Board with their new AP CS framework. It’s nice to see that they are going to have online resources for teachers/students to use including multiple choice practice sets. I haven’t done a deep dive into the curriculum yet, but what I have looked at seems promising. I’m not terribly worried about my AP CS class. The students in there will be motivated and hard working for the most part. It will be their 3rd or 4th year programming (all but 2), so picking up Java should be pretty straightforward for most of them. I think the hardest part will be keeping them challenged so they don’t get lazy. That’s where UIL problems come in I think!

My “Advanced CS” classes (2nd year) will be modified from last year. I don’t think I’m going to start off with circuits this year, though I’m not sure what we will start with. Probably a bit more time on Git/Github. I need some offline ideas though, so probably some flowcharting.

The next month is going to fly by, so I hope to use that time to relax but also get a little bit of work/planning done. I don’t want to burn out before the school year starts, but I also don’t want to lose all of the great things I’ve picked up over the past few months.

Planning Ahead is Hard

I find that planning for much farther out than a week is not a good use of time. Not that I don’t have a general idea of what we’ll be doing. I mean planning in detail. More often than not, I throw out my “well planned” lesson the day or two before we’re going to do it because I think of something better. This results in some on the fly teaching, which, as Mike Zamansky pointed out in this blog post has some value for students. I generally agree with Mike’s assessment of the situation, and I’ll add this: planning is not the same as scripting. Generally I have a topic in mind for the day and I go about teaching it as I see fit (at that moment). Sometimes the examples I use will differ from class to class. This more often than not occurs because the students have different interests and, once I get to know them, I try to cater my examples to them. That only applies to direct (group) teaching though, not necessarily to assignments.

As soon as possible, I like to get students making stuff. Whether it be a program to help them with their Algebra class, a study tool for history or science vocabulary, a hangman game, a choose your own adventure game, etc. I find they are much more engaged when they’re making something they value. Since there tend to be multiple ways of creating working solutions for a project, working out a single solution ahead of time is often not as helpful. I do, at first, give them small chunks of starter code. Sometimes this code comes from me working out a program, then deleting the main chunks. Other times, it’s just to get their brains going and I haven’t necessarily figured out all of the inner workings yet.

I agree that working out problems before assigning them allows the teacher to know ahead of time what difficulties students may have and how to address those difficulties. Another advantage to working problems ahead of time is it gives me a chance to make sure the problems aren’t too hard, or go too far off-track from the objective. It also gives me a little bit of time to figure out how to extend the problems for my more advanced students who enjoy the extra challenge.

The downside to this of course is students think that I know everything and this stuff should be easy. I also have a really hard time resisting the temptation to help them by just telling them what to do (especially later in the day).

Also, by having prepared solutions, they don’t see me pounding my head on the table trying to figure out what is wrong with my code. They don’t see my missing colon, missed indentation, misspelled variable names, missing return statements, etc. They see a finished product that took problem solving and hard work, but they don’t actually see me working hard. I don’t think they believe me either when I tell them how much effort I put into my solutions. 🙂

While knowing potential pitfalls students are going to run into, I find that proactively pointing these out is generally a waste of time. The students have to encounter the problem before they are listening for a solution. I don’t know how many times I have warned the class up front about a particularly tricky problem (and how they might go about handling it) to just have them ask me 5 minutes later anyway, “What did you say?” In fact, when they run into a problem, I really want them using their resources (Python/Java documentation, Google, Stack Exchange, a classmate, etc.) before they ask me anyway.

I started this blog post with a very different idea of topic in mind. I am currently working on rewriting my CS 1 curriculum (if you could call it that, more like a collection of small projects and problem sets with some Google Slides and Youtube videos). I’ve been inspired by the 100 Days of Web in Python tutorials that I’ve been working through (just wrapped up day 21). I would love to create something similar for my classroom. Where each day is carefully planned out and chunked in a logical way. In my experience, most students have a different work ethic than professional programmers, hobbyists, etc. that would be taking this course along with me. As a result, my course would need to be structured differently and would need to include things besides just programming in Python.

That being said, I have a ton of ideas, but given my difficulty planning more than a week out, it’s hard for me to really flush them out. I now have two full years of teaching Python under my belt, and while I think I’m getting the hang of things for the most part, I’m still struggling with a few things:

  • Sequencing: what should I start with? how far should we go? Last year, I started with Turtle graphics and the kids did really well. This year, I’m considering going back to ASCII art and printing/inputting text before introducing the Turtle. By the end of the 2nd semester, students have used OOP to build a basic “Tron” style 2 player game using the Turtle module.
  • Homework submission: While not really directly related to the curriculum, I need to have some idea of how students will be turning in the assignments. I still don’t have a good system in place for students to submit their assignments. I have used Google classroom the past two years. The downside is, I have to have all of the assignments created in Google Classroom. Once I create them, they’re difficult to change if I need to (you have to edit each class individually after creation). I like the ability to give feedback within the system (not that the students read my feedback, but it’s nice to have it there nonetheless). I’m trying to create the curriculum on Github, and, while I guess I can link to the individual assignments, I would prefer a more integrated approach. I use Github Classroom with my 2nd year and AP classes, but I don’t want that kind of cognitive overhead in my intro course.
  • Getting everything in there and documenting it. I teach in Texas where we have K-12 standards for CS. The CS1 standards (called TEKS in Texas) are kind of all over the place. I need to figure out better ways of incorporating the non-programming parts of the standards into my class. We have talked about computing ethics, open source software, and the like just a little each of the past two years. I would really like to hit that a little more if we can. We used Linux in my classroom this year after the first semester, so we talked a little bit about operating systems, viruses, and security, but again not in much detail or depth. We did a brief foray into MakeCode/Javascript but did not discuss other programming languages beyond the (false)dichotomy of compiled/interpreted. I’m sure there are another handful of standards that we either barely touched on or left out all together.
  • Information delivery: what is the best medium to pass on information to students? Students tend to avoid reading carefully, like the plague. I really dislike full class teaching, especially when it comes to coding. I find that very few students can actually keep up when I live code. If I provide my code, then they just tune out, thinking they will be able to figure it out when I finally stop talking. I generally make short tutorial videos and put them on Youtube, but that is a problem when the school wifi decides to have a bad day. There are of course advantages and disadvantages to these ways of delivering content. Some combination is probably best.
  • Not getting bogged down: This is more about creating the curriculum than teaching it. I tend to overthink assignments, materials, videos, etc. at first. Do I start here, or there, or what about if we did that? It results in a paralysis of choice. I think I just need to start writing, and then worry about organizing later.

Of course all of this begs the question, why make my own stuff? I’m familiar with CodeHS (who are FINALLY switching to Python 3 this summer), Code.org, CodeCombat, etc. But for the past 13 years of teaching, I’ve always had more success making my own teaching materials than using someone else’s. I like the freedom it provides. While it is definitely time consuming, I find that I’m not able to deliver someone else’s lessons with the same gusto as my own. Maybe it’s just my imagination.

Honestly, I would be interested if anyone is familiar with an open-source project to build a high school computer science curriculum (lessons, activities, etc. not just a book) with Python as the language. I didn’t find anything after a few Google searches. I’m aware of the EDU-SIG resources at python.org, but many of the free resources on that page are either dead links or go to projects that are/have ended.

For now, I only have the first few days’ activities loosely planned (with solutions of course). Once I get a bit further, I plan on sharing with the world to anyone who wants to use it or contribute to it. But like I said, planning ahead is hard, so we’ll see how far I can get before the new school year is upon us.

How do you Google?

It used to be that if the teacher didn’t know something, and we couldn’t find it in the adopted textbook, there wasn’t much else to be done. I mean, you could go to the library, or try to find an article someplace, but it was difficult and time consuming and unless the question was extremely compelling, it just wasn’t worth the effort to us (the students). But times have changed…

In this day and age, teachers are no longer “Founts of Wisdom” as they once were; textbooks are not the only place for information on a subject (in fact, many classrooms don’t even use the adopted textbook anymore). Today’s students have more tools at their disposal for getting information. That being said, most students really only use one tool: Google.

Most of the time when students ask me a question, I answer with a question. One of my goals as a teacher is to foster independent learning. My usual go to is, “How could you find that out for yourself?” I want students to know how to find information on their own, and not rely on me to provide it. That’s not to say I don’t answer some of their questions. In particular, if there is a feature of the language that we are not fully taking advantage of to keep things simple, I will often just answer their question. When asked, students inevitably respond, “I can Google it.” With some topics, Google is pretty straight forward. But with technical things (like programming) students often aren’t sure what they should use as their search terms. They also have difficulty narrowing down or eliminating irrelevant information from the Google results.

Using Google (or any search engine for that matter) is a learned skill. I think most teachers are pretty good at it because we are used to searching for information by key word or concept, and then iterating on that search to hone down the results to what we think might be useful. However, we tend to take for granted that students will be able to effectively use Google to find what they’re looking for.

No one taught me how to use search engines. I was around in the bad old days of search engines like Lycos, Webcrawler, and Alta Vista. Using these search engines required using logical operators in order to get useful results. While Google has made searching much easier (generally Google is pretty good at guessing what you’re looking for), finding useful results for programming often requires multiple searches, with slight modifications in the searched words or phrase based on the returned results. This iterative process of searching requires some patience and the ability to determine relevancy of the search results quickly. When you’re new to a topic, that second point can be difficult. The best way to improve that is with practice and experience. These things take time but we often don’t give ample time to develop them.

I think this year, I’m going to spend a little bit of time (maybe a week before we get into programming) having students develop their “Googling” skills. I’m not 100% sure what that’s going to look like right now, but I came across this page with lesson plans from Google on improving search engine use. I haven’t had a chance to look closely at the lessons, but at a glance they seem promising.

What is your approach to teaching students to use search engines?

Block-Based vs Text-Based for my Intro CS Course (High School)

The past two years I have used Adafruit’s Circuit Playground Express in my CS1 classes. The students really enjoy working with them, and while there were a few hiccups this year (more about that in another post), I felt like it was time well spent and the students learn quite a bit.

The CPX is this really nifty all-in-one device that runs Circuitpython. It has built in touch sensors, buttons, a switch, speaker, temperature sensor, accelerometer, infrared sender/receiver, and LED lights called Neopixels. Check out the link above for more information, but needless to say it does a LOT of cool stuff. In addition to Circuitpython, it can also run Microsoft’s MakeCode. I really like the interface for MakeCode, and actually had the students play around on the website for a bit. I used it as an opportunity to talk about “block-based” languages. Keep in mind, this came at the end of the year, so the students had about 6 months of experience with Python.

I asked them to give list some advantages to the block-based language. All of the expected ones were there:

  • No concern for syntax errors
  • No need to remember commands or keywords
  • It was easy to see what was or wasn’t allowed because of the shape of the blocks
  • No need to go looking through documentation to find an available list of functions, just search through the pretty colored categories.

I then asked for any disadvantages:

  • Once you were familiar with the keywords or functions, it became tedious to use the drag-and-drop interface
  • They didn’t think they could add their own custom functions (which I showed them afterwards could be done pretty easily in the “advanced” section)
  • In line with the previous, they felt like the block-based coding was more restricted than text-based, but they could not articulate why they thought that
  • Removing or changing blocks is tedious; if there is a very small change necessary you often have to drag apart multiple groupings of blocks in order to make the change.

These issues were very similar to the complaints that my OnRamps classes had about Scratch, so no real surprises here.

I then asked which style of language they preferred. They unanimously agreed that while MakeCode might be easier for a beginner, they still preferred Python. This is understandable: they just spent 6 months learning a text-based language, of course they’re going to prefer what they are familiar with!

(I did show them how MakeCode would convert very nicely to Javascript. BUT since they aren’t familiar with Javascript, they did not see the advantage that brings. So our discussion focused on the block-based nature of MakeCode. I’m not comparing Python to MakeCode, but instead block-based to text-based.)

Finally, I asked them to put on their beginner hats for a moment and rewind time. I told them to go back to their August 2018 self, who doesn’t know any programming. Would that self have preferred the block-based language, even if just for a month to learn? Every one of them said “no”. They gave some interesting reasons for this (I am elaborating on their responses a bit, none of these are word for word what they said):

  • Starting with something more “difficult” when you don’t know any better is easier than starting easy and working your way to difficult.
    • My analogy for this one: Pretend you have two dumbells (weights), one is 5 lbs and one is 30 lbs. Which will seem more difficult:
      • Pick up the 30 lb weight, or
      • First pick up the 5 lb, THEN pick up the 30 lb
    • They all said the 2nd one would be more difficult since you will have a lighter weight to compare to the heavy one, whereas in the first instance, you won’t know any better and just kind of go with it.
    • By starting with Python (or text-based programming) they were just under the impression that this is programming. Without an “easier” thing to compare to, they just accepted it and struggled but weren’t complaining about wanting to do things the easier way.
  • They felt a greater sense of accomplishment using Python (text-based) than using MakeCode (block-based)
    • This one is interesting, but not terribly unexpected. Block-based languages seem like anyone can do them. While this is great from a recruitment perspective, it may have an unexpected downside. Think about it, if EVERYONE can do it, then when you have difficulty you must just not be good enough!
    • I would argue that programming, whether it be block-based or text-based, is difficult and requires a lot of hard work and thinking.
    • However, when the student struggles with Python (or another text-based language), they are fine with that, because it is “hard” (and looks hard). When they finally get the program working, they feel real pride for having overcome the challenge.
    • When that same student struggles with a block-based language (Scratch/MakeCode) they feel like they can’t do something that everyone else can do. When they finally get the program working, they don’t feel the same pride because they expected for it to work the first time!
  • “Real” programmers use text-based languages.
    • Not much to say here. I challenge you to find anyone in industry (not academia) using block-based languages for their daily jobs. In fact, if you find them I would be curious to know what they’re using and why. I’m always open to new ideas!

I took a vote from my classes asking if I should start CS1 next year with a block-based language instead of Python. Not a single student said they thought I should start with block-based programming. Now there is some selection bias here, I know. The students who might benefit most from starting with block-based dropped the class at the semester. This wasn’t a large number, but there were a few. However, I’m not convinced that those students would have stuck it out if I had used something like Scratch or MakeCode either. The students who dropped didn’t drop because of low grades (very few were failing). They dropped because they weren’t enjoying the class. I could probably argue that they weren’t enjoying it because it is “hard” and they didn’t want to exert the mental effort necessary to understand what we were doing, and if I were to use Scratch/MakeCode, it would be “easier” and would require less up front effort. I think they would eventually hit a wall though and not want to continue. Maybe it’s better they find out sooner rather than later that they don’t enjoy the subject?

While their feedback validated my thinking and some of my reasons for choosing Python for my CS1 classes, I can’t help but wonder what differences starting with Scratch would have on the class dynamic. Students would be able to get up and running with neat graphical applications much faster. They would be able to more easily share their products with family and friends. They can make cool (though probably very basic) games and applications very quickly. I wonder if that is the goal though. I mean, is computer science about instant gratification? In order to make any programs of substance, you have to have a lot of perseverance and persistence. Debugging code is a pretty useful skill that is mostly eschewed by block-based languages, if nothing else because you can’t really get syntax errors. Finally, Scratch and MakeCode often fail to reinforce the sequence of program execution; everything (seemingly) happens simultaneously. Async, threading, and multiprocessing are getting more and more common, but I can’t imagine starting off my programming journey without understanding flow of execution!

I do see how separating logic from syntax might be nice, but I think you lose something. I wonder how effective an English class would be if they used “block-based” languages. Where students could essentially drag and drop sentence stems together and just fill in a few blanks. While this strategy might be terrific for a younger audience, at some point (high school at the latest, I think) the student needs to be able to form their own thoughts into their own sentences into their own paragraphs. They need to remember how to spell some words. They need to remember some grammar rules (yes, I know they can always Google them when in doubt, but you have to remember some basics for sure!)

I think the same holds true for programming.

What is this CRUD?

I just finished day 11 of 100 days of Web with Python and am pretty pleased with how it went. The past 2 days were following along as the instructor setup an API using API Star. While overall I was able to follow along with the tutorial, there were a couple of instances where Bob (the instructor) jumped to the next step with little or no explanation and I was playing catch up. In particular, since I had never used “breakpoint()” before, when he ran the application and there was suddenly a “pdb” prompt I was very confused. I got it figured out, but I probably re-watched that part of the video 10 times trying to figure out where the “pdb” was coming from.

breakpoint() is pretty slick!

That being said, I think that “breakpoint()” is one of my new favorite functions. Apparently it was added in Python 3.7, and implements PEP553. Basically it gives you a prompt at that point in your program so you can check variable states and test functions, etc. For more information about the breakpoint() function, see this quick tutorial on Hackernoon. I can definitely see using this in class next year. Unfortunately, Kubuntu 18.04 is still on Python 3.6. I guess that means I’ll be upgrading to 19.04 in the Fall. That’s ok, I was already thinking about switching the class to Xubuntu.

CRUD Operations

Back to APIs…I actually had my 2nd year classes do some work with open-notify.org, an API for checking the whereabouts of the International Space Station, so it’s pretty neat to see how to develop the API itself.

This was my first experience with CRUD operations since my databases class in college. CRUD is an acronym that stands for Create, Read, Update, and Delete. These are the primary operations you do on elements in a database. For this particular project, we used a dictionary instead of a database, but I can see where (probably) with a few minor changes to the code, we could be using an actual database back end.

Where’s the data?

An important part of building the API is getting the data. But finding data for testing things can be difficult. I mean, it’s EVERYWHERE, but in my experience it’s often behind a pay-wall or isn’t in a very usable format for testing things. That is where Mockaroo comes in. I hadn’t seen this tool before. Basically, it lets you get up to 1000 randomly generated rows of data in JSON, csv, xls, or SQL. That’s really cool. I think we may use this next year for some practice processing csv files.

Pytest

Another major part of the past two days was using Pytest for testing the functions. In class, I have my students use the doctest module, so I don’t have any experience with Pytest. I’m looking forward to diving in tomorrow to see what is involved and may consider using it instead next year. A big advantage to doctests is they can be inserted in as documentation in the code itself. The downside to this is it (in opinion) potentially makes the program much more difficult to read. It might be nice to just have a separate .py file with a bunch of tests that I can put in the starter repo. I know you can do the same thing with doctests basically, so I’ll have to weigh the advantages and disadvantages of each a bit more.

Reinventing Google…am I doing it right?

Days 6-7 of the 100 Days of Web with Python involve recreating Google’s search page from 1998 (the logo belongs to Google, of course). It was a pretty fun exercise but didn’t take me very long. I did cheat a little (I looked at the HTML file on Google’s page in 1998 to see how they did their tables). Once I stopped thinking of a table as an Excel spreadsheet-like thing, it really made recreating the page much easier. Since it didn’t take me very long to get the basic page recreated, I decided to go ahead and work ahead. Here is my Github repo for this project.

Day 8 asks you to create a simple form for someone to register on Google (or something like that) and not worrying about style too much. Here is my form:

©2018 Google LLC All rights reserved. Google and the Google logo are registered trademarks of Google LLC.

As you can see, it’s pretty basic. I think it’s really nifty that the input field can auto validate different types, including e-mail and date. Of course the form looks kind of ugly right now. I don’t particularly like how the date input is clearly a different size from the others. So after a quick Google search, I came across the style=”width:” and set each of the input boxes to the same width:

©2018 Google LLC All rights reserved. Google and the Google logo are registered trademarks of Google LLC.

Still not perfect, but better. That’s one of the things I love about this stuff. If I don’t know how to do something, I can just look it up and generally find an acceptable way. What I don’t like is always wondering if the way I did it is the ideal way or the industry standard. That second one in particular really matters to me as a teacher. I do my best to teach my students in industry standard ways, or at least what I think they are. Sometimes a solution on Stack Exchange may just be a hack, and not really the right way of doing something.

This dilemma of industry standard practices has to be one of my constant struggles. Since I have 0 experience in industry, I’m never 100% sure what I’m teaching is a best practice. I base most of what I teach on blogs, online tutorials, and books, so I would like to think the people who write these things know how programs are written in the industry, but maybe they don’t. I mean, they have to at least know more about it than me right? But then again, here I am blogging and some new person might see my code and think I know what I’m doing. I wonder if everyone feels this way. I’ve heard it called “imposter syndrome”. Maybe I’ll do another post about that another time.

Getting the hang of HTML

Just finished day 5 of 100 Days of Web with Python. I’ve always wanted to learn HTML, or at least enough to make decent web pages. Oddly enough, by working through this one lesson, I learned more than I ever have. Michael Kennedy does such a great job of explaining things, and I’m really enjoying working through the exercises with him. Here is my Github repo for today’s stuff. It’s basically the same as the one on their site. Days 6-8 involve remaking Google’s page, then making a submission form page. I’ll put them in that repo as I work through them as well.

I decided to make a list of a few of the things I’ve learned so far:

VS Code Tricks:

  • ctrl-shift-alt-numpad down = duplicate current line (or selection)
  • VSCode has a ton of autocomplete stuff for style=
  • VSCode will auto-complete images if they are there…very cool.

HTML Stuff:

  • I understand <div> tags now! Wow, how simple. I see <div> everywhere on web pages and now I understand why.
  • Use <strong> for bold.
  • Use <input type=password> for password field
  • There are quite a few input “types” and VS Code will auto-complete
  • Add the `required` keyword to an input if it is required

After completing this lesson, I began wondering what is being taught in the high school web design course. I need to go take a look at the curriculum. This is pretty simple to get going it seems like.

After 5 days, I’m extremely pleased with my purchase, and am very much looking forward to the next 95 days!

100 Days of Web with Python

I decided to go ahead and spend some real money and finally learn some web technologies. 100 Days of Web with Python is pretty interesting so far. I’ve finished the first 3 days (1 lab) and can now create a basic web page template using Flask. Since I don’t know HTML or CSS (very well) I haven’t done much customizing. Here is my Github repo with my site so far.

My super basic Flask page

The video lectures are well paced and chunked really well. I never felt overwhelmed and was easily able to follow the instructions (even though the first instructor is using Windows 10 and I’m on Linux). He made a point of giving instructions for Windows, Mac, and Linux, and I could follow along no problem. I’m already comfortable with Vim, so that part was easy enough. When I went back today for day 3, which is basically to redo the whole process on your own without looking at the instructions (as much as possible), I used VS Code (my normal editor for Python). I was able to do about half of the process without looking at the instructions. I did forget a few little things:

  • The specific modules to import from flask haven’t sunk in completely. They’re logical enough, but I still need to connect the dots in my head completely.
  • For some reason, I keep forgetting that the templates folder has to be inside of the program folder.
  • I had to look up how to setup the virtual environment again.

One big thing that I’ve already learned which now seems so simple and obvious is virtual environments in Python. There have been so many times that I have read about using virtual environments, only to get confused about how to set them up or use them. If I had known it’s as simple as python -m venv venv, I would have started using them a LONG time ago (I don’t know how many modules I have pip-installed for a one off project that I never used again!) I will definitely have my Advanced CS courses use virtual environments next year!

Even 3 days in, I think I’m going to be very happy with my choice to start 100 days of programming. If nothing else, I’m looking forward to the journey.