Slashdot Mirror
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."
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.
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.
You dont choose a project for a language, but a language for a project.
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.
- http://www.milkme.co.uk
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.
Keep the Classic Slashdot.
"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!"
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.
- 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.We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
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.
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 denno, I ditched Windows for Debian Linux over a year ago and haven't looked back since. (I'm a programmer though, so my needs are a bit different than your typical Windows user)
:-)
Then again, if this article is any indication, maybe I had better wait another year before I speak.
Peace sells, but who's buying?
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."
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
This reminds me of a similar incident I saw on Reddit a few months ago:
.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.
Sometimes it's best to leave old software systems alone.
http://pinderkent.blogsavy.com/archives/88
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
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 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?I am TheRaven on Soylent News
LISP.
Deleted
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
- Michael T. Babcock (Yes, I blog)
- 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.Reduce, reuse, cycle
thats because rails is a web FRAMEWORK not a programming language - you know RUBY is underneath it all, right?
people get too tied up with cms's that they think will do everything. code a plugin yourself (assuming a decent api is available).
#include <sig.h>
About your point #6, not only is it easier, but it is easier to add onto later. When you use SQL to create objects, you have to go back to whatever line of code you used to do your insert command and adjust the fields. In Rails, you just run a migration to add a field to the table, then modify your form to add that extra field.
:p
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
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.
The article reads as a "I tried to use Rails without learning Rails or Ruby and gave up" story and then admits to using many of the Rails patterns in a home grown PHP solution. Well, obviously, if you are much more familiar with another language and refuse to learn the language underneath a framework, it will be hard to use that framework. Point by point:
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.
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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.
;-)
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
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.
Why would you throw out perfectly good code and rewrite everything?
There's nothing wrong with PHP, especially if the current implementation does the job.
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.
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.
If you need web hosting, you could do worse than here
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.
I am TheRaven on Soylent News
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.
I've got to agree. In two years he could have rewritten this in Fortran on MVS. This has nothing to do with techonology. Obviously he's not comfortable with Ruby - it not be the right language for him since it's full on OOP. Complaining about integration problems because two systems are written in different languages indicates that their systems are tightly coupled. As Homer Simposon would say "Doh!". Probably sticking with PHP in their shop is a good idea in their case and they would have gotten in over their heads with . The second rule of techonology problems is "No matter how it looks at first, it's always a people problem."
The big problem with flavor-itis in large projects is the years of support after. Time tested solutions people!
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.
-- Life is good. Tastes like chicken.
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.
Palm trees and 8
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.
[FUCK BETA]
I'd just like to point out that the parent is decieving. He's not a programmer. According to his website, "Bill is employed by Century College working on developing new recruitment and retention programs." I seriously doubt that means programs in the slashdot sense.
He's just pissing in the GP poster's cornflakes; he isn't for real and should be modded appropriately. His only technical qualifications seem to be messing with his own blog, which he describes as "working on the website."
Don't take my word for it though -- follow the links and decide for yourself how technical Bill might be. I personally have formed the opinion that he's a cereal-pisser.
Here's his own list of articles with a more technical bent:
http://www.lazylightning.org/taxonomy/term/6
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.
We suffer more in our imagination than in reality. - Seneca
I've been interested in learning at least one of those languages for a while. Usually what gets in my way is that I can't find the necessary libraries to complete whatever task I'm working on. Can you point me towards the language from your list that has:
* 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.
Social scientists are inspired by theories; scientists are humbled by facts.
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.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
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.
You are welcome on my lawn.
...stupid decisions based on myth over reality. You have front end people making decisions about browser security in utter discord with back end choices made for functionality. You have redesign of existing functional systems without starting back at the design specification. You have scale failures because you didn't test your nonexistent spec. for scale.
I'm glad I don't work there.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
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.
XML is like violence. If it doesn't solve the problem, use more.
...and I found the keys to a Porche at the bottom of her vagina.
Ow.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
You're just trolling.
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.
I am TheRaven on Soylent News
MySQL? I know a company that went MySQL4 for a lot of things (and then later MySQL5). Using MySQL is usually a bad idea (and it does bite them every now and then - though most of them don't even realize it - I suppose they think that sort of thing is normal, they switched to having email on Microsoft Exchange too, so go figure).
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").
Something tells me the ongoing prejudice against Perl has a lot to do with organizations (or devs, or management) taking up the latest and greatest technologies such as those being disputed in this branch. All languages are going to have their quirks, but there is a simple performance tradeoff for enduring the idiosyncrasies of Perl. Nothing matches mod_perl for performance yet, besides C itself. Java? No. RoR? No. Python? No. While all of the language alternatives in this thread may all have modernizing advantages over Perl, its hackish OOP and its questionable maintainability, many of the criticisms are based on intellectualizing the problems involved. Many times it is just that someone thinks their pet language is better for arbitrary reasons. They were taught it in school, there's a universal force that draws everything to pure Computer Science ideals, there's money in them thar buzzwords, etc.
Non-technical reasons very much outweight technical reasons to choose one language over the other.
When I was a kid, we only had one Darth.
Ruby is nice, Rails has some severe limitations on what it can do without major hacks.
Examples:
Business Model versus Business RulesThere is a distinction between the Rules and the Model. Rules are those things that must be enforced against the data. Examples of this would be (in database terms) referential integrity, unique values for certain fields or combination of fields.
Without this distinction you can easily run into rampant data duplication and your ability to determine what is actually going on becomes a major challenge. Rails fails on this enforcement of the rule because when you identify something as being unique according to Rails, it's managed by a Model declaration to check for uniqueness before making an UPDATE/INSERT SQL execution. Problem with this is you are assuming that you have only one active rails session at a time. If you don't, then it's trivial for two web sessions to insert the same username in the table, thereby fucking your database and your business. Without the database actually enforcing the data through database constraints, you cannot guarantee the results.
Things get even more difficult/tricky when you have to ensure that combinations of fields remain unique or referential constraints are preserved.
I'm know there is some way to do all of this in Rails, but it's counter productive and essentially a hack. For example -- I would have to create additional unique SQL constraints in the database migration files, in some cases, I have to write out the SQL directly -- bypassing that which is Rails. Then the Model would not only have to run the extraneous SQL statement to check for uniqueness, but also be modified to accomodate the error handling that is going to happen when you violate the database integrity. Again, this makes for a lot of non-Rails and non-elegant code.
Don't get me wrong, Rails is nice but it is not really going to be a useful product for some major site that is going to just get crushed in transactions. Do you really think you can open the next MySpace and have it keep all the data properly synchronized? I know it's possible to get around the application rules of the Model, so I know it's also likely to muck up your data.
The original Slashdot post implies some things that are not substantiated by the actual content of the article (blog post). It sure seems as though the poster him/herself has something against Rails.
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.
On a practical level rather than a "my code is more beautiful than yours" level, one answer is simple: deployment. If you're writing a program that's intended to be used pretty much just by you (or other people on your dev team, perhaps), it really doesn't matter what you write it in. If you're writing a program that's going to have to be rolled out to production systems that you don't have absolute control over -- like, say, a commercial web-hosting service -- there are new issues.
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.)
A colleague has been learning Common Lisp and is using SBCL and it has cored on him more than a few times in the past few weeks. According to him Common Lisp is great but SBCL is not production ready and there is no free Common Lisp that is, so if we are to use a Lisp it'll probably have to be something like Allegro.
;).
/dev/null) for daemons/servers because daemons aren't supposed to output stuff". While I do agree that daemons aren't normally supposed to send stuff out via STDOUT and STDERR, that is exactly why I want such output to go to syslog (or the equivalent)! Believe me it has been helpful. Even if your code has no bugs that show up that way, you could find bugs in 3rd party libs that you use ;).
I also did try learning CL, but I personally found it hard to find out how to write production code in Lisp - most of the examples on the web are all very nice for CS stuff (e.g. run this from emacs via slime) , but not real world stuff. While you're strictly in the Lisp world everything is nice and all that - 101 ways to do "fibonacci" etc, but seems like the lisp docs are written by people who are so much smarter than I am that they probably find a lot of things so obvious that they don't list them in FAQs
Example questions I asked:
How do you compile and make an SBCL program executable? (I know now, but still...).
How do you trap and handle posix/unix signals? (not sure the ways I found are best practice)
How do you redirect STDOUT and STDERR to syslog?[1]
Any examples of production style boilerplate code?
How do I write a program that listens on UDP port X on all interfaces for packet and know which interface each packet came in from?
I'm currently using Perl and it is a lot slower than sbcl but so far it hasn't cored on me for a long while. With the exception of the last item the above sort of things are also easy or not too hard to find out (just man perlipc gives a lot of real world details).
I would like to learn a _fast_ high level language AND be able to use it to write production grade code (and no, I don't regard Java as high level, even if you program your java program to do XML and reinvent lisp badly).
[1] I do this for most of my programs. I disagree with people who say "STDOUT and STDERR should be closed (or sent to
I usually try to get it prefixed by the program name and PID (or parent PID) e.g.
Sep 22 03:07:16 host progname[1312] STDOUT: <std output here>
Sep 22 03:07:17 host progname[1312] STDERR: <std err here>
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".
On of the comments on the existing site contains this additional information:
...The deal was this: Derek was not a programmer; he was a musician.
> 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.
Old dog. New trick.
Examples of this would be (in database terms) referential integrity, unique values for certain fields or combination of fields.
I agree completely.
More generally, ActiveRecord does not address any interdependence of the tuples or relations at all (except for a few very common cases where they have no alternative).
ActiveRecord is essentially a persistence engine at its core, with it's own OODBMS-like API on top (that is not closed over any useful set of operations). It blindly assumes that objects are independent of eachother, and can be created, updated, or deleted without regard to the rest of the data. There are some special cases that are addressed, but they are far from complete. In general, ActiveRecord does not even know how to handle database errors, even though the SQLSTATE error codes are defined in the SQL standard. It doesn't expect errors aside from the few special cases.
It has no regard at all for potential race conditions with another application accessing the same data. In fact, it assumes that it's the only application accessing the data, and the data therefore really has no meaning outside of the context of the ActiveRecord application.
Social scientists are inspired by theories; scientists are humbled by facts.
I was disappointed too.
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.
You want the truthiness? You can't handle the truthiness!
>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?
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?
evil is as evil does
I think some of the other major lessons are as follows:
* 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.
Looking at Ruby on Rails, it seems like a cheap clone of the old NeXT WebObjects
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.
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. 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, finder_sql, etc. Rails lets you put your own SQL into the application almost anywhere.
Does my bum look big in this?
Referential integrity and unique constraints should always be enforced by the database. Why even have a database if you're not going to use it?
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.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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...