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."
To me that's poor planning (Score:4, Interesting)
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)
- I still have to program it
- We already knew PHP
- Rails has features I didn't use
- Rails has too many features
- I didn't really want to change my thought process
- I like my way of doing things
- 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...! (Score:4, Interesting)
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.
Re:thinking about something new? think again (Score:3, Interesting)
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 brighter...you 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."
Re:Why rewrite existing systems? (Score:5, Interesting)
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
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)
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.
Re:thinking about something new? think again (Score:2, Interesting)
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
CDBaby.com (Score:0, Interesting)
Re:thinking about something new? think again (Score:5, Interesting)
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:
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:
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:Why rewrite existing systems? (Score:2, Interesting)
Re:Why rewrite existing systems? (Score:1, Interesting)
* 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.
Re:Why rewrite existing systems? (Score:1, Interesting)
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').
Another option: OKWS and C++ -- really (Score:1, Interesting)
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)
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.)
Re:Why rewrite existing systems? (Score:3, Interesting)
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...