Wednesday, December 9, 2009

Getting Started with Rails

I was asked today what resources I would recommend for getting started with Rails.

Firstly, learn some Ruby. Ruby is a very deep language with a lot of really cool stuff you can do to get the most out of it. You can really make a choice here between learning a lot of Ruby straight away or just learning enough that you can start tinkering in rails. You could easily create an entire Rails application without touching any of the metaprogramming tricks or fancy shortcuts that Ruby provides, it is way cooler if you do use them though.

There are, of course, docs pages for both Ruby and available for day to day use but they're not exactly learning tools. So I'll take the time to describe some of the more explanatory resources available.

Learning Ruby

A good first look is Ruby in 20 minutes.

After that you can try and dive into rails and rely on docs or, if you want a lot more depth in your exposure to ruby, then Programming Ruby by the Pragmatic Programmers(affectionately known as the pickaxe due to its cover) is a very good bet. It has nearly everything you'll ever need to know and is a good read.

Learning Rails

The Pragmatic Programmers also publish what is essentially the definitive introduction to Rails. Agile Web Development With Rails is now in its third edition and reading it cover to cover would not be time wasted.

A second, and free, resource for rails developers are the Rails Guides a collection of detailed guides to most of the major parts of Rails. They're maintained well, although often checking the "edge" version of the guides is necessary to find ones that are currently in draft state. If you can't get your hands on the book, then the guides are probably the best replacement.

The other major area to pick up on before calling yourself a Rails developer is testing. The tradition in the Ruby and Rails community is to test as much as possible. While Rails comes with test::unit, a test framework called Rspec has become the dominant framework in community and is worth taking the time to learn sooner rather than later if you intend to stick with Rails, the website has reasonably easy to follow introductory guides. Cucumber is another testing system that is often used in conjunction with Rspec to create a wider range of tests, you can afford to leave it out for longer though although it is worth learning about(and using) eventually.

Broadening and Maintaining Your Skills

A number of very good alternative resources have sprung up for rails, one of the best is Railscasts. Which, at the time of writing, has nearly 200 detailed videos available for free regarding a variety of Rails related topics. If you're having trouble with a particular aspect of rails then check if there is a video available on Railscasts.

Peepcode do some very nice longer Rails videos on important topics and are well worth a look, although they charge for the videos so it's worth having a clear idea of what you want to know about.

Ruby5 is a convenient podcast for keeping up with Ruby and Rails related news. Although, it's often easier just to check the topics listed on the website rather than spend the time listening to the podcast itself.

IRC channels can mostly be found on freenode with #rubyonrails having a significant pool of people who alternate between happy and grumpy at an exciting pace. #railsbrain also features good people and is likely to be friendlier to newcomers.

There is also a significant pile of blogs related to Rails floating around they're generally pretty easy to find and the best posts will generally float to the surface. At the same time it's good to be cautious of any blog posts that Google finds you as Rails has moved a lot in the last few years and many of the blog posts it finds are no longer relevant.

Hopefully these resources can put you on your way to being a Rails developer.

Sunday, December 6, 2009

Scrum Introduction at RailsCamp

I did end up giving a talk at RailsCamp on Scrum. I'd had a few conversations about client management the previous day so I pitched it at a reasonably introductory level. The audience that showed up was probably about half familiar with scrum and half not. I think we got through a pretty good overview of the Scrum process and the experienced folks caused a lot of really interesting discussion.

View more presentations from breccan.

During the talk estimating/sprint size and client trust became a significant part of the discussion. A number of people had issues with picking an amount of work and suggesting that that amount of work should be concrete for the sprint. I mentioned a few ways of minimising or accepting this and there are probably many other methods:

  • Set stretch targets at sprint planning by putting some targets in the sprint at the bottom of the sprint backlog. This way there's something to do if you run out, they should only be done if you really finish the other tasks and there's no penalty for not reaching them.
  • Regardless of having slightly less work, there's almost always something else for developers to be doing. From refactoring time to working on side projects there's never likely to be a shortage of work.
  • Clients are going to be happy with consistent work and meeting the goals they've started with. If velocity needs to change that should be worked out before the sprint.
  • Developers are most likely going to be happier if rules agreed on at the beginning of the process are kept throughout, changing things at odd times is likely to have odd flow on effects.
  • Any change to these rules can be easily addressed according to team desires during the retrospectives and planning for the next sprint.
My general belief is that by maintaining consistency in process and methods, clients and teams will have a more comfortable feel for what's happening in the project. All parties are likely to trust each other more. Parties that trust each other(where the trust is justified) are more productive than groups that are trying work everything through an adversarial state of requirements and contract negotiation. Scrum occupies a similar position in development to manners in general society by allowing people to have a set of behaviours that allow for smooth communication without intimate knowledge of each other.

The talk also spawned a talk on Kanban a project management system with some interesting properties that I might blog about sometime(it also has inbuilt support in cucumber).

Wednesday, December 2, 2009