Rails Rumble – the Experience

Rails Rumble is a yearly programming challenge.  Each team is given 48 hours to complete and publish a website written in Ruby.  You are permitted solo entry or up to 4 people as a team.  You can do no coding of the project beforehand, but you can draw up and discuss plans as much as you’d like.  You can find out more about Rails Rumble from their site.

I have now competed in the competition twice.  Once in 2014, and once in 2015 recently.  The first time I joined the project vision of another, and this time I lead a team with my own vision.  Each year I connected with and programmed with people I’ve never worked with before.  I believe the competition is great way to establish real developer connections.  This is always a good thing.

2014

In 2014 I paired up with two other developers through Twitter.  We created a slack.com channel for our team and discussed the plan beforehand.  We started with a Rails project and uploaded it to the Github repository we were given.  Initially some of the team had some issues getting some of our systems setup with a working DB.  Minor setback which was shortly overcome.  We broke the project up into various areas of work.  One man was in charge of front end design, another with data retrieval and database seeding with a catalog of Basketball season data, and I was responsible for integrating Youtube content that matched that data; from which my gem yt_util was created.

Thing seemed to be going really well during the development process.  We were tackling issues and getting working code relatively well.  One feeling I had during the experience was  the disconnect of working separately without much communication on any problems the others may have been running into during their development process.  I believe this was purely a communication issue where I was talking with the project lead some, but heard almost nothing from the front end side.  But hey, this was my first time on a team competition like this so, just keep coding away. 🙂

When we started getting near the finish time we had working code on our local machines.  It looked like we’d make it.  We still needed to prove and improve some basic core details, but now we were pushing it up onto Heroku, the production environment.  So we deployed it and triggered the data fetch and seed process.  Aaaand it failed.  We scrambled to get it working, but we could only manage to scrape roughly a dozen records in the retrieval process.  Also our Resque background system wasn’t working.  We had to manually start up the data retrieval and still only received a dozen entries.  We did what we could to make the system work on Heroku regardless.  But in the end we didn’t have enough time to make it functional… so we, I, placed a RickRoll video on the site 🙂

2015

This year I had vision of what I wanted to accomplish.  I put the word out on Twitter that I was looking for a team. I ended up having about 6 people contact me through twitter, and two via email.  I initially accepted 4 people.  But after having an issue adding a 5th on Rails Rumble I read the rules and saw it was limited to up to 4 people (including myself).  This was very disheartening.  I was happy to have a team of people I was really looking forward to working with and now I had to let one of them go.  Since I enjoyed getting to know new developers last year I decided to let go the member who’d joined me from last years Rails Rumble.  This way we could both experience the competition with new developers, and it’s not burning any bridges this way.

We had a week together in a slack channel to discuss the vision of the project.  Plenty of questions were asked and that really helped solidify what was to be done and what should be addressed.  We used the Github issue tracker for every feature.  Each person could open as many issues as need be and when they started that part of the project they’d self assign the task.

With having experienced the competition once before and knowing what was ahead I decided to deploy to Heroku often, and try out Docker to verify production worked locally and avoid any team system setup difficulties.  I got to know Docker a bit during the week and wasn’t successful with Docker itself, but I did find it easy to work with docker-compose .  During the start of the competition we had trouble with Docker.  But fortunately we didn’t end up needing it.  One brilliant decision Heroku made is to overwrite the database configuration themselves each upload.  And it just works!  So we used sqlite3 for local development and trusted Heroku.  It was so painless it was wonderful!  Although looking at the docs Heroku recommends using one DB for both development and production.

Heroku recommends running the same database locally during development as in production. There are several pre-packaged installers for installing PostgreSQL in your local environment. Once Postgres is installed and you can connect, you’ll need to export the DATABASE_URL environment variable for your app to connect to it when running locally. E.g.:

$ export DATABASE_URL=postgres:///$(whoami)

This tells Postgres to connect locally to the database matching your user account name (which is set up as part of installation).

One of the first things I did after setting up the minimal Rails project on Github was to add Travis Continuous Integration testing to the project.  Having an experience where everyones uploads get tested against our collection of tests to verify nothing is broken is a great tool for having peace of mind.  Especially during an intense timeline of development.  Because the git repos are private for the competition I needed an upgraded account with Travis CI, so I started my free trial with them and was easily able to set it up.  And it started out great!  Everything was tested each time we pushed code to Github.  I was a happy camper. … 4 hours in, Travis CI stopped all testing.  It took me a while to notice as everything showed as all green.  But once I noticed fear struck me.  And Travis CI worked no more.

I'm very grumpy right now that Travis CI has failed me for the past 7 hours during Rails Rumble! Grrrrr!

— Daniel P. Clark (@6ftdan) November 7, 2015

I feel like a plane without light for the landing strip, or a train in motion off the rails. Oh Travis CI… why have you forsaken me?

— Daniel P. Clark (@6ftdan) November 7, 2015

Yes folks we are experiencing some turbulence, please remain seated with your seat belts fastened… this is going to be a rough landing.  Now Travis CI is an awesome tool, and its integration with Github is amazing.  What reason they stopped working for this project remains a mystery to me.  I honestly love Travis CI and I wish them well and may everyone have a perfect experience with them.  To be fair my open source projects have had no issue integrating with them up to this point.  I can’t speculate at what went wrong, that’s not fair to them.  Yes, even after this crucial time and experience I can’t help but love the tool that is Travis CI.  And I do recommend them.

With hindsight I knew that we wanted to focus on MVP (minimal viable product).  I chose to work on an example resource to mock up parts as to not conflict with others contributions.  Who can better demonstrate the projects vision than the one who has it?  The team I worked with were all well experienced in Rails.  I can tell from their depth of comprehension and the work I’ve seen.  So it’s a real joy to develop alongside them.  So the most important thing to guarantee before the competition end was prioritizing the User’s own Podcast feed experience.  I designed my code to work without the need for user accounts.

One college introduced us to the gem Feedjira which is a beautiful RSS fetcher and parser.  This saved us some time as another one of our developers had difficulty with Ruby’s inbuilt RSS library.  From there it was relatively simply to parse the information we wanted.  One issue left to deal with is that we had different Duck Types for each kind of RSS feed.  So we needed to meld out results to one uniform output.

Incorporating a jQuery audio player known as jPlayer wasn’t as quick and easy as I thought it was going to be.  Each component of the player is an individual HTML object that gets styled.  I spent hours fighting with the style sheet not getting why I couldn’t match the design when I had the same styles and code from the demo.  After pointing this out to a team mate he told me to try swapping the order of style sheets imported.  I did that and then everything worked perfectly.  This is why it’s important to share struggles with team mates as soon as it becomes a head ache.  Team work should involve working together.

The Github issue tracker was a very helpful way to determine our timeliness within the competitions allotted time.  When it came down to the wire there were enough issues still open that it was just a crunch to get the minimal feature working.  All this and not everyone was available at most times during the competition.  I forced myself to cut my sleep short to get the last 2.5 hours of development in… and it was a bit painful to operate with shortened sleep.  We ended up using the example resource as the most complete part for the project to operate on.  But the great news is we have working code launched to production!  Yay!  You can try the project out at http://trendercast.r15.railsrumble.com/

There is still much to be done.  After the Rails Rumble voting is done we plan on continuing the project and finishing what we set out to do.

Summary

There really is way more to talk about than I can cover in one blog post.  But let me finish off with some thoughts on what I believe an ideal team scenario is.

* Ideally everyone on the team can see a window of any code that’s currently being edited.  It would reinforce an understanding of progress and help with pair programming by expert advisement.  Without seeing the code being worked on by others I would have to check out the Github branches and read over the code to see what was going on.

* Submit changes to the repo in small parts and frequently.  It’s too easy to get a big code change that’s suddenly unable to merge because of conflicting changes.

* Communicating the vision for the project and getting as many questions answered beforehand is key.  Sometimes you will have to answer in a universal language to properly convey your thoughts.  One of my team mates didn’t have the best knowledge of the English language.  When I first mentioned we needed to parse incoming XML into usable data from a Hash I was told “OK”.  Then after an hour he had submitted code of a Rails view rendering XML output.  And he did it well.  He grasped the terminology and brought his contextual understanding to implement what he thought I was asking for.  So I changed the Github issue to have an actual code snippet of XML in to Hash object out.  And then he got it and we now have the wonderful Feejira gem.  There are several things that are universal languages: music, math, and code.  If you can communicate with these you can transcend language barriers.

* Personally I’d like to work in teams with 3 who alternate in live pair programming of two people where we both can see and edit the code.  Having 4 people can become a bit more difficult as you have to break out of any groove you’re in to answer any questions on implementation.  The smaller the team the less you have to break focus.

For the most part I love the process we went through this year with Slack and Github.  I’m very happy about how Heroku handles database configuration.  And I’m happy we didn’t have any server addons this year as the more complexity you add the more likely your project can’t make the deadline.  I enjoyed getting to discover and work with people I’ve never developed with before in both years of competing.  This diversity has not burned me, but only rewarded me.  Yes I’m sure it would be nice to have a programming buddy who I pair with regularly on on projects, but I don’t have that yet.  Either way it’s a beneficial experience and I’m honored to have worked with the people on both of my teams both years.

I highly encourage everyone to get into programming competitions.  Connect with others and gain from the experience.  I especially encourage newbies to pair up with a more experience developer to have a mentor during a project or competition.  Developers should connect, share code, and glean knowledge and experience off of each other.

If you have any questions feel free to ask!  Please feel free to comment, share, subscribe to my RSS Feed, and follow me on twitter @6ftdan!

God Bless!
-Daniel P. Clark

P.S. In case you haven’t heard you can practice excellent coding challenges at CodeWars.com . I’m an avid fan!

P.P.S. I have tried out Rails Presenters for the first time in this last project and love them!

Image by Gerard Stolk via the Creative Commons Attribution-NonCommercial 2.0 Generic License