Rails Philosophy

The Rails philosophy is based upon three principles:

  • Convention over Configuration – Common aspects of a web application are provided (i.e., preconfigured) for you, so use them, rather than fight against them! Ideally, the developer should only have to specify the unconventional aspects of the application.
  • Don’t Repeat Yourself (DRY) – Every piece of information should have a single, unambiguous, authoritative representation within a system. Duplication of code fragments throughout an application can lead to logical contradictions, and in general make the application more difficult to maintain.
  • Agile Development – Software development methodologies based on iterative and incremental development, where requirements and code evolve with minimal planning through self-organizing, cross-functional teams.

Convention over Configuration

A massive number of “conventions” are built into Rails, and the real trick is learning all of them. When you create a Rails application, the full web stack is “pre-wired” and ready to go.

Rails code generators follow specific naming conventions. E.g., if you use the scaffold (MVC) generator to create a Post, you get:

  • – A class called Post will be created for the model, along with a corresponding table in the database that will be called posts
  • – A RESTful controller called posts_controller will be created, and routes will be set up so that specific URLs will be able to perform CRUD operations on the post table in the database.
  • – A posts view will be created, consisting of a set of HTML files that can be used to render the results of the CRUD operations.
  • – Test fixtures, along with unit, functional, integration and performance test suites are automatically generated.

Don’t Repeat Yourself (DRY)

Every piece of information should have a single, unambiguous, authoritative representation within a system. E.g., In Rails, with ActiveRecords, once a model is specified, you don’t need to specify database column names –they’re determined from the model.

  • When applied successfully, a modification to a system element does not change any other logically-unrelated system element, while elements that are logically related all change predictably and uniformly, thereby keeping them in “sync”.
  • This principle makes it easier to use code generators and automatic build systems.
  • Thus, DRY code is typically created by data transformations and code generators, allowing the software developer to avoid copy and paste operations.
  • Following the DRY principle makes it easier to maintain large software systems.

Agile Development

  • Agile development emphasizes working software as the primary measure of progress.
  • Rails was built with agile development in mind:
    • – A working application is available immediately.
    • – In development mode, there are no recompile, deploy, restart cycles.
    • I.e., Rails does not generally require you to stop the server; changes made to the application will be automatically picked up by the server.
    • – Rails has simple tools to generate code quickly.
    • – Testing is built into the Rails framework.
  • Extreme programming is an agile approach that that centers around test-driven development (TDD). Behavior-driven development (BDD), a second generation agile approach, extends TDD by writing test cases in natural language that non-programmers can read. BDD focuses on obtaining a clear understanding of desired software behavior through discuss with stakeholders.
  • RSpec and Cucumber are BDD tools for Ruby that we’ll use.