Ruby Derailed: Tricks, Idioms, and Experiments in Application Development 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: Coming soon Online slides: Coming soon 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