How do I learn Ruby & Rails?

This is a question I get quite a lot.

Where should I start? What should I do? What can I do to become a better Ruby/Rails developer etc.. (more common questions)

I wish there was a “simple/right” answer to these questions. Something like: “Read this book and you will become an awesome developer”. Unfortunately, things are not that simple. We are all different and we learn differently, we also come from different backgrounds.

So instead of telling you what I think is the best way to learn, I decided to ask the community. Here is a quick compilation of some of the responses I received:

What the community says:

How did you learn Ruby and/or Rails?

  • DHH DHH: I learned Ruby by programming in anger. Attempting to make something real. Not just a toy program.
  • David Black David Black: I learned ruby via pickaxe and lots of practice and both reading and answering questions on ruby-talk.
  • Evan Phoenix Evan Phoenix: reading code WHILE writing code
  • Yehuda Katz Yehuda Katz: I tried impossibly hard things to force myself to learn.
  • Laurent Sansonetti Laurent Sansonetti: I learned ruby via pickaxe, reading the posts on ruby-talk and then reading MRI’s source code
  • Ninh Bui Ninh Bui: I was quite a java fanboy back, writing struts + j2ee enterprise apps, Hongli forced me to look at Ruby over a weekend and I learned the Ruby basics. I then learned Rails by googling, reading books and source code.
  • Tim Connor Tim Connor: the rails community habit of obsessively blogging was probably the biggest help
  • Lar Van Der Jagt Lar Van Der Jagt: Ryan Bates’ railscasts for sure. The Rails Way once I knew enough to dig deeper. What I wish I’d done tho is work with experts!
  • Arun Gupta Arun Gupta: The Rails guides and Agile Development with Rails book.
  • Geoffrey Grosenbach Geoffrey Grosenbach: After I had read a few tutorials, I started by spending a few hours reading through the API docs. Even if you don’t understand everything, it’s a fantastic way to become familiar with what’s available.
  • Nate Todd Nate Todd: I learned MVC with a few CakePHP apps first. It helped me learn best practices in a language I was familiar with.
  • Chris Wanstrath Chris Wanstrath: I learned Ruby on Rails by writing apps and reading the framework’s source.

What advice would you give?

  • Bob Martens: Get involved in the community in some way. They know more than you. ;)
  • Ismael Celis: understanding the relationship between the parts of MVC. Loads of people coming to Rails don’t know what a design pattern is.
  • @jeromegn: I find the best trick to learn RoR is to simply try building something. Rails docs and learning Ruby in parallel helped me the most
  • @johnbender: knowing why instance vars are available in templates, etc. Essentially knowing the basics of ruby would be my initial advice
  • @ryandotsmith: writers read. Find popular projects on github (i.e. radiant ) and study their specs.
  • Sunil Karkera: understanding MVC in Rails was the most important thing for me when I started.
  • Luke Burton: basic screencasts showing something impressive being achieved in small amounts of code were a great start
  • DHH: Pick a real project and program in anger. That’s how I’d recommend learning any language including Rails and Ruby.
  • Anthony Green: Accept that there’s a Rails Way and you need to learn it. What helped me most ? - the community.
  • Kent Fenwick: Learn by doing a REAL project. Pick something you want to build and slowly chip away at it.
  • Trevor Turk: learn by reading and writing code… meaning you should try to build something you want instead of dumbly following tutorials…
  • Ryan Bates: Rails is made up of many technologies (HTML, CSS, Ruby, OOP, SQL, etc.). If you’re struggling with Rails, focus on weakest part.
  • Geoffrey Grosenbach: And there are many examples throughout that will help a new developer get a feel for the philosophy of Rails. Many people have learned from the Rails from Scratch series at PeepCode
  • @eifon: A good grasp of MVC is invaluable as is knowing some Ruby before you start.
  • John Yerhot: don’t be afraid to ask questions and use support channels - irc, mail list, rails bridge, etc…
  • Roy Wright: use the same version of rails as is in the book you are using.
  • @brianthecoder: read other people’s code
  • Ninh Bui: I learned by having discussions with a lot of people, I can definitely recommend that
  • Chris Wanstrath: Stop asking other people for advice and start coding something.

Different opinions but very interesting answers. I tried to compile some of what I thought were great resources that helped me and/or other people I talked to.

Never heard of Rails or Ruby, what is it?

newbie

Start by watching one of the many screencasts/presentations about Rails. Rails and software developed using Rails are written in a programming language called Ruby. If you are new to software developer, you can quickly learn Ruby and I would recommend a great book called Learn to program by Chris Pine. Ruby is a very elegant and intuitive language that you will be able to pick up quickly while learning new tricks for many years. However, don’t expect that after installing Rails, you will have a Drupal clone in Ruby. Rails is a web framework, in other words, a tool to help you write your own web application quickly and efficiently.

Tip: The Ruby website has a lot of information and resource to get started.

I hacked some PHP/Perl/ scripts but I don’t know anything about MVC or Object Oriented development:

Here it really depends on how you learn things. Are you a “How” or a “Why” person? A “How” person will learn by being shown how to do something and will then reproduce it and learn from it. A “Why” person needs to understand why things are done a certain way so they can re apply their knowledge on other challenges.

building

The good news is that Rails uses many conventions and if you pick them up, you will quickly get things done and feel rewarded by what you have done. That’s great for “How” people, but “Why” people might have to be a bit more patient and start playing with the framework before that can fully understand everything.

“How” people should definitely watch Ryan Bates’ excellent railscasts and read the Rails guides “Why” people might want to read Ruby Programming Language and The Well-Grounded Rubyist, aka Ruby for Rails 2nd edition

You should also check the Rails wiki and contribute info that might be potentially missing. (If you have a problem that is not covered/discussed in the wiki, try to solve it and then post your solution. If you come across the same problem at a later time, you will be able to quickly find how you solved it. By contributing, you will also save other developers’ time.)

Start reading Ruby/Rails related blogs, subscribe to rubyinside RSS feed and visit your local Ruby group.

Tip: Start a blog and keep track of what you learned. That will help you and other people facing the same challenges

I started writing a Rails app but I feel limited by my knowledge of the framework and the language

That’s a normal stage, don’t give up! Here are a couple of great reads: The Ruby Way and The Rails Way. the Ruby Way should satisfy primarily the “why” people, while the Rails way should primarily please the “how” people. I’d recommend to read both. Don’t hesitate to ask questions, check google, use twitter, blog comments, mailing lists. Try to find some local rubyists to share knowledge with. Pick a topic you would like to know better and prepare a talk for your friends/local Ruby group or write a blog post about it. One thing for sure, don’t be ashamed or discouraged. Persevere, it’s worth it (or get out, relax for a while, and then come back and give it another go).

hacking

A good way to improve your Ruby/Rails skills is to look at other people’s code. Check GitHub and see how people have solved the same problems you are facing. You can also attend a Ruby/Rails training, a lot of companies offer classes around the world. RailsBridge is trying to reach out to people aspiring to become better developer, check their site.

Tip: I often use apiDock when I’m looking for documentation on a method/class.

I wrote a Rails app, I adopted and understood the Rails conventions and I feel comfortable writing new apps.

party dog

Congratulations, you should be proud of what you have accomplished! But don’t stop learning! Did you write tests for your application? Do your tests really test your application, or are they just there to make you feel better (i.e: change your code, are your tests still passing? they shouldn’t)? Do you use plugins? Did you look at their code? Do you understand how they work? Could you write your own plugin? What about a Ruby gem? Also, how are your javascript skills? What about CSS and DBA stuff? focus on your weaknesses.

I would strongly suggest contributing code at this point. Contribute a patch to one of the many GitHub projects, or even Rails, you will learn a lot!

Tip: Check out Gregg Pollack’s Scaling Rails series

I wrote a couple of Rails app, I even wrote a plugin/gem.

That’s great, by now you probably are very familiar with Rails and Ruby. You might want to dive in a bit deeper. Maybe check how to wisely use metaprogramming and/or check on how to write C/FFI extensions. Why not look at Ruby’s source code to learn how things really work?

strength

It’s also probably a good time for you to start learning new languages to see how other communities do things. Look at other frameworks and try to understand how and why people chose other conventions/ways. Play with Python, Java, Scala, Clojure, Objective-C, Ocaml, Scheme or whatever language sounds interesting to you. You don’t have to master other languages, but you should try to understand the reasoning behind each approach and understand the pros/cons. It will honestly help your Ruby skills and broaden your horizons.

Tip: Prepare a couple of talks and send proposals to various conferences. (Don’t limit yourself to Ruby conferences)

I know Ruby and Rails like nobody else, I could even quote Rails and MRI’s source code by heart. (just ask a LOC)

Then I hope you are helping with the Ruby 1.9 efforts, contributing code to other implementations (IronRuby, JRuby, MacRuby, Rubinius) and helping with Rails 3 :)


If you are reading this post, you are probably in one of the above categories. Pairing and tutoring are great ways to learn, it’s all about karma. Helping others will help you becoming a better developer. Feel free to leave advise, links and info in the comments.

Community Highlights: Yehuda Katz

Over the past few months, Rails core team member Yehuda Katz has posted a series of great blog articles describing some of the process and technique he’s used while coding Rails 3 with Carl Lerche. In case you haven’t followed his blog posts, I thought I’d repost them here for your educational reading.

Rails 3: The Great Decoupling
is about decoupling components like ActionController and ActionView.

New Rails Isolation Testing
is about the creation of a new test mixin that runs each test case in its own process.

6 Steps to Refactoring Rails
is about the refactoring philosophy he’s using when coding Rails 3.

Rails Edge Architecture
is about Rails 3 Architecture including AbstractController::Base & ActionController::Http

Better Module Organization
is about cleaning up the way modules are included.

alias_method_chain in models
is about alternatives to using alias_method_chain, some of which made it into Rails 3 refactorings.

Rails 3 Extension API
is where on the new wiki Yehuda has started documenting the new extension APIs which are being added for Rails 3. There’s not a whole lot there yet, but be sure to watch this space in the coming weeks.

Rails BugMash

Some of you may remember the Rails Hackfests that were conducted in 2007 and 2008. Well, with some help from the RailsBridge folks, we’re bringing back something similar :

The First Rails and RailsBridge BugMash

The idea is simple: RailsBridge has a lot of energy. The Rails Lighthouse has a lot of open tickets. By combining the RailsBridge enthusiasm with guidance from some Rails Core team members, we’re going to see what we can do to cut down the number of open tickets, encourage more people to get involved with the Rails source, and have some fun.

Here’s how it will work: the BugMash will run over the weekend of August 8-9. The Rails team will identify open issues that need some help and tag them in Lighthouse. Participants will draw from this pool with four goals:

  1. Confirm that the bug can be reproduced
  2. If it can’t be reproduced, try to figure out what information would make it possible to reproduced
  3. If it can be reproduced, add the missing pieces: better repro instructions, a failing patch, and/or a patch that applies cleanly to the current Rails source
  4. Bring promising tickets to the attention of the Core team

RailsBridge is organizing both face-to-face and online support for BugMash participants. The plan is to do everything possible to make it easy to start contributing to Rails, and to increase even further the substantial pool of developers who have helped make Rails what it is.

For more details, including a checklist of what you can do to get ready to work in the Rails source and details on a scoring system and rewards for the most active participants, keep an eye on the RailsBridge Wiki (a work in progress). For now, though, there are two things for you to do:

  1. Reserve at least a chunk of that weekend to roll up your sleeves and work on the BugMash
  2. Speak up by updating the wiki or posting on the mailing lists ( rubyonrails-core or railsbridge ) if you can contribute prizes, familiarity with the Rails source, or other help to the project.

Rails 2.3.3: Touching, faster JSON, bug fixes

We’ve released Ruby on Rails version 2.3.3. This release fixes a lot of bugs and introduces a handful of new features.

Active Record

  • touch is a convenient method to update a record’s timestamp and nothing else. This is extracted from apps whose models “touch” others when they change, such as a comment updating the parent.replies_changed_at timestamp after save and destroy. Timestamping an entire has_many association makes it easy to build a key for fragment caching that covers changes to the parent object and any of its children. This pattern is wrapped up as belongs_to :parent, :touch => :replies_changed_at. When the child changes, parent.replies_changed_at is touched. :touch => true is defaults to :touch => :updated_at.
  • :primary_key option for belongs_to for broader support of legacy schemas and those using a separate UUID primary key: belongs_to :employee, :primary_key => 'SSN', :foreign_key => 'EMPID' changeset

JSON

  • decoding backends for the json and yajl libraries. Both are significantly faster than the default YAML backend. To get started, install the json gem and set ActiveSupport::JSON.backend = 'JSONGem'.
  • leaner user-facing encoding API. Since a JSON libraries implement to_json with varying compatibility, safely overriding it is difficult. Most custom to_json looks like
    
    def to_json(*encoder_specific_args)
      { :some => "json representation" }.to_json(*encoder_specific_args)
    end
    so we DRYed the user-facing API down to a more natural
    
    def as_json(options = {})
      { :some => "json representation" }
    end
    without the ugly internal state exposed by overloading to_json as both public-facing and internal builder API. Rails 3 splits the API explicitly, so prepare now by switching from to_json to as_json.

Other Features

  • Add :concat option to asset tag helpers to force concatenation. changeset
  • Restore backwards compatibility for AR::Base#to_xml. changeset
  • Move from BlueCloth to Markdown for the markdown helper. Users using BlueCloth to provide their markdown functionality should upgrade to version 1.0.1 or 2.0.5 in order to restore compatibility.

Notable Bug Fixes

  • Fix errors caused by class-reloading with streaming responses in development mode.
  • Several fixes to the gem bundling, unpacking and installing system.
  • Make text_area_tag escape contents by default.
  • Make filter_parameters work correctly with array parameters.
  • Thread-safety fixes for postgresql string quoting.
  • Performance fixes for large response bodies.

Remaining Ruby & Rails Conferences in 09

The Ruby and Rails community is still growing strong and the sheer number of conferences coming up is proof of that. Below I’ve put together a list of all the conferences/events I could find before 2010 so you can hopefully make it out to at least one. ;-)

If you do attend one of these conferences, do me a favor and thank the organizer for taking the time to produce the event. Most of them spend a great deal of unpaid time making the event happen and most of them aren’t making a profit. Their passion and hard work helps keep our community strong.

Jul 17 – Jul 20 Rails Camp in Bryant Pond, Maine.

Cost: $120

Jul 17 – Jul 19 Ruby Kaigi 2009 in Tokyo, Japan.

Cost: Sold Out

Jul 24 – Jul 25 Rails Underground in London, UK

Cost: £240

Jul 31 – Aug 1 Rails Outreach Workshop for Women in San Francisco, CA

Cost: FREE

Jul 30 – Aug 1 RubyRx in Philadelphia, PA

Cost: $550

Aug 7 – Aug 9 eRubyCon in Columbus, OH

Cost: $299.00

Sep 10 – Sep 11 Ruby Rx in Washington DC

Cost: $550

Aug 7 – Aug 8 Oxente Rails in Natal, Brazil

Cost: R$ 200,00

Aug 27 – Aug 29 Lone Star Ruby Conf in Austin, TX

Cost: $250

Aug 28 – Aug 29 Ruby Hoedown in Nashville, TN

Cost: FREE

Aug 29 RS on Rails in Porto Alegre, Brazil Cost

Cost: R$50

Sep 1 – Sep 2 Rails Konferenz in Frankfurt, Germany

Cost: €215

Sep 7 – Sep 8 RubyWorld Conference in Matsue, Japan

Cost: ¥5000

Sep 12 Windy City Rails in Chicago, Il

Cost: $99

Sep 26 – Sep 27 Central eUropean RUby camp in Wien, Austria

Cost: Free

Oct 2 – Oct 3 Ruby Foo in London, UK

Cost: £ 220

Oct 5 – Oct 6 Aloha on Rails in Waikiki, HI

Cost: $199

Oct 13 – Oct 14 Rails Summit Latin America in São Paulo, Brazil

Cost: R$ 400

Oct 16 – Oct 19 Rails Camp UK in Margate, UK

Cost: £50

Oct 16 ArrrrCamp in Ghent, Belgium

Cost: Free

Nov 7 – Nov 8 Rupy 2009 in Poznań, Poland

Cost: ? (registration not open yet)

Nov 13- Nov 14 Conferencia Rails in Madrid, Spain

Cost: ?

Nov 19 – Nov 21 Rubyconf in San Francisco, CA

Cost: ? (registration not open yet)

Nov 20 – Nov 23 Rails Camp Australia in Melbourne, Australia

Cost: $180

Let me know if I forgot any events, I’ll be happy to add them to this list.

Community Highlights: Rails Prescriptions

Doing Test Driven Development (TDD) effectively is not something that comes easy, even when you’re working with a well structured Rails application. Up until March of this year there really was no guide I could recommend for developers who wanted to learn TDD with Rails.

What happened in March? Noel Rappin released his Rails Test Prescriptions PDF guide. You can start out by reading his FREE 84 page Getting Started With Rails Testing PDF Guide, and then maybe upgrade to his $9 dollar 286 page guide which covers advanced topics like creating Test helpers, stubbing, mocking, and even how to use factories, shoulda, rspec, and cucumber.

Noel is a great teacher providing examples that are really easy to follow and code downloads if you want to try writing tests on your own. So if you’re not doing testing yet or you want to learn some best practices, definitely check out Rails Prescriptions.

It’s also worth mentioning that Noel has posted some pretty interesting blog posts on the Rails Prescriptions Blog going over a few testing topics and even some testing interviews with developers like Chad Fowler, James Golick, Ryan Bates, and Mike Gunderloy. Lastly I can’t talk about Noel without mentioning his contributions to the Pathfinder blog, I’m a big fan of his blog posts.

Minor Changes to the Rails Security Policy

After reviewing the feedback on the two recent security announcements we’ve made a few minor changes to the Ruby on Rails security policy.

The first change we’ve made is to include more information on what to do if you don’t receive a response from the security team. In general reports to the security address should receive a response within 24 hours, however the sheer volume of spam to the address can, and has, lead to messages being caught in spam filters. In the event you don’t receive a response there are now two direct-emails to the people currently looking after security reports. That page will be kept up to date as responsibilities are reassigned.

The second change is to more clearly outline the announcement policy for rails vulnerabilities. In short, we notify vendor-sec ahead of the public notification to allow time for people distributing rails to prepare packages for their distributions. Then when the time has come for public notification an email is sent to the security announcement list. Finally the announcement is posted to this blog.

The security announcement list is extremely low volume and you’re strongly suggested to subscribe to it. This is the place which receives the first public announcements of all vulnerabilities in Rails, and also tends to receive additional notifications about vulnerabilities in ruby itself. We’ve been using this list for several years but judging by confusion and misinformed comments following the announcement of CVE-2009-1904, not enough people were aware of its existence.

If you have any comments on the security policy, please send them via email to security@rubyonrails.org.

Community Highlights: Ruby Heroes

This week I’m happy to tell you about a new set of articles which will be appearing here on the Rails blog called “Community Highlights”. This new series will feature people/projects/sites from the Rails community that may deserve a little extra recognition.

This week, we’re going to start with a few people who received awards on stage at Railsconf 2009, this years Ruby Heroes.

Brian Helmkamp


Brian has been a contributing member of the Ruby community for 4 years now, but is most well known for his testing library Webrat. He’s a contributer to Rails, RSpec, Rubinius, and is a co-author on the recent RSpec Book. More recently he’s been helping out the Rails core team with Rack:Test, and Rack:Debug.

His Blog: http://www.brynary.com/
Twitter: brynary

Aman Gupta


Aman has taken over the maintenance, new features, and the recent releases of EventMachine, which is an invaluable tool for writing fast ruby applications. He’s also the author behind amqp & xmpp4em gems which are deployed far and wide.

Github: http://github.com/tmm1
Twitter: tmm1

Luis Lavena


Luis has done a lot for the Ruby community in Argentina, but he’s most well known in our community for the work he’s done for windows users maintaining the One-Click Ruby Installer. Recently he’s put up a Plegie to help get the windows installer a new home.

His Blog: http://blog.mmediasys.com/
Twitter: luislavena

Pat Allan


Pat is the mastermind behind Thinking Sphinx which has become a standard when it comes to full-text search in Rails. He is also the author of the excellent Thinking Sphinx PDF book and one of the founders of Railscamp, where I hear he makes some killer pancakes.

His Blog: http://freelancing-gods.com/
Twitter: Pat

Dan Kubb


Dan been tirelessly working on one of the hardest Ruby projects around, DataMapper. He became the official maintainer after Sam Smoot and since then has completely rewritten the test suite to give DataMapper better coverage, has come up with a viable path to completion, and is currently working on making sure DataMapper works great with Rails 3.

Github: http://github.com/dkubb
Twitter: dkubb

John Nunemaker


Although John Nunemaker has released several widely used open source libraries, like HTTParty and HappyMapper, his main contribution in my opinion comes from his blog Rails Tips. Over the past year he’s written an incredible number educational blog posts on many Ruby and Rails topics.

RailsTips: http://railstips.org/
Twitter: jnunemaker

Those are your six Ruby Hero’s for 2009. If you’re interested you can also watch a video of the award ceremony which talks more about the methodology about how they were chosen and see 5 of these guys receive their awards on stage at Railsconf 2009.

DoS Vulnerability in Ruby

A Denial of Service vulnerability has been found and fixed in ruby. The vulnerability is due to the BigDecimal method mishandling certain large input values and can cause the interpreter to crash. This could be used by an attacker to crash any ruby program which creates BigDecimal objects based on user input, including almost every Rails application. This vulnerability has been assigned the CVE name CVE-2009-1904.

For upgrade instructions and information on affected ruby versions please see the ruby security team’s announcement.

All users are advised to upgrade their ruby installations immediately to avoid this problem. In the event that you are unable to upgrade your ruby installation, or are using an out-of-maintenance ruby version, there is a workaround available on github. You can either install it as a gem, or simply copy the file bigdecimal-segfault-fix.rb into config/initializers of your rails application.

NOTE: this workaround breaks valid formats supported by BigDecimal, users should not rely on this fix for an extended period of time but should instead immediately begin planning a migration to a supported ruby release.

The upcoming Rails 2.3.3 release will include some minor mitigating changes to reduce some potential attack vectors for this vulnerability. However these mitigations will not close every potential method of attack and users should still upgrade their ruby installation as soon as possible.

Thanks to Jose Fernández for reporting the vulnerability to the rails security team, and to the ruby security team for confirming the nature of the bug and handling the release process.

Security Problem with authenticate_with_http_digest

A security problem has been reported with the digest authentication code in Ruby on Rails. This vulnerability can allow users to bypass your password protection. This vulnerability has been publicly disclosed on several websites, users are advised to take the mitigating steps described below immediately.

The issue comes from the handling of the block passed to authenticate_or_request_with_http_digest. This block must return the user’s password in the clear, or a sha1 hash of the user’s password. Unfortunately the documentation was unclear on this and the examples cited would return nil if the user was not found. The correct behaviour if the user doesn’t exist is to return false.

If the return value was nil, rails proceeded to verify this value against the provided password. Because of this an attacker can provide an invalid username and no password and authentication will succeed.

Fixed Versions

We have altered the behaviour of the relevant code to make nil an authentication failure. This fix has been pushed to 2-3-stable and will be present in 2.3.3 due to be released in the next few days. All versions of edge rails after commit 1ad57cfe2fbda58439e4b7f84008ad23bc68e8b0 contain the fix.

Steps to Protect your application.

Users can protect themselves without upgrading by simply ensuring that their authentication blocks never return nil. To take an example from the documentation:

authenticate_or_request_with_http_digest(REALM) do |username| USERS[username] end

Should instead be something like:

authenticate_or_request_with_http_digest(REALM) do |username| USERS[username] || false end

Disclosure Notes

Due to communication difficulties and a mis-understanding between the reporter and the security team. This vulnerability has been publicly disclosed on several websites, users are advised to update their applications immediately. Steps are being taken to ensure that the security email is more reliable in the future. We regret the nature of this disclosure and will endeavor to ensure it doesn’t happen again in the future.