Rails - Dec 2009 - Ruby from a Project Manager POV: Pros vs Cons

Hello RoR Developers,

I''m currently not a developer anymore, I''m a project manager,
that
adopted really eagerly agile methodologies.

One of the things that I identified while working is that, while agile
already gave me a boost while managing my projects, it sometimes
slacks by not using a really productive tool.

You end up, having to build tons of modules, for a different variety
of scenarios, to compensate for the an unproductive language. What if
you constantly switch groups? What if the code you produced is
proprietary?
The bottom line is, how do I keep up my team productivity?

Here I come searching for new horizons. Enter the Ruby world.

From a Project Manager POV, I need to know a couple things before
deciding my approach on a given project.

- Can x (Technology, Language, Framework) accomplish my goal?
- How long would x take to accomplish it?
- How easy is it to maintain?
- Whats the depth of its documentation?
- How easy is it to get help?
- How easy is it to deploy?
- How easy is it to test? Does it have integration tests (Use Case ->
views -> controllers -> model -> persistence -> response) ? And how
easy is it?
- What x can''t do?
- How well does x scale?
- How easy is it to persist data and work with database? How easy is
it to swap database vendors?
- How well does x work with caching?

Basically from a couple question, I can define my schedule, my cost,
my risk and quality.

I also try to get my hands dirty, so I will not blindly accept
someones input.

I would love to hear from you guys on this question, specially on
scalability, data persistence, caching, tests and deployment.

Cordially,
Rodrigo Dellacqua

--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Rodrigo,

While there might be people better able to answer your more technical
questions, I thought I should offer you my view regardless.

I am also a project manager who started my current job 3 months ago. I
would consider my role to be 50% project management and 50% hands-on
development. When I joined this company, the state of our proprietary
and patent-pending software was in disarray. The software could not
keep up with our sales, and could not handle the load. The software
would not scale even an inch further. Critical components were failing
and a team of three people were spending most of their time holding it
together with duct tape.

One of the first things I did was suggest a change in platform to Ruby
and the Rails framework, which was immediately approved. We started
hacking away and now, we have a long-term plan that includes a
solution to our scalability issues. The future is looking exceedingly
bright.

We chose Ruby. Here''s why:

1. It''s a do-little-receive-lots language.
I know this has been re-hashed and replayed by many, and that only
confirms the validity of the claim. If I''m lucky, I have four hours
per day in which I can code. With tight deadlines. Ruby and Rails
allows me and the rest of the team to get results with less work.

2. TDD.
Rails in particular feels as if it''s built for testing. Previously,
we''ve had limited testing as the past platform made them difficult to
automate. With Rails, on the other hand, you can do unit, functional
and integration tests out of the box--and there are plenty of other
options as well. While we haven''t yet been able to move to a
completely test driven development environment, we''re getting there.

3. Fast and vibrant community.
The Ruby and frameworks communities are growing and moving rapidly. If
you''re looking for a solution to a problem--authentication, background
processing, etc., chances are a quick Github search will solve the
problem for you and save days or weeks of development. And they''ve all
got their own tests, so you can make sure they work in your
applications.

4. Quick and effective help.
Because of 3., there''s lots of help to get. Some of it is even free
(*waves!*). If you want to pay for it, there are plenty of top-notch
companies and individuals who can consult you on any number of things.
They''re so easy to find that I won''t even link to them.
Documentation''s fine--I''ve never had any issues with finding
what I
need.

5. Ease-of-deployment.
Personally, I first looked at Rails before v1.0, but moved away from
it sometime in ''06 because deployment was clunky and didn''t
fit my
needs. Since then, systems like Phusion Passenger (aka mod_rails) have
emerged, making deployment a breeze--to take simplicity to extremes,
you can just FTP your application to your production server.
Naturally, you may not want to go *that* far, and so there are options
such as Capistrano. There are options everywhere on the complexity
scale.

6. It can scale.
Yes, Twitter had well-publicized scaling problems, but they got over
it and are still mostly running Rails (part of their stack is in
Scala). There are plenty of other high-volume sites running Rails,
too. Yellow Pages and Github are a couple. It can most definitely be
done.

7. It''s sexy.
I said "Ruby" and "Rails" and our CEO and Board of Directors
clapped
their hands in joy. Much as I hate to admit it, they''re buzzwords and
the higher-ups loves them--regardless of whether they know what it is
or not. (If you really want to make their socks roll up and down,
mention "cloud computing" in the same sentence.) I realize that this
is a completely non-technical reason for choosing Ruby, but it might
be worth taking into consideration anyway.

As for your other questions... to me, maintaining software is more
about planning and source control. If you plan your app well and use
the right source control tools (git is excellent), it doesn''t really
matter what language you''re using.

I can''t reliably answer the ones about caching and databases. I know
Rails support different vendors and that there are lots of caching
options.

I hope any of this helps.

Best,
Sebastian

On Dec 9, 4:11 am, "rgoyta...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<rgoyta...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hello RoR Developers,
>
> I''m currently not a developer anymore, I''m a project
manager, that
> adopted really eagerly agile methodologies.
>
> One of the things that I identified while working is that, while agile
> already gave me a boost while managing my projects, it sometimes
> slacks by not using a really productive tool.
>
> You end up, having to build tons of modules, for a different variety
> of scenarios, to compensate for the an unproductive language. What if
> you constantly switch groups? What if the code you produced is
> proprietary?
> The bottom line is, how do I keep up my team productivity?
>
> Here I come searching for new horizons. Enter the Ruby world.
>
> From a Project Manager POV, I need to know a couple things before
> deciding my approach on a given project.
>
> - Can x (Technology, Language, Framework) accomplish my goal?
> - How long would x take to accomplish it?
> - How easy is it to maintain?
> - Whats the depth of its documentation?
> - How easy is it to get help?
> - How easy is it to deploy?
> - How easy is it to test? Does it have integration tests (Use Case ->
> views -> controllers -> model -> persistence -> response) ? And
how
> easy is it?
> - What x can''t do?
> - How well does x scale?
> - How easy is it to persist data and work with database? How easy is
> it to swap database vendors?
> - How well does x work with caching?
>
> Basically from a couple question, I can define my schedule, my cost,
> my risk and quality.
>
> I also try to get my hands dirty, so I will not blindly accept
> someones input.
>
> I would love to hear from you guys on this question, specially on
> scalability, data persistence, caching, tests and deployment.
>
> Cordially,
> Rodrigo Dellacqua
--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Really appreciate your thoughts on this matter.

Thx!

--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.