My Rails Rumble app this year is meant to be the beginning of a bigger project that I’ve been thinking about for some time.
I didn’t choose this idea because I thought it was a particularly good match for the Rumble, but because I really wanted to get it going.
Creating chord sheets in a word processor really sucks:
- It is difficult to correctly position chords, therefore:
- It is very slow, you can’t place chords in real time.
- You can’t transpose songs easily.
I am attempting to make the process of creating, editing, and using lead sheets much more natural, intuitive, and easy.
mysongnotebook.com is up and running! Well, crawling might be a better term, but the important thing is that it now exists.
Here’s what you can do right now:
- Import existing chord sheets from a format like this
- Reposition chords by dragging them around
- Edit and add lyrics
- Construct new (basic) chords from a chord creation palette
- Add more chords to a song
The application is plain, buggy, and almost unusable unless you know what the bugs are. Most of the issues right now are easy fixes, but are things that I either didn’t have time to address, or that I broke in haste during the last hour of the competition.
I’m eager to fix the existing bugs and want make the app at least minimally usable soon.
I have a lot of new feature ideas that I really like and want to start working, but I don’t want to get into those now.
This year was quite a challenge for me in a number of ways.
Technically, it was filled with some new experiences and difficulties. My project last year was basically all stuff I’d done before or know how to do — it was just a matter of putting the pieces together. This year was much different. I was doing things I’ve never done before and the creation process was a big learning experience for me.
It was my first time using CoffeeScript and Underscore.js, both of which I really enjoyed. I also made a last-minute decision to use Backbone.js — released just two days before the Rumble began — which drove me to write my CoffeeScript in a much more organized fashion than I have in the past.
Almost all my time was spent writing CoffeeScript. I used haml-js for templating JS views.
I feel some disappointment with how far I got. I recognize a lot of places where I could have made better decisions in how I used my time. I spent too much time dealing with implementation roadblocks or details where I should have changed my approach or made it work in a different way.
Another challenge was that I was not in a good work environment. I am living in an apartment in Beirut, Lebanon with some family for a few months and I don’t have an office here. Working from the dinner table in a shared space is not good for productivity. The internet in Lebanon is infamously bad — worse than many third-world countries — and I had some connection problems at various times. I also had to go to a restaurant with internet for the start of the competition because we didn’t have electricity.
Overall I am extremely pleased that I used the Rails Rumble as an excuse to get this thing started!
As we are quickly approaching the 2010 Rails Rumble I thought it appropriate to finally post my (4 minute) timelapse video from the Rumble last year.
At the time I was working in front of a 24" Dell Display with my 15" MacBook Pro to the left. I ran a script that took a screenshot of each monitor and a picture with my iSight each minute.
If you’re doing the Rails Rumble this year, consider recording it. It’s a fun experience to look back on!
For some reason the iSight shot failed a number of times, so the missing frames have been replaced with black.
Thanks for watching!
I was recently asked how I deal with problems that come up between development and production environments, so here’s my answer. This article refers to apps that are currently deployed, not to deploying an app for the first time.
First, one of the best things you can do to make the deployment process easier is to automate it using Capistrano. I’m not going to get into the details of setting it up, but Capistrano takes the busywork out of deployment and other common server tasks. It also allows you to quickly and easily rollback changes when needed.
I’m sure you already have a fully automated, redundant, offsite backup system (you are backing up your database, right?). But especially before deployments, make sure that you have a fresh backup, and a good way to restore if things go wrong.
Be a good web citizen
Update the server at times of lower traffic and put up a maintenance page while the site is down, so anyone on the site during that time knows what’s going on. Depending on the audience and traffic level, you might warn users of the planned downtime beforehand.
Check your dependencies
Make sure that any dependencies within the application — gems, rails, ruby version — are the same. The easiest way to do this is to “freeze” the gems into the application’s vendor directory. Rails checks for frozen dependencies first, and if it doesn’t find them, it will fall back on whatever is installed at the system-level.
Freeze gems with
rake gems:unpack and freeze rails itself with
Check any environment-specific variables — especially paths to executables — that may not be the same on the production server. Anything that could be different should go in the respective
config/environments/(development or production).rb file instead of
config/environment.rb, which is loaded for all environments.
Setup a Staging environment
Rails makes it pretty easy to run different environments. Setting up a staging environment is the best way to be completely sure that you’re not going to break production.
I thought it would be awesome to be able to look back and quickly see the evolution and development of my application for the Rails Rumble, so I wanted to figure out a good way to make a timelapse video of my work during the competition.
I’d love to see some other developers do this too, so if you record your progress and make a video, please let me know, and I’ll post a collection of the videos here after the rumble.
I’ll be taking a screenshot every minute, and supposing I work for 40 of the 48 hours and display each screenshot for 3 frames, the video will be about 4 minutes long. I’ll also be taking a picture of my increasingly tired face with my iSight.
I use a dual-screen setup, which is what caused most of the problems along the way. Here’s how I’m setting things up.
I thought it would be pretty easy to write a little script that would take a screenshot every minute, but it turned out to be a bit harder than I expected to come up with a solution that I was happy with.
As it turns out, the native OSX ‘screencapture’ command is really slow, taking about 3-4 seconds to complete, and worse, it freezes the entire system for the whole time. Not such a good option.
After looking at a bunch of other options, I decided to use an application called InstantShot!, which supports taking timed shots. Instant shot has some good features, but it can only work on one screen at a time. To get around this, just open a new instance of the application (open -na InstantShot!) so you can use one on each screen.
If you set the preferences correctly, you won’t have to change anything except the active screen for one of the instances.
- Set your save path and filename (called prefix).
If you are using 2 screens, you’ll want to save the screen index at the beginning so you can sort them out easily.
Here is my prefix: :S_:M-:D-:Y@:h.:m.:s (paste by right clicking, the keyboard shortcut won’t work)
- Make sure you are capturing in .png format. Do this by selecting “Shoot with timer > To Png file…” and that setting will be used in the future.
- In “Advanced” select “Automatically start multiple shots” and use 10 seconds.
As far as I can tell, the only way to make it stop shooting is to quit.
It’s worth mentioning that your application preferences are saved to disk when you quit an application. If you want to make permanent modifications to preferences, make sure the instance that you quit last is the same one you used to change your settings or your changes will go unsaved. You can, however, change settings during an application’s life-cycle, and they will be in effect as long as you have that instance open.
Timed iSight pictures
The only way I could find to get pictures from the iSight is a command line tool called isightcapture. The original developer’s website is no longer around, but I found a copy of the script that you can download here.
Make sure to put the downloaded script in /usr/bin/.
Here’s the script I’m going to run to get things going. All you have to do is change the active screen in one instance if InstantShot! and leave the script running until you want it to stop taking pictures with your camera. The script will output the time whenever it takes a picture.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
system 'open -na InstantShot!' system 'open -na InstantShot!' puts "--- Change the active screen in one instance of InstantShot." # InstantShot is set to start shooting after 10 seconds sleep 10 loop do # Using a new thread for the picture keeps the timer accurate Thread.new do system 'isightcapture ~/Desktop/Rumble\ Screenshots/iSight/`date +%m-%d-%Y@%H.%M.%S.jpg`' puts Time.now.strftime('%H:%M:%S') end sleep 60 end