Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Before I asked this question I had a look through the search results for 'Ruby on Rails' here on SO. Couldn't find much, but the following (found on this page) amused me
Personally, I started using .html, moved onto php, tried ruby (hated it), discovered Python / DJango.. and have been happy ever since.
Now here's the deal. I have no personal intention of learning Ruby on Rails just yet, but it's the topic of a group presentation I am to do at the Uni (and my mates chose the RoR subject). People with a grudge against students asking homework-type questions should leave immediately.
This question is for RoR people who find it great. I hope to find those that claim RoR is the best (authors of the breathtaking testimonials to be found at RoR website). What makes RoR so outstanding? What would you like the youths of today to find out about it just before they leave the Uni with a degree. Try suggesting something that could root in their minds and perhaps navigate them the RoR way after leaving Uni.
Your answers will not only help my presentation, but could be the source of enlightenment for many.
ActiveRecord's dynamic finders:
Person.find_by_name_and_company_id('Jorge Luis Borges', 42)
rjs, writing javascript in ruby:
page['element_id'].insert_html :bottom, :partial => 'comment'
ActiveRecord's scoping
class Shirt < ActiveRecord::Base
named_scope :red, :conditions => {:color => 'red'}
named_scope :dry_clean_only, :joins => :washing_instructions, :conditions => ['washing_instructions.dry_clean_only = ?', true]
end
calling Shirt.red will query the db with the "color = 'red'" condition
the cool part, is that if you combine more than one scope eg:
Shirt.red.dry_clean_only
it will build just one query, with all the conditions and joins necessary to satisfy both scopes.
ActiveRecord's Migrations, being able to manage db structure and data using active record, just like in the app's code, with minimal sql usage.
Tools are about solving problems. It doesn't matter whether you're talking about the tools in a wood worker's shop or a programmer's. What impressed me about Rails (and still does) is that it was extracted from framework used to build real-world web apps and has repeatedly been improved by people who extended or changed it after using it to build real-world web apps. It was no mere academic exercise.
Some of the specific problems it addressed:
Getting started quickly. If you are looking to get a web application underway quickly, what better choices could you have than a framework that specifies an existing directory structure (one based on MVC), with lots of code generators, and choices already pre-made for you as to components like JavaScript library, testing support, ORM, etc. You may not agree with all the choices but you can assume them and have something that will work for 80% or more of projects and swap out something later if you have a preference.
Long term maintainability. Migrations give you ways to move data forward as your code changes, something that happens in any real-world application, yet most frameworks do not account for that at all. Separating all of the parts of your application into a directory hierarchy already setup with areas for testing, database, configuration, etc. again aids the long term maintenance of your project.
Reduced human error. Configuration files give you extra opportunities for human error. Logical conventions, once learned can avoid mistakes like the classic mistyped file name or class name in a configuration file error.
Recognition of different modes of development. Rails has built in support for the idea of having a different set of settings for development vs. test vs. production. Real apps have this too, but often the framework around them doesn't accommodate it and you end up having to swap configuration files in and out to achieve the same effect (see human error above).
Good practices. Several things I've mentioned above embrace and encourage good programming practices (MVC, standardized project layout, etc.) but Rails is often explicit in encouraging them and not just implicit. For evidence of that you need look no further than its built in support for test driven development.
I blogged in detail about why I love Rails three years ago, but for me for number one cool feature is that it makes developing web applications easy and fun.
To name a few items:
Large developer community (not saying that python doesn't)
Convention over configuration rocks
Can be used with JRuby/Warbler to make rails run on Java Application servers. Very important when trying to drag Enterprise into the 21st century (Django can be used with Jython to work with application servers, but is less mature).
MVC framework helps keep your application structured.
Scaffolding and generators to get your project moving.
Rails doesn't try to be the only way to do web applications, that's not the intent. It fulfills a specific set of needs.
This isn't a comparison against Python - it's a general list of things I like.
I write a lot less code than I would in Java
... And the code I do right is very readable and maintainable
I very rarely need to think where some code lives or how to handle a common task - it just has its place (e.g. migrations are built in)
You don't end up using lot of different technologies on one project (Java, EJB, Hibernate, JSP, SQL DDL, Ant, XML, taglibs)
Interpreted rather than compiled saves you lots of development time
One of the main reasons for me is that it puts fun back into web programming.
Suddenly things become simple and within reach. you don't need months of code crunching and
don't need tons of code written. you can do some pretty amazing things with just a few lines.
And it feels good :)
Honestly, I like the design of Django more then rails, but I like ruby more then python. Its a personal thing, because I know plenty of people who feel the opposite way, but I find ruby to be one of the most elegant languages I have ever used.
My main motivation for using Rails is ruby. I touched a lot of languages before I found ruby and I never felt I was any good in any of them. When I met ruby everything just made sense. It's a beautiful language; Easy to learn but hard to master.
I use rails because it suits my needs as a webdeveloper and is very feature rich.
Related
soliciting advice about upgrading (or re-writing?) a legacy app. It's a single page webapp with lots of dynamically generated windows and forms, roughly comprised of
13,000 lines in .rb files
11,000 lines in .erb files
25,000 lines of javascript (not including large 3rd party libraries that bring this to nearer 60000 lines)
This acts as a UI for end users of our system, which also has a number of core business services (mostly written in Java, with a small amount of Node.js) and a fairly sizeable MySQL database (>200GB). Some of these services push AJAX to the client browser for real-time updates.
Reasons for upgrade
It's ruby 1.8.7, rails 2.3.15. Most of the core code dates from 2009. This makes it both insecure and hard to maintain (think "predates the existence of gemfiles".)
The app has been maintained by Java devs for most of its life, as most of the company's devs have been hired as Java devs to work on all the other services that perform business logic. It's probably safe to assume that this has lead to lots of hacks from people who didn't want to break anything, and certainly lots will not be done in a "rails way".
The javascript is also a bit of a mess. It's got a knot of frameworks (the original Angular is used sporadically; jquery and prototype are both fighting over the $ symbol in different places.) There are files that are 7000 lines long.
the css styling has been upgraded since 2009(!) but is starting to look a little tired. We'd like to implement a bootstrap theme that will look sharp without too much front-end skill, but right now the code that renders all of our pop-up windows, sidebars etc breaks badly if we try and add bootstrap.
It would be nice to modernise our push servers, replacing them with websockets.
Context
There are 3 of us on the dev team- this is my first job, and I've only been here since January. Of the other two, one has only been here about 4 months longer than me, and it's his first dev job too. The other guy is the only one who has ever spoken to someone who spoke to someone from the original team.
Oh, and of course we have little or no test coverage.
Options
When I was hired (as a Java developer), I was told that we were looking to replace the website with one based on Spring MVC. This effort is partially underway, having been attacked in drips and drabs over a couple of years. Because different devs who never met have attacked it as if it's their own brand new project, the same problems are solved in different ways in different places. They've tried some flashy techniques such as custom annotations that I find hard to follow, but as far as I can tell don't fully work. The most senior of us estimates it would take our team a year's dedicated full-time work to finish it (which is not a realistic business proposition, based on how many requests for new features we get from customers).
I'm inclined to upgrade the website rather than spin out a new one. This is partly because I can see the sense in that post. Another reason is that we're all employed as jack-of-all trade full stack developers (doubling as DBAs, sysadmins, etc...). We've got no particular expertise in UI design, and the UI for our present interface, although dated, is pretty user-friendly; it feels like a blank canvas would throw that structure out, and play to our weaknesses. Upgrading ruby/rails would also make any features we add during the upgrade much easier to add to the new site.
Apparently some experienced ruby devs who are friends with my boss have advised him informally it'd be so much work to bring the website up to date that it would be comparable to a complete re-write, which was the motivation for the spring project. This would have the advantage of only having to think about Java + javascript, and not trying to hire people who know both Java and ruby well.
Conventional wisdom seems to be upgrade rails in stages. I'm not sure how well this would work for us, for 2 reasons. For one thing, there 3 major versions for us to upgrade, which might have significant changes between them. More importantly, the code needs some TLC anyway with refactoring and the creation of a test suite.
I'm inclined to follow the following strategy:
Invest some developer time in training, to get a sense of the relevant best practises and the "rails ways" of doing things, rather than the "good enough to hack" knowledge most of us have now.
fire up a new rails 5.1 project on ruby 2.4.0
Configure active record to use our old database
Copy across the javascript from the public folder of the existing project in to the relevant parts of the asset pipeline and save that headache for "phase 2".
Sort out a gemfile with updated versions of our dependencies (for example, mysql gem has been replaced by a mysql2 gem.) Installing rubocop seems like a good idea at this point.
Copy files across from old to new project one at a time. Read the code, figure out what it's doing, write the relevant tests, fix where they break. Use the ruby API and rails upgrade guides to update the syntax. Refactor until rubocop is appeased.
Once we've reproduced the functionality of the existing site, write a new stackoverflow post on how to sort out the javascript ;)
This certainly sounds like a lot of work, but seems less likely to produce a buggy mess than trying to reproduce our existing functionality from scratch in a different language. So...
Questions
Does this strategy seem sensible? Is this a case where the re-write is really a better option? Is tackling the JS separately the best call, or is it better to restructure it as we're examining the calls to it from the views? Or should we really upgrade -> 3.0, 3.1, ... 5.0, 5.1?
We've altered the database manually, adding new tables, new fields and whatnot directly rather than using .rails generate. 'Rails magic' seems to make this work at present, but should we anticipate problems in step 3?
Is there any logical order in which to approach the migration of ruby? As there's major changes to the routing, which is the central entry point of the application, it seems sensible to start there, followed by authentication, then the main page, and then add functions one at a time.
Part of the problem is "not knowing what we don't know" about the rails way of doing things. Apart from the canonical Ruby/Rails tutorials (Hartl, Ruby Monk, Ruby Koans, Kehoe's rails book), is there any essential reading we should be aware of before trying to take on such a large job? I'm especially thinking about things that may not be immediately obvious, like proper use of helper functions, module structure, etc.
Any other advice, comments, prayers, ... welcome!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
This is not a core programming problem as most posts on this website are, forgive me for that but I didn't know where else to ask this.
I am a beginner in web languages and want to build a small website for our family business, mostly a bunch of galleries that would display our different product lines with prices and some basic specs for customers to get an idea..currently I'm pursuing comp science at the undergrad level
So here is the problem, I can't decide between platforms
I started out with HTML and making a basic mock up but that didn't quite work out as i needed to have dynamic galleries that was quite hard to code by hand and since we need to update often it would be a pain even if I did manage to get it going
then I thought of Joomla as it would be easy to update but soon realized that its not that easy to customize templates
Then I started reading about Ruby on Rails and what it offers and it sounded really interesting might be useful in developing applications that we possibly would need in some time.
so I wanted to know from the community which course should one pursue: DHTML, Joomla, RoR
Please keep in mind that I want this to be a learning experience that will be useful possibly in the future in my professional career and at the same time get the job done.
I would also greatly appreciate any resources or suggestions that the community might have.
You are actually comparing apples to oranges here as DHTML, RoR, and Joomla are not the same thing. You are comparing a mark up language, to a programing framework, to a content management system. You could feasibly learn a CMS (Joomla, Drupal, Wordpress, etc) and never learn to code a single line of HTML or PHP.
For the purpose of getting a site that you can manage and edit yourself, then what you are asking is which CMS should you use. There are dozens of CMSes and opinions on which one is the best. In general are the big 3 - Wordpress, Joomla, and Drupal. Wordpress is by far the easiest to learn. It has a very simple admin that shouldn't take more than a few minutes to figure out. There are tons of themes and extensions that go along with it. The downside is that it's coded to be a blogging platform, not an extensible CMS. That means that doing things other than blogging are harder to accomplish (relative to Joomla and Drupal). It can still be done, but the more complex the site, the harder it is to do in Wordpress.
Joomla is the next step in ease of use. The admin is significantly more complex than WordPress, but a tech savvy user will get the basics down in the first couple of hours or so. Extendding Joomla is much easier for both the developer since the framework is specifically designed to be extended, and the user since installing is very quick and easy for most extensions. It's a pretty good balance between ease of use for the admin and ease of extension for the developer.
Drupal is probably the most powerful of the 3, but the trade off is in the user admin. Most non-developers will struggle to understand how the admin works or what taxonomy is and how it works. Again, the trade off is that it allows developers much more power in extending Drupal. Drupal makes it easier for the developer to accomplish much more complex tasks than Joomla or Wordpress.
At the end of the day, all 3 can accomplish the exact same thing on a website. You need to determine which one will accomplish your particular needs the best.
That said, you should still learn HTML and a programming language. My recommendation would be to learn PHP and mySQL. That will give you a solid foundation on which to build on once you are well versed. Other languages and flavors of SQL will come easier, plus many of the large open source projects are done in PHP/mySQL.
Since what you are trying to do is a pure learning exercise, I suggest you look around into a lot of things(rails/css/javascript/php etc) until you finally find the one that you will have fun playing-with. You learn faster when you can tinker with it.
Ruby on Rails may 'seem' easy to an advanced web developer. Its an advanced framework and needs considerable amount of investment in terms of time and interest and most importantly you need to have an aptitude for it. If you REALLY want to do this, and you have a general aptitude for Web programming, I suggest you start with Wordpress. Its search-engine friendly and will get you running in no time.
Learning we development and design is not a small task. It'll take you years to get even moderately good, so if you need to get something up and running now, I'd not recommend you to build it yourself.
There are a lot of nice Joomla templates and plugins available if you are ready to pay a small price for it. Search around a bit more, and you might find something that works for you.
I would start with a CMS such as Joomla or perhaps even Wordpress. Grab a template and tweak it - this will be a good introduction to coding websites as the really hard parts are already taken care of.
Once you have finished the site that you are working on then you can think about moving on to a framework such as Rails or even a PHP based once like Code Igniter. The frameworks will take a lot longer to figure out but at the end of the day they will give you a better learning experience then just tweaking a CMS template.
I would say it depends on your goal. As mentioned they have different purposes. That said I would say Joomla or Rails.
If you are interested in CMS (or design), and don't want/care about getting down and dirty into coding then I would use Joomla and learn what you need to acccomplish your goal.
If your goal is to be able to develop custom web APPLICATIONS, I would probably learn Rails. There is much more of a learning curve but you will get experience with things like html5, javascript (or coffeescript), css3 (or sass), exposure to the MVC model (model view controller) and exposure to Ruby.
But with Rails there is a lot more to learn, but you will have a lot of knowledge.
If you want to go down the rails path, maybe start with a Rails CMS (like locomotive or refinery) b/c they are written in Rails, you could look at the code or have some insight into the CMS. Disclaimer I have not used a Rails CMS (just did some research)
I would choose Joomla. They have a vast array of components and modules that should meet your needs. As far as customization, if you are a beginner this will be difficult no matter the platform. DHTML is not a platform. DHTML is mainly javascript, css and php. I suggest you get some books on doing dynamic stuff with javascript and jquery, styling with css and creating MVC sites with PHP. When you learn all this first your job customizing an whatever platform will be much much easier.
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a boss who is convinced learning Rails is too steep a learning curve and not cost effective from a labor standpoint when straight Ruby running as a CGI app on Apache is available. He is proposing, for our rewrite, that we use straight Ruby w/ no framework rather than Rails (or Merb, Sinatra, etc.) I believe in my heart that this is a bad idea but I'm having trouble putting my case into words. Some ideas I've come up with so far:
Rails promotes better code reuse and better separation of concerns via MVC
A shop running rails will look more attractive to the qualified job seeker, since Rails looks better on his/her resume, is more fun to work with, etc.
(I may be wrong on this one) Rails will have better performance on Passenger because Passenger automatically pools connections to the database where as a handrolled CGI app would have to manage that itself or not at all resulting in worse performance.
Rails is a proven technology, at least certainly more than a handrolled CGI framework
Are there any reasons I'm missing or wrong about? Are there valid tradeoffs I'm not aware of?
There are occasionally good reasons for a company to roll their own framework instead of using a standard Rack-compliant framework. But "Rails has too steep a learning curve" is not one of them.
Doing it brute-force is actually more complex, rather than less. If your boss is really worried about learning curve, he should use the standard framework that has documentation and articles and screencasts and entire hosting companies dedicated to it.
Besides, Rails is dead easy to develop for. I've taught one-day workshops on Rails, and even people who have never programmed before have a working, deployed app by the end of the day. Experienced developers have an even easier time of it.
If your boss doesn't understand Rails, and rather than figure it out, he's giving you this line about Ruby over CGI...be careful. Technology left him behind 15 years ago, and he's no longer qualified to make technical decisions.
He should be moved into marketing without delay.
Does your boss have any reasons for his conviction? Other than "a feeling"? What are his real concerns - you won't have much success in changing his mind until you have worked out what his underlying concerns are. Don't be surprised if they turn out to be substantially different to what he's currently saying. He may have an irrational fear of Danes, for example.
Do you have any concrete reasons for disagreeing?
As a boss, I wouldn't be too swayed by the reasons you list so far: good design/coding practices don't need a framework, recruitment isn't your concern, performance optimisation? Don't do it? How more proven than CGI? (He might say, not me: I drink the Rails Kool-aid every day).
Is he technical in a current sense? I mean, will he be involved in coding the rewrite? If so, might he be open to a challenge? Pick a subset of features, buildable in a day or two and try it both ways. If he's not technical, why does he think your opinion is less valid than his?
If he's concerned from a cost/effort perspective, why does he believe that writing less code (and getting thousands of lines of useful, tested framework code for free) is more costly and/or more effortful than otherwise?
Someone else has already mentioned "managing up" - I suggest Googling for resources on ways to work on this.
Are there other members of a team involved? How do they feel?
Martin Fowler famously (in the Agile world at least) said something like "if your organization is not doing what you think it should, you should change your organization". There are at least two ways to read that...
I think a potentially great idea would be to use parts of RoR(Cough ActiveRecord) and roll your own stuff if it simplifies things... I'm not a framework kinda guy, I prefer libraries and a certain degree of code abstraction, which is why I could never be mistaken for a RoR fanboy... but I think getting him to use certain parts of rails, might turn into using all of rails.
Only other point I would like to make is that MVC isn't rails only and if you rolled your own then you could very easily follow that design pattern... besides rolling your own can have benefits... for one thing, you'll know exactly what everything does and how it works, self rolled would mean a leaner system, that you can modify more easily...
My final answer is meet in the middle... Ruby is EXTREMELY powerful in the hands of creative programmers... in fact, I'm in the process of re-rolling my 2 months of rapid "throw-together" php/jquery prototype into a erb/jquery site...
--Thinking out loud--
Not trying to crap on Ruby on Rails... but Rails are what trains go on... and trains do go fast... but they only go where the tracks take you. I'm more in favor of a "Ruby off Road" environment. Less speed, More control.
Using Ruby on Rails versus just Ruby is the difference between buying an automobile and welding a unicycle out of a single tire: both will get you where you are going.
At heart though, I think this is less a technological issue and more an issue of "managing up" as the decision NOT to use Rails is so laughably bad at this point as to be nonsensical.
I think you have two options:
Sort out a way to make it seem as if using Rails was your bosses idea all along. You might say something like: "Boss, I've heard what you've said and so instead of using full blown Rails, I'm just going to use it as a basic framework and do most of the work in straight Ruby."
Take the initiative to do a prototype of the development over a weekend, give your boss something provable that says: "This is clearly the way to go".
Good luck.
It's not a very steep learning curve. You might want to ask him to walk through a tutorial before making a decision.
Also, a big advantage is that RoR is a pretty popular system right now. Installing plugins is trivial, there are many deployment options already figured out--basically a lot of the work that isn't directly "Programming" will probably be easier.
And active record--it's so useful that it's difficult to imagine doing a web/database app without it any more.
I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.
We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.
After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:
So I thought it would be about time to
set the record straight on a number of
unfounded fears, uncertainties, and
doubts. I'll be going through these
myths one at the time and showing you
exactly why they're just not true.
This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn't
founded in the many myths floating
around.
Let's Clarify!
Myth: "Ruby on Rails doesn't scale"
Bust: That is not a specific, answerable question. Please clarify.
Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:
"What precisely do you mean by 'scale'? and how do you measure it at the moment?"
It could mean:
Maximum user sessions
Average response time given load
Throughput of given concurrent scenarios per server in a fixed time.
... difficulties organising the project so a large team of developers could work on it.
There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.
There are loads of ruby-based solutions, including
caching fragments of HTML
sharding the application across multiple databases
pre-computing work that's shared between users
pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
using a front-end web server more efficiently
just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
doing less interactively and having more batch work
doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend
If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.
However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.
Make the argument from the only perspective the client understands, money!
Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.
In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:
1) Why Rails?
Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)
http://www.theserverside.com/news/thread.tss?thread_id=33120
2) Rails doesn't scale
http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html
3) Rails is just a CMS?
If they are building a CMS then recommend Drupal, not Rails
I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job
Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.
Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.
Myth: it is hard to hire a good Ruby on Rails programmer.
(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)