My friends at Citerus put together a great newsletter. If you don’t mind reading through a little Swedish intro (the content is mostly in English), I’d highly recommend subscribing.

From a recent interview with Jerry Weinberg in their newsletter:

Q: You seem pretty relentless about quality, why is quality so important to you?

A: Because if you don’t care about quality, everything else is trivial. (I call this The First Law of Software Engineering.) You need to ship on a certain date? If you don’t care about quality, you just ship. You need to cut costs? If you don’t care about quality, you just stop when you run out of money. You need to boost morale? If you don’t care about quality, you do whatever your people want. (Oh, wait a minute. What if they want quality, even if you don’t care? You want to destroy a professional software organization. Act as if you don’t care about quality. The professionals will leave, either physically or psychologically.)

So, that’s why quality is so important, not just to me, but to our industry. And, until we start caring, we’re not going to get better. And I know we can get better, because when I’ve worked with clients whose entire business (or people’s lives) depends on quality, they produce quality software. Curiously, it turns out that quality software is cheaper in the end, but if you’re not into long-term thinking, you won’t see that.

While refactoring some ruby code the other day I found myself wanting respond_to-like functionality. Specifically, I was calling a function that would have one of several possible outcomes, and I wanted to handle each in a clean way. Specifically, I wanted syntax like this:

1
2
3
4
5
6
7
8

zebra array do |row|
  row.even do |element|
    puts "even #{element}"
  end
  row.odd do |element|
    puts "odd #{element}"
  end
end

I put together a bit of code for doing this, called Multiblock. You could write zebra, with a Multiblock, like so:

1
2
3
4
5
6

def zebra(list)
  list.each_with_index do |element, index|
    odd_or_even = [:even, &odd][index % 2]
    yield Multiblock[odd_or_even, element]
  end
end

Here’s the source code for Multiblock:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class Multiblock
  def self.[](*args)
    new *args
  end

  def initialize(*args)
    _expect *args unless args.empty?
  end

  def [](*args)
     _expect *args
     self
  end

  def method_missing(name, *rest)
    if !@matched
      @matched = [@waiting_for, :else].include? name
       if @waiting_for == name
          @result = yield *@args
       elsif :else == name
         @result = yield @waiting_for, *@args
       end
     end

      @result
  end

  private

  def _expect(waiting_for, *args)
    @waiting_for = waiting_for.to_sym
    @args = args
    @result = nil
    @matched = false
  end
end

Wouldn’t it be nice if you could evaluate arbitrary javascript in the context of your Rails application’s window when testing it with Selenium? Well, you already can. What Selenium doesn’t do for you, however, is automatically serialize the result of your computation to JSON, then deserialize that JSON into a convenient ruby object. What I want to do is stuff like this:

1
2
3

# get the center of the page's google map 
lat, lng = get_json "[c.lat(), c.lng()]",
        :c => "googleMap.getCenter()" 

or

1
2

positions = get_json "{foo: $('foo').offsetLeft, bar: $('bar').offsetLeft}"
assert positions['foo'] < positions['bar'], "bar was too far to the right"

Here’s the definition of get_json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

   # evaluate arbitrary javascript in the context of your page. 
   def eval_js(code)
     get_eval <<-JS
       selenium.browserbot.getCurrentWindow().eval("#{
         code.gsub('"', '\\\\"').gsub("\\n"," ")
       }") 
     JS
   end

   def get_json(code, objects={})
     entries = objects.entries
     ActiveSupport::JSON.decode(
       eval_js("
         Object.toJSON(
           (function(#{entries.map (&:first).join(', ')}){
             return #{code};
           })(#{entries.map(&:last).join(', ')})
         )
       ")
     )
   end

We are, after all, Atomic Object…

A gallery of products using radioactive materials.

Because radiation was seen to be new and powerful, at the beginning of the 20th century radioactive material was used in products such as face creams, mineral water and medicine, by equating power with rejuvenation. For similar reasons it was even used in items from spark plugs to condoms.

I was struck recently by how rarely software developers and project managers really analyze software development expenses.

Ever been part of a discussion about purchasing a third party library? Ever considered whether to automate a particular task? How often have you or anyone involved estimated how much money the library purchase or automation would save in comparison to the needed developer time?

Is JRuby a realistic candidate for authoring complex desktop applications?

Yes.

UPDATE (Jan. 30, 2009): Our client has cleared us to spill our guts on the details of the project discussed here now that it’s complete… Ruby for Desktop Applications? Yes we can.

About a year ago Greg Pattison and I began working together on a new C++ application for a client. It was the first C++ project of any significant size for either of us since becoming enamored with interaction-based testing techniques.

I’ve just given this presentation at Rubyconf 2007. And now you can enjoy it too:

Keynote file: Enhancing Embedded Keynote

PDF version: Enhancing Embedded PDF

Video: Full Video from Confreaks

Taking a string and splitting it with a delimiter is a very common task in Ruby. The official documentation states that String#splitdivides str into substrings based on a delimiter, returning an array of these substrings.

The delimiter itself can be a string or regular expression:

1
2
3
4
5
6
7

#string delimiter
"hello".split('')                #=> ["h", "e", "l", "l", "o"]
"hello".split('ll')              #=> ["he", "o"]

# regular expression delimiter
"hello".split(//)               #=> ["h", "e", "l", "l", "o"]
"hello".split(/l+/)            #=> ["he", "o"]

String#split takes an optional second parameter representing a limit. From the String#split documentation:

If the limit parameter is omitted, trailing null fields are suppressed.

If limit is a positive number, at most that number of fields will be returned (if limit is 1, the entire string is returned as the only entry in an array).

If negative, there is no limit to the number of fields returned, and trailing null fields are not suppressed.

Here are some examples of how the limit parameter works:

1
2
3
4
5
6
7
8
9

# omitting the limit
"1234 1234".split('4')          # =>["123", " 123"]

# positive limit
"1234 1234".split('4', 1)      # => ["1234 1234"]
"1234 1234".split('4', 2)      # => ["123", " 1234"]

# negative limit<code>
"1234 1234".split('4', -1)      # => ["123", " 123", ""]

These examples have been short and simple and in my experience the common usages of String#split will be. When you start to go beyond the short and simple you will find some behavioral oddities with String#split and it will always be with regular expression delimiters.