Official Rules

v0.3.1

Overview

Railschallenge has been designed for the community, by Jeff Lunt and Nick Kellermeyer, as a way for you to test your Rails application development skills, but unfortunately not your dance skills. You will start with a skeleton application and a set of features you need to add to that application. As you develop your solution you commit your code to a public GitHub repository. Your submission is then scored as you go, providing you feedback.

How to Participate

  1. You may compete in railschallenge as an individual, meaning all commits on your submission repository must come form a single person.
  2. Pick any challenge repository on the railschallenge account.
  3. Fork it.
  4. Commit and push code to your fork as you go.

Prizes

Prizes for the challenge are as follows. See exceptions and rules below.

First Prize

  • No-fees for the first $100,000 in Braintree processing*
  • Braintree t-shirt
  • Heroku t-shirt
  • Up to $99 in books of your choice from The Pragmatic Bookshelf**
  • Free license to Sublime Text (or another dev tool of your choice, up to $70 USD in value)***
  • railschallenge sticker

Second Prize

  • Braintree t-shirt
  • Heroku t-shirt
  • Free license to Sublime Text (or another dev tool of your choice, up to $70 USD in value)***
  • railschallenge sticker

Third Prize

  • Braintree t-shirt
  • Heroku t-shirt
  • railschallenge sticker

* Braintree processing limited to US residents only.
** The Pragmatic Bookshelf is not affiliated with railschallenge.
*** Submlime Text is not affiliated with railschallenge.

Timeline

Challenge submission period: April 17-26, 2015 (US Central Standard Time)

The challenge will begin on Friday, April 17, 2015. The challenge will run for 10 days, encompassing two full weekends, allowing participants ample time for research, development, and refinement around busy school, work, or lazy Sunday schedules. The idea here is not for the challenge to be a race, but instead to be a demonstration of your skills and thought process. Quality programming takes time and thought, and we want to reflect that in the challenge itself.

Judging

The judging period will commence at the end of the challenge submission period, and will continue until all submissions have been properly scored. We're not sure how long this will take, depending on the number of submissions, but we expect it to take less than 1 week. We know, that sounds like a long time, and would never fly on an agile team. This is our first attempt at running this challenge, so we ask your patience on this matter.

Winners

Prize winners will be announced after judging has finished.

Challenges

A handful of skeleton applications will be provided. Each skeleton application will contain instructions in its README.md explaining what needs to be done, and how to run the test suite.

Feel free to submit solutions to as many or as few of the challenges as you like within the timeline. Budgeting your time and deciding whether to put all of your attention into a single challenge or spread it across multiple challenges is completely up to you.

Judging & Scoring

The judges collectively, at their sole discretion, will make all final decisions on scoring, disqualifications, and other determinations as they relate to the challenge, as needed. Judges will be anonymous during challenge time.

Scoring is handled in two sections:

  • Automated scoring:
    • Correctness: An automated test suite will be provided with each skeleton application so you can test your submission. You can also use this as the application's specification, to which you must adhere or risk virtual flogging.
    • Efficiency: An automated test suite for speed will be run to check how much load your application can handle.
    • Style: RuboCop will be used to score code submissions for style. The judges may decide to exclude certain RuboCop rules as they deem it necessary. More details on this will be announced at challenge time.
  • Human scoring:
    • Judges will analyze submissions beyond just the static analysis provided by the test suites and RuboCop. They will be looking for especially well designed or efficient code that goes beyond More specifics on the scoring mechanism will be announced soon.

Necessary Skills

To participate in the challenge you'll want to have certain basic skills that most Rails developers require:

  • General knowledge of Rails 4.2 and the basic things that go with it (MVC model, Ruby itself, etc.).
  • Knowledge of DBMS systems in general. The challenges will use SQLite for simplicity.
  • Knowledge of git, or at least GitHub, as solutions must be submitted to GitHub to be considered.

Eligibility & Prizes

Anyone with a GitHub account may participate, but in order to win a prize you must be eligible to receive that prize in your country/state/province of residence. This is determined on a per-prize basis, and is subject to any restrictions set forth by the sponsor providing the prize.

However, even if you are ineligible to receive a prize, you may still "win" a challenge, if you score the best for that challenge.

Disqualification Conditions

If judges determine, at their discretion, that some form of cheating or unethical behavior has taken place on the part of a participant, the judges may elect to disqualify that person. Notification of disqualification will be given. The judges may also elect to reverse a decision, or give warnings where they see fit. It's impossible for us to list all things that may disqualify a person, but here are some general guidelines:

  • Plagiarism: While the judges recognize that GitHub is an open platform, and collaboration is encouraged, it's important not to try to submit a solution that is simply a collection of other person's solutions to the same challenge. That said, much of Rails code is relatively boilerplate in nature, and so the judges also recognize that many parts of a solution will be very similar from one person to the next. If conflicts along these lines arise, the judges will make their best effort to determine the original author.
  • Hacking and malicious action: Any attempt to bring down the services of railschallenge.com or any other service upon which railschallenge (and its challenge participants) depend may be grounds for disqualification. For example, if you somehow prevent another person from submitting code to the challenge in an attempt to prevent them participating fairly. Standard stuff: play fair and don't be a jerk. However, hacking/malicious behavior should not be understood as being limited to just this kind of example.

Supported Platforms

The automated scoring and testing will be run on a popular distribution of Linux (probably Ubuntu). Feel free to develop on whatever system or OS you want, but understand that your code is scored and must pass its test suite in the automated environment.

Questions & Conflict Resolution

If, at any time in the challenge, you would like to appeal the decision of a judge, or ask a question, please do so in the following ways:

  • General questions: Submit your question to the mailing list
  • Feedback from judges: If you heard from a judge via a GitHub issue or comment, reply there instead.