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!

Common ground between English literature and computing

Richard Brautigan with a typewriter
Richard Brautigan. Read on for a treat.

While I’m a computer science student these days, that doesn’t mean I’m any less of a bookworm. After finishing Here’s Looking at Euclid (2011 and the best math book ever), I picked up John Markoff’s Machines of Loving Grace: The Quest for Common Ground between Humans and Robots (2015).

Machines of Loving Grace is “a sweeping history of the complicated and evolving relationship between humans and computers” (from the book flap). It’s a little drier than Here’s Looking at Euclid, but I enjoy learning about the early history of computing so it’s not too bad.

But this isn’t a book review.

Instead, I was recently struck by a passage I encountered in a chapter called “Walking Away,” about a computer scientist named Terry Winograd. Now a professor of computer science at Stanford, Winograd started as a researcher in artificial intelligence — only to abandon that field for “intelligence augmentation,” or human-centered computing, instead (Markoff’s favourite thing to talk about is the chasm between these two competing branches of computer science). Before that happened, though, Winograd developed an influential system called SHRDLU that could respond to typed commands in natural language.

Markoff’s description of SHRDLU sounded eerily familiar to me:

[SHRDLU] was an early effort at disambiguation, a thorny problem for natural language processing even today. For example, in the sentence “he put the glass on the table and it broke,” does “it” refer to the glass or the table? Without more context, neither a human nor an AI program could decide. –Markoff, p. 176

After a minute or two of thinking, I realized why this sounded so familiar — I’ve taught pronoun disambiguation before! Occasionally the Writing Centre needs my help in delivering writing workshops, and last term I taught 5 or 6 workshops to English 100 students at Queen’s on how to write effective papers. Pronoun disambiguation was a major topic, and effective writers avoid it like the plague (much like they are supposed to avoid cliches).

I’ve long wondered if somehow my background in English literature is directly contributing to my success so far in computer science classes, and maybe this is a clue. I think that when people learn how to write well — clearly, unambiguously articulate their ideas to a specific audience — those skills can pretty easily transfer to writing computer programs. My guess is that the same students who struggle with communicating their thoughts in writing will likely struggle with programming, too — and students who have learned to program well, or write well, should be able to translate those skills into clear writing or programming, respectively.

Weirdly, this is the second time in two days that I’ve encountered this idea. A friend of mine in the computer science program recently directed me to How to Design Programs. Check out this bit from the preface:

… [P]rogram design teaches the same analytical reading and writing skills as English. Even the smallest design tasks are formulated as word problems. Without critical reading skills, you cannot design programs that solve the problem and match its specifications. Conversely, program design methods force you to articulate their thoughts in proper and precise English. Indeed, our observations suggests that if you truly absorb the design recipe, you will develop your articulation skills more than anything else. “Preface” from How to Design Programs

I completely agree, and this echoes my rambling conversations that I’ve had with other writing consultants at my work and some of the STEM educators I met at the Canadian Celebration of Women in Computing conference this past January. While STEM educators worry about teaching STEM, and writing and rhetoric educators worry about teaching writing and rhetoric, I am looking incredulously at each side and wondering “Why the heck aren’t these instructors talking to each other more?”

Perhaps none of this comes as a surprise to you. I’m glad if that’s the case. Yet I have spoken to so many arts and humanities students (English literature and beyond) who don’t think they can learn computer science, and it seems to me that many computer science students share disdain for ‘fluffy,’ non-computer science or mathematics topics. (I’m not as certain of the latter since I don’t know as many computer science students, but that has been my experience in working with some engineering students, for example).

In reality, though, the fields seem to foster the same skills — the ability to read and understand texts, and to articulate your ideas with precision!

I am definitely not an expert in any of this. I don’t teach computer science, and I don’t teach writing (well, sometimes I teach writing, but not usually). These are just my impressions, and maybe there are some amazing organizations already doing this kind of work of which I’m just unaware. But I do wonder …

How many students are missing out on some really exciting breadth and knowledge because they think they’re incapable, or that the other field is irrelevant or too different from what they’re used to? Also, are STEM or writing instructors missing out on some valuable insights from each other, because they too assume the practices are too different? Is there a way to tie together clear writing skills with good program design? Wouldn’t it be awesome if more of our computer scientists could write and read as effectively as our English majors, and if more of our English majors knew how to program and think like a computer scientist?

I’ll leave you with the poem that gave Markoff’s book its title. I think this is Richard Brautigan’s most famous poem — a lot of different things are named after it — and it’s so, so good.

All Watched Over by Machines of Loving Grace

by Richard Brautigan

I like to think (and
the sooner the better!)
of a cybernetic meadow
where mammals and computers
live together in mutually
programming harmony
like pure water
touching clear sky.

I like to think
(right now, please!)
of a cybernetic forest
filled with pines and electronics
where deer stroll peacefully
past computers
as if they were flowers
with spinning blossoms.

I like to think
(it has to be!)
of a cybernetic ecology
where we are free of our labors
and joined back to nature,
returned to our mammal
brothers and sisters,
and all watched over
by machines of loving grace.

Here’s Looking at Euclid — or how I learned to stop worrying and love math

Here's Looking at Euclid book cover
Thank you, Alex Bellos.

I don’t have a typical blog post for you today. This is more of a rhapsodic book review. But first, some back story …

I did not grow up thinking of myself as “a math person.” The opposite, in fact. I have unfortunately vivid memories of ignoring the homework, failing the tests, and then being lucky enough to have a sympathetic teacher who would always let me re-take it so I could pass. I dropped math like a hot potato as soon as I could (which, in Ontario, is after grade 11).

I’m pretty sure I’m not the only one who felt that way.

I have a lot of theories as to why this was so, at least in my case. Firstly, no one in my family has anything to do with math, so I didn’t have any personal role models or anyone who could help me with homework if I ran into trouble. Secondly, I never felt a strong connection with any of my math teachers (all men, too) — it’s no coincidence that the class I loved most, English, was taught by the teachers with whom I bonded most (hi, Doc Evans, Doc Sumner and Mr. Nugent!). Finally, I also didn’t have a lot of friends in high school, and my grade 11 math class especially was full of kids I had come to dread. I remember sort of just hunkering down at my desk and watching the clock ’til the period ended.

But now that I’m venturing into computer science, “not being a math person” is no longer an option.

Fortunately, after some time and distance from high school drama, I’m not scared of math any more. Last winter I took grade 12 Advanced Functions and Calculus through the Independent Learning Centre (ILC), and in the summer I took Queen’s MATH 121, a first-year differential and integral calculus course. They all went surprisingly well!

And yet I still find myself being a little, well, nervous around math. Sort of like I don’t belong. A throwback, maybe, to when I felt socially excluded in my high school math class — except now it’s like I feel intellectually excluded by the entire field of mathematics itself (how’s that for melodramatic anthropomorphism?). When writing or reading, I feel at home, comfortable, and ready to take on any new theorist or text (my MA essay was on Jacques Derrida, for pete’s sake), but when I think about taking a more advanced math class, I still hear a little doubting voice: “Do you really think you can do this?” Intellectually I know this is silly, but emotionally it’s disheartening.

But how can I boost my math confidence or sense of belonging? This seems separate, somehow, from simply boosting my knowledge and practice of mathematics; I did well in the courses, so surely my knowledge is pretty good. It’s as if I have to shift my emotional relationship with math, instead. But how?

Enter Here’s Looking at Euclid: A Surprising Excursion through the Astonishing World of Math by Alex Bellos.

I picked up this gem of a book from Kingston’s public library. Published in 2010, Here’s Looking at Euclid shares Bellos’s lighthearted international journey through some of the most intriguing chapters of mathematics’ cultural history. It’s like an adult, non-fiction version of The Phantom Tollbooth by Norman Juster on steroids — which is to say, Here’s Looking at Euclid is AWESOME.

Steeped in a humanities background, I’ve found so much more to love and appreciate about mathematics in this book, because I’m finally starting to understand the connections between the math I’ve studied recently and the history, philosophy, and religions courses I studied in the past. To me, math always felt like this highly abstract, isolated field of study, like something found frozen at the peak of a mountain, ahistoric and eternal — but of course that’s not the case! Like everything else, math has evolved differently around the world, and almost every feature I take for granted (like our decimal system, the number zero, or the way I was taught to do multiplication) was actually invented by a person or culture for a particular purpose.

I’ve learned too many interesting things to list them all here, but one of my favourite chapters is about an Indian mathematician named Bharati Krishna Tirthaji who discovered some arithmetical tricks now known as Vedic mathematics. This is my favourite paragraph about him:

Tirthaji promoted Vedic mathematics as a gift to the nation…. Due to Tirthaji’s moral authority and charisma as a public speaker, audiences loved him. The general public, he wrote, were “highly impressed, nay, thrilled, wonder-struck and flabbergasted!” at Vedic mathematics. To those who asked whether the method was math or magic, he had a set reply: “It is both. It is magic until you understand it; and it is mathematics thereafter.” Bellos in Here’s Looking at Euclid, p. 83

That’s how I feel about math every day, Tirthaji. (I also like how he’s the one who wrote how flabbergasted and highly impressed his audiences were … What a modest dude. Also the quotation nicely foreshadows Arthur C. Clarke’s third law, which is “Any sufficiently advanced technology is indistinguishable from magic.”)

At first I was surprised by how much this book improved my confidence and feelings toward math, but upon reflection, it makes total sense. We learn best when we connect new information to things that we already know and understand (the fancy term for this is “elaborative rehearsal,” and a lot is written about this already, both informally and academically). So, in my case, having a very humanities-heavy background, I can improve my comfort level with mathematics by connecting it to my prior knowledge of and enthusiasm for world history, religious studies, and literature.

How does all of this relate to computer science or being a mature student? Well, I’ve come to respect and value my prior knowledge a lot more through this process — my MA in English literature can, after all, help me learn and appreciate math. You should respect and value your prior knowledge, too! If you ever feel stumped by a new topic, I encourage you to seek out ways to connect it to other topics that you already know a lot about.

For example, here’s a way to connect pi to basically the best female rocker of all time, Kate Bush: