On the Fence with Rails
Ruby Rails...love it or hate it
Ok, unless you're a person who just doesn't care what types of frameworks or technologies that are out there, you've probably heard of Ruby...and most likely "Ruby on Rails". Lots of books and opinions have been written about this particular framework and I thought I'd put in my quick 2 cents worth about the subject since I've recently finished up another Ruby/Rails project.
The Real Deal
Ok what's the big deal about it? Good question. In a nutshell...speed. I have to admit, the ability to create a model view framework that takes care of your inserts/deletes/reads/updates in literally 2 seconds or less has to be a draw for any developer who has been through this mundane procedure before even with the advent of some helpful modelers (see my blog on PHP and asp.NET ones: http://www.justicesolutionsllc.com/blogcfm/1/2008/02/57.Getting-the-CRUD-out-in-your-code.cfm).
Ok so what else? Well there are some very helpful 'helpers' that Ruby provides that does actually make things quite easy when needing a membership module built, or a quick and easy shopping cart, etc.
Custom Pathways are another neat little feature of RoR. If you want you can defined a custom path based upon a users input, a page they enter on, a word they type after the page. It's really a super version of taking 404 error rewrites and doing something useful with them in a very easy to use fashion.
The Down
So there's gotta be a downside right? Otherwise everyone would be RoR-ing about it. (btw...RoR is short for "Ruby on Rails"). Anyway, what I've found personally is an issue with the server speed and sometimes the paths you create take a while for good ol' Roob' to figure out and deliver the page. If you use a "mongrel" server base vs. Apache or IIS (yes it can run on it) things do improve.
However, there are some tweaks and tunes you'll need to do in order to get it to run just right.
It's a typical Linux type scenario that most of us have been through. Yes...the Linux based server config of Lamp (Linux/Apache/MySQL/PHP) does run very well and hardly ever crashes....however setting up that ideal system with your own custom needs sometimes does become its own beast.
Like all frameworks there are some cool features that unfortunately create other problems. Some are not obvious until Mongrel crashes unexpectedly on you like it did me when I was using Ruby's neat little refresh Ajax control that basically can be used to update data in a <DIV> every second if you'd like. The problem....it also submits the variables of a POST form as a blank at the same time if you're not careful.
"Let Me Explain...no....there is too much....Let me Sum Up." (I'll award a gift certificate to a national chain restaurant to the person who emails me at doug@justicesolutionsllc.com with the answer to where that quote is from. No Matt Krause...you are not eligible....lol)
So should you go Rails? The answer like I say to so many new clients who ask me the same question about asp.NET, PHP, ColdFusion, Flash, and yes...Rails...is simply this. It depends. It depends on your budget, your site's future development needs, the availability of a developer who knows RoR...etc.
If you have a site that is pretty simple that maybe requires a blog, some simple data entry and data display...I'd say go Rails in an instant. You could literally build that entire concept in probably an hour or two at the most. But, if you're going large scale and have a lot of unknowns in your development and business plan path...perhaps another language may work a bit better for you. Again, it depends on your developer.
So there's my two cents on rails. For a look at this latest Rails project we've launched recently and continue to develop on (btw....great company with a great concept), check out http://www.gqex.net when you get a chance.
Happy Coding!
Doug.
The Real Deal
Ok what's the big deal about it? Good question. In a nutshell...speed. I have to admit, the ability to create a model view framework that takes care of your inserts/deletes/reads/updates in literally 2 seconds or less has to be a draw for any developer who has been through this mundane procedure before even with the advent of some helpful modelers (see my blog on PHP and asp.NET ones: http://www.justicesolutionsllc.com/blogcfm/1/2008/02/57.Getting-the-CRUD-out-in-your-code.cfm).
Ok so what else? Well there are some very helpful 'helpers' that Ruby provides that does actually make things quite easy when needing a membership module built, or a quick and easy shopping cart, etc.
Custom Pathways are another neat little feature of RoR. If you want you can defined a custom path based upon a users input, a page they enter on, a word they type after the page. It's really a super version of taking 404 error rewrites and doing something useful with them in a very easy to use fashion.
The Down
So there's gotta be a downside right? Otherwise everyone would be RoR-ing about it. (btw...RoR is short for "Ruby on Rails"). Anyway, what I've found personally is an issue with the server speed and sometimes the paths you create take a while for good ol' Roob' to figure out and deliver the page. If you use a "mongrel" server base vs. Apache or IIS (yes it can run on it) things do improve.
However, there are some tweaks and tunes you'll need to do in order to get it to run just right.
It's a typical Linux type scenario that most of us have been through. Yes...the Linux based server config of Lamp (Linux/Apache/MySQL/PHP) does run very well and hardly ever crashes....however setting up that ideal system with your own custom needs sometimes does become its own beast.
Like all frameworks there are some cool features that unfortunately create other problems. Some are not obvious until Mongrel crashes unexpectedly on you like it did me when I was using Ruby's neat little refresh Ajax control that basically can be used to update data in a <DIV> every second if you'd like. The problem....it also submits the variables of a POST form as a blank at the same time if you're not careful.
"Let Me Explain...no....there is too much....Let me Sum Up." (I'll award a gift certificate to a national chain restaurant to the person who emails me at doug@justicesolutionsllc.com with the answer to where that quote is from. No Matt Krause...you are not eligible....lol)
So should you go Rails? The answer like I say to so many new clients who ask me the same question about asp.NET, PHP, ColdFusion, Flash, and yes...Rails...is simply this. It depends. It depends on your budget, your site's future development needs, the availability of a developer who knows RoR...etc.
If you have a site that is pretty simple that maybe requires a blog, some simple data entry and data display...I'd say go Rails in an instant. You could literally build that entire concept in probably an hour or two at the most. But, if you're going large scale and have a lot of unknowns in your development and business plan path...perhaps another language may work a bit better for you. Again, it depends on your developer.
So there's my two cents on rails. For a look at this latest Rails project we've launched recently and continue to develop on (btw....great company with a great concept), check out http://www.gqex.net when you get a chance.
Happy Coding!
Doug.
Posted by dougjustice at 10:36 PM | Link | 0 comments
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
No comments found.
Post a comment (login required)