Since my fiancee, Jess, and I are getting hitched in a few months, we've obviously been in the midst of wedding planning (prior to starting work on this game). When discussing our options for music, we thought that the money we could spend on hiring a DJ could be better spent elsewhere. Initially we were just going to put together a google music playlist and let it run on shuffle, but then I thought it would be fun to let guests have a say in the playlist, so I decided that I could probably build a jukebox web app pretty easily.
The jukebox application is pretty straight forward. It's a Laravel project which basically consists of two components. First, a pared-down MPD web client which users can just select a song to add to the queue. The second portion is an artisan command which runs in the background which listens for the state of MPD. Whenever the song changes, the listener checks to see if its that song is the last song in the queue, and if it is, it just queues a random song.
It's open source and you can check it out on GitHub if you'd like (though I haven't touched the readme yet, it's pretty straight forward I'll try to remember to update it with some instructions). The repository is a Homestead project, which I was using for dev, so you can probably get it going locally with a 'vagrant up' though you might need to do some tinkering with MPD in the VM in order for it to actually play.
In "production", I'm running it on a Raspberry Pi LEMP stack.
Step-by-step to follow...
I wanted to set up a little blog for myself so that I had a place to document all the shitty little projects home automation projects that I do, as well as a place to highlight whatever else I find that I think is interesting but would probably bore the shit out of my wife or other people around me, so this is it!
This blog is "serverless" and powered by a series of AWS services, instead of your traditional webserver architecture. Full credit for the architecture on this goes to Matej Šircelj who laid the groundwork for all this. Be sure to check out his github repo: https://github.com/sirceljm/aws-lambda-blog
It's pretty slick in how it works. Essentially, instead of your request being routed to a standard web server, your request gets sent to an API in AWS API Gateway, which parses the request and parameterizes whatever data comes with it, and then it invokes a corresponding Lambda function, which fetches whatever data it needs from DynamoDB and/or S3, renders the templates and returns the response. Static assets are also hosted in an S3 bucket and the routing and caching is handled by CloudFront.
All of this happens on request-- meaning I'm not paying for a server to run just to sit and wait for the 1 visitor who might stop by every other month. Pretty dope, eh?
Here's a bit of a visual breakdown (image credit also goes to the projects original author):
I've forked the repo and made some changes-- notably, adding some data fields for the posts, refactored some of the lambda functions to move some data around, and then cobbled together this stunning front-end.
This was dead-simple to get up and running, and you can find the project's github repo here.