Ruby Rampage

Ruby Rampage is a 48h Ruby-based online hackathon, previously known as “Rails Rumble”. And it just happened last weekend. For me, this was fourth time to participate in it and for the first time and want to share some thoughts about it right away.

About the hackathon itself

Ruby Rampage, just like its predecessor, does not have any theme or topic. It has just one technical constraint: all entries have to be a Rack-based web application that can de deployed to Heroku instance. It is also online, which means that contestants are expected to show some kind of uprightness and not code before it starts or have more members on the team that it’s allowed. It is generally a fun event, not a serious business.

That being said, I noticed few flaws on that idea:

Different strokes for different timezone folks

Only this year it struck me that it is not exactly the same for people in different time zones. For Poland, it starts at 2AM on Saturday, which is basically to late to start coding. You have to wake up early on Saturday morning, then you have whole day of coding, some sleep, and a very long Sunday, which finishes at around 3AM. And next day you are going to work.

It is quite different for people who start e.g. Friday at 6PM. They can bootstrap their project, overcome some initial problems, have some rest. Then they have one full day of coding, time to get some sleep and then half a day to finish. They can even hit a bar afterwards!

Of course, there is probably no way to mitigate this, but maybe because I could monitor people activity on Slack this year, it came as a realization.

Tech stack this year

One thing that wasn’t exactly fair this year was that we could only use free addons on Heroku. This was quite different from last years, when first tiers of paid services were provided for free for contestants and there was no warning in the rules about that. Halfway in the first day we realized that we have PostgreSQL instance in which we can keep only 10K records, compared to 10MM last year. Fortunately, organizers provided us with alternative solutions (using Compose.IO, although it only happened for us on Sunday afternoon).

Is there any Ruby in it?

More and more entries are basically front-end applications which have close to nothing on a backend. While they are technically correct, this does not have much in common with Ruby theme. I have a bit mixed feeling about this, but then again: there’s probably nothing to prevent this.

Our project

As I said before, this was fourth Rumble/Rampage for me. As it happened, we tend to have a cycle in what we build:

• Three years ago we mashed Instagram and Foursquare together to put some food photos on the map. It was simple API-based one-controller application. It is even available here (please, don’t click if you want to asses my code abilities ;) ).
• Next year we built app for thanking people and showing them appreciation for their work. It didn’t go well, was too complicated and we weren’t very satisfied. Neither were people who rated us.
• Last year we used Github API to create some kind of “open source profile” of users. And it was quite a success. It worked (still does) and we missed top10 be a few points.
• So this year it was time for a complex app. We decided on that in quite a last-minute manner and we created application for gamification processes in the company or any kind of other organization. This actually came up on our work Slack as something that would be worth implementing in the company and real-life ideas are the best!

We ended up with an app with 10 models, 15 controllers and 10 service objects, which is quite a lot as for 48-hours-long hackathon in my opinion. QuestFlow was born.

The initial idea was to turn checklist-like sets of task (such as onboarding process) into something fun, where you can both report your progress (as for example new employee) and track the progress (as their supervisor). Therefore instead of todo items we have quests grouped in flows – now you know where does the name come from.

As an addition there are achievements. They are designed as arbitrary reward: for example for giving a talk in a local Ruby users group or coming up with an idea that is vital to business. On top of that there are experience points and levels.

Upsides

• Using Semantic UI was a clear win for me. I became interested in it few weeks ago and it’s not the first project where I used it and I can tell you it’s definitely worth taking a look. Bu using its default theme we were able to achieve quite a decent look without being “yet another bootstrap website”. (Of course, I was equally excited about Bootstrap those few years ago when I first saw it.)
• Not using React and especially Redux. Right in the feelings, huh? Well, while I respect React (I don’t respect Redux though), sticking it in every new project is generally not the best idea. We resisted temptation to spend 12 hours on trying to get working webpack configuration and it was a good decision.
• Creating something, that has prospects to become a usable app. The idea came from wild world, not from some brainstorming session on what can be a winning project in Ruby Rampage. If we polish it, it can actually be used to do some good.
• And we had a lot of extra ideas we did not had time to implement. So the project is far from being a finished and closed one. There is a huge area for improvements and it’s quite exciting.

Downsides

• Looking back, it is a bit too complex for a hackathon. Especially knowing how it’s judged – people have to go through dozens of projects and usually don’t have time to explore every aspect of them. That’s why it can be less appealing than some single page entries that can be evaluated in several seconds.
• We did not have graphic designer. It hurts every year and it seems it is required to have a cool-looking result. Neither of us is good at designing websites, but we did what we could.
• No tests. I’m not gonna lie. We had plans, we made promises, but there were always more pressing things to do. At least this year we had a well-defined golden path for manual testing and had time to check it few times.
• (No Hanami. I really wanted to use it instead of Rails. It would be a perfect fit for our last year project. But with this one there were just too many models and controllers, so using Rails sped us up significantly. Plus Hanami model is undergoing a major rewrite right now and I’d have to learn it pretty much again from scratch. However I already have plans to start rewriting QuestFlow into Hanami. This time with tests.)

What now?

Now we wait for judgement to finish and we also rate other people’s entries. If you want, you can see our entry here. By the way, the name of our team (Beer Driven Development) is very misleading as, unlike previous editions, we did not drink any alcohol during the contest ;)

QuestFlow dashboard built with default Semantic UI theme