×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ruby on Rails 2.0 is Done

CmdrTaco posted more than 6 years ago | from the i-miss-perl dept.

Programming 385

Jamie noted that ruby on rails 2.0 is done. In addition to upgrade and installation instructions, the article lists a number of the more interesting new features in the release which appears to be quite extensive.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

385 comments

PFFT! (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21624977)

Round here we care about only men's languages, like LISP. Fuck Ruby on Rails! LONG LIVE LISP! It's a language, a language for men!

ORM still broken? (5, Informative)

poet (8021) | more than 6 years ago | (#21624985)

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key.... The Rails developers could learn a thing about databases. Start here: http://en.wikipedia.org/wiki/Database_normalization [wikipedia.org] . Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases.

Re:ORM still broken? (1)

ILuvRamen (1026668) | more than 6 years ago | (#21625111)

they could learn a thing about programming! From what I've heard, if you use the objects in the "rails" that they premade, you're stuck doing it their with with their methods and properties and if you want to do it another way, you're out of luck. Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

Re:ORM still broken? (5, Funny)

K. S. Kyosuke (729550) | more than 6 years ago | (#21625145)

Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

What a relief... As a lisper and rubyist, I'm glad to hear that Python is going to die! Good riddance!

Re:ORM still broken? (1)

K. S. Kyosuke (729550) | more than 6 years ago | (#21625367)

(And, BTW, that was just an irony to point out the absurdity of the parent's statement. ;-))

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625961)

hah, I got it... apparently the modders didn't!

You don't have to use ActiveRecord (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21625309)

You could make a web app without ActiveRecord. You could write your own ORM framework or whatever. The whole philosophy is to have easy to use, quick to program, etc frameworks by default. If you want to chart your own course beyond that, there is nothing holding you back. Sorta like any other framework.

Re:You don't have to use ActiveRecord (4, Insightful)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#21625845)

Yeah, and thats what I don't really like about frameworks in general. They have all of these awesome cool fast easy to use things built in. But sometimes you discover that your needs are too complex for the framework, and someone instantly replies " you don't have to use feature X". Well sooner or later you aren't using many of the cool features of the framework anymore. So why are you using the framework?

Re:You don't have to use ActiveRecord (2, Insightful)

K. S. Kyosuke (729550) | more than 6 years ago | (#21626091)

Maybe it would be a good idea to acknowledge that many application frameworks simply work for often quite large groups of people, but none of them is a one-size-fits-all solution. Hey, it's the same as with programming languages - maybe it's just natural. ;-) Even though I like and use C, Lisp, Ruby, Python (sometimes - it's good that many apps have adopted Python as a scripting language, it's just convenient) and Bash, I just fail to see why I should stop using X just because a few things are easier in Y. That said, I think that DHH and the Rails folks are doing awesome work - even though some people just won't like Rails, I think it wouldn't be fair to dismiss their work just because it fails to work for my application, while many other people seem to be happy with it. (And I'm not suggesting that the parent is doing this - that's just a general thought.)

OK, back to work now. :-)

Re:ORM still broken? (4, Insightful)

FooBarWidget (556006) | more than 6 years ago | (#21625167)

People have discussed this over and over and over again. I presume you're talking about support for composite primary keys. They aren't necessarily a good thing. Go read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html [blogspot.com]

I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Just because normalization is "good" according to ivory-tower database theory, doesn't mean that anything that isn't fully normalized is "bad" or "broken".

"Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases."

Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)

Re:ORM still broken? (1)

JoeCommodore (567479) | more than 6 years ago | (#21625291)

If you are working with a redundant distributed DB (where the satellites don't always have connection so the data is mirrored) trying to integrate added data among the nodes is a nightmare with an auto incrementing numeric key.

Re:ORM still broken? (5, Insightful)

FooBarWidget (556006) | more than 6 years ago | (#21625363)

That's great for you, but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications. Ruby on Rails is not trying to be the thing for everybody. And that's exactly what makes it so powerful and easy. Indeed - turning it into something for everybody actually makes it worse. I'd like to see some proof that composite primary keys are so important in web applications. So far I've seen no convincing evidence. Despite all the complaints about composite primary keys, new Rails websites are written everything, even by high-profile organizations like IBM, NASA, Oracle and Yahoo. And they seem to function just fine.

If you really, really, really, really need composite primary keys, you can still fallback to raw SQL queries in Rails.

Re:ORM still broken? (1)

CastrTroy (595695) | more than 6 years ago | (#21625429)

See there you go generalizing about web applications. Here's a hint. Web applications could be just about any application in the world. There's nothing in particular about a web application that makes it web, Except the web interface. And that may be only one interface to the application. There may very well be other interfaces that connect to the same data. So if there is a need for compound primary keys in any application (which there is) then there are uses for compound primary keys in web applications.

And saying that you can still fall back to raw SQL queries in rails is like saying you can still write assembly and fortran in C. Once you start doing that, you're not using C anymore. Just like once you start using raw SQL in ruby, you've kind of gone off the rails.

Re:ORM still broken? (1)

FooBarWidget (556006) | more than 6 years ago | (#21625547)

While theoretically you are correct, it doesn't apply to 99% of the web applications. Most web applications are very CRUD-like and deal with small to moderate amount of data. Most software on this planet is written to be used internally by an organization. Not everybody is building the next MySpace or the next Google search engine.

So one one side, we have J2EE (and similar frameworks), which is "enterprisey", flexible-until-your-head-pops-off, can-be-used-for-anything, etc etc. The downside of all that flexibility is they make the regular CRUD operations a royal pain to write.

On the other side, we have Ruby on Rails. It doesn't do absolutely anything. It has a limited scope. But within that scope, it does its job very, very, very, very well, much more than the competition. Hey, doesn't this ring a bell? It begins with a "U"...

I know what I'm choosing.

Re:ORM still broken? (1, Flamebait)

shmlco (594907) | more than 6 years ago | (#21625915)

"While theoretically you are correct, it doesn't apply to 99% of the web applications."

Is that related to the fact that 99% of all quoted facts are BS made up on the spot?

You're wrong, and you're guessing based on your own apparently very limited experience. Why not just admit that for "simple" CRUD applications ROR is great, for some it still works well, and that for other applications it may not be a good fit... or not work at all.

Re:ORM still broken? (5, Interesting)

crayz (1056) | more than 6 years ago | (#21626025)

If you do a search for "composite keys rails", hit #1 is this [rubyforge.org], a gem written by a fairly prominent ruby programmer that makes it trivially easy to use composite primary keys within ActiveRecord. My guess is if you actually cared about this issue, rather than just raising it as a canard to bash Rails with, you would have found this solution to your problem and wouldn't be posting here

Re:ORM still broken? (1)

CastrTroy (595695) | more than 6 years ago | (#21626177)

You're right, I'm not a Rails developer. I haven't looked up composite keys. What I was doing in my post was responding to the parent, who thought that composite keys weren't supported, and his short-sighted, narrow minded view that you should never need to use composite keys. It's great to hear that Rails supports this, because it actually lets me take Rails seriously. I wasn't raising the issue, I was responding to other users to seem to think that composite keys is an unneeded feature.

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625397)

Yup, 5th normal form is a tad much, but there is no reason to don't go 3rd.

It also SIMPLIFIES application, you just have to think accordingly.

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625425)

Why would you not want a composite primary key for a many-to-many link table?

Re:ORM still broken? (1)

FooBarWidget (556006) | more than 6 years ago | (#21625443)

I would. And Rails supports exactly that.

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625509)

Then what is everyone complaining about?

If I have a table called Loans (PK = loan_id) and a table called TaxParcels (PK taxparcel_id) and I wanted a many-to-many link table I would naturally have a primary key on this table of (loan_id, taxparcel_id). Yes?

Re:ORM still broken? (1)

crayz (1056) | more than 6 years ago | (#21626079)

No, in Rails conventions you would have a join table, called 'loans_tax_parcels' with the loan_id/tax_parcel_id fields, and then your Loan model would say:
has_and_belongs_to_many :tax_parcels

and your TaxParcel model would say:
has_and_belongs_to_many :loans

And then you could do @loan.tax_parcels, or TaxParcel.find(:all, :include => :loans), etc.

Re:ORM still broken? (3, Interesting)

Anonymous Coward | more than 6 years ago | (#21625495)

Getting a *PROGRAMMER'S* opinion on data modeling is probably not a good idea. The view everything as objects or records, which is what they use in their programming. That's a subset of what the relational model allows.

Here's the simple, easy-to-comprehend reason why surrogate keys should not be used universally: Your logical model should exactly correspond to the client's conceptual model.

If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as the compound key for order items. If the client says "customers are identified by an arbitrary customer number", then it's okay to use an artificial ID. If the client says "customers are identified by SSNs" then that's your key.

Pretty simple concept, but completely lost on programmers who think the database is the "backing store" for their code (which will likely be replaced or rewritten in few year anyway, especially stuff like PHP, Ruby, etc). No, the database is the foundation of the business. It should be properly designed.

BUT, it's true, today's SQL databases are pathetic. They don't make this stuff easy. The don't let you create a data type that automatically renumbers the "LINE#" field if entries are deleted or removed. They don't let you create fully updateable views, making it trivial to create alternative key structures on top of your properly designed base tables. They make it hard to refactor and transition schema (views are like methods in OO code.. they let you encapsulate). They make joins expensive. So yes, there's a tradeoff and usually I give up and use surrogate keys most of the time (not ALL of the time though.. depends).

It's not WRONG to be faithful to the conceptual model 100%. It's a limitation of TODAY'S tools. But the programmers continue to spew their nonsense, the database vendors put out products optimized for programmers... it's a vicious circle.

Also, I don't know why you're bringing normalization into this discussion. I suspect your knowledge of "ivory-tower " database theory is limited, thus you incorrectly label all ad-hoc design rules as "normalization". (What exactly do you use to when working with databases, if you don't like theory?) Normalization has to do with key dependencies, not the structure of the keys, and is not required by the relational model because it is a *design* concept.

But since you bring it up, denormalization ALWAYS results in either a loss of data integrity, or a loss of performance. If you denormalize without maintaining integrity (the usual way), then you've fundamentally changed your model (what's allowed in the DB is different now). You better BE DAMN SURE you need it, and you better DOCUMENT IT out the ass. If you denormalize, but add constraints to maintain integrity, then you've killed performance for no reason (however this is useful when transition from denormalized designs back to normalized designs).

Re:ORM still broken? (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#21625649)

"If you denormalize, but add constraints to maintain integrity, then you've killed performance for no reason (however this is useful when transition from denormalized designs back to normalized designs)."

You can't say that will be the case 100% of the time. Most of the times denormalisation is chosen to improve the performance. In which case its faster to be denormailized, even with constraints. There are many different variables that come in to play when discussing database design that can't be accounted for with general rules. Yes, you should apply best practices and consult various rules of thumb, but nothing can replace testing the design with realistic data.

Re:ORM still broken? (2, Insightful)

FooBarWidget (556006) | more than 6 years ago | (#21625687)

Yeah, blame it on the programmers. Taking elitism (or perhaps "anti-programmer-ism" is a better word) to a whole new height.

Yes, my database theory knowledge is limited. I admit it. I passed the 'database systems' course, but I'm not a professor in database systems, so *of course* my database theory knowledge is limited. That's why DBAs exist and why they are paid to do their job in the first place.
But you know what, the database isn't the only thing that exists. There's also the actual application. If, by normalizing stuff to the extreme, makes the application 6 times harder to write (= missed deadlines, potentially more bugs, harder to maintain, etc) then I don't mind de-normalizing some stuff after carefully weighting the pros and cons.

As for "ivory tower database theory", consider the following scenario (this is based on a question from the "database systems" exam):
We have a 'teachers' table with columns (first_name, last_name, address, city, phone_numbers). Here, phone_numbers is a set. We are asked to normalize the table. One of the obvious things to do here would be to change the 'phone_numbers' column into a table, and add a one-to-many relation from the 'teachers' table to the 'phone_numbers' table.
The professor, however, took normalization to the extreme: he even introduced a 'numbers' table. So a 'phone_number' table has a one-to-many relationship with the 'numbers' table. (Or something like that; I can't remember the question completely.)
Great. Perfect normalization. But I would never write such a database schema. I don't even want to think about the huge, ugly, and hard to maintain SQL queries that result from this. And this is what I mean by ivory tower: great in theory, but makes things a total pain in practice for 99% of the applications.

Re:ORM still broken? (1)

CrazedWalrus (901897) | more than 6 years ago | (#21626185)

Holy. Crap. You're not the guy that writes Active Record, are you?

The thing a lot of OSS developers seem to forget is that many applications are primarily for data processing with user interfaces thrown on top. I.e. Not every damn "web app" is a blog or wiki, where it's primary purpose is to be a web app.

Fact is that, if Rails wants greater acceptance (and, yes, I realize it is already widely accepted -- I'm talking about continued growth), then it's going to need to support things like composite keys. Why? Because people use them, and the application may have come years before the web interface.

I don't use RoR at all, but these comments saying that composite primary keys are useless are simply insane. They're a fact of life, and if ActiveRecord doesn't support them, it's automatically precluded from use in existing applications that use them.

If AR does support them now, hey, great. In that case, I can't understand why this argument is even happening.

Re:ORM still broken? (1)

smallpaul (65919) | more than 6 years ago | (#21625861)

Pretty simple concept, but completely lost on programmers who think the database is the "backing store" for their code (which will likely be replaced or rewritten in few year anyway, especially stuff like PHP, Ruby, etc). No, the database is the foundation of the business. It should be properly designed.

You're generalizing from your specific situation. Often the goal is to sell the company in a few years to another company that will require you to integrate with their databases in any case. In that case both the code and the database are disposable (in the long run, both always are) but time to market is the immutable requirement. Every situation is different. It's even possible in some circumstances that performance is more important than integrity.

Re:ORM still broken? (1, Insightful)

poet (8021) | more than 6 years ago | (#21625563)

Actually no I am not talking about compound keys (although yes that is very, very important). I was talking about:

CREATE TABLE foo (company_name text PRIMARY KEY)

Which as I understand it, Rails is too stupid to understand. Granted, the only ORM that I know of that isn't is the one being used by Catalyst but still. It is a major design mistake to assume that your data can be correctly represented in a normalized structure using (id serial PRIMARY KEY).

I am also not talking about extreme normalization. I am talking about basic normalization... e.g; up to say the Third Normal Form.

The job of the DBA is to enforce proper database semantics, including design, performance, and maintenance.

Proper design is impossible with rails without reducing performance (the requirement to have a serial primary key and then a natural unique just to satisfy proper data requirements). Rails also increases database maintenance through mention of the above, and increases resource utilization (disk space and IO), reduces transactional velocity (having to update multiple indexes that shouldn't be required) etc...

I can go on and on.

However, I have talked myself to death with Rails and Java programmers before. The majority (not all) are stuck in there own little code generated world and don't want to actually do things correctly.

Not to mention that Rails significantly reduces your ability to do really cool stuff such as stored procedures (yes you can break out and do it manually but then why are you using Rails?), Federated databases and on and on and on.

Re:ORM still broken? (1)

FooBarWidget (556006) | more than 6 years ago | (#21625877)

"Proper design is impossible with rails without reducing performance (the requirement to have a serial primary key and then a natural unique just to satisfy proper data requirements). Rails also increases database maintenance through mention of the above, and increases resource utilization (disk space and IO), reduces transactional velocity (having to update multiple indexes that shouldn't be required) etc..."

In theory you are true. But I'd like to see some evidence that proofs that lack of support for non-integer primary keys is *the* source of performance problems in Rails. Have you ever benchmarked a Rails app? How do you know that 90% of the spent time is to be blamed on the use of surrogate primary keys instead of the rest of the stack? Often performance problems aren't where you think they are.

"However, I have talked myself to death with Rails and Java programmers before. The majority (not all) are stuck in there own little code generated world and don't want to actually do things correctly."

That sounds a bit like an assembly programmer blaming C programmers that they stick to own little code generated world.

"Not to mention that Rails significantly reduces your ability to do really cool stuff such as stored procedures "

I've been wondering this for a while. Why are stored procedures "cool"? Just because you can? Can you give me use cases in which stored procedures have a significant advantage over application-generated SQL queries?

I've witnessed a game server (which uses MS SQL) using stored procedures that look like this:
DEFINE STORED PROCEDURE GetMonster(name) (this is something I made up; I don't remember the correct syntax, but you get the point)
BEGIN
        SELECT * FROM Monsters WHERE monstername = @name;
END

And then I think "Doh! Why does this exist in the first place? Why not just write that SQL query inside a GetMonster() function inside the application?"

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625985)

And then I think "Doh! Why does this exist in the first place? Why not just write that SQL query inside a GetMonster() function inside the application?"

We use stored procedures for extra security and to make sure that programmers don't mess things up.

Re:ORM still broken? (1)

crayz (1056) | more than 6 years ago | (#21626217)

And then I think "Doh! Why does this exist in the first place? Why not just write that SQL query inside a GetMonster() function inside the application?"

Heh. In Rails that would be Monster.find_all_by_name('whatever'). Without creating any methods at all - ActiveRecord 'created' it for you. The guy below mentioning protecting data from programmers - if that's the philosophy you want to use, why not just quit now?

Re:ORM still broken? (1)

erwan (539327) | more than 6 years ago | (#21625567)

Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?) Most real world business applications use partitionning in order to cope with very big tables. An auto-increment key is not a good candidate for splitting a table, as it will prevent spreading the data across the partitions for parallel processing, so you have to play with an application key (the auto-increment) and a partitionning key that the application has to set anyway when creating rows, which is far from optimal ... Anyway, good developpers understand the implication of what they do for the underlying database ... DBAs and DBMS won't fix your bad design decisions.

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625839)

An auto increment key isn't unique across instances of an application. Thus if you set up two distinct instances of a given app within an organization, and then want to move data between them, you're in trouble since you have key collisions e.g. both the finance and the it department servers have a user number 69, only finance think's he's Bob Jones, and IT thinks he's Ted Williams.

A pseudo unique guid, on the other hand, is unique across any practical number of instances, meaning you can always move data between them without keyspace collisions. (yes, I know, there are some apps out there with sufficiently high transaction volumes that the chances of a collision of pseudo unique guids is non trivial, but lets face it, they're pretty damn rare).

Re:ORM still broken? (1)

dfdashh (1060546) | more than 6 years ago | (#21625859)

Why are surrogate keys a pain in the ass for DBAs? My guess is their difficulty in high-availability or disaster-recovery scenarios. When most application frameworks create autoincrementing surrogate keys, it is tough to get them synced over to a disaster recovery site and maintain consistency. Inserting explicit values into a sequenced table in Sybase, for example, requires table-owner intervention (usually the DBA) and not just access to insert into the table. Ever had to do asynchronous, multi-master'ed data correction with lots of these keys hanging around? Didn't think so.

Surrogate keys, by definition, also replace a table's naturally identifying characteristics. This means that you'll be creating additional indexes if some natural search columns are present. With those additional indexes come additional data storage to house them. There's also the chance that the surrogate key will be used by the query optimizer anyway, sometimes resulting in horribly inefficient joins.

Re:ORM still broken? (0)

Anonymous Coward | more than 6 years ago | (#21625199)

The Rails developers could learn a thing about databases.

HA HA HA HA HA

Fucking understatement of the year, bro.

Hmm, monolithic record-oriented design (all facts for a single entity in one table), using one-to-one links ("universal IDs"), and queries that fetch all attributes at once, and save all at once, minimal use of joins, implementing complex queries in procedural code? WELCOME TO COBOL! Har har har.

I swear, if I had a nickle for every time somebody on the Rails list said "don't do that, it's bad design" in response to someone trying to figure out how to implement a *proper* intuitive design.... I'd be able to fund my own Web 2.0 startup, or some shit...

The rest of Rails is pretty good though. And I'll admit, SQL databases don't exactly make it easy for anybody (how about letting DBAs create a VIEW with the "Rails design", on top of a properly designed database? That's what views are for! Codd is rolling in his grave).

Re:ORM still broken? (2, Informative)

crayz (1056) | more than 6 years ago | (#21626137)

And I'll admit, SQL databases don't exactly make it easy for anybody (how about letting DBAs create a VIEW with the "Rails design", on top of a properly designed database? That's what views are for! Codd is rolling in his grave).

Go for it - I've done it more than once when I needed to get data out of legacy(and very poorly designed) databases. Rails supports this and it works just fine. The one point you make that I really agree with you on is ActiveRecord's inability to detect changed attributes and save only them to the database. You may want to take a look at DataMapper [datamapper.org], a bit of a different take on a Ruby ORM

Re:ORM still broken? (1)

heinousjay (683506) | more than 6 years ago | (#21625203)

For the sake of discussion, what would you suggest, and what benefits would it bring to the process?

Re:ORM still broken? (4, Interesting)

thammoud (193905) | more than 6 years ago | (#21625449)

A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change. Use business keys for that.

Re:ORM still broken? (1)

Enahs (1606) | more than 6 years ago | (#21625933)

Not true. You can work with a number of different conventions...easier on the DBA, but harder on the person developing the Rails app.

I don't think this is entirely the best way, but here's ONE way I found by Googling: http://lindsaar.net/2007/11/28/connecting-active-record-to-a-legacy-database-with-stored-procedures [lindsaar.net]

I know I've seen tips and tricks for PostgreSQL before, but I'm having trouble locating them at the moment. D'oh!

It's even covered in the Pragmatic Programmers' book on Rails. My copy is in a duffel bag in my car trunk, and it's raining hard outside. I'm too lazy to go look. ;-) I've never had to work with legacy databases, to tell the truth, and only use Rails for an in-house app, so I used their conventions. For what I was (and still am) doing, working against Rails was like pushing rope.

There's a lot of comments on this story that have patently untrue "Informative" statements...but then again, this is Slashdot, where authoritatively-delivered misinformation is rewarded. For example, it's not true that Rails forces conventions on you, but arrogantly stating that it's so garnered high ratings for another comment. People, the "authoritative" people you see here on Slashdot are the same people you roll your eyes at in, say, inter-deparmental meetings, and are usually the guy who qualifies stupid ideas with "and I used to hack in Forth on a PDP-11 before you were born, so I think I know what the #$%! I'm talking about!" So please...if you roll your eyes in real life, don't reward that behavior on /. Having said all that, I'll admit that Rails and/or DB design is a weak subject area for me, so I'll just shut up now ;-)

Fresh Meat! (2, Interesting)

TechyImmigrant (175943) | more than 6 years ago | (#21624991)

Fresh Meat, full of bugs, for the hackers to hack.

If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.

Re:Fresh Meat! (0)

Anonymous Coward | more than 6 years ago | (#21625293)

I haven't seen one post by a Slashdot subscriber yet that was anything other than pure bullshit. I suppose I shouldn't be surprised, anyone that would pay a dime to visit this shithole obviously doesn't have a clue. Allow me to try and give you some of the education you desperately require.

I suppose that security through obscurity is the better solution to you, mmm? Let the exploits stay out there in the wild while the company producing the OS takes months (if not a year) to produce a patch for a vulnerability they'll never likely explain to the public. It'll just be another "critical Windows Update" #Q1234567. How well has that been working out for Microsoft so far? Not so well, evidently.

How about all those subversion and cvs repositories out there for open source projects? Any mean, nasty hacker can look at the code, so why aren't we seeing myriads of Linux backdoors, remote exploits and the like? They exist alright, usually in the form of some proof of concept or script kiddies' tool. Thing is, everyone has access to the source code. Take Firefox for example; if a serious security problem is found then it's usually fixed and stable within a couple of DAYS, not months, and meanwhile there's a myriad of possible vulnerabilites that are being patched before they can even be used. How about on the Mac? There's been a few here and there, but Windows is keeping the antivirus industry alive, and you'd have to be a fool to try and deny it.

Is that enough for you to think about, or are you done trolling for the day? Maybe you should put the keyboard and your dick down and polish that subscriber * off a little, it's been tarnished by your idiocy.

Re:Fresh Meat! (1)

TechyImmigrant (175943) | more than 6 years ago | (#21625371)

Actually I was arguing from the standpoint that security in online systems comes through reduced complexity in trusted code. Thus affording effective review and analysis. If you structure your online application such that you have to trust the whole codebase, you're screwed. Make sure you only have to trust a tiny bit of code, then polish that turd well.

The two properties I warned against were 'large' and 'immature'. I mentioned neither 'open' nor 'closed'.

Thankyou for educating me. I'll file it with all the other security advice I get on Slashdot.

Re:Fresh Meat! (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21625505)

Obviously you aren't filing much information at all, judging by your ignorance. And would you look at that -- the moderators agree. You ARE a troll, you DON'T have anything useful to contribute to the discussion. Funny that, isn't it? Must be a blow to that enormous ego of yours.

Have any other witty retorts to add, troll? By all means, go right ahead. Enthrall me with your comic ignorance and weak, veiled attempts at insults. I won't be here to read them.

I wonder what Tina would think if she knew little David was trying to get his e-penis hard by trolling Slashdot? Is that the way a real man behaves, Davey? I wonder what she'd think of her man acting like a little child. Something tells me she's already quite aware that you're not a real man. Maybe you're not with her now because you're impotent, mmm? Can't get it up any more, Davey, is that what keeps you coming here?

Have fun and come up with some witty response that I won't read. I've wasted enough time on you, boy.

Re:Fresh Meat! (0)

Anonymous Coward | more than 6 years ago | (#21626027)

full of bugs
If you know of said bugs, please report them. If not, your post is lies and FUD.

Too bad I just switched to Python (1, Funny)

Anonymous Coward | more than 6 years ago | (#21625029)

This new antigravity [xkcd.com] feature is astounding.

I don't understand the fuss. (4, Interesting)

Russ Nelson (33911) | more than 6 years ago | (#21625039)

I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?

Re:I don't understand the fuss. (1)

FooBarWidget (556006) | more than 6 years ago | (#21625117)

My productivity has been boosted four fold (not a joke!) compared to when I was still developing in PHP. *And* my code is now shorter, more readable, more maintainable, and more secure. I'm not looking back to PHP anymore except for the most simplistic (= less than 500 lines) web applications.

Re:I don't understand the fuss. (1)

jonadab (583620) | more than 6 years ago | (#21625183)

> My productivity has been boosted four fold (not a joke!) compared to
> when I was still developing in PHP. *And* my code is now shorter, more
> readable, more maintainable, and more secure.

Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails.

Re:I don't understand the fuss. (3, Interesting)

FooBarWidget (556006) | more than 6 years ago | (#21625251)

"Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails."

Uhm no I don't. I've programmed in Perl far longer than I've programmed in Ruby. I only started with Ruby about 2 years ago. I have experience with mod_perl and stuff like Template Toolkit. I have experience with Python. And Ruby on Rails *still* beats everything else I've used.

It isn't just Ruby, it's also Rails. It's the entire package. Rails is not just any framework, it's an entire design philosophy. It's opinionated software. It's Don't-Repeat-Yourself. It's REST. It's convention-over-configuration. All this stuff together makes me much, much more productive. Ruby on Rails actually makes web application programming more fun than desktop application programming.

Re:I don't understand the fuss. (1)

Tomy (34647) | more than 6 years ago | (#21625767)

Sure, having a nice language like Ruby helps. I'm sure a Rails-like framework could be developed in any language that supported class metaprogramming, specifically some way to either add methods to a class at runtime, or fake it with something like "method_missing" (Smalltalk, Objective C, Ruby, etc) or __getattr__,__setattr__ (Python).

To me the important features of Rails are:

- Convention over configuration. Follow some simple naming conventions and your class to table mappings come practically free.

- Very good enforcement of MVC. Not that you're 'forced' to do MVC, it's just that the framework is designed to make MVC programing easy and natural. There is very clear separation of business logic from control and presentation, and it is easy to refactor when you do get it wrong.

- Easy to split parts of the app out into separate services when you need to scale to multiple machines.

- Rails' "migrations" is definitely the easiest way I've found to manage schema evolution.

- Ruby wrappers for a lot of AJAX-y stuff, you can stay in Ruby-land and still take advantage of js libs like Prototype and script.aculo.us.

- Emphasis on getting something up and functional quickly.

I built a Build/Release/Deploy application with complete integration with subversion in two days. It had functional parts in the first hour, including dynamic 'select', i.e. select the package you want to set up for nightly or continuous integration builds, and the drop down for branch selection would change to reflect the branches for that package without a page reload (without writing a single line of Javascript). Now this app is still pretty ugly looking, since it uses a lot of default scaffolding that Rails can generate, but it is easy to incrementally replace the scaffolding, and let the CSS Beauticians work in parallel.

This last point just seems mesh well with how I like to work. Get the pig up and running and we can slap lipstick on it later. In the early development phase, I want to concentrate on function and work flow.

Re:I don't understand the fuss. (0)

Anonymous Coward | more than 6 years ago | (#21625385)

you forgot performance, the performance in your application is shit now.

Re:I don't understand the fuss. (1)

FooBarWidget (556006) | more than 6 years ago | (#21625489)

Not everybody's developing the next MySpace you know. For the past 4 months, I've been working with some fellow students on a web application, to be used by some student organizations at my university. Performance is not important *at all*, and we've done absolutely no work on tweaking performance. The project's deadline is in a month. So far, Ruby on Rails is godsent. If we chose PHP we'd still be at less than 50%, *and* the code would be a lot more messy. Right now, communicating with the student organizations' representatives and our professors takes more time than writing the code -- as it should be.

Re:I don't understand the fuss. (0)

Anonymous Coward | more than 6 years ago | (#21625761)

ahhh, so you are a student working for the university maybe Rails is good for you, one question, you are a student in liberal arts?

Re:I don't understand the fuss. (2, Informative)

CastrTroy (595695) | more than 6 years ago | (#21625481)

Yeah, but PHP is one of the least productive environments there is, at least as far as web development goes. You could switch to .Net, and you would increase your productivity 10 fold. That is, if you stick to the .Net way of doing things. You're application might not scale that great, and you might not have any idea what's going on under the hood, and you might have a 20K viewstate submitted with every form, but you will be really productive in the sense that you can turn out a lot of features in a very small amount of time. Comparing raw PHP to rails isn't really something you should be comparing. Make your own custom framework in PHP, that fits the needs of whatever project you are working on, and you can probably turn out features extremely quickly. And your own framework will actually need what you need it to do, instead of you having to make compromises for the shortcomings of the framework.

Re:I don't understand the fuss. (1)

FooBarWidget (556006) | more than 6 years ago | (#21625737)

I tried. I seriously considered ASP.NET. And I didn't use it.

First of all, ASP.NET is almost Windows-only. Mono support is not ready for prime time. This would mean I'd have to use Windows for development work, and it'd significantly lower my productivity. For a while, I installed Visual Studio and played around with ASP.NET. I borrowed an ASP.NET book. But I didn't like the experience at all. Everything is tied to the IDE. I have reasonable C# experience and I quite like the language, but ASP.NET doesn't appeal to me at all. It seems like Microsoft is working very very hard to abstract the web away.

Re:I don't understand the fuss. (4, Interesting)

pestilence669 (823950) | more than 6 years ago | (#21625463)

"Web guys" will never understand the hype behind RoR. For the average PHP coder, RoR is slower and more restrictive... A hindrance. To a software engineer, however, RoR's great use of design patterns and best practices compliments what they should be doing already. Just as an example, if you're not writing unit tests, then you aren't very serious about your software to begin with. RoR's test facilities will bore you and nag you death. What Rails does is force you to consciously decide to not do something you should probably be doing, like testing. If MVC and encapsulation mean nothing to you, then RoR can't help you much. You still need you own discipline, or you can still write abominable code. RoR embodies many practices from how the big boys write software, few from the basement hackers.

Re:I don't understand the fuss. (2, Informative)

CastrTroy (595695) | more than 6 years ago | (#21625569)

But you could do the same thing in PHP. The fact that most people don't doesn't really say anything bad about PHP, but just bad about people who generally use it. A lot of people who write PHP leave SQL injection problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in PHP. Just because most people don't, doesn't mean it's a bad tool. If you need a tool to hold your hand and force you to adhere to best practices, then you aren't a very good developer.

Re:I don't understand the fuss. (1)

pestilence669 (823950) | more than 6 years ago | (#21625825)

PHP is a language, not a framework. Cake, Akelos, Symfony... Those are valid comparisons. Sure, you can use the raw facilities of the language to build a site, install libraries and tools (PhpUnit, PhpDoc, xdebug, prototype.js, ADOdb, etc.) If you are already building good software, Rails gives you a nice toolbox and prevents you from perpetually reinventing the wheel. Its the layer you should be writing for every project. PHP doesn't provide anything out of the box. In fact, it even discourages best practices. Global variables? Magic quotes? Goto statement (its coming... Really)? And no, there is never any reason to use goto or "register globals." just making them available reduces software quality globally.

Re:I don't understand the fuss. (4, Insightful)

crayz (1056) | more than 6 years ago | (#21625935)

Please just try Rails for a little while. While Rails has its flaws, overall it's a highly productive framework - and much of the credit for the terrific code clarity goes to Ruby, which is much more powerful and dynamic than almost any other mainstream language(other than maybe Javascript)

Some things to read about and try within Rails:
* ActiveRecord's ability to introspect the DB schema at runtime. e.g. autocreating the method to allow: User.find_by_name('Joe')
* ActiveRecord's magic-fields, e.g. created_at/updated_at
* the ActiveRecord associations, and the easy DB queries that come with them, e.g. @user.posts.find(:all, :conditions => {:status => 'pending'})
* the scope_out plugin, which provides some nice additions to 'with_scope'. e.g. in the Post model you could do scope_out :pending, :conditions => {:status => :pending}, and then be able to change the previous example to:
@user.posts.pending
* ActiveRecord callbacks and the controller before/after filters
* the RESTful routing and easy links that come with it, e.g. link_to(@user.name, @user) will create a hyperlink to the correct URL for that user record's 'show' page
* the form/field helpers which also integrate with the routing, so you can now do just form_for(@user) - it will create a proper form tag for hitting either the create or update method for that @user, depending on whether the record has already been saved to the database - the form_for/fields_for block syntax is also very powerful, especially when you add your own form helper methods
* all the convenience methods provided by active_support, like 5.minutes or 1.month.ago
* Ruby itself - Ruby is simply a joy to code in. even if I were going to dump Rails, I would now strongly prefer to find a new Ruby framework(like Merb) than using another language

I'd strongly urge you to pick one or more of the PHP MVC frameworks to look at while you read about Rails. Most of them are copies or at least inspired off Rails to some degree, so they often use similar conventions. You'll see the difference between what's possible in PHP and Ruby - PHP doesn't come out looking too good at the end

Re:I don't understand the fuss. (1)

MarkRose (820682) | more than 6 years ago | (#21625595)

It's good for rapid development, but bad if you want to run a high performance site. It's keen on the active record pattern, which is brutal on database servers in many situations.

Re:I don't understand the fuss. (1)

Tablizer (95088) | more than 6 years ago | (#21626165)

I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?

Gives me a youtube idea: Ron Paul on Rails.
     

Compound Keys (0)

Anonymous Coward | more than 6 years ago | (#21625069)

I like to use whatever functionality my database engine offer, including compound keys, in ruby on rails 2.0 my databases with compound keys are still "legacy"?

Re:Compound Keys (2, Interesting)

poet (8021) | more than 6 years ago | (#21625089)

I doubt it.. Rails has never been known for actually using the database for more than a flat file... One of the reasons it can't scale.

Scaling matters if you're Digg. Are you Digg? (4, Insightful)

patio11 (857072) | more than 6 years ago | (#21625427)

While Rails might not be my first framework of choice to implement Digg in, I prefer to build sites which actually, you know, make money by solving problems for paying customers. When you do that, you don't really have to worry about scaling to infinity and beyond, but you do have to worry about expressiveness, maintainability, and time to market. (If you have too many customers relative to servers, heck, easy solution there -- the engineer in me says "just throw up more boxes", but the businessman in me says "pay somebody to worry about it so I can go back to counting my benjamins".)

I have a Rails site, my first (hopefully of many) for my small business, which plugs along at about 20 requests a second in tests. If I could saturate those 20 requests a second, I would quit my day job on the spot. Scaling? Eh, who cares.

(P.S. Day job is writing enterprise level crud apps for Japanese universities on the J2EE stack. They worry a bit about, e.g., getting hit with 8k users signing in simultaneously during class registration. You know what we do? Exactly what I'd do for a Rails app in the same situation ("don't do anything stupid like an n+1 queries loop, cache the important stuff, and buy enough hardware for the job"). Only difference in Rails is I have never wanted to poke my eye out with a spoon while writing it.

Re:Scaling matters if you're Digg. Are you Digg? (4, Insightful)

pestilence669 (823950) | more than 6 years ago | (#21625633)

Ever notice how those most "concerned" about scalability tend to have never profiled or benchmarked their own code? ... or understand why you want to scale horizontally, rather than vertically? Whenever I build services that can handle 120,000 requests/sec., they usually just end up being 99% underutilized. Everyone likes to think THEY will be the next MySpace, with no server budget apparently. I highly doubt that any who argue Rails can't scale has ever had to deal with real distributed clusters. The database cluster will have many more scalablity issues than the webservers. This is such a non-issue, I cannot believe it. If you can scale JAVA!!!... You know what I mean.

Re:Scaling matters if you're Digg. Are you Digg? (1)

FooBarWidget (556006) | more than 6 years ago | (#21625779)

Well said. Most people complaining about Rails scalability are simply complaining because it's the newest hype, but because they're actually concerned for legitimate reasons. "Fixing" the source of their complaints (whatever that might be) would be a huge waste of time.

Re:Scaling matters if you're Digg. Are you Digg? (2, Insightful)

crayz (1056) | more than 6 years ago | (#21626001)

Exactly. The fact is, Ruby is slow. Rails is slower. This is a very accurate complaint about Rails as a web framework, although in the real world it's generally not much of a problem. Somehow though, people have confused speed with scalability, and start claiming the Rails isn't scalable. In fact Rails tends to encourage or at least make fairly easy a shared-nothing architecture which allows a trivial "throw more servers at it" solution to scaling

That said, because of Rails speed, you will wind up needing to scale it sooner and larger than you would a site written in Django, say. If people want to complain about the hardware costs of running a real-world Rails site, I encourage them to do so and put up real numbers regarding the money they spend on developer time and other company expenses vs. server costs, and how Rails being so CPU-hungry is killing their bottom line. So far I've seen none of that, just uninformed whining

Re:Scaling matters if you're Digg. Are you Digg? (1)

Fnkmaster (89084) | more than 6 years ago | (#21625643)

Ruby makes me wanna poke my eyes out. J2EE is the abortion of the Java universe, unfortunately.

Re:Scaling matters if you're Digg. Are you Digg? (2, Funny)

crayz (1056) | more than 6 years ago | (#21625969)

What language do you use that's more readable and expressive than Ruby?

Re:Compound Keys (0)

Anonymous Coward | more than 6 years ago | (#21625521)

I doubt it.. Rails has never been known for actually using the database for more than a flat file... One of the reasons it can't scale.


That sounds like FUD to me. Would you like explain exactly how Rails isn't able to scale and in comparison to what? Can you give an example where a Rails based project that has failed specifically because of poor scaling?

Off the top of my head Twitter and 37Signals apps seem to have scaled. Do you have something bigger in mind?

Re:Compound Keys (1)

Enahs (1606) | more than 6 years ago | (#21625991)

Hey, aren't you the same "authoritative" person I responded to earlier? Second comment, and I'm hoping you're just trolling. Hell, you can even use raw SQL with Rails, so, well, either you're trolling, or you're an idiot. Which is it?

Sites Moved to Rails? (4, Interesting)

markmcb (855750) | more than 6 years ago | (#21625095)

OmniNerd.com [omninerd.com], a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since. Our site has even survived a few Slashdottings and Diggs since the switch, which used to murder it before. (Granted, the PHP code wasn't the best.) I've heard the "doesn't scale" debate a million times, but I'm curious if there is anyone out there who has recently moved a project from one language/framework to Ruby/Rails and whether you're glad you did or if it's been a nightmare. We're a medium-to-low traffic site with big surges every few weeks and it's worked well for us.

Re:Sites Moved to Rails? (1)

Bonus_Eruptus (991451) | more than 6 years ago | (#21625487)

I built Too Many Secrets [too-many-secrets.com] as an excuse to learn Rails, and haven't experienced any problems yet, thanks to caching. Unfortunately, since it's slightly personalized depending on whether or not you're logged in, I had to use fragment caching instead of page caching, so it still needs to hit Rails, but I've been able to keep the amount it needs to do to a minimum. I suppose if I actually sit down and think about it, I can figure out a solution and move to page caching.

How is Rails 2.0 speed-wise compared to 1.2?

Re:Sites Moved to Rails? (1)

robinw (257786) | more than 6 years ago | (#21625711)

I wrote a web based game in RoR http://www.forumwarz.com/ [forumwarz.com]. It's running of a single dedicated server and it seems to be handling a lot of requests just fine. During peak periods, we've got multiple requests per second and I've never had any complaints about the performance.

Ruby gets a lot of flack for being slow. The truth it, it is slower than other languages. However, it's rarely a bottleneck for web applications. I'm fairly active in the local Rails community and I've yet to meet someone who had to backpeddle on rails for performance reasons.

In most web applications the database is your big bottleneck. Since Rails is process-based you can always buy another server or two and increase your performance that way. Let's face it, servers are cheap and developers are expensive. Rails allows you to get done stuff faster.

Re:Sites Moved to Rails? (1)

mali_iz_rs (1193657) | more than 6 years ago | (#21625759)

The site that I administer, has recently passed from slashcode(perl) to ruby on rails (custom web site code). After the switch, intel dual core 2.6ghz with 2gb of ram is dying. So, because developers like the 'programming on the fly' method, the owners of the site will pay more money for the server administration, and for few more servers so the site can handle the peaks. As far as I see it .. it's a programming language (with framework) which is created not to scale better, but because everyone wants to finish things faster, which is not neccesarily better. IMHO.

Re:Sites Moved to Rails? (1)

Tablizer (95088) | more than 6 years ago | (#21626139)

OmniNerd.com, a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since.

It's just a blog. I don't see it testing the complexity of say business forms with complex validation.

Granted, the PHP code wasn't the best.

If you compare bad PHP to good RR, of course RR will win. Plus, you have the learning experience of the first (bad) try to make the next deal with the issues you didn't know about the first round.

Better luck next time (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21625103)

Looks like it's still not capable of handling a high load.

I hope the linked site isn't running it (1, Insightful)

sof_boy (35514) | more than 6 years ago | (#21625119)

I am like the 10th comment and it is already slashdotted!

this is fantastic (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21625143)

why don't you slashfags just shut the fuck up? go outside, meet females instead of sucking linux dicks. you'll see there is more to life instead of just being a fucking linux faggot.

Re:this is fantastic (-1, Flamebait)

calebt3 (1098475) | more than 6 years ago | (#21625171)

Why don't you trolls just shut up? Go outside, meet females instead of wasting your virtual breath. you'll see there is more to life instead of just being an a**.

Re:this is fantastic (0, Troll)

calebt3 (1098475) | more than 6 years ago | (#21625269)

Moderator obviously didn't read GPP.

Re:this is fantastic (0)

Anonymous Coward | more than 6 years ago | (#21625389)

No, they just noticed that you responded to a troll, which is exactly what you're not supposed to do, and modded you accordingly. Personally I hope you get modded into oblivion, you deserve it. It's ignorant fucks like you that keep reacting to the trolls and keeping them coming here. You deserve what you get. Maybe you should just be a man and accept that you made a mistake, if you're even capable of being a man.

Re:this is fantastic (0)

Anonymous Coward | more than 6 years ago | (#21625365)

And why exactly are you doing here, then?

Infected with Christianity (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21625247)

Matz is a Mormon! Please, avoid Knuth, Matz, and Wall. Anybody who thinks that was is stupid and illogical.

Re:Infected with Christianity - perhaps, but .... (0, Troll)

chawly (750383) | more than 6 years ago | (#21625431)

Please remember that thinking is not forbidden. It is not even illegal. You can do it if you try .... really. There are (my goodness me) even people who find pleasure in it. Productive thinking is also possible ..... try to keep this in mind.

More hype? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21625379)

RAILS sucks!

Science (3, Interesting)

Cache22x (1056176) | more than 6 years ago | (#21625797)

Okay, all I see on here is negative comments, what ever happened to the concept of "the right tool for the job"? Ruby on Rails is a gem (excuse the pun) in the realm of bioinformatics and chemical informatics. I don't need to be concerned with "scaling" when I am building a site with a maximum of 10 users. For labs and small companies everywhere needing to create and support small or large databases, RoR is fast and easy. It also has major industry backing from the likes of IBM and Apple. It may be a bigger problem for high-volume sites, but I have found it extremely useful. I am using it on the backend (for data management - the data is exported from the database to the legacy perl system daily) for sites like http://www.drugbank.ca/ [drugbank.ca] http://www.hmdb.ca/ [www.hmdb.ca] and on the frontend for sites like http://hmdb.med.ualberta.ca/foodb/ [ualberta.ca].

I guess they didn't fix the scalability issues (4, Funny)

ThinkFr33ly (902481) | more than 6 years ago | (#21625879)

Perhaps a web development framework's web site should be designed in such a way that it can handle a burst of traffic from Slashdot.org and Digg.com.

Otherwise, one might think that RoR doesn't scale.

Re:I guess they didn't fix the scalability issues (2, Interesting)

abigor (540274) | more than 6 years ago | (#21626101)

That's why I'm curious as to why Django (Python framework) doesn't get more press. It's fast and, unlike Rails, it's been proven to scale (ie washingtonpost.com). The languages have more similarities than differences, so it can't be that. Better marketing/hype, maybe?

Does it still require Mongrel? (2, Insightful)

ibbie (647332) | more than 6 years ago | (#21626213)

Or rather, since I haven't been keeping up with the development process, perhaps I should ask, is there a viable apache 2.x module for ruby that allows one to run RoR sites without relying on mongrel/other web servers?

Because, frankly, if it can't be run on apache 2.x, I (and the company I work for) won't touch it. We have already seen the scalability nightmare that RoR was, of course, so obviously we're a bit skeptical about performance optimizations. (:

Note: I have nothing against using new technology, even if it requires learning a new language, but when one has a hundreds of sites that require web server A, and a framework requires the shoehorning of web server B, well, the aforementioned framework loses its appeal.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...