Rails Programmer Worth His Salt

You've probably heard the phrase before... maybe even used it. What I
want to know is what does it mean to you? What should a professional
rails programmer know? I'm going to spend the next 6 months learn
Rails in depth and I want to prioritize what I learn.

Here are some things that have come to mind so far that I want to
learn:

    * Shopping Cart + Checkout
    * Substruct
    * Subversion
    * Capistrano
    * Attachment_fu
    * Caching
          o MemCache
          o Page Caching
          o Fragment Caching
    * ActiveMerchant
    * Acts as paranoid
    * RSpec
    * Git
    * Action Mailer
    * RJS
          o Prototype
          o Effects
          o Scriptaculous
    * subdomains as account + payment plans
    * SSL
    * Acts as taggable
    * Authentication
          o Restful Authentication
          o Role-based authentication
          o Open ID authentication
    * Testing
          o Unit
          o Functional
    * Design
          o Lightbox helper
          o Redbox
          o Creating helpers
    * Flex + Rails
    * Flash Charts
    * RMagick
    * Liquid
    * GeoKit
    * Google Maps
    * Restful Development

Anything I miss? For those that consider themselves pros at Rails,
what do you know that makes you valuable?

Honestly, most of that is stuff that's too specific. You need to
spend more time understanding concepts instead of libraries. What
powers a shopping cart? Is RMagick the best solution? How do you
tell? How do acts_as_paranoid or ActiveMerchant work? These are the
things you need to focus on because they will make you a better
developer instead of a better Rails user.

To pare down your list:

   * Subversion
   * Capistrano
   * Attachment_fu
   * Caching
   * RSpec
   * Git
   * Action Mailer
   * RJS
   * jQuery
   * SSL
   * Authentication
   * Testing
   * Restful Development

To that I would probably add a lot of things about how the web works,
how to profile Ruby, and a ton of Ruby education.

--Jeremy

Specifics is what I am asking for. What things (plugins/technologies/
methods/etc) does a pro rails developer use often to build real world
apps? It will differ based on projects you are involved with... but if
various people answer with specific things they need to do their build
their apps, I'll get a good idea of what I should know to build the
apps I want to build.

BTW, Thanks for adding jQuery to the list. I'll look into what that
is.

Mel,

An old school professor of mine once said:

"We don't teach you how to use tools, we teach you how to reason"!

I fully agree with Jeremy. Focus on learning the basics, the concepts,
the core of Ruby and RoR. The rest will come easy after that. After
all, tools change...

Cheers, Sazima

Well, I am hoping the series " Monkeying around with a Rails 2
Development Environment" on my blog (http://there.thruhere.net/
randy_gordons_blog) will cover all those areas. The idea is that I am
starting with a basic Eclipse RDT installation and adding support
for , well, the kitchen sink, using Eclipse Monkey and Remote Systems
Explorer.. The first couple of articles cover setting up a serious
development environment on Windows. I am hoping to use the code from
the book "RailsSpace" as the base since I think that is the best book
for beginners out there, but I am still trying to contact the authors
for permission to do so. Once I have support for the basics, later
articles will cover customizing Eclipse for the advanced topics you
are describing. I am hoping it will also explain the concepts behind
each application/technology.

Mel,

An old school professor of mine once said:

"We don't teach you how to use tools, we teach you how to reason"!

I fully agree with Jeremy. Focus on learning the basics, the concepts,
the core of Ruby and RoR. The rest will come easy after that. After
all, tools change...

I'm definitely 100% on that. I would add javascript of some flavour
(prototype, jQuery etc..) to the list: rjs is nice, but it's not the
be all and end all. There are times when you should just write some
javascript (and with prototype that can actually be quite nice). Rails
has been a full time job for me for not far off 2 years and I've not
touched quite a few of those initial things, because I just haven't
needed to. The important thing is to be able to pick up new things
when they come up (although a general awareness of what sort of thing
is available is useful)

Fred

I agree here. Learn Ruby first. The "Ruby for Rails
Programmers" (Black) is a great way to start since it uses the Rails
platform as an example of good Ruby. Most of the things that you've
listed are helpful tools but they'll be useless if you don't
thoroughly understand the language in which the framework is
implemented and the core concepts (MVC, REST) and specific
implementations (ActiveRecord, ActiveResource, ActionController, etc)
then you're completely wasting your time with plugins and gems.

Humor me and gemme specifics please.

OK, for your first salt, learn and explain the differences,
advantages, and tradeoffs among:

has_many
has_many :through
has_and_belongs_to_many

associations. What problems does one solve that another does not? Why
have three when one more general one might do?

Any Rails programmer worth his or her salt should be able to do this.
Extra points for a discussion of eager loading and its impact on
memory consumption, object instantiation and potential performance
issues.

Is that specific enough?

Thats what I'm talking about!

Anything I miss? For those that consider themselves pros at Rails,
what do you know that makes you valuable?

Learn how to optimize queries in your choice of database. A lot of
'rails scaling' issues I've seen are from slow or needlessly frequent
database queries. Doing this goes a long way towards writing a good
web app in any language.

This sounds like a good one. Thanks, I'll look into it.

Steve Ross wrote:

OK, for your first salt, learn and explain the differences,
advantages, and tradeoffs among:

has_many
has_many :through
has_and_belongs_to_many

associations. What problems does one solve that another does not? Why
have three when one more general one might do?

Any Rails programmer worth his or her salt should be able to do this.
Extra points for a discussion of eager loading and its impact on
memory consumption, object instantiation and potential performance
issues.

Is that specific enough?

has_many
has_many :through
has_and_belongs_to_many

These are ActiveRecord associations. I would call them methods except
that they seem to *generate* methods.

class Project < ActiveRecord::Base
    belongs_to :portfolio
    has_one :project_manager
    has_many :milestones
    has_and_belongs_to_many :categories
  end

generates the following methods:

Project#portfolio, Project#portfolio=(portfolio), Project#portfolio.nil?
Project#project_manager, Project#project_manager=(project_manager),
Project#project_manager.nil?,
Project#milestones.empty?, Project#milestones.size, Project#milestones,
Project#milestones<<(milestone), Project#milestones.delete(milestone),
Project#milestones.find(milestone_id), Project#milestones.find(:all,
options), Project#milestones.build, Project#milestones.create
Project#categories.empty?, Project#categories.size, Project#categories,
Project#categories<<(category1), Project#categories.delete(category1)

has_many :through
is shorthand for a through association, whose continued syntax is:
:through => :catalogue_items
This association appears to have implications for polymorphism.

You're right, inasfar as these methods generate other methods, a.k.a.,
metaprogramming (code that generates other code).

Now your task is to figure out how all that works. :stuck_out_tongue: And where else
Rails uses metaprogramming (there's a lot).

If you can master metaprogramming (and know when and not to use it
[the hardest part]), then you'll be a number of steps ahead of most
developers.

--Jeremy

These are all excellent suggestions! Thanks for your guidance.
Anything else?

There's a general sort of attitude one should have towards libraries and
frameworks, though I'm hesitant to bring it up because it's too easy to
take it its illogical extreme. The idea is that one should be capable of
implementing any framework/library one uses. That doesn't mean that it's
worth your time to do so, just that you understand it well enough that
nothing seems "magical" to you.

Importantly, this should not be taken to mean that one should not use a
framework/library one couldn't have come up with independently, or
implement equally well, or anything like that. I'd be hard-pressed to
implement a dependable 3D rendering library, much less an optimized OpenGL
renderer. That said, I feel comfortable using OpenGL (and ruby-opengl)
because I understand it well.

What that understanding does for you is that you spend less time guessing
at configuration/methods/whatever because your first guess is usually right
and, if not, you can read the source to quickly find out what you need. For
Rails in particular, reading the source is very instructive. It is likely
to teach you things about Ruby you didn't know, and enlighten you about
what functionality Rails actually provides and how it does it. I would love
to see a book on the Rails source in the same vein as the Lions book on the
Unix source
<http://en.wikipedia.org/wiki/Lions'_Commentary_on_UNIX_6th_Edition%2C_with_Source_Code>.

Anyway, I'd say that a "Rails programmer worth his salt" understands Rails
to the point that it holds no magic or mystery, not merely in its use but
in its implementation.

--Greg

Rick, can you be more specific and provide an example, please. To me it
is not clear what you are suggesting. It could be (a) to learn how to
write custom, optimized SQL queries, or it could be (b) learning how to
avoid unnecessary database accesses using eager loading, caching etc.

Regarding (a), writing optimized SQL queries, I'm curious as to the
performance improvements that can be gained. I have no doubts that
there are huge potential improvements when changing algorithms so that
they are expressed in a single SQL statement rather than in Ruby
intermingled with multiple DB queries. I'm more cautious when it comes
to one to one substitution of Rails-generated SQL with handwritten SQL.
I'd expect that in such a case optimization is more a matter of
providing the DBMS with suitable access paths, i.e. indexes, that are
necessary regardless how the SQL of the query is created.

Michael

I'm not Rick, but I can give you a couple of concrete examples:

Counter caching can be a huge win. Say every blog page says: This entry has (3) comments. With counter caching, you can avoid the database hit each time the post is shown.

By default, Rails does a SELECT *. On a table with many fields, this can get pretty darn expensive. Instead, for critical queries, use:

@person = Person.find :all, :select => 'first_name, last_name'

I guess I wouldn't do this unless you were doing full-table scans of bulky tables, but I have (in some cases) been able to measure significant improvements when there was a complex table and all I needed was a small subset of the information for a given query.

The DataMapper people claim (and I have no reason to doubt this) that large text or blob fields can be expensive if loaded for each object. I'm not sure how they do this, but they lazy-load text fields so you incur the database hit as late as possible (and for the smallest number of rows required).

Also, AR does query caching. That's cool, and I suspect it solves many problems, but it's a single-machine solution. If you are looking to offload some of the burden from your primary app server, running a memcached server on a separate box to cache queries can help.

I'm sure Rick has cooler examples.

This kind of stuff is pretty far in front of the original "worth his salt" question. I believe one can do a workmanlike job constructing a Rails app just knowing that some of this stuff *can* be done, without ever having done it.

Oh, one other note: textile and markdown are relatively expensive operations (not SQL related, however), so if you store a preformatted version of text in your database on create or update, the render will happen faster.

http://docs.google.com/Doc?id=dg4nzw3x_139hkpwmpf7

Based on all the ideas you guys have put out there as well as going
through some books, here is my check-list of things to learn in rails.
The order will change as my needs change and I'll keep things updated
as I go. I figured it might be helpful to other newbies like me.

~ mel

>>> Anything I miss? For those that consider themselves pros at
>>> Rails, what do you know that makes you valuable?
>>
>> Learn how to optimize queries in your choice of database. A lot
>> of 'rails scaling' issues I've seen are from slow or needlessly
>> frequent database queries. Doing this goes a long way towards
>> writing a good web app in any language.
>
> Rick, can you be more specific and provide an example, please. To
> me it
> is not clear what you are suggesting. It could be (a) to learn how
> to write custom, optimized SQL queries, or it could be (b) learning
> how to
> avoid unnecessary database accesses using eager loading, caching
> etc.

[snip]

I'm not Rick, but I can give you a couple of concrete examples:

Counter caching can be a huge win. Say every blog page says: This
entry has (3) comments. With counter caching, you can avoid the
database hit each time the post is shown.

By default, Rails does a SELECT *. On a table with many fields, this
can get pretty darn expensive. Instead, for critical queries, use:

@person = Person.find :all, :select => 'first_name, last_name'

I guess I wouldn't do this unless you were doing full-table scans of
bulky tables, but I have (in some cases) been able to measure
significant improvements when there was a complex table and all I
needed was a small subset of the information for a given query.

The noteworthy thing about all these examples is that they remain at
API-level, nowhere do you manually write SQL with the express purpose
of optimization. That doesn't dimish the value of these techniques, of
course, however, I'm wondering whether they are what Rick had in mind.

Michael