=  Teaching Rails at a University by Carsten Bormann

cabo@tzi.org

If Ruby is so great, why are universities still teaching Java?

== About me

Teach and do research at universities
Write books
do real work
help create software (screen)

== Situation in Germany

You can't earn credit points for learning a programming language at the university

== How to motivate teaching Rails?

 * To colleagues?
	 * Hard (see above)
 * To myself?
   * I need the students

PHP: Quick and dirty
Java: Clean and slow
Rails: Quick and clean

== Can't really teach Rails. anyway

 * We actually teach web application development
 * Outcome (objectives)
   * Agile development
   * Web-based apps as a specific form of fast app dev
   * Ruby as the leading dynamic language

== Eat your own dogfood

 * The TZI administrative/financial database is a Rails site
 * One afternoon, we knocked off a little course management system in Rails
 * We run internal and external projects using Rails
 * Lots of project ideas only possible with Rails

== One interesting approach

 * Use Ruby/Rails to teach programming to non-programmers
 * http://rubylearn.com
 * http://wonderfullyflawed.com/course/
 * Hackedihack

== Ruby on Rails @ Uni Bremen

 * Master-level course, 6 ETCS
 	 * but open for younger people
 * Agile Web-Entwicklung (AWE)
 * Not just Rails, but the agile dev methods

== Practical course: How do you actually do agile web development without customers?
 * You can't
 * So where do you get customers?
 * Always managed to do it
   * University administration
   * Small companies

== Structure of the AWE course

 * Learn Ruby in a no-credits pre-course
   * A couple of weeks before the Rails course
   * Hard to keep up the motivation, because people are learning Ruby before seeing Rails
 * Lock up the students in a computer room for two weeks
   * Start the day with some "lectures"
   * Let them work in pairs on projects for the rest of the day
   * Encourage communication

=== Organization

 * Assign a customer to each pair
 * Have a hard deadline at the end of the 12 days
	 * Whatever is in the repository is the result of the project
	 * Getting done is a significant focus of the course
 * Morning: Lectures
 * Late afternoon: communication break
 * Rest of the time: project work (incl. customer meetings)

== The communication break

 * Groups are encouraged to do peer-teaching (mutual coaching)
 * 17.00-18.00 each day:
   * I pick a subject
   * groups are randomnly paired
 * Result: 2 to 3 distilled presentations on the subject prepared in a common wiki

== Week 1

 * Get people up and running in two days
 * Give them all to be "feature-complete" in first week
 * At the end of the day, every group has written some kind of webshop

Mon:
Tue: First customer meeting, agile methods
Wed: More about views and controllers, more about AR, Validation, Security
Thu: AJAX, RJS
Fri: More about TDD, lead into a weekend of work

== Week 2

 * Three more days of refinements
 * Focus is on project completion

== Result

6 ETCS = 180 H work

Very intense course

== Who is actually attending the course?

 * Funny:
   * Half is sophomore (1st term)
   * Half is graduate level (7th term or more)
 * Great mix for getting students to learn and teach at the same time

== What they liked

 * Ruby
 * Rails
 * The format (2 intense weeks in one room with many iMacs)
 * The combination/mix of presentations and practice
   * Some discussion about the distribution in time
 * The snowballing/communication breaks

== What they didn't like

 * No time for groceries and laundry
   * Next time, we'll tell them beforehand
 * I brought up TDD only on the fifth day
   * To be fixed
 * I used a (long) screencast in class
   * Don't do that (people need to look at that in their own time)
 * Some of my slides still at the previous level of Rails

== What I liked
 * Incredible level of motivation
   * Coupld with high level of (voluntary) cooperation
 * Students' own experience mixes with my guidance and their ad-hoc research
   * In the end, I probably learned even more than the students
 * Students like AWE

== Rails is moving - fast

 * Much of the material out there is in 1.0-land
   * or somewhere not far beyond
 * Start-with-SQL vs. migration approach
   * Originally you started by designing your db in SQL, now you generate migrations
 * Classic vs. REST
 * Lots of little things that are changing (see DHH's keynote)

 * You want to demonstrate best practices from the start
   * but they change
 * It's difficult to hit a moving target

== What could be fixed in Rails

 * Fix SQLite support
 * The "docs" (actual comments unprintable)
 * symbols vs. strings (where to use what?)
 * i18n, l10n (at least make the plugins more reliable)
 * Today's students want IDEs, code browsers, refactoring
   * Students has all kinds of configurations, very difficult to get plugins etc. to work
   * Part of the class used RadRails

== So, can you teach Rails at a Uni?

 * yes, you can!
   * But you probably should think fresh
   * Model teaching on actual usage
 * AWE course: Demanding
  * 2 week blackout
  * Have to re-work much of it every year
 * Why isn't it done in more places?
   * Unis are conservative?
   * Ignorance? Haughtiness? (to stay part)


Q: Results? Customers happy?
!: Not all customers were happy, since students are allowed to fake it. One project went into production, but other customers wasn't necessarily unhappy, they had a prototype etc.

Q: Literature?
!: Didn't want to point to a specific book. Nothing used really.

Q: What happened when the pairs got stuck?
!: The students helped each other

Q: Does it have to be so compact/intense?
!: Hard for a computer science student to carve more than two weeks out their schedule

Q: Was deployment included?
!: No, not part of the original assignment