In that vein, we’re working on opening up Grooveshark to make it a bit more extensible.

The first thing we’re doing is making the player status really easy to get to. People want their chat clients to be able to reflect what’s playing in the status when they are listening to the desktop app. We can’t do that through AIR directly, and we’re not going to have time to learn about and write special code for each chat client out there, but now anyone who already knows about that stuff or just really wants to put the time into it can do it.
There is a file that we are storing in documentsDirectory\Grooveshark\currentSong.txt
documentsDirectory is defined by Adobe to be the current users’ documents directory. In windows that’s %HOMEPATH%\Documents\Grooveshark\currentSong.txt

The format of the file is pretty obvious if you open it up, but I’ll spell it out here:
SongName\tAlbumName\tArtistName\tStatus
where \t is a hard tab (note: names are guaranteed not to have tabs in them)
Valid statuses are “playing,” “paused” and “stopped” – we may add others later if it makes sense to do so. Note that if a user clears their queue or quits Grooveshark, the last song to play will still be listed with a status of “stopped”.

Other ways we plan to open up Grooveshark to 3rd party developers includes creating an external interface through javascript for the web client so people can make Firefox or Chromium extensions to control playback, and creating something similar that can allow the desktop app to accept connections from 3rd party apps running on the desktop alongside, so for example someone could write a plugin that registers global keybaord shortcuts for play/pause, back and next. Again, AIR will not allow us to register those shortcuts directly.

A few times on my way home, I’ve noticed somebody driving in a fashion that can only be summed up as ‘crazy.’ From a distance it looks like they start to pull up into somebody’s driveway, then turn onto the sidewalk, then back onto the road, and then back up onto the sidewalk again, until I or some other car gets near, then they zoom off down some side street.

Tonight I saw that again and I was on my scooter, so I decided to follow the car down the side street. It didn’t take them long to realize they were being followed, so they started driving even more crazily, speeding and running stop signs, turning off on even more side streets, but still sometimes pulling up onto the sidewalk and then veering off. I started to get freaked out at how freaked out this person was, and how crazy they were driving, afraid that they would decide to try to run me over or something, so I gave up. I turned around and took off, but not before looking back. And at that moment the car I had been following was pulled onto the sidewalk again, and I finally saw the detail I had been missing before. What I saw was a newspaper flying out the window of the car. My crazy driver was just a person delivering papers.

Can’t exec “–decompress”: No such file or directory

Amazingly, I found no exact matches for this in Google (my google-fu is generally weak, however). It turns out that in order for the module installer to be able to install the modules it needs, there’s a certain module it needs!

yum install perl-Compress-Zlib.x86_64
yum install perl-Archive-Tar.noarch
makes everything happy again.

Nothing earth shattering, but maybe now Google will have an answer if anyone else runs into this.

Example:

$tacos = "Robots: " . 1 + 2 . " for the win!";

I think a normal human would expect $tacos to be equal to “Robots: 3 for the win!”. But the result is actually “2 for the win!”

What gives? Well, the PHP docs say that plus, minus and string concatenation all get equal precedence, with left associativity. So going from left to right, it says:
“Robots: ” . 1 | “Robots: 1″ so far, so good.
“Robots: 1″ + 2 => (int)”Robots: 1″ + 2; | “Robots: 1″ converts to 0, so 0 + 2
2 . ” for the win!” | “2 for the win!” D’oh!

I think it would make a lot more sense for string concatenation to take a lower precedence than any arithmetic.

The correct way to write the above code is:

$tacos = "Robots: " . (1 + 2) . " for the win!";

It looks like there was a mix up and a bunch of our VIP users received the following email:

Andrew Wise
to me

show details 2:10 PM (3 minutes ago)

Hi,

Thanks for purchasing our eBook, please download the eBook from this email.

http://tripletsmommy.com/wp-content/themes/typebased/ebook1.zip

Having not actually purchased an eBook, some of our users thought this was a weird form of spam or phishing, or even that their accounts might have been compromised. It’s nothing as sinister as all that, however, just a flub.

Here’s the official explanation from BWC, sent to one of our users who originally pointed out the issue:

Hey [redacted],

Thanks for letting me know, and sorry for the confusion!

Looks like our business guy (Andrew) who handles all our PayPal and such had a little mixup between Grooveshark and one of his side-projects. I just yelled at him, and everything is sorted out now.

[...]

Let me know if there’s anything else I can do to help out. Oh, and I guess enjoy being a triplets mommy! ;)

Regards,

Ben Westermann-Clark

Although I know I shouldn’t, I love Stouffer’s french bread pizza.
What I don’t love is the 30 minute cooking time in the oven, or how it comes out all soggy and gross after the recommended 5 minutes in the microwave.

The solution? 1 minute in the microwave, 10 in the toaster oven. The result? Crunchy pizza perfection, in just about 1/3rd of he time.

That’s right, if you find a song on Grooveshark that you like, you can add it to your library with the simple click of a button. If you have a song in your library that you wish would just go away, you can also remove it from your library with the simple click of a button.

Screenshots:

You can click this button on any song row to add it to your library (note: icon subject to change)

You can also drag as many songs to your library at once as you’d like.

If you toggle this button (icon subject to change) when it is highlighted, the song will be removed from your library.

Reminder: We will be releasing a preview (in other words, still buggy) version of Grooveshark 2.0 to VIP subscribers on the 24th, this upcoming Monday. Subsequent changes to Grooveshark 2.0 will depend on feedback we get from the VIP community, so we can’t predict when 2.0 will be available to the general public.

First, a history lesson. Our first stab at RPC (codename tambourine) was SOAP. We chose SOAP because it did what we needed (theoretically), it was XML (so super easy for Flash to use), and it’s also super enterprisey, which appeals to certain people here, myself not included. We used NuSOAP because it supports WSDL generation, which is so annoying we did not ever, ever want to have to do that by hand. Using SOAP turned out to be a huge mistake (anyone familiar with SOAP probably could have told us that). Because it’s XML, it was super easy to break the service by returning data with, say, an unsupported character in it, or by having PHP accidentally output a newline character (say, by following the PEAR standard and having an extra newline at the end of every PHP file). Further, because browsers eat most error codes and don’t pass the codes or the accompanying data on to plugins, we had to hack NuSOAP to violate SOAP standards and return a 200 OK when generating SOAP Faults. On top of all that, and most importantly, it turns out that generating all of that XML is very expensive. So expensive that I could not test code locally on my machine before putting it on a server. So expensive that we actually got a huge performance boost by caching the generated XML in memcache.

After the SOAP fiasco, we wanted to try using JSON, because it’s much more terse and far less expensive to generate than XML, while still being human readable, which we value for debugging purposes. We looked at official JSON-RPC stuff, but we were spoiled by SOAP in one regard: support for headers. We got used to using headers to pass around status information that didn’t exactly belong to the method calls, and we didn’t want to give that up so I wrote my own JSON-RPC server (codenamed cowbell) modeled largely after how SOAP worked, but more efficient. My custom JSON server class was only 275 lines long to NuSOAP’s 7,994 lines for just the core file. We gave up the elaborate data type declarations (we just verbally communicated what type everything would be), but beyond that method registration worked the same way as SOAP and every other RPC implementation I’ve seen: you need a service file which registers all available methods with the RPC server, and then invokes the RPC class, passing through the raw POST data. Although I did not save benchmark information, the speed difference between my custom RPC class and NuSOAP was astronomical, so we left the RPC optimizations at that.

I recently came back and did some profiling out of curiosity to see how much overhead our current RPC implementation was creating, and it turned out to be about 15% plus about an extra 1.5MB of memory used. I thought about how things were working with the current implementation and realized that it’s a bit silly to be registering hundreds of methods every time the client makes a request, when you really only need information about whatever method is currently being requested. All the other information is superfluous. So in our new JSON-RPC implementation (codename more because it’s still cowbell in a way), 162 lines long, there is no ‘registration’ of methods. Instead, the service class that would normally do the registration simply has a collection of “meta methods” which return information about the methods that make up the service when called. So the RPC server parses the request, does a little bit of reflection magic to determine which meta method to call, and calls that method to get all the information it needs in order to handle the request. What’s the overhead of this approach? Well, it hardly even registers in the profiling I’ve done. :)

In summary, Grooveshark 2.0 method calls should be nearly 15% faster on average than Grooveshark 1.0 calls. :)

P.S. On the topic of cowbell, there’s an old easter egg that we added and never got around to telling anyone about. Before Grooveshark 2.0 is lost and it’s forgotten forever, you can get to it by typing about:cowbell into the search bar.

As you might have guessed from the punny title of this post, one of those cool things is sorting! When looking at a list of songs, artists, albums, etc., in Grooveshark 2.0, you will be able to sort that data however you like.

Yes, this is another excuse for me to leak a screenshot. ;)

Another feature it enables which won’t make it into the VIP release of the 24th, but will be available to VIP users shortly thereafter, is live search. You’ll be able to narrow down any list of songs you’re looking at by searching within the result set.

As Grooveshark evolves and the application becomes more sophisticated, the PHP layer is more and more becoming just an interface to the DB. The application just needs the data; it knows exactly what to do with it from there. It also only needs to ask for one type of data at a time, whereas a traditional webpage would need to load dozens of different pieces of information at the same time. So for our type of application, magic methods and ORM can really just get in the way when all we really need is to run a query, fill up an array with the results of that query, and return it.

Our old libraries employing ORM, magic methods and collections, were designed to meet the needs of a typical website and don’t necessarily make sense for a full-fledged application. On a webpage, you might only show 20 results at a time, so the overhead of having a bunch of getters and setters automatically fire whenever you load up your data is probably not noticeable. But in an application, you often load far more results than can be displayed, and allow the user to interact with them more richly. When you’re loading 500, or 5000 results as opposed to 20, the overhead of ORM and magic can start to really bog you down. I first noticed the overhead issue when testing new method calls for lite2, when in some cases fetching the data would take over 30 seconds, triggering my locally defined maximum execution time, even when the data was already cached.

Like any responsible developer considering making changes to code for performance reasons, I profiled our collections code using XDebug and KCachegrind, and then I rewrote the code to bypass collections, magic and all that stuff, loading data from the DB (or memcache) into an array and returning it. The difference? In the worst case, bypassing magic was an order of magnitude less work, often times far better than that. My > 30 second example took less than 1 second in the new code.

For Grooveshark 2.0 code, wherever makes sense, we are bypassing magic, ORM and collections and loading data directly. This of course means that Grooveshark is faster, but it also means that we can load more data at once. In most cases we can now afford to load up entire lists of songs without having to paginate the results, which in turn means fewer calls to the backend *and* much less work for the database. Whenever you must LIMIT results, you must also ORDER BY the results so they come back in an order that makes sense. Not having to ORDER results means in many cases we save an expensive filesort which often requires a temporary table in MySQL. Returning the full data set also allows the client to do more with the data, like decide how the results should actually be sorted and displayed to the user. But that’s another post…