Limit your use of plugins, wrappers, and gems (at first):
When I first started out on rails one of the first things I experimented with was connections with other services such as flickr and twitter. I also played around with a lot of javascript tools like the rich text editor plugin tinyMCE. The nice thing about Rails is that you can usually find a wrapper, gem, or plugin that encapsulates these tools and services nicely and makes it easy to implement them use ruby and rails-like syntax. If they are written well, they can save you a lot of time and keep your code looking clean and consistent. However, when you're first starting out with Rails and web development in general, overuse of these tools may prevent you from learning about how they work. For instance, the TinyMCE Rails plugin made it easy for me to get text editing on my forms, but it made it difficult for me to refer to documentation and forum posts about TinyMCE because the javascript was hidden from me. Therefore, if I wanted to change options, debug problems, or upgrade to newer versions of TinyMCE I was at the mercy of the plugin.
Once I ditched it and decided to implement TinyMCE the traditional way, it all became clear. Sure, javascript isn't as elegant as Ruby but knowing how it works is an absolutely essential skill for all developers. I made heavy use of gems that helped me connect up to services like Twitter and Flickr too, but it wasn't until later that I dug into the gem code itself to find out that they used gems like Hpricot to interact with these APIs and that it wasn't actually as complicated as I had originally assumed. Often I'd run into limitations in functionality with these gems as well which eventually forced me to learn how they worked and patch them accordingly. Had I went through the motions of rolling my own connection to these API's I would have learned a lot more. I'm not suggesting you stay away from gems and plugins by any means. When you are first starting to learn web development, though, it's important that you understand the underlying mechanics of the tools you use. The time savings will come later when you can use them with the knowledge about how they actually work.
Make a habit out of testing immediately:
If I could go back in time and tell myself one thing about Rails when I was first starting to learn it this would be it: "learn how to write tests and then make sure you write tests for each piece of functionality in your code before you write that code." This one line of advice would've saved me hundreds of hours of debugging and refactoring pain. I now use behavior driven development when I work on projects, but in the beginning I basically ignored testing altogether. In another post I placed the blame on the venerable "Agile Web Development with Ruby on Rails" in a misplaced blame I refuse to retract. My reasoning is that testing is a chapter that is introduced at the end of the sample "Depot" app tutorial rather than the beginning where test driven development would demand. Because I was so excited to start building apps in Rails I didn't even reach that chapter before I was waste deep in brittle Rails code.
Here is an excellent presentation on getting started with behavior driven development. He uses RSpec, I use shoulda, but it's all good.
Learn the basics of javascript and prototype
One of the most rewarding features of rails, at least to me, were the prototype helpers like link_to_remote and the lot. I could introduce ajax into my apps with little-to-no effort, but I had no idea what was going on under the hood. It all just worked. Now that I've since started to dive into the worlds of javascript and prototype I understand just why it's so powerful and can create any custom effect, widget, or tool I need, but this knowledge would have been a lot more useful early on. It's a bit of a paradox that Rails is so easy to use because if you're entering the world of web development through Rails you can do a great many powerful things with little effort but you are limited later on when you want to go beyond the magic of Rails because you were saved having to learn the underpinnings in the first place. This is not an indictment of Rails, however, because had it not been so easy and intuitive I may have given up on trying to become a web developer in the first place, so in that respect Rails is a fantastic beginner's framework. Most Rails developers move to the framework from somewhere else, often after years of experience using those other tools, so I doubt that these same concerns come up very much in the Rails Community.
Learn something new about Ruby the language every day
I believe no greater benefit to your Rails development skills can be had than by learning how to become a better at the Ruby language itself. Rails helpers are nice, but the time and space savings you can get with various ruby tricks out there are incomparable. This bit of advice may seem obvious, but it's easy to forget that at it's core Rails is a Ruby program. PHP developers only have one language to deal with for their framework, so any tricks they learn are solely applicable in the realm of web development. Ruby is used for much more than just Rails, however, and it pays to understand just exactly what makes it so powerful and popular. I did of course regularly refer to the Ruby docs online when I needed to remind myself about Array methods and the sort, but rarely did I pick up a book that was dedicated solely to the teaching of Ruby techniques. These days I'm hungrier than ever for more Ruby knowledge because I know just how effectively it can help me write better Rails apps and re-factor old ones. For instance, the other day I learned about the "constantize" method and it allowed me to re-factor one of my applications down to literally 1/5 the amount of code I had previously written. The Pickaxe is the defacto resource for learning about Ruby.
Join a Ruby or Ruby on Rails users group
This was something that I have no excuse for having not taken advantage of earlier on because my brother had prodded me to do this from the beginning. Once I finally did join the MN Ruby Users group I instantly realized why he had. If I have a question about Ruby, or Rails, or anything programming related for that matter, regardless of how trivial or elementary it is, I'm guaranteed at least 2-3 good answers from the mailing list. I can also find out about the hottest trends in Rails development and make sure I'm not being left in the dust with old technologies and tools.
Use "debugger" in run time
I'm not sure how this one fell off the radar for me, but I at some point had glossed over the fact that Rails had a debugging mode that allowed you to jump into your app at runtime in the console. I shudder to think about all the times I debugged some Rails code by throwing variable outputs into their respective views. Of course, had I been testing from the get-go I may not have needed to use this much at all in the first place, but that's neither here nor there. For those of you just starting with Rails development, put "debugger" in your code to define a break point, run your server with "script/server --debugger" and you should be able to interact with your app through the console at those points.
Rake + Cron
One of my first endeavors in Ruby on Rails was to create the ever flogged-to-death "lifestream" app - something that pulls in all your activities from social services like flickr, last.fm, twitter, digg, etc. and organizes them into a chronological feed. While building this, I ran into the ever present problem of performance. The bottleneck wasn't from Rails, mind you, but from the API's I was connecting up to. Trying to generate a feed of all your social activities by asking for this information at render time is a recipe for disaster. Timeout errors abound and after many weeks of frustration I finally discovered that this information gathering process could be offloaded to a cron job accessing a rake file, essentially a script that runs on a schedule you set. Rake files are great because they load up your entire Rails environment to interact with. I now use cron jobs and rake files for a vast number of applications, both for personal and client projects, and it's something every beginner should know about from the outset. Here's a great guide on how to get up and running with your own rake files and cron jobs. Here's the guide I used to get started.
Don't reinvent the wheel
Chances are, if you need a piece of functionality in a Rails app, it's probably already been written and a heck of a lot better than you'd write it on your first go. For years I was using the authentication code from the AWDwRoR book which was ok but nowhere on the same level as the restful_authentication plugin that handles nearly every detail you can think of. To my point above, it's important that dive into these plugins and understand the basics of how they work under the hood, but it makes no sense to roll your own when better stuff exists out there.
I'm sure there's more and I'll add it if I think of any but these are the big ones I can think of right now. To close, I'll post some links to some excellent resources for new and seasoned Rails developers.
http://guides.rubyonrails.org/
http://railscasts.com
http://peepcode.com
http://pragprog.com/screencasts
http://ryandaigle.com/
