Just a few weeks ago, I really didn’t know what I was going to do for my Sinatra project. Our Flatiron labs leading up to the project were varied enough…and I knew I needed to come up with an idea that didn’t replicate any single one yet utilized relevant structural elements. Finally, I resorted to thinking about a use case that might appeal to someone I know. I have a friend who organizes weekly chamber music sessions, so I decided to proceed with him in mind as an end user. Music Mates was the result. Music Mates is just the very elemental beginnings of a much more complicated application. In its simplest form, for the purposes of this project, it’s a directory of musicians that register for membership to the Music Mates community. Someone signs up and selects from a list all the instruments they play, which will be listed on their public profile, which can be viewed by other members. A member can also elect to keep their profile private. You can search for other musicians by instrument from an instrument index, or from instruments listed on a musician’s profile page. Then you can contact the other members via an email link.
I don’t know about you, but I have been getting serious choice paralysis trying find the next great binge on Netflix. Everything seems contrived and formulaic. Lately, I’ve gotten into the habit of watching our Flatiron videos on my big HDTV screen. Watching programmers and instructors go through the cycle of Code - Fail - Debug -Fail Differently - Debug - Fail Yet Again - Debug - SUCCESS! has become very compelling watching. I go through the same nail-biting agita, yelling at the screen if I see something the tunnel vision of the coder doesn’t (because we’ve all been that coder), and screaming “YESSSS!” when a particularly gnarly problem has been artfully vanquished. Watching a master programmer think out loud is quite the narrative - and now I find myself thinking out loud while I’m working. It really helps. This is what’s known as “Rubber Duck Coding.” The term comes from the book “The Pragmatic Programmer,” in which there was a story about a programmer who would carry a little rubber duck around and would debug their code by explaining it line by line to the rubber duck. I suppose one could explain one’s code to the family dog or cat, but there’s something about the unflinching nature of that little happy, squeaky waterfowl that inspires us to think more clearly and clear those coding hurdles we face day in and day out. I think I’ll order one from Amazon right now…
This was really quite an adventure! I went through several different project ideas, when it finally occured to me to code a project concerning web content I knew something about…string instruments. I figured that would help me figure out the most important information to scrape from a website. So, I picked a string shop that sells fine violins, violas, cellos, bows, plus instruments made by the Benning family. I have a lot of friends that deal in musical instruments, so I had them in mind as an end user.
Like a dog with a bone, I just can’t let go of a problem, even the smallest one. I’m working on my CLI project, and the scraping was going beautifully until I came across an annoying problem. The “p” elements I’m stripping have nested “strong” tags for a label, followed by the text. On the website, it appears “Instrument: Viola” and it strips to “Instrument: Viola,” I really just want “Viola” as the value to go into my hash and make my own hash keys. No problem - .sub(/^[^:]+:\s*/, "")
, strips all that gunk away, and I’m left with the value to plop into my hash. Except ONE of my “p” element text outputs would ALWAYS print with a space before it, completely immune to my Regex: