Archive for the ‘ruby’ Category
In the series of posts that have Ruby Quirks in the title, my goal is to keep track of unexpected behaviors I encounter with Ruby as I continue learning the language. I will divide the quirks into separate sections (most likely respective classes) as I encounter them.
Since it is the same post, that will be constantly updated, I will put the date I encountered a particular quirk next to it’s subheading. I am going to take Pete’s advice and write separate posts for each quirk I encounter.
String class has
 operator that allows us to get a substring for a given string. For example:
name = "Ashish"
str = name[2,3] # str contains "his"
However, if you pass a single index to the
 operator, the response is not something you would expect. For example:
char = name # char contains 115, the ASCII representation of the character s
While we are in the topic of characters & their ASCII representation, Ruby provides a
? operator to evaluate the ASCII representation of a string. For example:
?a # returns 97
?A # returns 65
?s # returns 115
?AA # results in SyntaxError
This quirk can be seen in Ruby 1.8.7 & earlier versions of Ruby. However, from 1.9.1, the behavior is as expected. For example, in 1.9.1 and beyond:
?a # returns a
"Ashish" # returns s
This is going to be first of what I hope to be many blog posts documenting my foray into Ruby programming. Foray might be a bad choice of word given that this is not my first attempt at learning the language. However, the approach that I am taking this time around is more active than my previous attempts so I am hopeful. Like any other endeavor, this too has a goal & a specific one at that – being able to build a foundation in Ruby in time for Lone Star Ruby Conference at the end of August.
The reason I am optimistic about this approach is because I am currently working through the wonderful Ruby Koans created by EdgeCase. Ruby Koans was what introduced me to Mike Clark’s approach on learning different facets of Ruby. This is a great starting point for anyone who is new to Ruby as it introduces both the core concepts or Ruby while introducing the idea of testing. Since we are not writing code, it is not test-first-development but more of an inquiry into the ruby interpreter through test cases. The best part about Ruby Koans so far is the question that are posed that forces you to move away from the hows that the tests focus on to more of the whys. I am going to focus on one such whys on this post.
The question posed in one of the Koans was in regards to String modification. The tests were for the shovel (
<<) & plus equals (
+=) operators. The question was:
“Ruby programmers tend to favor the shovel operator (
<<) over the plus equals operator (
+=) when building up strings. Why?”
At first, I did not pay attention to this & was about to move to the next failing test. However, since I wanted to do proper justice to my learning experience, I decided to think a little bit about the the two operators in relation to the question being posed. My gut feeling told me that it probably had to do with the fact that the shovel (
<<) operator modifies the actual object while the plus equals (
+=) operator created a new object altogether.
Of course, I was afraid of being wrong and wanted to verify this. I was about to fire up IRB to test it out when I remembered Mike Clark’s approach to learning and thought I should write a test to see if what I was thinking was the answer was true. So, I decided to write a quick test:
class StringTest < Test::Unit::TestCase def test_plus_equals_creates_new_object original_string = "Hello, " hi = original_string assert_equal original_string.object_id, hi.object_id there = "World" hi += there assert_not_equal original_string.object_id, hi.object_id end def test_shovel_does_not_create_new_object original_string = "Hello, " hi = original_string assert_equal original_string.object_id, hi.object_id there = "World" hi << there assert_equal original_string.object_id, hi.object_id end end
The test proved my initial hunch. I was going to leave it at that but then I remembered that Array also use both operators. So I wrote another test to verify that the behavior is the same for Arrays:
require 'test/unit' class ArrayTest < Test::Unit::TestCase def test_plus_equals_creates_new_object original_string = ["Hello"] hi = original_string assert_equal original_string.object_id, hi.object_id there = ["World"] hi += there assert_not_equal original_string.object_id, hi.object_id end def test_shovel_does_not_create_new_object original_string = ["Hello"] hi = original_string assert_equal original_string.object_id, hi.object_id there = ["World"] hi << there assert_equal original_string.object_id, hi.object_id end end
So long story short, the reason why Ruby programmers prefer the shovel operator (
<<) over the plus equals (
+=) operator when building strings is to avoid creating multiple objects during the process. If there are subtleties that I am missing or if I am completely wrong, I would love to hear from people and improve upon what I have learned so far.
UPDATE: Thanks to @i82much for telling me how to embed code in wordpress.
UPDATE 2: Thanks again to @i82much, you can find out how to have source code displayed for different languages here
I recently finished reading & working through the example code for Eldon Alameda’s Foundation Rails 2 book. As someone who has been struggling to learn Rails for the past few years, Eldon’s approach of teaching the fundamentals before diving into building an app was very helpful. This may not apply to everyone but I was always frustrated with the previous books & tutorials where the application building was done before explaining how the plumbing works.
Another good thing about the book is that Eldon talks about how a particular feature in rails has evolved over the years as well as explains the reasoning behind the changes. He also introduces related topics such as RESTful Architecture as an aside without going too far off topic. The fact that we play around with the console immediately is also helpful.
One of the thing that I really enjoyed is how Eldon would give a basic solution to a give problem and walk us through refactoring that piece and turning it into a more elegant code. This is great not only because it teaches us how to go about refactoring our code but also makes sure that the reader first understands the solution in a simple version that is easier to understand before introducing Ruby syntactic sugar & rails magic. I love the fact that Eldon introduces the idea of TDD in the book because it is definitely a good habit to develop and a requirement to be a successful Rails developer.
Eldon also does a really good job of introducing the readers to plugins as well. Rails is known for the extensibility and there are a lot of plugins out there that give us additional functionality. By showing us how to develop applications using plugins, he gives us an idea of what are the kinds of things to consider when using plugins as well as customizing it to fit your needs. All in all, it is a great introductory book for Rails and I highly recommend it to any beginners who are trying to learn Rails.