💡 We've had some fantastic Tip of the Week feedback, so we're carrying on :-) If you have any suggestions of things Jemma could cover, you can tweet her @jemmaissroff— she's also keeping a Twitter thread of quick Ruby tips if you want even more.
__
Peter Cooper, editor | ![]() |
![]() Are You Listening to FounderQuest Yet?— It’s a weekly podcast about three Ruby developers bootstrapping a software business on their own terms...and murderbots, ninjas, garlic scapes, and (checks notes) something called Big Mouth Billy Bass. Don’t miss out. FounderQuest sponsor |
Active Record Queries in Views: When It's Bad, When It's Fine— Keeping concerns separate where you can is generally a best practice, but Jason doesn’t think it’s a cast iron rule. (Many JavaScript developers are mixing CSS in with JS nowadays, so it’s a free for all as far as I’m concerned… ;-)) Jason Swett |
Senior Software Engineering Consultant - [100% Remote] — Co-founded by Justin Searls, Test Double is an engineering consultancy on a mission to improve the way the world builds software. Work on challenging projects with a collaborative, passionate team. 100% employee owned, and awesome perks. TestDouble |
Find Your Next Job Through Hired— Create a profile on Hired to connect with hiring managers at growing startups and Fortune 500 companies. It's free for job-seekers. Hired |
Testing ActiveRecord Concerns— It’s a good idea to test your concerns outside of the models that use them, but there are some, um, concerns about how to do that. Alex Barret |
💡 Tip of the Week Kernel#caller_locations gives us a helpful view of the execution stack
Have you ever needed to know the execution stack for a call? Perhaps you’re looking to provide a useful logging message with the entire stacktrace? Or you want to know where a specific method was called? Or you’re writing a gem and need to know where a method is being used? In any of these cases, you’re in luck because from Ruby 2.0 onwards we have access to Kernel#caller_locations which gives us an array of Thread::Backtrace::Location objects which represent the current execution stack. Here’s a simple little example with three methods, where the third method calls the second method which calls the first method which in turn tells us the caller_locations: |
def method_one
caller_locations
end
def method_two
method_one
end
def method_three
method_two
end
pp method_three
|
If we run this snippet (saved in a file called example.rb), we’ll get: |
$ ruby example.rb
["example.rb:6:in `method_two'",
"example.rb:10:in `method_three'",
"example.rb:13:in `<main>'"]
|
We can see our stacktrace! Kernel#caller_locations can take two optional parameters which both work to limit the size of the array of Thread::Backtrace::Location objects we receive. The first (start) parameter tells how many stack entries to omit from the top of the stack. The second (length) parameter tells how many objects to include in the returned Array. A common use of caller_locations is getting the first element to see the calling method. This can be done by passing in the arguments (1,1). If we modify our code slightly to use caller_locations(1,1), we’ll get: |
$ ruby example.rb
["example.rb:6:in `method_two'"]
|
And we can see that method_two is calling method_one. Lastly, there are a few useful methods on Thread::Backtrace::Location objects. The most notable ones are #lineno, #label and #path which give us the line number, method name and file path respectively. This week’s tip was written by Jemma Issroff. |
|
|
