Restructured Ruby on Rails 3.0 Hits Beta 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?"
Buzzword Alert! (Score:1, Interesting)
...agile...
That's where I stopped reading. I'm on a no-buzzword diet.
Re:Standard Slashdot Ruby comment form (Score:2, Interesting)
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.
Testing (Score:1, Interesting)
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:I think everyone would agree here... (Score:1, Interesting)
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:Standard Slashdot Ruby comment form (Score:1, Interesting)
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 (Score:5, Interesting)
If you ever want to attract lots of blog comments, there are 2 subjects to cover:-
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.
Re:Standard Slashdot Ruby comment form (Score:3, Interesting)
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:Testing (Score:5, Interesting)
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:I think everyone would agree here... (Score:5, Interesting)
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:Testing (Score:3, Interesting)
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:I think everyone would agree here... (Score:3, Interesting)
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.
HTTP methods (Score:3, Interesting)
Re:Apple and Rails (Score:2, Interesting)
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... (Score:3, Interesting)
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).
TPS (Score:4, Interesting)