Ruby Derailed: Tricks, Idioms, and Experiments in Application Development

A training session by Hal Fulton
Lone Star Ruby Conference 2012

This is strictly non-Rails content (although there will a Sinatra component for those addicted to web development).

The session will consist of introductory material followed by live coding and discussion. The coding will be on a small application called Socrates (at present fewer than 20 classes and fewer than 1,000 lines of code). See individual sections below for more information.

github repo: Available for attendees
Online slides: Available for attendees

Software prerequisites

For everyone:

Linux, OS/X or equivalent
git
Ruby 1.9.2
SQLite
Gems: Bundler, minitest, sqlite3
rvm or rbenv

For those wanting to work on Swing interface:

JVM
JRuby 1.6.7

For those wanting to code a web interface:

Sinatra

Schedule (breaks are assumed)

  Hour 1: 
    - Tips, tricks, edge cases, and advanced techniques
    - People start cloning repo (allow for wifi trouble)
    - Refresher: Best practices, tools, app structure
    - Overview of Socrates
       * Question types and terminology
       * Classes and code structure
       * The text UI
       * "to do today" (and someday)
  Hour 2:
    - Basics of Sequel
    - Basics of Sinatra
    - Basics of Swing
    - Basics of minitest
    - First dev cycle (short)
  Hours 3-6:
    - Four dev cycles
    - Final cycle may be shortened for summary/discussion

Socrates is...

A tool for quizzing on various topics, designed to be effective, flexible, and extensible. It is intended to support multiple users, hierarchies of topics, and multiple question types. Ultimately, a sophisticated algorithm will maximize memory and learning efficiency. Part of its purpose is an experiment in attaching multiple user interfaces to an "engine" or model.

Coding guidelines

Maintain separation of concerns and modularity
Keep model or engine decoupled from interface
Test as much as possible (TDD not required)
Seek a high abstraction of data access
Keep the data store "agnostic" of DB and ORM
Maintain code style and readability

Coding tasks

Implement the "complex multiple choice" question type
Add tests as needed (new or existing code)
Implement a partial web interface via Sinatra
Implement a partial desktop interface via JRuby/Swing
Implement a simple "question editor"
Implement a mini-DSL for adding questions
Other as time and interest permit

"Rules of engagement"

Work alone or pair-program
"Test often, commit often"
Follow rational versioning
We'll mediate patch numbers "ad hoc"
Minimal coding standard (see below)
At least four (4) dev cycles after intro
Part of each dev cycle is class-wide code review
Coding ceases during code review
Update gemspec, release notes as needed
After review, code is merged and tested
Record any comments/observations (including "meta")
Ideally, each person/team runs all tests
Then coding may resume

Coding standard

Two-space indentation (hard spaces, no tabs)
No Windows-style newlines
No lines over 80 characters
Essentially "one statement per line"
Keep statement continuation to a minimum
Avoid multi-statement lines
But multiple assignment is OK
No methods over 20 lines
CamelCaseForConstants and snake_case_elsewhere
Parentheses on method definitions, please
Parentheses on method calls at your taste/discretion
Single-line blocks use {}
Multi-line blocks use do/end
Align righthand comments as needed
In general, avoid hashes faking named parameters