My Octopress Blog

Digging In

We just started “Build Mode” at Flatiron, which means switching from a labs and lecture-based school day structure, to an entirely project-driven, freeform day with completely new teams. Avi gave a great pep talk to kick things off, addressing why our projects were assigned rather than self-chosen, and specifically with less-than-riveting use cases. It all boils down to the fact that as web developers, we’re often hired to solve other people’s problems; we cannot be driven by purely personal interests.

This is a message that was particularly important for me to hear. My college didn’t have a required “core”, and as a Psychology and European Studies double major I was able to relatively easily fulfill what requirements I did have. This meant I only had to take two or three classes that I really truly didn’t want to be in. You can imagine the kind of harsh wake-up call that awaits someone that has only been studying exactly what she’s interested in, with spare hours filled by passion projects that are given a level of attention that only a person living in a bubble could maintain. Avi shared a story about a project that initially seemed very dull, but after digging deeper into the issue at hand, actually led to an important innovation. Being a great developer thus means not just being able to care about other people’s problems, but also finding ways to make projects interesting that on surface may seem anything but.

My team is tasked with the “OpenExam” project, which uses student-generated quiz questions to gamify both ends of the assessment process. The fewer people that can correctly answer your question, the higher your score. While this may not have initially been my first choice, upon “digging in” I’ve found a lot to be excited about.

One thing that my Flatiron experience is a constant reminder of is how detached our concept of “education” has become from actual learning. Take away things like grades and graduation requirements and people often become very suspicious, as if they’ve forgotten entirely that the aforementioned things are meant to be indicators of what has been learnt and not an end in themselves. OpenExam is a great opportunity to engage more deeply with these ideas as it flips the testing paradigm, making success require more than just regurgitation and closely targeted cramming. I’m still admittedly a bit skeptical of this model (are students really learning if they’re just hunting down edge cases to stump people?), so it will be interesting to find ways to measure its effectiveness, deciding which key metrics to present to instructor users and how.

Figuring out what motivates people is a core psychological concept, and one we’ll be dealing with once we get into the gamification aspect of the application. How can we engage student users and motivate them beyond seeing question creation as yet another dreaded homework assignment? Once we have the core functionality down, this feature provides a lot of room for expansion and creativity.

My exposure to user testing and human computer interaction (and their relation to psychology) is arguably what got me interested in code as a full time professional pursuit, so it may be hard to believe that I didn’t see the huge opportunity here for user testing until Avi mentioned it in class on Monday. As he pointed out, since none of the projects stray very far from the realm of students learning to code, we’re all surrounded by our users. I’m really excited to try my hand at some informal user testing and usability studies, as well as play with some of the wireframing and UI tools that are out there. Coding in particular presents a unique challenge for the app. Is multiple choice really an effective way to test programming, or might we have to look into repls if we decide to dig deeper into this problem?

Of course the main goal is still to learn as much as possible about Ruby and Rails. Hopefully these points of interest will be enough to propel me, without distracting from the key task at hand.

Don’t Forget to Float

So here’s a riddle for you. When do New York’s 300+ Citibike stations look like this? a funny map Answer: The same time 5 / 2 = 2 (i.e. when you’re doing integer math in Ruby).

But allow me to step back a bit. The above map arose during the hacking portion of the awesome Citibike Civic Hacknight held last night by BetaNYC (and co-hosted by Flatiron TA Ashley!). While Citibike has yet to release a public API (though I’m told that’s imminent), developers have been able to expose a JSON API endpoint in Citibike’s source code that gives a live snapshot of the status at all stations. By continually scraping this data, some people have been able to put together some pretty cool things, many of which were presented last night. One of the highlights for me came not from a hacker or data scientist, but from Anthony Townsend, a research fellow at NYU’s Rudin Center. Anthony explored the possibility of redesigning neighborhoods around Citibike, using it to effectively spread the value of the subway over a larger area, and thus drawing New Yorkers into farther-flung corners of the city. You can view his deck here.

Back to the hacking!

Ashley was kind enough to put together a little mini lab for the small group of Flatiron students that attended. We used the MultiJSON gem to parse a snapshot of the station feed, turning it into a Ruby hash for us to play with. Since we were just getting started with Citibike data and didn’t have weeks of scrapes to work with, plotting the stations on a map seemed like a good simple exercise to start with. We set to work implementing that with Leaflet but quickly realized that on its way to becoming a Ruby hash, our JSON data had undergone a few changes. Namely, our GPS coordinates, which previously had eight decimal places, were now eight digit integers.

Okay, no problem – easy fix, right?

Not so fast. For those of you who have already figured out the problem here, please bear with me because I’m about to explain the meandering route I took to get there.

Part of the problem with our code at this point was that it made it look like only two sets of our coordinates were being plotted, when we should have been iterating over more than 300. I spent a lot of time staring at this, trying to figure out what else could have potentially gotten lost in the JSON translation, and what other data points these markers could inadvertently be representing. Some key names underwent some minor changes (e.g. “latitude” to “lat”), but otherwise nothing stood out as too glaring, so I decided to take a closer look at the two actual locations.



Hmmm, so the one thing these seem to have in common is their perfectly rounded coordinates…perfectly rounded…hmmm…this sounds…familiar.

Time to do something I should have done a long time ago.

integer math

Ah ha!

If you use integers in Ruby arithmetic, you get integer answers. As it turns out, those “two markers” were actually all 300+ stations, directly on top of each other. When rounded, all became either 40, -75 or 40, -74. If you want floats (i.e. decimals), you need to use them in the operation whether by adding decimal places yourself or converting with .to_f.

float

Problem solved. a real map

This is some very basic Ruby math that we all learn early on, but can easily forget because we generally don’t have much reason to use floats in our programs (40.742354 artists in your playlist, anyone?). And it’s not often that we get such a cool visualization of this common error, so I’m kind of glad this happened. Between the maps and this post, here’s betting I don’t make it again!

The Place of Flash Cards

Speaker Deck is a great resource for finding technical talks from conferences you’d otherwise never be able to attend. The downside is that every speaker utilizes their deck differently when presenting, and since Speaker Deck only hosts the static slides (that is, not accompanying video or audio), it can sometimes be difficult to ascertain a speaker’s meaning from their slides alone. Peter Evjan, the author of “Using flash cards to improve your Ruby”, the talk I’ll be discussing here (given at RubyKaigi in Toyko just a few weeks ago!), admits as much in the notes accompanying his deck. But even when that’s the case, these decks can serve as great jumping-off points to explore more on your own, and frequently yes, they are damn beautiful!

At first blush, flash cards seem like an odd tool when it comes to learning to programming. After all, flash cards belong to the domain of rote memorization, to the childhood state capitals quiz – information that is tested once and rarely used again. In my study of Ruby I’m not looking to spit out term definitions, but to one day be able to nimbly apply concepts in practical settings. And one thing I’ve been told more than once is that programming is less about what you know, and more what you can figure out. One topic that comes up a lot at a place like Flatiron School is the existence different learning styles, and last week in particular, the wisdom of reading programming books cover to cover. Avi offered that he first reads such books for breadth, just enough to become aware that a particular concept exists, and then later to remember where he read about it (further emphasizing the “figuring out” aspect of programming).

So again, what’s the use of flash cards? As someone who in just the last week alone wasted time writing “my own” .collect and .each_with_index methods because I either wasn’t aware they existed or forgot how they worked, I can see the benefits of memorization in this regard -it potentially saves a lot of time! Memorizing exactly how .collect works and what it returns would make it easier for me to recognize when to use it in practice. I’ve also seen instances where a classmate suggested a method that no one else was even aware of. For those less-frequently used methods, flash cards might be a good answer to that “know that they exist” part of the equation. And as someone who is learning a bunch of new technologies at once, learning the correct terminology to go along with them is crucial to being able to discuss programming issues in a meaningful matter. So perhaps a little terms memorization isn’t uncalled for after all.

It’s worth mentioning that Evjan is advocating for a more sophisticated type of flash card use than we may have used for those state capitals –spaced repetition as utilized by the (mostly free) flash card program Anki. Spaced repetition is a learning technique that takes advantage of the spacing effect, which holds that items are more easily recalled when they are studied a few times over a longer period of time as opposed to many times over a short period of time. Anki takes feedback from the user after each answer (on whether it was remembered easily, with a small error, etc.) to construct an algorithm that determines when and how often to quiz the user again on that particular item. I’ve just started to look into the capabilities of Anki, but I look forward to finding ways to incorporate it into my Ruby regimen!

Why I’m Learning to Code

Because I have a tendency to be long winded and um, “tangential,” I’ve tended to approach the “why code?” question with a convenient “oh, lots of reasons” in the interest of sparing people my spiel. But since a first post is the perfect the opportunity to explore these reasons and tuck them away for easy reference, I thought I’d share a few here.

A (nearly) life long fascination

I initially became interested in how technology has changed the way we relate and communicate with each other because I could see it firsthand in my own life. AIM was huge when I was in high school and junior high. I owe the formation of several friendships to it, and as we all went our separate ways for college, the maintenance of many others. I find that quite remarkable for a form of communication that none of us were using just a few years before (not to mention one that, ten years later, no one is using now!)

As a former student of psychology I’m especially interested identifying the little peculiarities of online behavior and harnessing them for good. For instance, how can we use the internet’s protective shield of anonymity to encourage something other than horrific comment sections, like say, getting past the stigma of seeking mental health care?

Some other long term, big picture ideas I hope to eventually engage with: What is our always-on, multitasking culture doing to our attention spans? How can we take advantage of online dating without resorting to treating our fellow human beings like infinitely replaceable objects?

Ultimately I’m interested in working at companies that are using technology to make real life better. Learning to code is the first step.

Do I have a choice?

I’ve now worked in two industries that have been irreparably altered by technology: publishing and music. In neither case was this a change fostered from within, but rather forced from the outside. And if you believe software is truly eating the world, few industries will escape a similar disruption. To me that means adapt or become irrelevant.

Be the change (or something like that)

At some point I just got sick of repeatedly reading articles about the tech talent shortage (especially in New York) as well as abysmal gender ratios. To paraphrase one of our recent guest speakers, when you have a homogeneous tech work force, you have the same kinds of problems being addressed over and over again. Diversity in tech isn’t important merely because it’s politically correct or an ideal we should aim for, it’s important because it has real, serious implications for society. There’s no reason to resign yourself to unsatisfying work in a sector with increasingly few opportunities when there’s so much to be done elsewhere. And when you develop software, that elsewhere can be nearly anywhere.

Never again

I’ve already wasted way too much of my life just accepting conventional wisdom that there was no better way to do a particular task, only to realize later (in some cases much later), “why yes, there’s an Excel function for precisely that thing!” etc. I love that programming is about finding solutions to problems, and then making them as efficient as possible. The great thing about technology is that there’s always a “better way” to discover (or create!).

Brooklyn Based

In a very real and concrete way, I’m here because of this Brooklyn Based email I received a year ago -my first exposure to organizations like Skillcrush, Girl Develop It, and Hacker School. I had been interested in learning to code for a while, but felt like I really missed my chance by not studying CS in college, and suspected I could never get past the hobbyist level on my own. Being introduced to the idea that so many programmers were self taught anyway, and that there were now so many opportunities to learn that didn’t involve the wholesale “going back to school” really created a possibility in my mind that hadn’t been there before. That’s one daily email I’m glad I didn’t auto-delete!