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."
Why rewrite existing systems? (Score:2, Insightful)
One of my main customers hired a good team in Vietnam who used PHP, CSS, HTML, and Javascript. I introduced them to Rails a year ago, and they were just about instantly productive.
Deploying Rails can be a small hassle, but there are now lots of good options, including running on JRuby/Goldspike/Java app server.
thinking about something new? think again (Score:3, Insightful)
After twenty five years watching technology try to not suck, one note rings true from The Fine Article. The new girlfriend always seems better... at first. But over time you'll likely discover she too (as one might expect) has foibles, idiosyncrasies that annoy and sometimes downright frustrate.
If you've found a solution to a problem, consider carefully wrapping some other technology around it just because. Unfortunately my experience was that usually new technology/approaches typically were just because, usually driven by management (not always, and I'm not blaming them).
Had I known then what I know now I'd have fought harder for status quo on a lot of big projects.
Planning is key. (Score:3, Insightful)
Heyho I didn't read the artical but if i've learnt anything (hahah like hell i have), then its planning is key. Plan your project and find a language that works, not the other way around.
Languages are just tools (Score:4, Insightful)
Sometimes you go back to the tool you know how to use best.
What an idiot (Score:4, Insightful)
Very uninformative article (Score:5, Insightful)
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.
Sensationalist without a clue (Score:1, Insightful)
Why the hell would you take a system written entirely in PHP and add to it / rewrite some of it in a different technology?
I love Rails, and if I have my way I will never touch PHP again. But if I join a company who's intranet is all PHP, then by golly I'm going to use PHP!
This guy is a sensationalist and not worth the attention.
Re:Languages are just tools (Score:5, Insightful)
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.
Misleading summary (Score:5, Insightful)
Time to calm down here, people. Just because one person sees value in another set of tools doesn't mean you will too.
Re:thinking about something new? think again (Score:3, Insightful)
Then again, if this article is any indication, maybe I had better wait another year before I speak.
Re:thinking about something new? think again (Score:4, Insightful)
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:
Yeah, the One True Way (Score:3, Insightful)
7) How far will it scale (Score:5, Insightful)
- 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.framework != language (Score:2, Insightful)
people get too tied up with cms's that they think will do everything. code a plugin yourself (assuming a decent api is available).
Re:Planning is key. (Score:1, Insightful)
It makes little sense to sit down and think through an entire non-trivial project, especially when it involves a new technology that you and the developers know relatively little about. You'll surely run into technological roadblocks that there really isn't an effective way around, unless you throw out a lot of the code you've already written. So now you're not only rewriting your code, but you also wasted a long time planning that which you now cannot do.
So the only solution is to be able to manage change effectively, and swiftly. Do a minimum amount of planning, and then get to work solving the problems that you will not have anticipated during your planning sessions.
Re:He makes good points, but (Score:3, Insightful)
And, I think you're pretty much right on about his other "points." The slashdot summary of his post is entirely misleading and total flamebait--and not written by him. I think the guy is just inexperienced and crawled back to PHP out of a lack of wanting to change his mindset. He does in the end give Rails some credit for introducing him to a logical MVC structure, and I doubt he meant to flame Rails. He just happened to make mostly subjective and uninformed points to justify going back to what he already knew... I'm guessing he named his post "7 reasons..." before actually counting the reasons. Blogging is teh hard
Article Does Not Make Much Sense (Score:3, Insightful)
1. There is nothing that PHP cannot do that Rails cannot do - Well of course, and there's nothing that any language can do that Common Lisp cannot do. Almost all languages implement a Turing machine and can be used to solve any computational problem. The question is code readability, syntactical sugar, and adaptability, all important concepts. Also, the community that has grown around it that builds a knowledge base and plugins and libraries.
2. Their entire company worked on PHP and integration was difficult - Sounds like they didn't understand RPC and services models. Sharing between different languages and platforms is an unfortunate fact of life. Also, it sounds like PHP was the problem here, not Rails, if interoperation was such a problem. "Interoperation" in the article is used oddly - it's actually more about transition to a new site, which has nothing to with the platform used and, if is such a heinous problem, is a problem with design of the new app.
3. Didn't need 90% of Rails - Then why use it? Also, using a tenth of something is not an argument against it if it still the best tool for the job you are doing.
4. The custom solution they jury rigged is "small and fast" - Many Rails apps are small and fast - there's no statistics or analysis here for comparison.
5. The PHP custom app was built for to their tastes - Obviously. If you write a custom app it will miraculously suit your preferences and will probably be a very good solution to your problem. Custom apps if you can do them are often a good idea, keeping in mind the downside is that you don't have a community of knowledge, don't get patches for free, etc..
6. He loves SQL - Fine, don't use ActiveRecord then. Or use ActiveRecord and make direct SQL calls. This goes against common wisdom, of course, regardless of platform, but if you really want to do it, it's there.
7. Programming languages are like girlfriends? - No idea.
The bottom line is that there are criticisms you can level at Rails or any language or framework. However, you actually have to bring facts and analysis to an argument, and this article offers neither.
Re:Very uninformative article (Score:4, Insightful)
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.
Re:(I'm the author of the article) - Please read: (Score:4, Insightful)
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?
Re:thinking about something new? think again (Score:3, Insightful)
Funny, 10 years ago I ditched Windows (and OS/2) for Linux at home. I stopped dual-booting and everything -- no more Windows, period. I didn't have to use it at work because I was a college student and while I didn't have a wife, I had numerous girlfriends throughout that time period that had to use it when they were in my apartment or dorm. One day, I got a new computer and it came pre-installed with Windows XP and found it far more impressive than the kludge of shit I had been trying to do w/Linux to fit into a Windows world for the last (at the time) 6 years. I chuckled at myself for trying to hard for so many years when Microsoft actually had a product that worked for once.
Yes, some of us are very happy over the long term using both Linux and Windows. Am I a system administrator? No. Do I program? Yes. Am I the average Joe Computer User? No. Does my wife get a husband that understands the best of both worlds and a network that works happily with whatever flavor we require? Yes.
Just my $0.02, take it or leave it
Re:(I'm the author of the article) - Please read: (Score:3, Insightful)
Given that your O'Reilly Biography describes you as "Still a relative newbie among programmers, he'd appreciate any tips and advice you could give him", why is it you could pull off CDBaby in 2 months in PHP while an expert Rails programmers, including yourself as a second person on the project, could not pull it off on 2 years?
The project doesn't seem that large after all. Had Jeremy worked on comparably large Rails projects before? If so, had he experienced the same problems before. Did he flag them to you?
I'm not trying to lay blame. I have managed projects and seen the good, the bad and ugly and am always interested in getting the full story, from all the people involved, all opinions. Goodness knows I've pulled some doozies in my day that I'm embarrassed about.
Re:(I'm the author of the article) - Please read: (Score:1, Insightful)
If someone else is starting a project and considering rails this information might help them make their decision. San we heard more about what exactly was really hard to do in rails?
People are missing the last line (Score:2, Insightful)
Dumbass (Score:3, Insightful)
There's nothing wrong with PHP, especially if the current implementation does the job.
Re:Why rewrite existing systems? (Score:5, Insightful)
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:thinking about something new? think again (Score:5, Insightful)
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.
#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS (Score:4, Insightful)
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.
Re:Why rewrite existing systems? (Score:2, Insightful)
Re:Why rewrite existing systems? (Score:3, Insightful)
Once a company gets committed to a design decision made by an trendy-entranced developer, the sysadmins and users can get punished with years of suffering afterwards.
The tools stop being updated, and none of the *good* developers want to care for the ugly, unique application once the shine comes off the tools. It's like being forced to wear a magic top hat made out of steel - because top hats and magic steel were the fads when the project started.
A trustworthy, *experienced* design architect is important. Preferably someone who's been/seen the young-uns make the silly mistakes.
Re:Why rewrite existing systems? (Score:5, Insightful)
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:thinking about something new? think again (Score:1, Insightful)
The point of that particular quote is not that you should write slow code. It is that you should base your optimisations on measurements rather than assumptions -- so you only work on the real bottlenecks, so you know when it's "fast enough", and so you can make informed decisions if a particular optimisation would make the code significantly harder to maintain.
Yes, Ruby (like most scripting languages) lets you drop into C if you really need to... but that's a particularly extreme tradeoff. You should not start out on a Ruby project intending to do this, because it means that future Ruby programmers may not be able to maintain your code. Nor should you pick up Ruby on the basis of pie-in-the-sky promises that there'll be a new interpreter "real soon" that will be "real fast", because the developers might all die in a chain of freak accidents tomorrow. Use Ruby if it makes sense: if it's fast enough today, or if the improvement in programmer productivity is great enough that you can justify solving performance problems with expensive hardware.
Just bear in mind that you're measuring that productivity improvement against other faster scripting languages, like Perl and Python, not against C++. And bear in mind that there are more people with those other languages in their skillset, so they'll be cheaper, easier to find, and easier to replace. And bear in mind that Ruby is currently a fad, so some of the people who love it today are fad-chasers who will leave your company like a shot when the Next Big Thing turns up...
Ruby's the right tool for some jobs, but it's running a grave risk of being a victim of its own success, because when the pro-language hype is way up, so is the anti-language hype whenever anyone gets burned. Maybe you evangelists should cool off a little and prove Ruby's virtue by using it to make yourselves rich, instead of claiming that it's the best thing EVER because it, like, makes it really easy to recurse over directories, just like every other language apart from C++!
Re:Why rewrite existing systems? (Score:4, Insightful)
To get things straight: Rails did *NOT* invent MVC (Score:5, Insightful)
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:thinking about something new? think again (Score:4, Insightful)
* a rich standard library with a good reference
* a good extended library like CPAN
* easy extension in C
* good documentation
* easily available compiler, etc.
I don't mind buying a book, as long as I can get somewhere just from the online documentation. Out of the languages you mention, I got the furthest with OCaml. However, if I needed to do something simple like connect to a database and then contact a directory server using LDAP, I'd be lost.
Re:Why rewrite existing systems? (Score:5, Insightful)
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.
Re:Why rewrite existing systems? (Score:4, Insightful)
The only failed experiment is the one you don't try.
Clearly, someone thought there would be a benefit to using Rails over PHP in this case. If they were wrong, they gained valuable insight into a) the abilities of their tools and b) the nature of their project.
I never liked the old saying "if it's not broke, don't fix it". The quest for innovation is a beautiful thing.
Project failed due to Project Management and ..... (Score:4, Insightful)
I'm glad I don't work there.
Slightly different outlook... (Score:3, Insightful)
Linux also represents something significant. Essentially it has come to represent a set of software that does things in a standard way that multiple businesses can implement and compete in a compatible way. This is the key thing that pushed the PC architecture, competition. You can choose Ubuntu, Red Hat(Fedore/CentOS), SuSE, Debian, Mandriva, Gentoo, or any number of others, and still run the same software. You can pull one together yourself if so inclined, or use a community maintained one, and/or have commercial support. MS rode the PC platform to success because they were the only software company to support it on arbitrary hardware vendors. So powerful was this advantage that the industry essentially gave them the monopoly before any other company had a serious offering to consider under the same terms (They had it pretty well gotten by Windows 3.0). Now Linux can represent the same phenomenon, but for the operating system. In order to overcome MS, it's had to be truly Free, but there remains a healthy commercial environment around it.
Re:Why rewrite existing systems? (Score:4, Insightful)
Re:Why rewrite existing systems? (Score:4, Insightful)
A PHP tag on a webserver doesn't mean that the site is powered by PHP. It means that whoever compiled apache loaded a PHP module for possible use in one of the virtual hosts. That Apache also has FastCGI installed, which is routinely used for serving rails applications.
I know for a fact that several high-traffic websites use RoR extensively, but none of them are tech sites, so they don't go around advertising what is on the back-end.
I shouldn't have taken time to respond to your obvious troll, but I felt forced to because some gullible moderators gave you points for spewing lies and idiocy. Typical slashdot fare, I know, but give it a break.
Re:Why rewrite existing systems? (Score:4, Insightful)
They have should have gone postgresql as per my recommendation. Oh well.
With MySQL at first sight you seem to have all these features and behaviours/performance. But when you get down to the technical details you find that many of the "great" features, behaviours and performance are mutually exclusive. Want transactions - go innodb. Want fast inserts, go myisam. Want better concurrent write performance go innodb (or deal with buggy myisam insert delayed vs concurrent_insert vs etc stuff). Want fast selects - go myisam. Want foreign keys to work - innodb. Don't want to lock yourself to MySQL tech that's owned by Oracle (who may not have the best interests of MySQL in mind...) go myisam.
Or just use postgresql. The devs tend to do things right (except when the SQL specs are stupid, in which case they usually follow the stupid spec and do things "wrong").
Misleading Post (Score:3, Insightful)
The actual blog post (and poster) imply that Rails was not designed to do things that they were trying to do. That may or may not be... but that is not the fault of Rails. If the tool was inappropriate for the project, then the project manager should have determined that before starting.
Also, while it is implied (and even stated) that Rails was not designed to do these things... nowhere is he specific about what those things actually are. Rather than berating Rails, the blog post glorifies PHP. Those are two very different things.
In introductory Business Law at my college, there was discussion of the classic case of the tavern visitor in the 1700s who stated "My horse can pisse better beer than this!" (sic) The tavern owner sued the patron for slander. (In those days most taverns made their own beer.)
The judge ruled that the statement was not slander, because the customer did not insult the tavern owner's beer at all... rather, he had complimented his horse!
There really is a big difference. So... I want to know what he does not like about Rails, since he really did not explain that.
Re:thinking about something new? think again (Score:4, Insightful)
Ruby is getting a lot of attention because of Rails, and Rails' attention is making it moderately easy to find web hosts that support it. It is easier to deploy a Rails application than it is to deploy a Django application, if you're taking into account "I must find a web host that supports my framework/language." If you are writing, a web app in Smalltalk using Seaside, well, not only are you definitely not shoving that out to your $8/month Dreamhost account, the chances are you're going to have to have complete control of the production side (i.e., colocation or self-hosting). Also, of course, if you're writing for a business, maintainability becomes an issue with any "obscure" language: eventually, the original development team won't be there, and if you can't replace them because the dozen other people in your area who know the language you chose are happy at the research labs they're working at, you find yourself in a very uncomfortable place. I've heard the even a kindergartner can learn Smalltalk so fast they'll be writing complete CRM systems in a week! speech, too, but in practice it seems those kindergartners are few and far between.
Frankly, deployment issues are one of the reasons I'm slinking back to PHP myself; as much as I love Rails in theory, as it turns out, in practice Rails is a sufficient resource pig that many shared hosts that claim to support Rails put serious limitations on it unless you bump up your service level. (I know I'm inviting arguments from Rails fans here, but yes, I've really looked into this.)
Re:Why rewrite existing systems? (Score:1, Insightful)
The #1 lesson is that they did not properly assess the requirements for the project. If Firefox was required and they coded to IE, they missed a requirement. If scalability failed, they missed that as a requirement. How about the basic question: which requirement indicated there had to be a rewrite? Almost every paragraph you wrote points to this being the real problem.
People need to look at what happened much earlier in projects before blaming fads, AJAX,
Re:Why rewrite existing systems? (Score:5, Insightful)
"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".
The real problems - from the original link (Score:3, Insightful)
> I'm a little reluctant to add to the wasteland that is this post
> and these comments, but here goes.
>
> He learned some PHP and cobbled together the old CDBaby site by himself.
> It was good.
> Then, he heard about Rails, and became infatuated with it. He proceeded
> to attempt a rolling rewrite of CDBaby's frontend and backend both
> (the backend is large, because of inter-label and digital distribution
> stuff) in Rails.
> At this time, Derek had no experience with the following things:
>
> * any language other than PHP
> * systems integration and interoperability
> * Rails
> * object-orientation
> * the MVC pattern
> * managing a development team
Concluding with:
> No framework saves you from your own inexperience.
Re:Why rewrite existing systems? (Score:3, Insightful)
There were some rumblings about the incredible performance of the new PHP system, but no mention of how the Rails version was performing by comparison (it sounds like it never went live).
The "integration" point seemed to be claiming that the only way for the transition to work was for Every Single Line of PHP to be removed from the system simultaneously, but it should be possible for different portions of the site to run in different languages.
The "don't want what I don't need" point sounds sensible, until you decide to go adding arbitrary features. Then it's kind of nice to have some well-tested shortcuts that someone has spent a lot of time testing.
I'm sure he could spend a lot of time and detail justifying the points he tried to make, but these brief descriptions seem nigh unto trollish, and are practically begging for pat answers like "What about connection.execute()?" which the author doubtless has already considered. I just want to know WHY connection.execute() wasn't working for him.
Re:thinking about something new? think again (Score:3, Insightful)
Library, Library, Library, Library.
Then comes community, documentation, availability of tools.
Let me ask you a question.
Smalltalk has been around for ages. If it's so great then how come it never caught on?
Re:Why rewrite existing systems? (Score:3, Insightful)
* Use mature, well-tested, effective software (eg. Solaris, Oracle, FreeBSD).
Absolutely, and this should be a given but it isn't always.
* Avoid immature fad "technologies" like AJAX.
There are plenty of people here who would defend AJAX and blame the developers for a poor implementation, but really the point to be made is that if you are going with something that is new to the environment your research needs to be thorough and you need a lot of usability testing.
* Traditional applications offer more flexibility than Web-based applications.
Very true, but the benefit of a web application is easy deployment/easy updating and hopefully OS independence. Many companies are pushing for web based apps but they are ignoring the initial premises that led them down that road. If you are doing a web based app, there is no excuse for at the very least supporting Firefox. And you have to pay attention to screen readers / accessibility issues.
* Always give much consideration to back-end scalability.
This is another common gotcha in corporate environments. I see more than my share of apps that are highly scalable, but the licensing costs associated with scaling are enormous. Just because an application supports a load balanced environment doesn't mean that you are going to get linear performance increases by throwing more hardware at it.
* Sometimes a text-based interface is far more efficient than a GUI.
Sometimes? Always. Any application that requires a person to interact with it during their entire workday needs to be designed in such a way that you can use it without a mouse. It seems like such a simple task, but it is so frequently ignored. Sometimes a software solution isn't the best solution at all - everyone WANTS things in computers, but when the development project costs more than two years of temp monkeys pushing paper to get the job done, you should think long and hard about creating an internship program instead of throwing money at a software project.
* Get user feedback on software early and often.
This one is often ignored because third party companies don't share their intermediary results and project managers cut out the end users because of historic cooperation problems coupled with agressive roll out timelines. End user communication should be in the hands of somebody dedicated to the task and project planning should account for user feedback delays. If you really have to move forward without the delays, the push should be for dedicated time from a group of end users instead of cutting them out of the loop all together.
* Maintain a reasonable level of heterogeneity, when it comes to software, hardware and vendors.
I would argue that documentation is more important, and independence from vendors in order to perform maintenance and implement high level enhancements / bug fixes. As long as you have good in-house knowledge about how a system works and the decisions that went into laying out the requirements you should always be able to work with another vendor for a replacement system. It might be painful and expensive, but it is important to have the option.
Re:thinking about something new? think again (Score:3, Insightful)
It has been a long time since I did WebObjects work, but I don't think they're particularly similar. The spirit is certainly very different.
So, why do people use Ruby?
I think there are two big crowds. One is the smart OO guys who have been suffering through Java for years. Smalltalk is not commercially viable, but Ruby is. Suddenly, they can escape all the Java idiocy. For the ones doing web stuff, and in particular the ones who have dealt with the absurdity of trying to program via large XML framework config files, Rails is a similarly big relief.
The other crowd comes from PHP and other low-rent web development. Ruby + Rails lets them get something up as quickly as in PHP, but provides them better long-term tools and something much closer to what I'd call object-oriented development. Of course, a lot of those people quickly get in over their heads in Rails, as a lot of the shoddier Rails plugins demonstrate.
So maybe it would be better if Rails were written in Smalltalk or Lisp. But Ruby it is, and it's not so bad. If Java's half-way between C++ and Lisp, then Ruby's cut the distance in half again.
What a false dichotomy! (Score:5, Insightful)
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.
Huh? (Score:4, Insightful)
Perhaps I'm missing something in your post, because it sounds to me like you're advocating every application that accesses the database to enforce data integrity rules. This is a recipe for data corruption, as I'm sure you already know.
Re:What a false dichotomy! (Score:3, Insightful)
You are obviously very familiar not only with Rails, but databases. Many Rails users are not and there's not much attention paid to the database as a business model enforcement in the Rails "way" of doing things. Specifically, the Ruby on Rails book is way too lean on this subject.
My first and only Rails convention was a real learning experience. I was outnumbered by easily 20:1 in an argument that counter your statements. The generally accepted concept in that room was that Rails manages everything for you. If you have to create all these database centric constraints, indices, rules... then you aren't doing it Right. I was essentially shouted down on the notion that proper handling of unique values should be to manage the errors returned when you violate a constraint rather than doing a test and action without the database constraint. I'm not kidding about this either. I was one of three people who were in the database camp and we were all relatively new to Rails
The other probable answer to how this could happen is that Rails developers are ex-php developers who still don't know anything about what a database is beyond some kind of file system for storing data.
Re:What a false dichotomy! (Score:3, Insightful)
I think the reason it doesn't right now because it was designed to work with MySQL MyISAM tables, which are not really relational database tables.
I try to judge computer languages/framework by their authors' intents rather than what its novice users think about them. So I approve of Rails, even if it could do more to teach people about database design, because it successfully teaches people about the MVC pattern and Don't-Repeat-Yourself.