Learning Rails
By LearningRails.com, Michael Slater and Chris Haupt
To listen to an audio podcast, mouse over the title and click Play. Open iTunes to download and subscribe to podcasts.
Podcast Description
Want to learn how to build web sites with Ruby on Rails? Learning Rails starts from the beginning and teaches all the core concepts.
| Name | Description | Released | Price | ||
|---|---|---|---|---|---|
| 1 | Video23: Performance Analysis with the New Relic RPM | Goals In this lesson, we take a look at techniques for monitoring and improving the performance of your Rails application. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the button on the left. We recommend that you right-click on the button and choose Save As to download it to your computer. This lesson does not depend on the sample application code, although you can start with the sample application code (in the Github repository) to explore the developer mode of the New Relic plugin, as we do in this screencast. Improving the Performance of Your Rails Application For most non-trivial Rails applications, there’s going to be some performance issues. Rails has been subject to a lot of performance criticism, but in reality, Rails can perform very well—it just takes some tuning to get there. Rails makes it quick and easy to get your application up and running, and in the process it also makes it easy to ignore a lot of issues that require some attention when performance is critical. Fortunately, there are plenty of tools and techniques at your disposal when it comes to performance tuning. You’ll need to look for slow queries, for queries that are being performed too frequently, and for opportunities to cache pages and parts of pages. In this screencast, which is sponsored by New Relic, we’re going to focus on the tools and service that New Relic provides. A word about our sponsorships: we think of this like public radio. Sponsors underwrite the cost of producing and distributing a lesson, and we give them opportunities to review the content. But the words and opinions are all ours, and we wouldn’t say anything we didn’t personally stand behind. New Relic is being used by a lot of folks who we’d trust to have made a good choice: 37signals (Basecamp and other apps), Twitter, Lighthouse, and Shopify, to name a few. It’s also included in all hosting packages at Engine Yard. There are alternatives to New Relic’s service, such as those from Five Runs and the recent entrant from Rubysophic. There’s related services, such as Scout, and a variety of open source performance tuning tools, such as http-perf. For more information on a variety of performance optimization tools and techniques, see the performance tuning section of the BuildingWebApps site. Installing the New Relic Plugin The New Relic RPM service connects to your application via a plug-in that they provide, called the agent. Installing it is as simple as for any other plug-in: script/plugin install http://svn.newrelic.com/rpm/agent/newrelic_rpm There’s two modes in which RPM can run. In development mode, it runs on your local development server. In either mode, the plugin hooks into the Rails framework to automatically collect performance data. In Development mode, you examine the performance data RPM collects via views that it installs into your application. In this mode, RPM stores only the last 100 HTTP transactions, and it keeps all the analysis data in memory, so it doesn’t touch your database. In production mode, it runs on your production server and sends data to New Relic’s server once per minute. New Relic’s | 9/29/08 | Free | View In iTunes |
| 2 | Video22: Deploying to a Public Web Server | Goals In this lesson, we finally deploy our application to a public web server. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the button on the left. We recommend that you right-click on the button and choose Save As to download it to your computer. The code used in this lesson has all been checked in to the Github repository. Rails deployment overview Deploying a Rails application is more complex than for a simple web site or PHP application for two reasons: In general, a separate application server is used to keep the Rails application in memory, and execute requests that come in through the HTTP server. This requires more configuration, and that the application server be restarted when the code is changed. Static and PHP sites are typically deployed by simply uploading files to the server, with FTP or SFTP. Although there is nothing about Rails that requires it, Rails applications are almost universally deployed by having the server check the code out from a version control system. (This is a better practice for all kinds of sites, but it less often used with simpler technologies.) The flow of a deployment is thus as follows: Make changes to your code locally Test the changes Check the changes in to version control (and push to the main repository, if using Git) Optionally, display a maintenance page to replace the site while it is being updated Perform a checkout of the code from the version control system to the web server Run any migrations that the new code requires Restart the application server Disable the maintenance page, if any Although this may sound complicated, with the right tools it is quite simple once you’re all set up. The key tool is a program called Capistrano, which can automate the entire process (starting with step 4). In the previous few lessons, you’ve been through the first three steps; by the end of this lesson, you’ll have been through the whole process. Choosing a web and application server configuration There’s a huge array of choices to be made when it comes to server software selection and configuration. We’ll describe one of many possible approaches in this lesson. You’ll almost surely want to explore other options, and need to learn more about issues specific to your server, to do your own deployments. Here’s where to find some useful resources on our BuildingWebApps site: Linux Rails Hosting Rails Application Servers HTTP Servers Automation We also highly recommend the book Deploying Rails Applications. For the past two years or so, the most widely used setup has been Apache 2.2 as the front-end server, which processes HTTP requests, serves static files (including JavaScript, CSS, and images, as well as any cached <span clas | 8/31/08 | Free | View In iTunes |
| 3 | Video21: Version control with git | Goals In this lesson, we put our application into a version control system, in preparation for deploying the application in the next lesson. We do this first because the proper way to deploy an application is not to copy it from your computer to the server, but to have the server pull the application from the version control system. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Choosing a version control system There are many version control systems. CVS was the first system widely used in the open-source community. Several years ago, it was largely replaced by Subversion. And in early 2008, most of the Rails world moved to a newer version control system, called git. We’re going to use git in this lesson, since it has become the standard in the Rails community, and is used for Rails itself and most plugins. git was originally written by Linus Torvalds to manage development work on the Linux kernel. It’s an extremely capable system, with more than 100 commands. We’re going to just scratch the surface of its capabilities in this lesson, but you’ll learn enough to use it for day-to-day development. To make full use of it, spend some time with the resources listed on our git page. In particular, you may want to purchase the PeepCode git screencast. If you’re familiar with other version control systems, you probably expect there to be one central repository stored on a remote server somewhere. git is different; it is a distributed version control system, in which there can be any number of repositories for a single project. You’ll create a local repository on your computer, and if you want, you can create a remote repository elsewhere, such as on a hosted git service like github.com. (You’ll need to have a repository that is accessible from the Internet to deploy your application.) Setup We aren’t making any changes to the code in this lesson, and you don’t need to have the code installed locally to complete the lesson. If you follow along, by the end of the lesson you’ll have your own copy of the code on your computer, managed by a local git repository, and you’ll have your own repository stored on github as well. First we need to install git. Assuming you’re on a Mac and have Macports installed, open a terminal and enter: sudo port install git-core Now set up your user information in the git configuration: git config --global user.name "Michael Slater" git config --global user.email learningrails@buildingwebapps.com See our articles on installing Ruby on Rails for more details: Setting up Rails on Leopard Setting up Rails on Tiger Setting up Rails on Windows Vista Setting up Rails on Windows XP Creating a git repository for an application on your computer There’s two paths you could take to creating a repository on your computer: If you have an application already on your computer, you can create a local git repository and add the application to it If you want to start from an existing application, such as the Learning Rails sample application, you can make your own copy of that repository. In this lesson, we’ll do both of these things. First, we&rsq | 8/3/08 | Free | View In iTunes |
| 4 | Video20: Testing your site (Part 2) | Goals In this lesson, we finish up our testing journey by fixing up some of our functional tests. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup The code in this episode is the same as the ending state of the previous episode and contains all of the fixed tests. Learning Rails example app code as of the end of this lesson Functional Tests We continue where we left off, having working unit tests but many broken functional tests. Fixing the Functional Tests We now know how to read the test results, so switching our attention to the functional test block results, we see we have our work cut out for ourselves: FEEFFEEFEEFFEEFFFFEFFFFFFFFF.........FEEEE. Which in my first run was equivalent to 43 tests, 36 assertions, 20 failures, 13 errors. Ouch. The Rails scaffold generator does a much better job at creating functional tests than it does with unit tests. Functional tests exercise our controllers. Peeking inside most of the test files in the test/functionals directory, you will note that they follow similar patterns. So what went wrong? In scanning through the test diagnostics, we see a lot of tests with similar issues. There are many tests with problems with redirects: “Expected response to be a <:success>, but was <302>”. There are many tests where things were not created, updated, or destroyed when expected. Thinking back, the common thread here is that all of these things need you to be logged in, yet, when the tests are automatically generated for us, the generator has no idea about this requirement. Let’s fix that. The restful_authentication plugin that we used provides a utility module called AuthenticatedTestHelper. This module contains useful methods that you can mix-in to your test classes to simulate things like logging in, precisely what we need. Since we protected most of our administrative functions with those before_filter :login_required checks, that will cause any of our tests that try to directly exercise an action to instead get redirected to a login screen. Let’s pick one of our controller’s tests to fix up as our example. The others will follow similar patterns and you can look at the final project code to see the changes (or try to make the changes yourself as an exercise). First, add the authentication system’s helper at the top of the test class. While there, add the user fixtures so we have some test user accounts to log in with: class CategoriesController < ActionController::TestCase include AuthenticatedTestHelper fixtures :users Now, let’s use the new method we have to log in as the user quentin: def test_should_get_index login_as :quentin get :index assert_response :success assert_not_nil assigns(:categories) end Run the tests again. The redirect failure on test_should_get_index should now be gone. Go back to each method in this test class and add the login_as :quentin line at the start of each test method. All of your redirect failures should now be cleaned up. But, there are still failures to fix. Look through the other functional tests and make the same changes to all of the others that are protected with the before_filter (links_controller_test, messages_controller_test, pages_controller_test, users_controller_test). For the controllers that are selective about the login requirement, be sure to not login when it isn’t needed. For instance, @MessageControllerTest@’s new and create tests are not protected by login. See the contr | 7/24/08 | Free | View In iTunes |
| 5 | Video18: Adding a Contact Form and Mailer | Goals In this lesson, we’re creating the “Contact Us” page. There’s two major parts to this: creating the message model and the associated forms and admin setup, and then creating a mailer that takes new messages and sends them to the site administrator via email. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup We begin with the code with which we ended Lesson 17. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the start of this lesson Learning Rails example app code as of the end of this lesson Creating the contact form Scaffolding the Message Model If we only wanted to send an email when the contact form was filled in, we wouldn’t really need to use an Active Record model and save it to the database. But it’s actually easier to use all the scaffolding and other support that Active Record provides, and it is handy to have the messages stored in the database so the can be reviewed independently of email. We start by creating a scaffold for contacts: script/generate scaffold message name:string company:string phone:string email:string subject:string body:text This generates the model, controller, views, and test files. Now run the migration: rake db:migrate And start the server: script/server Hooking up the Contact Form First delete the layout file the scaffold generates (views/layouts/messages.html.erb), so the scaffolded views will use our standard layout. We already have a contact button in the navigation bar, but this is pointing to one of our initial static pages, and now we want it to point to the new contact form. So run the sample app (script/server), log in, go to the Page Admin, and edit the Contact page to set it to redirect (using the capability we added in the Lesson 17) to the new action in the messages controller. Since we’ve hijacked a scaffolded form that was meant to be part of the admin and are using it for a user-facing form, we need to tweak it a bit. Delete this line from the end of views/messages/new.html.erb, since we don’t want visitors to try to get to the list of all messages: <%= link_to 'Back', messages_path %> Redirecting to Home after Submission We don’t want to redirect to the message/show action, which is part of the admin interface and is what the scaffolding does by default. So we’ll change the redirect to go to the home page, and change the flash message to something more appropriate. Users who submit a message will see the thank-you message at the top of the home page. In the message controller’s show action: if @message.save flash[:notice] = 'Thanks for Your Message' format.html { redirect_to root_path } Later in this lesson, we’ll further modify this code to actually send the messages as an email, in addition to saving it to the database. Message validations We want to be sure that the message looks valid before processing it, so we add the following validations to the message model (models/message.rb): validates_presence_of :name, :subject, :body validates_format_of :email, :with => /^(\S+)@(\S+)\.(\S+)$/ The second validation ensures that the email looks like a valid email address. This messy regular expression is one of the simpler ones of many that could be used. To apply some styling to the error messages that are displayed if a validation fails, | 7/24/08 | Free | View In iTunes |
| 6 | Video15: Pages and Subpages | Goals In this lesson we’re adding a hierarchy to our pages. Instead of a single pool of pages with a navigation button for each, we want to have subpages as well, which don’t appear in the top navigation bar but are listed in second-level navigation on their parent page. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup We begin with the code with which we ended Lesson 14. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 14 Learning Rails example app code as of the end of Lesson 15 Model association To associate subpages with their parent pages, we could create a subpage model, and then we could write in the page.rb model: has_many :subpages And in the subpage.rb model: belongs_to :page But to do it this way creates a lot of duplication, since the subpage model would need to behave just like the page model. So we use what’s called a self-referential association: a page object has many page objects, and a page can have (belong to) a parent. This requires a more complex declaration in the page.rb model, as we’ll see, but once that’s done, the self-referential model works the same as it would if subpage was a separate model. Extending the Page table We need to add some fields to the Page model. As with any change to the database structure, we create new migration, with whatever name we’d like: script/generate migration AddSubpages These three lines in the “up” method create the new fields: def self.up add_column :pages, :parent_id, :integer add_column :pages, :navlabel, :string add_column :pages, :position, :integer end And the corresponding three lines in the “down” method allow us to set the database back to its prior condition, should we want to roll back the database: def self.down remove_column :pages, :parent_id remove_column :pages, :navlabel remove_column :pages, :position end Once we’ve created and saved the migration file, we apply the migration: rake db:migrate Defining the association In the Page class, we need to specify the relationship between parent pages and subpages. We have a field, parent_id, that we created in the previous migration to serve as the foreign key for the association. Since this is a self-referential association, the default naming schemes don’t apply, and we need to explicitly specify the class name and foreign key field name: has_many :subpages, :class_name => 'Page', :foreign_key => 'parent_id' The has_many declaration allows us to then write, typically in our controllers, page.subpages, to retrieve all the pages that have the current page as their parent. Since this is a self-referential association, the “belongs_to” side of the relationship also goes in the page model: belongs_to :parent, :class_name => 'Page', :foreign_key => 'parent_id' This declaration allows us to then write page.parent to find the parent page, if there is one. Writing Custom Finders Until now, we’ve mostly used standard find methods directly in our controllers. It’s a better design practice, however, to push logic for finding into the model. By writing a custom method to serve as a special kind of find, we can encapsulate more of how the page model works in that single file. Here’s a method to provide the complete set of navigation tabs: def self.find_main Page.find(:all, :conditions => [' | 7/24/08 | Free | View In iTunes |
| 7 | Video17: Resources Page: Links, Categories, and HABTM | Goals In this lesson, we’re creating the database-driven Resources page, with links shown by category. Along the way, we look at join tables and HABTM associations. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup We begin with the code with which we ended Lesson 16. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the start of this lesson Learning Rails example app code as of the end of this lesson Adding the Links and Categories Models For each link, we want to have a title and a description, and of course we need the URL. Let’s use the scaffold generator to create the model and the admin page: script/generate scaffold link url:string title:string description:text The “text” field type can hold longer strings that the “string” type, which is why we used it for the description. We also need a model for the categories, so let’s run another scaffold command for that simple model, which requires only a title and a description for each category: script/generate scaffold category title:string description:text Creating the Join Table When you have an association where one model has a belongs_to declaration, you know that model must have a field to store the foreign key that is what creates the association. In the case of Categories and Links, however, a category can have many links, and a link can belong to many categories, so what we need here is a has_and_belongs_to_many association. In this type of association, neither of the associated tables stores any foreign keys; instead, a separate join table stores just the pairs of foreign keys that define each association (i.e., associate one link with one category). We need to explicitly create this join table. There is no model associated with this table; it is just a database table that is use automatically along with the two associated models. Let’s generate an empty migration file with the migration generator: script/generate migration LinkCategoryJoin Note that the name is entirely arbitrary; we just want something that reminds us of what this migration is for. Now we define the migration by writing the self.up method: def self.up create_table :categories_links, :id => false do |t| t.integer :category_id t.integer :link_id end end This creates a table with two columns, each of which is one of the foreign keys. This table doesn’t get an id column of its own, so we add the option :id => false to the create_table method call. There’s several Rails naming defaults that come into play here, and you need to know what they are to write this code correctly: Join tables are always named with the names of the two associated tables, in alphabetical order, separated by an underscore. That’s why the table is called categories_links, and not links_categories (which won’t work because of this default). The foreign key fields are named with the name of the table they are referencing, with _id appended. The foreign key is referencing a single element in that table, so it uses the singular name (e.g., category_id, not categories_id). To keep our migrations reversible, we’ll add the down method: def self.down drop_table :categories_links end Migrate! | 7/24/08 | Free | View In iTunes |
| 8 | Video16: Clean-Up | Goals In this lesson we’re taking a break from adding features to do a little cleanup: Get the page title logic out of the application layout Add page titles for admin and login pages Make navigation buttons indicate which is the current page Add a ‘back to previous’ navigation link on subpages Add a little styling to subnav links Set the focus for the login field Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup We begin with the code with which we ended Lesson 15. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 15 Learning Rails example app code as of the end of Lesson 16 Fix up Page Title Handling Several lessons ago, as we were building the core of our content management system, we put a quick hack in the application layout (views/layouts/application.html.erb) that put this logic in the wrong place; we want to keep logic out of our views as much as practical. So let’s replace this line: <title><%= @pagetitle || (@page && @page.title) || 'Learning Rails Sample Application' %></title> with the much simpler: <title><%= @pagetitle %></title> Now we need to set this instance variable appropriately for each view. First, in the viewer_controller show method, insert the line (after @page is set): @pagetitle = @page.title That takes care of all pages that come from the content management system. Now we need to take care of the admin and login pages. Add to users_controller: before_filter :set_pagetitle def set_pagetitle @pagetitle = 'User Administration' end This before filter will run before every action, so the page title will be set (to the same thing) for all of them. In page controller, we already made a very similar addition in a previous lesson, but we called it set_metadata, so for consistency we’ll rename it to set_pagetitle Finally, the sessions controller needs some attention. Add to the (empty) new action in sessions_controller: @pagetitle = 'Please Log In' And after the else in the sessions_controller’s create method: @pagetitle = "Login was not successful" You could do more to customize page titles for the various admin pages, but this is enough for us. Highlight Current Nav Button Next problem: make the appropriate nav button highlight to indicate the current page. First, we need to identify which nav button to highlight by using some Ruby code to conditionally insert an ID. We’ll insert the following code in the application layout, in the <li> tag that begins each nav button: <li <%= "id = 'current'" if @page && @page == page %>> Now we need a CSS rule, in public/stylesheets/learningrails.css, to style the button for the current page: #navbar #current a { background-color: #000; } Now the navigation button for the current page is highlighted. Provide a Link Back to Parent Page When we added subpages in the previous lesson, we didn’t provide any indication when you’re on a subpage as to what the parent page is. There’s several things we might do about this; here’s two possibilities: We could use the subnav div area to show a “Return to About Us” link, for example, on subpages of About Us. To do so, replace the cod | 7/24/08 | Free | View In iTunes |
| 9 | Video19: Testing your site (Part 1) | Goals In this lesson, we’re going to step back and look at a subject we’ve neglected: Testing. First, we’ll take a brief tour to understand the support Ruby and Rails provides us for using tests in our regular development. Then, we will take stock of the current status of our code and make sure it is on solid footing with testing. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup We begin with the code with which we ended Lesson 18. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the start of this lesson Learning Rails example app code as of the end of this lesson A Brief Tutorial on Testing Why Write Tests? In our previous 10 screencasts, we’ve built a simple Ruby on Rails site. To move along as fast as possible, we’ve neglected testing, and in this lesson, we’re going to remedy that. Tests provide a safety net that helps you improve the quality of your code. You can certainly write significant Rails applications without writing tests — I have to admit I’ve done so myself, and I suspect that many Rails developers are continuing to do so. Rails doesn’t force you to write tests. But it is one of the hallmarks of professional-quality code that it has complete tests. In the short term, writing tests adds one more thing you need to do, and another set of syntax and technology you need to learn. There’s no doubt that this takes more time up-front. But in the long run, writing tests can save you time, since problems are easier to track down when they do occur. Many developers advocate writing tests even before you write the code, which forces you to think through exactly what your code is supposed to do. Tests are helpful in finding the corner cases that you might not remember to test manually, and in being able to automatically test all aspects of your code whenever you make a change. Without tests, it’s common for a change you make to fix one thing to accidentally break something else, which you might not notice right away. Tests are especially valuable when you’re doing major rework on your code, commonly called refactoring. With a good suite of tests, you can be confident after you’ve rewritten some code that it hasn’t broken anything. Testing Background Many studies have shown that the cost of fixing bugs rises with time. Imagine if you had a “quality safety net” that helped protect you by checking basic assumption about your code and notified you if something broke those assumptions. If you had such a tool, it would give you greater confidence as you added or refactored code in your program. The Ruby on Rails community has adopted many so-called Agile practices, and code testing is but one. The core Rails team has made it very easy to implement testing in your program by building in simple testing tools in the standard Rails installation. Whether you choose to write tests after coding parts of your program (“Test After Development” – TAD) or before you write a line of code (“Test First or Test Driven Development” – TDD), Rails will accommodate you. Ruby on Rails has built in support for a variety of testing scenarios. Rails currently uses the Ruby Test::Unit library to implement three kinds of tests: Unit, Functional, and Integration Tests. Rails’ usage of the names for testing terms is slightly different than common meaning. In Rails, Unit tests are tests that exercise Model objects. Functional tests focus on test | 7/24/08 | Free | View In iTunes |
| 10 | Video13: Admin Pages | Goals In this lesson, we implement the actual administrative dashboard using improvements we make to the mini-CMS we are building. We finish up with an improvement to our navigation code so we can build the tabbed interface more dynamically. Setup We begin with the code with which we ended Lesson 12. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 12 Learning Rails example app code as of the end of Lesson 13 Admin Pages Of course, it is tiresome to keep typing the URLs manually to get to our administrative pages. Let’s create an admin dashboard page that connects us to these sub-pages. Let’s also make the admin page easy to reach when we are appropriately logged in. Make the Admin page attribute If we are going to use our baby-CMS to implement this page, what is missing? We need to know when a page is an admin type page so we can protect it properly. Make a migration to add an admin attribute to pages, and then set some default values in the migration to keep things tidy. class AddAdminPageAttribute < ActiveRecord::Migration def self.up add_column :pages, :admin, :boolean @pages = Page.find(:all) @pages.each do |page| page.update_attribute(:admin, false) end end def self.down remove_column :pages, :admin end end Now, we need to update the Page Admin html so we can see/edit the new admin attribute: First, index.html.erb gets a couple of new table entries: <h1>Listing pages</h1> <table> <tr> <th>Name</th> <th>Title</th> <th>Body</th> <th>Admin?</th> </tr> <% for page in @pages %> <tr> <td><%=h page.name %></td> <td><%=h page.title %></td> <td><%=h page.body %></td> <td><%= page.admin? ? "TRUE" : "FALSE" %></td> <td><%= link_to 'Show', page %></td> <td><%= link_to 'Edit', edit_page_path(page) %></td> <td><%= link_to 'Destroy', page, :confirm => 'Are you sure?', :method => :delete %></td> </tr> <% end %> </table> <br /> <%= link_to 'New page', new_page_path %> Then add a snippet to show.html.erb to see the Admin value: <p> <b>Admin?</b><br /> <%= @page.admin? ? "TRUE" : "FALSE" %> </p> Update both edit.html.erb and new.html.erb with a snippet to use a check box for the state of the admin attribute (put this in before the submit): <p> <b>Admin?</b><br /> <%= f.check_box :admin %> </p> We should be all set. Check it out and create a page with the admin bit set. Can you see it when you are logged in? What about when you aren’t? Oops! Update the viewer controller to handle special pages Of course, we don’t filter in anyway for admin pages, so anyone can see a page marked with the Admin bit. Let’s fix that by protecting admin viewable pages by updating the viewer controller: def show @page = Page.find_by_name(params[:name]) login_required if @page.admin? end We are leveraging the login_required function provided to us by the restful_authentication plugin. If the requested page has the admin value set to true, we’ll check to see if the user is logged in with login_required. Add an admin dashboard page in the DB Finally, we can create a page using the mini-CMS’ Page Admin. Make one now and we’ll call it “admin”. Ma | 7/24/08 | Free | View In iTunes |
| 11 | Video14: Using Textile Markup, plus In-Place Editing with Ajax | Goals In this lesson we’re going to add two features to our content-management system: Textile markup and in-place editing. Both are, in principle, very simple to implement, thanks to a couple of Rails gems and plugins, as well as the Prototype and Scriptaculous JavaScript libraries. The reality turns out to be just as simple as we’d hope in the first example, and rather more complex in the second. Please note that, while we’ve tried to make these notes complete, they aren’t the full tutorial; that’s in the screencast, which you can access via the link on the left. Setup We begin with the code with which we ended Lesson 12. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 13 Learning Rails example app code as of the end of Lesson 14 Using Textile markup We don’t want our administrative users to have to enter HTML code, so we’ll use a simple markup language called Textile. There’s two pieces of Ruby code we use to implement this. The first is the gem RedCloth, which you already have if you’re on Leopard. This is the code that translates Textile into HTML. The second is a Rails plugin called “acts_as_textiled”, which makes it trivially easy to add Textile markup to our content blocks. Run “gem list” to see if you already have RedCloth. If not: sudo gem install RedCloth To add the plugin, open a terminal window at the root of your application and enter the following command: script/plugin install svn://errtheblog.com/svn/plugins/acts_as_textiled Add to the Page model: acts_as_textiled :body That’s it. This plugin is smart enough to automatically display the Textile markup source when you’re displaying the body in a form field, as we are in the admin pages, but to render it into HTML anywhere else you use the body. You’ll need to stop and restart the server before the plugin will function. Now you can edit any of the pages in the content management system, such as the admin page, to convert the markup to Textile. Note that the page list view shows the HTML created by RedCloth — that’s because the acts_as_textiled plugin automatically renders the Textile content into HTML anyplace except in a form field. In-place editing In-place editing is a common feature of modern web applications, and there’s good support for it built in to Prototype. There’s also a Rails helper that wraps the Prototype method so we don’t even have to touch the JavaScript code. In Rails 1.2.x, the in-place editor helper was part of the framework. In Rails 2.0, however, it was split out as a plugin, in theory so it could be separately maintained. Unfortunately, it has not been maintained (as of this writing in early May 2008), so not only do we need to install the plug-in, we’re going to have to seek out and install a couple of patches before we have everything working. Installing the plugin Install the in_place_editing plugin by entering the following in a console at the root of your application: script/plugin install http://svn.rubyonrails.org/rails/plugins/in_place_editing Modifying our code to use the plugin The readme file provides basic in | 7/24/08 | Free | View In iTunes |
| 12 | Video12: User Management | Goals In this lesson, we work towards implementing an administrative dashboard by expanding the user controller generated by restful_authentication to give us full abilities to manage user data. Setup We begin with the code with which we ended Lesson 11. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 11 Learning Rails example app code as of the end of Lesson 12 Clean up session create with a notice if user incorrectly enters credentials Before diving in to the core work in this lesson, let’s continue to do some small changes to improve the experience our application provides. One pain point occurs when you try to log in and type the wrong credentials. Let’s put a notice in the create failure path, before re-rendering the edit dialog flash[:notice] = "Try entering your credentials again" Create a default admin user (migration) Let’s use a migration called a “data migration”. It doesn’t change the structure of the database. Instead it loads data, in this case, a default user account. script/generate migration AddDefaultUser self.up if !User.find_by_login('admin') User.create(:login => 'admin', :email => 'admin@sample.com', :password => 'changeme', :password_confirmation => 'changeme') end end We aren’t creating a down migration in this case. We don’t know if we were the ones who created this account for sure, so we won’t delete it when this migration is run in reverse. Run the migration in the terminal: rake db:migrate Add a user list page The “restful_authentication” plugin’s generate creates a RESTful controller, but it only creates the new and create actions. We need to fill the rest out and can use the Pages controller as a model. Add an index action to users controller. def index @users = User.find(:all) end Create users/index view in the users directory (index.html.erb). Also prepare by adding links to show, edit, and delete. Put a link at the bottom to create new users. <h1>Listing Users</h1> <table> <tr> <th>Login</th> <th>Email</th> </tr> <% for user in @users %> <tr> <td><%=h user.login %></td> <td><%=h user.email %></td> <td><%= link_to 'Show', user %></td> <td><%= link_to 'Edit', edit_user_path(user) %></td> <td><%= link_to 'Delete', user, :confirm => "Are you sure you want to delete '#{user.login}'?", :method => :delete %></td> </tr> <% end %> </table> <br /> <%= link_to 'New User', new_user_path %> Take a look…seems to work, but we need to fill out the rest of the actions and the appropriate views. Add show user page Add a show action to the users controller. def show @user = User.find(params[:id]) end Add the show view (show.html.erb). <p> <b>Login:</b> <%=h @user.login %> </p> <p> <b>Email:</b> <%=h @user.email %> </p> <p> <b>Password:</b> [secret] </p> <%= link_to 'Edit', edit_user_path(@user) %> | <%= link_to 'Back', users_path %> Add a user delete function Add destroy action to users controller. def destroy @user = User.find(params[:id]) @user.destroy redirect_to(users_url) end Note the link is already in the index view and uses a javascript alert dialog | 7/24/08 | Free | View In iTunes |
| 13 | Video10: Putting the Page Contents into the Database | In this lesson, we create our first database table and Rails model. In the previous lesson, we created static pages, with all the contents in the view files. The problem with this approach is that to change any text, you must modify the code. A better approach is to put the page contents into the database, so we can then provide an administrative interface that allows non-technical users to modify the pages. In this lesson, we do just that, creating the core of a simple content management system (CMS). Setup We begin with the code with which we ended Lesson 9. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 9 Learning Rails example app code as of the end of Lesson 10 See Lesson 8 for pointers on setting up your development environment. In Lesson 8, we explained how to set up the MySQL database. In this lesson, we use SQLite, which is a little easier to get going (if you’re using Leopard, you don’t have to do anything to use SQLite). If you want to use MySQL instead, you just need to change the settings in database.yml. In particular, in the development section, replace the code in the sample application with something like this: adapter: mysql database: learning_rails username: root (or other user name) password: secretword (whatever your password is; leave blank if none) host: localhost You’ll also need to create the database, using the mysql command-line interface or one of the GUI interfaces (we’re partial to Navicat). With sqlite, this is done for you automatically. Lesson Outline Here’s the coding steps we take in this lesson. Watch the screencast for details and explanations (see link at the top of the left column). 1. Delete the four static views in views/pages 2. Create a scaffold for the new Page model with this command: script/generate scaffold page name:string title:string body:text 3. Run the migration: rake db:migrate 4. Start the server: script/server 5. Delete the automatically generated layout file views/layouts/pages.html.erb 6. Create the four pages (home, about, contact, resources) through the admin interface: Browse to http://localhost:3000/pages/new 7. Create a controller and view for the public view of the page: script/generate controller viewer show 8. In controllers/viewer_controller.rb, add this line to the show method: @page = Page.find_by_name(params[:name]) 9. Replace the boilerplate text in views/viewer/show.html.erb with this line: <%= @page.body %> 10. You can now access the home page using the explicit URL: http://localhost:3000/viewer/show?name=home 11. Create a route to clean this up. Add this line to config/routes.rb, after the map.resources line: map.view_page ':name', :controller => 'viewer', :action => 'show' 12. Update the route for the root (home) page (we created this line in Lesson 9): map.root :controller => 'viewer', :action => 'show', :name => 'home' 13. Fix the navigation links in views/layouts/application.html.erb: <li><%= link_to 'Home', view_page_path('home') %></li> <li><%= link_to 'Resources', view_page_path('resources') %></li> <li><%= link_to 'About Us', view_page_path('about') %></li> <li><%= link_to 'Contact Us', view_page_path('contact') %> | 7/24/08 | Free | View In iTunes |
| 14 | Video11: Adding User Authentication | Goals In this lesson, we add user authentication so only logged-in users can access the page controller and modify the contents of the site. Setup We begin with the code with which we ended Lesson 10. These zip files contain the beginning and ending states of the code: Learning Rails example app code as of the end of Lesson 10 Learning Rails example app code as of the end of Lesson 11 Page title cleanup First, we need to take care of a little problem we created for ourselves with the way we handled the page title metadata in the previous lesson. We’re going to add a couple more admin controllers in this lesson, and with the approach used in the previous lesson, we’d need to specifically set the @pagetitle instance variable in each of those controllers. For now, we’re going to replace the existing setting of the title tag in the application layout with the following: <title><%= @pagetitle || (@page && @page.title) || "Learning Rails Sample Application" %></title> This line sets the pagetitle in one of three ways: If there is an instance variable @pagetitle, use that If not, then use @page.title, if there is a @page object If there’s neither a @pagetitle nor a @page object, use the fixed string This is a little messy, and in a later lesson we’ll fix it in a more elegant way. Install plugin The plugin we’re going to use is called restful_authentication. You can find plugins by searching on Google or on various Rails plugin directory sites. One good site is AgileWebDevelopment. From this site, you can get the URL for the repository where the plugin code is located. To install restful_authentication, enter the following line in a terminal at the root of your application: script/plugin install http://svn.techno-weenie.net/projects/plugins/restful_authentication/ You can view the readme in vendor/plugins/restful_authentication to learn more about it. Set up the plugin This plugin provides a generator of its own to help us set things up, so let’s run it: script/generate authenticated user sessions In this command, “authenticated” is the name of the generator; “user” is the name of the model that will store user names and passwords; and “sessions” is the name of the controller that will manage user sessions. This generator creates a migration for us, but we need to run the migration: rake db:migrate Finally, to make the methods provided by this plugin available in your controllers, you need to add the following line to the file controllers/application.rb: include AuthenticatedSystem The application controller is “mixed in” to all other controllers, so any code you put here is available to all controllers. So by putting the “include” statement for the authenticated system here, you’re effectively adding that code to every controller. Creating a user Before we can have log-in, we need to have users, so let’s add some user management. The authenticated generator we ran in the previous section gave us a users controller and a view for creating users, so browse to //localhost:3000/users/new and create a login for yourself. The generator also created a sessions controller, which is what handles the actual log in and log out operations. Logging in is creating a new session, and logging out is destroying a session. It’s convenient to have shortcuts we can use to refer to these, so let’s add some named routes. Add the following lines to the top of the | 7/24/08 | Free | View In iTunes |
|
15 |
8: Setting Up Your Development Environment | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Note: we created this series in 2008, and the Ruby on Rails world, along with the software that supports it (such as various gems) has evolved quite a bit since then. Check the comments for suggestions on how to overcome various incompatibilities. We hope to have an updated version of the series by the end of 2010. Detailed Ruby on Rails Development Environment Installation Instructions Mac OS X 10.5 Leopard Mac OS X 10.4 Tiger Windows Vista Windows XP | 7/24/08 | Free | View In iTunes |
|
16 |
7: Testing Rails Code | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Code Examples Here’s an example of using asserts. Suppose you have a test that searches for a non-existent podcast episode; you’d want to assert that the result was nil. The test case code would read: def test_podcast_does_not_exist podcast = Podcast.find_by_title('Intro') assert_nil podcast end Another example checking to see if the test database contains three podcasts loaded from fixtures might read: def test_three_podcasts_exist assert_equal, Podcast.find(:all), 3 end Here’s an example of a fixture, illustrating how fixtures can use model associations. An entry in the podcast.yml file might read: episodeone: name: Introductory Podcast listeners: anne, bob, charlie and entries in the listeners.yml file would read: anne: name: Anne podcast: episodeone bob: name: Bob podcast: episodeone charlie: name: Charlie podcast: episodeone Links to More Resources See the following sections of the site for links to resources on testing: Testing in general Test-driven development Unit testing Functional testing Integration testing Test fixtures Testing Toolsl Behavior-Driven Development | 7/24/08 | Free | View In iTunes |
| 17 | Video9: The Simplest Possible Rails Application | Welcome to the first screencast in the Learning Rails free online course in Ruby on Rails. Note: we created this series in 2008, and the Ruby on Rails world, along with the software that supports it (such as various gems) has evolved quite a bit since then. Check the comments for suggestions on how to overcome various incompatibilities. We hope to have an updated version of the series by the end of 2010. If you want to follow along on your own system, you’ll need to have a basic Ruby on Rails development environment set up. Check Lesson 8 for details on how to do that. We’d love to hear any feedback you may have on this screencast. Please add your comment at the bottom of the page. In this lesson, we build a very simple Ruby on Rails application, with just a few static pages, so we can walk through the files that make up a Rails application and show how the view system works. The simple approach we’ve taken here isn’t something we would recommend for a production Rails application; it’s designed to cut away as much complexity as possible so we can focus on the essentials. In the next lesson, we’ll start building a more dynamic site. There’s not a lot of code in this first lesson, and we’ll be replacing it in the next lesson, but you can download the full application if you’d like. P.S. We’re still refining our production workflow, and the video in lesson is not quite up to our production quality goal. You’ll see improvements in future lessons. | 7/24/08 | Free | View In iTunes |
|
18 |
5: Rails Form Processing | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Lesson Notes CRUD is the acronym for the four main things you do with database records: Create Read Update Delete These notes illustrate the code described in the podcast. See the transcript for more details. For more details about forms processing with Rails, see the forms page in our topics section. You’ll find some great screencasts listed there that will go into much more depth than this podcast. For a database of podcast episodes, with a title and a description field for each, the basic form code looks like this: <% form_for @podcast do |form| %> <%= form.text_field :title %> <%= form.text_area :description %> <% end %> The minimal code for the controller’s create action is: Podcast.create params[:podcast] The create method takes the parameters from the params[:podcast] hash, uses them to initialize a new object, and then saves that object to the database. This line to the podcast model ensures that podcasts can’t be saved with a blank title: validates_presence_of :title In the controller, the create action tests the value returned from the Podcast.create call, and if it is not false, it knows the save succeeded. If it is false, then the form is rendered again. if Podcast.create params[:podcast] redirect_to (wherever you want to go after a successful save) else render :action => :new end To display the error messages, the form view just includes a call to the error_messages_for helper: error_messages_for :podcast To make this an Ajax form, we can simply change the form_for helper to remote_form_for: <% remote_form_for @podcast do |form| %> The rest of the form remains the same. The controller and views must be modified to return just an HTML or JavaScript snipped, rather than an entire page, after a create or update action. | 7/24/08 | Free | View In iTunes |
|
19 |
6: Tools for Rails Developers | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Lesson Notes For links to more information about the various tools mentioned in this lesson, refer to following parts of the BuildingWebApps site: IDEs Editors Gems Automation Plugins Source Code (Version) Control Deployment Documentation Logging Debugging Testing | 7/24/08 | Free | View In iTunes |
|
20 |
2: Anatomy of a Web Application | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Examples used in the audio program Here’s some of the examples we use in the show, which may be easier to grasp in printed form: If the user types www.BuildingWebApps.com/podcast.html into their browser, they’re asking the server at BuildingWebApps.com to find a file called podcast.html and send the contents of that file to the browser. In a Rails application, the request would be written as www.BuildingWebApps.com/podcast, in which podcast is the name of the controller to be invoked A Rails URL such as www.BuildingWebApps.com/podcast/show/17 invokes the show action in the podcast controller and passes it the parameter of 17 (presumably the ID for a podcast episode). To request all the podcast objects, the controller would execute a statement such as podcasts = Podcast.find(:all). (Don’t worry about the odd punctuation for now. To find a particular podcast episode according to its episode number, the show action might execute a statement such as podcast = Podcast.find_by_episode(2) For More Information See the notes for Lesson 1 for pointers to online resources and books about Ruby and Ruby on Rails. | 7/24/08 | Free | View In iTunes |
|
21 |
3: Rails Views -- How Rails Renders Pages | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Code Examples In this podcast, we mention several bits of code that are hard to visualize in audio, so we’ve included them here. Refer to the transcript to see these examples in context. For links to additional resources, scroll down past the code examples. Embedded Ruby Ruby code in a view template is preceded by <% and followed by %>. The enclosed text is what is called “embedded Ruby,” or ERb. If the Ruby code is preceded by just <%, then the code is executed, but its output is not inserted into the HTML stream. For example, you might have Ruby code that says something like “if podcast title is not blank”. In real code, this would be: <% if !podcast.title.blank? %> For example, if we had a variable named title and we wanted its value to be inserted into the HTML, we’d write <%= title %> Last episode, we gave as an example a page listing all the episodes of this podcast. In this example, the variable that would be passed to the view would be an array of podcast objects. The code to do so looks like this: <% for podcast in podcasts %> <h2><%= podcast.title %></h2> <p><%= podcast.description %></p> <% end %> Partials A partial is just a small view template that is meant to be included in another template, or in a layout. The statement that goes in the controller is: render :partial => 'partial_name' You can also use a partial when you want to repeatedly insert the same bit of markup, but using data from a series of objects. For example, consider our listing of podcast episodes. We can use a partial that displays the information for a single podcast. You could simply put that partial in a loop that executes it once for each podcast object, like this: <% for podcast in podcasts %> <%= render :partial => 'podcast' %> <% end %> (For simplicity, we’re ignoring here some details about how the podcast variable is passed to the partial.) But Rails gives us a shortcut that makes this even simpler; in the “render partial” statement, we can refer to the array of podcast objects (which the controller provided), and the partial will automatically be repeated for each podcast in the array. Here’s the code: <%= render :partial => 'podcast', :collection => podcasts %> Rails Helpers Instead of writing: <a href = 'some_URL'>Text to be linked</a> you can use the Rails link_to helper, like this: <%= link_to 'Text to be linked', 'some_URL' %> The link_to helper is more interesting when you use it to help you generate the URL, instead of specifying it explicitly. For example, you can specify the controller and action you want the link to invoke, and any parameters that you want to pass to it, and let link_to generate the URL. Dynamic generation of links is really preferable when it comes to flexibility and maintenance of your code. For example, you could write: <%= link_to 'View Transcript', :controller => 'podcast', :action => | 7/24/08 | Free | View In iTunes |
|
22 |
4: Rails Models | To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. Resources for Further Study Any Ruby on Rails book will explain how migrations, models, and associations work. The classic Agile Web Development with Rails does a good job explaining them. Note that Rails 2.0 provides a slightly simpler syntax for migrations, which we’ve used in our examples, so in most books you’ll see the Rails 1.2 style. The Rails wiki has an explanation of migrations, but as of this writing it has not been updated for Rails 2.0. The API document provides a less readable but more complete and up-to-date description. There’s a hand-on tutorial using NetBeans 6.0 that shows how to create migrations and models using the NetBeans IDE. Code Examples The user requirements for the example we discuss in this podcast are: A visitor to the site sees a list of podcasts with their title, description, and a link to an MP3 file If there is an associated show note for that podcast, a link appears that goes to a page displaying it. Each podcast is tagged with one or more topic categories which the visitor can see next to the podcast’s other information Here’s a schematic drawing of the required objects: The migration that creates the podcast database table reads something like this: create_table "podcasts" do |t| t.string "title" t.string "description" t.string "filename" end The create_table line begins a code block that defines the table. This line provides the shortcut name t, which is referenced in the lines that define the table. To create a new podcast object, you use a very simple Podcast class and simply type: episode = Podcast.new And now you have an instance of the Podcast class, which you’ve named episode. Now, to set its attributes, you can simply write: episode.title = "Learning Ruby on Rails" episode.filename = "learningrails-1.mp3" episode.description = "This episode covers..." When this code is executed, you’ve created the episode object and filled it with data. Now it takes one more line of code, episode.save, to write the data to the database. To find an episode by name, you can simply write: episode = Podcast.find_by_title('Learning Ruby on Rails') and you’ll get back a podcast object, called episode, with all the information about that podcast. What about the show notes? We need another migration to define that table, the core of which is simply: t.text "body" t.integer "podcast_id" The body field is where we store the text of the show notes. (The column type of “text” instead of “string” tells the database to allow a potentially large amount of text.) The podcast_id field is how Rails knows what podcast a particular show_notes object is associated with. To set up the association, you add one line of code to each of the associated models’ classes. The podcast class gets a line that reads: <pre | 7/24/08 | Free | View In iTunes |
|
23 |
1: Why You Should Learn Ruby on Rails | Welcome to the Learning Rails Online Course If you’ve read this far, you probably already have an interest in building web applications with Ruby on Rails. But just in case you’re unsure if Rails is worth learning, in this lesson we explore the reasons for the success of Ruby on Rails and the benefits that can result from using it. The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes. To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails). To read a transcript of the lesson, click the Transcript link on the left. Web resources Keep in mind the distinction between Ruby and Ruby on Rails: Ruby is a programming language Ruby on Rails (often called simply “Rails”) is a framework for building web applications with Ruby The central web resources for Ruby and Rails, respectively, are: Ruby Language Ruby on Rails If you want to do some more preparation for your Ruby on Rails education, we highly recommend that you begin learning Ruby, the programming language, without regard to Rails (at first). You don’t need an extensive knowledge of Ruby, but you need to learn the basics. We’ll talk about Ruby a little more in later lessons, but you can get started now learning it on your own. If you have experience with another programming language, much of Ruby will seem very natural. If you don’t have any experience with object-oriented programming, you may want to read up on Ruby objects — in Ruby, everything is an object, and you’ll work with them constantly. Ruby uses one unusual construct, the code block, which is unfamiliar to most programmers and merits some study. Code blocks are used extensively in Rails. Ruby-lang.org has a good introductory tutorial and a longer introduction to Ruby. Ruby Essentials is a short online ebook on ruby. And for those of you who are more graphically inclined, check out Why’s Poignant Guide to Ruby, it even has foxes! You can begin experimenting with Ruby right in your browser, without having to install anything. Just browse to tryruby.hobix.com. Introductory books You need to learn about both Ruby and Rails, and you’ll want separate books for each of them. For beginning Ruby, these are both good introductory books: Learning Ruby Beginning Ruby There are several other valuable references and advanced guides for Ruby, which you’ll want to pick up if you get serious about your Ruby programming; see our Ruby bookstore for an extensive list. For learning Ruby on Rails, the current selection of books is a little problematic. Two years ago, there were only a few books; now there are dozens, which makes it more confusing to pick one. And alas, most of them are written for Rails 1.2.6, and the ones that are the most up-to-date are not well suited for beginners. Although it is not the most accessible book for a novice programmer, and is written for Rails 1.2.x, <a href="http://w | 7/24/08 | Free | View In iTunes |
| Total: 23 Episodes |
Customer Reviews
Rails makes it easy. Learning Rails makes it achievable.
I've read countless books on Rails and attended lengthy (expensive!) workshops. Maybe it's because I had already completed these measures, and maybe it's because those other resources piled on a lot more (too much?) theory, but the style by which Michael and Christopher presented this course was exceptionally clear and easy to follow. That's not to say that they don't cover theory (the first 8 sessions are audio-only and all theory). But it's done succinctly and clearly. As a simple example, their explanation of gems vs. plugins was very helpful. They approach the teaching from the student's perspective, and answer the questions I was actually thinking up as they went along. I lost count of the number of times I started laughing because of how cool and how easy it was to do something...I'm sure my wife thinks I'm a much bigger geek than I actually am. So, Rails makes it easy. Learning Rails makes it achievable.
Learning Rails
This podcast is an excellent primer for learning about Ruby and Rails, background, capabilities, etc.The authors convey thier enthusiam and knowledge on the benefits of this language well and I think it successfully accomplishes the task of getting the listener interested in learning more without relying on too much technical jargon.
A Great Way to Solidify Book Knowledge
I've gone through several Ruby and Ruby on Rails books, but nothing beats seeing it done and explained in video. These videos are an excellent resource and have helped solidify my knowledge.
Viewers also subscribed to
- The Ruby Show
- Jason Seifer and Peter Cooper
- View In iTunes
- Rubyology
- Chris Matthieu
- View In iTunes
- RailsCasts
- Ryan Bates
- View In iTunes
- RailsCasts (Mobile)
- Ryan Bates
- View In iTunes
- Free
- Category: Software How-To
- Language: English
- © Copyright 2007 Collective Knowledge Works, Inc.
