Back in my Students' Shoes

Now that I am actually a "student" again, I could probably write dozens of posts with this title ... but this is the first time I've felt that head-spinning brain explosion that I suspect many of my math or CS students may have felt upon being introduced to a new topic that was heavy with both concepts and terminology.

Flashback to a typical AP Computer Science class for my students: I introduce some pretty rich content, demo some code, and have them write some code together. They do some legit troubleshooting, often using what they just learned, and then - Eureka! - by the end of the class period, they have something working and they feel good about it. The next day, they walk into class and I ask them to write an explanation of what they did yesterday, or connect the terminology to the content, and I get ... *blank stares*. Which always made me wonder, "Did they even learn anything at all the previous day???"

Of course, it was easy for me to stand on my metaphorical pedestal, having taught the content multiple times, and claim to students that they didn't truly understand something until they could explain it. I still think that is technically true ... but I also now see that there's a bit of a gray area where your brain may have started to make some significant connections, and is primed for deep learning, but is just not quite there yet. Which is all a long-winded way of saying that after a mind-blowing week of jumping into SQL, ORM, and ActiveRecord labs, I felt AMAZING about how MUCH I was learning ... and then I stopped to think about what these technologies actually are, and how they relate to each other, and I (like my students) had nothing.

So, here's my attempt to take a step back and articulate my understanding of these tools and their relationships to each other. Think of it as a little check for understanding that "teacher-me" assigned to "coder-me" before moving on.

SQL (Structured Query Language): The language of managing databases. It was fun spending a couple of days training my brain to thing along the lines of queries and "how do I access that piece of information I'm trying to find, that doesn't seem like it should be so complicated???" When we started learning about relational databases (i.e., tables with foreign key columns that relate them to other tables), the connection to object-oriented programming became clear: tables have relationships just like classes have relationships! Which brings us to...

Objected Relational Mapping (ORM): My understanding of ORM is that it allows you to access and modify a relational database using an object-oriented programming language (like Ruby). The big idea is that classes are mapped to tables, while individual rows in those tables are instances of the class they represent. This was a big "a-ha moment" for me: so far, everything we had been learning seemed to use toy examples and I still felt like something big was missing. For example, when instances of a class (like a Facebook user object) are created, are they really stored in an array called @@all??? Does an insurance company's software store its thousands of policies in a list??? I'm guessing not, and now I'm thinking these objects actually get stored in databases somewhere.

We were writing ORM's in Ruby, and the cool thing about these was that they used both Ruby and SQL so the connection between the object-side of things and the table-side of things was really transparent. To set this all up, we created a database in our environment file (that responsibility shouldn't fall to a specific class). We also created this special Ruby object that represented the connection between our Ruby program and the database we had just created.

Then, we were able to call the execute method on this special Ruby object and pass in raw SQL! This allowed us to, say, define a class method for SomeClass where we queried the table representing SomeClass to find a class instance with a specific attribute.

Just like with anything, after awhile, you get the feeling that you are doing a lot of work by hand that would be duplicated if you were creating an ORM for a different set of classes and a different database. Creating a table, saving instances to that table, and then finding an instance by an attribute all seem pretty standard. Which brings us to...

Active Record: Active Record is "just a gem" (this was emphasized multiple times) that gives you access to a bunch of standard ORM methods (create, save, find_by) you'd otherwise have to build from scratch. One cool thing about Active Record is that once you create a table called, say, users, that has columns for user_name and user_location, then your User class will automatically get instance variables corresponding to those columns! Pretty nifty, huh? (Although, I am grateful to have built some ORM's by hand first so that I could really see this relationship in a concrete way.)

Another feature of Active Record that blew my mind was the idea of creating class associations. Class associations are a concept I'm familiar with. When I taught AP Computer Science, my students did a bank account project and understood that "The Bank 'has many' BankAccounts" and that "a CheckingAccount 'is a' BankAccount", etc. Active Record lets you abstract these relationships using keywords like belongs_to and has_many that create those associations for you. Despite this being really cool, it's also not magical: what I've called "keywords" are really just "macros" that build methods for us - the same methods we'd be building if we were creating ORM's without Active Record!

Phew. Writing this all out was extremely helpful, and makes me remember that I can use my experience as an educator to benefit me as a learner. I'm starting to feel like those connections are becoming a bit more solidified and that that my brain is primed to fill in that next big hole -- How do you actually use all of this stuff to create an application that doesn't just live on your terminal and that other people can actually use???