Global Jukebox Update

I’ve been doing tons of work on the Global Jukebox recently, adding new features like Journeys and Learnings, and continuing fix up and modularize the codebase, trying to get things tight for a deadline to give a demo. We had an unexpected monkey wrench last week when the Smithsonian Institution reneged on an agreement they had to let us use a bunch of Alan Lomax’s own recordings to which they hold the copyright. They wanted to charge the project hundreds of dollars per song, for around 1000 songs. Doesn’t really seem in keeping with the public spirit of an institution supported by our tax dollars.

As a workaround someone suggested we embed a spotify player, since the songs in question are available for free on spotify. I did some research and it turns out Spotify has an API that allows you to do such a thing, so I made a little proof of concept where their player appears in our app. One downside is the user needs a spotify account the hear the music. If they don’t they’ll be prompted to create and account, which is free, so that’s not too bad. The other downside is that spotify is not aware of our song coding system, so for every song one of the graduate assistants needs to find the song in spotify, get the embed code and enter into our database to associate it with the correct song. Then I need to write some code check if that embed code is there when I load song data and bring up the spotify player with the correct code. I sure hope spotify doesn’t change their API once we get this up and running.

I got the news from Anna that the demo was today and it went very well. Hopefully this will lead to more visibility and funding for the project. Meanwhile I’m at a point where there are alot of loose ends to finish off ASAP and a bunch of new stuff on the horizon.

As I’ve been refactoring the old code and trying to keep things from breaking as I go, I’ve been giving alot of thought to Javascript as a language and the web application as an environment. I started programming in Javascript in the 90’s when it was still in its infancy, and working in JS was a mess to generally be avoided. Well Javascript has grown up alot, and while it still has some pretty deep flaws, I’ve come to feel it’s time to come to get to know it on it’s own terms and stop thinking of it as a broken version of Java. For example, maybe it’s not bad that there aren’t any classes or strong typing, and maybe it’s good that everything is just an object.

I bought a whole bunch of books recently and have read the first few. It turns out I already reinvented a few best-practice JS design patterns on my own, including self-executing functions with closures to model class-like objects with private and public methods. One author compares JS to the so called “classical” languages, and speaks of classically-trained programmers. I had this aha moment in jazz, playing a Gm7 chord without a G voiced anywhere, and realizing that’s something a classically-trained musician wouldn’t do. Unfortunately no one in the group is into programming languages, so I couldn’t really share my epiphany.

In any event it’s time to unlearn. I’m trying to reevaluate JS from a functional programming perspective. I’ve had some exposure to Lisp and Smalltalk and more recently Scala (which ironically compiles to the JVM), so I’m trying to step back and see things from a broader, more fundamental perspective. Which of course is not that easy when you’re trying fix up someone else’s mess so you can build new features on top of it to meet a deadline, but that’s the life of a software engineer. Hopefully I’ll have thought things thru enough to have something to share in a near-future post.

Leave a Reply