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?"
Standard Slashdot Ruby comment form (Score:5, Insightful)
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 (Score:5, Insightful)
7. The ruby community is full of over-hyping zelous twits
Re: (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.
Re: (Score:3, Insightful)
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
Re: (Score:2)
I agree with your comments - but the merb community has been awesome. Now that the merb dudes are core contributors to Rails 3.0 there is some hope that they will "unsuck" the elitist/cult-of-personality mania in the core Rails community. In the end the guy running the community makes a big impact - get cool people like Brian Behelendorf evangelizing Apache, Linus Torvalds for Linux and you get open, interesting communities. DHH has turned RoR into a Steve Jobs look-a-like. Ezra Z (original author of merb)
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.
Apple and Rails (Score:4, Insightful)
Re: (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 trie
Re: (Score:3, Informative)
ActiveRecord::Base.pluralize_table_names = false
simple.
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
Re: (Score:2)
And I don't know how big of a performance hit pluralize yields
It adds a couple of milliseconds to the startup time and that's about it. If you didn't manually specify a table name in the class, it will use the plural version of the class name and store that in the table_name variable when you start the app. Actually, most of Rails' "magic" is performed during application initialization (dynamically creating methods and setting variables) and after that it's (internally) just running code as usual.
You can also just add config.active_record.pluralize_table_names = fal
Relations and Tuples (Mod parent up!) (Score:2)
This isn't the standard usage. You have a set of "person" tuples - one person, one tuple, the set of person tuples forms a relation, singular.
That's interesting. Different from the way I had it explained, but I wouldn't be surprised if I or they had gotten the terminology for tuple and relation confused, and the distinction you've mentioned does sound promising from a formal perspective.
Not sure whether mathematicians would call it a 'people relation' or a 'person relation'
To invoke my earlier statement in
Re: (Score:2)
I run a production rails app with pluralization turned off. I turned this feature off in 2006 and it worked fine then - it works fine now. I agree with you that this is a dumb feature.
Re: (Score:2)
Imagine a discussion forum about developing with Rails on OS X (I just checked, rails is part of the standard OS X install). You'd probably need asbestos trousers for that discussion group.
Re: (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 bla
Re: (Score:2, Insightful)
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 clear
Re:Standard Slashdot Ruby comment form (Score:5, Insightful)
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: (Score:2, Insightful)
Re: (Score:3, Funny)
Re:Standard Slashdot Ruby comment form (Score:5, Funny)
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: (Score:2)
Pearl on Paths
Diamond on Driveways
Topaz on Tracks
Sapphire on Streets
Aquamarine on Avenues
Re: (Score:2, Funny)
Somebody out there is just itching to write C on Crack.
Re:Standard Slashdot Ruby comment form (Score:4, Insightful)
C++ was written a long time ago.
Re: (Score:3, Informative)
Somebody out there is just itching to write C on Crack.
...or COBOL ON COGS [coboloncogs.org].
Re:Standard Slashdot Ruby comment form (Score:4, Funny)
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 (Score:5, Informative)
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
Re: (Score:2)
Re: (Score:2)
There is no reason to "interpret" via JRuby in any case. JRuby provides an AOT compiler (jrubyc) that compiles Ruby code to Java bytecode; in addition, the normal mode of operation for JRuby is to do JIT compilation on method bodies when first encountered and then execute the compiled method from then on.
Re: (Score:3, Insightful)
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: (Score:2)
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: (Score:3, Informative)
Hostgator offers Rails on all their plans, too, which start at $4.95/month. I think someone's not looking hard enough.
Re: (Score:2)
You forgot the "local" part. In my case it needs to be in Quebec, Canada.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2, Funny)
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: (Score:2)
Now guess what my answers were...
Re: (Score:3, Funny)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Bullshit. I remember very clearly the 1.8.x AND the 2.2.x upgrade issues. Both these updates broke my app - not the gems, the core application. I was using features they removed or changed without deprecation warnings. It took me only about 2 hours to figure out the issues and repair them in both cases, but core libs were broken silently by the Rails core in both those version releases.
Re: (Score:2)
My pick:
Ruby sucks because:
2. It's slow
7. The ruby community is full of over-hyping zelous twits
Rails sucks because:
6. It's not lightweight enough
Ruby is awesome because:
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
Full disclosure:
Ruby sure isn't perf
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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, PH
Re: (Score:2)
Re: (Score:2)
And t
Cynicism = good sign (Score:4, Funny)
I'm glad first responses are so negative; now I don't have to bother trying ROR out.
Re: (Score:2, Redundant)
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 cu
Re: (Score:3, Informative)
Besides speed should hopefully become less of an issue once people migrate to Ruby 1.9 with YARV and eventually 2.0 which will hopefully have a decent JIT over top of the YARV bytecode (or something else perhaps) that should help significantly with the speed issues.
(Especially if said JIT offers an unsafe optimization mode that makes certain documented assumptions about the code, like not changing the integer arithmetic methods, and other similar cases, the detecting of which can add significant overhead wh
A ton of Rails 3 Beta links (Score:5, Informative)
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.. :-)
TPS (Score:4, Interesting)
Re: (Score:2)
It depends on what you are doing with it: ROR makes some things extremely easy, and others extremely hard. If your website is mostly about doing the easy stuff, it's great. If your requirements are all about what ROR isn't any good at, ROR is worse than a dozen other frameworks, where you pay a larger upfront cost for more flexibility.
Re: (Score:2)
Now it's matured into the finest open source development web development stack available
Tsk, tsk, you kids. I think you'll find that Spring is what you're really looking for. It's built on top of a real programming language as well, not some bastard offspring of Perl and Python like Ruby.
Re: (Score:2)
Having used both Rails (1.something) and Spring (2.something), I can tell you which I prefer.
Hint: it's not the one that tosses out the compile-time checking and performance of your so-called real programming language by having you write everything in XML.
Also, I much prefer the bastard child of several useful and expressive programming languages to a language that has set the world back a decade or so by having people re-invent and re-implement things that were working years before it.
Apologies if this com
Re:I think everyone would agree here... (Score:5, Informative)
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].
Mutually exclusive?? (Score:5, Funny)
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... (Score:5, Insightful)
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... (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: (Score:2)
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 o
Re:I think everyone would agree here... (Score:4, Informative)
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: (Score:2)
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: (Score:2, Insightful)
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 optim
Re:I think everyone would agree here... (Score:5, Informative)
Thus they have made no allowance for dropping back to raw SQL queries.
Ignoring your inaccurate remarks about the core Rails developers, do you care to expand on the above mentioned claim?
count_by_sql: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002276 [rubyonrails.org]
find_by_sql: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002267 [rubyonrails.org]
Re: (Score:3, Insightful)
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.co [wordpress.com]
Re: (Score:3, Funny)
Hey, I can make stuff up out of the air too!
(1) PHP still has a serious floating-point bug. Try multiplying 3.000001 and any number ending in
(2) Oracle is going to roll back the last 47 bug-fix commits to the Java repository, but only for the OSS version. Then it will sell the up-do-date version commercially.
(3) Microso
Re: (Score:3, Informative)
In fact, the Rails team always promoted the fact that you can drop down to pure SQL when necessary as a feature of ActiveRecord. It is like there is some kind of distortion field between Rails developers and the rest of the world.
What was said: We developed this handy framework to make web development more enjoyable for developers. We hope you enjoy it.
What was heard: We developed this handy framework to allow everyone and their brother to build a web application. Fire those expensive programmers! They aren
Re: (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 abo
Re:I think everyone would agree here... (Score:4, Insightful)
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... (Score:5, Insightful)
you're taking "ruby is really slow" and trying to spin it into an advantage.
Nope, I'm saying Ruby is optimizing something else -- developer time. That isn't to say it will never be fast, and last I checked, the full Merb stack (and Rails 3.0 is also Merb 2.0) was on par with PHP.
It's also not that it's hard, it's that it's expensive, and a needless expense. Let me put it another way: Do you watch YouTube, ever? (Replace YouTube with Vimeo or any other Flash video website.) Do you ever bother to download a video just to watch it? I mean, you do realize that VLC takes a fraction of the CPU cycles that Flash does, for the same video, right?
But no, I bet you're just like 99% of the population -- it may burn more CPU, it may burn more battery, but you're going to just watch it in the Flash player until you have a good reason not to.
If it was really an issue, if your computer was so old and so slow that the Flash wouldn't play properly... Weigh the amount of time you'd spend in a video downloader against the cost of a low-end PC, and it's a no-brainer.
Ruby on Rails can't be optimized!
Nope, it certainly can, it's just hard, and may (in an absolute worst case) involve replacing parts of it with another language, like C extensions -- not an entirely alien idea to any game developer who's replaced bits of C++ with assembly. (No one would sanely claim that the next blockbuster game should be written in assembly for speed -- you optimize the tight loops that way, but the game logic should be higher level.)
And it's just an observation, I'm not sure if it's cultural or if it's the slowness, but it seems like Ruby people, especially Rails people, focus on horizontal scalability and optimizing their algorithms in the broad sense -- again, O(logn) vs O(n^2). Java vs Ruby is the difference between two servers and four, or a request taking 50 ms vs 100 ms. Your application logic is the difference between four servers and twenty (or not being able to scale at all), or between 100 ms and 2000 ms (or two days, or crash the server because you ran out of RAM).
These are good lessons for any system, but Ruby people seem to be especially conscious of it. Still, I think it illustrates something -- the language is going to be the least of your problems when it comes to optimizing any app, until you're at a much larger scale than 2-4 machines -- think hundreds. Eventually, it may be worth rewriting large chunks of your app, or doing a ground-up rewrite, in a more efficient language -- or it may be worth improving the interpreter of the language you've got (as Facebook has).
But you have to get there first. If you're busy doing Java because you want it to be efficient, and I steal all your marketshare because I write one line of Ruby for every five lines of Java, and I get to market while you've got a prototype with 20% of the functionality... I win. Even if I have to rewrite it all in Java later, I have the money to do that, because I've got the traffic.
Re: (Score:2)
Re: (Score:2)
"Convention over configuration" in Rails generally doesn't m
Re:I think everyone would agree here... (Score:5, Funny)
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: (Score:2)
Nah, the real ultimate enterprise database is Google Spreadsheets.
Re: (Score:3, Insightful)
Everyone knows the real ultimate enterprise database is Access.
If by "ultimate" you mean "last because it killed the enterprise stone dead through sheer crap-ness" then yes, everyone does indeed know that.
Re: (Score:2)
Access is totally sweet, because its entire purpose is to flip out and kill the enterprise.
Re: (Score:2)
Access is really not bad for what it is. I think it's actually underrated among tech people. I'd take it over MySQL in many situations.
The only problem with it is that it's slow. It's REALLY slow.
Re: (Score:3, Funny)
Mod parent tragically informative.
Ah, the anti-groupthink groupthink... (Score:2)
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,
Re: (Score:2)
Actually, Facebook runs on C++ [guardian.co.uk] these days. Turns out that it is actually PHP that does not scale. ;)
Re: (Score:2)
As the source language is actually PHP, I'm going to say that the fact that it compiles to C++ is about as relevant as the fact that the PHP interpreter itself was likely written in C.
The point stands -- get as big as Facebook, and you could be doing the same thing to Ruby code.
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.
HTTP methods (Score:3, Interesting)
Re: (Score:3, Informative)
Not true. From the CouchDB docs:
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, typic
Re: (Score:2)
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 gener
Re: (Score:2)
PUT and POST don't map perfectly to Create and Update.
PUT should be used (per the HTTP spec) where the URI to which the PUT is conducted will be the URI of the resource provided. Clearly, this can make sense for either creates or updates in certain cases (creates wh
Re: (Score:2, Informative)
Yes, Django does have testing support, and Django itself is quite well tested - so I agree with you. The point I was trying to make is just that testing wasn't really a priority amoungst developers in the way it is in the Rails world. Things may have changed now.
As for talking about professionalism, it's more just a case of being fustrated by developers not testing their code - and it happens in all languages (and I do it sometimes too). It's just less common a problem in Ruby/Rails in my experience.
Re: (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: (Score:3, Insightful)
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
Re: (Score:3, Informative)
Re: (Score:2)
Okay, here is a common idiom in virtually every Rails project. Please show me how comments can improve the understandability of the following code:
Another common pattern is:
Again, I would love to see how comments can improve the code. I'm not saying that comments are never necessary. I am saying that if you need them in your average Rails a
Re: (Score:2)
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!
Zend Framework isn't. (Score:3, Insightful)
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 layou
Re: (Score:2)
Re: (Score:2)
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
Re:I can answer a few of the objections. (Score:4, Insightful)
What is the point of writing something that tries to look sensible and objective and then round it off with the utterly subjective "Python is for masochists, Ruby is cleaner"?
The only explanation: Your subconscious knows the obvious fact that Python is a beautiful language and thus subverted your entire comment.
Re: (Score:2)
What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those.
Thus spake Wikipedia:
And everything old is new again.
Re: (Score:2)
``(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.''
Common Lisp. There are several compilers for it that actually make it efficient. I've even seen Lisp programs beat C, C++, and Java.
Current Ruby implementations are dog slow even by dynamic language standards, but let's not forget that it's easy to interface to C from Ruby. You can alternate hard and soft layers [c2.com] and get _both_ rapid development and fast software.
``(3
Re: (Score:2)