padding an array

Posted by Colin A. Bartlett Fri, 03 Aug 2007 20:29:00 GMT

While doing a group code review of a small project Steve was working on today, we discovered that there doesn’t seem to be a way to make an existing array a certain length by padding it with a given value.

In VB, one can ReDim an array to make it a different length. This kind of feature on the Array class could save some lines of code in this project. So here’s what we came up with:

class Array
  def pad!(size=0, what=nil)
    self << what while self.length < size 
  end
end

a = ["hello","hello","hello"]
a.pad!(10,"goodbye")

This adds 7 “goodbyes” to the end of your array. Perfect for our needs. And surprising that there isn’t a method on Array to do this already. (That our 60 seconds of searching could find.)

Multicore Hardware and Ruby Article

Posted by Justin Reagor Fri, 08 Jun 2007 13:48:00 GMT

Just finished reading this excellent article about the urgency in bringing Ruby to the multi-threaded/core market.

Multicore Hardware and the Future of Ruby

This seems to be an excellent counter point to something that DHH blogged about recently.

Quote:
“The most important thing to remember when thinking about the future of Ruby is that just because we don’t have convenient methods for threading Ruby today, it doesn’t mean we shouldn’t explore all the possible avenues. YARV, JRuby, or Rubinius may come along any day and blow us away with completely new ways to think about working with concurrency. If Rails is ready for this, it can continue to be on the forefront of web toolkits. If it is not it will rapidly fall behind, because ignoring the problem at this stage is ignoring problems that well-funded startups have already encounterd.”

Colin's Ruby Quiz #126 Submission 3

Posted by Colin A. Bartlett Sun, 03 Jun 2007 13:03:00 GMT

If you haven’t looked at this week’s RubyQuiz yet, beware. Spoilers ahead.

This week’s quiz was dead simple. But I think that’s the point of this one. The most interesting thing about RubyQuiz for me is looking at how other people solved the same problem (no matter how simple) and learning about other ways to do things.

Here’s my solution:

(1..100).each do |n|
  ret = ""
  ret += "Fizz" if n.divmod(3).last == 0
  ret += "Buzz" if n.divmod(5).last == 0
  ret = n if ret == ""
  puts ret
end

The challenge presented this week is one that is well suited for a quick in-interview coding session for potential hires. Having prospective employees write code was a new idea to me that I read about in Joel on Software. And although I didn’t have candidates in the last round of hiring write code, I did review some psudo-code on the whiteboard with them and I think the next candidates will actually sit down at a machine and tap something out for us in our presence.

The Rails Way

Posted by Colin A. Bartlett Mon, 21 May 2007 15:01:00 GMT

Sunday’s morning keynote at RailsConf was by Jamis Buck and Michael Koziarrski, both committers to the Rails core. The format was quite useful: a series of short code reviews from a variety of submitters to their website, The Rails Way.

  1. Jamis asked for a show of hands for who had read his “Skinny Controller / Fat Model” article. I, ashamedly, have not, but I intend to. I’ve heard the “fat model” concept more and have been trying to emphasize putting as much as makes sense into the Model, and less into the controller.
  1. They mentioned how you can override the #to_param method on an ActiveRecorded descendant in order to control what is used as the “id” string when building a URL in Rails. This would work perfectly with the pretty URLs I have been trying to use more and more.
  1. Jamis stresses how we should all strive to make our code “intention revealing”. One of the beauties of Ruby is the flexibility and expressiveness it allows you. Wherever possible, we should structure our code to be readable and even self-documenting. And where our code does not clearly reveal our intentions, we should document liberally with comments.
  1. #with_options seems to be a pretty slick little method that I have to try. It’s a method on Object that allows you to prevent repeating the same options on a series of method calls.
  1. Many people forget to actually use the ActiveRecord associations they setup. For instance, instead of People.find(:all, :conditions => [“company_id = ?”, 99]) one can do something like @company.people which can make your code much more readable and DRYer, too.
  1. And finally, they showed a code example that used the #returning method wrapped around several lines of code in a method that was to return something. Even after an explanation, I didn’t quite get how this worked. So that’s something to investigate.

Reading code

Posted by Colin A. Bartlett Fri, 18 May 2007 23:12:00 GMT

Believe it or not there was actually a talk about how to read code. There’s more to it then I realized and there were some interesting handy tips presented, although there wasn’t as much actual substance to this talk as I had envisioned. Here’s some tips:

When reading ruby or Rails code beginners often might not even know where to start. Here’s a pretty good track to follow:

  1. Read the URL of the page in question. In simple apps that aren’t using fancy routes, the URL will tell you the action/controller.
  2. Check out the routes.rb file for any fancy route configurations to find the controller/action.
  3. Open the controller and find the method. Read through it.
  4. Look for any filters on the controller. Usually declared at the top. Find them and see if there is stuff running before or after your method.
  5. See what methods on the model are invoked and read through the model method.
  6. Look for callbacks on the model. Stuff like before_create can add functionality that you might not have realized was there.
  7. Application controller and application helper files often contain other stuff you should look through before doing any spelunking.
  8. Seek out observers. Often declared in environment.rb and residing in the models folder, these are callbacks that often attach themselves to multiple models.
  9. Plugins and libraries in /lib are good to look at, too.
Some other tidbits about finding the method you’re looking for:
  1. Check for normally defined methods
  2. Find any method_missing implementation
  3. Grep through files for any metaprogramming like define_method.

IRB in Candy Land 1

Posted by Justin Reagor Wed, 16 May 2007 00:23:00 GMT

I’m not sure about the general Ruby hacker population, but I can’t live without IRB (or Rail’s console). In my never ending quest to make my job even more colorful, I found this gem tidbit of yummyness earlier today…

As you can obviously see in the image, Wirble extends IRB to allow syntax highlighting as well as built-in ri references and various other wonderland features. You can also do extensive customizing, using your .irbrc file. I haven’t found any downside to having this yet, so if anyone knows of any let me know.

http://pablotron.org/software/wirble/

Older posts: 1 ... 3 4 5