A software developer by the name of Gustavo Duarte wrote something quite fascinating last month on Reality-Driven Development. Apparently, his writing drew many Slashdot readers to his humble blog.

In his post, Duarte draws from such disparate sources and ideas as physicist Richard Feynman’s thoughts on the Challenger disaster, natural selection, a linux discussion thread, the book Built to Last, and others to make his case for what he calls Reality-Driven Development.

Duarte says that “reality is invited in via experiments” and defines Reality-Driven Development thusly:

A good software development process should optimize experimentation and improve feedback from reality. This is what I mean by reality-driven development. And in software the most important realities are user experience and technical quality, while the primary experiments are working software and code.

He criticizes big up-front design:

And rigid upfront design is a sure way to a crappy code base or engineering disasters. Alistair Cockburn put it best: “With design I can think very fast, but my thinking is full of little holes.”

He also casts Agile development techniques in an interesting light:

There is no specific reality-driven methodology. The Agile principles have a lot in common with these ideas (and certainly influenced them), but the devil is in the details. I prefer to think of software engineering in terms of a toolbox, full of techniques we pick and choose for the right situation. Process tools for optimizing experimentation include iterative development, executable architecture, continuous integration, and unit testing.

It’s difficult to summarize all the juicy tidbits. Reading the entire post is well worth the time.

I gave a talk at Calvin College last Thursday for a joint meeting of the Michigan Ruby Users Group and the Grand Rapids Java User’s Group.

My topic was using the Java integration features in JRuby. I’ve posted the slides here. If you didn’t attend you may find the slides a little terse. Nobody likes reading from slides, which often means that the resulting slides aren’t very informative for absentees.

After a brief introduction of using Java integration, I addressed a few of the tricks we learned while developing a large desktop application in JRuby from the ground up. This includes calling Java libraries, overriding Java classes, including functionality from Java into your Ruby classes, and how to make the Java API more ruby-like. Probably the most useful hint is the diagram and pointer to our technique for bundling JRuby apps into a monolithic jar.

There’s much more to Java integration than I have here; I only discussed the things that were ambiguous in the existing documentation or difficult to nail down. Comments are welcome so feel free to ask questions about the scanty slides.

I came across a problem on project where trying to create a new record with a string attribute that ends in \ (backslash) was causing an OLE error to pop up through the DBI driver.

  DBI::DatabaseError: Execute
       OLE error code: 80040E14 in Microsoft OLE DB Provider for SQL Server
          Incorrect syntax near '\'.
       HRESULT error code:0x80020009
          Exception occured.: INSERT INTO completables ([project_id], [type],
                 [description], [completion]) VALUES(2, 'Deliverable', 'bar\', 0)

This happens with Rails 1.2.3 running on Windows Server 2003 talking to SQLServer 2005 using ruby-dbi 0.0.23 and version 0.1 of the ADO driver.

Normally SQLServer allows backslashes anywhere in a string. It uses a single quote as an escape for a single quote. But for some reason a backslash at the end of a string is treated differently.

The following bit of code put into environment.rb will replace backslashes with calls to CHAR. 92 is the ASCII value of backslash.

1
2
3
4
5
6
7
8
9

module ActiveRecord
  module ConnectionAdapters
    class SQLServerAdapter
      def quote_string(string)
        string.gsub(/\'/, "''").gsub(/\\/, "' + CHAR + '")
      end
    end
  end
end

VMware’s free VMware Server product ships with several command line utilities for controlling the server; the vmware-cmd program, in particular, offers control over starting, stopping, registering, and what not on virtual machines. vmware-cmd is a little clunky to use, though, because it requires an absolute path to the virtual machine’s vmx file. And it only works against one virtual machine at a time.

1. list: lists what virtual machines are running
2. register: registers a virtual machine
3. reset: resets a virtual machine
4. start: starts a virtual machine
5. stop: stops a virtual machine
6. unregister: unregisters a virtual machine
7. what_is_registered: lists the virtual machine registered on this server
8. what_is_not_registered: lists the virtual machines in the virtual machine directory that are not registered

The register, reset, start, stop, and unregister commands all take a list of virtual machines to act against. For example: “register piggy” will register the piggy virtual machine “stop beaker piggy tortoise” will stop the beaker, piggy, and tortoise virtual machines

1. VMware server installed and running on Linux. I doubt the scripts will work on Windows.
2. Ruby installed and on your path
3. Edit the vmx_control.rb file and change the VmLocation constant, at the top, to contain the location your virtual machines are installed in.

These scripts are unsupported. They are made to work best with my workflow, so if my workflow does not match yours, then modify the scripts however you’d like to make them work best for you.

Download link: vmx_controltar.gz

Recently, some of us at Atomic Object have been providing a small video that demonstrates any new features that we have implemented for our customers. It has been proven to be an effective technique when a customer has either been remote, busy, or traveling. Video demonstrations are also effective when the project is so small that setting up a weekly meeting with the customer is not plausible. However, even when the customer is readily available and is an active participant in the project, having these small video demonstrations can prove useful when they would like to show his/her coworkers a particular feature.

Surprisingly, the amount of effort you, as the developer, has to put forth actually decreases and customer satisfaction increases. A video demo is easy to make and it provides a “to the point” and a clear representation of the features. The customer can easily download and view the video in a matter of minutes. Because the features are being demonstrated and focused on; the customer can provide feedback quickly about what they like or dislike.

Most customers have other jobs and cannot focus solely on your project. Because of this, they may not have the time to download, launch, or try out new features. (Especially if it is 4:30 p.m. on Friday.) A small video demonstration makes life easy for the customer and it focuses them on what matters.

Another, not so obvious benefit, is how the video could quickly become viral and propagate to other end-users. For example, we had a small, tightly-scoped project that got a good deal of feedback in a short period of time, due to the amount of people that were able to view it. This enabled us to make tweaks and adjustments quickly without “burning up the budget.”

There are two tools that I know of that can do screen video capturing. Snapz Pro is my choice for MacOS X, it is easy to use and relatively inexpensive. I do not have any experience using screen capturing on Windows. However, when I did a google search, TechSmith popped up a few times and it appears to have some nice screen capture tools.