When Rails Fails(zef.me)
zef.me
When Rails Fails
http://zef.me/2308/when-rails-fails
36 comments
As a non-ruby dev, it isn't obvious to me that I should grep 'Homme' instead of 'HommeController' ...
A statically typed language with a good IDE (yes, like Java) will find almost all these errors for you as you type (excepting config files, like you said).
A statically typed language with a good IDE (yes, like Java) will find almost all these errors for you as you type (excepting config files, like you said).
I do Java at the day job. If we hired you as a new employee, and in the course of cutting your teeth on our Java framework you made those errors, I think Eclipse would have caught exactly one of them.
Routes.rb errors 1 and 2: sorry, this is either handled in a configuration file or the database, which is loaded from an XLS file in our framework. None of this is checked.
Linking to non-existent pages: we don't actually have a URL generation helper, but if we did, it would be in the JSP and thus not subject to fast checking. Since in Java you'd be passing a string as a parameter rather than an automatically generated method, you'd get nothing useful here prior to actually clicking on the link and finding it didn't go anywhere.
Misspelling confirm: This would be caught in your JSP compile step prior to deploying the server, although you'd still waste a minute.
Mistyped property names: OH GOD do I hate this one. You'll get as far as any page done by that action without error. Then the action gets loaded and the fun begins. Typically you'll get an error telling you that a form is not defined , which is your cue that says "Check the contents of the annotations for this action, something is borked", but if you don't know that symptom or (worse) if you borked something in one of the fields where the page can still load, you'd either waste a lot of time or miss the bug entirely. (For example, in our system, one way of causing this bug would leave "name" totally unchecked but let the form submission succeed for good input. Since many of our outsourcers don't bother testing with bad input...)
Misspelled formats: We don't even have this feature. (P.S. I don't know why Rails books and tutorials always emphasize this so much, since most people don't need it. I always just delete that code from my own Rails methods.)
Botching the key to a parameters access: Since the key is a string and there is no way to tell whether Map#contains("arbitrary string") at compile time, you'll get as far as execution before seeing any error here. It will probably be a NullPointerException.
Routes.rb errors 1 and 2: sorry, this is either handled in a configuration file or the database, which is loaded from an XLS file in our framework. None of this is checked.
Linking to non-existent pages: we don't actually have a URL generation helper, but if we did, it would be in the JSP and thus not subject to fast checking. Since in Java you'd be passing a string as a parameter rather than an automatically generated method, you'd get nothing useful here prior to actually clicking on the link and finding it didn't go anywhere.
Misspelling confirm: This would be caught in your JSP compile step prior to deploying the server, although you'd still waste a minute.
Mistyped property names: OH GOD do I hate this one. You'll get as far as any page done by that action without error. Then the action gets loaded and the fun begins. Typically you'll get an error telling you that a form is not defined , which is your cue that says "Check the contents of the annotations for this action, something is borked", but if you don't know that symptom or (worse) if you borked something in one of the fields where the page can still load, you'd either waste a lot of time or miss the bug entirely. (For example, in our system, one way of causing this bug would leave "name" totally unchecked but let the form submission succeed for good input. Since many of our outsourcers don't bother testing with bad input...)
Misspelled formats: We don't even have this feature. (P.S. I don't know why Rails books and tutorials always emphasize this so much, since most people don't need it. I always just delete that code from my own Rails methods.)
Botching the key to a parameters access: Since the key is a string and there is no way to tell whether Map#contains("arbitrary string") at compile time, you'll get as far as execution before seeing any error here. It will probably be a NullPointerException.
It's a religious thing. Writing actions that make sense both with XML output and with HTML output tends to force you to write REST-y web-service-y interfaces. I delete the code too, but I feel guilty for doing it.
If you're not a Ruby/Rails dev, it doesn't seem reasonable to expect that all the framework's errors will make sense to you. If you took the time to learn how requests are routed in an MVC framework, this particular error would probably make perfect sense to you.
I've found RubyMine to do a pretty good job with "red squiggly things". Its an IDE (yes, like Java) but for Ruby. A dynamic language. Static typing isn't a necessity for a good IDE, just look at Smalltalk.
As another data point, a few of my coworkers claim Netbeans is a reasonably good Rails IDE.
[deleted]
Poor attention to detail is going to bite you in the ass as a programmer no matter what technology you're using.
Good article that raises interesting points. I would also be interested in knowing what happens to experienced programmers using Rails - do they simply become used to the poor error messages (so this is just a ramp-up problem) or are you always stuck with making sure everything is without typos etc?
Without conceding that these are poor error messages --- most of them are pretty direct, and the one that confused him the most actually gave him a step-by-step for diagnosing the problem --- I do think that addressing this post point-by-point would be another opportunity for Rails to charm web developers.
Note that very, very few software development frameworks "gracefully" handle the typo problem.
Note that very, very few software development frameworks "gracefully" handle the typo problem.
They strike me as fairly poor, while not catastrophically so. The fact that such messages are typical doesn't make them not-poor.
They're not, though, something constrained to Rails and I'm not sure a Rails-specific rebuttal would help all that much - the difficulty is fundamental when the language and abstractions of expression are different from and essentially unknown to the system that's actually doing the runtime error checking. Another commenter spoke of the infamous JSP stack traces. Googling 'clojure error messages' brought up a thread on this as an error message:
They're not, though, something constrained to Rails and I'm not sure a Rails-specific rebuttal would help all that much - the difficulty is fundamental when the language and abstractions of expression are different from and essentially unknown to the system that's actually doing the runtime error checking. Another commenter spoke of the infamous JSP stack traces. Googling 'clojure error messages' brought up a thread on this as an error message:
(ns foo.bar.baz
(use clojure.contrib.core :only seqable?))
#<CompilerException java.lang.IllegalArgumentException: Don't know how to create ISeq from: Boolean (NO_SOURCE_FILE:0)>It's worse in Ruby though, because the "use maps for optional parameters" approach means you have to manually check for invalid keys in the map, whereas the same approach in a language that supports native named parameters would throw an exception about the invalid parameter. Several of the errors in this article would be caught by this.
True, but Ruby also allows for the Rails DSL to be fairly concise. If you assume a constant number of typos per typed word, the author would have made more errors in a more verbose language even if it had named params :)
[deleted]
Rails does this many places already. It seems he probably just stumbled into one of the few cases where the flexibility is needed and therefore the parameters aren't easily checkable.
I don't think it was a good idea to write this article. Some of these messages could reasonably be improved, and some couldn't, but regardless of the merit of each individual complaint when I read someone listing out the result of a half dozen common typos along with a description of how bad these extremely common error messages are, I can't help but immediately judge the author to be one of those NNPP's who spends days tripping over ridiculously simple issues because they never really grokked how to debug in the general sense. I'm not claiming the author is an NNPP, I'm just saying when you get hung up on the basics like this that's the impression that is conveyed.
Summary: Rails has a learning curve. If you're a newbie, you will get confused.
None of these errors are confusing once you've been using Rails for a couple of weeks.
None of these errors are confusing once you've been using Rails for a couple of weeks.
Maybe. I found routing errors to be massively useless until I spent way too much time finding out just what was expected to make things work.
Rails seems to favor the approach of first reading many docs and tutorials, then working your way through a series of examples, and always doing things Just So. It's not so friendly if you decide to wing it and try things because your gut says it might just work.
The funny thing is, one of the things I like about Ruby is that it works just the opposite; it's quite easy to jump in and guess at what to before reading much documentation. You'll often be right, or you'll (mostly) figure it out pretty fast.
Rails seems to favor the approach of first reading many docs and tutorials, then working your way through a series of examples, and always doing things Just So. It's not so friendly if you decide to wing it and try things because your gut says it might just work.
The funny thing is, one of the things I like about Ruby is that it works just the opposite; it's quite easy to jump in and guess at what to before reading much documentation. You'll often be right, or you'll (mostly) figure it out pretty fast.
I think that is the point of the article. The errors are confusing to a newbie - 1 day old
Those all look like perfectly legitimate, thorough error messages to me, far moreso than many languages would give you. Would it be confusing to a newbie? Maybe, but they're called newbies for a reason. Pay attention to details + write tests + take the time to learn the framework = problem solved.
Uh, not really. Anyone new to a framework should just stop learning at the first sign of frustration and write a blog post criticizing the framework.
I recently began working with Ruby on Rails after years in ASP.Net and I still have to refer to the API, Guides, and documentation so I consider myself an amateur. I'm having to get used to programming "better" since I no longer have the assistance of a compiler to catch these type of errors.
As you probably know, Rails is about convention over configuration. This increases the initial learning curve but speeds up development once you understand the conventions. I read Agile Web Development with Rails and was able to make it over the initial hump of "what..why is this capitalized and this plural and the singular" stage.
As you probably know, Rails is about convention over configuration. This increases the initial learning curve but speeds up development once you understand the conventions. I read Agile Web Development with Rails and was able to make it over the initial hump of "what..why is this capitalized and this plural and the singular" stage.
The bigger problem you're facing is that ASP.NET has been forcing you to use the, shotgun-in-mouth worthy, event driven model (I've done .net web dev).
The rest of the universe has been using MVC for five or 6 years to do web development. Praise be to Microsoft for figuring it out.
The rest of the universe has been using MVC for five or 6 years to do web development. Praise be to Microsoft for figuring it out.
as a beginner, things like scaffolds and other generated code pretty much completely eliminate these typo driven mistakes, they also make great starting points for understanding the framework. so that mitigates the problems mentioned for beginners, and by the time you are not a beginner hopefully those error messages make more sense. Personally, i found most of those error messages pretty good. im currently using spring/hibernate as well as RoR very heavily, and trust me i pull my hair out way more on the spring/hibernate side than the RoR side, come to think of it, i pull my hair out exclusively on the java side =)
The Rails backlash sometimes seems bigger then the hype ever was, and is cloying (so savvy, so de riguer). But this article is not one of those (you might think so from its title). The error messages really could use some TLC.
The error messages could use some love, but the article is crap. He didn't break Rails in any predictable ways. Who breaks stuff accidentally by misspelling things? Spellcheck can be turned on just about everywhere in any modern IDE or Editor.
> Who breaks stuff accidentally by misspelling things?
Wasn't there just another thread about '=' vs. '==' last week?
Wasn't there just another thread about '=' vs. '==' last week?
Friend, what you need is a compiled imperative language with verbose type declarations. Java comes to mind.
Rails works by following conventions that feed metaprogramming and method_missing magic, and the kind of safety net which the author seems to imply is missing will just never be available in that sort of system.
I find little errors like these totally worth it because of the time I save by using rails, and after the first couple of weeks (as many have already posted) most of these are non-issues.
Rails works by following conventions that feed metaprogramming and method_missing magic, and the kind of safety net which the author seems to imply is missing will just never be available in that sort of system.
I find little errors like these totally worth it because of the time I save by using rails, and after the first couple of weeks (as many have already posted) most of these are non-issues.
Rails uses Ruby's metaprogramming capabilities extensively, and those capabilities are one of the reasons people choose Ruby, as well as the very thing that makes it possible for Rails to work the way that it does. This is, at least in part, why your code doesn't seem to be on the call stack. My question is, do other language environments do better at exception analysis when metaprogramming is used in this way?
My response to your criticism: http://zef.me/2355/a-when-rails-fails-follow-up
[deleted]
gem install ruby-debug
He's right, rails doesn't improve speling.
Ruby is an interpreted language and can't feasibly do the red squiggle thingee, but the common errors are trivially debuggable after a few hours experience with the framework. If you see an error message talking about HommeController, you search for homme globally, find the one instance of it, fix the spelling and reload the page you were just seeing. Bam, that took you three seconds.