This week, node-spotify turned 50 - 50 stars on github. This feels incredibly great, after all it’s my pet project which started with a lot of hacks thrown together. I dare you browsing old commits of node-spotify. But now people all over the world stumble upon it and apparently think its great. I didn’t do much advertising (one announcement on the NodeJS mailing list, two posts in small NodeJS subreddits).
Initially node-spotify was a complete package consisting of a node module, an application using this module and a (web)frontend for that application. At one point this was actually working - you could start that application on a Raspberry Pi and control spotify via a browser on another device.
Since then I’m only working on the node module - it was just too much to work on all ends. But I think it helped that I started as a user of my own API. And maybe I can finish my app using node-spotify one day!
Version 0.6.0 of node-spotify is done - with lots of internal and external changes. The most noticable changes are the addition of the User class which allows access to other peoples playlists, the addition of some fields for Tracks in a Playlist and the changes in the callback registering methods. Overall I’m really happy with this version as it also includes some simplifications in the C++ code which is always a nice thing.
Also remarkable is the ability to access the constructors of all wrapped Spotify types (and therefore the prototypes). This allows much more customification of node-spotify.
I finally switched to Bootstrap 3 for node-spotify.com. Of course this does not change the contents, but personally I like the flat design of Bootstrap 3 more than the old one.
Less shared pointers
At some point a friend who is a much better C++ programmer than I am gave me an introduction to the new pointer types in C++11. I was very excited to try them out and decided to use them to save the reference to an spotify wrapped type in a node object.
The only reason why a pointer might be necessary here is because that field can be empty/null/non-present. Track does always need a sp_track*. But what if I would encapsulate that optional value in Track rather then NodeTrack? I tried it out but got stuck rather fast: node-spotify keeps crashing. It always happens in some libspotify sp_*_add_ref or sp_*_release function which I use in the ctor/dtor of the Spotify wrapped types.