I wrote a node.js server that listens on port 3000 (with an index page to be served by a regular server) that can do rudimentary control of rhythmbox.

Dependencies:

• Rhythmbox
• Node.js
• Express

TLDR: Download Playr from github.

The Premise

I wanted to be able to control my Rhythmbox from my phone, but didn’t want to build a special app to do so. So I set about building something in php to control it. I thought I would be able to use the `rhythmbox-client` command line tool I use with Compiz’s ‘Commands’ to map things to my keyboard and mouse buttons.

Boy  was I wrong.

Linux and it’s Multiple-User architecture suck

So first I tried to use the command-line and php’s `exec` to call things. Then I realized that php tried to start an X session to try to start up rhythmbox because it couldn’t detect one. OK. Fine. Maybe I can try to use dbus to communicate with it? No dice. Linux mandates that users cannot see each others programs. Or at least I’ve failed at finding out how. I tried changing the uid,gid,eid through various languages, still to no avail.

Then I had a conversation with @xanderal and came up with the idea of a server running in user space listening for commands. Magical! I’ve been looking to try my hand at some node.js, so I figured this would be a great opportunity to try it out.

I found a great web server framework that would do handily (expressjs) for dealing with uri’s sent by ajax, and got it working in quick order.

Gotchas

Because the port had to be different, I had to use jsonp to fetch data from the node.js server. What I couldn’t figure out is why sometimes the clicks sent out requests, and sometimes they didn’t. Browser caching is to blame. After setting $.ajax’s `cache` to false, it fired every time.

Todos

I’d like to have autocompleted searching for songs and being able to play them.

Also I’d like to add in some volume controls too.

If there is any way possible to get this server to run in user space on startup (or more likely login) please let me know. That would be awesome.

UPDATE: The original version of this post contained a story whining about a current co-founder of mine. I realized after posting it that I just wanted to get it off my chest. I have updated this post to reflect a much more subdued attitude, but a nonetheless just as important message.

Some people can be unreliable. Sometimes things they say make you wonder how much effort is actually being put into the project you have worked for the last year trying to get ready.

This is why I implore all you co-founders to pull your own weight. Or at least don’t overpromise and underdeliver. If you don’t think something can be done, say it up front. Ask for help. Let your other founders know that you’re having a hard time accomplishing your duties.  We as your fellow founders are relying on you doing what you said you would do. Not only are other people’s livelihoods depending on it, but the users who would benefit from your project are too.

There are signs that things like this can happen. No one is going to make all the right decisions and always be able to deliver. But batting zero is not going to get anything accomplished. Maybe you need to stand back and reevaluate your relationship with that person or your approach to your startup.

Hopefully we can pull through and make this work. This isn’t a cautionary tale quite yet, but it’s looking like it will be another story of why a startup failed.

At my startup, we have a moderately sane deployment environment. Check-ins are automatically pushed to a staging server (And i’m notified via notifo with this script). When we want to push code to our live server, we manually move things.

For a while that meant we had to run a

svn export

command by hand once a day or so. (we are under heavy development still)

Eventually we needed a couple more things done when we moved code to the live server (among them run google’s closure compiler to reduce our js footprint). So I wrote a script to handle these things. Apparently while testing, I got distracted and never finished it, because when i ran it, the code was this:

# ... snipped ...
#
# code to assure you're running as root
#

if [ -z $2 ]
    then
        loc= '/path/to/code'
    else
        $loc = $2
fi

# nuke old files
rm -rf $loc/*

# ... snipped ... 

Now, to the astute, you will notice there is a bug here. Can you find it? It’s in the assignment of

$loc = $2

It SHOULD be similar to the loc assignment above it.

loc=$2

Well. This throws an error, but happily keeps moving on down the script. Next question: what happens here when $loc is an empty string ”? That’s right. I just ran rm -rf /*as sudo on our main server.

I realized quickly what had happened. Errors whizz by about permissions, and finally I Ctrl+c’d it out of existence. Everything still in memory was intact. Our application was still running, I was still ssh’d in. So I took stock of my life, and tried to calm down. I had no idea what to do at this point; thoughts ranged from spending the next 12 hours slowly rebuilding everything (I had the latest copy of our code and db on my local computer, so our code was safe) to never returning my CEO’s emails again and abandoning our company. I initially did some fruitless googling for ‘restore rm -rf *’ even though I knew – short of serious hard drive-level manipulation – I was NOT getting anything back.

Then I remembered that we are using Jungle Disk to do daily and weekly backup. I figured out that Media Temple (our awesome host) allows us to reinstall our OS if something like… this happens. So first I checked that we had a recent backup. We did. So i went into our dasboard, and clicked on the button to ‘Revert to Default’ (MT’s oh-shit button). And waited. After that was done, the first thing I reinstalled was Jungle Disk and set it up to recognize itself. Then I simply ran Jungle Disk’s restore program, and voilà! I installed a few more programs that we needed, and we were 100% back up and running in about 3 hours.

We back up our /etc, /var, and /home folders daily and our entire file system weekly, so not too much data was lost. As it turns out, this doesn’t include our Postfix maildir, so we lost about a week’s worth of email (personally, I use gmail and it downloads all the email, so I didn’t lose anything). We have since fixed this to save email daily.

This story is another among many to remind you to back your shit up. Fortunately we ended up ok; thanks in no small part to Jungle Disk.

If you have any questions about our staging=>live process (which is now Idiot Proof©), or our backup strategy, drop me a line at hello at andrebluehs dot net.