프로그래밍 공부/TIL : Rails Tutorial

Chapter 12 : Debugging Rails Applications

나른한 하루 2020. 7. 18. 16:25
이 글은 Rails 5.0 Guide 기준으로 작성됩니다.
https://guides.rubyonrails.org/v5.0/debugging_rails_applications.html

 

 

  • Debugging Rails Applications Intro

이 안내서는 Ruby on Rails 애플리케이션 디버깅 기술을 소개합니다.

 

 

  • View helpers for Debugging

One common task is to inspect the contents of a variable. Rails provides three different ways to do this:

일반적인 작업 중 하나는 변수의 내용을 검사하는 것입니다. Rails는 이를위한 세 가지 방법을 제공합니다.

  • debug
  • to_yaml
  • inspect

1. debug

debug helper는 YAML 형식을 사용하여 객체를 렌더링하는 <pre> 태그를 반환합니다. 모든 객체에서 사람이 읽을 수 있는 데이터를 생성합니다. 아래 코드를 살펴볼까요?

<%= debug @article %>
<p>
  <b>Title:</b>
  <%= @article.title %>
</p>

위 코드를 웹페이지에서 확인 시, 아래와 같은 결과를 보게 될 것입니다 :

--- !ruby/object Article
attributes:
  updated_at: 2008-09-05 22:55:47
  body: It's a very helpful guide for debugging your Rails app.
  title: Rails debugging guide
  published: t
  id: "1"
  created_at: 2008-09-05 22:55:47
attributes_cache: {}
 
 
Title: Rails debugging guide

 

2. to_yaml

모든 객체에서 to_yaml 메소드를 사용하면 YAML 형식으로 변환됩니다. 이 변환 된 객체를 simple_format helper 메소드로 통해 출력 할 수 있습니다.

<%= simple_format @article.to_yaml %>
<p>
  <b>Title:</b>
  <%= @article.title %>
</p>
--- !ruby/object Article
attributes:
updated_at: 2008-09-05 22:55:47
body: It's a very helpful guide for debugging your Rails app.
title: Rails debugging guide
published: t
id: "1"
created_at: 2008-09-05 22:55:47
attributes_cache: {}
 
Title: Rails debugging guide

 

3. inspect

객체 값을 표시하는 또 다른 유용한 방법은 특히 Array 또는 Hash 작업을 검사할 때 입니다. 이때 객체 값은 String으로 출력합니다. 예를 들면 다음과 같습니다. :

<%= [1, 2, 3, 4, 5].inspect %>
<p>
  <b>Title:</b>
  <%= @article.title %>
</p>

위 코드는 웹에 아래와 같이 보여질겁니다.

[1, 2, 3, 4, 5]
 
Title: Rails debugging guide

 

 

  • The Logger

런타임 시 정보를 로그 파일에 저장하는 것도 유용할 수 있습니다. Rails는 각 런타임 Environment에 대해 별도의 로그 파일을 유지 및 관리합니다.

 

1. What is the Logger?

Rails는 ActiveSupport::Logger 클래스를 사용하여 로그 정보를 작성합니다.

Log4r과 같은 다른 로거도 대체 될 수 있습니다.

 

 config/application.rb  또는 다른 환경 파일에서 대체 로거를 지정할 수 있습니다. :

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

또는 Initializer 에서 다음 중 하나를 추가하면 됩니다.

Rails.logger = Logger.new(STDOUT)
Rails.logger = Log4r::Logger.new("Application Log")

 

 참고  기본적으로 각 로그는  Rails.root/log/  디렉터리 내에 작성되며, 로그 파일은 애플리케이션이 실행중인 Environment의 이름을 따라 이름이 지정됩니다.

 

2. Log Levels

When something is logged, it's printed into the corresponding log if the log level of the message is equal to or higher than the configured log level. If you want to know the current log level, you can call the Rails.logger.level method.

 

Log Level에는 다음과 같이 존재합니다:

  • :debug
  • :info
  • :warn
  • :error
  • :fatal
  • :unknown

(위에서 부터 0으로 시작해서) 0에서 5까지의 로그 레벨 번호에 해당합니다.

기본 로그 수준을 변경하려면 아래와 같이 설정해주면 됩니다.

config.log_level = :warn # In any environment initializer, or
Rails.logger.level = 0 # at any time

이는 Producton 로그에 작성해 있어 불필요한 정보에 대해선 작성하지 않고, development 또는 staging Environment에서 로그가 기록되려는 경우에 유용합니다.

 

 참고  기본 Rails log level은 모든 Environment에서 debug 됩니다.

 

3. Sending Messages

현재 기록에 대한 로그기록 작성 시 logger을 활용하면 됩니다.

controller, model, mailer 내에서 로그 표현 시, (debug | info | warn | error | fatal) method를 사용하세요.

logger.debug "Person attributes hash: #{@person.attributes.inspect}"
logger.info "Processing the request..."
logger.fatal "Terminating application, raised unrecoverable error!!!"

기존의 코드에 logger을 활용하는 예시입니다 :

class ArticlesController < ApplicationController
  # ...
 
  def create
    @article = Article.new(params[:article])
    logger.debug "New article: #{@article.attributes.inspect}"
    logger.debug "Article should be valid: #{@article.valid?}"
 
    if @article.save
      flash[:notice] =  'Article was successfully created.'
      logger.debug "The article was saved and now the user is going to be redirected..."
      redirect_to(@article)
    else
      render action: "new"
    end
  end
 
  # ...
end

그리고 Controller 내 Action이 실행 시 보여지는 log기록 입니다.

이와 같이 추가 logging을 추가하면 log에서 예기치 않은 또는 비정상적인 동작을 쉽게 볼 수 있습니다.

추가 logging을 추가하는 경우, production Environment에서 불필요한 log가 작성되지 않도록 log level을 적절하게 사용하세요.

 

4. Tagged Logging

When running multi-user, multi-account applications, it's often useful to be able to filter the logs using some custom rules. TaggedLogging in Active Support helps you do exactly that by stamping log lines with subdomains, request ids, and anything else to aid debugging such applications.

 

다중 사용자, 다중 계정 Application을 실행할 때는 종종 일부 사용자 지정 규칙을 사용하여 log를 필터링 할 수 있는 것이 유용합니다.

Active Support의 TaggedLogging을 사용하면 log 도메인에 하위 도메인, request ID 및 기타 응용 프로그램을 디버깅하는 데 도움이되는 모든 항목을 logging 처리 할 수 ​​있습니다.

logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
logger.tagged("BCX") { logger.info "Stuff" }                            # Logs "[BCX] Stuff"
logger.tagged("BCX", "Jason") { logger.info "Stuff" }                   # Logs "[BCX] [Jason] Stuff"
logger.tagged("BCX") { logger.tagged("Jason") { logger.info "Stuff" } } # Logs "[BCX] [Jason] Stuff"

 

5. Impact of Logs on Performance

Logging은 특히 Disk에 logging 할 때 Rails app의 성능에 거의 영향을 주지 않습니다. 또한 몇 가지 미묘한 점이 있습니다. :

 

1) :debug 레벨을 사용하면 훨씬 많은 string이 작성되어, 로그가 Disk에 자주 기록되므로, 그와 반대로 많이 기록되지 않는 않는 :fatal보다 성능이 떨어지게 됩니다.

 

2) 너무 많은 logger 내 string이 읽힙니다.

## Logger level 기록기준 설정
Rails.logger.level = 1 ## info 이상 log level에 대해 기록 writing

## logger 코드
logger.debug "Person attributes hash: #{@person.attributes.inspect}"

 

위의 예를 보면, 허용된 Log 출력 level에 debug가 포함되지 않은 경우에도 큰 따옴표(") 내에 있는 string을 읽어내는 문제점이 있습니다. 적은 내용이라면 괜찮겠지만, 긴 내용을 가지고 있을 경우 퍼포먼스에 영향을 미칩니다. 이러한 이유는 Ruby가 string을 판별해야 하기 때문입니다.

 

따라서 log 출력 level이 사전에 설정한 log 허용 level에 포함 된 경우, logger 메소드에 블록을 전달하는 것이 좋습니다.

위의 코드를 보완해서 다시 작성해보면 아래와 같습니다. :

logger.debug {"Person attributes hash: #{@person.attributes.inspect}"}

 

위와같이 블록 형식으로 작성할 경우, log level을 판단 후, 만약 조건에 맞지 않는 level인 경우 블록 내부의 string을 읽지 않습니다.

이는 대량의 logging 때 효과를 발휘합니다.

 

 

  • Debugging with the byebug gem

코드가 예기치 않은 방식으로 작동하면 log나 console로 출력하여 문제를 살펴볼 수 있습니다. 그러나 때론 이러한 사례의 오류 추적이 문제의 원인을 찾는 데 효과적이지 않을 때도 있습니다.

=> 실제로 실행중인 작업 내의 소스 코드로 바로 이동해야 하는 경우가 최고의 디버깅 방식일 수도 있습니다.

 

Rails 소스 코드에 대해 배우고 싶지만 시작 위치를 모르는 경우에도 debugger가 도움이 될 수 있습니다. Application에 보낸 request에 대해서 debug 후, Rails 코드에서 작성한 코드에 이동하는 방법을 이 가이드를 통해 배우게 될 겁니다.

 

1. Setup

byebug gem을 설치 후,

gem install byebug

실제로 서버가 돌아갈 때 당시의 상황에서 로그가 보여질 부분을 코드 내에 설정하면 됩니다.

Rails Application 내에서 byebug 메소드를 호출하여 debugger를 호출 할 수 있습니다.

class PeopleController < ApplicationController
  def new
    byebug
    @person = Person.new
  end
end

서버 내에 byebug를 통해 코드 디버깅을 하는 모습

 

2. The Shell

Application이 byebug 메소드를 호출하자마자 debugger는 Application 서버를 시작한 터미널 창의 디버거 셸에서 시작되고 디버거의 프롬프트(byebug)에 배치됩니다. 프롬프트가 표시되기 전에 실행할 행 주위의 코드가 표시되고 현재 행은 아래와 같이 '=>'로 표시됩니다.

byebug : byebug shell 접근 및 debugging 하는모습

브라우저에서 request 시, 디버거가 완료되고 trace는 전체 request 처리를 완료 할 때까지 request이 포함된 브라우저 탭이 정지됩니다.

 

이제 Application을 살펴볼 차례입니다.

debugger 사용법에 대해서는 help 명령어를 통해 알아낼 수 있습니다.

(byebug) help
 
  break      -- Sets breakpoints in the source code
  catch      -- Handles exception catchpoints
  condition  -- Sets conditions on breakpoints
  continue   -- Runs until program ends, hits a breakpoint or reaches a line
  debug      -- Spawns a subdebugger
  delete     -- Deletes breakpoints
  disable    -- Disables breakpoints or displays
  display    -- Evaluates expressions every time the debugger stops
  down       -- Moves to a lower frame in the stack trace
  edit       -- Edits source files
  enable     -- Enables breakpoints or displays
  finish     -- Runs the program until frame returns
  frame      -- Moves to a frame in the call stack
  help       -- Helps you using byebug
  history    -- Shows byebug's history of commands
  info       -- Shows several informations about the program being debugged
  interrupt  -- Interrupts the program
  irb        -- Starts an IRB session
  kill       -- Sends a signal to the current process
  list       -- Lists lines of source code
  method     -- Shows methods of an object, class or module
  next       -- Runs one or more lines of code
  pry        -- Starts a Pry session
  quit       -- Exits byebug
  restart    -- Restarts the debugged program
  save       -- Saves current byebug session to a file
  set        -- Modifies byebug settings
  show       -- Shows byebug settings
  source     -- Restores a previously saved byebug session
  step       -- Steps into blocks or methods one or more times
  thread     -- Commands to manipulate threads
  tracevar   -- Enables tracing of a global variable
  undisplay  -- Stops displaying all or some expressions when program stops
  untracevar -- Stops tracing a global variable
  up         -- Moves to a higher frame in the stack trace
  var        -- Shows variables and its values
  where      -- Displays the backtrace
 
(byebug)

 

코드 byebug 메소드 기준, 앞의 10줄 코드를 보려면 list- (또는 l-)를 하세요.

byebug : l-

 

byebug 메소드가 위치한 주변 코드를 볼 수 있습니다.

byebug 코드의 위치를 ​​다시 보려면 list= 를 입력하면됩니다.

byebug : list=

 

3. The Context

Application debugging을 시작하면 stack의 다른 부분을 거치면서 다른 context에 배치됩니다.

 

debugger는 중지지점 또는 이벤트에 도달하면 context를 작성합니다. context에는 debugger가 frame stack을 검사하고 debugging 된 프로그램의 관점에서 변수를 평가하며, debugging 된 프로그램에 대한 정보가 있습니다.

 

언제라도 backtrace 명령 (또는 where)을 통해 Application의 backtrace 결과를 출력 할 수 있습니다. 이를 통해 내가 보고자 하는 코드가 어디에 있는지, 어떻게 알 수 있는지에 큰 도움이 될 수 있습니다. 코드에 있어 (더 깊게) 궁금한 점이 있으면 backtrace를 통해 알아낼 수 있습니다.

byebug : where

위와같이 where로 조회 후 나온 frame 중, 현재의 frame은 --> 로 표시됩니다.

 

frame n 명령을 사용하여 이 추적에서 원하는 곳으로 이동할 수 있습니다 (더불어 context 또한 변경). 여기서 n은 지정된 프레임 번호입니다. 그렇게하면 byebug가 새로운 context를 표시합니다.

사용 가능한 변수는 코드를 한 줄씩 실행하는 것과 같습니다.

이것이 바로 debugging 입니다.

 

up [n] 및 down [n] 명령을 사용하여 context n 프레임을 각각 stack의 위 또는 아래로 변경할 수 있습니다.

n은 기본적으로 1 입니다. 이 경우, 위로 번호가 높은 stack frame을 향하고 아래로 번호가 낮은 stack frame을 향합니다.

byebug : frame #0 에서 up 3을 통해 frame #3 으로 context 된 모습

4. Threads

debugger는 thread 명령어(또는 축약 된 th)를 통해 실행중인 thread를 조회, 중지, 재시작(resume), 전환(switch) 할 수 있습니다.

thread 명령어는 아래와 같은 옵션이 있습니다.

  • thread  현재의 thread를 조회합니다. (byebug shell에서 해당 명령어 미지원)
  • thread list  모든 스레드 및 상태를 나열하는 데 사용됩니다. 현재 스레드에는 더하기 (+) 기호가 표시됩니다.
  • thread stop n  n thread를 중지시킵니다.
  • thread resume n  n thread를 재시작(resume) 합니다.
  • thread switch n  현재 thread를 n으로 context(전환) 합니다.

이 명령어는 concurrent thread(동시 스레드) 를 debugging 할 때 매우 유용하며, 코드에 race condition이 발생하는지도 확인해야 합니다.

byebug : thread 조회 및 thread 상태 확인

5. Inspecting Variables

현재 context에서 모든 표현식을 평가할 수 있습니다. 표현식을 평가하려면 아래와 같이 입력하면 됩니다.

아래 예제는 현재 context 내에 정의 된 인스턴스 변수 출력을 보여줍니다.

위 예시가 보여주듯, Controller에서 접근할 수 있는 모든 변수가 표시됩니다. 변수 목록은 코드를 실행할 때 자동으로 업데이트됩니다.

예를 들어 next를 통해 다음 코드를 실행해봅시다. (next는 이 후에 자세히 다룹니다.).

다음 행의 코드를 가리킨 후(next), 다시 instance_variables 을 입력해보세요.

이제 @articles가 인스턴스 변수에 포함됩니다.

이는 @articles를 정의하는 행이 이미 실행 되었기 때문입니다.

 

 참고  byebug shell 내에서 irb 모드로 들어갈 수도 있습니다. context 내에서 irb 세션이 시작됩니다.

 

var 메소드는 변수와 값을 표시하는 가장 편리한 방법입니다. var 에 대한 명령어는 byebug 내 help를 통해 알아볼 수 있습니다.

(byebug) help var
 
  [v]ar <subcommand>
 
  Shows variables and its values
 
 
  var all      -- Shows local, global and instance variables of self.
  var args     -- Information about arguments of the current scope
  var const    -- Shows constants of an object.
  var global   -- Shows global variables.
  var instance -- Shows instance variables of self or a specific object.
  var local    -- Shows local variables in current scope.

 

이 명령어는 현재 context 변수의 value을 검사하는 좋은 방법입니다.

예를 들어, 현재 정의된 지역변수가 없는지 확인 시, byebug shell에 아래와 같이 확인해보면 됩니다.

display를 통해 변수가 초기화 된 값을 볼 수도 있습니다.

이것은 실행이 진행되는 동안 변수의 값을 추적(backtrace)하는 좋은 방법입니다.

표시된 목록 내의 변수는 stack으로 이동 한 후 해당 값과 함께 출력됩니다. 변수 표시를 중지하려면 undisplay n 을 사용하세요.

여기서 n은 변수 번호입니다 (위 예시에서는 1).

 

6. Step by Step

실행중인 추적 위치를 알고 사용 가능한 변수를 출력할 수 있습니다.

이를 통해 계속해서 Application 실행으로 넘어갑니다.

 

step (약어 s)을 통해 다음 logical stopping 지점까지 프로그램을 계속 실행하고 debugger로 제어를 반환할 수 있습니다.

앞전에 잠깐 봤던 next는 step과 비슷하지만 step은 실행 된 다음 코드 줄에서 멈춘 단계에 대해서만 수행하지만, next는 메서드 내에서 내림차순으로 다음 줄로 이동합니다.

 

만약 아래와 같은 상황이 있다고 가정해봅시다 :

 

byebug가 호출된 시점에서 next를 사용하면 method call에 깊게 들어 가지 않습니다.

대신, byebug는 동일한 context 내에서 다음 행으로 이동합니다. 위 코드의 경우 현재 메소드의 마지막 행이므로 byebug는 호출자 method의 다음 행으로 돌아갑니다.

 

동일한 상황에서 step 을 사용하면 byebug는 문자 그대로 다음 Ruby가 가리키는 곳(이 경우 Active Support의 week method; 1.week.ago)으로 이동합니다.

 step 부연설명  step은 블록이나 method을 한 단계 혹은 그 이상을 이동합니다.

코드에서 버그를 찾는 가장 좋은 방법 중 하나입니다.

 참고  step n 또는 next n을 사용하여 n step을 한 번에 앞으로 이동할 수도 있습니다.

 

7. Breakpoints

breakpoint은 프로그램의 특정 지점에 도달 할 때 마다 Application을 중지시킵니다. debugger shell은 해당 라인에서 실행됩니다.

 

break 명령 (축약 명령어: b)을 사용하여 breakpoints을 동적으로 추가 할 수 있는데, 이를 수동으로 추가하는 방법에는 3가지가 있습니다. :

  • break n  현재 소스 파일에서 줄 번호 n에 breakpoints을 설정
  • break file:n [if expression]  file 이름을 가진 파일 내에서 줄 번호 n에 중단 점을 설정. 표현식이 제공 시, file up debugger 시 true로 평가돼야 함. 
  • break class(.|\#)method [if expression]  class에 정의 된 method(. 및 #으로 정의된 class 및 instance method)에서 breakpoint을 설정, 표현식은 file: n 과 동일.

예시로, 이전 next 상황 때를 봅시다.

위에서 11번 째 줄에 대해서 breakpoints를 설정 후, 위 코드에서 또 next를 입력 시, 11번째 줄에서 debugging이 멈춥니다.

(만약 breakpoints 미설정 시, 다음 method 행위를 가리키게 될 것입니다.)

 

또한 info breakpoints을 사용하여 breakpoints를 조회해볼 수 있습니다. 숫자를 제공하면 해당 breakpoints이 보여집니다.

그렇지 않으면 모든 breakpoints이 나열됩니다.

 

중단 점을 삭제 시, delete n 명령을 사용하여 중단 점 num n을 제거할 수 있습니다. 숫자를 지정하지 않으면 현재 활성화 된 모든 breakpoints를 삭제합니다.

 

8. Catching Exceptions

exception-name(또는 cat exception-name) 예외처리 명령은 처리기가 없는 경우 exception-name 유형의 예외를 중단 시키는데 사용될 수 있습니다.

 

모든 활성 캐치 포인트를 조회 시, catch를 사용하십시오.

 

9. Resuming Execution

debugger에서 중지 된 Application에 대해 다시 실행하는 방법은 총 두 가지가 있습니다.

  • continue [n]  script 마지막으로 중지 된 주소에서 다시 프로그램을 실행합니다. (해당 주소에 설정된 breakpoints은 무시됩니다.) 선택적 인수 n을 설정 시, 줄 번호를 지정하여 해당 breakpoints에 도달 할 때 삭제되는 일회성 breapoints을 설정할 수 있습니다. 
  • finish [n]  선택한 stack frame이 돌아올 때까지 실행합니다. frame 번호를 지정하지 않으면 현재 선택한 frame이 반환 될 때까지 Application이 실행됩니다. 현재 선택된 frame은 가장 최근의 frame을 시작하거나 frame 위치 지정(예 : up, down 또는 frame)이 수행되지 않은 경우 0입니다. frame 번호가 지정되면 지정된 frame이 반환 될 때까지 실행됩니다.

10. Editing

두 가지 명령어를 사용하면 debugger에서 editor로 코드를 열 수 있습니다. :

  • edit [file:n]  EDITOR 라는 이름의 환경변수로 지정된 editor를 사용하여 file이라는 파일을 편집할 수 있습니다. 특정 라인 n도 가리킬 수 있습니다.

11. Quitting

byebug를 종료하려면 quit 또는 q를 입력하면 됩니다.

byebug를 종료 시 모든 thread를 종료합니다. 이로인해 서버가 종료되다 보니, 서버를 다시 켜야할 필요가 있습니다.

 

 

12. Settings

byebug는 Action을 설정하는 몇 가지 옵션을 제공합니다.

(byebug) help set
 
  set <setting> <value>
 
  Modifies byebug settings
 
  Boolean values take "on", "off", "true", "false", "1" or "0". If you
  don't specify a value, the boolean setting will be enabled. Conversely,
  you can use "set no<setting>" to disable them.
 
  You can see these environment settings with the "show" command.
 
  List of supported settings:
 
  autosave       -- Automatically save command history record on exit
  autolist       -- Invoke list command on every stop
  width          -- Number of characters per line in byebug's output
  autoirb        -- Invoke IRB on every stop
  basename       -- <file>:<line> information after every stop uses short paths
  linetrace      -- Enable line execution tracing
  autopry        -- Invoke Pry on every stop
  stack_on_error -- Display stack trace when `eval` raises an exception
  fullpath       -- Display full file names in backtraces
  histfile       -- File where cmd history is saved to. Default: ./.byebug_history
  listsize       -- Set number of source lines to list by default
  post_mortem    -- Enable/disable post-mortem mode
  callstyle      -- Set how you want method call parameters to be displayed
  histsize       -- Maximum number of commands that can be stored in byebug history
  savefile       -- File where settings are saved to. Default: ~/.byebug_save

 

 참고  이러한 설정은 Home 디렉토리의  .byebugrc  파일에 저장할 수 있습니다. 디버거는 시작할 때 이러한 전역 설정을 읽습니다. 예를 들면 다음과 같습니다.

set callstyle short
set listsize 25

 

 

  • Debugging with the web-console gem

웹 콘솔은 byebug와 비슷하지만 브라우저에서 실행됩니다. 개발중인 모든 페이지에서 또는 Controller의 Context에서 Console을 요청할 수 있습니다. 콘솔은 HTML 컨텐츠 옆에 렌더링됩니다.

Web 내에서 Console을 돌리는 모습

1. Console

컨트롤러 Action 또는 view에서 console 메소드를 호출하여 콘솔을 호출 할 수 있습니다.

View와 연결된 Controller 내 Action에서 아래와 같이 console 코드를 추가해보세요 :

class PostsController < ApplicationController
  def new
    console
    @post = Post.new
  end
end

혹은 view에서 아래와 같이 코드를 추가해보세요 :

<% console %>
 
<h2>New Post</h2>

 

view 내부에 console이 렌더링 됩니다. 콘솔 호출 위치는 신경 쓰지 않아도됩니다.

호출 시점이 아니라 HTML contents 옆에 렌더링됩니다.

 

콘솔은 순수 Ruby 코드를 실행합니다. class를 define 및 instance화 하고, 새 모델을 작성하며 변수를 검사 할 수 있습니다.

 참고  요청 당 하나의 console만 렌더링 할 수 있습니다. 그렇지 않으면 웹 콘솔이 두 번째 콘솔 호출에서 오류를 발생시킵니다.

 

2. Inspecting Variables

instance_variables를 호출하여 컨텍스트에서 사용 가능한 모든 instance 변수를 나열 할 수 있습니다. 모든 지역 변수를 나열하려면 local_variables를 사용하면 됩니다.

 

3. Settings

  • config.web_console.whitelisted_ips : IPv4 또는 IPv6 주소 및 네트워크의 승인 된 목록을 확인합니다. (기본값 : 127.0.0.1/8, :: 1)
  • config.web_console.whiny_requests : 콘솔 렌더링이 금지 될 때 메시지를 기록합니다. (기본값 : true).

wen console은 서버에서 원격(remote)으로 일반 Ruby 코드를 판단하므로 Production 환경에서 사용하지 마세요.

 

 

  • Debugging Memory Leaks

Ruby Application (Rails에 관계없이)은 Ruby 또는 C언어 코드에서 메모리를 누출될 수 있습니다.

이 섹션에서는 Valgrind와 같은 도구를 사용하여 이러한 누수를 찾고 막는 방법을 배웁니다.

 

1. Valgrind

Valgrind는 메모리 누수 및 race condition을 감지하는 C언어 기반 응용 프로그램입니다.

 

많은 메모리에 대한 관리 및 threading 버그를 자동으로 감지하고 프로그램을 자세하게 볼 수 있는 Valgrind라는 이름의 도구가 있습니다.

예를 들어, 인터프리터의 C extension이 malloc()을 호출하지만 free()를 올바르게 호출하지 않으면 app(프로그람)이 종료 될 때까지이 메모리를 사용할 수 없습니다.

 

Valgrind를 설치하고 Ruby와 함께 사용하는 방법에 대한 자세한 내용은 Evan Weaver의 Valgrind 및 Ruby 글을 참고해주세요.

 

 

  • Plugins for Debugging

오류를 찾고 Application을 디버깅하는 데 도움이되는 몇 가지 Rails 플러그인(Gem)이 있습니다.

  • Footnotes  모든 Rails 페이지에는 요청 정보를 제공 및 TextMate를 통해 소스로 다시 연결되는 각주(footnotes)가 달립니다.
  • Query Trace  로그에 원본 Query 추적이 추가됩니다.
  • Query Reviewer  이 Rails 플러그인은 개발중인 각 선택 쿼리에 있어 "EXPLAIN"를 실행할 뿐만 아니라 분석 된 각 쿼리에 대한 경고 요약과 함께 각 페이지의 렌더링 된 출력에 작은 DIV를 제공합니다.
  • Exception Notifier  Rails Application에서 오류가 발생 시, 이메일 알림을 전송하기위한 Mailer 객체 및 기본 양식 설정을 제공합니다.
  • Better Errors  표준 Rails 오류 페이지를 소스 코드 및 변수 검사와 같은 상황 정보가 포함 된 새로운 페이지로 보여줍니다.
  • RailsPanel  크롬 패널 내에서 Rails 로그의 모든 정보(예 : 매개 변수, 응답 시간,보기 렌더링 시간, DB 요청)를 표시하는 Chrome 확장 프로그램 및 Gem입니다.;브라우저에서 개발자 도구 패널의 Rails 앱 요청에 대한 모든 정보가 정보되는데, db, rendering, total time, 매개 변수 목록, 렌더링 된 view 등에 대한 정보가 제공됩니다.

 

저작자표시