Comments on: When Rails Fails

By: Models are Programs « I am Zef

Models are Programs « I am Zef — Mon, 30 Nov 2009 10:12:20 +0000

[...] patterns and was able to capture them in a little library we like to call Ruby on Rails, and sure, it’s not perfect, but it seems to dramatically improve developers’ productivity. Is Rails a new idea, though? [...]

By: Lenary

Lenary — Tue, 24 Nov 2009 02:47:27 +0000

Jesse, it remains that you should test everything that is 'game-breaking'. If a peice of javascript is a 'game-breaker', write some Behaviour Tests that run in something like selenium so that can simulate and test the javascript correctly.

If you are only relying on doing a once-through of the app for your testing, especially for 'game-breaking' logic and behaviour, you only have yourself to blame. There are many good and viable BDD tools avaliable, as well as normal TDD. (I'm not sure if conventional TDD will cover this particular behaviour)

I am almost 100% sure there will be tutorials online for getting selenium setup, or you can find help on stackoverflow.com or irc as you see fit.

By: pradkris

pradkris — Wed, 18 Nov 2009 02:23:13 +0000

Thanks for your valuable comments. I personally feel the author is explaining about improving error messages and not trying to reach the community for help. I mean trying to debug a typo should not take a longer time like posting on SO, etc. Also in a team setup or a large scale system you might sometimes wonder if there is actually a class with name homme.. This is jus my humble opinion.

By: pradkris

pradkris — Wed, 18 Nov 2009 01:23:13 +0000

By: When Scala DSLs Fail « I am Zef

When Scala DSLs Fail « I am Zef — Tue, 17 Nov 2009 11:16:59 +0000

[...] in its XML-based language for constructing user interfaces. I won’t milk this one too much, we know the trick by now, but let me demonstrate what happens when a programmer makes mistakes in [...]

By: Framework Failures for Beginners | Thought Clusters

Framework Failures for Beginners | Thought Clusters — Tue, 17 Nov 2009 11:04:00 +0000

[...] Hemel writes about the inscrutable error messages that he gets when making typos in Ruby on Rails, Scala and JBoss Seam. I recently saw a new programmer struggle with the RoR errors and I have been [...]

By: The Third Bit » Blog Archive » Bend It ‘Til It Breaks

The Third Bit » Blog Archive » Bend It ‘Til It Breaks — Mon, 16 Nov 2009 14:18:21 +0000

[...] It’s not the only approach, but it’s the one Zef Hemel took with Ruby on Rails. In his original post, he took a critical look at how helpful Rails is when a developer mistypes something. A lot of [...]

By: Static Verification: An External DSL Advantage « I am Zef

Static Verification: An External DSL Advantage « I am Zef — Mon, 16 Nov 2009 11:17:24 +0000

[...] through the use of meta programming facilities, looks a lot like a domain-specific language. I looked at Ruby on Rails as a prime example of an internal DSL built on a dynamic language, at JBoss Seam as a framework [...]

By: Jesse Dailey

Jesse Dailey — Thu, 12 Nov 2009 21:52:21 +0000

Engineering explanations aside, the fact remains that #4 is a game-breaking, absolutely should never happen, serious flaw in a web application. To dismiss it as 'you should notice', is like saying, if you want to code with Rails, 'hire more testers'.

By: Geraldo

Geraldo — Thu, 12 Nov 2009 21:41:20 +0000

Ryan Bigg don't worry. Your advice is going to be useful coz the site is indexed.
One sign that rails got there is the amount of bashing it gets.

By: jgodse

jgodse — Thu, 12 Nov 2009 20:18:29 +0000

Let's see.

1) When you used "homme", it was an unknown symbol. Same as making a typo in C. Granted, in Rails, you have to know that "HommeController" is the Ruby class associated with "homme". However, it is not vastly different from figuring out name mangling when you debug a C++ linking problem.
2) Because Ruby is interpreted, the interpreter cannot say if a symbol should not be there. :controler may be a valid symbol. This program failed because a required symbol :controller was not defined.
3) I agree with you on this one.
4) Because Rails is interpreted, it cannot say if :confrm is required. Furthermore, I don't think that HTML requires the "confirm" attribute, so the Ruby wrapper cannot require it either. If you were coding straight HTML, you would have the same problem.
5) This is a huge problem in Rails. The underlying issue is that ActiveRecord is actually only partially coupled to the underlying data model. (This is good because it allows easier interfacing with legacy data schemas). That is why you have to write migrations separately and keep them in sync with the attributes in ActiveRecord. Keeping knowledge of the data schema in two places is a bit of a kludge, but I'm not sure how to fix it without forcing all data definitions to reside in one place such as ActiveRecord.
6) This is not a huge problem. Although Rails is flexible in which MIME types it supports, it should generate some kind of warning if the format is not well-known (such as html, xml, json, text). The lower-case uppercase thing is there for visual "beauty" I think, but it throws off people trying to parse error messages.
7) Rails is pretty powerful when it comes to naming conventions. However, I find it confusing when one is able to create objects by passing params[:post] and not even knowing what was passed in. Also, if you try to include other parameters on your form, it is hard to get them in using the Rails naming convention, and you are effectively back to coding raw HTML forms. I find that doing a "view source" on the form page will quickly tell me what Rails generated as parameter names.

Rails is very powerful, but in some places the abstractions leak and you need to know how it works under the hood. Overall, I find that Rails abstractions and "convention over configuration" let me get a system up & running quickly. When I was working with Perl/CGI, I had to understand raw HTML forms, and when I was with ASP.Net, I had to learn that framework (which IMHO is much more cryptic than Rails or Perl/CGI).

By: luigimontanez

luigimontanez — Thu, 12 Nov 2009 19:09:34 +0000

Ryan, thanks for taking the time to craft a well-explained, reasonable response. Nice job.

By: voidspace

voidspace — Thu, 12 Nov 2009 18:52:10 +0000

My goodness, the Rails crowd doesn't like any criticism does it. :-)

Nice post. Any framework developer should consider error handling part of the API.

By: none

none — Thu, 12 Nov 2009 17:31:36 +0000

lol

you are a pathetic loser to even waste your time to write such a post. very funny! that really made my day.

and good luck with webdsl.

By: pk

pk — Thu, 12 Nov 2009 14:17:58 +0000

Hi Zoltan,

This is so true. I did couple of web projects and when started with third one was frustrated so much rework needs to be done. Rails solves these problems. When you have done some website you know typical things needed and RoR provides them out of factory. You don't need to reinvent the wheel.

Price of using such framework always comes at cost you don't understand all the code that goes into framework. This is true with any kind of framework be it RoR, DJango or PHP MVC. As long as you know how to fix issues with framework or can find answers to them on a well supported forum using a framework should not be issue at all. RoR is one of the best community supported frameworks I have come across.

PK
http://roorky.com
Interactive Programming Books

By: Giles Bowkett

Giles Bowkett — Thu, 12 Nov 2009 12:42:58 +0000

Wrong. It's not the framework's job to do anything. Rails isn't for lazy people. If you want an error-checking system, you build one.

That would be a ridiculously easy Rails plugin. Just use the ruby2ruby library and grep it.

By: Zef Hemel

Zef Hemel — Thu, 12 Nov 2009 11:34:23 +0000

For all those offering their help and tips on how to debug Rails programs, I thank you. However, I'm not a struggling Rails developer. I look at Rails because we are developing a Rails competitor called WebDSL (http://www.webdsl.org). One problem that we try to solve is the lack of static analysis that many frameworks, like Rails, have. To point out that this indeed a problem, I'm writing a series of posts like this one.

By: When JBoss Seam Fails « I am Zef

When JBoss Seam Fails « I am Zef — Thu, 12 Nov 2009 10:51:40 +0000

[...] I wrote about Ruby on Rails and what happens when programmers make common (typing) mistakes in their programs. It seems to have [...]

By: Edward Ocampo-Gooding

Edward Ocampo-Gooding — Thu, 12 Nov 2009 10:27:45 +0000

Hi Zef,

I agree with your sentiment – watching beginners work with Rails make typos and become unaware of how/when they made a mistake can be frustrating.

What often happens is that beginners learn to recognize these fairly opaque errors and later dig a little deeper to realize what’s actually going on, along with picking up other web development debugging techniques like Firefox’s Firebug, or Safari’s Inspector where you can look at the requests and responses.

It’d sure be nice if there were better stack traces and more transparent errors. Do you have some ideas about how you’d patch things or redesign the various DSLs Rails uses to accommodate newer web developers apart from static analysis?

By: dasil003

dasil003 — Thu, 12 Nov 2009 09:20:53 +0000

This is so true. It all started with the infamous 15 minute blog video from DHH back in '04. That pretty much guaranteed that for the rest of time the uninitiated would think of Rails as a super-easy toy framework for programming lightweights.

But the reality is that Rails is hardcore Ruby–some of it very ill-advised Ruby for any project less ubiquitous than Rails–and it's written for serious web programmers. Unlike say PHP where you can muddle through a lot of applications without much training, writing any non-trivial app in Rails is going to through some curveballs your way. If you're not willing to roll up your sleeves and learn the finer points of Ruby meta-programming then all your productivity gains in Rails are going to be nullified the first time you see a weird error message (which happens frequently, especially before you are familiar with the language).