To RoR or Not To RoR

Hello RoR Community,

I am involved in a new project, we have to build a dynamic website (no
surprise!), and I have to decide which technology to use. I come from
PHP, ASP (VBScript and then .NET, VB, C#) world. I coded a lot in
C#.NET for Win32 apps and have some Java Knowledge. I have been
following Ruby on Rails progress lately. I brought the "old" book
(which is now in Beta for the new version), Pragmatic Programming, and
I really like what I read on the book about RoR.

Despite all this magic, I'd really like to get some feedback from
different RoR gurus or experienced people. Bad things you've seen,
good things, people who were working with PHP/MySQL and switched to
RoR. People who considers switching back to something other than RoR
and why? Etc.

The project has nothing to do with http://amiestreet.com but there are
some things there that we'd be implementing. (Users, Logins, Uploads,
Downloads, Basket, Checkout, Statistics, etc.). Only it has nothing to
do with music :slight_smile:

I can't reveal much more per NDA. :frowning:

Any insight or constructive comment would be appreciated.

Thanks in advance,

Martín M.

Hi Gryzor,
Gryzor wrote:

I am involved in a new project, we have to build
a dynamic website (no surprise!), and I have to
decide which technology to use. I come from
PHP, ASP (VBScript and then .NET, VB, C#)

If this project is time-constrained and mission-critical, I strongly
recommend _against_ using tools with which you and your team are not
familiar.

If you're attracted to RoR, get some experience with it. It can do anything
you can do in any of the other technologies you're familiar with, but you'll
enjoy the work a lot more. Especially after you've gotten over some of the
un-learning you'll have to do. Start with Rails and let it lead you to
Ruby. Much of writing good Rails apps has nothing to do with Ruby. MVC,
for example. And Rails is 'convention over configuration'. The conventions
are really, really important to learn.

I recently worked with a team who took on rebuilding the company's
client-facing .NET web-site in RoR. The ones who where there at the start
of the project got 3 days of Ruby training. They learned Rails as they
went. The ones that were brought on later got no training; just
assignments. They ended up with a .NET application coded in Ruby. Not
pretty. And it was highly over-schedule and -budget.

If you really want to go RoR, build just the core of the app with it. Then
throw that away. Twice if you can. Then develop your estimates, plans,
etc., and you'll have a much better chance of success.

Just my $0.02.

Best regards,
Bill

Hi Gryzor,
Gryzor wrote:

I am involved in a new project, we have to build
a dynamic website (no surprise!), and I have to
decide which technology to use. I come from
PHP, ASP (VBScript and then .NET, VB, C#)

If this project is time-constrained and mission-critical, I strongly
recommend _against_ using tools with which you and your team are not
familiar.

If you're attracted to RoR, get some experience with it. It can do
anything
you can do in any of the other technologies you're familiar with,
but you'll
enjoy the work a lot more. Especially after you've gotten over some
of the
un-learning you'll have to do. Start with Rails and let it lead you
to
Ruby. Much of writing good Rails apps has nothing to do with Ruby.
MVC,
for example. And Rails is 'convention over configuration'. The
conventions
are really, really important to learn.

Each to his own, but I'd say ruby then rails. A lot of rails magic
would seem even more impenetrable without knowing a reasonable amount
of ruby and its idioms.

Fred

Thank you both for your insight.

All I can really offer is to try it out on something small first and
see how it goes from there. Having no programming background and
trying to learn Rails has been an interesting adventure for me, but
the more I learn the more doors are unlocked and the better things
become. Already I'm looking at a project I started three months ago
and shaking my head as to why I did some things because I've learned
so much more in just trying stuff out and failing ... a lot.

+1 to "Don't try to learn RoR through a time-critical, commercial
project". It has been incredibly stressful. :slight_smile:

Hi,

If you already know .Net languages than you should go for IronRuby only.

With this Language, you can stay in your own .Net world plus get the
maximum advantage of Ruby as well as advantages of converting the
existing codes from C# or Vb.Net to IronRuby.

Plus, with IronRuby, you can stay in both the worlds simultaneously.
This is the best thing happening. In case, you are more familiar with
Java then you should go for Jruby.

I am not sure of only of one thing and that is.. How well IronRuby
supports Active Record with their Asp.Net MVC. BTW... Asp.Net is almost
80% clone of Ruby on Rails.

I hope i am clear.

Hi,

If you already know .Net languages than you should go for IronRuby
only.

With this Language, you can stay in your own .Net world plus get the
maximum advantage of Ruby as well as advantages of converting the
existing codes from C# or Vb.Net to IronRuby.

Plus, with IronRuby, you can stay in both the worlds simultaneously.
This is the best thing happening. In case, you are more familiar with
Java then you should go for Jruby.

I am not sure of only of one thing and that is.. How well IronRuby
supports Active Record with their Asp.Net MVC. BTW... Asp.Net is
almost
80% clone of Ruby on Rails.

IronRuby isn't ready. To quote John Lam (about 3 weeks ago) "We're
barely able to run Rails functional tests now, and there's a lot more
library work to be done before we can start thinking about deployment
etc" (http://rubyforge.org/pipermail/ironruby-core/2008-May/
001909.html). I've no doubt it will get there, but not quite yet.

Fred

Also--ASP.net's MVC stuff is completely independent of IronRuby. And
it's the MVC stuff that is a clone of RoR--not asp.net generally.


Hello RoR Community,
I am involved in a new project, we have to build a dynamic website (no
surprise!), and I have to decide which technology to use. I come from
PHP, ASP (VBScript and then .NET, VB, C#) world. I coded a lot in
C#.NET for Win32 apps and have some Java Knowledge. I have been
following Ruby on Rails progress lately. I brought the "old" book
(which is now in Beta for the new version), Pragmatic Programming, and
I really like what I read on the book about RoR.

wrong book,

the basic library you have to go through is

The ruby programing language

The rails way

Ajax on rails

Rails API

You can also start with Ruby for Rails as a soft ice breaker

Without understanding those three books and the API

you won’t be any close to start a complex project.

Don’t forget to add peepcode test screencasts to the pool,

but after you get the basic understanding,

You may be investing about two or three weeks, (at least, before start doing serious work)

but your productivity and personal value will be way higher.

Despite all this magic, I'd really like to get some feedback from
different RoR gurus or experienced people. Bad things you've seen,
good things, people who were working with PHP/MySQL and switched to
RoR. People who considers switching back to something other than RoR
and why? Etc.

because to really master RoR you have to learn Ruby upside down and read the whole Rails API

a lame, unprofessional coder will never find the drive to learn all what is needed to get starting with Rails.

(the how to write a blog in 15 minutes screencast is a booby trab)

The project has nothing to do with [http://amiestreet.com](http://amiestreet.com) but there are
some things there that we'd be implementing. (Users, Logins, Uploads,
Downloads, Basket, Checkout, Statistics, etc.). Only it has nothing to
do with music :)
I can't reveal much more per NDA. :(
Any insight or constructive comment would be appreciated.

Once you know Ruby and Rails your feelings will hurt if you use anything else.


Thanks in advance,
Martín M.
--~--~---------~--~----~------------~-------~--~----~
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@googlegroups.com
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](http://groups.google.com/group/rubyonrails-talk?hl=en)
-~----------~----~----~----~------~----~------~--~---
-- Andres Paglayan
CTO, StoneSoup LLC Ph: 505 629-4344
Mb: 505 690-2871
FWD: 65-5587
Testi. Codi. Vinci.

The folks that I work with on Rails varying expertise in php, python,
java, coldfusion, and C++/C#/VB.Net. To a person, everyone grumbles
and complains when legacy apps demand their attention in their old
environments. I have not met a single developer who wanted to go back
to their previous environment and most are actively trying to flip
their legacy app to Rails.

Contrary to the earlier post I think that AWDR is a decent place to
get an introduction to Rails. Specifically, the first dozen chapters
leads you through a good cross section of the kinds of things you can
do. From there I'd agree that The Rails Way (Fernandez, Addison-
Wesley, 2007) and Ruby For Rails (Black, Manning, 2005?) are the best
resources.

IronRuby isn't ready. To quote John Lam (about 3 weeks ago) "We're
barely able to run Rails functional tests now, and there's a lot more
library work to be done before we can start thinking about deployment
etc" (http://rubyforge.org/pipermail/ironruby-core/2008-May/
001909.html). I've no doubt it will get there, but not quite yet.

Fred

I went to a few minutes of Lam's IronRuby presentation at RailsConf.
I missed the very beginning (too much Starbucks :slight_smile: and when I got into
the room he was already saying "that's about it." Ten minutes into a
45 minute talk on the state of IronRuby and "that's about it"? Ouch.

The best line was "about ten minutes ago we got this code working so
we can read from the database with ActiveRecord."

Fundamentally I don't like their approach. "shotgun" is somewhat
kind. Their idea is simply to try stuff, see what works, try to fix
something that doesn't work, and then try something else. There does
not seem to be a comprehensive, top-down or bottom-up approach to
implementation and I got no impression that they're leveraging the
work that the Rubinius team has put into for Ruby language
compatability testing.

Oh, and it was slow as.... anything. I think we used a sun dial to
time the start up of Webrick.

Hi --