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

On Feb 3, 2008 10:49 PM, mel ram [email protected] wrote:

* Substruct
* Git
      o Role-based authentication
* 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?


http://www.jeremymcanally.com/

My books:
Ruby in Practice

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

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

On 4 Feb 2008, at 12:40, Sazima wrote:

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

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.

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.


Rick O.
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com

Steve R. 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.

Dan F.

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

On Feb 4, 2008 7:25 PM, Dan F. [email protected]
wrote:

have three when one more general one might do?
has_and_belongs_to_many

Project#categories<<(category1), Project#categories.delete(category1)


http://www.jeremymcanally.com/

My books:
Ruby in Practice

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

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

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

On Tue, Feb 05, 2008 at 12:23:05AM -0800, mel ram wrote:

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

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

On Feb 5, 2008, at 10:28 AM, Michael S. wrote:

Rick, can you be more specific and provide an example, please. To me
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.

On Monday 04 February 2008, Rick O. wrote:

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.

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


Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/

On Tuesday 05 February 2008, s.ross wrote:

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


Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs