Rails works by convention. It generates directory structure, and some stub files. This doesn't limit flexibility, because you can over-ride everything. What matters more is convention (where you put the braces, etc), not what the convention is.
Code/setup configuration do via generate command is the pathway into the generation engine in rails. You can create your own generators, to generate Rails apps that have your own custom elements (like authentication, etc). Use "./script/generate" to make a controller. Rely on convention that by default, controllers you create are exposed in URL based on their name (instead of having some nasty XML config file that makes this correlation). Based on how you refer to URL, some actions are assumed (no trailing slash, tries index action, for example).
Conventions:
For views, in order to process an action, Rails attempts to look in the views directory, to see if it can find a view that matches the action. If it finds a match, then it will apply the view to the output.
Rails does have a config file, in YAML format, which gets converted into a ruby hash automatically.
Just like generator, there is a companion command, called destroy. Can remove things that you create by mistake, etc.
Rails has automatic (default) model actions for different database types. If it finds a date/time type in the DB, it will automatically generate HTML to allow inputs for that type. Ordering on page corresponds to order of columns in DB table. Scaffolding is just for getting started, because look and feel will always need to be customized. The model queries the database, handling all of the necessary SQL by default. You can still plugin your own SQL, when it is needed. Models are created before making database table.
Need to key in model objects as to "what you mean" (many-to-one, many-to-many, etc). Use foreign keys in DB to do this. Convention is to call foreign key <table_name>_id, so that Rails can find the other table, and correspond it to the model for that table. Also some code in the model. Goal is to get all logic in the model, instead of in the DB. DB is just for storage.
Rails is targeted at greenfield development -- new applications being built from scratch. For example, Rails doesn't like composite primary keys. It can bend to work with legacy DBs, but if they are super-complicated, it won't work.
Can use console script, to interact with domain model in a CLI-type fashion. Can also be used to debug & administer live systems.
Layout: way of reversing responsibility between layout and template. Layout includes other files, so you can change formatting in one place. Inversion-of-control-like? Convention around file names, if file in layout directory shares same name with view, will automatically be used.
Rails has "filters", applied in a chain. Seems conceptually similar to workflow, hence filters in Remedy ARS. Apply filters in the controller class. Have granularity to specify which actions need to run which filters.
Rails has built in logging. Even better, you can access the logger, to do printf-style debugging. Call logger.info to do this.
By default, Rails stores session info in files in /tmp. Can configure it to store session info in DB or in memcache. That will work better for LB-style environments.
You can use inheritance. For example, if you rename layout file to be at application level, then all views will apply it, since they all inherit from application.
Unit tests are built in. Type "rake unit_tests" to run all of the unit tests. Type "rake recent" to test all of the files that have changed in the last 10 minutes. Unit tests good for testing model. What about controllers? There are functional tests for that. Use assert_response in order to make sure you get the response back from the application that you expect.
Includes AJAX helpers: bits of code you can invoke from Ruby, that will generate JavaScript in output to the browser.
Miscellaneous notes:
Tools: