Hello guys I have this video tutorial on Ruby on Rails and I see that the guy has a bottom script debug, in the browser window. The problem is, I have only one part of that video tutorial (that part is free) and he says nothing about that debug. Maybe you guys can figure it out.
Here's a screenshot with it: http://i55.tinypic.com/3537drp.png
How can I achieve that? Thanks.
In the view, doing something like
<%= debug params %>
will achieve what you have shown. Using the debug helper you can basically get a yaml dump of any variable that's available to the view, it will also "prettyfy" the dump by formatting it in a <pre> block and using a different background color. From the looks of what he has, he might have added that to the bottom of a layout (might be in app/views/layouts/application.html.erb). That will give you that dump in any of your pages.
The Rails Footnotes gem is very easy to configure and includes information like:
variable assignments
params action / controller
route information
SQL statements & execution times
Check it out:
https://github.com/josevalim/rails-footnotes
Looks like he's just rendering params.to_yaml onto the page.
you should maybe consider running rails with the --debugger flag as exemplified in this guide:
http://guides.rubyonrails.org/debugging_rails_applications.html
for debugging the view you can simply <% debugger %> in your view page wherever your want to see the dataflow and load that view again and on the console you can run each line of view and see the data flow.. and make sure you have debugger gem in your gem file.
Related
There is a rails application that uses bunch of gems one of which is ActiveAdmin.
Dashboard works OK, but other custom tabs gets a 500 response.
How do I enabled debugging/logging inside ActiveAdmin gem to get to the bottom of this problem?
Corresponding generic question is this: what are the ways to enable debugging on rails apps with multiple gem dependencies?
1) Check your development.log file after hitting the custom tab page and see where the error was. The log should give you a stack trace or at least tell you the last controller that was hit. You can use this information to work backwards and find out where you code is breaking.
2) Once you have found the broken spot in the code you can use raise or pry debugger to inspect variables/methods to help you debug.
This turned out to be a version mismatch between the mongoid interface and the active admin interface.Thanks for all the help.
I'm new to ROR and I"m having trouble with all the text that rails spits to the terminal window. Primarily, the html from my web pages get repeated in the terminal window and I'm really just wanting to see the important stuff like sql queries and error messages. I'm wasting a lot of time scrolling throughout the terminal window trying to find what I need b/c of all the HTML that fills up the screen.
Is there an option to disable the 'source of your encoding' output?
Thanks.
You could raise your log level
The rails guide gives a good example
http://guides.rubyonrails.org/debugging_rails_applications.html#log-levels
Make sure if you are in development to change it in config/environments/development.rb
I don't know if this will really solve your problem though because I am unsure of exactly what output you are looking for. A higher log level may throw out the baby with the bathwater.
I was wondering how to exit a controller in rails and get the output up to that point.
In PHP I often used the "exit" when debugging to get only the data processed to that point. I haven't found a sollution to this in rails.
If you get a error further down in the code the view is locked from displaying <%= debug %> information.
Some would suggest console or rescue, and I know about these. But isn't there a simpler solution?
In development mode, I often just use puts or awesome_print to print something to the screen that I ran rails server from. That works pretty well for the simple cases.
For anything more complex than that, I use ruby-debug or pry to drop down into an interactive console when it hits the right point.
I have some editor shortcuts to print one of these two snippets:
require 'pry'; binding.pry
require 'ruby-debug'; debugger
Drop these in your code and you can use IRB to inspect (and manipulate) the state of your program.
I highly recommend you give pry a shot. Check it out here:
http://pryrepl.org/
http://railscasts.com/episodes/280-pry-with-rails
There is also the older ruby-debug:
http://railscasts.com/episodes/54-debugging-with-ruby-debug
Please can you share your approach / methodology to debugging in Ruby / Rails.
I'm busy with the Rails tutorial, and am getting the error:
NoMethodError in UsersController#show
undefined method `microposts' for #<User:0x83b43e8>
And that got me thinking about debugging strategies. Does anyone have advice for a new Rails user (and new MVC user) on strategies to approach debugging. What path do you follow? Is there a generally accepted approach? Is there a way to step through the code?
Right now I am using unit testing as a kind of "lint" checker, but that only goes so far.
Although I want to solve it, the actual error I am getting right now is not the main thrust of this question.
(PS: The problem is not a duplicated "show" as documented in elsewhere on Stackoverflow
I haven't seen this mentioned yet but another option is to put a debugger statement in your code. Like this
def some_method
something = 3
debugger
# ... more code
end
If this is in a rails app when the code reaches debugger it will cause the terminal window running the web server to jump into something that looks like an irb session (I'm not exactly sure what it is). From there you can do puts something to see what the value is for example. You can even puts params to see what all the params values are. You can also step through the code, jump to a specific line, etc.
Pry seems to be a better way to go about this but it's how I used to debug before I knew about pry.
Note: You might need to do require 'ruby-debug' if you're doing this outside of rails.
i use a combination of irb, print statements, logging and pry bindings. (pry is a great gem)
irb is a great way to just play around with your ruby or rails app in the console. You could just enter the code from your controller (or similar) and see if it breaks in console for faster feedback loop. But remember you have to do reload! if you change anything in your class/module.
print statements are easy if you're running tests and just want it to output something a different points in your test. But if your testing in a browser I would recommend writing to the logger: Rails.logger.debug "...". But remember to set your logging level in your configuration to DEBUG -or- you can just do Rails.logger.info instead which should show up by default. Then you can just tail or view the logs in my_app/logs/development.rb.
My favorite method for really tricky bugs is that if the error is happening in a test you can just place binding.pry in the preceding line and then it will pause your test at that line and drop you into a console. I recommend watching the rails casts for more in-depth info: http://railscasts.com/episodes/280-pry-with-rails
I do not start Rails project without 'pry' gem.
Add gem to Genfile:
group :development, :test do
gem 'pry'
end
and stop request execution anywhere in your project, just put
binding.pry
to your model, controller, tests ..., or
<% binding.pry %>
in your view's, templates, partials.
Then you can check what ever you want objects, params, variables ...
Type exit to leave pry environment, and request will continue.
The Ruby on Rails Guide would be a great place to start, but there's plenty more.
I always have a rails console session or at minimum an irb session to play with to see if things do what I think they do.
I also use RubyMine which has an excellent integrated debugger http://www.jetbrains.com/ruby/
Beside pry gem, another option would be byebug. This gem enables you to temporarily stop code execution at a breakpoint, which is marked with keyword byebug inside the code. When execution reaches the breakpoint, a marker will be pointing to the current line, and you are able to type in commands.
This Gem offers a huge set of commands, the most commonly used ones are:
next - this command enables you to go to next line
step - goes into each invoked method step by step
break - it stops the execution of code
continue - continues code execution
This is a great article to check for debugging in rails.
I'm trying various ways to implement pretty graphs in my app. I followed http://pullmonkey.com/projects/open_flash_chart2 steps in my app, but instead of creating test_it, I just added to my own controller. In my routes.rb, I have
resources :my_controller_name do
collection do
get 'graph_code'
end
end
also, since I don't think it could find the action my_controller_name/graph_code otherwise (I'm kind of confused as to why most tutorials leave the routes part out? Am I doing something wrong?). (I also used #graph.html_safe in my views for Rails 3)
Anyway when I go to /my_controller_name, I get the error in the flash box:
Open Flash Chart
JSON Parse Error [Syntax Error]
Error at character 0, line 1:
0: #<OpenFlashChart::OpenFlashChart:0x000001043c4b78
I don't know why this is happening. I tried creating a new app and following the guide, generating a controller named test_it. It worked (provided I corrected the routing). I can't think of how my controller is any different than test_it, except I initially generated it using a rails scaffold (so it has all the MVC parts), whereas I only generated the test_it controller. (I've also tried using/not using the json gem conflict fix, but it didn't make a difference--https://github.com/klochner/open_flash_chart/commit/00cf531387880af8c49ed5118737f0492b437f75) Thanks for any insight, I'm stumped as to why it's easy to implement on a new app but I can't add it to mine...
Thanks.
Nevermind, it seems to work if I use the old lib/base.rb instead of the json gem fix. Ah well.
Don't waste your time with Flash based charting libraries. Highcharts is definitely the way go to. It works in pretty much any browser, including those that don't support Flash. Much better performance on OS X than Flash will ever provide.