This post originated from an RSS feed registered with Ruby Buzz
by David Heinemeier Hansson.
Original Post: Transparent internals in web-applications
Feed Title: Loud Thinking
Feed URL: http://feeds.feedburner.com/LoudThinking
Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp
Dmitry V. Sabanin recently announced his PrettyException project on ruby-talk. It's an attempt to turn web-app box from black to white by making the internals more transparent. About his own usage, he said:
I find it very useful when you develop something for Web and you don't have access to apache logs. For myself, I'm using PrettyException when I develop a web site, and when it's time to release it, i turn PrettyException off.
This is indeed a critical component of any web-application framework. How easy is it to spot an error, how much information are you supplied to locate it, and how much time does the fix-test cycle take.
Rails is extremely focused on providing a grade-A handle at all three crisis points. Here's a snapshot of the old version of how exception handling in templates was done in Rails.
In the current version, it's also tracking the nesting of templates (so when an error occurs in an included template, you can see how included it up the chain). The template parameter dumps are also made much more readable by using YAML to do pretty printing.
More importantly, though, is that Rails acts intelligently in the face of stackdumps and collection inspections. I always found it so funny to read a dump from Tomcat. 120 lines of framework internals exposed to the unwitting spectator. Totally oblivious as what to look for.
So as far as it's possible, Rails will determine what's relevant in a stacktrace (the lines from your own app) and in a collection dump (the variables you assigned) and then deemphasize the rest.
Of course, these details views inside the internals of a Rails application are only exposed to requests deemed "local". Everyone else will automatically be routed to a public error page.
The cool thing about having this distinction in code is that you can keep it in a production system. So when you need to debug something on a live system, you'll have a condition present that triggers the local condition for the developer (like a fixed IP), so he'll get the full story when he needs to investigate real-world bugs.
And in the real world is where he's likely to need the information the most. It's where all those odd inputs he never thought about are popping up. And without a looking glass, it's all too easy to just rip out your hear in frustration over "this shouldn't be happening!". When the internals are transparent, the solution is often obvious.
Previous Topic
