1366 0 true 2008-09-04T14:46:12+01:00 1366 2008-10-13T00:00:00+01:00 20253 5 how-to-debug-a-rails-application 5 16213 resolved 2008-11-03T17:09:03+00:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 * ruby-debug * debugger options * How to analyze stack trace * Form helpers for debugging etc. * ruby-debug * debugger options * How to analyze stack trace * Form helpers for debugging etc. <div><ul> <li>ruby-debug</li> <li>debugger options</li> <li>How to analyze stack trace</li> <li>Form helpers for debugging etc.</li> </ul></div> 1366 0 * ruby-debug * debugger options * How to analyze stack trace * View helpers for debugging etc. <div><ul> <li>ruby-debug</li> <li>debugger options</li> <li>How to analyze stack trace</li> <li>View helpers for debugging etc.</li> </ul></div> false 2008-09-04T19:12:05+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-04T19:12:05+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 "Form helpers for debugging"? Did you mean "view helpers"? <div><p>"Form helpers for debugging"? Did you mean "view helpers"?</p></div> false 2008-09-04T17:27:00+01:00 1366 --- {} 5 how-to-debug-a-rails-application-2 0 16213 new 2008-09-04T17:27:00+01:00 192 Mislav Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 Sorry, yeah. Fixed. <div><p>Sorry, yeah. Fixed.</p></div> false 2008-09-04T19:11:56+01:00 1366 --- {} 5 how-to-debug-a-rails-application-3 0 16213 new 2008-09-04T19:11:56+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 I have started working on this guide. Cheers <div><p>I have started working on this guide.</p> <p>Cheers</p></div> false 2008-09-04T19:22:57+01:00 1366 --- {} 5 how-to-debug-a-rails-application-4 0 16213 new 2008-09-04T19:22:57+01:00 16138 Emilio Tagua Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 Hey miloops, * I'd lose the history section * Before ruby-debug I'd describe what logs are and how to add stuff to logger (logger.debug/info...) * Also before ruby-debug I would cover view helpers * Why is non-ruby code highlighted as ruby? * You're using "NOTE" admonition where "TIP" is more appropriate * You're using single-char shortcuts in ruby-debug shell; full commands should be used for clarity * "Editing" chapter is unclear: what is "line specification"? What is "frame"? Regarding the example in "step by step" @@@ ruby def find_recent_comments(limit = 10) debugger @recent_comments ||= comments.find( :all, :conditions => ["created_at > ?", 1.week.ago], :limit => limit ) end @@@ Maybe it's best to stick with one-line expressions for the sake of demonstration? Also, this method shows wrong practice to programmers because the above logic is much better achieved with a named_scope. So, my proposal for the outline (titles are just for the rough idea): * 1. "Something went wrong". Present the readers with a hypothetical situation they all experienced: Something on the page is not as it should be, but just by viewing the page and its source doesn't reveal the cause of the problem. * 2. "View helpers for debugging". That would be only the "debug" method and "local_assigns.has_key?(:foo)" in templates (most useful in partials). * 3. "Inspecting the application log" (covers logger methods) * 4. "Debugging with ruby-debug" <div><p>Hey miloops,</p> <ul> <li>I'd lose the history section</li> <li>Before ruby-debug I'd describe what logs are and how to add stuff to logger (logger.debug/info...)</li> <li>Also before ruby-debug I would cover view helpers</li> <li>Why is non-ruby code highlighted as ruby?</li> <li>You're using "NOTE" admonition where "TIP" is more appropriate</li> <li>You're using single-char shortcuts in ruby-debug shell; full commands should be used for clarity</li> <li>"Editing" chapter is unclear: what is "line specification"? What is "frame"?</li> </ul> <p>Regarding the example in "step by step"</p> <pre><code class="ruby"> def find_recent_comments(limit = 10) debugger @recent_comments ||= comments.find( :all, :conditions =&gt; [&quot;created_at &gt; ?&quot;, 1.week.ago], :limit =&gt; limit ) end </code></pre> <p>Maybe it's best to stick with one-line expressions for the sake of demonstration? Also, this method shows wrong practice to programmers because the above logic is much better achieved with a named_scope.</p> <p>So, my proposal for the outline (titles are just for the rough idea):</p> <ul> <li> <ol> <li>"Something went wrong". Present the readers with a hypothetical situation they all experienced: Something on the page is not as it should be, but just by viewing the page and its source doesn't reveal the cause of the problem.</li> </ol> </li> <li> <ol> <li>"View helpers for debugging". That would be only the "debug" method and "local_assigns.has_key?(:foo)" in templates (most useful in partials).</li> </ol> </li> <li> <ol> <li>"Inspecting the application log" (covers logger methods)</li> </ol> </li> <li> <ol> <li>"Debugging with ruby-debug"</li> </ol> </li> </ul></div> false 2008-09-05T20:54:14+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-05T20:54:19+01:00 192 Mislav Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 * History is going away * As i explained in rails-contrib non-ruby code is using [source, shell] not [source, ruby] * Changing NOTEs for TIPs, missed that on ASCIIDocs documentation. * Will change the commands on debugger shell to use full command names. * The "Editing" episode was changed and clarified. * That example was in many lines for the sake of reading, because Mizuho will compile it in a long line with a scrollbar, and as for the content of the example named_scope may be used for that but i don't think it matter so much for what i was trying to explain, i'm willing to change it if it's that bad. I like the outline you propose for the guide, i just started with the ruby-debug and hadn't defined the order of the view helpers or the log debugging, but yours sounds good. Thank you very much for the feedback, Update coming soon! Cheers <div><ul> <li>History is going away</li> <li>As i explained in rails-contrib non-ruby code is using [source, shell] not [source, ruby]</li> <li>Changing NOTEs for TIPs, missed that on ASCIIDocs documentation.</li> <li>Will change the commands on debugger shell to use full command names.</li> <li>The "Editing" episode was changed and clarified.</li> <li>That example was in many lines for the sake of reading, because Mizuho will compile it in a long line with a scrollbar, and as for the content of the example named_scope may be used for that but i don't think it matter so much for what i was trying to explain, i'm willing to change it if it's that bad.</li> </ul> <p>I like the outline you propose for the guide, i just started with the ruby-debug and hadn't defined the order of the view helpers or the log debugging, but yours sounds good.</p> <p>Thank you very much for the feedback,</p> <p>Update coming soon!</p> <p>Cheers</p></div> false 2008-09-05T21:36:13+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-05T21:36:18+01:00 16138 Emilio Tagua Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 A few comments/suggestions: * Start with a "This guide covers xxx. By referring to this guide, you will be able to:" list - as I did in the Routing guide. I'd like to see us do this sort of standard intro across all the guides; it really helps readers figure out whether a particular chunk is something they should read. * In the example for #inspect, there's a discrepancy between the code you show and the output. * Should probably include a few words on how to get & install ruby-debug. * I would probably move the thread commands down towards the end of the ruby-debug section; I think in most cases Rails developers won't need them at the moment. <div><p>A few comments/suggestions:</p> <ul> <li>Start with a "This guide covers xxx. By referring to this guide, you will be able to:" list - as I did in the Routing guide. I'd like to see us do this sort of standard intro across all the guides; it really helps readers figure out whether a particular chunk is something they should read.</li> <li>In the example for #inspect, there's a discrepancy between the code you show and the output.</li> <li>Should probably include a few words on how to get &amp; install ruby-debug.</li> <li>I would probably move the thread commands down towards the end of the ruby-debug section; I think in most cases Rails developers won't need them at the moment.</li> </ul></div> false 2008-09-06T02:13:06+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-06T02:13:09+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 I think keeping 'threads' section is ok, considering Rails is threadsafe now. Agree with everything else Mike said. Also, local_assigns stuff is not really relevant to debugging. <div><p>I think keeping 'threads' section is ok, considering Rails is threadsafe now. Agree with everything else Mike said. Also, local_assigns stuff is not really relevant to debugging.</p></div> false 2008-09-06T03:07:14+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-06T03:07:15+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 The guide was updated: * Added Logger chapter. * Fixed #inspect example (oops!). * Added a short section on how to get ruby-debug. * The guide intro was change in favor of Mike's suggestion, i think it's great to have a standard way too. * I didn't change the thread section because of the reason it was created: Rails becoming threadsafe. * A few more changes. Thanks for the feedback, Cheers <div><p>The guide was updated: * Added Logger chapter. * Fixed #inspect example (oops!). * Added a short section on how to get ruby-debug. * The guide intro was change in favor of Mike's suggestion, i think it's great to have a standard way too. * I didn't change the thread section because of the reason it was created: Rails becoming threadsafe. * A few more changes.</p> <p>Thanks for the feedback,</p> <p>Cheers</p></div> false 2008-09-08T16:16:58+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-08T16:17:02+01:00 16138 Emilio Tagua Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 More feedback on the current draft: - In general, we should avoid having two heads directly follow one another; readers tend to find this dizzying. So for example between "View Helpers for Debugging" (and we should be using title case in all headings) and "debug" you need some text that applies to the whole section. Something like "One common task is to inspect the contents of a variable. In Rails, you can do this with three methods, blah, blah, blah..." - I'd separate out to_yaml and inspect into different heads - In the Logger chatper, I'd start the "What is it?" section with "Rails makes use of ruby's standard logger to write log information. You can also substitute another logger such as Log4R if you wish" - In your tip about logging, italicize the variable part: +_environment_name_.log+ - I wonder if it's at least worth mentioning some of the log-file analysis tools and services. Things like Palmist or FiveRuns Tuneup <div><p>More feedback on the current draft:</p> <ul> <li>In general, we should avoid having two heads directly follow one another; readers tend to find this dizzying. So for example between "View Helpers for Debugging" (and we should be using title case in all headings) and "debug" you need some text that applies to the whole section. Something like "One common task is to inspect the contents of a variable. In Rails, you can do this with three methods, blah, blah, blah..."</li> <li>I'd separate out to_yaml and inspect into different heads</li> <li>In the Logger chatper, I'd start the "What is it?" section with "Rails makes use of ruby's standard logger to write log information. You can also substitute another logger such as Log4R if you wish"</li> <li>In your tip about logging, italicize the variable part: +<em>environment_name</em>.log+</li> <li>I wonder if it's at least worth mentioning some of the log-file analysis tools and services. Things like Palmist or FiveRuns Tuneup</li> </ul></div> false 2008-09-16T16:52:12+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-16T16:52:16+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 I think the log file analysis tools should go to the performance guide. <div><p>I think the log file analysis tools should go to the performance guide.</p></div> false 2008-09-16T16:55:00+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-16T16:55:03+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 Guide updated (and pushed!). Changes: * All title have title case now as Mike suggested. * Added changelog and link to the authors page to be consistent with other guides format. * Logger and view helpers section changes as Mike suggested. * Added myself to the authors page. <div><p>Guide updated (and pushed!).</p> <p>Changes:</p> <ul> <li>All title have title case now as Mike suggested.</li> <li>Added changelog and link to the authors page to be consistent with other guides format.</li> <li>Logger and view helpers section changes as Mike suggested.</li> <li>Added myself to the authors page.</li> </ul></div> false 2008-09-16T17:42:49+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-16T17:42:52+01:00 16138 Emilio Tagua Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 Just letting you know that log analysis tools are being covered in the performance guide. Though if you have done any work in that regard feel free to forward it to me. fotoverite@gmail.com <div><p>Just letting you know that log analysis tools are being covered in the performance guide. Though if you have done any work in that regard feel free to forward it to me. <a href="mailto:fotoverite@gmail.com">fotoverite@gmail.com</a></p></div> false 2008-09-17T03:07:13+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-17T03:07:17+01:00 31512 FotoVerite Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 >> 3.5. Inspecting Variables >> >> Any expression can be evaluated in the current context, just >> type it! As far as I know, this doesn't work with the default settings of rdebug, you must set autoeval either manually or in your profile. <div><blockquote> <blockquote> <p>3.5. Inspecting Variables</p> <p>Any expression can be evaluated in the current context, just type it!</p> </blockquote> </blockquote> <p>As far as I know, this doesn't work with the default settings of rdebug, you must set autoeval either manually or in your profile.</p></div> false 2008-09-20T16:53:43+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-20T16:53:48+01:00 11063 Rick DeNatale Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 Rails adds a couple of settings after initializing rdebug, "autoeval => true" being one of them. <div><p>Rails adds a couple of settings after initializing rdebug, "autoeval =&gt; true" being one of them.</p></div> false 2008-09-20T19:49:07+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-20T19:49:09+01:00 192 Mislav Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 Hey Rick, As Mislav said, Rails sets debugger to use autoeval when starting it. @@@ ruby def start_debugger begin require_library_or_gem 'ruby-debug' Debugger.start Debugger.settings[:autoeval] = true if Debugger.respond_to?(:settings) puts "=> Debugger enabled" rescue Exception puts "You need to install ruby-debug to run the server in debugging mode. With gems, use 'gem install ruby-debug'" exit end end @@@ <div><p>Hey Rick,</p> <p>As Mislav said, Rails sets debugger to use autoeval when starting it.</p> <pre><code class="ruby"> def start_debugger begin require_library_or_gem 'ruby-debug' Debugger.start Debugger.settings[:autoeval] = true if Debugger.respond_to?(:settings) puts &quot;=&gt; Debugger enabled&quot; rescue Exception puts &quot;You need to install ruby-debug to run the server in debugging mode. With gems, use 'gem install ruby-debug'&quot; exit end end </code></pre></div> false 2008-09-23T14:45:26+01:00 1366 --- {} 5 how-to-debug-a-rails-application 0 16213 new 2008-09-23T14:45:31+01:00 16138 Emilio Tagua Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 1366 0 false 2008-09-30T00:09:01+01:00 1366 --- :milestone: 20253 5 how-to-debug-a-rails-application 0 16213 new 2008-09-30T00:09:05+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 1366 0 Just committed an edit pass on this one. If anyone has more suggestions, make them soon. <div><p>Just committed an edit pass on this one. If anyone has more suggestions, make them soon.</p></div> false 2008-10-20T01:28:25+01:00 1366 --- {} 20253 5 how-to-debug-a-rails-application 0 16213 new 2008-10-20T01:28:29+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 1366 0 - Guide can include a small section on debugging memory leaks and point to bleak house and valgrind ( http://blog.evanweaver.com/articles/2008/02/05/valgrind-and-ruby ) - Maybe a sections about debugging RJS ( av::base.debug_rjs = true ) and point to resources for learning firebug <div><ul> <li> <p>Guide can include a small section on debugging memory leaks and point to bleak house and valgrind ( <a href="http://blog.evanweaver.com/articles/2008/02/05/valgrind-and-ruby">http://blog.evanweaver.com/artic...</a> )</p> </li> <li> <p>Maybe a sections about debugging RJS ( av::base.debug_rjs = true ) and point to resources for learning firebug</p> </li> </ul></div> false 2008-11-02T01:11:52+00:00 1366 --- {} 20253 5 how-to-debug-a-rails-application 0 16213 new 2008-11-02T01:11:54+00:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 1366 0 And also, it'd be nice to mention some good plugins useful for debugging. These are the ones that I like * Footnotes - http://github.com/drnic/rails-footnotes/tree/master * http://github.com/ntalbott/query_trace/tree/master * http://github.com/dan-manges/query_stats/tree/master <div><p>And also, it'd be nice to mention some good plugins useful for debugging.</p> <p>These are the ones that I like</p> <ul> <li>Footnotes - <a href="http://github.com/drnic/rails-footnotes/tree/master">http://github.com/drnic/rails-fo...</a></li> <li><a href="http://github.com/ntalbott/query_trace/tree/master">http://github.com/ntalbott/query...</a></li> <li><a href="http://github.com/dan-manges/query_stats/tree/master">http://github.com/dan-manges/que...</a></li> </ul></div> false 2008-11-02T01:22:08+00:00 1366 --- {} 20253 5 how-to-debug-a-rails-application 0 16213 new 2008-11-02T01:22:11+00:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 1366 0 Updates commited: added RJS, memory leaks and helpful plugins. <div><p>Updates commited: added RJS, memory leaks and helpful plugins.</p></div> false 2008-11-03T16:00:03+00:00 1366 --- {} 20253 5 how-to-debug-a-rails-application 0 16213 new 2008-11-03T16:00:06+00:00 16138 Emilio Tagua Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 1366 0 false 2008-11-03T16:58:27+00:00 1366 --- :state: new 20253 5 how-to-debug-a-rails-application 0 16213 taken 2008-11-03T16:58:30+00:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1 1366 0 true 2008-11-03T17:09:00+00:00 1366 --- :state: taken 20253 5 how-to-debug-a-rails-application 0 16213 resolved 2008-11-03T17:09:03+00:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/5 Guides batch 1