Rails Programmer Worth His Salt

rubyonrails-talk
1

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?

2

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

3

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.

4

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

5

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.

6

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

7

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.

8

Humor me and gemme specifics please.

9

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?

10

Thats what I'm talking about!

11

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.

12

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

13

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.

14

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

15

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

16

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&gt;\.

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

17

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

18

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.

19

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

20

>>> 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