WNY Ruby User Group

For the past few months I have been attending meetings of the WNY Ruby User Group. My reason for attending was both job related and of a personal interest as part of that cliche 'lifelong pursuit of knowledge'.

I had been a member of only two 'programmers' groups prior to attending the WNY-RUG; I was a member the Buffalo State College Information Processors Association and an ancillary reader and commenter of evolt.org. Having only minor involvement in these organizations, I wasn't sure what to expect at the meet-ups for WNY-RUG.

I think many people, as I did, are picturing a group of high-level Ruby folks hanging out and speaking about things only high-level Ruby folks understand. And this was my first impression as well. As people presented, I thought I would have no point of reference at all.

However, as I persevered through the first meeting and went back to my notes, I realized there was benefit there for even people like myself (read: total ruby n00b). I found that there were three main things I gained from these meeting, and likely anyone with even the slightest interest or knowledge can glean from attending.

Resources

One of the biggest benefits I've had from attending is the people there. Each person there is interested in the language and spreading the knowledge of Ruby and Rails. Egos are tossed out and people can converse on a level that is stimulating and educational. After watching presentations I was able to interpolate what was being said about Ruby into what I was working on in my day-to-day work.

In conjunction with learning Ruby...

While going to group meet-ups I have been learning Ruby (on Rails). In comparison to other frameworks or languages, Ruby seems much more straightforward, but with the 'smarts' of other languages. While listening to other people present their information, I realized there were little pieces I was picking up as I was learning Ruby. The little bits I have been taking away from presentations have allowed me to better understand, if not on the level of other group members than on my own precursory level, the way things function in Ruby. This has been a nice in-road to the learning process.

Input

Not surprisingly, people who program in Ruby have the same problems any other people have. At the end of each meeting, when everyone who planned to present is finished, it seems the entire group engages in discussions that effect everyone who programs. It is a good feeling to be able to find common ground and understanding among peers regardless of platform or language.

At this point in time, I am not programming in Ruby day-to-day. As several members of the group have pointed out, all this will become easier once I do. In the meantime, I plan to continue learning and continue going to the meet-ups in order to benefit as much as possible from the group.

  I raised a question in our last meeting about passing parameters into rake tasks. I was surprised that there wasn't an immediate answer to the problem and only a few references to it online.

   After messing around with some of my own tasks and taking some of the thoughts brought up in the meeting it turns out that this is quite simple and it appears it is also under utilized as there is quite a bit of experience in our group and it doesn't appear than anyone has tried it.

Simple example

  To pass parameters into rake tasks you simple append a key = value hash to the end of your rake command. So if you had a task foo in namespace bar and you wanted to pass in a variable called 'snafu' you call the following.

$>rake foo:bar snafu='situation normal all frakked up'

  The one caveat here is that obviously you have to have some knowledge of the parameter names used in the task. So your rake file would look something like this. Notice that your variables are accessed via the ENV hash.

namespace :foo do

  desc 'testing parameter passing'
  task :bar do

    puts "you passed in the parameter snafu = #{ENV['snafu']}"

  end

end

  So why would I want to do this in the first place? In my case I wrote a task to do some data related operations on 80K records and I wanted to be able to specify the number of or type of records on which to perform the task without having to write a different script for each instance or change the script itself for each run of the task.

Thoughts on multiple parameters

   It can get cumbersome if you have a task that needs several parameters. My current solution is to use to use a single params hash member and then parse out multiple values from it in the task. This has the added bonus of not requiring the person running the task to have to know anything about the names you've used inside your task they only need to be aware of the params hash.

$> rake foo:bar params=var1,var2,var3,var4

Note that you will need quotes around your params list if it contains any unescaped white space.