4/06/2009

Workshop 2 -Part1

To Do:

1. Set up a focus group (like a study group for peer learning) to work on the Ruby on Rails workshops via Interact tools as a class.

Join the focus group at http://railsfocusgroup.blogspot.com/


2. What is meant by “convention over configuration” and how does it reduce coding?

The below Information from Beginning Rails(2007) at http://books.google.com.hk/books?id=0rD_q96srHoC&pg=PA356&dq=%22convention+over+configuration%22+and+%22coding%22&lr=#PPA7,M1.

Convention over configuration means that the programmer needs to define only configuration that is unconventional. Programming is all about making decisions. If you were to write a system from scratch, without the aid of Rails, you would have a lot of decisions to make: how to organize your files, what naming conventions to adopt, and how to handle database access are only a few. If you decided to use a database abstraction layer, you would need to sit down and write it, or at least find an open source implementation that suits your needs. You would need to do all this before you even got down to the business of modeling your domain. Rails lets you get started right away, by encompassing a set of intelligent decisions about how your program should work, alleviating the amount of low-level decision making you need to do up front. As a result, you can focus on the problems you're tying to solve and get the job done quicker.

Rails ships with almost on configuration files. If you're used to other framework, this fact might surprise you. If you’ve never used a framework before, you should be surprised. In some causes, configuring a framework is nearly half the work. Instead of configuration, Rails relies on common structures and naming conventions, all of which employ the often-cited principle of least surprise (POLS). Things behave in a predictable, easy-to-decipher way. There are intelligent defaults for nearly every aspect of the framework, relieving you, the developer, from having to explicitly tell the framework how to behave. This isn’t to say that you can’t tell Rails how to behave. In fact, most behaviors can be customized to your liking and to suit your particular needs. While you can manipulate most things in the Rails setup and environment, the more you accept the defaults, the faster you can develop applications and predict how they will work. The speed with which you can develop without having to do any explicit configuration is one of the key reasons why Rails works so well.

3. Further work on understanding MVC:
a. See the wiki at

http://wiki.rubyonrails.org/rails/pages/UnderstandingMVC - Done!
b. Do the MVC tutorial at http://wiki.squeak.org/squeak/1767 - Done! (Try to access the web page at http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html, however, this website has been obsoluted.)

4. Got a spare hour or so? I recommend the UC Berkeley RAD lab’s Ruby on Rails Short course at
http://youtube.com/watch?v=LADHwoN2LMM - Done!


5. Read the Flash article using ActionScript by Colin Moock titled “The Model-View-Controller Design Pattern “at
http://www.adobe.com/devnet/flash/articles/mv_controller.html - Done!

沒有留言:

發佈留言