Live Coding Competition

  • See how quick and easy it is to build a complete Ruby on Rails application.
  • See how Rails compares with other leading frameworks written in other languages.
  • See how skilled programmers use rapid web application development frameworks.

Participants

We've contacted GemStone, and the Portland Ruby Brigade, Portland Pythoneers, Portland Django, Portland Drupal and PDXPHP user groups to recruit participants:

  • Ruby on Rails: Sam Livingston-Gray and Brian Artiaco
  • GemStone/S Smalltalk Seaside: James Foster
  • Drupal: Jakob Perry and Joshua Brauer
  • PHP Symfony: Chris Alan

Summary

At this live coding competition you'll see programmers build complete web applications from scratch while you watch. Teams using Ruby on Rails, and hopefully Python's Django, PHP's Symfony & Drupal, and Smalltalk's Seaside will work in parallel, with their every keystroke displayed on projection screens for you to watch.

Competing teams will have 20 minutes to create an online cookbook application. Some of the requirements will be provided in advance, but others will only be announced when the competition starts. To be competitive, the teams will need to use their frameworks' unique and powerful features. After time has elapsed, the applications built by the competitors will be reviewed and judged by the audience based on their completeness and clarity.

Spirit

We want every team to have a chance to shine in this competition. Despite the competitive nature, we will keep this event fun, fair, and friendly.

Each framework should be represented by 1 or 2 person teams. The programmers are expected to create their applications from scratch using the same kinds of resources available to typical users of their framework.

It may not be possible to implement all the features requested within the time limit. That's okay. Participants should try to implement as much of the application's functionality as possible.

Dependencies

Participants are welcome to use code from publicly-available, general-purpose reference manuals and libraries, but will not be allowed to use any code they prepared specifically for this competition.

Participants must bring along a computer to the competition that they'll use to write their application on. Each team may use only one computer total throughout the competition. The computer must be able to connect to a projector so that the audience can watch them work. Projectors will be provided, but participants are welcome to bring their own.

Participants must setup their computer with all system prerequisites before the competition starts, such as the language (e.g., Ruby), libraries (e.g., Rails), and persistence store (e.g., PostgreSQL). Network connectivity cannot be guaranteed, so download all necessary libraries/plugins/modules in advance (e.g., Drupal's CCK module, Rails' acts_as_chunky_bacon plugin, etc).

Once the clock starts in the competition, participants will be expected to create a new application instance or image, configure it and its persistence store, load in any application-specific libraries, and begin to write their application.

Requirements

The competition will involve building a simple cookbook web-based application. Some of the requirements will be provided in advance, but others will only be announced when the competition starts. You do not have to implement all these features, but the audience will be asked to choose the winner based on the completeness and clarity of your code.

You can see and use a sample reference implementation of a Ruby on Rails application built to these requirements at http://sample.pdxfoscon.org/

The cookbook web application should provide the following features:

Models

  • In general
    • All model instances should be persisted (e.g., SQL database, transparent object serialization, etc)
    • All operations manipulating the persistence store should be done safely (e.g., use SQL parameter binding to avoid injection attacks)
  • Recipe model (representing a recipe), all attributes are required
    • “title”, short string (e.g., Tiramisu)
    • “instructions”, long string
    • “servings”, integer, must be 1 or greater
    • “course”, association to a single course
  • Course model (representing a type of recipe), all attributes are required
    • “title”, short string that must be unique (e.g., “Dessert”)
    • “recipes”, association to all recipes matching this course
    • Courses do not need to be editable from the UI and should simply be pre-populated to contain “Appetizer”, “Main”, and “Dessert” as initial values.

Controllers & Views

  • In general
    • All pages should use a common layout
    • Forms used to edit and create should share common code
    • Create/update methods must validate that records are complete
  • Recipes controller and views
    • /recipes
      • List of recipes
      • Search for recipes by title (form with text input field)
      • Search for recipes by course (form with dropdown selector)
      • Links to features that:
        • Create a recipe
        • Show a recipe, parse the “instructions” field using a lightweight markup language like Textile which generates HTML from a simplified markup.
        • Edit a recipe
        • Delete a recipe, with an “are you sure” type JavaScript confirmation
    • /recipes/ID - show a particular recipe
    • /recipes/titles/SUBSTRING or /recipes?titles=SUBSTRING - list all recipes whose title contains a case-insensitive substring in their title specified by the SUBSTRING, e.g., “iram” should match “Tiramisu”.
    • /recipes/course/ID or /recipes?course=ID - list all recipes whose course matches the complete string specified by the ID, e.g., “Dessert”.