Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Programming IT Technology

Thinking about Rails? Think Again 482

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."
This discussion has been archived. No new comments can be posted.

Thinking about Rails? Think Again

Comments Filter:
  • by RaigetheFury ( 1000827 ) on Sunday September 23, 2007 @09:25AM (#20718587)
    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.
  • article: -1, troll (Score:4, Interesting)

    by Verte ( 1053342 ) on Sunday September 23, 2007 @09:37AM (#20718635)
    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.
  • by bogaboga ( 793279 ) on Sunday September 23, 2007 @09:39AM (#20718643)

    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.

  • by ducomputergeek ( 595742 ) on Sunday September 23, 2007 @09:52AM (#20718727)
    I do the technical coding for a couple web designers (they make it look pretty and I make it work). Typically their clients have done enough research to have heard some buzz words so a typical conversation goes like this:

    Client: "We'd like our site/new site to be Web 2.0 with AJAX and Rails and....

    Web Designer: "This is the layout I've created with new logo, etc."

    Client: "Ohhh, that's pretty, but I don't like that shade of >, could you make it >, maybe a couple shades darker, but know what I mean?"

    Web Desiger: "Sure"

    Me: "Okay now what are you looking for the site to do?"

    Client: "We want our site to be Search Engine Optimized, with built in Web 2.0 features."

    Me: "Okay, SEO is not a problem, we have a professional copy writer on staff that handles the ad copy for the pages. What keywords you you like to target in search engines?"

    Client: "Um...I want my page to be on the top of Google when they search for it..."

    Me: "Okay, is your site E-commerce: meaning your actually going to be selling goods from it?"

    Client: "No, just about our XYZ business. But it needs a Web 2.0 contact form so clients can email us from the web page and we can send them back a quote."

    Me: Okay, so you need a contact form (standard feature on just about every site we do). What else?"

    Client: "Well I need to be able to update upcoming events on a calender and news items."

    Web Designer: "We can use Joomla for that."

    Me: "Or we can find a news page script in Perl or PHP for that page with a nice easy to use backend. Same with an events calender. Then you can design your nice tabled based pages in Photoshop/Dreamweaver and I won't have to spend a week converting them to a CSS based Joomla template."

    Client: "PERL? PHP? That's not Web 2.0. It's suppose to be Ajax and something called Ruby on Rails! That is what > says about having your web site designed!"

    Me: *hands client copy of Cult Of Amateurs* And then i WANT TO SAY "Here read this and then get back to me about web 2.0. The short version: there is no such thing, it's a fancy buzzword no different than Dotcom ten years ago. Now we could everything you wanted on your site back then with CGI/PERL and now PHP and it will work.

    Instead I say, with a smile: "We can make it work."

  • by Anonymous Coward on Sunday September 23, 2007 @10:00AM (#20718765)
    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. []

    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
  • sad (Score:3, Interesting)

    by m2943 ( 1140797 ) on Sunday September 23, 2007 @10:03AM (#20718779)
    You know, the sad thing about all the comparisons you make is that they are all choices between bad technologies. Assembler vs. PL/I, C vs. Java, Windows vs. Linux--they're all questions like whether you want to be drawn or quartered, drowned or burned, poisoned or starved. At each of those choice points, there were better technologies available.

    As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented. After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.

    But if I have to work with bad technologies, the one that's more popular, more mature, and more widely supported one is, relatively speaking, better. That's why I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.
  • My wife and I ditched Windows for Linux 8 years ago at home. I stopped dual-booting and everything -- no more Windows, period. I still have to use it at work, but my wife didn't for years working in retail. One day, she had to use Windows at work and found it dreadful, I chuckled to myself.

    Yes, some of us are very happy over the long term using Linux. Am I a system administrator? Yes. Do I program? Yes. Am I the average Joe Computer User? No. Does my wife get a free sysadmin with the ability to recode around bugs? Yes.

    Just my $0.02, take it or leave it :-)
  • (Score:0, Interesting)

    by Anonymous Coward on Sunday September 23, 2007 @10:33AM (#20718945)
    Am I the only one that's noticed that the site in question is pretty damn ugly and seems kinda primitive?
  • 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|
        recurse(target + '/' + entry)

    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.

  • by Anonymous Coward on Sunday September 23, 2007 @11:22AM (#20719315)
    last year we made a major rollout of an application that was a rewrite of an existing application with microsoft tools, and guess what, it was a success, it outperformed the previous application and now the old system is forgotten. Lessons learned. * Use HTML, CSS, and keyboard support (onfocus, onblur, etc). * Don't understimate old software, we basically rewrote the application from scratch but using the lessons learned in 10+ years of the legacy software, sometimes working with the original developers. * Performance IS a priority, using proper OO techniques, and proper database design, performance is not an issue, even in windows plattform, sometimes the performance problems come from sloppy programming. * Benchmark your software, and test since day 1. Rewrite software is sometimes a need, particulary when the software is not actively mantained, the mentality of "it just works" avoid to look at the real problems... the systems that not change die, even the 20+ year cobol systems will die. Your post is misleading, since the problems were due bad project management, cheap developers and not in the tools.
  • by Anonymous Coward on Sunday September 23, 2007 @12:02PM (#20719645)
    The rest of those points look pretty valid to me. I don't know how you can disagree with them.

    * Use mature, well-tested, effective software (eg. Solaris, Oracle, FreeBSD).

    Why do you disagree with that point? It makes sense to me. Using proven technology, especially those ones that were listed, does help build a solid foundation for whatever software you're layering on top.

    * Avoid immature fad "technologies" like AJAX.

    It sounds like they were just building a CRUD app, like you find in most enterprises. When it comes to the presentation layer for such an app, Ajax should be more than suitable. Why do you say that Ajax shouldn't be used for those kind of CRUD apps?

    * Traditional applications offer more flexibility than Web-based applications.

    This makes sense. You do have far fewer restrictions when using non-web technologies. Using C++ with a toolkit like wxWidgets or GTK+ is a lot more flexible than HTML forms and JavaScript.

    * Sometimes a text-based interface is far more efficient than a GUI.

    I guess this can be true. It's probably why you don't see point-and-click UIs at most POS terminals. The focus there is on making as many transactions as possible, as quickly as possible. ie. Maximizing the efficiency. This is best done from a keyboard.

    * Maintain a reasonable level of heterogeneity, when it comes to software, hardware and vendors.

    Diversity like this is also sensible. It prevents the spread of malicious software, and can help contain security issues without risking the entire network. But you don't want too much of it, like the point suggests. It's all about balance.
  • by Foofoobar ( 318279 ) on Sunday September 23, 2007 @12:23PM (#20719813)
    Instantly productive like any framework will make them in any language. Ruby on Rails though has serious scalability issues that limits it in a production environment. This is why the RUBY website and RUBY ON RAILS website all use PHP on their frontend [].

    If they no longer show it's because they have expose_php turned off but several of these sites still show. They have yet to resolve their scalability issues and this is a well known issue with RUBY and why no main website uses it in production; it's only for small blogs or news sites but nothing major.

    Even 43things in their switch had to use 2 as much hardware to scale RUBY and they still had to fall back on PHP to get it to scale. The move was a nightmare (though the president keeps saying it was 'smooth').

  • by Anonymous Coward on Sunday September 23, 2007 @12:25PM (#20719833)
    There may only be 2 large websites in the world written in C++ (actually there are probably more), but if you are looking to write large websites with many tools and features and dynamic contents, check out OKWS. It's a platform for written large web site/application in C++, with security and performance advantages.

    Why don't you want to write in C++? It's too low level and does not have a lot of the abstractions already built in, like PHP, perl, etc... But OKWS offers those abstractions, from perl like regex and string operations, to all the CGI things you need. Plus reference counted memory and asynchronous callbacks. It's like written a big C++ application, but for the web. Really, it's not bad.
  • Re:sad (Score:3, Interesting)

    by m2943 ( 1140797 ) on Sunday September 23, 2007 @12:56PM (#20720071)
    If everyone had waited for heavyweight pros to address the problem, we'd still be waiting, or be working with some horrible kludge (a camel is a horse designed by a committee etc.).

    The heavyweight pros did address the problem, many times: Modula-3, Smalltalk, Sather, APL, OCAML, Haskell, Scheme, EuLisp, Icon, and on and on. What those languages lack are user communities.

    They aren't perfect, and nothing ever is, but they power a great deal of the web, very effectively and usefully.

    Ruby does not power the web; it is late to the party and offers no compelling advantages. If we need simplistic scripting languages, between Perl, Python, and PHP, we really have the bases more than covered. Ruby is superfluous. (Well, I suppose if it managed to kill Perl and replace it, that would be some minor progress, but I don't see that happening.)
  • by TheLink ( 130905 ) on Monday September 24, 2007 @02:16AM (#20725367) Journal
    Yeah, MySQL would have been a better choice than Zope.

    But, if the company grows and its database can't do it gracefully then there will be big problems. MySQL is like PHP, it will look ok when you're testing some small stuff, but when you really want to do things properly it gets really difficult (it might still be possible but its difficult and to use the technical term for it - very yucky/icky).

    For example: Say it's X years later, and after a few "problems" the company (now bigger) decides it does need to do live backups. So now you want consistent backups of a bigger database (say tens of gigs), and you need to do it without slowing the reporting, orders and deliveries etc too much (it's stockkeeping like you said).

    If you picked MyISAM, in a naive system then you'd need to lock _all_ tables otherwise the mysqldump won't be consistent. But locking all the tables blocks stuff...

    If you picked innodb, you don't have to lock all tables (yay!). But when stuff goes belly up, and you try to _restore_ from backups, you may find that the estimated time it takes to reload in X gigabytes of data into the innodb tables is more than "a few" days, which is not what you want to tell the boss or your customers (don't ask me how I know this - and it wasn't even _my_ problem). On a related note it seems that innodb has performance problems with concurrent inserts if you have autoincrement fields (weird but true).

    So one workaround is to use MyISAM, buy two or three machines. Live data = master, and nonlive reporting and backups on slaves. You can lock all the tables on a slave to make a consistent snapshot and not stop the master (basically you are badly reimplementing MVCC).

    The recommended option of course is don't use MySQL. Forgive my ranting, but the fewer MySQL systems out there, the lower chance of me one day inheriting yet another crappy MySQL system.

    Same goes for PHP too - braindead bad designs like magic_quotes, addslashes. Then there's peardb vs pdo vs mysql_escape vs mysql_real_escape vs mysql_definitely_real_escape_this_time_no_really. OK last one's a lame joke (for now?) but so's much of PHP.

    Sure mod me flamebait, but mysql_real_escape says it all...

All laws are simulations of reality. -- John C. Lilly