Hi list,
I'm sorry to come here talking about this (since I realize you have many, far better things to do, but I'd really like your feedback on an idea I have for the summer of code.
I'd like to work with the guys at Ruby Central on implementing a feature for Ruby on Rails, and since you guys are the best source of information on the subject, I'd like to ask you if you like my idea and if you think it's possible to do this during the course of three months.
I'd like to "improve debugging capabilities for Ruby on Rails" (that will be the title of my application).
Right now, debugging a Rails application isn't really as smooth as it could be. You can set up a breakpoint and start up a breakpoint client and then access the page and that sort of works. If you haven't set up a breakpoint, all you get is some information on an HTML page, which sometimes isn't all that useful. If you're debugging Ajax-based apps, sometimes you don't even get the HTML page to let you know something's gone wrong. What you'd really like to be able to do is inspect the state of the application at that point.
What I'd like to do is change what happens when you start script/ server and during its execution. Unless it's started in Daemon mode, I'd like it to support a more REPL-based style of development. By adding an option to script/server and/or the appropriate places (config/environment.rb and friends) you should get behavior like this:
1) When a sucessful request is made, the behavior remains the same as now. (the results are logged on screen) 2) When an error occurs, a page appears, similar to the 500.html page that's currently shown in production. This page will instruct the developer to check to console for additional details and a debugging session. 3) On the console, the error message that would have been displayed inside the HTML form is presented to the user. 4) He is then dropped in an Irb like environment, similar to what he'd get if he were to set up a breakpoint. At this point, the server will display an error message (something like 'Service temporarily unavailable') on any other request that is made during the time of the debugging session. 5) After inspecting the problem (and hopefuly fixing things) he could call something like 'continue', which would exit the IRB session and let the server return to its normal state. 6) Also, script/server should follow a similar behavior when meeting a breakpoint, except for the HTML page which should be different. 7) The HTML pages should give the developer useful info on where to direct his text editor (what file and line, for breakpoints, as well as errors).
Some of this has been done with ruby-debug http://blog.nanorails.com/articles/2006/07/14/a-better-rails-debugger-ruby-debug but it would be great if this were integrated so that you could get this kind of behavior each time your application hits an error. It could use ruby-debug or the standard debug.rb, since I'm not really that aware of all the details, at this point.
I believe this could be a great aid, both to application developers, and to Rails developers.
So This is what I'd like to work on, this summer. I want to know if you guys think this project is worth submitting an application for (if you'd include it somehow, in core Rails, or if you'd like to have it as a plugin or something). Mostly, I'd like to know if you like the idea
I'd also like to know if you think it's possible (and doable), or if you think three months is too much time to work on this.
I'd generally appreciate any form of feedback you guys can send my way. I'd love to work on Rails for the google SOC and I'd really like to have this kind of functionality in Rails.
Thanks.
Eugen.
