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