The screencasts and pictures don't lie. It is easy to learn Rails and quickly become productive. However, the dirty little secret is that it's very hard to be come an expert at utilizing Rails.
Anatomy of a Rails Web 2.0 Application
Rails provides many helpers that make your life easy. But, you can't entirely hide the fact that you'll need to be proficient with Ruby, JavaScript, YAML, and SQL. Just like Rails, getting started with any of the above languages is easy, it's mastering them that takes time and effort.
Becoming an expert with each of the above languages involves gaining knowledge and becoming proficient with several aspects of the language.
Development Environment
There's no IDE that can provide all the features you'd like for Ruby, JavaScript, YAML, and SQL. Some are (hopefully) on the way, but they still suffer from speed, feature, and stability issues. That generally means is you'll have two options:
- Find a productive development environment that specializes in one or two of them and use a different IDE/Text Editor for each language
- Find an editor that provides decent support for all of them.
Language Features
Look for documentation and try out the examples for each language you are looking to master. Ruby has decent documentation on http://www.ruby-doc.org/. YAML documentation can be found on http://www.yaml.org/. JavaScript and SQL have seemingly endless documentation resources. I've always been a fan of the O'Reilly books, so I'd recommend Safari Books Online, but there's plenty of other options if you'd like.
But, don't stop with reading. Reading documentation and trying examples isn't going to bring you to the expert level. Another great way to get some insight into a language is to look at the successful frameworks and see how they are implemented. Browsing the Rails codebase should provide examples of almost every feature available in Ruby. Likewise, understanding the Prototype and Script.aculo.us libraries should greatly improve your JavaScript skills.
Testing
Testing is valuable in any language. Ruby provides a few different testing solutions, but the most popular are still Test::Unit and RSpec. JavaScript also provides several options for testing. I can't say there's a clear winner, but JsUnit and Crosscheck seem to be gaining momentum. As far as testing SQL and YAML, I generally functionally test them through Ruby. Additionally, Selenium is a great resource for acceptance testing Rails applications.
Frameworks
Both Ruby and JavaScript provide a plethora of framework options. Ruby provides RubyGems for distributing shared Ruby code. RubyGems are frameworks that can provide all kinds of building blocks for creating applications. In the past I've used the Prototype and Scriptaculous JavaScript libraries, but my current team is enjoying using JQuery.
Debugging
Debugging Ruby is a bit primitive these days. The simplest form of debugging is printing to standard out. You can roll your own simple debugging solution also. Additionally, ruby-debug looks promising. None of the solutions are great, so it's good to have all 3 tools at your disposal. For JavaScript debugging I suggest getting proficient with FireBug. SQL debugging solutions are generally vendor specific, check the docs of the database that you choose for a good suggestion. YAML doesn't generally require a debugger since most errors simply result in parsing problems.
What else makes Rails difficult to master?
Mastering languages is important, but it's not enough to run a high traffic Rails application. You'll still need to understand performance optimization and deployment strategies. There's an abundance of Rails production heuristics available, but little of it is well documented. I'd suggest reading the following blogs: Brainspl.at, Err the Blog, and RailsExpress. Beyond those blogs the web provides several other resources. A Google search should provide more than enough reference material.
That's a ton to learn
It's true, that is a lot of information to digest. But, experts aren't made overnight. The good news is, you can get started very easily and expand your knowledge as needed. There is a large amount of information available, but don't feel overwhelmed: The majority of the information is very straightforward. Becoming an expert with Rails takes time more than anything else.
Great intro post.
ReplyDeleteAs a long-time programmer who's been "new to Rails" for 2.5 years now, here are the things that trip me up the most:
* Like most Ruby DSLs, most of the action in Rails is happening in an anonymous, yielded block, not in a classic object/method. So if I'm doing anything beyond the basics, I find it tough to understand "where I am" in Rails. That, in turn, makes it difficult to set up the appropriate context in a unit test - doubly so in RSpec, where there are fewer working examples I can cargo-cult (er, I mean cut-and-paste). Even "simple" things like FormBuilders took me on a long trip through ActionPack.
* The internals documentation is still in its infancy. We know that, there are projects to improve that, we've donated money to writers, and Jamis has written many cool articles on his blog - but the code is changing faster than the docs. So the best way to understand what Rails is really doing is to look at the source, which leads back to "anonymous yielded blocks" above - as well as the not-yet-ripe debugger support you mention.
* Relatedly: Rails logging is very simplistic. Everything goes to one big out file; there's no pervasive concept of log levels, categories, etc. Rails will work with log4r, but it doesn't take advantage of it. Ideally, Rails logging would work more like sendmail debug levels, where you can log the heck out of any portion of the code you need to follow by setting a flag. Someday...
Workaround: If you freeze Rails to your application, and you're using SVN, it's really trivial to add lots of "pp" statements, bounce the server, and see what Rails is doing. (Little-known fact: "put", "p" and "pp" do work in Rails, and output to the mongrel or webrick console.) When you're done, svn revert to erase all your inspect statements.
* It's too easy to try to force-fit everything into the MVC framework. Some objects are still just objects, and belong in lib. If it's not part of your model, don't squeeze it into your model.
* Rails doesn't like value objects. It pretends it does, with composed_of, but there's no clean way to say "this model has an address", and then somewhere else define "an address is an object that represents itself like so in the database"; the primitive types are magic in ActiveRecord, and anything else needs to be composed_of. There's talk on rails-core of adding a true "column" object to ActiveRecord that would enable things like that, so maybe someday.
* ActiveRecord doesn't encourage thinking about concurrency and atomicity. It doesn't prevent it, but by default, nothing's locked, everything's cached (but not by object ID) and stateless, and an awful lot of things just won't work the way you expect if two people - or even two parts of your code - modify the same records at the same time. There are really, really good reasons for it to work like this; the vast majority of apps, and Rails apps especially, don't need the overhead. But it's something you have to keep in mind, and Rails makes it easy to forget, because everything else works like magic.
Plug - I'm actually planning to start a blog at http://www.nothingeverworks.com, detailing the day-by-day roadblocks I run into trying to learn and use Rails, and open-source tools in general, while making sure to contribute back to the community in the form of bug fixes and patches whenever possible. The philosophy: dive into the rathole and come out the other end. The status: Well, I had this problem upgrading MovableType, and then I started digging deeper into Perl, and then I decided to try to find a TextMate clone for Windows so I could better edit Perl and Textile, and then...
Using spell check is easy. Choosing the correct work in spell check is Hard.
ReplyDelete"Learing Rails" or "Learning Rails"?
Chris
Learning is what I was looking for. Too many pints in London it seems.
ReplyDeleteCheers, Jay
Great article, good guide lines, thanks :)
ReplyDeleteGreat post. I hope to see more of these in the future!
ReplyDeleteI also bought this Rails Code Review PDF from peepcode and I must say it's tremendous (unless you are on the master level already...)
Keep these posts coming!
Part of my Rails reading list:
ReplyDeletehttp://blog.webinforem.com/category/rails/
http://cfis.savagexi.com/articles/category/rails
http://cfis.savagexi.com/articles/2007/09/21/alias_method_chain
Have you looked at Selenium on Rails at all? It integrates and simplifies testing of Rails apps using Selenium. I wrote a lengthy post about it here: http://citechnology.blogspot.com/2007/09/getting-started-writing-dsls-using.html
ReplyDelete