×

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!

Restructured Ruby on Rails 3.0 Hits Beta

kdawson posted more than 4 years ago | from the insert-gems-and-trains-reference dept.

Programming 197

Curlsman informs us that the first beta of Ruby on Rails 3.0 has been released (release notes here). Rails founder David Heinemeier Hansson blogged that RoR 3.0 "feels lighter, more agile, and easier to understand." This release is the first the Merb team has participated in. Merb is a model-view-controller framework written in Ruby, and they joined the RoR development effort over a year ago. Reader Curlsman asks, "So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

197 comments

I think everyone would agree here... (0, Troll)

Anonymous Coward | more than 4 years ago | (#31055780)

So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?

How about, we don't care? Back in the day, Ruby on Rails promised that it will "kill developers" and CEO-s will be coding the sites themselves in Rails, the hype was THIS big. "Programmers obsolete??".

Soon after it turned out "real programmers" can't scale a Rails app to save their job (Twitter).

Your moment of marketing glory is over. Have the decency to go in a corner and die.

Re:I think everyone would agree here... (4, Informative)

k33l0r (808028) | more than 4 years ago | (#31056014)

I've never heard that Rails would make "programmers obsolete", in fact it seems to be the opposite; if you look at the official Rails site [rubyonrails.org] you'll notice that the biggest tag-line is "optimized for developer happiness".

Rails makes developers happier, not unemployed. What's more, anyone can write bad code in any language, so pointing to Twitter is hardly a conclusive argument. There are lots of big Rails sites out there, including Basecamp [basecamphq.com], the original Rails application.

For a better (and longer) write up on scaling Rails, I refer you to this article [zdnet.com].

Re:I think everyone would agree here... (0)

Anonymous Coward | more than 4 years ago | (#31056094)

AC probably thinks the ruby part in "Ruby on Rails" is a gemstone.

Mutually exclusive?? (4, Funny)

syousef (465911) | more than 4 years ago | (#31056446)

Rails makes developers happier, not unemployed.

When you've had a lousy job, the two aren't mutually exclusive. I want assurances that they don't intend to make me happier BY making me unemployed ;-)

Re:I think everyone would agree here... (5, Insightful)

Anonymous Coward | more than 4 years ago | (#31056484)

I've used Rails on five projects now. To be honest, I think it has made me more and more miserable with each project.

First, I truly dislike "convention over configuration". The main problem there is that they "convention" they use is far too limited for any sizable application. It may be sufficient for a blog web app, or a bug tracker, or small-scale applications like that. But we now have one web app with over 900 controllers, and "convention" falls apart at this size. Sure, we probably should refactor our app, but we're not in a position to do so at the moment.

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval. It gets even worse if you need to optimize that data retrieval. At this point, ActiveRecord becomes a huge pain in the ass, rather than a useful tool.

And like it or not, the performance of Ruby is quite poor. We actually had to purchase some additional hardware to handle the extra load after converting an old Java-based web app to Ruby on Rails. We tried to optimize it, but were spending far too much time fighting with Ruby on Rails and its abstractions. It was cheaper just to buy more hardware.

Re:I think everyone would agree here... (4, Interesting)

Pengo (28814) | more than 4 years ago | (#31056810)

It's a double-edged sword.

I've been involved with rails pretty extensively now for a few years, and i've enjoyed the platform for the most part. A few projects we've launched have grown pretty complex, and we too have had some problems with the code management, but discipline seems to help and a steady peer review.

Ive been working with Java pretty much exclusively since the late 90's, with exception of the last few years which have been focused on Rails projects. I've recently been working with Grails (Grails.org) which is a Java based stack taking the great concepts from RoR platform.

As someone who has never worked with Java, I believe that Grails might not be as easy to pickup and learn, but as someone who has an extensive Java background, it's a serious breath of fresh air. For a large scale project, I MUCH prefer grails code management to rails approach. Obviously with my Java background, i'm partial to Grails.

On the note of deployed code, a few of our rails projects have grown to be pretty large. I've had to implement a LOT of hardware to handle the scaling of usage. We've been able to do a lot of improvements to the code, but compared to the speed and efficiency of Java (Yeah, I never thought i'd say that) I'm a little bit 'burnt' on rails.

Comparing something like Passenger on Apache to Glassfish or Tomcat is like getting out of a 2009 BMW 5 series and jumping into a 1991 Kia.

The first time in YEARS i have had run-away processes take down an entire server, I've migrated all of our servers to Xen servers because i got tired of driving to the datacenter 1-2x a week or making a remote hands call to reboot a server because a zealous process took things down. (Did I mention i bought a load balancer to manage the traffic, i'm doing on 10 machines what i used to do on 3 machines w/my java apps)..

I'm sure that there are folks that know Rails better than I do, we're a do-everything group (4 guys managing a LOT of code and servers), not a large IT shop by any stretch, but on one hand we've hit epic levels of productivity. We've gotten projects out fast, and some of them have done well. We've had other projects we assumed would do great, but ended up failing due to marketing miscalculations. The lesson I'd say i've learned with Rails, is it's better to get a 'good enough' product out the door and then figure out how to tighten it down later than not even make it to the race.

I'm hoping that i can bypass that compromise with Grails, but time will tell. :)

Either way , Rails absolutely has it's place in the Open Source server software stack world. In the end it's just a matter of remembering that if you are doing rails programming, you better be doing it with a Test-Driven development style, as large projects can get out of control.

I've not looked at RoR 3.0, but i'm hoping that they have implemented a Service-style implementation for business logic, rather than encouraging to have it thrown into the Models.

Re:I think everyone would agree here... (1)

mgkimsal2 (200677) | more than 4 years ago | (#31057048)

I think the parent possibly could have used JRuby for Rails, getting to stay on the JVM platform they were already comfortable with. But perhaps when they considered it JRuby wasn't as mature as they needed it to be.

Even for someone without a lot of Java experience, Grails can be very productive. I prefer the 'domain first' approach Grails allows, rather than the 'database first' which Rails promotes. There's no 'right' answer, but I prefer the Grails way. I've had my fair share of headaches with Grails over the last couple of years, but I'm typically more productive with it than other platforms on many/most types of projects.

I've got some high hopes for Rails 3, from what I've heard from my Ruby-lovin' friends. There's apparently been a lot of refactoring at various levels, so speed and resource handling should be much improved. I'm expecting some backwards compatibility breakage, but I've nothing to base that on other than speculation - major version numbers are the best time to do those sorts of changes, if any are required.

Re:I think everyone would agree here... (3, Informative)

Pengo (28814) | more than 4 years ago | (#31057656)

We tried JRuby.

We had various deployment problems, i'm sure that many people have managed to make it work, but we got about 2 days of trying to port in a medium-sized, high concurrent project, and we finally came to the conclusion that it's better to stay closer to the mainline c-based Ruby than diverge our project to JRuby and deal with the dangers of working on the bastard-project (when we talked to some of the guys at sun, back when we made the choice to give JRuby a try, there was only 3-4 paid employees working on it... it just felt too edgy for us, and we were looking to stabalize our project, not go down a lonely road of untested/unknown.... )

As they say, sometimes it's better the demon you know , than the ones you don't.

Disclaimer:

1. We have had a LOT more success with rails, than failure. And we're getting a LOT more done now than before when doing struts/JSP/JDBC style dev.

2. My lead developer wrote a book on Rails development for Oreilly, (rails handbook), he is leading our charge into Grails even having a substantial background in Ruby/Rails.

I'd never say I regret doing our projects in Ruby, nor do I feel like JRuby would of solved my problems. I'm happy with Grails, and it has well complimented our teams capabilities and experience. We write code to solve problems and generate revenue, we don't have the luxory of coding at a well funded public company, we pay our mortgages and car payments from code we write every week. Ruby has met the challenge for us, but it's silly not to explore our options to try and make our new projects even more robust and improve our development, and our current dilemma of ongoing maintenance.

Re:I think everyone would agree here... (1)

mgkimsal2 (200677) | more than 4 years ago | (#31057878)

In my previous post, I'd meant to say "grandparent", rather than parent (your post). Still, given my position, I'm always happy to hear about Grails adoption successes. :)

Rails popularized a lot of ideas that have since been adopted/adapted by many other frameworks, including Grails. I'm not sure many people could argue that "convention over configuration" has overall been a *bad* thing for web development, especially in the Java world.

Re:I think everyone would agree here... (0)

Anonymous Coward | more than 4 years ago | (#31057966)

I really enjoyed this reply. Using third person "I think the parent...." is an excellent way to keep the reader (me) interested in the topic of discussion.

Re:I think everyone would agree here... (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#31056886)

"But we now have one web app with over 900 controllers" ... If ever there was a case for Your Doing It Wrong. VERY FUCKING WORNG

Re:I think everyone would agree here... (2, Insightful)

Big_Mamma (663104) | more than 4 years ago | (#31057142)

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval. It gets even worse if you need to optimize that data retrieval. At this point, ActiveRecord becomes a huge pain in the ass, rather than a useful tool.

Hmm, can you explain why? I haven't worked with Rails much, but in Django, if things are too slow like in a really complex query spanning so many tables that the PostgreSQL optimizer chokes, you can hand optimize it easily by either rewriting how you specify it in python, breaking it up into multiple statements. You can also choose to retrieve the data as plain tuples or map/dicts if you need to fetch thousands of rows (100k+, I've no problem with 20k/query the normal way at all). If all fails, plain sql is just 2 statements away, with an easy way to turn the results back into objects.

A good ORM recognizes that there are situations that falls outside of the common/simple use cases and should assist you in the harder things, not work against you.

Re:I think everyone would agree here... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31057424)

Django is developed by professionals who have developed very large systems, who do realize that sometimes you need to fall back to manually-written queries, and who thus have made it easy to do so.

Ruby on Rails has been developed by people who repeatedly develop blog systems, and bug trackers. These projects rarely exceed what a college student is expected to produce as part of their coursework. Thus they have made no allowance for dropping back to raw SQL queries. It's pretty astounding, but very unfortunate. It's the reason I don't use RoR.

Re:I think everyone would agree here... (3, Insightful)

arthur.gunn (1687888) | more than 4 years ago | (#31058310)

Not true.

Model.find_by_sql sqlstring

or even more primitively:
ActiveRecord::Base.connection.execute( sqlstring )

Easy. Although you really shouldn't have to use it if you understand relations properly.

Also note that rails 3 is going to have Arel, an Object-Oriented interpretation of the Relational Algebra. It is a mathematical model for representing “queries” on data. It understanding relations this fundamentally means it can optimise easily.

Have a look at:
http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/ [wordpress.com]

Re:I think everyone would agree here... (2, Interesting)

SanityInAnarchy (655584) | more than 4 years ago | (#31057152)

First, I truly dislike "convention over configuration". The main problem there is that they "convention" they use is far too limited for any sizable application. It may be sufficient for a blog web app, or a bug tracker, or small-scale applications like that. But we now have one web app with over 900 controllers, and "convention" falls apart at this size.

First, yes,

we probably should refactor our app, but we're not in a position to do so at the moment.

you should, and this would be biting you in the ass just as much with other technologies.

But keep in mind, "convention over configuration" is not "convention instead of configuration". The idea is that if you follow the conventions, things work better. If you need to go beyond them, you can still configure things.

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval.

For what it's worth, I prefer Datamapper. I don't have especially bad memories of ActiveRecord, though -- but I probably wasn't doing especially complex queries.

But note, again, it's about convention over configuration. Nothing's stopping you from hand-coding raw SQL, or even going entirely around ActiveRecord in the few cases where you actually need that. The other lesson is, of course, that if your queries are your bottleneck, there are probably other tricks you could be doing, like memcached.

And like it or not, the performance of Ruby is quite poor. We actually had to purchase some additional hardware to handle the extra load after converting an old Java-based web app to Ruby on Rails.... It was cheaper just to buy more hardware.

That's part of the point of Rails, though. It usually is cheaper to buy more hardware than to optimize, Ruby just forces you to face that up front.

Sure, sometimes you can change your algorithm from O(n^2) to O(logn) and get a massive speedup, and it's worth it when you can do that. But an extra 5-10% likely isn't worth it until you're of sufficient size that 5-10% of your hardware is costing more than hiring an extra person to do those optimizations.

Re:I think everyone would agree here... (3, Insightful)

ZorbaTHut (126196) | more than 4 years ago | (#31057568)

That's part of the point of Rails, though. It usually is cheaper to buy more hardware than to optimize, Ruby just forces you to face that up front.

I haven't actually used RoR, but you have to admit that this sounds like you're taking "ruby is really slow" and trying to spin it into an advantage.

"Most people end up having to optimize eventually. But that's hard. Ruby on Rails can't be optimized! You just have to buy more hardware! Isn't it great!"

Re:I think everyone would agree here... (0)

Anonymous Coward | more than 4 years ago | (#31057938)

You have a good point, and IMO the "buy more hardware" meme is a terrible message to be sent to less experienced programmers.

One one hand, "Scaling through purchasing hardware is easier than deep optimization and refactoring" is generally true. But in the Rails world that often translates into "Scaling through purchasing hardware is easier than learning the RDBMS and not abusing ActiveRecord."

Furthermore the scalability issues in Rails are multifaceted, there's really no single-bullet answer to the issue.

Re:I think everyone would agree here... (0)

Anonymous Coward | more than 4 years ago | (#31058016)

I think the point of Rails 3 is to step back a bit from convention over configuration. They still ship with defaults, but they've made it trivial to swap out bits of the framework. If you don't like Active Record, for example, you can bring in sequel or datamapper or roll your own and still integrate seamlessly with the rest of the framework.

Re:I think everyone would agree here... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31056394)

So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?

How about, we don't care? Back in the day, Ruby on Rails promised that it will "kill developers" and CEO-s will be coding the sites themselves in Rails, the hype was THIS big. "Programmers obsolete??".

Soon after it turned out "real programmers" can't scale a Rails app to save their job (Twitter).

Your moment of marketing glory is over. Have the decency to go in a corner and die.

Just like Google, anybody saying one bad word against the slashbot groupthink that RoR is the second coming gets modded into oblivion. AC was just saying what many of us think, just like PHP RoR is a great language to write not-so-serious apps on. It's praises are sung by the same group that think MySQL is the ultimate enterprise database.

Re:I think everyone would agree here... (5, Funny)

HeronBlademaster (1079477) | more than 4 years ago | (#31056480)

It's praises are sung by the same group that think MySQL is the ultimate enterprise database.

Everyone knows the real ultimate enterprise database is Access.

Re:I think everyone would agree here... (1)

selven (1556643) | more than 4 years ago | (#31056968)

Nah, the real ultimate enterprise database is Google Spreadsheets.

Ah, the anti-groupthink groupthink... (1)

SanityInAnarchy (655584) | more than 4 years ago | (#31057200)

Do you have an original thought of your own?

Take a look at some of the replies. I see two which bash Rails quite a lot, they just actually put some thought into it. They got modded up, and you got modded down.

But hey...

Ruby on Rails promised that it will "kill developers"

I don't think anyone ever claimed that, except you.

Soon after it turned out "real programmers" can't scale a Rails app to save their job (Twitter).

They still have jobs, and Twitter still runs Rails on the web interface.

Your moment of marketing glory is over.

We're programmers. Marketing doesn't quite work if there isn't at least something to back it up -- that's why we're not all using ASP.NET.

AC was just saying what many of us think,

Nice how you post this as an AC, also...

just like PHP RoR is a great language

Nope, PHP is a language, and it's not great. Ruby is a language, but Ruby on Rails is not a language, it's a framework.

I could find dozens of reasons Ruby is better than PHP, but hey, Facebook runs on PHP.

It's praises are sung by the same group that think MySQL is the ultimate enterprise database.

Rails supports Oracle and SQL Server. But hey, MySQL still runs Twitter.

Standard Slashdot Ruby comment form (5, Insightful)

metalhed77 (250273) | more than 4 years ago | (#31055990)

Please pick form the list below

Ruby and/or Rails sucks because:
    1. It doesn't scale (Twitter)
    2. It's slow
    3. I read somewhere that Python was a better language
    4. I write PHP, I can do everything Ruby/Rails can do better
    5. My obnoxious younger coworker uses it
    6. It's not lightweight enough
    7. The ruby community is full of over-hyping zelous twits
Ruby and/or Rails is awesome because:
    1. It scales within reason (Twitter, Lighthouse, Shopify)
    2. It's as fast as Python and PHP
    3. I read somewhere it was better than Python
    4. I used to write PHP, Ruby's been a godsend
    5. There are so many motivated and innovative people in the community
    6. It's featureful
    7. Pythonistas are over-hyping jealous twits

Re:Standard Slashdot Ruby comment form (5, Insightful)

Anonymous Coward | more than 4 years ago | (#31055996)

7. The ruby community is full of over-hyping zelous twits

Re:Standard Slashdot Ruby comment form (2, Interesting)

Anonymous Coward | more than 4 years ago | (#31056308)

This is exactly true. Rails was in full-scale OMG hype mode before they even found an application server that worked properly or had a decent XML library. (Many of the fundamental building blocks only appeared because people bought into the hype and found that Rails, as promoted, was simply unusable for anything more than a low-traffic blog.)

And I say this as a developer who really likes Rails, but the toy-developer nature of the community is it's biggest weakness IMO.

Re:Standard Slashdot Ruby comment form (3, Insightful)

MadCat (796) | more than 4 years ago | (#31058608)

I gave RoR a chance and evaluated it for a while, and while RoR isn't bad, it's community is absolutely terrible. Help is hard to get, and more often than not a simple question leads to 5 people falling over eachother to call you stupid in various degrees, yet they are unable to actually offer any help. A large majority (from what I've seen) of the community can only follow the "hype" and treats the RoR dev team like deities, yet has no idea how to do certain things, how to properly structure and architect software, and responds with vitriol when asked about this.

So instead I stuck to what I know, and have been using Catalyst [catalystframework.org] for my projects. That community is awesome, helpful, knowledgeable and not afraid to help out even for dumb questions.

In short:
RoR: loud, obnoxious, hype followers
Catalyst: quiet, friendly, no hype anywhere (which unfortunately means Catalyst is a bit in the shadows)

Just my 2 cents.

Re:Standard Slashdot Ruby comment form (5, Interesting)

16K Ram Pack (690082) | more than 4 years ago | (#31056512)

If you ever want to attract lots of blog comments, there are 2 subjects to cover:-

  1. Apple.
  2. Ruby on Rails.

Seriously, what put me off Rails was the utter zealotry of some of the people involved in it. Django is full of more sane folks.

Apple and Rails (3, Insightful)

200_success (623160) | more than 4 years ago | (#31057106)

Apple makes opinionated hardware. Rails is opinionated software. It's not surprising that the two fan bases act similarly. In fact, I would bet that there is a lot of overlap between the two groups.

Re:Apple and Rails (1, Interesting)

edw (10555) | more than 4 years ago | (#31057896)

Yes, but while there may not be right and wrong opinions, opinions can definitely be either thoughtful or stupid. A case in point: Rails likes to give your database tables plural names. This is a stupid opinion. I explained this on #rubyonrails years ago, but it seems that the developers, DHH included, were so enamored with their pluralize method that they didn't want to rip it out and do the sane thing.

It's convention over configuration, not instead of configuration, I read in another comment. Well, I tried to configure Rails to not pluralize table names...and Rails broke. If the pull of tradition and convention is so strong that very few people stray out of the ruts worn into the beaten path, deciding to break with convention means fixing all the latent bugs in the system.

One of the reasons to prefer singular table names is that it improves Rails's interoperability with the applications that either want to supply data to or consume data created by Rails. Web apps do not exist in a vacuum. I was told by DHH that such things were outside the scope of Rails, and therefore those pluralize calls would stay for the rest of eternity. And thus everyone who has their first involvement with relational databases using Rails becomes brain damaged. Hooray for opinionated software?

I soured on Rails early, though I have tried to go back to it on occasion, only to find that the hype still exceeds the reality by a significant factor. I'm very much a right-tool-for-the-job kind of person, but I haven't come across a project where a feature in Rails makes it uniquely suited to the situation over something like Django.

Don't get me wrong, I think Rails gave web development frameworks a much-needed wake-up call. The Java way of doing things circa 2004 was horrible. But Rails has no monopoly on smart developers -- an understatement? -- and smart developers are quick to adopt good ideas.

Some other reasons singular would be better... (2, Interesting)

weston (16146) | more than 4 years ago | (#31058544)

A case in point: Rails likes to give your database tables plural names...One of the reasons to prefer singular table names is that it improves Rails's interoperability with the applications that either want to supply data to or consume data created by Rails..

Another reason is that it gets you closer to relational thinking. Plural names come about because some think of tables as collections of records and it follows that said collection should get a plural name. So, your "person" record becomes your "people" table.

However, the table isn't really and formally a collection of rows. What you really have is a set of "person" relations; the plural on the end of relations there is where the plural belongs.

And I don't know how big of a performance hit pluralize yields, but it's doing something that doesn't have to be done: the convention could just as well be singular (and arguably would more properly be singular).

Re:Standard Slashdot Ruby comment form (3, Interesting)

Anonymous Coward | more than 4 years ago | (#31056548)

You're absolutely right. After seeing widely-publicized incidents like the trademark shenanigans [rubyinside.com] involving DHH, and then the blatant sexism at GoGaRuCo [ultrasaurus.com], I refused to become associated with that community.

As a professional, I don't want my name linked to such childish behavior. So I took Ruby and Ruby on Rails off of my resume in May of 2009, and have taken contracts dealing with Django and Python instead.

Unlike the RoR community, the Python community somehow seems to be able to avoid petty arguments and blatantly unprofessional behavior. Then again, the Python community is generally made of more experienced professionals interested in developing high-quality software applications, rather than 18-year-old college students "rebelling" against PHP to develop Web-2.0-buzzword-compliant web sites.

Re:Standard Slashdot Ruby comment form (2, Insightful)

Dhalka226 (559740) | more than 4 years ago | (#31058398)

Then again, the Python community is generally made of more experienced professionals interested in developing high-quality software applications, rather than 18-year-old college students "rebelling" against PHP to develop Web-2.0-buzzword-compliant web sites.

You clearly gave Rails a fair chance there, didn't you?

Perhaps your really silly reasoning for "taking Ruby on Rails off [your] resume" was really nothing more than self-selecting against a platform you had already decided was worse than one you clearly think more of?

Rails isn't for everybody, and it isn't for every project. But "ZOMG SOME RANDOM RAILS CONFERENCE HAD A BAD SPEAKER MAKE A BAD ANALOGY ABOUT TEH PRONZ!!!" is about the stupidest possible rationale for not using it.

Work with whatever you want, but don't pretend you gave it a fair evaluation.

Re:Standard Slashdot Ruby comment form (4, Insightful)

metalhed77 (250273) | more than 4 years ago | (#31056882)

7. The ruby community is full of over-hyping zelous twits

You know, I wrote my post as a joke, to hopefully prevent stupid comments like yours. That yours was modded (twice) up is proof of the juvenile partisanship present here on slashdot.

Re:Standard Slashdot Ruby comment form (0)

Anonymous Coward | more than 4 years ago | (#31058378)

Stop being such a zealous twit.

Re:Standard Slashdot Ruby comment form (2, Funny)

Foofoobar (318279) | more than 4 years ago | (#31056006)

You forgot Groovy and Grails does it better :)

Re:Standard Slashdot Ruby comment form (4, Funny)

Hurricane78 (562437) | more than 4 years ago | (#31056062)

What about F#lukie and FAILs?

Or Gravel and Nails? (Chuck Norris’ favorite morning cereal.)

Or Gravy and Meats? (Favorite British breakfast, I guess... especially in pie form. ;)

Re:Standard Slashdot Ruby comment form (1)

Neon Aardvark (967388) | more than 4 years ago | (#31056180)

Pearl on Paths

Diamond on Driveways

Topaz on Tracks

Sapphire on Streets

Aquamarine on Avenues

Re:Standard Slashdot Ruby comment form (2, Funny)

maxume (22995) | more than 4 years ago | (#31056650)

Somebody out there is just itching to write C on Crack.

Re:Standard Slashdot Ruby comment form (3, Funny)

Foofoobar (318279) | more than 4 years ago | (#31056190)

Actually Groovy and Grails are Java native. No need to interpret via JRuby. Groovy is native Java code as is Grails.

But being the ignorant troll that you are, your kneejerk response shows how little you know about these technologies and that you must have confused Slashdot with another one of your Facebook pages.

Re:Standard Slashdot Ruby comment form (4, Informative)

Hurricane78 (562437) | more than 4 years ago | (#31057848)

What the...
My friend, the fact that you misinterpreted my little funny and random word-play as having a “knee-jerk reaction” of an “ignorant troll” really shows, that you should go out more often, and have a little fun.
Because you are starting to see assholes everywhere.

See, the problem with text-only communication is, that we read it in the (inner) tone of voice of what we expect to read. Which is controlled by our own mood.
So if we expect ignorant trolling everywhere, that’s what we will always see. Which makes them that, in our reality.

And because I just recently realized that I did the same... man... it’s not good for you. You are getting angry where you could have a little laugh etc. Basically making your own life bad. :/

Look at the moderators. They got it right, and even modded you funny, because of the good mood. :)
Chill, relax, kiss a girl. :)

P.S.: This is a dual-purpose comment. In case parent comment was really meant funny, it’s meant funny too. In case it’s not, this one also isn’t. :D

7 seven 7 seven 7 seven 7 seven 7 (0)

Anonymous Coward | more than 4 years ago | (#31056078)

7 seven 7

Re:Standard Slashdot Ruby comment form (2, Insightful)

Yvan256 (722131) | more than 4 years ago | (#31056184)

Ruby and/or Rails sucks because:
8. None of the local web hosting services offer it except in their most expensive packages, all we get for the low-cost packages is XSSI, PHP and Perl.

Re:Standard Slashdot Ruby comment form (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31056254)

Shut the fuck up.

Re:Standard Slashdot Ruby comment form (2, Funny)

Anonymous Coward | more than 4 years ago | (#31056618)

Shut the fuck up.

Say, do you happen to do any Ruby on Rails consulting? You're more polite and better-spoken than most Rails consultants I've had the "pleasure" of working with so far. I might have some work for you.

Re:Standard Slashdot Ruby comment form (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31056310)

Who the fuck is using "web hosting" these days? Get a $15-20/month VPS and stop whining.

Re:Standard Slashdot Ruby comment form (0)

Anonymous Coward | more than 4 years ago | (#31056340)

What about clients who don't want to/don't care to/can't host their website?

Re:Standard Slashdot Ruby comment form (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31056400)

They aren't paying developers, that's for sure.

Since you're obviously some low-level sysadmin monkey with really ghetto clients, why not just dowload the free buggy PHP shit from freshmeat and stop bitching up every other language thread?

Re:Standard Slashdot Ruby comment form (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31056594)

What a stupid comment. Many small to medium businesses will pay good money for a decent web app but have no interest in hiring a sysadmin permanently for the purpose of keeping it running when that can be outsourced for $15/month with the same outcome. Of course in your little world nobody cares about the app they are building, they only care whether it runs on RoR or not. Go and propose your RoR solution to a bank or telco or some such, I am sure they are dying to hear your excellent insight as to why RoR is the ultimate in enterprise development.

As usual /. draws out the "developers" who have build a little personal blog with a toy language like RoR using MySQL then lend their "expert" opinions as to why their little toy is actually quite similar to a large scale business app.

Re:Standard Slashdot Ruby comment form (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31056838)

Haha, you ghetto-ass LAMP trash can't even keep your story straight. You can't rip on MySQL and beg for $10/month trailerpark hosting at the same time.

You here the same complaints around here about Java or .NET or Postgres and everything else that isn't baseline LAMP dogshit. The reason being there is a whole cottage industry of sysadmin HTML monkeys who replace the logos on freshmeat garbage and sell it to their cheap-ass "clients" (the local wig shops and chicken counters).

Re:Standard Slashdot Ruby comment form (0)

Anonymous Coward | more than 4 years ago | (#31057236)

Wow - you think RoR is even in the same ballpark as Java or .Net? Methinks your idea of a large application and the rest of worlds idea of a large application are orders of magnitude different in size...

Re:Standard Slashdot Ruby comment form (1)

metalhed77 (250273) | more than 4 years ago | (#31056866)

Well, if you want good, cheap rails hosting you could easily do Dreamhost or Heroku. I'd go with Heroku, they'll scale up pretty well.

Re:Standard Slashdot Ruby comment form (2, Informative)

PCM2 (4486) | more than 4 years ago | (#31057124)

Hostgator offers Rails on all their plans, too, which start at $4.95/month. I think someone's not looking hard enough.

Re:Standard Slashdot Ruby comment form (1)

Lord Ender (156273) | more than 4 years ago | (#31057224)

ASmallOrange.com has Ruby web app hosting for $5 per year.

Google App Engine offers JRuby hosting for free, though you have to deal with App Engine's miserable Java performance problems.

Re:Standard Slashdot Ruby comment form (1)

SanityInAnarchy (655584) | more than 4 years ago | (#31057246)

And the biggest "problem" there is the lag while they spin up an instance of your app. The most promising thing I've seen about that is a proposal to cache a JRuby image as Java bytecode -- that should drop us back closer to Java spin-up times, which really aren't that bad now.

Re:Standard Slashdot Ruby comment form (1)

Lord Ender (156273) | more than 4 years ago | (#31058598)

Java loads on App Engine are so slow, even a Java "hello world" app will occasionally time out. Java spin-up times are typically OK (1-4 seconds usually) but are occasionally and unpredictably unacceptable.

Re:Standard Slashdot Ruby comment form (1)

Draek (916851) | more than 4 years ago | (#31057830)

Shouldn't that be the other way around? local web hosting services suck because none of them offers Ruby and/or Rails in their low-cost packages.

Yeah, yeah, grandma won't care whose fault it is when she can't run her knitting patterns e-store, but put the blame where its due. It's not Rails' fault that web hosting services won't offer a language worth shit unless you pay for the priviledge.

Re:Standard Slashdot Ruby comment form (0)

Anonymous Coward | more than 4 years ago | (#31056346)

Ruby doesn't suck, I first checked it out around 2003 and impressions were good. Wrote a couple of small programs for fun and moved on. Never used it seriously because I'd use perl, python, PHP, javascript, lua or shell scripting where they're strongest and there's zero advantage to using ruby in any real world situation I can think off.

Rails let 'developers' with no fucking clue whatsoever churn out cookie-cutter apps that performed about as well as you'd expect. The bullshit being spewed forth a couple of years back was offensive because it put us in an unfavorable positions with potential clients.

No, we can't write a high load web site in two days using a slow scripting language and ORM. What you're asking for is two months work and it'll be written in perl or PHP with anything heavyweight being done in C; alternatively we can write the entire thing in Java. Yes, we're more expensive than the Rails shop. Yes, the Rails shop are offering [biting tongue] a faster turnaround.

Long story, short story. We're still in business, several of the Rails shops we bid against are not.

Re:Standard Slashdot Ruby comment form (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31056476)

Lets not confuse the technology issues with the business issues.

I'll speculate those Rails shops folded because they were 24 year old noobsters who bought into the Agile bullshit, which simply does not work for fixed budget/fixed time development projects where clients expect a finished product. All those "two-week" projects probably turned into three-month over-budget development hells with dissatisfied customers.

Technology-wise, its not as if Java/etc devs don't load up the ORMs and other frameworks and spew out massive amounts of poor-performing cookie-cutter code. The difference is that the architects and PMs are smart enough to estimate the projects properly.

Re:Standard Slashdot Ruby comment form (1)

metalhed77 (250273) | more than 4 years ago | (#31057726)

Hey, I agree, I wrote that post as a joke, almost all the negatives are easily dis-proven falsehoods. The knee-jerk zealots on Slashdot are too arrogant to educate themselves about this language unfortunately.

Re:Standard Slashdot Ruby comment form (1)

Jane Q. Public (1010737) | more than 4 years ago | (#31058540)

Haha that's actually funny because that was the point I made in my own post. In my experience, most people who make these objections simply haven't bothered to learn about it.

I even lost a job because of that once. The senior programmer at the company wanted to do everything in PHP, and was constantly putting a bug in the boss's ear about how he "didn't trust this new Ruby on Rails stuff... it's funky and unreliable." But he NEVER bothered to actually learn anything at all about it, despite our frequent prompting and offering to help.

Eventually, all the RoR work was shut down... despite the fact that they never found another technology that would do the particular niche work we were doing, and despite the fact that we had been quite successful at doing it. We had finished 3 major projects and by then we had done enough meta-programming that the next one would have taken a fraction of the time. They just closed down that part of the operation, even though it was profitable. Because 1 guy preferred PHP. Talk about shooting yourself in the foot!

Re:Standard Slashdot Ruby comment form (1)

metalhed77 (250273) | more than 4 years ago | (#31058584)

Eeesh, what a tragedy. I got the same BS at my job, luckily my higher up was fired and I replaced him, letting me turn our crapload of PHP into Rails.

I took a good long look at the PHP MVC world when it was clear my company wasn't going to drink the Rails kool aid, and I have to say, none of the PHP frameworks were (at the time, 2 years ago) up to snuff compared to Rails. They were just flat out missing a lot of the features that made Rails great.

Plus, it takes me way less time to code in Ruby than PHP, PHP just takes more LoC, especially as your app's complexity increases.

Re:Standard Slashdot Ruby comment form (1)

JAlexoi (1085785) | more than 4 years ago | (#31056420)

The magic of math, my response is a sum of two of my answers: 10.
Now guess what my answers were...

Re:Standard Slashdot Ruby comment form (2, Funny)

s_p_oneil (795792) | more than 4 years ago | (#31057110)

Good post, but IMO it's a shame you left this one out:

Ruby and/or Rails sucks because:
8) It doesn't use spacing to delineate code blocks

Ruby and/or Rails is awesome because:
8) It doesn't use spacing to delineate code blocks

Re:Standard Slashdot Ruby comment form (1)

bill_mcgonigle (4333) | more than 4 years ago | (#31058252)

Ruby's a great language with a mediocre runtime (but getting better) and Rails is a great idea with massive breakage and version dependency problems among minor versions. Maybe that just means it's not done yet, but, man, stuff should work on 1.8.6 and 1.8.7 the same way and Rails 2.2.1 and 2.2.2 should cause huge breakage (I'm only recalling those versions from memory, apply fuzz).

Re:Standard Slashdot Ruby comment form (1)

Jane Q. Public (1010737) | more than 4 years ago | (#31058488)

The Ruby and Rails core groups have both been excellent about documenting any issues, and also offering plenty of warning and deprecation time before features are changed or dropped. If minor version changes in Ruby or Rails are not getting along with some of your Gems or Plugins, I would start looking at the suppliers of those Gems and Plugins, not Ruby or Rails.

Mod submitter -1 Troll (0)

Anonymous Coward | more than 4 years ago | (#31056010)

WTF kind of troll-ass summary is this? It's be like seeing a Microsoft announcement like this:

Office 2010 is almost out; is it gayer than nine guys blowing eight guys, or just a total piece of crap?

BTW: a preemptive STFU to the scaling trolls. Take your whinge back to 2005, where somebody might give a crap.

Cynicism = good sign (3, Funny)

dino213b (949816) | more than 4 years ago | (#31056026)

I'm glad first responses are so negative; now I don't have to bother trying ROR out.

Re:Cynicism = good sign (1, Redundant)

Jane Q. Public (1010737) | more than 4 years ago | (#31058580)

"First responses" were years ago. The people who are still bitching about it are people who have not gotten to know it well.

I have many years experience in programming, but I have spent the last 4+ doing Ruby, and Ruby on Rails. And I love it. I have yet to find something another languages and frameworks do that RoR will not, and usually RoR does it simpler and more easily.

It does in fact scale quite well, and while it is relatively slow, all interpreted dynamic languages are.

There is a learning curve, probably a bit more than most languages, but once you get past the hump it's a pretty nice ride. Most of the objections are coming from people who haven't gotten there.

A ton of Rails 3 Beta links (4, Informative)

Peter Cooper (660482) | more than 4 years ago | (#31056056)

Over at Ruby Inside we did (and are maintaining) a roundup of ~36 Rails 3.0 beta links/articles [rubyinside.com] (it's up to about 40 now, I think). If you've got Rails 3.0 installed and want to know how to use X or Y or want to learn some of the back story/motivation, the links should come in useful. They're only things that are actually worth reading. Well, mostly.. :-)

It's a great day to be a rails developer! (1, Informative)

Anonymous Coward | more than 4 years ago | (#31056066)

I just love the rails development community...they've really shown that they welcome any new ideas, frameworks etc and incorporate the best of everything into a fully fledged release.

Well done and Thank you.

Buzzword Alert! (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31056068)

...agile...

That's where I stopped reading. I'm on a no-buzzword diet.

Re:Buzzword Alert! (0)

Anonymous Coward | more than 4 years ago | (#31056362)

You probably missed the announcement of Emeralds on Asphalt 3.0 beta too. It's heavier, more waterfall-like and harder to understand.

Re:Buzzword Alert! (1)

John Whitley (6067) | more than 4 years ago | (#31056630)

That's where I stopped reading. I'm on a no-buzzword diet.

Excellent! More enjoyable and better paying work (and better co-workers) for the rest of us clued enough to realize when there's real substance behind those buzzwords. Have fun with that self ghettoizing!

Re:Buzzword Alert! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31056744)

Oh noez - I won't get a gig developing toy applications!!!1! I'm sure missing out now I won't get hired for those personal blog or omgz here's my homepage type projects.

Testing (1, Interesting)

rgravina (520410) | more than 4 years ago | (#31056336)

Slightly off-topic, but since a lot of comments are about how Ruby and Rails has nothing other popular dynamic languages and frameworks have to offer, I'd like to say there's one thing which drew me to Rails which I couldn't find in any popular Python or PHP web frameworks.

Testing. Craftmanship. Quality. This is more cutural than technical. While it's technically possible to write tests in PHP and Python, it just seems like people rarely do (especially so with PHP). And even if they do write tests, it's an afterthought. Things may have changed since I've done any serious development in PHP or Python, but I've done a little with Django and the testing that's done in the community didn't come close to Rails at the time. I'd be lucky to find a plugin authour whom had a test suite for their work and there was nothing of the function or quality of RSpec or Cucumber around.

This kind of lax "I tried it in my browser so it works" attitude to web software development in PHP and Python almost made me want to give up on web development and get into some other type of programming with some real professionalism - but thankfully I found Rails and glad that in general Rails programmers take their work seriously.

Having said all of that, I don't want to paint too negative a picture of Python. There are some awesome frameworks and communities in the Python world - Twisted/Divmod, for example, where the community really are bright and dedicated to test driven development. Zope 3/Grok is another. But I couldn't find anything in the mainstream web development world which were. Being mainstream is unfortunately important in getting anyone to support your descision - be they management, or a client.

Re:Testing (4, Interesting)

Bogtha (906264) | more than 4 years ago | (#31056576)

I can't say my experience matches yours. There are two testing modules shipped by default with Python. Django has integrated support [djangoproject.com] for them out-of-the-box. Django itself has plenty of tests [djangoproject.com]. There are plenty of good third-party testing modules and people are pretty vocal about using them.

On the other hand, I do very strongly get the impression that the lax attitude of "I tried it in my browser so it works" is omnipresent in the Rails community, coming right from the top. Witness the uproar over the Google web accelerator. Rails was just plain wrong to use GET for unsafe operations. But "it worked in a browser", so they didn't see anything wrong with it, even though it was out of spec. GWA came along and triggered data-loss bugs in Rails applications that used unsafe behaviour for GET requests, including 37signals' applications. Rails developers, rather than simply saying "whoops, our bad, we'll fix this ASAP", called GWA evil and wrote code to block GWA. Roll forward a year, GWA changes its behaviour and the blocks don't work any more, the same things happen all over again, and the Rails developers call GWA "scary" and "malicious". These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention.

As for the word "professional" in particular, that's a dirty word [twitter.com] in the Rails community.

Re:Testing (0)

Anonymous Coward | more than 4 years ago | (#31056918)

DHH != Rails

Re:Testing (1)

jemmyw (624065) | more than 4 years ago | (#31057086)

Well Rails itself wasn't responsible for developers putting unsafe operations behind GET requests, you can shoot yourself in the foot with any language. Rails convention (now) is for a RESTful service where each operation does what it says (GET gets, POST posts, PUT puts, DELETE deletes). I think that perhaps the Rails community will have to accept "professionals", like it or not, if larger companies start using the framework. Also I think that a few very vocal developers who consider themselves central to the Rails community are quite unprofessional in a bad way.

HTTP methods (2, Interesting)

200_success (623160) | more than 4 years ago | (#31057180)

That wouldn't be the only time that Rails has been sloppy in choosing the right HTTP method to use. When they implemented REST, they got PUT and POST backwards. Compare with CouchDB, which gets it right: PUT to create and POST to update a record.

Re:HTTP methods (2, Informative)

mini me (132455) | more than 4 years ago | (#31057514)

Not true. From the CouchDB docs:

To create new document you can either use a POST operation or a PUT operation. To create/update a named document using the PUT operation, the URL must point to the document's location.

In other words, because CouchDB allows you to define the document ID before it is created, you can use PUT to pass that information upon creation. But if you want CouchDB to define its own document ID, you must use POST. This is consistent with the HTTP spec.

Rails apps, on the other hand, typically do not allow you to define the ID of the record you are manipulating. It is assumed that the database, or at very least the application, knows how to handle this operation best. That is why creates are almost always POST for Rails apps. Again, this is consistent with the HTTP spec.

Re:HTTP methods (1)

Jane Q. Public (1010737) | more than 4 years ago | (#31058622)

Actually this is not true. While a newly instanced object (or record as you are using it) may not have an ID using the Object.new() syntax, Rails has always allowed you to create a record with an ID. The fact that you did not know this does not say much for your experience with it.

Nevertheless, while you can both create a new record with an ID, or specify your own ID for an object, the former can cause issues if you are not careful, and the latter was determined by the Rails folks (correctly) to be generally BAD PRACTICE, because any logic errors on your part could hopelessly (and very easily) screw up your DB's table index. They were correct in deciding to make it not easy to do that accidentally.

Re:Testing (0)

Anonymous Coward | more than 4 years ago | (#31058294)

Rails today is based largely on REST concepts. They learned from those early mistakes and are better for it.

Re:Testing (2, Interesting)

metamatic (202216) | more than 4 years ago | (#31056884)

Testing. Craftmanship. Quality. This is more cutural than technical.

Funny, my experience of the Rails community is that it attracts a lot of crackpots who don't believe in documentation--not even API documentation.

Re:Testing (0)

Anonymous Coward | more than 4 years ago | (#31057128)

I have to agree somewhat about the lack of both solid tests and solid documentation. There seems to be a lot of TALK about testing in the RoR community, but a lot of the test tools (and the debuggers, for that matter) are underdeveloped and immature. I've run into undocumented or counter-documented behavior more than once when writing Cucumber tests, for example. I've also seen a lot of code where the rcov coverage reports are okay, but looking at the actual cases tested, you see that only the bare minimum was done (e.g., build from the scaffolding and don't think through the tests too much). The only significant documentation to back any of these tools: forum posts. The biggest things reining in my excitement about RoR are the underdeveloped development and testing tools and the total disregard for documentation, really.

Now, to play devil's advocate against myself, I'm not a web application developer by trade - I do high-reliability embedded software (avionics), so I'm used to a pretty stringent level of required testing that isn't really appropriate for most web apps. I'm also really only at a hobbyist level for RoR - I've only used it off and on for about the past year, spending maybe 2 or 3 months of real time working with it, so I'm sure I'm still running into seriously rookie problems. Still, the talk about RoR doesn't really jibe with the reality of the situation, at least from what I've seen so far.

Re:Testing (0)

mini me (132455) | more than 4 years ago | (#31057570)

While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting. Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.

If you need the documentation you are looking for in a Rails app, it was written poorly, or, dare I say incorrectly. So yes, you are right, you're not going to find the documentation you might find in other languages and frameworks. But it just isn't necessary most of the time if the app is written well.

Re:Testing (0)

Anonymous Coward | more than 4 years ago | (#31057890)

I hope I don't work in the same company as you.

That's a very dangerous thought process. Each language has it's own way of doing things and not everyone thinks in a way that fits every language. I know some people who swear by Lisp. I personally swear at it because it doesn't fit my brain.

You should never rely on code alone to document how to use something.

Re:Testing (3, Insightful)

beguyld (732494) | more than 4 years ago | (#31058180)

While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting. Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.

Yeah, sure... I've inherited plenty of code by people who were religious about the "no comments" idea. Utter nonsense.

Yes, my own code is as self documented as possible. It shows HOW, but it can't show WHY. Code alone can 't describe the overall context of why that code, and now some other code, or how it fits into the whole. That's what comment blocks are for.

Otherwise, you're just doing like the current US government, and burdening future generations with the true cost of today's "short cuts." It's self-centered and short-sighted.

If it is truly "throw away" code, fine. Don't comment it. But that is about 0.001 % of all the code I've seen in the last 25 years.. Good rule of thumb is that all code lives forever, and will be read 100 times for every time it is read. Thus the ROI on comments is enormous and always worth doing.

Re:Testing (0)

Anonymous Coward | more than 4 years ago | (#31058418)

hahahahahahahahahahahahahhaha

wtf d00d

Re:Testing (0)

Anonymous Coward | more than 4 years ago | (#31058494)

Maybe its just me, but a language that encourages monkey patching and anonymous methods is not very "self-documenting". Any trips I've made into the Rails source code have resulted in a lot of WTFing trying to figure out what's really going on.

Plus that entirely misses the point of an "API" being a documented interface rather than a random heap of methods sitting on your disk.

The documentation for Ruby on Rails is horrible (0)

Anonymous Coward | more than 4 years ago | (#31057196)

I REALLY wanted to like ruby on rails, but the problem is that there is no good documentation on the internet, and of the 3 books I tried, all were designed for ancient versions of Ruby (and used depreciated functions in the first few chapters). So instead, I'm giving Django a try.

Unless Ruby On Rails 3.0 API is more stable, and there are good official tutorials, I don't think it will matter how good RoR3 is, if thee isn't enough documentation again to help newbies.

Re:The documentation for Ruby on Rails is horrible (1)

Stiletto (12066) | more than 4 years ago | (#31058452)

Count me among the people who wish the Rails guys spent more time on documenting, settling the framework and standardizing things... and less on making yet another Rails version that's different than the previous ones.

We're talking about a system where (to many) it is considered "best practice" to freeze your gems, including rails, to a particular version by copying them into your vendor directory, because of the breaking changes that happen from version to version. WTF??? It's like telling a C programmer he ought to copy the standard library headers into his source tree just in case the next version of C changes strcpy().

Re:The documentation for Ruby on Rails is horrible (1)

arthur.gunn (1687888) | more than 4 years ago | (#31058566)

Excellent documentation, good official tutorials:

http://guides.rubyonrails.org/ [rubyonrails.org]

One of the goals of rails 3 is indeed a solid public api.
In fact because of rails' goal to be more modular / customisable the public api is going to constitute the only communication between rails' components.

Respectfully, a question (1)

djheru (1252580) | more than 4 years ago | (#31057658)

I am a php developer that does a lot of small to medium sized apps using zend framework. I don't plan on doing anything enterprise scale, my niche is what it is. Do you see any advantage to zend framework over ROR?

Zend Framework isn't. (2, Insightful)

weston (16146) | more than 4 years ago | (#31058364)

I am a php developer that does a lot of small to medium sized apps using zend framework. I don't plan on doing anything enterprise scale, my niche is what it is. Do you see any advantage to zend framework over ROR?

I don't know Ruby or Rails well yet. But I do know PHP pretty well. And my answer is: no. Not as a framework.

Zend Framework isn't a web application skeleton / development system. It's an over-objectified library of barely related pieces. Yeah, there's a controller and a recommended directory layout, and you can pull it together with the rest of the library and a project or two elsewhere (say, Doctrine and Smarty), but it's not a thought-out whole. The job of creating an overall architecture for your app and getting the components to work together becomes yours.

Maybe that's what you want, and if so, then Zend Framework or doing things by pieces in Ruby (say, Sinatra + Sequel + HAML/SASS) could be for you. But if you want an actual web application framework, then I'd look at something like Code Igniter or Symfony (for PHP) or Rails or Merb (for Ruby) instead.

Re:Respectfully, a question (1)

moore.dustin (942289) | more than 4 years ago | (#31058386)

Keep using zend, especially if you are using the IDE and debugging features. In this case, go with what you know.

I can answer a few of the objections. (0, Troll)

Jane Q. Public (1010737) | more than 4 years ago | (#31058446)

(1) It doesn't scale worth a darn.

It actually scales better than just "within reason": yellowpages, scribd, hulu, github, odeo, jango. They don't seem to have any problems. (Twitter is hardly a good example. There was a lot of debate about that and its move to Scala for some [not all] operations. Frankly, it appears that Twitter's approach to programming has been similar to its approach to its business model: "What we did isn't working, and we don't know why... but we don't know what will work, either, so we'll just try something random.)

(2) It's slow.

Yep. What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those. It's the nature of the beast. You want something faster? Pay out the extra cash to build your site using Java or C++. But both Ruby and Rails continue to improve in speed and together today on average are several TIMES the speed they were a few years ago.

(3) It's not suitable for large projects.

Sure, if you don't know how. It actually does just fine. See the answer to (1) again. While the very top-traffic sites are not built in RoR (they are too old to have been), ebay, yahoo, amazon, and others all have Rails projects in the works.

(4) Python is better.

Maybe, if you're a masochist. Ruby and Python do most of the same things, but Ruby often does it easier and cleaner.

Ruby and Rails aren't perfect. But most of the objections come from people who don't know much about what they're talking about. Not all, certainly, but most. It can be harder to understand than Visual Basic or C++, but any newer technology has some learning curve. If you don't want to bother learning about it, then just be quiet and use whatever else you like.
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...