#bitplayer

I accessed the Twitter API today for the first time. Actually, this was the first time that I’d accessed any API, and I think I’m going to like it. Suddenly, it feels like the tiny little programs we’ve been writing have access to so much potential information that they could really become useful.

What was the first thing I did with such awesome power? Built an IRC spambot, of course!

The bot returned tweets ranging from Rob Delaney to Goldman Sachs Elevator Gossip (Twitter classics) to less-known but equally funny finds @JonyFuckingIve and @UrbanEnglish. Simply by sending out an IRC message with the code phrase “bloodsucking vampires,” for example, the program would return the latest Goldman Sachs gossip going back one day each time to keep the results fresh.

Now that I’m not so intimidated by APIs, I plan to spend a few hours this weekend just playing around and seeing what other fun things I can do with them. Of course it makes it way easier if, like Twitter, there’s a Ruby gem available to access it, but I imagine figuring out the basics of JSON APIs wouldn’t be too hard if I had to.

Since I tend to relate all my web development learning to music somehow, I imagine that the Twitter API could be an extremely useful tool to find out about music trends worldwide. Searching for different keywords like the newest subgenres of EDM (currently: trap) and filtering them by locations could expose what is happening in the most music-aware neighborhoods in the world. I could track obscure artists and measure their changing popularity, where their fanbase is, and whether their live events are generating any buzz for them in each city they play. Of course, there’s an endless field of tweet visualizations that I could come up with to surface interesting patterns. Are dubstep fans tweeting later in the day? Are followers of soft indie bands more likely to tweet about sad or emotional topics? Are DJs wilder than rock stars?

Finally, our first dive into real coding, real Ruby. The first game we had to make was simple enough: turn words into Pig Latin by moving the first letter to the end (if it wasn’t a vowel) and add “ay” to the end. The process went by simply enough, giving us that first sense of writing code rather than just filling in blanks and evaluating answers.

When we got to making a Hangman game, the challenges multiplied along with our frustration. My partner Dylan and I started in a very unstructured fashion, making random methods as we needed them and rewriting every line of code we wrote multiple times as later issues developed. We chose to pursue our own solution rather than follow the boilerplate template on the Bitmaker github, but that quickly went awry. We tried to write a method that would evaluate and print the correct Hangman board whenever it was called, but as soon as we finished and tested it, we realized that it redrew the board whenever you typed in a new letter - it forgot the correct answers you entered before!

Our initial hope was that we could neatly avoid saving every result to memory and using a dozen different methods for every minor task by chaining much of the process into one method.  However, this approach didn’t make any room for easily putting in exceptions (e.g. when you’d already guessed a letter), and random errors kept creeping in until we knew that we had to start over.

Starting to feel hopeless and tired, we frantically reworked our whole program, deleting almost everything we wrote and slowly building it up in a new way that depended on saving every result to variables before proceeding. Finally, a full three hours after we started, we got the first hopeful sign: we had properly written a method that filled in the correct letters, and saved the result until the next letter was guessed. The sense of accomplishment grew as old errors were fixed quickly after that, and new issues didn’t stump us for long. We checked that we were running our code as efficiently as possible, making changes to loops that were onerously written and redoing the way we drew our initial empty board to remove a few unnecessary lines. Nearly done! A few edge cases bothered us; for example, the ability to write in multiple letters at once or use numbers or other characters. We added in some extra if blocks to handle those cases, and BOOM! Done!

I stepped in ready with excitement. Like a toddler giddy about the prospect of going to kindergarten, I came off a lifelong string of unfulfilling educational experiences ready for the next phase of life. In the introductory icebreakers, you could tell how strong that sentiment was among the cohort - at least a dozen people cited their pride at leaving behind their staid jobs, the rat race, the old-fashioned expectations of friends and family, and giving it all up to try to make something.

That might be making something of ourselves, or making some actual thing. I heard people say they want to unleash their creativity, they want to enable themselves to take control of their dreams, or at the very least they want to find a job that doesn’t treat them like replaceable number-crunchers. Together those confessions collude to create a beautiful sense of understanding of why we all came here.

Going into the first lecture was tense; it seemed that everyone was scared to know less than everyone else. Our nerves eased, however, as Khurram did a fantastic job of setting the pace appropriately, constantly reaching out for feedback, and turning the abstract advantages of Git version control into simple, concrete lessons.