The logger

Community ES
1

Hola, me estoy mirando un link [1] que me pasaron ayer en otro hilo. Si
vais
al punto 2 de ese link, veréis que habla del logger.
Tengo dos preguntas sobre los dos primeros puntos del punto 2.

a) En el punto 2.1, el codigo que pone debajo de la linea que dice…
…"You can specify an alternative logger in your environment.rb or any
environment file:"
-¿Dónde se supone que lo tengo que poner?
-¿en que parte del enviroment.rb?

En ese punto 2.1 Da dos formas de determinar un logger diferente al que
trae
Rails de inicio
-¿Para que?
-Una vez cambiado ¿dónde puedo ver el cambio?

b) En el punto 2.2. Los logs levels, ¿para qué los podría querer
cambiar?

Un saludo

[1] Debugging Rails Applications — Ruby on Rails Guides

2

2009/1/26 Andrés gutiérrez [email protected]:

Hola, me estoy mirando un link [1] que me pasaron ayer en otro hilo. Si vais
al punto 2 de ese link, veréis que habla del logger.
Tengo dos preguntas sobre los dos primeros puntos del punto 2.

a) En el punto 2.1, el codigo que pone debajo de la linea que dice…
…“You can specify an alternative logger in your environment.rb or any
environment file:”
-¿Dónde se supone que lo tengo que poner?
-¿en que parte del enviroment.rb?

Podrías poner esto en cualquier parte del environment.rb, yo lo
pondría debajo del bloque initializer:

ActiveRecord::Base.logger = Logger.new(STDOUT)
ActiveRecord::Base.logger = Log4r::Logger.new(“Application Log”)

O como dice la guía, podrías poner también con el mismo resultado,
dentro del bloque Initializer:

config.logger = Logger.new(STDOUT)
config.logger = Log4r::Logger.new(“Application Log”)

En ese punto 2.1 Da dos formas de determinar un logger diferente al que trae
Rails de inicio
-¿Para que?

Esto sirve para cambiar el logger, esto sirve para cambiar tanto la
salida como también podría ser el formato de salida.

Por ejemplo:

require ‘hodel_3000_compliant_logger’
config.logger = Hodel3000CompliantLogger.new(config.log_path)
config.logger.level = Logger::INFO

Modifica la salida de los logs para que tenga el formato de syslog y
poder utilizar herramientas como pl_analyze.

-Una vez cambiado ¿dónde puedo ver el cambio?

En los archivos de log generalmente, log/*.log, salvo que cambies la
salida a algún otro tipo.

b) En el punto 2.2. Los logs levels, ¿para qué los podría querer cambiar?

Se utilizan para loguear diferentes cosas, por ejemplo te
podríainteresar en modo development loguear todo y en modo
producción sólolas cosas que sean de determinado nivel crítico. Así no sobrecargas
los logs de cosas que no son de importancia en un entorno.

Espero haberte aclarado tus dudas. Saludos!

3

Pues si, me has aclarado mis dudas, gracias.
De todas formas despues de haberme leido el tutorial [1], me quedo con
poquitas cosas. Algunas las descarto porque se utiliizan para ver cosas
que
de momento no me interesan (ej.: thread. No me interesa de momento saber
nada de los thread)

NOVATADA:

Esta mañana he metido un controlador en debug y le he dicho
thread list: Bien. Me lista los hilos abiertos por mi y por rails.
thread stop n He empezado a parar hilos y no se como el mongrel no se
me
quería arrancar. Algo de que había un proceso abierto de
mongrel…PID…
No sé, un rollo. He googleado, pero al final me ha
tocado reiniciar el ordenador.
No me he explicado muy bien, y es posible que no se pille del todo cual
ha
sido el problema, pero lo importante es que veáis que no puedes empezar
a
parar
threads de rails y tuyos (o de cualquier otra cosa,…mongrel) si no
sabes
lo que haces.

Hacia el final hay conceptos o utilidades como:

Debugging Memory Leaks

Esto a alguien que está empezando tampoco le interesa.

¿Que me ha gustado?

  1. <%= debug @post %>: Es como un echo de PHP, pero mejor porque te
    imprime toda la variable de instancia(@post) en la vista.
  2. <%= [1, 2, 3, 4, 5].inspect %> # [1, 2, 3, 4, 5] Útil para
    imprimir
    hash y array como string en la vista.
  3. logger.debug “Person attributes hash:
    #{@person.attributes.inspect}” Esto
    también esta bien, por ejemplo te puedes dejar recaditos en el
    controlador,
    y cuando hagas SCRIPT/SERVER, los veras por el terminal (ej.: esto
    debería
    de dar…)

Estos tres casos es sin instalar [ruby-debug]. De ruby-debug, me quedo
con cuatro comandos (de momento):
help: te muestra todos los comandos de ruby-debug
help : te muestra ayuda de un comando en concreto.
list: te muestra tu código. Por donde esta el debugger pasando en ese
momento.
backtrace o where: Muy bueno para aprender. Te muestra todos los
archivos de rails que participan en la realización de la petición:
ej.: de backtrace:
#0 PostsController.index
at line /PathTo/project/app/controllers/posts_controller.rb:6
#1 Kernel.send
at line
/PathTo/project/vendor/rails/actionpack/lib/action_controller/base.rb:1175
#2 ActionController::Base.perform_action_without_filters
at line
/PathTo/project/vendor/rails/actionpack/lib/action_controller/base.rb:1175
#3
ActionController::Filters::InstanceMethods.call_filters(chain#ActionController::Fil…,…)
at line
/PathTo/project/vendor/rails/actionpack/lib/action_controller/filters.rb:617
…
En una petición de New a mi controller intervenían 29# archivos
frame n: Para saltar a uno de esos 29# archivos y ver como se
ejecuta el código de Rails y el tuyo y ver que variables hay en juego.
instance_variables: con este te saca un Array con todas las
variables de instancia definidas en ese momento…útil
*
var instance : *Muestra las variables de instancia de un objeto:
ej.:
(rdb:9) var instance Post.new
@attributes = {“updated_at”=>nil, “body”=>nil, “title”=>nil,
“published”=>nil, “created_at”…
@attributes_cache = {}
@new_record = true
En este ejemplo se ven las variables de instancia del objeto (Post.new)

display: Le dices, muestrame esta variable (por ejemplo @post) según
avanzo por el código (con NEXT por ejemplo) y cada vez que avanzas te
va diciendo
el valor que va tomando @post. tambien se le puede decr que te lo deje
de mostrar undisplay @post.
step: Avanza por el código como *next *pero la diferencia es que
next avanza linea por linea y step avanza de bloque de ejecución en
bloque de ejecución.
Este no me ha quedado muy claro. si alguien lo quiere explicar mejor…

Lo último que me interesa de ese tutorial son los breakpoints, pero
según lo explican ahí no me aclaro, así me lo mirare en el otro
tutorial que me recomendaron,
a ver si deja las cosas más claras.

No sé, seguro que me he dejado comandos que consideráis útiles. Si
alguien ve que he dicho algo mal o ve que la info se puede aclarar o
aumentar…que lo haga
en este hilo que ya esta pagado :slight_smile:

Un saludo

[1] Debugging Rails Applications — Ruby on Rails Guides

El 27 de enero de 2009 16:41, Emilio T. [email protected] escribió:

4

Lo último que me interesa de ese tutorial son los breakpoints, pero según lo explican ahí no me aclaro, así me lo mirare en el otro tutorial que me recomendaron
El tutorial al que me refería [1] si que creo me ha aclarado un poco
lo de los *breakpoints
*Hay tres formas de poner breakpoints
break : La palabra *break *y un nº de linea. P.ej.: si
estoy en la linea 3 y quiero parar el código en la nº 5, pongo *break
5
break file:line [if expresion] *: Pones la palabra *break *y después
un path a un archivo (ej.:
/Users/web/RoR/App/rails2/restblog/app/models/user.rb) aunque
nuestro debugeo haya empezado en un controller, podemos apuntar a
cualquier archivo de nuestra App. Despues de los dos puntos hay que
especificar el nº de
linea de ese archivo en el que ponemos el break. Lo último no lo he
usaro *[if expresion], *pero sirve para poner una condición al break,
y si se cumple, se ejecuta,
y si no, pasa del break.
*break class(.|#)method [if expression]: *pone el break en el metodo
de clase(.) o metodo de instancia de esa clase(#):
"set breakpoint in method (. and # for class and instance method
respectively) defined in class. The expression works the same way as
with file:line."
Lo que yo entiendo lo muestro con un ejemplo:
Tengo un archivo User.rb con un metodo *latest_post *definido en el
que pilla los últimos 4 post de ese usuario
def latest_post
posts.find(:all, :order => ‘id DESC’, :limit => 4)
end

Supongamos que yo inicio mi debugger en el controller del modelo User
(users_controller.rb). en el metodo index de este controller:

def index
debugger
@users = User.find(:all)

respond_to do |format|
  format.html # index.html.erb
  format.xml  { render :xml => @users }
end

end
el método que hemos definido en el modelo user (en user.rb) →
latest_post

Lo usamos en la vista index del modelo User (index.html.erb)
<% for user in @users %>
<%= user.latest_post_title %>
<% end %>

vele, ¿situados? ahora si queremos meter un *break *haremos:
(rdb:5) break User#latest_post

Ahora cuando le demos a *cont *para continuar el código se nos parara
en user.rb:line 4 que es donde hemos definido el metodo en el modelo.
Una vez puestos los break hay 4 comandos que son útiles:
info breakpoints: te dice los breaks que has puesto ej.:
(rdb:5) info breakpoints
Num Enb What
1 y at users_controller.rb:15
2 y at User:latest_post_title

En este caso he puesto *2 break
enable breakpoints: *Autoexplicativo, habilita los todos los break
*disable breakpoints: *Autoexplicativo, deshabilita los todos los break
*delete n: *Borra el break n cuyo nº sabes con info breakpoints

Creo que está bien ruby-debug. A mi me puede hacer la vida más fácil.
Cuando pueda pondre esto que he puesto aquí en mi blog todo junto,
aunque como siempre,
las cosas estarán mejor explicadas en los artículos que referencio.

Un saludo
NOTA:
Cualquier aclaración que queráis hacer, me lo contáis aquí así luego
no pongo tonterías fuera de la lista :slight_smile:

[1] Debug Your Rails App With ruby-debug — SitePoint
[2] Debugging Rails Applications — Ruby on Rails Guides

El 27 de enero de 2009 17:56, Andrés gutiérrez
[email protected]escribió: