Thinking about Rails? Think Again

wolfeon writes "In 2005, Derek Sivers of CD Baby wanted to scrap his site and perform a rewrite in Rails. He hired Jeremy Kemper, also known as bitsweat on Freenode, to help on the project. Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project. Mr. Sivers has written an entry in the O'Reilly blog: 7 reasons I switched back to PHP."

To me that's poor planning

[RaigetheFury (1000827)]

Every technology out there has it's benefits. It's the job of the person planning the project to explore all of these technologies before they choose one. If you read his article, he makes no comments as to why he chose Ruby on Rails. Was he following the hype?

I've been involved in the decision making process to choose a technology for writing a site many times. Working for a University common questions we use in comparison to the technology is

1) Development time
2) Ability to integrate with LDAP or other existing technologies
3) Support (server level)
4) Documenation (For development)
5) Budget
6) Number of developers on the project

Depending on those variables it usually winds up being either PHP or Cold Fusion. Ruby on Rails has never once been a consideration. Not because it isn't a good solution, but it's never once been the best for our needs.

7) How far will it scale

[giafly (926567)]

After 30 years development, "How far will it scale" is

• the question that scares me most,
• the one that you can never get honest information about from OS or component suppliers,
• and the one that's hardest to test because the most-used features are rarely those you expected.

Who said "prototype the thing, assuming a worst-case scenario"? No can do. With server code, this means you leave out features or spend $$$s more on hardware. And with client code such as AJAX, you know anything could break if used alongside idiot third-party widgets or when another IE patch makes Javascript even slower. You just don't know exactly where it will break in practice. So you add a lot of logging and try to spot when the next bottleneck is approaching. Worst case, it's in obfuscated, third-party modules that you can't change in practice, and you're re-factoring masses of code while angry villagers are breaking down the door. This is IMHO a risk with programming frameworks like Ruby on Rails, or MS dotNet for that matter.

Languages are just tools

[Monoman (8745)]

It is all about choosing the right tool for a job. Sometimes you use a new tool and you wind up feeling like you are trying to put in a screw with a hammer. Sure it will work but not the way you want.

Sometimes you go back to the tool you know how to use best.

Re:Languages are just tools

[Jeff DeMaagd (2015)]

The problem I have with the "languages are just tools" adage is that they are about the most complex tools one can use, I mean hammers and screwdrivers have nothing on them. What might undo a project might be because of an obscure limitation of the language that wasn't known at the time of designing the project.

That said, I don't know much about Ruby or Rails, but I've heard that you have to follow the conventions or you're just making things hard. You can just not follow conventions, but it's just adding another pile of problems that defeat the point of using Rails.

What an idiot

[by Anonymous Coward]

"All the cool kids were using Rails, so I decided if I wanted to be cool, I had to completely switch to Rails in one big jump!"

Very uninformative article

[DaleGlass (1068434)]

There's a complete lack of points against Ruby in that article. And I don't say that as a fan, I don't know the langauge at all. It's just got a complete lack of any useful information to judge the usefulness of Ruby.

Reasons:
#1: Seems a very weak criticism, all languages are interchangeable really. Except some do some things much better than others.
#2: Internal management problem, not really related to Ruby specifically.
#3: Applies to every language
#4: Potential for real criticism here, but without any DATA it's completely useless
#5: Works for whatever language the author likes, again not related to Ruby
#6: Potential for more real criticism here, but again lacks any useful information
#7: Again something unrelated to Ruby specifically

From the whole list, only 2 of the reasons point to Ruby in any manner, and those are so uninformative as to be useless anyway. I think most of the blame for this lies with slashdot, as the article tries to spin it into something against Ruby when the actual article is more about a failed migration than anything else.

Re:Very uninformative article

[discord5 (798235)]

I have to agree with you. I've been through a few webprojects in perl, php, rails and struts. Perl is my favorite, but that has largely to do with the jobs I had to do in the past, and it's certainly not the only language to get to a solution.

The only thing that I'd have to agree with is that Rails does take up a bit more resources than the average PHP application (#4), but rails like any other framework does allow you access to your database. It's very well documented in Agile Web Development on Rails [pragmaticprogrammer.com] (not being paid, just giving an example I know of) where they introduce Active Record, and there's an small section on the subject itself. I'm pretty sure it's somwhere in the API reference as well.

Some languages are more suited than others for a certain project, so it's perhaps more important to do a proper analysis of what you want to achieve and what languages will help you most to achieve those goals. The author offers very little detail into what exactly went wrong with his project, except that it didn't go as smooth as planned (welcome to the 90% of all projects, pull up a chair and have a drink).

Finally, even though the article mentions he hired a programmer, it's often wise when learning a new language/API/tool to start with a small application so you'll get a firmer grasp on it. That way you'll get a better feel for possible trouble ahead. Sure, we don't all have the time to do that, but in that case it's often better to stick to what you know and what works for you instead of blindly charging forth and trying to ride the latest wave of technology buzzwords. Not that I'm saying that RoR is just a buzzword (it's pretty neat actually), but don't use it because it's hip. Use it because it solves a problem more easily than another language/framework.

article: -1, troll

[Verte (1053342)]

New article summary:

1. I still have to program it
2. We already knew PHP
3. Rails has features I didn't use
4. Rails has too many features
5. I didn't really want to change my thought process
6. I like my way of doing things
7. How I justified trying something new.

I'm not saying that these aren't valid- save 1 and 3, maybe. But they aren't new, and aren't interesting.

He was incompetent...!

[bogaboga (793279)]

Two years later, through blood and sweat, the project was then canceled because of limitations of Rails.

While I do not doubt the hired programmers coding skills, I am afraid he was incompetent at planning.

It's like choosing ISAM as the DB engine in MySQL instead if InnoDB then expecting to implement [referential] integrity using your own code.

The fact that it took two years to realize imminent failure disturbs my mind. The worst thing is that this coder might have been an Open Source enthusiast that I'd expect to know better.

I am afraid no home work was done or whatever home work was done, it not good enough. The results speak for themselves.

Misleading summary

[Craig Maloney (1104)]

I read the article, and I believe the reasons the author switched back to PHP was because he was more comfortable with it than Ruby. If you read deeper, you'll note that he appreciated the experience in dealing with Ruby, and brought some of it back with him to PHP, but he did not think it was right for his application. Seeing this as a "OMG! Ruby replaced with PHP!" is just another fanboy reading into it what he will.

Time to calm down here, people. Just because one person sees value in another set of tools doesn't mean you will too.

(I'm the author of the article) - Please read:

[linuxbaby (124641)]

Hey gang -

Longtime Slashdot reader, surprised to find my little personal blog post on Slashdot today, especially since the lead-in description framed it with the completely wrong point.

I never said "the project was cancelled because of limitations of Rails" - more like I spent two years trying to make Rails do something it wasn't meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

That's all.

Re:(I'm the author of the article) - Please read:

[icepick72 (834363)]

This whole debacle on Slashdot isn't a result of the lead-in description. Anybody who has commented on the 7 points has read the original article in its entirety (well, hopefully!). There are many good discussions occurring around your points, some favorable, some not, but it's all good in the end.

I have one burning question: What is the take of Jeremy Kemper (aka bitsweat) on this situation? Being "one of the best Rails programmers in the world", many of us would like to hear from him. Has he blogged or posted about this too? (need a link) Does he share the same view points on the situation?

#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS

[Dr_Barnowl (709838)]

This is his best point.

My VB coding improved immeasurably after I learned C#. And I'm not just talking VB6, I'm talking VB3 as well.

Learning a new language can teach you to do so much better in your old ones. I am *still* more productive, if you want something fast, in VB6 than I am in Java or C#. I can knock together a small cheap GUI very fast.

Of course, sometimes you do run into the limits of your chosen platform. VB6 strings are all 2-byte unicode internally, which makes dealing with UTF-8 a real pain. Then the ugly kludges start coming out.

To get things straight: Rails did *NOT* invent MVC

[Qbertino (265505)]

Rails did not invent MVC, nor did they invent scaffolding or any of the other stuff. They didn't even make it popular. Very many people get these facts wrong. The only thing Ruby On Rails did as a first was to apply professional marketing strategies when trying to make an open source web application framework popular. They were the first to build a project website that was appealing to the eye more than anything else and they heavyly pushed the concept of the screencast, right when broadband was becoming commonplace. I'm shure almost everybody has watched that famous 'a blog in 15 minutes' screencast. This screencast alone made Rails (and the editor presented in it, Textmate) extremely popular.
Technology wise there are many frameworks and webkits that are far more mature and far more sophisticated than Rails and have been around for 6 years and more.

Re:Why rewrite existing systems?

[by Anonymous Coward]

This reminds me of a similar incident I saw on Reddit a few months ago:

Sometimes it's best to leave old software systems alone.
http://pinderkent.blogsavy.com/archives/88 [blogsavy.com]

Last night at the pub, a friend and colleague of mine was telling me of a recent experience he had at a company he was doing some IT work for. I think the lesson learned is a very important one, and thus I wish to share it. But first I'll describe the situation he encountered.

In the mid-1990s, the company in question built their IT operations around systems from Sun. They wrote much of their in-house code using C++, and used Oracle for their database needs. On the front-end, they used PCs running a mix of Windows NT 3.51, FreeBSD 2.x, and even OS/2, depending on the department. While that is not a unique setup by any means, what is somewhat unique is that they essentially continued to use those same systems up until 2006.

One of the main reasons why they didn't switch is because their software systems worked just fine, even if the UIs were somewhat archaic. Their software was mature and well-understood by the company's employees. They even got extremely lucky in the first place, as the developers who initially designed and implemented their software systems did so in a way that allowed for the systems to easily scale as the need arose over time.

The hardware proved to be the main instigator of change. After a decade, many of the front-end PCs they were using started to exhibit a variety of physical problems. Some had been replaced earlier, but eventually it was decided to replace them all with newer systems. However, to the best of my friend's knowledge, the back-end Sun systems were working just fine.

However, at the same time they decided to also replace the back-end systems. A variety of consultants were apparently called in to appraise the situation. For whatever reason, it was eventually decided that the new back-end systems would be built around Windows Server 2003 and SQL Server 2005. The new back-end software was to be built upon .NET, while Web-based client-side apps would be developed and used. My friend wasn't sure exactly when this effort started, but he believed it was in early 2006.

By the end of 2006, the consultants and developers deemed the new system ready to go. Over the course of the December 2006 holidays, the new systems were rolled out. It turned out to be a pretty major disaster. The first problem they ran into was a complete lack of performance. As they moved into the first weeks of 2007, their back-end systems just wouldn't scale. As an emergency fix, they ended up throwing more hardware at the problem, which did ease the burden on the existing servers somewhat. But it was in no means a permanent solution.

The front-end software systems proved to be an even bigger disaster. Many of the AJAX-based applications used Internet Explorer-specific functionality. But the IT managers of some of the front-end networks would not allow IE to be used, for security reasons. They only allowed for Firefox to be used. So the Web-based front-end software needed significant modifications right away, as well.

What was perhaps the worst failure involved the in-house users and their productivity. Large portions of the old system were built around a curses-based UI. Although it apparently wasn't very pretty, it did allow for a great deal of user productivity. One of the main complaints about the new Web-based software was that the keyboard support was quite poor, requiring the user to select input fields using the mouse, and at times even having to scroll the page to input or manipulate certain data. With the earlier system, the nagivation could rapidly be performed using just the keyboard. Some of the more experienced users were apparently so efficient with the older system that their productivity was reduced to 25% of what it was before the switch.

My friend and his colleagues were called in to try to

Re:Why rewrite existing systems?

[man_of_mr_e (217855)]

I disagree with the vast majority of those points. The only two that I agree with is giving consideration to scalability and getting user feedback. The rest are illogical conclusions based on a failed project whos real failure was poorly specified requirements.

Certainly, Web UI's are not appropriate for everything. They should really only be used if there is some overpowering need (like the ability to access the data from anywhere without having client apps installed). They also apparently gave zero thought to existing processes and staff skillsets.

Avoiding AJAX or any other technology because you tried to use it for something it wasn't good at is patently stupid. There are good uses for the technologies. This just wasn't one of them.

Re:Why rewrite existing systems?

[betterunixthanunix (980855)]

I thoroughly agree with you on this one. Unfortunately, I stand alone when I ask a question like, "What has a GUI added to this system? Why wasn't a text-base solution sufficient?" People think I am some kind of lunatic if I propose a non-AJAX/Application Server/wiz-bang solution to a problem. I understand that sort of mentality from end-users, but from programmers?

My advice is to analyze the needs of the system before designing it. Don't assume a GUI or AJAX front end is the best possible way to do things. My favorite example is the library system in my county: their computers are using a console system for check in/check out, card processing, etc. The beauty of it is that the bar code scanner they use behaves like a keyboard, so that each scan is just a series of a numeric keystrokes following by an end-of-line. It is simple, the 80 year old librarians have no problem using it, and it doesn't require any difficult to coordinate mouse movements (as anyone who has studied this knows, using the mouse requires a lot of brain activity than using the keyboard). The console very accurately maps the workflow; a GUI wouldn't add very much, other than sheer lines of code, and a web interface would actually slow down the people who need to use it.

Sure, there are cases where a GUI or web interface is better than a console interface. But that is why an analysis is needed before any code is written. As your friend's situation demonstrates, a well design system can work for many years without any trouble.

Re:Why rewrite existing systems?

[u38cg (607297)]

The biggest problem, as I see it, is that the people who make major strategic decisions on IT don't have a clue what they are talking about. It's happening in my company right now - a consultant is being paid vast amounts of money to essentially write an ERP from scratch, for a company that doesn't need anything more complex than a decent accounting package that can handle more than one operating site. The guy is being paid a monthly fee and has no written specification or brief. He has no deadline and no agreed feature set. On a regular basis he turns up and spouts off his latest idea, solving a problem we don't have. The bosses, who know their business but don't know technology, are completely clueless and are pretty much at the whim of this chancer.

Re:Why rewrite existing systems?

[turbidostato (878842)]

I just can't understand how your input data makes you assume your conclussions. Except from the "why change a system already working just OK?" which I'm 100% with you, I extract very different ones from your provided data:

"In the mid-1990s, the company in question built their IT operations [...] They wrote much of their in-house code"

I read here: in the mid 90s the company built a tailor-made IT system engineered by their internal knowledgeable technical staff.

"what is somewhat unique is that they essentially continued to use those same systems up until 200what is somewhat unique is that they essentially continued to use those same systems up until 2006."

We know their staff was knowledgeable and that the system fitted well their needs from the simple fact that it managed to work about 15 years without major complains.

"One of the main reasons why they didn't switch is because their software systems worked just fine"

Exactly what I was saying.

"They even got extremely lucky in the first place, as the developers who initially designed and implemented their software systems did so in a way that allowed for the systems to easily scale"

Do you think that's "luckyness"? That properly scalable systems grow up "per chance"? No: it was properly designed, that's why the system scaled, not because "luck".

An now, for the problems:

"A variety of consultants were apparently called in"

I read here: A variety of *external* resources that surely couldn't know the bussiness better than their old internal counterparts (things cannot be done much better than "OK", and that was the standard to beat), and that surely held their own agendas (like pushing the technologies they are knowledgeable about, instead the ones that best fitted, if only because the old "for a man with only a hammer every problem seems a nail", if not worse, "Certified Microsoft Gold Partner That Gains Money Every Time Microsoft Technologies Are Pushed Into A Client") were in place to design the new system.

And this is the very and only problem: By the 90's they had knowdledgeable internal staff. By 2006 they went to external unfitted consultors. I bet there's an untold story here that includes those "so expensive" Solaris sysadmins and C++ developers that were fired by a "smart" manager looking for profit. All the particular problems you outlined are not problems but consecuencies of this. Of course the new web-based GUI could be Firefox-tested -if knowledgeable people were in charge. Of course the new web-based GUI could make use of proper keyboard-based navigation -if knowledgeable people were in charge. Of course that the proper ammount of iron could have been pushed on the backed (specially after 15-more years of stats and usage-patterns) -if knowledgeable people were in charge.

No one of them are strictily speaking problems with AJAX, or Windows, or dot-net, or whatever the technology (while going from a perfectly working C++/Unix environment to an all-and-only-Microsoft is a very hard hint about management going nuts). All of them can be pointed out to a very common tendency on IT: fire the old knowledgeable technicians that put the means for the company to grow and stay there in first place and contract cheap minions and expensive external consultants as substitutes; then look as a very smart manager that saves the company some pennies; then the obvious "???" and finally the "wreak havoc" instead of "profit".

Re:Why rewrite existing systems?

[Slim Backwater (550617)]

I submit to you, my fellow slashdotters, the parent post for the most ironic post ever. Such a long, insightful post about how to do a successful software deployment, and then not clicking preview to realize that the formatting of your list is all screwed up. Only posting as an A/C saved you a year of personal shame.

Re:Why rewrite existing systems?

[B'Trey (111263)]

I don't see anything in the article that actually states why he chose Rails in the first place.

Even worse, there's absolutely nothing there about why Rails didn't work. Exactly what was it that was so hard to do in Rails that was easy to do in PHP? The article provides nothing useful to anyone looking to build a web site. How do I know if PHP is superior to Rails for my particular application? There's little there to help. This is nothing but a senseless rant.

What a false dichotomy!

[-kyz (225372)]

I've now written two large business applications in Rails. I did the UML modelling first. Then I wrote a fully constrained RDBMS schema, normalised to 3NF, using the Rails naming conventions. Then I wrote the Rails app on top of the rigorously constrained database.

If you want multi-key uniqueness constraints, just define it in your database already! Why do you think Rails prevents you from configuring your database layer?

When I need to do transactions, I use Rails' full support for transactions [rubyonrails.com]. There, that wasn't so difficult, was it?

I let Rails save me hours of backbreaking labour writing conventional SQL queries. Then I use the completed application, identify the query bottlenecks (thanks to Rails' built-in profiling) and re-write the slowest of the dumb auto-created SQL using hand-written SQL, which I can get to using find_by_sql [rubyonrails.org], finder_sql [rubyonrails.com], etc. Rails lets you put your own SQL into the application almost anywhere.

Re:thinking about something new? think again

[TheRaven64 (641858)]

I really don't understand the point or Ruby. It seems like it's semantically similar to Smalltalk, but with uglier syntax. Is it faster? Apparently not. [debian.org] On average, Ruby is 1/5 the speed of Smalltalk, and in some cases much worse. In only one test was it faster; startup (not important for long-running processes, such as stateful web apps).

So, we have a slow language, with ugly syntax. The ugly syntax is subjective, so we'll overlook it for now. We have a slow Smalltalk, but maybe the framework makes up for it. Looking at Ruby on Rails, it seems like a cheap clone of the old NeXT WebObjects (cloned as GNUstepWeb and SOPE, uses Objective-C, which is typically faster than Smalltalk), and so far behind something like Seaside [seaside.st] it's not even funny.

So, why do people use Ruby? Or is it like Java, as Guy Steele said:

And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?

Re:thinking about something new? think again

[19thNervousBreakdown (768619)]

Try Ruby, code up a project in it after you actually understand the language, and you'll see the draw. For instance, just an hour ago I was writing a quick script to recurse through directories and apply ReplayGain. I had a loop like this:

Dir.foreach(target) do |entry|
  if File.directory?(entry)
    recurse(target + '/' + entry)
  else
    dostuff(target)
  end
end

Later on, just on a whim, I decided I wanted it to sort the dir listing so I could judge how far it was through the process. I only had to change the first line:

Dir.entries(target).sort().each() do |entry|

A teensy tiny sript to be fair, but that's just an example that I was able to pull out of the last couple hours, I've done much larger things but it'd be hard to think of a good example. There's nine different ways to do everything, and they all work exactly like you'd expect. There's a million things that allow beautiful constructs, like lambda functions and yield statements, implict reference but easy to do deep copies, it goes on and on. The langugage is just an absolute joy to work with, and I'm saying this as a hard-line strict ANSI C++ programmer--so much so that I still find it hard to make myself use long long.

The problem is, it's so easy that it attracts people who hardly understand programming. It also makes you want to try out weird new ideas. I've never looked very hard into it, but from everything I've heard about Rails and its almost code-generation level programming I get the impression that it's a great idea that got over-engineered to Frankenstein proportions, like the first home project of any size a fledgling programmer makes. Not saying these guys are that ... just that's what it reminds me of.

One good measure I try to follow is, if you have to basically learn an entire new language to use your product, be it a framework or a word processor, unless you've purposefully designed it as a language, with all the deep thought that goes into that, you're probably doing something wrong. Really, the yardstick I try to go by is, you should only have to learn one thing to progress further, never two things at once, and it should always be apparent what directions are available. I looked over the Rails documentation and example source, and it doesn't meet that criteria.

Ruby Isn't Rails. Check out the language, it's a thing of beauty, and it allows you to do things really quickly, really easily, and most importantly, the Right Way without a lot of extra effort (an area C++ fails miserably at, unfortunately). No, it's not the fastest language by a long shot, but haven't we always said that premature optimization is the root of all evil? They can (and in all likelihood will) fix that later. Plus, given how easy it is to add inline C, which can easily interact in both directions, make calls, construct objects, etc... well, when I discovered that it was like I was banging a smoking hot woman, who to be fair is a little slow, and I found the keys to a Porche at the bottom of her vagina.

Re:thinking about something new? think again

[TheRaven64 (641858)]

Nice strawman reply. To my question 'why would you choose Ruby over something like Smalltalk,' you replied 'because Ruby is better than C++.' While this is true, most things are better than C++. The only advantage C++ has over languages like Smalltalk, Lisp, Haskell, OCaml or Ruby is execution speed.

Everything you've said is good about Ruby also applies to Smalltalk, which uses blocks (closures) to implement all control structures, has trivial syntax (the entire language can be defined on a single piece of paper, and taught to small children with no programming experience in a few hours). It's obvious that the choice between Ruby and C++ is not necessarily simple; Ruby has higher-level abstractions, C++ has faster execution speed, so the choice depends on which is important. The question is, why would you choose Ruby over any of the following:

• OCaml
• Haskell.
• Common Lisp.
• Smalltalk.

These all have the same high-level abstractions as Ruby (more in some cases). They are all mature languages, and they are all 5-50 times faster in terms of execution speed than Ruby. I understand why you would choose a slow-and-expressive language over a fast-but-less-expressive one, but why would you choose a slow-and-expressive language over a fast-and-expressive one?

Even Objective-C can do most of what you claim is great about Ruby, and some other things. For example, I have a category which allows me to send messages to arrays as if they were individual objects and have it perform a map operation in Objective-C, and I've implemented futures in the language, and yet I would still choose Smalltalk over it for anything where speed is not critical.

I would hope, by now, that everyone knows that pretty much any language is better than C++, so 'better than C++' is not much of a recommendation anymore.