Jicc teaching rails

Editor's Notes

• #2: Hello, sorry for the food analogy just before lunch, but as you’ll see, it’s appropriate. I shall run through the presentation and then do a short demo at the end showing you how to set up a simple Ruby on Rails web site. I’m not trying to show you how to build a Ruby on Rails site, by the way, but rather convince you of its value as tool for teaching web scripting.
• #4: When we started teaching Web Design and Administration at the University of Aberdeen we choose to use PHP. We excluded compiled languages as they are covered elsewhere in the degree. We didn’t have to choose PHP. We could have also looked at Python, or Ruby. However, admittedly at this time neither were really on the radar for web site building. Ideally we should’ve worked out a list of qualities that we desired in the language we were going to use. However, we didn’t have the time for this, and we already knew that we would use PHP.
• #5: PHP was the scripting language familiar to the course team, and the department web servers were already set up to handle PHP. It was an easy choice for us when we started the course.
• #6: PHP is easy to use. You create a variable and manipulate it. You can connect to a database and display the results on the page without any problem. In order to use it well you need to create libraries of code, or at the very least break up the code into small scripts of functions that are reused where appropriate so that you can change the database access details in only one place when you move the database. Students don’t seem to remember this no matter how many times they run through the practical on this in a lab, or read the lecture notes. It probably has something to do with the fact that a number of them have already learned PHP by the time you see them too, which means that they think they know it all, and don’t pay as much attention as they should. The result is that no matter that you start with nice clean files of code, by the time assessments are handed it, the straight coding has been turned like spaghetti from solid straight pieces to a tangle of spaghetti code.
• #7: Ruby on Rails is the antitheses of a PHP application. In a Ruby on Rails application every part of the code has a specific place where it should be. Code that affects the business logic of the application goes into the controller classes. Code dealing with the instance data goes into the model, while code affecting the look and feel of the site belongs in the view files. This structured approach means that the developer should know where the code belongs. In a PHP application you can put the code where you want to, and it can develop into a spaghetti bowl full of tangled code. In a Rails application this will be a structured bowl of cannelloni, all nicely laid out in rows.
• #8: If you learn Ruby on Rails and teach it to your students, then you get a number of benefits. Instead of bored students, who ‘know it all about PHP’, you’ll have interested students wanting to learn a new language and framework. Instead of spaghetti code you get cannelloni code, which makes for better coding habits. Instead of learning how to script variables to build an application, the students have another example, as with Java, of using objects to build applications. Making the switch to using Ruby on Rails instead of PHP, or another scripting language is straightforward as you’ll see.
• #10: The first part of teaching students about Ruby on Rails is that everything happens within the model-view-controller design pattern. The students need to understand how the pattern is implemented in Rails so that they can work with the structure. In our department at Aberdeen University this is usually the students’ first encounter with design patterns. Although the students are also taking the software engineering course at the same time, they don’t start design patterns in that course until the following week. In any case, this overlapping will aid the students in understanding what patterns are and how they are applied in a Rails application.
• #11: Controllers in a Ruby on Rails application intercept the page requests from the browser and then marshal the details for a response. This could mean using a model to query the database, or using a model to validate a user login. Whatever. In any case, once the controller has the result, it then pushes the result to the appropriate view. Usually there is more than one controller for an application. It is common to have one controller for each model, and then others to coordinate the action between the other controllers for a smooth running application.
• #12: Models hold the instance details for the application. They are the objects that are manipulated by the controllers in the application. They represent users, customers, products, books, etc. If a new instance is created then the model determines what needs to be validated before the object is created.
• #13: When a controller has the result of the page requested by the browser, then it hands this to the appropriate view file. This file knows how to present the response to the browser. In a Rails application these are built up from a small collection of templates to speed development, which also make it easy to integrate shared menus so that code is not needlessly repeated.
• #15: Ruby underpins the Rails framework so the students need to learn this too. In addition to learning how Rails implements the model-view-controller pattern, they need to learn basic Ruby language structures so that they can write methods, as well as understand the Rails generated code, and modify it as required.
• #16: In the first practical the students create a basic site with some simple controllers and methods tied to hand crafted views. This is by way of showing them how the Rails structure works and which files are required to handle a page request and a response. We do this with a simple hello and goodbye example using one controller and two views. We put two methods in the controller, one for each view, and then modify the views with some basic scripting. Later we start a larger example that they’ll use over several weeks, which brings models into the exercise so that they see how controllers deal with models.
• #17: Arrays are everything in a Rails application. When a controller queries a model to obtain a list of products, for example, then this is returned as an array. When the same array is displayed on the web page in the view, then this is iterated over by the page. Similarly, if the controller method wanted to find a specific product in the array, then this too means searching through the array. Arrays are easy to do in Ruby, and there are various ways to work with them. Rails also adds its own ways. The students need to learn a few of them so that they can get the most out of their Rails applications. As here, too, we can retrieve arrays of models associated with other objects and iterate through them.
• #18: The students also need to know how to handle exceptions for when things go wrong. They need to tell the application what to do when something is ‘nil’ instead of a value, or when it’s not the expected value. They also need to be able to write helpers, bits of code that can be called by different views, without having to write it as a file include. Helpers apply to contollers and allow you, for example, to call formatting code for prices in different currencies. Filters are also useful as they represent chunks of code that can be called before or after another method. For example, if some methods can only be run by authorised users, then we can have the authorisation method called first before any of these other methods are run. We can also use this for logging if we want run ‘around’ filters that place the method within the filter so that, for example, we could time a method.
• #20: Throughout the practicals the students work with a cruise booking example. This provides cruises on ships, and cabins booked for cruises, which are reserved by customers, who pay with them using one of their credit cards. At one level this is a simple example, while on another there is lots of scope for further work.
• #21: The first practical has the students set up basic models and controllers for the different tables of customers, addresses, credit cards, ships, cruises, reservations and payments. This gets them used to the basic structure that Rails creates and they can see how easy it is to manipulate the basic application.
• #22: The next step is to integrate the object relationship mapping to deal with one-to-one and one-to-many as well as many-to-many relationships. This is one place where the real power of Ruby and Rails shows up, because it is not that difficult to set up. We only need to add some lines of code to the model objects and that’s it. Rails does the rest.
• #23: Beyond the relationships of the objects we can also move on to explore other parts of the application as time and student aptitude allow. We could change some of the methods so that they use AJAX, or we could integrate RSS feeds into the application to show new cruises as they are added. In addition, there is the rest of the workflow for the application because at the moment it only has some parts tied together.
• #24: So, we’re back where we started. Looking for a good structure for teaching web scripting. I’ve tried to show how Ruby on Rails makes this easier.
• #26: As noted earlier PHP has problems with resembling spaghetti instead of cannelloni if good habits aren’t followed. In addition there is the problem that some students think they know it all when it comes to PHP because they’ve been using it for a number of years already. This means that they skip practicals, don’t pay much attention in class, and then don’t improve their habits, and their attitude potentially influences other students in the class too.
• #27: Teaching Ruby on Rails for web scripting has a number of benefits. Its model-view-controller structure forces students to understand the pattern, which they should be able to ‘port’ to other applications, when they encounter it in Java, or whatever. The students learn to work with components instead of only variables, which is what tends to happen with PHP. Ruby like other scripting languages is easy to learn and its brevity make it fun to use.
• #28: The predetermined layout and model-view-controller component structure of a Rails application make it simple to know where parts of code should be placed in an application. Each of the models, controllers and views has an appropriate role to play in the application, and this structure, once the students understand it, makes it simple to know where code belongs so that it is not repeated.
• #31: Useful starting points for learning Ruby on Rails programming: The book: http://www.pragmaticprogrammer.com/titles/rails/index.html The site: http://www.rubyonrails.com/ The editor: http://www.radrails.org/