Diana Kimball

thejogging: Straightened Out ‘@’ Symbol, 2013 Digital...

Mon, 13 May 2013 00:44:36 -0400

Straightened Out ‘@’ Symbol, 2013

Digital image

✍

The long tail was there all along.

What Happens Next

Tue, 07 May 2013 13:56:00 -0400

Every now and then, I write a letter about what I’ve learned lately. Today’s letter was a little different.

Over the past year, people have often wondered out loud: what will you do next? What happens after you graduate? For a while now, I’ve had a hunch. But now that it’s official, I wanted to share the news with all of you.

What’s happening next is this: I’m moving to Berlin to work at SoundCloud.

!!!

The most amazing part? Erik is, too. After two years of long distance, we’re reuniting on the other side of the world. I’ll be joining SoundCloud as a Community Manager focused on scaling up their community engagement efforts; Erik will be joining as a Developer Evangelist. I am pretty much over the moon.

I’ve been on the lookout for a way to work with David Noël ever since our first conversation. The day we met, I tweeted in awe: “Too energized to sleep after dinner & ideas with @David, thanks to @eqx1979’s introduction. Future history, left turns & leading by example.” Over the next two years, we talked all the time; every conversation blew my mind. But SoundCloud was still in Berlin, and the rest of my life was still in San Francisco, and neither city would budge. The impasse was undeniable, but so was the draw.

The first turning point came when David invited me to Berlin last November to meet with the rest of the team—just to see. What I wasn’t prepared for was that every conversation would leave me in awe. Back in my teal and orange hotel room after a day of those conversations, I remember telling Erik in disbelief: I think I need to work here. I returned to Boston exhilarated, but perplexed. I stayed that way for weeks.

The second turning point came in December. Erik and I were on FaceTime, just catching up on each other’s lives, when suddenly he brought up an idea: what if I worked at SoundCloud, too? My eyes went wide as the idea sank in; I tried my hardest not to explode with excitement. That would be AMAZING. The next time David and I talked, I mentioned the idea and he broke out one of the biggest smiles I’ve ever seen.

The rest is history…except for what happens next.

Where is this from? The song tingled like déjà vu. I hunted...

Thu, 18 Apr 2013 18:29:44 -0400

Where is this from? The song tingled like déjà vu. I hunted through my memory, grasped at keywords for clues. And found it: this scene and what it’s like to be fourteen.

elleluna: Keep moving, she said. And I did. Floored by...

Tue, 16 Apr 2013 19:45:38 -0400

elleluna:

Keep moving, she said. And I did.

Floored by Elle’s art, always.

I got absolutely lost in Lorde’s music this weekend,...

Sun, 31 Mar 2013 12:29:46 -0400

I got absolutely lost in Lorde’s music this weekend, thanks to David’s strong recommendations. Tracked down this interview:

So tell me, you go by Lorde. How did that come about?

I just made it up really. I really like the way it looks, the way it sounds. I like the way it’s kind of feminine, but it’s a Lord—it’s a male position of power you know? The e softens it too, it’s a combination of things. I mean, I like to read a lot. I’m really into how words look and sound, so that was important to me.

Can’t wait to hear more from Ella. Extraordinary.

A Day of Dev Bootcamp

Tue, 19 Feb 2013 22:39:00 -0500

I was supposed to spend yesterday in an airplane, hurtling from San Francisco back to Boston. Instead, I ended up in a fifteenth-floor conference room in Chicago with 30 aspiring web developers, getting them excited about coding.

What? How? Rewind:

It’s April 2011, and Jesse Farmer and I meet for breakfast at Stacks in San Francisco. We’ve reached a critical mass of friends in common, and so we decide to connect two more dots. Our conversation ranges from Chicago to Tumblr to fashion, but the part that sticks with me is the moment when Jesse asks: “but how do we get more women into coding?”

May 2012, and an email from Dave Hoover shows up in my inbox. We have a lot in common, not least our shared interest in mentoring and apprenticeship. It takes a while for us to hop on Skype, but once we do, it’s evident that our wavelengths are even closer than we thought. We resolve to stay in touch.

January 2013 finds me sending out my latest letter about what I’ve learned lately. In the letter, I write:

I’ve heard from a handful of people that my posts about programming have inspired them to give it a shot, or to get back in the saddle. And yes yes yes, that’s half the reason I’m doing this at all! I want more people to know what it feels like to make it to the edge. But the writing has gone about as far as it’s going to go on its own. If this work is to travel further and mean more, I need help. Will you tell people it exists?

The letter lands in Dave’s inbox; he’s been reading along. I receive a note from him in return:

If you ever find yourself in Chicago, I hope you’ll come spend some time with us at Dev Bootcamp. We push people to the edge every day and try to instill in them the ability to remain comfortable with confusion.

“Dev Bootcamp” rings a bell, and loudly: Jesse is one of its founders! Dev Bootcamp is a 9-week intensive intro to web development, and Dave is starting up the Chicago campus. Two more dots, connected in a surprising way.

Two weeks after Dave’s note about the letter, another note shows up. He’s wondering, too: how do we get more women into coding? Not just in, but into. We set up a Skype call for the afternoon of Wednesday, February 13.

On the call, I learn that Dave’s made significant progress: he and Elliott Garms and Jen Meyers have organized a day-long introduction to the Dev Bootcamp way. Through careful planning and the efforts of a supportive developer community, over 50% of those who’ve signed up for the workshop are women. But there’s still the question of how to make the most of the momentum, and how to keep it going.

This is something I think about all the time, so we dig into brainstorming. I float the idea of bringing in speakers who will tell their stories. “If I were to give a talk, it would be about how it took forever for coding to click for me…but once it did, I was hooked for good.”

“Wait. Do you want to give a talk?”

“Wait. Yes!”

“Are you free this Monday?” Monday is the day of the event.

We both laugh. The absurdity of the proposition is self-evident. It’s too soon! Unless…

“Actually, maybe. I’m supposed to be in an airplane all day. But if you can get me from San Francisco to Chicago on Sunday and from Chicago to Boston on Monday…I’m there.”

It’s getting real. We start looking up flights. “Could you stay and mentor the students all day?” I’d love nothing more. Okay! Lunch talk plus mentoring. “I have to run to a meeting,” I say, “but let me know what you think. I want to make this happen.”

By 9pm, the flights are booked. This is really happening.

Yesterday, it happened.

This one’s for you, Marie:

How do we get more women into coding? This is the answer that took me to Chicago yesterday: by telling our stories, and by seizing every opportunity to share what we’ve learned.

Thank you, Dev Bootcamp. And thank you to Dave, Jesse, Jen, and Elliott for building the momentum that made yesterday possible.

Books I've Read Lately

Sun, 27 Jan 2013 12:47:00 -0500

Since yesterday morning, I’ve been trying to make headway on a new edition of the open letter I write every now and then about what I’ve learned lately. In the beginning, I had five sections outlined: on finishing, coding, noticing, reading, and listening. I started working on the reading section because it seemed straightforward enough; just list all the books you’ve read since the end of August, right? Then add a bit of commentary where warranted.

Nope. Took forever. List seemed never-ending. Got urge to delete entirely. Then realized: maybe this belongs on my blog instead! Relief told me it was the right thing to do.

So: here are all the books I’ve read since August, filed by reason for reading. I hope that in this stack you’ll find something to love.

First off: I took a class last semester called The Moral Leader, wherein we examined the ethics of leadership through the lens of narrative. On the reading list:

American Ground: Unbuilding the World Trade Center, by William Langewiesche. I was a fourteen-year-old in Michigan when the Twin Towers came down. I felt the horror filtered through screens. What I didn’t see, didn’t even think about, was what it would take to get the ground back: how many tons of steel would have to be moved, how many careers were at stake. More than any other book I’ve read, this one helped me understand the scale of cities, the ubiquity of ambition, the transcendence of stubbornness. It’s a heavy read, but it’s worth it.
Things Fall Apart, by Chinua Achebe. I think I read this in high school, but it felt new to me. I don’t think I’d recommend it as a stand-alone read, but I got a lot out of the classroom discussion.
The Remains of the Day, by Kazuo Ishiguro. I remember reading this one as a teenager, too, but I appreciated it far more this time around. I’m moved by Ishiguro’s quiet, precise take on introspection.
This Child Will Be Great: Memoir of a Remarkable Life by Africa’s First Woman President, by Ellen Johnson Sirleaf (selections). We paired this with the documentary about Sirleaf and the rest of Liberia’s women in power at the time: Iron Ladies of Liberia (link goes to YouTube, where you can watch it in six parts). Sirleaf is complicated, but she impressed me deeply.
Personal History, by Katharine Graham (selections). Another book I read as a teenager; another book I’m glad to have returned to. I like how no-nonsense Graham is. In parts, the book reminded me of Joan Didion’s Blue Nights in that both narrate their wealth and influence matter-of-factly, with a willingness to disclose the interior struggles they still faced.

For my final paper in The Moral Leader, on “disappointing role models”:

The Prime of Miss Jean Brodie, by Muriel Spark. I didn’t end up writing about this novel, but I did enjoy reading it. Brodie’s desire to keep a stable of acolytes is so fierce, so unbecoming; exactly the kind of portrait a non-fiction profile would have trouble getting away with.
The Last Samurai, by Helen DeWitt. I wrote ten too many pages about this book because I couldn’t stop. Ludo goes on a quest to find a father figure worth looking up to, but it’s the opposite of sappy. It’s actually pretty upsetting, but by the end I felt a kind of epiphany. I gave my mom a copy for Christmas and she finished it recently, too; she told me she’d never met a protagonist quite like Ludo, and I think she’s exactly right about that.

For 24-Hour Bookclub, one of the best things I did in 2012:

Mr. Penumbra’s 24-Hour Bookstore, by Robin Sloan. SO GOOD. Go read it!
Both Flesh and Not: Essays, by David Foster Wallace. Revived my love of language.

Following recommendations from people I’ve never met in person:

It’s Always Personal: Emotion in the Workplace, by Anne Kreamer. I bought this back in July, 2011—back before business school even started! First seen on Charlie Rose, who definitely qualifies as someone I’ve never met. (Even though back in San Francisco, Erik and I spent an hour in his televised presence almost every night.) About 40% of this book is vital, and the other 60% is old hat. If you can stomach skimming, I think it’s worth it. All the boring sections rehashing Csíkszentmihályi’s flow were redeemed by the recap of research showing that women’s tear ducts are narrower than mens’ (and therefore quicker to spill over). That’s so basic that I feel I almost should have guessed it, but no: without that knowledge, rogue tears still felt…well…personal.
Mindstorms: Children, Computers, and Powerful Ideas, by Seymour Papert. Recommended by Bret Victor in an essay of his that I loved: “Learnable Programming.” I’ve never met Bret, but I hope to someday. This book blew my mind, and I’ve since bought copies for Erik and my dad. It goes way beyond computer science. If you care about learning in any way, shape, or form, you need to read this book.

On recommendations from friends:

Money, Real Quick: The story of M-PESA, by Tonny Omwansa and Nicholas Sullivan. I picked this up after reading a fascinating blog post by Christina Cacioppo. How does money move in societies where bank accounts are rare? Phone-based transfers are only half the story: the real secret is M-PESA’s vast network of cash agents.
Living Contradictions: The Women of the Baby Boom Come of Age, by Joanne Michaels. Erik’s mom wrote this book; it was published by Simon & Schuster in 1982, and she gave me a copy last year. I finally made time to read it this fall, and loved it. My main epiphany was that being a woman in the U.S. has been weird for a while now. Some of the problems and ambiguities I face are new, but many more have been simmering for upwards of 30 years. (Maybe longer?) It’s hard to find a copy of the book now—the link above goes to Amazon, which is perpetually running low on used copies—but if you’d like to read this, let me know and I’ll see what I can do.
Close to the Machine: Technophilia and its Discontents, by Ellen Ullman. First recommended in an ingenious review by Robin Sloan, later reinforced when the SF branch of techbookclub selected the book as its January read. (Which had not a little to do with Robin’s original recommendation…cause and effect go round and round.) Same deal as with Living Contradictions: this memoir of living life through technology helped me realize how much of my daily experience has roots that reach back for decades. I wrote up some thoughts on this book in my first post on Medium.
When We Were Orphans, by Kazuo Ishiguro. Perry recommended this after I finished reading The Remains of the Day for the second time. I think Remains of the Day was better, but I was glad to be able to spend more time traveling along the trains of thought that Ishiguro illuminates so well.
The $12 Million Stuffed Shark: The Curious Economics of Contemporary Art, by Don Thompson. Recommended separately by Renee and Jane. I found it absolutely riveting. I’ve seen people protest that it doesn’t go much further than saying “people are willing to pay irrational amount of money for status,” but the details of that irrationality are weird beyond words. If you’ve ever wondered what Damien Hirst is all about (and why his recent split with Larry Gagosian is of note), this is the book for you.
Ghetto at the Center of the World: Chungking Mansions, Hong Kong, by Gordon Mathews. Recommended by Jia. A gripping profile of a gritty yet supremely effective site of economic transformation. I only just started Behind the Beautiful Forevers, so I can’t draw a thorough comparison, but I predict that if you enjoyed Behind the Beautiful Forevers, this will be an excellent complement. Especially great because it gets into regulatory arbitrage! (Hong Kong is looser about visas than most developed countries are, and everything else flows from that.)
Tenth of December: Stories, by George Saunders. Recommended by Meaghan. I’ve never read Saunders before, and so his voice startled me. He writes the way people talk and think, but artfully and always with an element of surprise. I started this before I went to sleep a few nights ago, and finished it the next morning.

In other reading news: I recently completed the mysterious book cycle, and I love reading dispatches from Uncommon every Tuesday more than words can say.

I think that’s the end.

glitchnews: Andy Murray serves to Roger Federer during their...

Sat, 26 Jan 2013 09:18:09 -0500

glitchnews:

Andy Murray serves to Roger Federer during their men’s singles semi-final match at the Australian Open.

At the center, the colors are smudged like paint. I could look at this all day long. The Federer mention brings to mind Both Flesh and Not…

On Acronyms

Sat, 26 Jan 2013 09:02:17 -0500

I wrote the following paragraphs in a text file on February 17, 2010, and then threw them into the attic of an external hard drive. I dimly remember believing that they needed a lot of editing. A few years removed, I can accept that just a little editing will do.

Some time ago, I read a passage about scientific writing—I wish I could find it, I’ve looked everywhere—that had this to say about acronyms: in many domains, especially technical ones, words have very specific meanings, and using a word just left of the right one could be misleading or even disastrous. But the words are long, and hyphenated, and to use them every sentence would be tiring. So you use it once, and then you use an acronym thereafter, and that’s how paragraphs come to be filled with symbols.

This might not be news to you, but it was certainly news to me! And something of a revelation, because: I’ve observed that the deeper I go into technology, the more I resist using technical words in public places. Especially to describe experiences.

There’s a reason that company and technical cultures thrive on acronyms and coined words; shared language helps you know who’s in and who’s out. Traversing all the opaque acronyms is a rite of passage and then a tool for survival, in local configurations. In diffuse groups (devoted to programming languages, for instance), the acronyms also serve as in-group signifiers, but also serve another purpose altogether: a one-of-a-kind cluster of letters that can be typed together looks like a word as far as a search engine is concerned, and if you invent a new word you own the global namespace in a very powerful way. Synonyms are hard to search for, and so are universal experiences phrased in different ways. Names of categories are easier, and so are names of brands. And so, it seems, are acronyms. Words form the structure and the substance of information, and if you own the acronym you’ve unlocked the path to information produced by an in-group. (But they’re context-specific; acronyms don’t actually belong to you, and so sometimes there’s unintentional overlap, which is almost better for the exclusionary: you must not only recognize these all-capital words, but recognize that their letters stand for something different and that the meaning is never guaranteed, depending on domain.)

There’s more at play here, though. Sentences littered with long words repeated are tiresome, but sentences littered with capital letters are alienating. They presume prior knowledge in a way that can seem smug or clueless. And, further: if you’re writing sentences whose nouns have no synonyms, even if the themes are universal, your readers will balk and feel excluded. Even large vocabulary words, as long as they’re rendered in lowercase, can be skimmed and skipped and understood in context. They might gesture to something general. Acronyms, however, almost always point to something specific, and so if you miss the point the meaning is entirely lost.

All of this is to say: in order to address universal themes, I’ve found it helps to use words that have synonyms.

Worksheet, 1997. (Plundering the archives tonight.)

Thu, 24 Jan 2013 21:04:00 -0500

Worksheet, 1997. (Plundering the archives tonight.)

Asleep (The Smiths Cover) – Stars I read The Perks of Being a...

Thu, 24 Jan 2013 10:51:00 -0500

Asleep (The Smiths Cover) – Stars

I read The Perks of Being a Wallflower at thirteen or fourteen or fifteen, and that’s how I learned about The Smiths. The next chance I got, I opened Napster over my family’s dial-up connection and searched for the song in question—“Asleep.” (I know I had to be thirteen or fourteen or fifteen because the book came out in 1999, and, according to Wikipedia, Napster was only active beween June 1999 and July 2001.)

My search returned a lone file by an artist cryptically listed as “Benjamin B.” I downloaded the track (slowly!), listened to it, and listened to it again; almost every mix CD I made for the next few years included that song as its final track. But somehow, I persisted in believing that it was really The Smiths. Maybe I thought the metadata was messed up; maybe I thought one of the band’s members was named Benjamin B. I don’t really know what I thought, but I do know I was very surprised when I heard the studio version for the first time. For me, “Asleep” had always been a quiet, intimate track; when I eventually heard the original by The Smiths, it struck me as too spacious.

When this cover by Stars came on at the end of their new EP last night, these memories flooded me. I was listening after dark, and it was quiet.

Building SoundScout

Tue, 15 Jan 2013 14:29:00 -0500

Between November and December 2012, I built SoundScout as a way to discover up-and-coming musicians on SoundCloud. What started as a simple command-line script rapidly evolved into a Ruby app running on Sinatra, powered by two gems, deployed to Heroku, fueled by Sidekiq workers managed by a Redis instance. Building SoundScout was one of the most challenging projects I’ve ever undertaken, and one of the most satisfying by far.

It all started when I realized I wanted to find more people to follow on SoundCloud. My first impulse was to scroll through artists in my Rdio collection and then search for each name on SoundCloud in turn, but after a few minutes of rapid tapping, a realization kicked in: A computer could do this!

A quick skim of Rdio’s API documentation confirmed my hope that I’d be able to get the info I needed through their API. Meanwhile, past experience with the SoundCloud API reassured me that it would be smooth sailing on that end. Before long, it occurred to me: this had the potential to be a great final project for CS50, Harvard’s introductory computer science course (and one of my favorite classes last semester). A conversation with Erik convinced me that I could actually go beyond finding the SoundCloud accounts of my favorite Rdio artists—that the higher good would be to identify new artists to check out based the revealed preferences embedded in my Rdio data. And so, it was decided. With that decision, the next month of my life was more or less spoken for.

This is the story of that month, what I learned along the way, and where I ended up.

In the beginning, the basic workflow I had in mind went like this:

Authorize a user’s SoundCloud and Rdio accounts in order to access personalized data.
Grab a list of the user’s most-listened-to Rdio artists. (Relying on Rdio for the initial dataset provided the additional advantage of data “cleanliness”; artist names would be spelled correctly and the list of names would arrive free of duplicates.)
Iterate through the whole list of Rdio artist names; use each artist’s name to seed a separate search on SoundCloud.
Probe into the superset of SoundCloud results using SoundCloud’s API; grab relevant info such as number of tracks, number of followers, recency of the latest upload, etc.
Run a custom algorithm against that data to select the “best” of the SoundCloud results for any given Rdio artist.
Return a permalink to the top few artists’ pages on SoundCloud.

Spreadsheets are my secret weapon, so my first version of the app returned results as a CSV. They looked something like this:

By opening the CSV in Excel and turning it into a sortable table, I was able to experiment with sorting by most followers to least followers (and vice versa) and the recency of track uploads. I clicked a few of the permalinks that came out on top to see if the method had any merit. The only problem was that every time I clicked through, I got lost listening to tracks and clicking around on SoundCloud some more. I eventually concluded that this was the opposite of a problem: my plan was working.

Clicking around some more, I noticed that many of the artists’ profiles sported extensive bios. Further examination revealed that many of these bios listed the allegedly “matching” Rdio artist name within the text itself. Artists on SoundCloud were using the text of their bio to list influences, inspirations, and bands they’d opened for in the past. This was a totally emergent behavior (as far as I could tell), but also impressively reliable: I couldn’t find many cases where the pattern didn’t hold.

The current version of SoundCloud’s search API casts a wide net, but I’d stumbled across a great way to filter the results. Given a search results superset seeded by a particular Rdio artist’s name, I could boil it down to just the results that included the seeding artist’s name in the text of the bio. In Ruby (my programming language of choice), I could accomplish that filtration with the following code:

With that breakthrough, I had my primary mechanism working, and the results were already starting to look promising. The next step was to graduate from a CSV to a real database.

Rather than go the familiar Rails/ActiveRecord route, I followed a a path known to me from past projects: I quickly settled on Sinatra as my web framework and DataMapper as my ORM—an object-relational map, a kind of interface to the underlying database. Rather than inserting my results into a CSV line by line, I could create reusable database entries and connections between those entries. This meant that I could store an Rdio artist’s name in one table, associate that artist with a user of my project stored in another table, and then link both to the info for multiple SoundCloud artists stored in a third table.

Rather than crown one “most promising” SoundCloud pick for any given Rdio artist right off the bat, I decided to stash all the members of the subset and their attendant API-derived properties in my local database. Objects in a database can be sifted and sorted in much the same way that rows in a spreadsheet can. Storing info for a large number of results in my local database would let me grab a rich dataset and then use all of its properties as fodder for the development of my algorithm.

Writing the algorithm was the most interesting part of building SoundScout. In boiling down the whole universe of artists to just a handful worthy of displaying to the user, I had to think about what qualities I valued and what metrics had the potential to signal the presence of those qualities. For instance, I decided early on that I wanted to highlight “up-and-coming” artists. To me, this meant artists without too many followers on SoundCloud. But how many is “too many”? Did an arbitrary cutoff make sense, or would I need to determine the cutoff for each user in the context of the rest of the artists in their pool of candidates? I also wanted to showcase artists who would be fun and rewarding to follow—those whose actions on SoundCloud communicated that every listener mattered. And follower count and platform engagement were just two of the properties I examined. I took seven main factors into account, awarded points for each one, and summed all those points into an overall score. Here’s the full list of factors:

Follower Count Suitability: I awarded points such that the max number went to artists with 2,000 followers; the slope then descended linearly on both sides such that artists with 0 followers and 4,000 followers would each receive zero points for this measure. In a future iteration, I would probably revise this to take into account the context of the user’s candidate pool. I could order the candidates from least followers to most followers and then award the max number of points at the “happy medium,” or midpoint.
Upload Recency: I wanted to reward artists who were in the middle of an active posting streak, and so intended for the points to shake out so as to favor ultra-recency. Once I applied this measure to my own personal candidate pool, though, I realized that favoring ultra-recent posters unnecessarily and somewhat arbitrarily narrowed the field. I revised the criterion to focus on artists who had posted in the last 10 weeks, or 2.5 months. I could have tweaked that particular cutoff, but the idea was to favor artists for whom SoundCloud engagement was currently top-of-mind—perhaps they were in the middle of releasing and promoting a new album, perhaps they were in the studio and sharing behind-the-scenes work. I’d like to make this metric more useful, perhaps again by tweaking the dials according to the characteristics of a particular candidate pool.
Join Recency: Another “freshness” metric; I thought it would be nice to shower artists new to the platform with attention, so I rewarded artists whose first upload took place within the past year or sol.
Upload Frequency: I was looking for artists who uploaded, ideally, an average of once per week. To determine this, I just subtracted the date of the least recent track upload from the date of the most recent track upload to get the span of days over which the artist had been uploading, then divided the number of tracks into that span. Unfortunately, this was a very crude metric; to really figure out upload frequency, I should have sought some metric that referred to the distribution or the average gap of time between uploads. Instead, my version of “upload frequency” really just asked: if they’ve been actively uploading over a span of a lot of weeks, do they at least have a consummate number of tracks to show for it?
Platform Engagement: The goal here was to enable reciprocity; I wanted to reward artists who were using SoundCloud to the fullest, experimenting with its features, and supporting other sound creators. This measure had two components: number of fellow SoundClouders followed by the user, and number of favorites doled out. I awarded the max number of points available at 500 fellow users followed and 25 likes given. Those cutoffs were arbitrary, but I took them to be sufficient proof of engagement.
Venn: This was a measure of how much “overlap” a SoundCloud artist’s bio text had with a SoundScout user’s list of favorite Rdio artists. A SoundCloud user who cited Metric, Arcade Fire, and M83 as influences would receive a Venn score of 3 against my collection of favorite Rdio artists, since all of those artists are on my list. Any artist inspired by all three would be an artist I’d be very likely to want to check out. Heavily favoring artists with a “Venn” of at least 2 also had the advantage of suppressing anomalies created when an Rdio artist’s name was also a common word. “Metric” is a good example of that, actually; if “Metric” were the lone word matched in a SoundCloud artist’s bio text, it could easily be them proclaiming their love of the metric system. But when at least two artist names were present in the bio text, I found that they were typically being cited as I expected—that is, as artistic influences. Another criterion followed from this one, then: Confirmation, which just meant that the artist’s bio cited at least two relevant Rdio favorites. Any Venn number of 2 or greater would lead to a Confirmation value of 2, which I used as a multiplier on the final score.
Has Avatar: I took the presence of an avatar (a picture uploaded to represent the artist on their profile) as a positive signal: for artists without many followers, it provided one way to demonstrate commitment to and engagement with the platform. Also: without an avatar, the track-streaming widgets I planned to display on my results page wouldn’t look right. So this was a practical necessity, too. I allotted “Has Avatar” a value of 0 (for no avatar) or 1 (avatar present), intending to use it as a multiplier in the final evaluation.

My ultimate scoring equation looked like this:

But before I could test out the algorithm, I had to fetch data to feed to it. And fetching the data turned out to be a very, very long process at first.

Fetching Rdio favorites wasn’t so bad; I just had to issue a single API call and then stash all the resulting artists in my database, row by row. (It actually wasn’t quite that simple, but only because I’d missed a crucial feature of the Rdio API—more on that later. Anyway, calling out to Rdio was the fast part.) But fetching SoundCloud results took much longer, much longer. Let’s say my call to the Rdio API gave me 100 artist names. To run 100 individual searches seeded by that name, I’d need to make 100 separate calls to the SoundCloud API. Each of those calls could return up to 200 results; I’d need to insert all of the datapoints for each result into my database of prospects and create appropriate connections with all the other databases, too. Furthermore, to get some of the data I wanted, I’d need to make an additional per-artist call to that artist’s page of tracks, to figure out things like number of tracks and upload recency. Basically, each Rdio artist name was the tip of an iceberg that involved inserting hundreds of database rows and making multiple SoundCloud API calls, all of which took time…and all of which I was performing in serial.

That’s right: serial. At first, I only had one SoundCloud API client running. If that client was running a search, it wasn’t grabbing an artist’s tracks; furthermore, whenever the app reached the point in the loop where it inserted a bunch of rows into the database, my one SoundCloud API client would sit idle. As a result, running the script against the 600+ artists in my Rdio collection took days—yes, days. I knew that couldn’t be right, but I didn’t know how to fix it. So I waited.

Waiting wasn’t too bad. I had other classes to attend to, so I spent the better part of a week mostly just babysitting the script when I woke up in the morning and before I went to sleep at night, making sure that it didn’t get hung up on errors and checking in on its progress. Finally, I had my dataset. I ran my algorithm draft and mostly rejoiced: the results were interesting. I felt vindicated, and motivated to continue. But in order to move forward, I’d need to learn a thing a two.

What I needed was to learn how to run background jobs. That phrase had actually kicked around in my head and over text message conversations as I’d watched the script continue its slooooow progress over multiple days. I’d heard of “background jobs” before, and I had a feeling they were the solution, but I didn’t know the “right” way to implement them in the context of Ruby. Some Google searching suggested that Resque was pretty popular, but when I told Erik about my plan, he suggested I check out Sidekiq. Resque is great, and has some strong Google juice because it’s been around for a while. But Sidekiq is an up-and-coming complement/alternative (sort of like the musicians I was seeking to highlight!); as further evidence, Erik showed me the “Background Jobs” page on Ruby Toolbox, which made it clear that Sidekiq is on the rise. As an added plus, Sidekiq’s “Examples” folder included a Sinatra example that looked like it would help me get everything set up right. I was sold.

It took me about half a day to get the hang of Sidekiq, but once it finally clicked, my coding world turned inside out. What had taken days now took minutes. Instead of making API calls wait patiently in line, Sidekiq allowed me to spin up as many as 20 simultaneous API clients, each of which could go run searches and retrieve data independently. Since my app was all about casting a wide net, stashing the detailed results locally, and then running a one-time algorithm on the results, it presented an ideal use case for background jobs…and Sidekiq was the perfect companion.

I felt like I was getting close. There was still a lot to do—design a front end, deploy to Heroku, refine the algorithm, hunt down bugs—but the core of the app was working, and I felt like the hard part was behind me. Normally, this is the point in a narrative where I’d say “little did I know how wrong I was”…but fortunately, and to my huge relief, I was mostly right. Designing front ends and deploying to Heroku and equation-tweaking and bug-hunting aren’t exactly easy, but they were all at least paths I’d been down in the past. Background jobs had been the big unknown, but tackling them had provided the biggest payoff. In the case of SoundScout, I learned to run background jobs mostly out of necessity; the app just wasn’t viable without them. But I think the same logic applies even in less-dire situations: great unknowns can yield incredible surprises. I’ll try to remember that the next time familiarity beckons.

The clock was still ticking. For the purposes of CS50, the app was due at noon on a Sunday. The night before, I skipped sleep entirely—knocking out the front end, deployment, and algorithm refinements one by one. As the final half-hour ran down, I captured some screencast footage in a hurry; part of the assignment was to create a short video showcasing your app. I found a Creative Commons-licensed track by a band called Method to use as the soundtrack, rushed to edit the video in iMovie, and uploaded it to YouTube in the nick of time.

Time ran out. The assignment was over. But I wasn’t done. I wanted to see if SoundScout would work for people besides me. So I tweeted out an oblique invitation to try out the app I’d been working on, and got a few responses. I sent those people a link to the site, refreshed my database connection to watch their SoundCloud and Rdio authorizations appear, and then the Sidekiq workers were off to the races.

It was thrilling to see people really using a thing I really built. It was also maddening to see assumptions break down in practice. In one case, the entire app got derailed because a certain artist name derived from Rdio exceeded the default max string length set by DataMapper. (Fixing that was as simple as setting a new, higher maximum manually…but hunting down the bug in the first place took forever!) And extremes on the spectrum presented their own problems; searches seeded with just two Rdio artists led to thin, almost unusable results; a candidate pool derived from an Rdio list of 1000+ artists took so long to sift on the fly that a page load timed out. (The solution there was to cache results in a separate table as part of the initial search process.) But the most interesting realization hit slowly, and arrived as a result of a back-and-forth with my friend Patrick.

Throughout this recap, I’ve been using “members of a user’s Rdio collection” and “Rdio favorites” interchangeably. But they’re not actually interchangeable at all, and their incompatibility was a major source of frustration throughout the development process. What I wanted was a shortlist of each user’s most-listened-to or otherwise most-beloved Rdio artists; what I settled for, after a too-cursory initial read of the documentation, was artists whose albums belonged to the user’s Rdio collection. Rdio collections can be gigantic, as demonstrated by the 1000+ artists case. But without the ability to surface the most important artists in any given collection, I opted to prefer a wide net over an arbitrarily exclusive one.

After trying the app for himself, Patrick asked how I was determining which Rdio artists to focus on. I explained my reasoning, and he said something like: “Weird. Seems like most-listened-to artists is something the Rdio API should have.” To prove my point, I loaded up Rdio’s API documentation to confirm the URL before sharing it with him. But as I scrolled up and down the page, my heart sank and exploded: it was there all along. Rdio has a concept of “Heavy Rotation”—the most-listened-to artists and albums in a network. Turns out, they expose per-user Heavy Rotation through the API as well—complete with a hits count representing relative importance in a user’s collection.

I took a screenshot of my conversation with Patrick as the realization dawned on me in real-time:

Moral of the story: don’t give up so easily! The tool you wish existed probably already does. Keep looking, keep asking, keep trying. I hope I’ll never resign myself to apparent limitations so quickly again.

As it was, the late-breaking epiphany led to a madcap rewrite on zero sleep…which, all things considered, turned out to be pretty fun. I think part of me didn’t want it to be over, and my “how could I have missed this?!” moment kept the adrenaline going.

A month later, I still miss that adrenaline sometimes. I miss the terror of the unknown getting toppled by the thrill of discovery, over and over again. But I’ve got a new project in mind; a new unknown I’m ready to face. I’ll find my way down the rabbit hole again.

With thanks to two great Pauls: Paul Bowden, my CS50 TF, and Paul Osman, SoundCloud’s incredibly helpful API Evangelist. (Go check out his new SoundCloud API lesson on Codecademy!) The longest hug goes to Erik, for everything.

Art and Convenience: Reflections on The Cultural Cold War

Tue, 08 Jan 2013 13:33:00 -0500

Cultural freedom did not come cheap. [Between 1952 and 1969], the CIA was to pump tens of millions of dollars into the Congress for Cultural Freedom and related projects. With this kind of commitment, the CIA was in effect acting as America’s Ministry of Culture. – Frances Stonor Saunders

In July 2012, I wrote:

Did you know the 1950s CIA patronized Abstract Expressionism indirectly? Neither did I! But according to [Lewis] Hyde, the whole story is detailed in a book titled The Cultural Cold War: The CIA and the World of Arts and Letters, by Frances Stonor Saunders.

I need to read this book.

Thanks to a mysterious sender, the book appeared on my desk a week later. I started reading it right away, finished a few months later, and let it sink in for a few months more. The Cultural Cold War is a dense, difficult, painstakingly-researched book, and it blew my mind.

Because the book was so dense and difficult—Biblical in its litanies of names, dizzying in its quick cuts between poorly-illuminated scenes—I can’t recommend it without reservation. To get a flavor of the weirdness, I’d suggest this (much) shorter news piece by the book’s author, instead: “Modern art was CIA ‘weapon’”. But if you’re looking to thoroughly upend your understanding of art, prestige, and the role of government, and you’re tireless in your search for truth, this is the book for you.

At the outset of the Cold War, a sliver of the US elite identified the appeal of Communism to European intellectuals as a risk. They perceived high culture as a serious front in the struggle—one to be defended and surveilled. To fuel these efforts, they turned to counterpart funds.

Under the Marshall Plan, governments receiving U.S. funds were required to deposit a matching amount; 5% of that amount “became, upon deposit, the property of the US government.” (p. 105) As a result, “a secret fund of roughly $200 million a year [was] made available as a war chest for the CIA.” (p. 106) They called it “candy,” because it came unburdened by the threat of outrage from US taxpayers. It was free money, and the CIA spent a lot of it on art.

[The Congress for Cultural Freedom] was not to be a centre for agitation, but a beachhead in western Europe from which the advance of Communist ideas could be halted. It was to engage in a widespread and cohesive campaign of peer pressure to persuade intellectuals to dissociate themselves from Communist fronts or fellow travelling organizations. It was to encourage the intelligentsia to develop theories and arguments which were directed not at a mass audience, but at that small elite of pressure groups and statesmen who in turn determined government policy. (p. 98-9)

The spending was entirely indirect; of course the CIA couldn’t be seen funding grants and symposia, even though that’s exactly what they were doing. They funneled the money through believable benefactors such as Julius “Junkie” Fleischmann, whose “personal wealth and varied artistic patronage made him an ideally plausible angel for the CIA’s sponsorship of the Congress for Cultural Freedom.” Tom Braden, an official in the CIA, “later described Junkie as one of the many ‘rich people who wanted to be of service to the government. They got a certain amount of self-esteem out of it. They were made to feel they were big shots because they were let in on this secret expedition to battle the Communists.” (p. 126) Covert action agent William Colby described the mechanism further:

We generally reached out to find Americans who would consent to take the money into their accounts and then use it to contribute in various ways…If you went to any American institution, company, anything else, and said “Will you help your country by passing this money?” they’d salute and say “Absolutely, I’d be delighted. It’s easy to pass money around the world to the desired end objective. It might not be one bulk payment but various small payments going in the right direction. (p. 133)

Serving one’s country in secret, gaining more of the prestige afforded by philanthropy in public; what could be better? Fleischmann, in particular—”a multi-millionaire famed for his stinginess”—had a ball “dishing up CIA money an taking all the credit for it.” (p. 119) Case officer Lee Williams unpacked the motivations of these “quiet channels” further: “There sas a commonality of purpose that seemed to us to dissolve any major concern about the morality of what we were doing.” (p. 134)

The biggest obstacle standing in the way of success? Joseph McCarthy. While the CIA was vigorously promoting the tenets and exemplars of American free expression abroad, McCarthy’s campaigns began to undermine that freedom at home.

The Soviets—and indeed much of Europe—were saying that America was a cultural desert, and the behavior of US Congressmen seemed to confirm that. Eager to show the world that here was an art commensurate with America’s greatness and freedom, high-level strategists found they couldn’t publicly support it because of domestic opposition. So what did they do? They turned to the CIA. And a struggle began to assert the merits of Abstract Expressionism against attempts to smear it. (p. 257)

As for the artists—of course they sometimes wondered where all the money was coming from. But it was in their interests to not question the money too closely. Why shouldn’t the Fleischmanns of the world devote their fortunes to art? Here, I found Donald Jameson’s remarks so striking that I’ll include them in their entirety and add a few points of emphasis:

I think that almost everybody in a position of significant in the Congress [for Cultural Freedom] was aware that somehow or other the money came from some place, and if you looked around there was ultimately only one logical choice. And they made that decision. The main concern for most scholars and writers really is how you get paid for doing what you want to do. I think that, by and large, they would take money from whatever source they could get it. And so it was that the Congress and other similar organizations—both East and West—were looked upon as sort of large teats from which anybody could take a swig if they needed it and then go off and do their thing. That is one of the main reasons, really I think, for the success of the Congress: it made it possible to be a sensitive intellectual and eat. And the only other people who did that really were the communists. (p. 345)

That’s it, isn’t it? We all want it to be possible to be a sensitive intellectual and eat. I want that. Most of my friends want that. Who wouldn’t? For almost two decades, the prestige and credibility afforded by art were valuable to the CIA; priceless, almost. In the scheme of things, funding art was small potatoes. The CIA could afford to spend a few million dollars for the chance to change important people’s minds.

When I mentioned this book to a friend, he replied: “oh, art historians hate it.” I don’t know how widespread that sentiment is, but I buy into its basic premise. That the entire art apparatus of the United States could be swayed by “candy” (a sliver of a sliver of the money that went into the Cold War) and patriotism calls into question the entire endeavor. In fifty years, what patrons of today (governmental or not) will we come to understand as puppeteers of prestige?

Saunders deals with this question head-on. In fact, her book is motivated in part by a desire to show that CIA motives really did make a difference in what art was produced; that even if “quiet channels” weren’t instructing artists, they built enough preferences into the whole machinery of magazines, grants, and publishing that their favored perspective was sure to win out. In the introduction, she writes:

The defense mounted by custodians of the period—which rests on the claim that the CIA’s substantial financial investment came with no strings attached—has yet to be seriously challenged…But official documents relating to the cultural Cold War systematically undermine this myth of altruism. (p. 4)

And later in the book, she quotes Jason Epstein as saying:

It was not a matter of buying off and subverting individual writers and scholars, but of setting up an arbitrary and factitious system of values by which academic personnel were advanced, magazine editors appointed, and scholars subsidized and published, not necessarily on their merits—though those were sometimes considerable—but because of their allegiance. (p. 323)

Saunders attempts to reconcile art as independent and art as a kept field by explaining:

It is hard to sustain the argument that the Abstract Expressionists merely ‘happened to be painting in the Cold War and not for the Cold War’. Their own statements and, in some cases, political allegiances, undermine claims of ideological disengagement. But it is also the case that the work of the Abstract Expressionists cannot be reduced to the political history in which it is situated. Abstract Expressionism, like jazz, was—is—a creative phenomenon existing independently and even, yes, triumphantly, apart from the political use which was made of it. (p. 277)

But I’m still left with a wary feeling: how much are creators driven by convenience? Constraints aren’t always bad, but shadowy ones worry me. If you knew that a rubric existed and you could see its outlines by the actions of emergent winners, wouldn’t you be tempted to lean into the skeleton as it surfaced?

What I really want is a movie version of The Cultural Cold War—something riveting and troubling that we can all see and talk about. As it stands, the message is locked away in 427 difficult pages that even I would be hard-pressed to read again. Yet perhaps the chief of the CIA’s Covert Action Staff, quoted by Saunders on page 245, was onto something: “one single book can significantly change the reader’s attitude and action to an extent unmatched by the impact of any other single medium.”

If The Cultural Cold War were a movie, I would file it away in my mind as fiction. In reality, it’s all too true.

This post concludes the Mysterious Book cycle.

Sunday, January 6, 2013 marked the second meeting of 24-Hour...

Mon, 07 Jan 2013 22:30:00 -0500

Sunday, January 6, 2013 marked the second meeting of 24-Hour Bookclub—a reading flashmob anyone can join.

After spending the whole day reading Both Flesh and Not (the new collection of essays by David Foster Wallace), I set my trusty reading device down and recorded the track above, alternately rambling and rejoicing over the experience.

So much happened, and for one day it all hung together. But the links are fading away already, so I wanted to make sure to collect them all in one place before the reality we inhabited for a single day disappears completely!

First and foremost: all tweets (over 200!) from all readers.

In-depth conversations about each essay on Branch.

Highlights and notes on Readmill.

(And don’t miss the nice blog post Readmill wrote about 24-Hour Bookclub!)

I’m so happy that this happened, and can’t wait to see it happen again.

24-Hour Bookclub Tips

Sat, 05 Jan 2013 21:31:00 -0500

In just a few short hours, the latest edition of 24-Hour Bookclub—a reading flashmob you can join!—will begin. We’ll be reading Both Flesh and Not, the new collection of non-fiction essays by David Foster Wallace. If this time is anything like last time, I’m going to be delirious with happiness by the end of the day. I’m already kind of delirious with excitement.

Since a ton of readers are joining us for the first time, I thought I’d jot down a few examples of ways people have seized the day and new ideas we’re trying out this time. These are all things that people came up with spontaneously, though, so my number-one piece of advice is: experiment! If it seems like a good idea, try it. We’re all making this up as we go along, and that’s what makes it so fun.

You could…

Take a picture as you start reading. Capture the book (or the device you’re reading it on) in your natural surroundings. And if you received a membership card in the mail…might we suggest using it as a bookmark?
Pull quotes that catch your attention and post them to Twitter. Make sure to add the hashtag #24hourbookclub to all your tweets so that we can find them!
Throw an in-person reading party with friends. Last time, people in San Francisco got together to read Mr. Penumbra’s 24-Hour Bookstore in Dolores Park with bagels. This time, people are gathering in Brooklyn to read together and eat coffee cake. That’s so cool.
Write more than 140 characters on Branch! Thanks to Libby and Josh at Branch, we’re all set up with a shiny new Branch group for 24-Hour Bookclub. Click “ask to join” and we’ll let you right in once it’s Sunday morning where you are. We’ve set up separate branches for each essay in the collection. Once you finish reading “The (As it Were) Seminal Importance of Terminator 2,” for instance, you can hop on over to the associated branch and see what other people have to say, as well as adding your own thoughts. Branch and Twitter are complementary; Branch emanates quiet purpose and lively civility, where Twitter is all chaos and bright light. I’m excited to see them coexist!
Highlight in Readmill as you go along. I did this for my original solo book-in-a-day experiment and I can’t wait to do it again for Both Flesh and Not. When Matthew from Readmill interviewed me and Max over email, I realized that “calm and exhilaration are two sides of the same coin: books were made for immersion, and no experience is more immersive than Readmill.” If you’d like, you can follow my real-time highlights and notes here.
Share your thoughts out loud with SoundCloud. I love the image of a time-shifted in-person bookclub…all of us sitting around a kitchen table, talking once we have things to say. SoundCloud’s mobile apps are great for recording audio on the fly—I use their iOS app pretty much every day.

Or…just quietly read, and know that you’re in good company. I love playing with new tools, and I love that so many 24-Hour Bookclub readers do, too. But books are our first love, and if solitude feels truest to you, then that’s what you should do. This can be whatever we want it to be, and if all you need is the license to throw yourself into a book for a day…well, dear reader, we will give that to you in a heartbeat.

I hope to see you in the morning! Thank you for being a part of this.

“Weapons,” by Dad Rocks! The whole album is so good....

Sun, 30 Dec 2012 00:46:00 -0500

“Weapons,” by Dad Rocks!

The whole album is so good. Teenage me would have been head over heels, and twentysomething me is, too. I was suspicious of the band name when I saw it in SoundCloud’s Community Team Favs 2012 set (will this be like Yo Gabba Gabba crossed with Wilco?), but the music won me over quickly. This track features Charles Spearin of Broken Social Scene on cornet.

"My voice—with its grain, with its accents, with its imprecise diction, its tonalities, rhythms,..."

Sat, 29 Dec 2012 18:45:07 -0500

“My voice—with its grain, with its accents, with its imprecise diction, its tonalities, rhythms, pauses and vacillations—is witness to a presence even when I’m not there; it brings me close to people and doesn’t negate my transformative capacity because its presence is dynamic, alive and trembling even when seemingly still.”

- Wu Ming, via Jane

I love this about sound.

I’m playing with Medium.

Sat, 29 Dec 2012 15:48:00 -0500

I’m playing with Medium.

Code Log 12.4.2012

Tue, 04 Dec 2012 02:19:00 -0500

Notes on what it’s like to write code.

I woke up this morning and pulled my open laptop onto the mountainous comforter piled over my knees. Eyes blinking against the sunlight, I squinted at the Terminal window on my screen. Before email, before Twitter, before breakfast, before anything: the most pressing, exciting thing in my world at 7-something this morning was the status of the script I’d set running overnight…

…Noooooooo. I’d forgotten to turn off Energy Saver. The script had stopped when the laptop went to sleep, which is to say, right about when I went to sleep, which is to say, it hadn’t run overnight at all.

The goal had been to grab a ton of data from SoundCloud using their API, so that I could fill my database with useful test data against which to tune my algorithm. I’ve been working nonstop on this app idea I laid out exactly one month ago. It’s nominally my final project for CS50—due this Sunday!—but it’s become much more than that, as I always hoped it would.

Over Thanksgiving, I spent late nights coding at my grandma’s house in Wyoming, precariously connected to the internet over tethered cellular data. I generated piles of CSVs as I experimented with different properties that might indicate promising SoundCloud musicians inspired by artists a user follows on Rdio. My working title for the project was “Riser.” Since all my early files remained in the RIser folder, you can see the accumulated detritus of experimentation:

(Terminal sporting Erik’s dotfiles. They’re indispensable!)

As you can see, the folder was a mess. I’m philosophically okay with messiness (especially in the beginning of any new project), but I’ll admit that I added a needless layer of messiness by not using version control from the beginning.

Conceptual discomfort with version control was not the problem. I love using Git and GitHub; my GitHub profile shows 18 public repos—mostly forks of other projects—and I have 5 private ones (mostly original material) besides. The two main sticking points were subtler:

To work with the Rdio and SoundCloud APIs, I needed to hand off some personal information through my app. In the beginning, I was just storing that info willy-nilly through the code. I eventually moved it to a credentials file (credentials.yml), but still had a nagging worry; I didn’t want to risk uploading a credentials file to GitHub.
I especially didn’t want to “risk it” because I semi-remembered that I’d hit my limit of private repos on GitHub’s micro plan. (Free to students.)

In truth, I probably could have figured out what to do. My eventual solution was to delete one of my private repos (which was actually just an empty app, so it was good to get that cleaned up anyway) and to add credentials.yml to my gitignore file so that Git would, well, ignore it when deciding what to track and send to GitHub. A quick conversation with Erik was all it took to get me over the hump and into using version control (in a new folder bearing the project’s final, still-top-secret name) at last. But what’s funny is that I’d actually handled each of those situations once or twice before; they weren’t completely alien to me. Rather, the hurdles felt just unfamiliar enough that I held on to some resistance below the level of conscious awareness. Minute to minute, the sensation was: I just want to keep making my app better! But now I’m kind of disappointed not to have the full history of my progress preserved eternally on GitHub.

Next time will be better.

And the script that went to sleep? Well, that had a happy ending. After turning off Energy Saver with a flourish of righteous indignation, I spent some more morning minutes squinting at my screen (eyes slowly opening), improving the script, messing with my database, until it seemed like it was in better working condition. I set it running and then stepped outside to go get oatmeal from the cafeteria.

It was my first trip outside in…oh, about 36 hours.

I’m hopelessly hooked.

Code Log 11.4.2012

Mon, 05 Nov 2012 01:15:00 -0500

Notes on what it’s like to write code.

Today, I raced back into Ruby’s arms.

It’s hard to believe, but the end of the semester is drawing near, and so CS50 (the intro to computer science course I’m taking at Harvard) is winding down, too. Well, “winding down” would probably be an overstatement; there’s a lot of work left to do! But lectures have finally broken free of the thicket of C, and this week’s problem set will be our last. After that, there’s just one more quiz and the final project.

The final project. The specification explains: “All that we ask is that you build something of interest to you, that you solve an actual problem, that you impact campus, or that you change the world. Strive to create something that outlives this course.” I’ve built apps before, but something feels different about the prospect of this one. It might be my great love for the course; it might be the element of communal experience; it might be that CS50 itself feels like a rite of passage. It might be that in the past, apps I’ve built have always felt hacked together—hanging by a thread. This one might, too, but I’ll understand the threads so much better. I’ll see how they come together.

For a long time, I’ve imagined that I’d build my final project for iOS. The promise of being able to experience something I built on my phone just seemed impossibly cool. But after spending some time with Apple’s iOS documentation this weekend, my heart fell. In spite of my newfound (relative) comfort with C—a close relative of Objective-C, the language iOS apps are written in—the tutorials still felt insurmountable. This could be for a lot of reasons, but I have a feeling that Xcode’s cryptic interface contributed mightily.

So I backed up. I remembered RubyMotion, a “toolchain” that lets you write iOS apps in Ruby that then compile to Objective-C. Also, if the screenshots are to be believed, it lets you circumvent Xcode. Hallelujah! Seems great. The only problem is that it costs money. I visited their website for the dozenth time, and this time noticed that they were willing to discuss student discounts for those who wrote in. I wrote in. I still hope to hear back; I’d love to try it out. But in the meantime, my mind started spinning on alternatives.

The idea for the alternative I’m running with arrived unbidden, as most good ideas do. This is how it came about:

This coming Thursday, I’m traveling to Berlin—for the first time!—to visit friends at SoundCloud. I’m so, so excited for this trip. One reason: I’ve been recording daily, private audio messages to Erik using SoundCloud’s iPhone app for the past year (now up to 321 tracks totaling over 75 hours), so SoundCloud means a lot to me; this will be like a pilgrimage to the mothership. Another reason: I’ve never been to Germany, and haven’t been to Europe at all in almost eight years. Also: I’ll get to hang out with David!

So over the weekend, looking forward to the trip, I decided it was high time to follow more people on SoundCloud. My primary one-to-one use case means that I haven’t played around with many of the site’s social features, and I wanted to take those for a whirl by filling out my network a bit. The only question: how?

I was running errands while mulling this over, so I pulled up the SoundCloud app on my phone and decided to just start searching for the names of bands and musicians I like. But—well—that didn’t seem very thorough. So I opened up Rdio (my primary music app) and started scrolling through the artists in my “collection”—a list of albums stored in my account, originally built off of my iTunes library (which is itself now in deep storage on an external hard drive…Rdio and sites like HypeMachine and SoundCloud serve all of my day-to-day music needs, and SSD storage space is precious). It’s a long list; my iTunes library was huge, holding almost a decade’s worth of accumulated tracks. When I saw an artist that rang a bell as a solid favorite, I’d toggle over to the SoundCloud app on my phone and search for that artist’s name. But the hit rate was disappointingly low, and I soon grew frustrated with the workflow. This seemed like the kind of repetitive work a computer could be doing…

A computer could do this!

And that means I could make a computer do it.

The idea started to shudder to life in my mind. What if…matching?…Rdio…SoundCloud…APIs?…this must already already exist?…shouldn’t it be built in to SoundCloud?…but…well…it sounds fun.

My mind careened onto other topics, then veered back, then kept careening. Later that evening, back in front of my computer, I decided to give iOS development one more shot. I got stuck on some Xcode setting and felt totally defeated. Eventually, I went to sleep.

Today, Erik and I got to talk in real-time for the first time in a while; he was at RubyConf in Colorado for the second half of the week, and we typically rely on time-shifted methods (like my SoundCloud audio messages) during the workweek anyway. We talked about all kinds of things (including the lightning talk he gave on the T gem, his open-source command-line power tool for Twitter), but eventually ended up at the question of my final project.

I presented the options. Option 1: I attempt an iOS app, but I somehow have to figure out all of iOS development in two weekends, since I’ll be traveling for most of the rest of November and the CS50 fair (where we exhibit our apps) is on December 10. Or, Option 2: I explore this Rdio/SoundCloud idea in Ruby (a familiar language) and focus on making the interface cool. But…that didn’t feel like quite enough. I’ve mashed APIs together before; for a project last spring, I at one point had Stripe, Twilio, and MailChimp all hooked up at once. So where was the challenge befitting a semester of hardcore computer science?

Erik’s suggestion: focus on the algorithm. What if instead of straight matching—”you listen to this artist on Rdio, here’s that same artist on SoundCloud”—the app used Rdio artists-in-collection as revealed preference inputs to a suggestion algorithm for new, up-and-coming artists to follow on SoundCloud?

Now that was interesting. I could feel myself getting more excited. I’ve never tried to write a real algorithm, though I’ve gotten close in my work with databases. When I interface directly with databases, it’s usually about pulling all the fields I think might be useful, exporting to a spreadsheet, then messing around in Excel til the data starts to make sense. The prospect of writing an algorithm tugged at those same detective instincts, but went beyond. Rather than figuring out how to make sense of the data in one particular configuration, I’d be trying to figure out how to make sense of the data across all users and all cases, and to present the results of that sense-making in a usable form. When I mess with data in Excel, I’m the intended audience; by putting data through an algorithm, it expands the possible audience to—well, anyone.

So, that’s the going idea. That’s what I’ll be working toward. But this is one of my favorite things about coding: glimpsing the end goal let me see all the hurdles standing in the way—stretching out to the horizon—and gave me the energy to start jumping them, one by one.

Obstacle #1: I wasn’t actually sure what Rdio’s API looked like. I’ve used SoundCloud’s API for projects in the past (here’s one example), so I felt pretty confident that I’d be able to get what I needed from that side. But Rdio’s API was a total mystery. And, weirdly, I haven’t seen many people tap it for projects. That could just be a sample error (I only follow so many people on Twitter, so I only hear about so many hackathon projects), or it could be that Rdio just doesn’t have a big presence at hackathons, or it could be a lot of other things. But that relative void made me wary, so I decided to investigate Rdio’s API first, to make sure it had what I needed.

I found Rdio’s developer page just by searching for “rdio api,” and quickly realized that I would need to apply for an API key. I was a bit worried that a human would need to review my application, so I resigned myself to a couple-day wait. But fortunately, the process was automated; my application was approved instantly. I browsed the documentation just enough to reassure myself that the API was, indeed, quite extensive. And then it was time to rush off to lunch.

When I came back from lunch, I hit obstacle #2: finding the right Ruby gem.

The hazard—and joy—of programming in the GitHub era is that for any given API, there might be lots of ways to access it in your language of choice. Companies will often release an official “wrapper” for their API that makes it nicer to interact with their data through Python, or Java, or—my favorite—Ruby. But that wrapper (called a “gem” in the context of Ruby) may or may not be the nicest one: some kind soul out there in the world might have taken it upon themselves to make an even better one. There’s really no way to know until you start looking. And, unfortunately, the company’s documentation will not always give you the answer you seek.

In the case of Rdio’s API, I started out on the straight and narrow. Well, I thought it was the straight and narrow. I typed `gem install rdio` at the command line, kind of expecting that to be the canonical one. Simplest name, most canonical; makes sense. Sadly, as I soon discovered, the gem hadn’t been updated in a while…and didn’t behave exactly as I expected. It might actually be fine, but I veered away before answering that definitively, because a closer look at Rdio’s documentation told me that what I really wanted was Rdio-Simple, a family of wrappers developed by Rdio itself and hosted on GitHub.

Except…did I really want it? The syntax seemed kind of horrible—not Ruby-like at all—and I was having trouble getting it to do what I wanted. Again: maybe it’s fine. I didn’t push it far enough to know for sure. What I do know is that I got frustrated and went on a last-ditch quest to find something better. To do that, I went straight to the source: GitHub.

GitHub explains itself as a place for “social coding,” and it meets that definition, certainly. But it can also act like magical toolbox: every time you go there, the available tools have gotten better and shinier in your sleep. I say “act like” because in reality, it’s not magic at all: it’s a result of the efforts of hundreds of software developers, working out in the open, giving their creations back to the community. What makes GitHub so great is that those creations are made instantly usable and instantly discoverable—so instantly that as soon as you find the tool that does what you need, you can’t imagine how you ever lived without it.

So, I went to GitHub and typed into the search box: “rdio”. Rdio’s official rdio-simple repository did show up first. But a few lines down, something caught my eye: a different gem by AnilV, titled “rdio_api”. I went to the gem’s page, skimmed the README, and noted that its author cited the Twitter gem as inspiration. Erik’s one of the Twitter gem’s primary maintainers, and so I’ve seen first-hand all of the care that’s gone in to designing it well. This seemed like a good sign. I installed the gem and revised the few shreds of code I’d written up to that point, trying to use the gem the way I thought it should work. I ran the program and…it didn’t break! The gem worked the way I wanted it to! I didn’t have to bend to its will, or bend it to mine; it already fit my will like a glove.

That’s one of the nice things about open-source: sometimes it’s not about what version is better or worse, but about which one matches your built intuition. The rdio_api gem matched mine, and so I ran with it.

I figured out how to get artist names from Rdio; then figured out how to input those names as search terms to SoundCloud; then figured out that if I ranked the results from SoundCloud by number of followers, I got a reasonable approximation of the “most legit” account matching any given artist’s name. I started printing those results to the command line, but then realized that scrolling up and down through Terminal would be a pain; printing the results to a CSV (which I could then open in Excel) would be way more usable. So I got that working, and then watched with glee as my spreadsheet filled up with permalinks to artists’ pages. I hit a few snags—I periodically got 503 error codes from SoundCloud, and discovered that SoundCloud couldn’t seem to handle colons as search input. (My iTunes library was voluminous enough that it included a couple of artists with this issue, including the mysteriously-named P:ano.) But overall: it worked. It worked! The basic idea worked.

With the data in a handful of spreadsheets, I started exploring—clicking permalinks that seemed promising and, on a meta level, trying to develop some intuition for what datapoints I was privileging when deeming permalinks as “promising,” so that I could build that into a future algorithm. I ended up following about 45 new accounts (you can see all of them here), very few of which I would discovered without this exercise. A few highlights:

Olafur Arnalds makes serene, dreamlike music. At least one of the tracks appears to be a true improvisation—not just a polished, finished track. I always like it better when artists show their work.
The way I was sorting showed me that Vagrant Records is actually home to several artists I love, including Edward Sharpe and The Magnetic Zeros and School of Seven Bells. Since Vagrant lists those artists in its profile, SoundCloud search picked up on the connection and returned Vagrant’s account as a result. And now I’m following them, which means I’ll get to trust their taste further.
It seems improbable that this Owen Pallet account is legit, but I loved hearing the demo version of “Tryst with Mephistopheles”—a song I listened to every morning, for a span of months, when I lived in San Francisco.
Lykke Li!

Now that I’ve cleared many of the hurdles, I can’t wait to start building out the app itself—tweaking the algorithm, generalizing the code to work for more users than just me (probably by enabling authentication), figuring out how to present it all. But underneath that anticipation, there’s also ecstatic satisfaction. There’s nothing quite like bringing an idea to life in an afternoon, and I never get that feeling more reliably and more acutely than when I’m working with code.

And I’d say that the prediction/wish I made last week is holding truer than I imagined: “I don’t think I knew how good I had it with Ruby…but I also never knew what it was capable of (or what I was capable of). So that’s the bet I’m making: two months of alternately infuriating and satisfying hand-to-hand combat with C followed by a lifetime of harmonious cooperation with Ruby and whatever comes next.” Ruby is awesome. It’s so good to have it back. I’ll never take it for granted again.

What else? So many things!

While debugging with Erik today, we took a detour into talking about SOLID principles of object-oriented design—specifically, the Liskov Substitution Principle, which states that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” I actually had a bug that related to that principle, so it proved a good learning moment. In the process, I learned about Barbara Liskov—a computer science pioneer, now at MIT. New goal: meet Barbara Liskov before I leave Boston/Cambridge!

Exploring SoundCloud, I ran across this Four Tet remix of Ultraísta’s “Smalltalk,” (warning: it’s great), which reminded me of this Twitter exchange with Patrick and Buzz, wherein Buzz noted that “Objective-C actually shares one of the same ancestor[s] as Ruby (Smalltalk),” and Patrick recommended Squeak as a way to play with Smalltalk today. Still need to dig in to all the links they suggested, but that thread is one of the many that feels more woven into my life lately.

I’m still making progress through Seymour Papert’s Mindstorms, which I picked up from the library after taking heed of Bret Victor’s strong recommendation in his post on “Learnable Programming.” The book is sort of about LOGO (the programming language with the turtle), but mostly about learning. A few passages I’ve loved recently:

Of all ideas I have introduced to children, recursion stands out as the one idea that is particularly able to evoke an excited response. I think this is partly because the idea of going on forever touches on every child’s fantasies…

…what is important when we give children a theorem to use is not that they should memorize it. What matters most is that by growing up with a few very powerful theorems one comes to appreciate how certain ideas can be used as tools to think with over a lifetime. One learns to enjoy and to respect the power of powerful ideas. One learns that the most powerful idea of all is the idea of powerful ideas.

An important component in the history of knowledge is the development of techniques that increase the potency of “words and diagrams.” What is true historically is also true for the individual: An important part of becoming a good learner is learning how to push out the frontier of what we can express with words.

And, finally, there was this: an artifact of today’s remote pair programming date with Erik, the moment where I excavated all the way to the bottom of an object’s ancestry.