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!

How I solve small assignments in my computer science class

Millie chewed up some old headphones. She doesn't recommend listening to music while programming.
Millie does not recommend listening to music while programming, unfortunately. Too distracting.

Right now I’m enrolled in CISC 124, a first-year computer science course at Queen’s on object-oriented programming in Java. This is the third computer science course I’ve taken at a university level. In every course so far, instead of writing one massive essay at the end of term like in my past life of English literature, the professor requires us to write many small computer programs and submit those throughout the term. (There may also be midterms and exams, but those are not the purpose of today’s post!).

This week, I finished writing my fourth program for this course, and I want to share the strategies I’ve found helpful so far. Keep in mind that these strategies probably best apply to small programming assignments as opposed to actual projects, and I’m always learning more about the process!

Rewrite the instructions

In CISC 124, the assignment prompts tend to be pretty wordy. I like to read through the prompt and actually re-write what’s important on a separate piece of paper. I tend to do this in a visual way; I use mindmaps to signify the relationships between different classes and methods (the ignorant student’s version of UML!), and I create tables that compare the purpose of each method if some of them are pretty similar. I need to be able to explain, in my own words, what the program I’ve been assigned to write actually has to accomplish.

This step is less important for simple assignments that I can immediately wrap my head around, but for assignments with parts or algorithms that I’m not 100% on yet, I find this step is surprisingly helpful. I’ve come to realize that I am very bad at mental visualization, so verbalizing in words and writing things down is a lot easier for me than trying to imagine mentally. (I learned a lot more about visualization from The Mind’s Eye by Oliver Sacks — very cool, check it out.)

Shuffle a deck of cards in your hands

Okay, this is maybe one of the weirder strategies I’ve come up with. I mentioned above that I find visualization pretty difficult. This makes imagining even basic search algorithms tricky for me. The best way I found to combat this, weirdly enough, was to pretend that I was actually holding a deck of cards (a real-world array!) in my hands and sorting them according to the algorithm. This helped me articulate what was actually happening in the algorithm so that I could then write it in a program.

When I first started using nested for loops, I used this same method. I never actually needed to hold objects in my hands for it to work; it was enough to move my hands around and pretend I was shuffling things. I found this physicality a lot easier than completely imagining what was going on. I think this is why I find math so much easier to do on paper than in my head.

Code with a plan

When I first started writing these assignments, I’d often dive right into the coding part without taking some time to plan the program’s structure. Now that we’ve covered polymorphism in CISC 124, though, I find it much more helpful to plan out the program in advance — how will I break down the methods, classes and variables in a way that makes sense. I normally do this on a piece of paper. This helps me avoid a lot of refactoring or debugging from careless, avoidable errors.

On my latest assignment, it was extremely satisfying that I was able to compile and run the whole program successfully after just one go, passing all my tests. The saying is “measure twice, cut once,” and it applies equally to coding!

Move from top to bottom

When I want to work a little more quickly, sometimes I’ll cheat by doing the planning directly in the .java files as opposed to a piece of paper. I’ll create all the headers for the classes and methods, and include in comments what each one should take as a parameter and what it should return. Then I can start filling in the blanks.

There is something very pleasing about finishing up a program’s skeleton like this! I always got a similar feeling when I finished outlining a paper, but before I started writing it. It’s sort of like, “Okay, the assignment is now basically written, right?” You get a nice sense of the assignment as a whole, and filling in the gaps doesn’t seem as tall of an order anymore.

Talk to yourself if you get stuck

Sometimes, despite all my planning, I’ll still get a little stuck on something. This normally happens when it’s a concept I didn’t pay much attention to in-class (likely because I was tired, thinking about something else, or missed the lecture for work). My go-to solution for this is always to talk out loud to myself. I do this for math problems, too. Starting at a point in the program where I feel confident in my code, I’ll talk myself through what is happening.

Sometimes, it’s the syntax that throws me off instead of the concept (a prime example is Comparators from this past week). In cases like that, I’ll talk out loud in pseudo-code about what I want the program to do, write down that articulation, and then look through the professor’s sample code or lecture slides for something that looks like it might be able to accomplish (or be tweaked to accomplish) my end goal.

So far, at least, this has always worked. I’ve come to rely on this a lot in my darkest coding moments.

Revisit the assignment instructions

Whenever I finish the assignment, I have a little dance party with the dog. But I don’t stop there. I always make sure to look back at the assignment instructions, and this time I treat the instructions as if it’s a checklist. After every sentence, I ask myself “Did I do this in the assignment?” If I’m at all unsure, I review what I wrote and revise as needed.

The more complicated the assignments get, the more this step becomes essential — it’s very easy to miss something small. For example, in this latest assignment, there was one little sentence toward the end that said all our variables should be private or protected. Easy to miss — but very important!

I haven’t done much research into why these strategies work for me. I think it has something to do with the limitations of working memory and my personal coping mechanisms for being terrible at mental visualization. Maybe that’s a blog post for another time.

On another note, I’m sorry I missed a blog last week! The week flew by and I forgot all about my commitment to a weekly blog.