SCM: The Next Generation

Written on 9:58:00 PM by S. Potter

I am sure most developers (whether Java, Ruby, Python, or other) have used Subversion, Perforce or CVS to manage and control their projects' source, but have you used darcs or git? I am sure most of you would have heard of git - it hosts the Linux kernel code currently. A few less have probably encountered darcs before on an obscure European open source project you were interested in once or twice. Prior to this evening, the most notable point of darcs, to me, is that it is written in Haskell - a language I plan on reading more about because I have heard so many good things about it. Both git and darcs are examples of distributed version control systems of which there has been an explosion of products (both commercial and open source) since GNU's Arch. Tonight I had the fortune of experiencing darcs for the first time. Previously I had used darcs get URL to download code before, but never actually utilized any of the features before. Tonight I submitted a patch to a Ruby open source project (RForum) and found the experience very pleasurable as a developer. I have read that darcs is a user friendly version of git minus some powerful options. Perhaps there are git or darcs gurus reading that can shed more light on these two less mainstream SCM systems? If so, I would love to hear your thoughts on them especially if you can compare and contrast with any non-trivial Subversion, Perforce or CVS experiences. Background: I currently use Subversion, however, I usually work in smaller teams, so concurrent work is not that much of an issue at present, but things will be changing. The largest team I worked in on a Subversion project was 6 active developers (9 for the one Perforce project). Of course, I have worked on a project with over 80 developers, but that was using ClearCase and there were so many problems with that project that I can't determine what was caused by ClearCase or the rest of the project's [many] issues.

Ruby Idioms, Part 7

Written on 6:48:00 PM by S. Potter

This idiom I have seen a little more in Rails than I have seen in Ruby, but I am putting it in this Ruby Idioms series anyway. First off, most of you will know by know that you can "transparently" provide a method in Ruby a Hash. What do I mean by "transparently"? Well have a look at the code example below:


user = User.find(:first, :include => :preferences)
The last argument is actually a Hash even though you do not see the curly braces at all. In my opinion it makes for more readable code. So let us look behind the scenes at what the User.find method might do if it wasn't a magic method from ActiveRecord:

class User
  # ... some stuff here
  class << self
    def find(type, params = {})
      options = @@DEFAULTS.merge(params)
      case type
      when :first
        options[:limit] = 1
      when :all
        # do stuff with options and query database
        # bla bla bla
      end
      # rest of implementation
    end
  end
  # ... some stuff here
end
This is quite useful, but one of the idioms in the same vain that I really appreciate is the following usage:

  validates_length_of :name, :title, :company, :in => 2..128
This provides another example of supplying a transparent Hash arguments at the end of a list of arguments, the length of which is unknown. For example we may decide that the code needs to actually be more like:

  validates_length_of :name, :company, :in => 2..64
  validates_length_of :title, :in => 2..128, :allow_nil => true # to cater for those ridiculously long job titles out there or those that do not have a job title at all
Now you will notice that the validates_length_of method accepts a list of variable size for the list of attribute symbols to check and then at the end an option hash to specify length checking specifics. How does the method know there is an option Hash at the end to use for these things and/or how long the list of attributes is? The secret is in the sauce. If we were to look in the source code (though I am not, because I have seen it so many times before), we would see something like:

def validates_length_of(*attrs)
  options = @@DEFAULT_OPTIONS.merge(attrs.pop.symbolize_keys) if attrs.last.is_a?(Hash)
  # then continue with rest of implementation.
end
All it is doing here is in the signature, specifying that there is a list of unknown length to be supplied to the method. Then it pops the last item off that list (Array) if and only if the last element of the list is a Hash for use as the options that the implementation will use. Until the next time enjoy Ruby's "transparent" Hash idioms.

Ruby Idioms, Part 6

Written on 10:28:00 PM by S. Potter

Tonight I remembered couple more idioms in Ruby and felt compelled to share. In Javafied Ruby code (below) we often see something like the following:

if something
  for role in user.roles
    return true if @@roles.include? role
  end
end
Now when I first started writing Ruby code almost 3 years ago, I thought looping through a collection like above was the nicest way. I quickly found Ruby like the following snippet in code I inherited:
user.roles.each do |role|
  return true if @@roles.include? role
end
At first it took me some time to understand it (remember I was just a poor Java developer with a little Python experience), and I wondered why people would write loops this way. At the time it made no sense. Using this form of looping in Ruby does somewhat violate my "reads more like natural language" coding style preferences, but for some reason this form of looping is now the only one I use in Ruby code. Despite this violation, it feels much more natural. If you are unsure about this yourself, I would encourage you to look into the power of blocks in Ruby. Once you fully appreciate blocks, I think you might be persuaded, (though different opinions make this world more colorful and less bland). The second Ruby idiom is less odd and does enhance code readability more like natural language (again in my opinion):
user.roles.each do |role|
  return true if @@roles.include? role
end if something
Usually when people are having a conversation in English (at least native English speakers), we tend to say things like: We need to verify at least one role the user belongs to is in a pre-defined list of roles if [something]. Non-techies tend to say "if something" at the end of sentences, not at the very beginning (at least this is my experience). So for this reason I think this idiom enhances readability of the code to be more like natural English. For those that start every sentence that contains a conditional with the conditional clause, you have probably been a developer for far too long - go be a beach bum to save yourself before it is too late.

Ruby Idioms, Part 5

Written on 7:43:00 PM by S. Potter

Some of you may say this isn't strictly an idiom, but it is dependent on Ruby's core API and classes, so I have included it. Ranges are a very nice low-level abstraction and can save Ruby developers a lot of time for certain coding needs. In a previous idiom example on this blog I had a list of positive odd numbers under 7. Well typing this out by hand is hardly consuming so I typed [1, 3, 5] by hand. However, say we wanted to check if a number given by the user is an odd number under, say, 1001. How can we do that in as few lines of code, while still maintaining or even enhancing code readability? Look no further:

ls = []
(1...1001).step(2) {|x| ls << x} #=> [1, 3, ..., 997, 999]
For Java heads that don't understand blocks - too bad that is out of the scope of this blog entry:) Go and do you homework then revisit. Google should be able to help you out in this regard. Of course, Ruby developers could and would debate whether my solution above is the "best", concerning how terse and readable it is since there are so many ways of doing this that provide a decent solution. There may even be another solution in the Ruby universe I may prefer, but at present this maintains readability to a high standard (assuming you understand blocks, of course), again in my opinion. I may even expand the code as follows to make it truly readable:
ls = []
(1...1001).step(2) do |x|
  ls << x
end #=> [1, 3, ..., 997, 999]
What are a couple of extra lines to make something as readable as possible anyway?

Ruby Idioms, Part 4

Written on 7:36:00 PM by S. Potter

To splat or not to splat, that is the question. In Java to unpack an array's values into separate variables you would need to do something like the following:

burgers = [:hamburger, :bocaburger, :gardenburger, :turkeyburger]
t = burgers[0]
u = burgers[1]
v = burgers[2]
w = burgers[3]
In the Ruby mindset this would look more like the following:
burgers = [:hamburger, :bocaburger, :gardenburger, :turkeyburger]
t, u, v = *burgers # t=>:hamburger, u=> :bocaburger, v=>:gardenburger
t, u, v, w = *burgers # t=>:hamburger, u=>:bocaburger, v=>:gardenburger, w=>:turkeyburger
t, u, v, w, x = *burgers # t=>:hamburger, u=>:bocaburger, v=>:gardenburger, w=>:turkeyburger, x=>nil
Think of * (or splat) as the Ruby way of unpacking the elements of an Array into separate variables in Ruby. This brings me to an even nicer example. Many moons ago, when I was working on a Java/J2EE project, I found a piece of code that looked something like the following (except it has been Rubyfied for this blog entry so that I do not get sued for sharing outrageously fantastic proprietary code with the public - ok, ok....even lawyers would understand this couldn't be called outrageously fantastic even in a parallel universe):
class RunnableWithParams << Thread
  def initialize(param1)
    @param1 = param1
  end

  def initialize(param1, param2)
    @param1 = param1
    @param2 = param2
  end

  def initialize(param1, param2, param3)
    @param1 = param1
    @param2 = param2
    @param3 = param3
  end

  def run
    # some code the uses param1, param2, etc. - in Java this was an empty method body or abstract  - can't remember
  end
end
Rubifying the the code sure does take some of the sting out of it, but you can probably still feel my initial pain when I realized what kind of code I was inheriting. The class name and the variables are in fact the same as the original code. The problem this tried to solve, which I suppose it did solve in a stupid way, was to allow Java code to pass parameters over to the thread's logic (which, at least, at the time was not possible to do) in the context of an anonymous class implementation of the method. Now if you wanted to pass in 4 parameters, you were out of luck OR you had to beg the core framework people to add that constructor OR you had to do an ugly JAR patch hack and put your own implementation of RunnableWithParams class ahead of the core framework JAR in your CLASSPATH. They were all pretty ugly scenarios. Of course, you could pass in a List or Map instance, but that really isn't the point. The most obvious optimization to the code from a readability, extensibility and utility perspective would be to pass in a list to the class's constructor and use elements in the list in the run method logic. However, Ruby provides a nicer way of doing things from the perspective of the client code:
class RunnableWithParams << Thread
  def initialize(*params)
    @params = params
  end
  def run # needs to be defined by clients
  end
end
The client code for using this class would look like the following:
rwp = RunnableWithParams.new param1, param2, param3, param4
# instead of the initially optimized suggestion, where the client code would look like the following
rwp = RunnableWithParams.new [param1, param2, param3, param4]
In my view the first line of the snippet above is slightly superior because it is more natural in the way it reads. Again, different people will have different views on this perhaps, but both lines of code provide a decent solution.

Ruby Idioms, Part 3

Written on 7:32:00 PM by S. Potter

Now, probably the biggest difference after the syntax, and the non-static nature of Ruby for Java heads to get used to is that Ruby is an "expressionist" language. Meaning almost all statements in Ruby evaluates to a value, i.e. everything that reasonably can be is an expression in Ruby is. This is definitely not the way Java thinks or works. So this will take some adjusting to. Don't worry I will show you an example. Now the Javafied Ruby code we will optimize is shown below:

user_id = nil
if comments
  if comments.first
    if comments.first.user
      user_id = comments.first.user.id
    end
  end
end
Now that is some ugly code, but sometimes doing something equivalent to that in Java is very necessary. So how would a true Rubyist write that code:
user_id = comments && comments.first && comments.first.user && comments.first.user.id
Now let us walk through what this really does.
  1. comments is evaluated, if it is nil, then the value nil is returned, the boolean expression is exited out of (because it is all &&'s and fails at the first condition, thus the whole boolean expression fails) and nil, which was the last value evaluated in that expression is set to user_id. This is the same outcome that would have occurred in the first code snippet.
  2. We repeat the process of the previous step for comments.first, comments.first.user and finally comments.first.user.id until either nil is encountered and set as the value of user_id or the final part of the boolean expression evaluates to a non-nil value and that value is set to the value of user_id.
Do you follow? If not, reread through things again, because it should eventually make sense after a while. So this Ruby "optimization" goes against my philosophy of producing code that reads as much like natural language as possible. For the better more elegant, natural way to solve this, refer to my previous blog entry on Rubyisms: Forwardables, which talks about how to make evaluating attributes on attributes on attributes of your given object a thing of the past in a more elegant way. This isn't, however, an idiom, since it is not a specific construct of the Ruby language that provides this utility.

Ruby Idioms, Part 2

Written on 7:21:00 PM by S. Potter

Now the "idiom" we will use is not specific to Ruby, since I am pretty sure Perl has one of the constructs we will use to solve the stated problem, but it is still idiomatic, since the majority of popular OO languages (static, dynamic or otherwise) do not have it (as far as I know). Also some consider this to be a sub-optimal idiom, because there is a terser way to do something like this. However, the idiom I recommend below is much more multi-purpose, though I will show the terser version for the trivial case. Firstly our Javafied Ruby code looks like the following for the problem at hand:

if not var
  var = "some text string"
end
# OR for a pure Java to Ruby translation with ZERO Rubification
if nil == var # of course "if var == nil" is equivalent too.
  var = "some text string"
end
Now this is the most trivial case of wanting to set a variable to a value only when it is nil. The Ruby idiom I advocate is much more multi-purpose than this trivial case, but there is an even terser Ruby idiom that is only applicable to this case, which I wanted to show you first. See below:
var ||= "some text string"
As you can see this is very terse, but my question is, is it readable? Well to many Rubyists it is, but this relies on expressionistic understanding of how Ruby works under the covers. On projects involving developers with varied skill levels, I would definitely prefer my proposal below. Now onto the more readable and more multi-purpose idiom that reads much more like my natural language (which is my preference in general):
var = "some text string" unless var
Now some of you may think this isn't as readable as it could be, I concur. I sometimes prefer to use something like the following, but consistency on a project is important in my view, so pick on and go with it:
var = "some text string" if var.nil?
Again it reads more naturally, at least to an English speaker. But I will admit I have found myself using the terser "or equals" idiom in favor of the above for the trivial case (but consistently on projects with other advanced Ruby developers). However, the "if var nil?" idiom can be used in more multi-purpose situations, not only when you wish to set a variable when it has a nil value (that is null to you Java heads). A non-trivial usage of the "unless" version of the idiom would be well suited to a code snippet that tries to do the following:
user_defined_fruits = ['apple', 'cantaloupe']
fruits = ['apple', 'banana']
user_defined_fruits.each do |fruit|
  if fruits.include? fruit
    fruits << fruit
  end
end
fruits #=> ['apple', 'banana', 'cantaloupe'] NOT ['apple', 'banana', 'apple', 'cantaloupe']
Now a better way of doing this with the "unless" version of the idiom would be:
user_defined_fruits = ['apple', 'cantaloupe']
fruits = ['apple', 'banana']
user_defined_fruits.each do |fruit|
  fruits << fruit unless fruits.include? fruit
end
As you see above the code is terser, while being as readable, if not more (in my opinion again). To me it feels much more like my natural language, which in my view is the thing to aim for. Again the as-terse-as-possible enthusiasts will love the following:
user_defined_fruits = ['apple', 'cantaloupe']
fruits = ['apple', 'banana']
fruits |= user_defined_fruits

Ruby Idioms, Part 1

Written on 7:16:00 PM by S. Potter

With more people moving to Ruby everyday from languages like Java, I wanted to create blog entries on the most common Ruby idioms (especially ones frequently found in Rails core or Rails application code) and briefly explain how to convert your Java mindset to Ruby (over time). This is the first installment. First let us inspect what we might do in Java (converted to Ruby syntax) when determining if a value passed in equals various fixed values:

if val == 1 || val == 3 || val == 5
  puts "hello odd number under 7"
end
Rubyists will know this is really ugly, so our first attempt at Rubifying the code above would probably look like:
if [1, 3, 5].include? val
  puts "hello odd number under 7"
end
Of course, one-liner fans should note you can also do the following:
puts "hello odd number under 7" if [1, 3, 5].include? val
include? is an instance method on Array (which is a builtin Ruby class - remember all first class citizens in Ruby are classes [or more technically, modules]). In Ruby developers use "?" postfixes in method names as a way to letting clients of the method know it should return a true or false value. I described the unwritten/unofficial Ruby conventions and guidelines for naming in a previous blog entry Rubyisms: Naming Conventions This first attempt is fairly nice, because it makes (in my opinion) the code more readable and more like my natural language, English. Now it doesn't quite read as well as it could, so let's try again:
class Array
  alias :includes? :include?
end

if [1, 3, 5].includes? val
  puts "hello odd number under 7"
end
# OR the one-liner version
puts "hello odd number under 7" if [1, 3, 5].includes? val
The code snippet above reopens a class in Ruby, a facility I describe in a previous blog entry Rubyisms: Reopening Classes. You should refer to that for more information. Now some may be saying, "this is terrible...you have converted a 3 line code snippet into 6." Well not exactly. The reason is, the first three lines just need to be put in a ruby file to extend the Array class just once in the whole application, library or framework and you can use the aliased method, includes?, as many times as you like throughout the code base with not a care in the world. Of course there are a variety of ways to change the code to be more readable as per your opinion of code readability, but I'll leave that as an exercise for the reader. Ruby's core Range class could be used to generate an array of odd (or even) numbers under a specific number. Another blog entry will deal with this.