ror developers

what are the primary requirements for ror developers?


1. Passenger aka mod_rails
2. Proxy setups
3. JRuby on Rails
4. Automate with Capistrano
5. Hosting

anything else?

Sns Sem wrote:

1. Passenger aka mod_rails
2. Proxy setups
3. JRuby on Rails
4. Automate with Capistrano
5. Hosting
anything else?

Plenty of
good ROR sides have been developed without 2, 3 and 4. 1 and 5 are not
relevant for developing a site but only for deploying it.

Sns Sem wrote:

what are the primary requirements for ror developers?

Posted via

1. host
2. ruby
3. rails
4. editor (textmate, vim, etc.) Some people prefer IDE's instead.
5. development and testing tools (cucumber / rspec / shoulda etc.)
6. version control (git, subversion, etc.)
7. project control (redmine, trac, etc)
8. somebody else to talk to

You guys are surprising me. So you are looking for developers and you
don't know what you need from them. Given that someone said it's, for
example, RSpec that they need to know well, how would you to assess
the prospective developer? Does anyone around you know RSpec well
enough, or will you take his word for it?

My point is that even if you had a collective list of things one
should know to develop web sites, you have no way to find out the
level of skills of a real candidate, have you?

I would look for a really good first developer. I mean REALLY good who
will become your "CTO" and who will fill the crew with adequate and
professional developers. Let them be of a lower level, but you will
knows your adviser understands what you need.

Hope it helps.


i use
netbeans(only for editing and intelisense)
lunar pages dedicated linux server

Here's a better list:

1: ability to rapidly pick up new tools and methods
2: ability to communicate effectively with both technical and non-
technical staff
3: passion for quality, readable code
4: the three programmer's virtues: Laziness, Impatience, and Hubris

None of these are HR-drone checkoff points, and that's for a good
reason: you can't measure developers that way. Traits like #1
eliminate the need for an exact skillset match; if I was hiring a dev,
I'd be less concerned with specific knowledge of a particular testing
framework than a general understanding of the *idea* and *purpose* of

Why emphasize generals over specifics? A quick example: Cucumber is
the new hotness at the moment, but less than 16 months ago it DIDN'T
EXIST. I doubt you'd find many people who would bet that the Cucumber
of today will be exactly the same as May 2011's Cucumber. So the
ability to adapt to change is vastly more important than how many
pages of RDoc one can memorize.

#2 and #3 are closely related, just in different arenas of
communication. A programmer who can't write documentation, or who's
code is unreadable to anyone else on the team is a massive liability.
This is especially important in languages like Ruby where freedom is
balanced with responsibility; you don't want to spend two weeks
finding out that Very Clever Programmer Guy has redefined + to mean -
on *some* objects returned from a method but not documented it

--Matt Jones

Very nicely put, Matt. I share your view completely.

This all boils down to having the right mind set, but unfortunately
the person who's looking for the team may not be ready to assess if
the mind set is right. That's why in many cases people are looking for
"the rule of the thumb" -- to simplify the problem of choice. I
wouldn't use the fixed set of tools as a criteria, but would talk to a
candidate for 20 minutes and figured whether he's the right kind. By
that I mean whether he's passionate, flexible, disciplined and eager
to learn at the very least. These are way more important than any
specific technologies.

- Aleksey