72 Virgins

Sometimes things are not always what they seem..

Lines of Code

Shakespeare’s sonnets have exactly 14 lines, his plays have usually around 2600 lines (Hamlet about 4000 lines). This is not that different from the few thousand lines of code a typical programmer writes for a unit, library or project, for example jQuery 1.2 and 1.3 have around 4000 LoC (jQuery 1.2.6: 3549 LoC, jQuery 1.3.2: 4376 LoC). It is well-known that progress and productivity cannot be measure in lines of code. Yet the order of magnitude is often quite similar in completely different projects and environments, because there is a limit what people can handle and produce.

The order of magnitude for the typical lines of code is as follows. A single programmer working a few days will usually produce some functions, methods and classes more or less rapidly, depending on his experience. If he is working a few months he will produce typically a few thousands lines of code. This is an amount a single person can still understand well, and it can still be customized and changed easily:

• function/method: 10 = 10^1 LoC/Method
• class: 100 = 10^2 LoC/Class
• library or small project: 1000 = 10^3 LoC/Project

A few programmers together working a few months will produce about 10^4 lines of code. This is an order of magnitude where it is becoming difficult for a single developer to understand and comprehend the complete code base if it is not well structured. According to DHH, Rails on Rails 2.3 has currently about 35.000 LoC (without tests and comments). A large framework requires about 10^5 lines of code. A complete operating system belongs to the largest software projects, it requires about 10^6 – 10^7 lines of code, Microsoft Windows 2000 for example is said to have around 50M lines of C++ code or ~5GB of data:

• a small framework or large application: 10.000 = 10^4 LoC/Framework
• ide/framework: 100.000 = 10^5 LoC/Framework
• operating system: 10.000.000 = 10^7 LoC/OS

For comparison only, a human has around 30,000 genes (~3.1B base pairs ~ 1.5GB).

Longing for World Domination

As a computer programmer or software developer, you long each day for world domination. To be precise, you stagger constantly between world domination (in German “Weltherrschaft”) and total powerlessness, between absolute might and complete plight, between omnipotence and complete impotence. One day you feel like a mighty emperor, and the next day you feel like a powerless subject. Here’s why:

In the world of your own software, you are the lawgiver with absolute power and undisputed authority. This means world domination: everything follows your command without the slightest kind of opposition or resistance. The programmer determines in detail what every object, every class and every function should do, step by step, in every possible situation and in every possible context.

“The computer programmer is a creator of universes for which he alone is the lawgiver…No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or a field of battle and to command such unswervingly dutiful actors or troops.”
(Joseph Weizenbaum)

The programmer and developer is the ultimate commander. Ideally he can create a whole application with only a few lines of code, he can create worlds with his fingertips. That’s the fun part. Yet despite all this power, and no matter how smart you are, as a programmer you will typically trying to understand what is going on most of the time. The problem is you usually use a lot of code from others – plugins, modules, units, libraries, frameworks – which you do not and can not understand completely. Even your own legacy code from the past is sometimes difficult to understand. Debugging foreign code is like walking around in a foreign city without a map. You don’t know how everything is connected, where the center is, or where everything leads to.

And there are always bugs around the corner waiting to be solved. Bugs belong to software like explosions to rockets. Rockets are based on controlled gas flow which results in explosions. Software is based on controlled program flow which results in features and bugs: there is saying that “the only difference between a bug and a feature is the documentation.” If debugging is the process of removing software bugs, then programming must be the process of putting them in.

Because there are always code parts which he doesn’t understand or bugs which he is trying to solve, a programmer gets often completely stuck, and falls into total powerlessness, until he is able to find out what happened. For a programmer, it is extremely important to find out what happened: either by examining existing or newly created log files, or by debugging (that is by stepping through the code bit by bit). Once a bug has been identified and located by logging and debugging the code, it is often easy to remove it, and the programmer is ready to dominate the world again.

This is why programmers stagger constantly between world domination and total powerlessness. Programming is 20% world domination and 80% frustration. Unfortunately, the frustrating times prevail, but the world domination times compensate for everything.

(The Flickr photo is from the user Toni Villen)

Holidays

I am on holiday for the next weeks

Charts and Graphics

We know that a picture is worth a thousand words. A few charts can indeed improve any application and presentation..

..sometimes it works too well:

Object matching in Ruby

Often one must traverse a list or array of items to find and return the first instance with a certain property, attribute or id. For pattern matching in strings or texts, one would use regular expressions. For object matching in lists or arrays, usually one would write a function like this:

result = nil
instances.each do |instance|
  if instance.id == _id
    result = instance
    break
  end
end

With the detect method of the Enumerable module in Ruby this is quite easy. It returns the first object for which the passed block is true, for example the first element which is divisible by 5 and 7:

instances.detect{|instance| instance.id == _id}

(1..100).detect {|i| i % 5 == 0 and i % 7 == 0 }
=> 35

Error

From the Daily WTF:: an error in an error message:

this is also great: the word of the day

Eval, module_eval, and instance_eval

As a dynamic script language, Ruby provides a few different options to evaluate a string or a block of code: eval, class_eval, module_eval, and instance_eval. What is the difference between them? This article describes it well. The main different is the context: instance_eval evaluates in the context of a certain instance, module_eval (and class_eval) in the context of a class, and eval in the current context or the context of the given binding.

instance_eval

Object.instance_eval evaluates a string (or the given block) within the context of a certain class instance and allows thus the direct access to class properties without attr or attr_accessor. It allows you to define new methods for a instance

class Klass
  def initialize
    @secret = 99
  end
end
k = Klass.new
k.instance_eval("@secret")    # => "99"
k.instance_eval("@secret=42") # => "42"

k.instance_eval("def hi() \"Hello there\" end")
k.hi()  # => "Hello there"

eval

Kernel.eval evaluates a string in the current context or the context of the given binding. It is the method used by IRB to process your input. It allows you to define new variables and methods for the current context.

def secret(number)
  return binding
end
number = "42"
eval "number"                #=> "42"
eval "number", secret("99")  #=> "99"

eval "def hi() \"Hello there\" end"
hi()  # => "Hello there"

module_eval

As the name says, Module.module_eval evaluates the string or block in the context of a module or class (Synonym: class_eval). module_eval allows you to define new instance method for a class.

String.module_eval do
  def secret
    "42"
  end
end

"string".secret    #=> "42"

MBAs from Top Business Schools

Dilbert has got the point again, here is a nice cartoon about MBAs:

and a follow-up here

DSL for Finite State Machine (FSM)

In an introductory chapter about DSL, Martin Fowler mentions the state machine model. Now here is how you can implement a simple finite state machine. A FSM DSL can be defined for example like this (if we assign states, the first state is used as an initial value):

class StateMachineDSL
  attr_accessor :state

  def initialize
    @states, @events = [], {}
  end

  def states
    @states
  end

  def states=(values)
    @states, @state = values, values.first
  end

  def event(name, transition)
    @events[name] = transition
    self.class.send(:define_method,"#{name}!") { change_state(name) }
  end

  def transitions
    @events.reject{ |key,value| !value.keys.include?(@state.to_sym) }.keys
  end

  def change_state(event)
    @state = @events[event][@state]
  end
end

If we use the block technique mentioned before to apply the DSL in Ruby, we get the following class:

class MyClass
  def self.apply_dsl(a_class, &block)
    obj = a_class.new
    yield obj if block_given?
    return obj
  end
end

Finally, the FSM can be defined in the DSL:

obj = MyClass.apply_dsl(StateMachineDSL) do |state_machine|
  state_machine.states = [:submitted, :reviewing, :accepted, :rejected]
  state_machine.event :submit, {:submitted => :reviewing}
  state_machine.event :accept, {:reviewing => :accepted}
  state_machine.event :reject, {:reviewing => :rejected}
  state_machine.event :revise, {:rejected => :reviewing}
end

obj.state
=> :submitted
obj.submit!
=> :reviewing
obj.accept!
=> :accepted

DSL in Ruby

A Domain Specific Language (DSL) is a computer language targeted to a particular kind of problem or application domain. There are various ways to implement a DSL in Ruby: classic blocks, instance_eval or mixins and extend. Most often instance_eval is used. How does it work? First one has to define the DSL itself, for example in a class like the this:

class MyDsl
  def initialize
    @local_var = 1
  end

  def method_1
    puts "#{@local_var}+1=#{@local_var += 1}"
  end

  def method_2
    puts "says your DSL method"
  end
end

then one can apply the dsl to an object:

MyClass.apply_dsl(MyDSL) do |obj|
  obj.method_1()
  obj.method_2()
end

We only need the define an “apply_dsl” method. The first option is to use simple Ruby blocks to apply the DSL:

class MyClass
  def self.apply_dsl(a_class, &block)
    yield a_class.new if block_given?
  end
end

The second option is to use instance_eval to apply the DSL:

class MyClass
  def self.apply_dsl(a_class, &block)
    dsl = a_class.new
    dsl.instance_eval &block if block_given?
  end
end

Or one can use mixins and extend..

class MyClass
  def self.apply_dsl(a_module)
    obj = MyClass.new
    obj.extend(a_module)
    obj.init
    yield obj if block_given?
  end
end

but then one would use modules instead of classes:

module MyDSL
  def init
    @i = 1
  end

  def method_1
    puts "#{@i}+1=#{@i += 1}"
  end

  def method_2
    puts "says your DSL method"
  end
end

Blocks, procs, and arguments in Ruby

Understanding Ruby blocks, Procs and methods is not easy for a Ruby beginner, especially if Procs and Lambdas are involved. Yet the basic elements are simple, as Matz says, blocks are basically nameless functions. You can pass a nameless function to another function, and then that function can invoke the passed-in nameless function.

An ampersand in a function is a good hint for such a process. Ruby on Rails functions often have arguments which start with stars (*args) or ampersands (&block). In C programming, the * marks a pointer to a variable, while & is used to get the address of a variable. In Ruby, the splat operator * turns a list of arguments in an array, and the ampersand & marks a reference to a block which is passed to a method.

It is important to understand both methods if you want to write advanced Ruby functions using blocks, for example to use Ruby blocks for custom tags. The following analyzer example takes a list of arguments and a code block, and logs the effect of the code in the block for each argument:

def analyzer(*args, &block)
 args.each { |arg| puts "#{arg} is "+block.call(arg) }
end

>> analyzer(1,2,3,4,5) { |i| (i % 2 == 0) ? "even" : "odd" }
=> 1 is odd
=> 2 is even
=> 3 is odd
=> 4 is even
=> 5 is odd

If we define

  array = (1..5).to_a
  number_type = lambda { |i| (i % 2 == 0) ? "even" : "odd" }

then the following lines of code are equivalent and result in the output above:

  analyzer(1,2,3,4,5) { |i| (i % 2 == 0) ? "even" : "odd" }
  analyzer(1,2,3,4,5, &number_type)
  analyzer(*array, &number_type)

Blocks in Ruby are often functions which are passed to variables (contrary to parameters in methods, which are variables passed to functions). As we can see, the uses of & and * as a prefix are different for function definitions and calls: in definitions they have a capturing effect, but in calls their effect is expanding:

• in a function definition, for example def analyzer(*args, &block),
  & captures any passed block into that object
  * captures any arguments into an array
• in a function call, for example analyzer(*array, &number_type)
  & expands the given callback object into a block
  * expands the given array into a list of arguments

Therefore if we want to pass a proc or lambda object instead of a block to a function, we have to expand it with &:

>> sum = lambda { |x,y| x+y }
=> #(Proc:..)

>> array = (1..5).to_a
=> [1,2,3,4,5]

>> array.inject &sum
=> 15

By the way the following lines of code are equivalent, too. The shortest way to sum an array is obviously the last one:

[1, 2, 3, 4, 5].inject { |x,y| x + y  }
(1..5).inject{ |x,y| x+y }
(1..5).inject(&:+)

Nil or Empty

Do you use statements like

 .. if !name.nil? && !name.empty?
 .. if params[:name] and !params[:name].empty?

in your code? Using the blank? function of Rails, they can be simplified to

 .. if !name.blank?
 .. if !params[:name].blank?

But we can go even further. Using the present? function, this is equal to

 .. if name.present?
 .. if params[:name].present?

See the documentation for the class object: an object is present if it‘s not blank. An object in Rails is blank if it‘s false, empty, or a whitespace string. That means “”, ” “, nil, [], and {} are blank.

Adopt a toilet

Another great Dilbert cartoon:

$(document).ready vs. $(window).load

jQuery offers two powerful methods to execute code and attach event handlers: $(document).ready and $(window).load. The document ready event executes already when the HTML-Document is loaded and the DOM is ready, even if all the graphics haven’t loaded yet. If you want to hook up your events for certain elements before the window loads, then $(document).ready is the right place.

$(document).ready(function() {
 // executes when HTML-Document is loaded and DOM is ready
 alert("document is ready");
});

The window load event executes a bit later when the complete page is fully loaded, including all frames, objects and images. Therefore functions which concern images or other page contents should be placed in the load event for the window or the content tag itself.

$(window).load(function() {
 // executes when complete page is fully loaded, including all frames, objects and images
 alert("window is loaded");
});