The Foraker Labs team had a great time at this year’s Rocky Mountain Ruby Conference (#rockymtnruby). It was fantastic to see a full house at the Boulder Theatre for the two days of the conference, and we enjoyed hanging out with old friends from within the Boulder Ruby community, as well as getting a chance to meet a whole host of visitors from near and far.
Here’s a brief overview of some of our favorite talks.
Posted: September 27th, 2011 by Neal Enssle
Tags: conferences, foraker, programming, ruby
No Comments »
Here’s a nifty little patch to Ruby’s Array class to provide a method for picking an element at random:
class Array
def random_pick
self.sort_by { rand }.first
end
end
So then you can do things like this:
def what_is_your_favorite_color?
colors = [ 'red', 'blue', 'green', 'yellow', 'purple', 'pink', 'black' ]
colors.random_pick
end
Please don’t ask my why I’m doing this. The answer has something to do with test data.
Posted: February 28th, 2011 by Neal Enssle
Tags: code, howto, programming, ruby
1 Comment »
So occasionally I want to output a debugging message for a Rake task. That’s easy enough. But what if I only want to output that message if the Rake task is being run with the --trace option? It turns out the answer is to check the Rake.application.options.trace flag in your task to determine if the --trace argument has been passed in, like so:
desc "The answer to life, the universe, and everything"
task :answer do |t|
puts "42"
if Rake.application.options.trace
puts "Task '#{t.name}' is in --trace mode"
end
end
Note that you can also set Rake.application.options.trace = true in your Rake task if you always want to see the stack trace information.
Posted: November 12th, 2010 by Neal Enssle
Tags: programming, rake, ruby
No Comments »
Foraker Labs just posted this (unofficial) YouTube video of the lightning talk I had a chance to give at the Mountain.rb Ruby conference last week in downtown Boulder, Colorado:
How to Become a Better Programmer in 90 Days
In this brief talk I present highlights from three books on my required reading list that (I believe) will help make you a better programmer:
Thanks to Derek Olson for taping and editing, and thanks again to Marty Haught for organizing the conference!
Posted: October 13th, 2010 by Neal Enssle
Tags: better, boulder, conferences, foraker, howto, programming, reading, ruby
No Comments »
I had a great time along with some of the rest of the Foraker crew at Mountain.rb, Boulder’s own Ruby conference.
Check out my recap of Mountain.rb, posted in two parts on the Foraker blog.
Posted: October 11th, 2010 by Neal Enssle
Tags: boulder, conferences, foraker, ruby
No Comments »
It took me a bit too long to Google this, so I thought it was worth a note: You can find the location or path to where your Ruby gems are installed at with this command:
gem environment gemdir
Hope it’s useful!
Posted: March 30th, 2010 by Neal Enssle
Tags: gems, howto, programming, rails, ruby, rubygems
2 Comments »
A few weeks ago I needed a Rake task to answer a simple question for me:
“What’s my name?”
I honestly can’t quite remember why exactly the task needed to know it’s own name, but at the time it seemed important and I spent a couple hours digging about before I found out that Rake tasks are shy by nature. Or at least when implemented the way almost every tutorial tells you to implement them:
namespace :life do
desc "The answer to life, the universe, and everything"
task :answer do
puts "The answer to life, the universe, and everything is 42."
end
end
But how do I know what the name of the current task is? Well, after making a couple of random attempts (like “puts task.name”) and digging around in the very sparse documentation on the Rake homepage, I stumbled across a bit of documentation that talked about “Tasks with Actions”:
Actions are defined by passing a block to the task method. Any Ruby code can be placed in the block. The block may reference the task object via the block parameter.
task :name => [:prereq1, :prereq2] do |t|
# actions (may reference t)
end
Ah ha! “The block may reference the task object via the block parameter.” That’s exactly what I was looking for. Adding the block parameter allows us to reference the task object itself. And the task object itself has a good bit of useful meta information:
namespace :life do
desc "The answer to life, the universe, and everything"
task :answer do |t|
puts t.name
puts t.comment
puts t.scope
end
end
The task now returns the following:
life:answer
The answer to life, the universe, and everything
life
The first line of output is nifty, and answers the “What’s my name?” question with the fully scoped name of the task. Given that much it’s probably not hard to return the task name in even the most deeply namespaced Rakefile. The second line is the “comment” — actually the description of the task. And the third line gets us the scope (namespaces). There are more methods available, but check teh googles for “Rake::Task api”.
So with this meta information we can do something useful like:
namespace :life do
desc "The answer to life, the universe, and everything"
task :answer do |t|
puts "#{t.comment} is 42."
end
end
Voila. And that’s probably enough meta for one day.
Posted: November 14th, 2009 by Neal Enssle
Tags: code, howto, programming, rake, ruby, tools
1 Comment »