BCS Term 2 review: CPSC 213, CPSC 221, ETEC 510, and MATH 221

The best lil study buddy.

Two study terms down in BCS, three more to go (… at least. And not including my work/co-op terms, of course). In December, I wrote a Term 1 review; it’s high time I give you a Term 2 review! In term 2, I took CPSC 213 and 221 (the two core CPSC 2nd-year courses apart from CPSC 210, from which I was exempted upon admission to UBC), MATH 221 (matrix algebra), and ETEC 510 (a graduate-level course on educational technology design).

The good news is that I found term 2 easier than term 1. I think this is largely thanks to the fact that I had acclimated to my new living situation and figured out how to manage my stress and workload a lot better. Probably also helped that multivariable calculus was behind me, too! This isn’t to say that my courses were easier this term. CPSC 213 and 221 are both known as tricky, busy courses. But in term 2 I spent a lot less time worrying about Millie and my landlady’s cat, or coming up with a grocery shopping routine, or getting lost on campus.

Interestingly, one of my favourite learning strategies fell by the wayside this term, too. Previously I had taken messy notes in class and then rewritten and reorganized those notes on my own time. I also made notes on all my readings. This term, I was a little more cut-throat about prioritizing my time — and that meant not rewriting all of my notes from class and even not doing all the readings (or at least being selective about them). To my surprise, I got better grades this term than last despite not doing as much ‘busy work’. Instead of writing notes, I focused on identifying weaknesses and drilling problems. I saved a lot of time this way, but this new method also required me to be much more aware of exactly when I started feeling lost in any course material — because as soon as that happened, I’d go out of my way to talk to a TA or professor about the content. Talking about my mental models of the course material with an expert helped me understand the material better and helped me correct my misconceptions much more quickly than reading or writing notes.

Anyway, without further ado, here’s my brief course review of the term.

CPSC 213: Introduction to computer systems

I really enjoyed this class and I’ve applied to be a TA this summer! In 213, you’ll get to learn a lot more about how and why a computer works at the machine code level. You also get to use C! (Yay, pointers…) The course’s main downside? CPSC 213 is a LOT of work! I recommend starting the weekly assignments as soon as they come out, doing the assignments all by yourself (no partner), and attending an office hour or the labs when you get stuck (and you will get stuck). Don’t bash your head against the wall for hours when you just can’t spot a tiny typo. I rarely read the textbook in this class, but the course companion is a godsend — sometimes the professors haven’t taught you everything you need to do the weekly assignment, so reading the course companion can clear things up. My last main piece of advice is take the time to get very comfortable with assembly in the first half of the course; if you can read and write assembly quickly and accurately, you’ll free up a lot of your time for the harder questions on the midterm and final.

CPSC 221: Basic Algorithms and Data Structures

CPSC 221 felt pretty similar to CPSC 121; once again it’s a smorgasbord of lots of different things (proofs! big-O! C++! data structures! algorithms!). Sometimes it felt less like a cohesive course, where one unit built on another, and more like a “Hey look at this cool thing! Now look at this unrelated cool thing! and WOW did you notice this third cool thing over there?!” Discovery Channel show. Unlike CPSC 213, where the assignments got harder and harder as the term progressed, 221 did the reverse: I found the coursework very heavy at the beginning (the labs and the first programming project were tough), and as the term progressed the theory assignments and programming projects got simpler. I did the readings more often in this course and found them especially helpful before diving into the labs. I had my first pair programming experiences with 221 and found it extremely helpful; although having a partner for the programming projects didn’t seem to save us much time, I think I learned much more from the assignments and realized just how enjoyable pair programming can be! The theory assignments, however, I did on my own. I think if you found CPSC 121 bearable, you will be just fine in 221 — the proofs build off of 121 pretty nicely.

ETEC 510: Design of Technology-Supported Learning Environments

This course came out of left field. Because my bridging module is “technology and education,” I was just mindlessly googling around when I found UBC’s Masters in Educational Technology. Not feeling very hopeful, I asked for special permission to be enrolled in this graduate course, and to my surprise they let me in! I was expecting a lot of research on current educational software best practices, but instead this course was very theoretical. Instead of writing a research paper, I formed a team with 3 other classmates (brilliant elementary school teachers, all of them) and we created our own contribution to ed tech where we shared coding resources with K-8 teachers online. While I enjoyed learning from my peers, overall I didn’t get very much practical use from the course content. I imagine that the theory has impacted my thinking on ed tech in ways I haven’t even noticed, though, and someday if I work in the field it will affect my practice even if I’m not aware of it.

MATH 221: Matrix Algebra

Never-ending row operations … Despite doing well in this course, I never really felt like I had the hang of it until maybe five days before the final exam. I had the opposite experience in MATH 221 versus MATH 200: in 221, I felt like the math itself was straightforward (a bit of factoring, mostly basic arithmetic), but conceptually I had no idea what was going on (null spaces? column spaces? dimension vs rank? spans? basis?!). In 200, I felt like I had a good grasp of the concepts but tricky computation like integration or differentiation escaped me. Fortunately, there were some great YouTube videos called Essence of Linear Algebra on the concepts, and then I just drilled problems from class and old exams. I didn’t find the textbook too helpful — too dry, not conceptual enough for me — but everyone else I know essentially taught themselves the course from the textbook rather than attending lectures. Overall, despite some panicky moments over the course of the term, MATH 221 really wasn’t that bad.


Millie’s got her fetch face on.

I’m a little under halfway done my spring break at this point, and trying to enjoy the sunshine with Mill while fretfully applying for my first co-op position. My only project for right now is to sample as much ice cream as possible, and maybe deploy our JavaScript game from the Vancouver Game Jam if I can get ahold of one of my teammates from the weekend.

Class resumes on May 14: CPSC 313, 322 and 320. That’s Hardware and Operating Systems, Intro to Artificial Intelligence (cooooool), and Intermediate Algorithms and Data Structures. Wish me luck!

Future BCSers, don’t hesitate to leave a comment with any questions you’ve got about the upcoming year.

 

nwHacks and the little Android app that could

I attended a second major hackathon this past term called nwHacks in March. nwHacks is western Canada’s largest hackathon, 24 hours of coding, and it really showed. Unlike the Vancouver Game Jam, where you just had to buy a ticket, nwHacks was a free event but it required an application something like two months in advance. I formed a team with 4 other students in my program back in January, but two weeks before the hackathon, nwHacks alerted us that only two of us were actually accepted to the event — the rest of my team was rejected.

The grading rubric for how applicants were accepted or rejected isn’t publicly available, although I think that the teammate and I who were accepted probably did have the most coding experience out of the five of us on the original team. Later I met several people who weren’t accepted — people that I thought were much more experienced and skilled than me. If you are applying to nwHacks, take the application seriously! We all thought it was just a formality so didn’t spend very much time on the application — boy, were we wrong. Go over your resume and your responses to their questions very carefully, especially if you’re a new programmer without a lot of experience or GitHub projects yet.

Fortunately, my teammate and I had other friends in the BCS program in the same boat — that is, their original team was broken up by a mix of acceptances and rejections. We formed a new team at the last minute with some other BCS students, and two days before the hackathon we decided to make an Android app that would display a list of available, personalized walking tours to the user based on the user’s location, and then guide them through the destination points on the selected tour and play the audio as the user approached.

… Yeah. We were ambitious.

When we arrived at nwHacks, the energy was already really high. It was a very different vibe from the game jam — you could tell some teams were really in it to win it, and the swag and sponsors at the event were on a whole new level. I got a t-shirt from Hootsuite that remains, to this day, my favourite pajama t-shirt (it’s so comfy), and I also got a great water bottle from Microsoft, annnnd of course tons of stickers for my laptop (yay!). On the one hand, that was pretty cool — we felt very important — but on the other hand, I definitely found it more intimidating!

Once we started coding, we quickly realized how out of depth we were. For one thing, we struggled a lot with version control. Using git came pretty easily to my team in the Game Jam, but this time around somehow we mangled up our file names and so every time one of us tried to commit, there were an endless number of merge conflicts. We didn’t fix this issue until the next morning.

We revised our plan to make it more manageable and decided to focus on getting a functional backend and frontend, so at least we could say we made an app (even if it didn’t do much). We used Google Maps and Yelp’s APIs to provide the data for three dummy walking tours (latitude/longitude, address, name of each destination point) and used one of the sponsors (CockroachDB — so friendly and helpful!) to store all the data. Then we had an Express Node.js server to handle requests and a JSON parser that finally fed all of this data to the frontend so it could be nicely displayed in the app. All of these concepts and terms were new to me at the hackathon — only one of our teammates had any experience building an app, so it was a pretty big accomplishment (especially considering all the version control hiccups) that we got as far as we did!

Our team naturally split into three sub-teams, without any real discussion on our part. Two of us did UI, two of us did the Google Maps and Yelp APIs + CockroachDB, one of us did the JSON parser. We all ended up troubleshooting the server issues, although primarily the database guys set it up initially. I ended up doing most of the UI on Android Studio, but then realized that the Android emulator kept crashing my laptop (!) so I couldn’t actually test my code. Six hours into the hackathon, I started pair-programming with another teammate so we could use her computer instead. My poor little laptop went back into my bag and stayed there for most of the day.

We were understandably cranky and tired the next day (three of my teammates stayed overnight, but luckily I had a place to crash on campus). nwHacks was a higher-pressure environment, 24 hours is a lot less than the Game Jam’s 48 hours, and the version control issues holding us back were a definite source of frustration. I probably only spent about 5-10 hours actually coding, and the rest of my time was spent learning how Android Studio worked, troubleshooting our version control problems, trying to fix the Android emulator on my laptop, and discussing with my team what features we should cut so that we’d have something to demo at the end of the hackathon.

Like every hackathon I’ve attended so far, we were in the depth of despair in the last 4-6 hours. Nothing was working, we couldn’t figure out why, we felt like so much of our precious time had been wasted on silly problems … But (also like every hackathon I’ve attended so far) in the last thirty minutes of the hackathon, the original teammate and I finally figured out how to get our front and backends correctly communicating with each other, and we had a functional, non-crashing, beautiful little app! Just in time! That success was one of the highlights of my year, for sure.

At the end of the day, our WalkyTalky app displayed a list of available walking tours and, after selecting one of the walking tours, displayed a detailed list of its destination points as well as a Google Map path. “Talky” never really happened.

We ended the weekend watching all the award recipients demo their truly fabulous projects. Many of them had to do with accessibility (hardware that could read a person’s ASL signing and then translate it to text, for example), which was pretty cool to see. The winning project overall was a grocery cart that followed its owner around, scanned items placed into it, and then allowed the store manager to track and analyze shoppers’ movements and purchases through the store.

I found the Game Jam more personally enjoyable, but nwHacks pushed me much further outside of my comfort zone. I would have liked to learn more about the backend stuff going on in our project; at this point, I’ve forked the repo on GitHub and I hope to do a bit of exploring on my own to see if I can piece together everything that happened. I think my biggest takeaway from nwHacks is that any hackathon team I’m on has to go to a GitHub workshop together before starting to code!

Jamming with squirrels at the Global Game Jam 2017

I wrote my last exam yesterday (April 25) and fully intended to write a new blog (seeing as it’s so out of date) … only to realize I drafted this one some time ago, but never published!

Tomorrow I’ll write about my experiences at nwHacks, preparing for co-op applications, and a term 2 review of the BCS program. Hope you find this helpful, future BCSers!


Squirrel Adventure screenshot
Our plucky protagonist perches on a platform, pondering what to plunder next. (It accidentally became alliterative and then I just went for it.)

I’ve officially completed my second hackathon! The Global Game Jam — I was at the one in Vancouver — is an amazing, 48-hour game dev bonanza in which artists, devs, designers, you-name-it all come together for a glorious weekend of coffee, coding, and calamity. (Calamity, like when my team and I realized that our game’s baddies defied the laws of physics and started flying uncontrollably around the screen when we accidentally adjusted the gravity settings.)

This hackathon was so. much. fun. A friend from the BCS program and I formed a team along with two other UBC students we randomly met in the registration line-up. None of us had much programming experience, the two other students weren’t even majoring in CS, but it was “ride or die” from about 7pm on Friday night until Sunday at 3pm.

We settled on using JavaScript and the Phaser game dev framework using the JetBrains WebStorm IDE. Phaser is a free open source HTML5 game dev framework that has a pretty fantastic community and regular newsletter that I’ve been reading ever since. They also have many cool, actual game examples of Phaser features, like how to use sprites, create scenes, do fun things with their arcade physics, and much more. I found these examples, and their quick tutorial, an intuitive and inspiring way to get to know the framework … at first. Unfortunately, Phaser’s biggest flaw is that its official documentation is quite sparse. Want to look up a method to see what it does and what its parameters are? Cool! Find it in the docs! … But frequently the docs would only give you the name of the method and the names of its parameters — no description of what it was for, what the parameters or options meant, etc. It made debugging a pretty frustrating experience at times — we essentially learned the entire platform by looking at the given examples and experimenting a lot.

The other downside to Phaser was that basically everyone else at the hackathon opted to use the Unity game engine instead, so we couldn’t ask others for help. There was one other group that used Phaser (and they came up with a fantastic and hilarious multiplayer game called Whales Hate Birds), but they were also new to the framework and, in fact, made up of fellow BCS students! So while we chatted a bit, we couldn’t help each other too much since both of our groups were new to Phaser.

On the other hand, I feel comfortable enough in Phaser — and its online community is friendly enough — that I think I could make my own game by myself now, which is neat! I don’t think of myself as a gamer (in spite of many years in middle and high school avoiding my problems with MMORPGs …), but game development requires such a fun combination of creativity, technical skill, and story-telling that I really got addicted. If I meet any artsy/designer friends in Vancouver (I now realize that good art and design is the key to a polished game — we had to get our sprite sheets from the web), I would totally make a game as a fun personal project.

The most fun part of all, though, was getting to know the other hackathon attendees and feeling inspired by their amazing creations. 48 hours allowed us enough time to mingle and explore other projects, and wow — they were all so cool! One game required the player to use the pitch/tone of their voice to navigate the character. Another game was a sumo wrestling simulation where the players had to shift their weight on a balance board to ‘bump’ off their opponent. A few teams also played with some neat virtual reality hardware. Everybody was so creative and had so much fun; the jam’s theme was “waves,” so some people ran with that, but others just did their own thing and rocked it anyway (like we did). There’s something really special about a ton of people giving up a whole weekend to create stuff with the sole purpose of spreading joy and silliness.

What was our game, you ask? We called it Squirrel Adventure: you play a perky little squirrel just trying to collect some acorns on UBC’s Main Mall (the busiest road on campus) while evil cyclists and longboarders are hellbent on running you over during classroom rush hour. In theory, sounds pretty cool; in practice, our graphics were preeeetty amateur since we didn’t have an artist, and our game mechanics accidentally turned into “Super Mario 2D platformer” because that was the easiest to implement. We bit off way more than we could chew!

Fortunately, my team decided to stay healthy and fresh, so we always went to bed at decent times and ate regularly. Other teams stayed overnight (I don’t think I could handle that). This meant I was ready to start up at school the following week without lagging too much.

We didn’t manage to deploy the game, so I can’t share it with you yet, although one of my team members and I plan to figure that out after we’re done our exams in April. Overall, I learned a lot more about JavaScript, working in a team of programmers, version control using git, and the importance of “planning first, coding later” (learned that the hard way this time around). I definitely plan on returning to Vancouver Game Jam 2018 — hopefully with a bigger skill set and maybe even a sleeping bag!