Atomic Spin - Home

Rolling a JRuby desktop application

2008-07-02T17:46:00Z

Atomic has been using JRuby, several Java libraries, and Jar Jar Links to distribute five different Ruby desktop applications (read: not Rails applications) as single, executable jar files. In this article, I will show how we:

Work on our application as developers
Distribute our application as a single jar file to our users
Compile the Ruby source files into Java class files
Integrate third-party Ruby and Java libraries

This article includes an example project that demonstrates all of the above.

The example is our old friend Hello World. A tarball and zip file are available here:

This article will read best if you can download the example and follow along, but I will include some code snippets so that you can gather the main ideas even without the example.

I’ll start by discussing the project layout. It is meant to be similar to a normal Ruby project—there’s a Rakefile at the top level, a lib directory for Ruby files, and a vendor directory for third-party libraries (though I think having a vendor directory may be a Railsism, not necessarily a Ruby thing). In this case, I’ve got a couple of Ruby files in the lib directory, a Java library and a Ruby library in vendor, and all of JRuby 1.1.2 in vendor as well.

The Java library I’ve chosen to use is SwingX from SwingLabs. SwingX includes some nice Swing widgets that don’t ship with Java. In the sample application, I’m going to use the JXDatePicker widget. The swingx-0.9.2.jar is hanging out in the top level of the vendor directory.

Constructor is a Ruby library we use at Atomic for simplifying the declaration of Ruby class constructors. The constructor gem is unpacked into the vendor directory, so it lives in vendor/constructor-1.0.0 ¹.

I’ve laid the project out like this for several reasons. The first is that it is a typical Ruby project layout. The second is that all of the libraries this application needs are distributed with the application itself; thus, the only dependence on the host system is a working Java 1.5+ installation. Err the blog has an excellent write-up about why distributing an application like this is a good idea. His discussion is in the context of Rails, but it is still relevant here.

The third reason is that this layout allows me to work as a developer or roll everything up for a user. As a developer, I don’t want to build a new jar every time I run the tests, since that is too slow. Users want to run a jar instead of trying to navigate some files splattered all over the filesystem. Using some tricks with JRuby’s $LOAD_PATH and $CLASSPATH globals, I will make the application work transparently as either a developer working against the filesystem or a user working with the jar.

Now let’s take a peek at the Rakefile. There are two namespaces: dist and java. The dist namespace defines tasks for building, cleaning, and running the single jar file. The tasks in the java namespace are used by the dist tasks to do the actual building.

namespace :java do
  output_directory = "classes"

  desc "Compile java executable stub class"
  task :stub => 'java:clean' do 
    mkdir_p output_directory
    sh %+javac -target 1.5 -d #{output_directory} -classpath vendor/jruby-complete-#{JRUBY_VERSION}.jar lib/Main.java+
  end

  desc "Compile the Ruby files into class files"
  task :rb => "java:clean" do
    prefix = "com/atomicobject/hello_world"
    sh %+#{jruby} #{jrubyc} -p #{prefix} -t #{output_directory} lib+
  end

  desc "Compile all source files into class files"
  task :compile => ["java:stub", "java:rb"]

  CLEAN.include output_directory 
end

The truly interesting bits of the Rakefile are the java:stub and java:rb tasks, which compile the Java and Ruby files, respectively. The Java stub file is a small Java class that fires up the JRuby interpreter; we’ll look at that next. The java:rb task uses the JRuby compiler to translate all of the Ruby .rb files in the lib directory into Java .class files. The java:rb task also passes the ‘com/atomicobject/hello_world’ argument to the JRuby compiler, which in turn will use that for assigning a package to the each compiled class. After the compiler has run against a .rb file, the corresponding .class file will have the package ‘com.atomicobject.hello_world.lib’—a combination of the prefix and directory we pointed the compiler at.

After building the Java classes, the dist:build task concludes by running ant. An ant task will build the final jar for us using JarJar.

package com.atomicobject.hello_world.lib;

import org.jruby.Ruby;
import org.jruby.RubyRuntimeAdapter;
import org.jruby.javasupport.JavaEmbedUtils;
import java.util.ArrayList;
    
// This technique for starting JRuby is taken from
// http://wiki.jruby.org/wiki/Direct_JRuby_Embedding
public class Main {
  public static void main(String[] args) {
    Ruby runtime = JavaEmbedUtils.initialize(new ArrayList());
    RubyRuntimeAdapter evaler = JavaEmbedUtils.newRuntimeAdapter();
    evaler.eval(runtime, "require 'com/atomicobject/hello_world/lib/application_bootstrap'");
    JavaEmbedUtils.terminate(runtime);
  }
}

The next thing worth looking at is the Main Java class in ‘lib/Main.java’, which is the class that is executed when Java is pointed at the jar. The main method is using one of the JRuby APIs for firing up the interpreter. We’ve got it requiring the ‘lib/application_bootstrap.rb’ file, which is a classless script that takes over the responsibility of starting the application.

The Main.java file distributed with the example includes an alternative method (which is not shown here) of starting JRuby. This method allows you to start the JRuby interpreter by giving it JRuby parameters just like you would on the command line. The downside to this technique is that it is not considered part of the public JRuby embedding API, which means it may be brittle with respect to JRuby versioning.

Now we can move along to the application_bootstrap.rb file.

include Java
$LOAD_PATH << "lib"                              # running from filesystem
$LOAD_PATH << "com/atomicobject/hello_world/lib" # running from jar
$LOAD_PATH << "vendor/constructor-1.0.0/lib"
$CLASSPATH << "vendor/swingx-0.9.2.jar"          # running from filesystem
  
require "view_builder"
require "hello_world"
    
hello_world = HelloWorld.new(:view_builder => ViewBuilder.new)
hello_world.run

This script’s goal is to pull in our third-party dependences and then start the application. Then the rest of the application does not care where the various libraries come from.

The first line of application_bootstrap includes the Java module, which brings in JRuby’s Java integration support. The second and third lines make the source files in the lib directory available to the require lines farther down. The fourth line and fifth lines make the Ruby constructor and Java SwingX libraries available, respectively. Note that the jar is added to $CLASSPATH instead of $LOAD_PATH; $CLASSPATH is a global made available via Java integration and is useful for adding things to Java’s classpath during runtime ². My applications generally loop over directory globs when setting up the LOAD_PATH and CLASSPATH, but in this example I think it is more instructive to be explicit. Once the environment is setup, we require and build a couple of Ruby classses and then start the application using HelloWorld’s run method.

Rather than pasting in the entirety of ViewBuilder and HelloWorld, I will simply discuss the interesting bits.

view_builder.rb contains the line

import org.jdesktop.swingx.JXDatePicker

which allows it to do

date_picker = JXDatePicker.new

This is how the application can access the Java library.

Similarly, hello_world.rb contains

constructor :view_builder

which uses the Ruby library. Thanks to the work done by application_bootstrap.rb, accessing both the Java and Ruby libraries is transparent to the application, whether it is running from the filesystem or within a jar.

Finally, here are the guts of the build.xml Ant file:

<project basedir="." default="dist" name="Hello World">
  <description>Combine Ruby and Java source with the jruby-complete jar</description>
  <target name="dist" description="Create the deliverable jar">
    <taskdef name="jarjar" 
             classname="com.tonicsystems.jarjar.JarJarTask" 
             classpath="vendor/jarjar-1.0rc7.jar"/>
    <mkdir dir="pkg"/>
    <jarjar destfile="pkg/HelloWorld.jar">
      <manifest>
        <attribute name="Main-Class" value="com.atomicobject.hello_world.lib.Main"/>
      </manifest>
      <fileset dir="classes"/>
      <zipfileset src="vendor/jruby-complete-1.1.1.jar"/>
      <zipfileset src="vendor/swingx-0.9.2.jar"/>
      <zipfileset dir="vendor/constructor-1.0.0" prefix="vendor/constructor-1.0.0"/>
    </jarjar>
  </target>
</project>

The Ant file is pretty small; it exists only to make use of JarJar for bundling the application. The <jarjar> task extends Ant’s regular <jar> task by allowing existing jars to be rolled up into the new jar target. In this case, JarJar is directed to pull jruby-complete, swingx, and constructor into our final HelloWorld.jar. Note that the package I chose earlier, com.atomicobject.hello_world, shows up in the Main-Class jar attribute.

If your application is dependent on any RubyGems then I suggest throwing them them into the vendor directory as well. Rolling them in with jruby-complete is not easy, and the same arguments from the previously linked Err the Blog post are relevant. His technique for vendoring gems is good and I recommend using it (Constructor was, in fact, a gem that I unpacked).

I have run into a problem when using JarJar to roll signed jars into our single jar file. In my case, I got exceptions coming out of the signed Bouncy Castle library I use for OpenSSL encryption. My problem likely stems from the fact that JarJar does some bytecode manipulation, which in turn means the bouncycastle files no longer pass signature verification. I do not entirely understand what JarJar does, so I’m not totally sure about this. Either way, my solution was to distribute the bouncycastle library alongside the application’s jar file—the standard way of distributing a Java application. It isn’t as clean as I wanted, but it works.

One thing I’m not particularly happy about with this process is with how many places the com.atomicobject.hello_world package name shows up—it appears in one form or another in almost every file we’ve discussed. Each case is slightly different and exists in a different part of the process, so solving this problem is not easy. I have considered having the main Rakefile generate Main.java, build.xml, and application_bootstrap.rb. This could not only solve the problem of the com.atomicobject.hello_world duplication, but also make it so that less files need to be touched when we add new Ruby and Java libraries to the project. But this solution is not particularly easy to implement and I do not have a great sampling of different project with which to base my abstractions.

David Koontz has a RubyGem named Rawr that helps you turn your project into a single jar. The last time I tried it (a while ago) I could not get it to work the way I wanted; then when I looked again I couldn’t find the website anymore. The above linked page is now active, but I have not tried it lately. So I cannot speak to whether it works or not. And I cannot speak to whether is better or worse than what I’ve described in this article.

I’ve written this post from the first-person perspective, but Atomic’s jar rolling process is hardly my own effort: Micah Alles, David Crosby, Shawn Crowley, Karlin Fox, and Andrew Witte all helped figure this out a year ago and evolve it since then.

My goal here is not to promote the Constructor or SwingX libraries. I chose them simply because they are representative of both Ruby and Java libraries and were easy for me to integrate into the example. ↩
I believe there is an outstanding JRuby JIRA issue for bringing $LOAD_PATH and $CLASSPATH closer to synonymous. ↩

Finder Objects in Rails

2008-06-16T02:08:00Z

ActiveRecord is perhaps the most compelling component of Ruby on Rails. ActiveRecord makes it easy to create a record, or to find one, or even to migrate the database schema. Unfortunately those “find” methods can be a little too seductive. Let’s see why.

Our example project is a basic social network. It will start with profiles and friends, and add from there. We’ve implemented “Profile” and “Friend” features and now our customer asks for “Search by State”. In our “Profiles” controller, we implement:

class ProfilesController
  def search
    @profiles = Profile.find_all_by_state(params[:state])
  end
end

At first, this is wonderful. It does not burden the caller with unnecessary knowledge, and keeps the code simple and clean. It’s also simple to test through either state-based or interaction testing. At the customer’s request, we add an admin listing, a friend list, and the profile page itself. It’s working beautifully.

class ProfilesController
  def search
    @profiles = Profile.find_all_by_state(params[:state])
  end

  def show
    @profile = Profile.find(params[:id])
  end
end

class ProfilesAdminController
  def index
    @profiles = Profile.find(:all)
  end
end

class FriendsController
  def index
    @user = User.find(params[:user_id])
    @friends = @user.friends
  end
end

Then our customer comes back and says we need the ability to have private profiles. A profile should only show up if it’s public. We make the changes as follows:

class ProfilesController
  def search
    @profiles = Profile.find_all_by_state_and_public(params[:state], true)
  end

  def show
    @profile = Profile.find(params[:id], :conditions => {:public => true})
  end
end

class ProfilesAdminController
  def index
    @profiles = Profile.find(:all)
  end
end

class FriendsController
  def index
    @user = User.find(params[:user_id])
    @friends = @user.friends.find_all_by_public(true)
  end
end

We know it’s not ‘DRY’, but we move on in the interest of ‘Getting Things Done’. We run our integration tests, but one is failing. A user can no longer view their own profile. After investigating, we realize that in reality the rule should be “A profile should be visible if it’s public or belongs to the current user”.

class ProfilesController
  def search
    conditions = [
      "state = ? and (public = ? or user_id = ?)", 
      params[:state], true, current_user.id
    ]
    @profiles = Profile.find(:all, :conditions => conditions)
  end

  def show
    conditions = ["public = ? or user_id = ?", true, current_user.id]
    @profile = Profile.find(params[:id], :conditions => conditions)
  end
end

class ProfilesAdminController
  def search
    @profiles = Profile.find(:all)
  end
end

class FriendsController
  def index
    @user = User.find(params[:user_id])
    conditions = ["public = ? or user_id = ?", true, current_user.id]
    @friends = @user.friends.find(:all, :conditions => conditions)
  end
end

This has gotten out of hand. It’s just not ok to leave SQL lying around in our controller, even if it’s just condition arrays. The caller should specify intent, but not worry about details like privacy.

class Profile < ActiveRecord::Base
  def self.find_all_by_state(state, current_user)
    conditions = [
      "state = ? and (public = ? or user_id = ?)", 
      state, true, current_user.id
    ]
    find(:all, :conditions => conditions)
  end
  
  def self.find_all_for_admin
    find(:all)
  end
  
  def self.find_by_id(id, current_user)
    conditions = ["public = ? or user_id = ?", true, current_user.id]
    find(id, :conditions => conditions)
  end
  
  def self.find_friend_profiles_of(user, current_user)
    conditions = ["public = ? or user_id = ?", true, current_user.id]
    user.friend_profiles.find(:all, :conditions => conditions)
  end
end

class ProfilesController
  def search
    @profiles = Profile.find_all_by_state(params[:state], current_user)
  end

  def show
    @profile = Profile.find_by_id(params[:id], current_user)
  end
end

class ProfilesAdminController
  def search
    @profiles = Profile.find_all_for_admin
  end
end

class FriendsController
  def index
    @user = User.find(params[:user_id])
    @friends = Profile.find_friend_profiles_of(@user, current_user)
  end
end

Now all of the actions that need profiles can find them safely by calling one of our methods, and the privacy logic is handled for us. Something doesn’t feel quite right, but we’ll try it for a bit to make sure we’re not just suffering from indigestion.

A month later, the customer asks for a different kind of search. Now we need to search by last name. By this time, there’s a second pair on the project, and they implement this feature.

class ProfilesController
  def search_by_state
    @profiles = Profile.find_all_by_state(params[:state], current_user)
  end

  def search_by_last_name
    @profiles = Profile.find_all_by_last_name(params[:last_name])
  end

  def show
    @profile = Profile.find_by_id(params[:id], current_user)
  end
end

Their integration test passes and they check it in. After we deploy, the customer complains. It seems the new form of search doesn’t take privacy into account. Why did this happen? Intelligent programmers following project conventions and acting conscientiously will still make these mistakes. Is it a communication breakdown? I contend that it’s a code flaw. When finding rules are implemented, they need to be designed to allow later programmers to forget the details until they need them. The programmers should not be filling their minds with privacy while implementing the controller action. But how?

In my experience, finder logic very often gets complicated very quickly. The responsibility for finding a specific kind of entity is a big deal, and should not be given to a class that already fills another responsibility (persisting profile information). In addition, finder methods should not be implicit, as it leads to the issues outlined above. Instead we use finder objects.

class ProfileFinder
  attr_accessor :current_user

  def find_all_by_state(state)
    conditions = [
      "state = ? and (public = ? or user_id = ?)", 
      state, true, @current_user.id
    ]
    Profile.find(:all, :conditions => conditions)
  end

  def find_all_by_last_name(last_name)
    conditions = [
      "last_name = ? and (public = ? or user_id = ?)",
      last_name, true, @current_user.id
    ]
    Profile.find(:all, :conditions => conditions)
  end
  
  def find_all_for_admin
    Profile.find(:all)
  end
  
  def find_by_id(id)
    conditions = ["public = ? or user_id = ?", true, @current_user.id]
    Profile.find(id, :conditions => conditions)
  end
  
  def find_friend_profiles_of(user)
    conditions = ["public = ? or user_id = ?", true, @current_user.id]
    user.friend_profiles.find(:all, :conditions => conditions)
  end
end

class ProfilesController
  before_filter :build_profile_finder

  def search_by_state
    @profiles = @profile_finder.find_all_by_state(params[:state])
  end

  def search_by_last_name
    @profiles = @profile_finder.find_all_by_last_name(params[:last_name])
  end

  def show
    @profile = @profile_finder.find_by_id(params[:id])
  end

  private 

  def build_profile_finder
    @profile_finder = ProfileFinder.new
    @profile_finder.current_user = current_user
  end
end

Now when our new pair is asked to implement the ability to find profiles by last name, they know project standards dictate the use of the relevant finder. Their integration test fails since the method does not exist. When they create it, they see the other privacy logic in close proximity, and now have enough information to initiate a conversation with the customer about privacy. We’ve found that conscientious use of finder objects enables us to have very consistent finding logic, which reduces bugs and user confusion. It also simplifies tests, as the tests benefit from a clear scope definition, and are not cluttered by other model logic. It also makes finder rules discoverable as they are now in a centralized location.

We decided that finder objects are allowed to know model fields and conditions, sql, etc. They are also allowed to call with_scope on that model. This all fits with their responsibility of knowing how to find the appropriate model.

Usage Tips

For bonus points, combine this with dependency injection. We do, and we’re loving it. It allows context like the current user to be injected, and then the caller doesn’t even need to know that the method requires the current user, as that’s simply a privacy constraint.

We’ve also discovered that for purposes of authorization rules (are you allowed to see this record?), it helps for the caller to provide intent. If a record otherwise exists but the user does not have permission to follow through with the stated intent, nil is returned.

12	profile_finder.find_by_id(id, :for => :show)profile_finder.find_by_id(id, :for => :update)

I may be able to see my friend’s profile, but I can’t update it. Finder objects already need some authorization information to restrict queries. It makes sense to block out access at the data layer. If I can’t fetch the record, I can’t update it. My code can be required to provide an intent with the :for attribute; you may rig your finder to raise an error if no intention is indicated.

Sometimes, even just the act of determining the permissions of the current user and the object at hand can be complicated, and given that you may need to apply action-oriented permissions for an entity type in more than one place in your code, it makes sense to implement a Permitter (in this case, a ProfilePermitter). The topic of permitters may warrant another blog post.

Google I/O Impressions

2008-06-12T18:59:00Z

Atomic Object provides some fantastic benefits. For example, Atomic sends each developer to one conference each year. They pay the registration, air fare, and hotel. They also pay as if I had been actually working. It’s fantastic to have an employer that not only wants me to be a better developer, but takes the extra steps to help me improve.

This year, I attended the Google I/O conference in San Francisco. The first day’s keynote was essentially a bird’s eye view of the conference content. The overall theme was that Google wants to advance capabilities of web applications. They understand that their growth is tied to the growth of internet use at large. They understand that internet use will increase as web applications improve. They want to facilitate the improvement of web applications by providing tools for developers to use. As much as possible, these tools are open source, and not bound to Google, as that is the best way to empower the advancement of the internet.

From any other company, I would consider this pure rhetoric, but after those two days in San Francisco, I’m inclined to take Google at its word. All but one of the technologies I looked at is open source and/or an open standard. In addition, they have a financial interest in the continued improvement of internet applications.

OpenSocial

OpenSocial is an open standard for integration of third-party social applications. As OpenSocial is an integration standard, it has two sides. Social networks (orkut, for example) act as OpenSocial containers, where their members can add third-party applications to their profile. Third-party developers provide OpenSocial applications which can then plug into an OpenSocial container. This allows, at least in theory, someone to create an application that can run on many different social networks without having to customize for each one. In reality, there will probably be some GUI customization required, and not all OpenSocial containers will allow all OpenSocial applications.

Google App Engine

Google App Engine is a web framework designed to scale, hosted on Google’s server cloud. Google App Engine is the one technology covered that is not open source. This is forgivable since it’s specifically designed to run on Google’s server cloud. Since I don’t (yet) have a sophisticated cluster of thousands of servers with crazy infrastructure, I don’t begrudge them the closed source nature.

The intent of Google App Engine is to make it so any application using this framework will automatically scale. The free version allows up to five million page views per month, and the pay version, while not yet available, will be metered, and should, by Google’s estimates, be somewhere in the ballpark of forty dollars a month for 10 million page views per month. The datastore uses Bigtable, Google’s custom database.

Exciting features

Google App Engine provides (almost) guaranteed scalability! In theory, the framework does not allow any operation that is not scalable. In practice, no framework will overcome bad development practices, but this framework makes it a lot harder to screw it up.

The application gets free, high quality hosting running on Google’s server cloud. Up to 5 million page views per month are free.

The application gets convenient access to most Google APIs. It’s super easy to do logins using Google Accounts.

Disappointing limitations.

There is currently no support for schema migrations. There is no support for batch data operations. The application may not fetch more than 1000 records in a query. Requests are time-limited. This means I cannot rename a field after it has been deployed. To be fair, it is technically possible, but I would have to make one request for each 1000 records, which would be tedious and error-prone at best.

Bigtable does not yet back-fill default values into existing records when you add new fields to a type. For the old records, the field isn’t null, it’s just not there, and you cannot query for that condition. (Fields may have null values and be queried as such, but these “missing” fields will not match a query for null.) In a production environment, this can lead to vanishing data when querying based on such fields. Currently there is no mechanism (like migrations in Rails) to help you adjust your data.

BigTable does not support substring searches. String equality and begins-with style conditions are supported, but searching based on partial matches mid-string doesn’t work yet.

While Bigtable encourages you to create most objects with a parent object, you cannot move them to a different parent after the fact. The record would have to be deleted and recreated, which would also require updating every reference to that object.

There is hope however. App Engine is a beta product, and the presenter mentioned that they are prioritizing support for offline processing, like schema migrations, as well as full text search.

Gears

Last year, Google released Google Gears, which is a plugin available for all major browsers. It installs like flash, but provides a client-side JavaScript API for doing various things that are impossible in current browsers. The goal of the project is to make more desktop-like behavior possible for web apps. The major features currently in place center around making it possible to take the web application offline.

Google made a big deal about debranding Gears. It is now just Gears, rather than Google Gears. The rationale is that they don’t want corporate branding to hinder adoption. The purpose of Gears is to push browsers forward, not advance Google’s brand. They demoed some new features, that are currently only prototypes.

Gears will allow applications to upload multiple files with a smooth interface, using a multiple file selection box, instead of the current system of one input field per file. Progress information will also be available to the client. Uploads will also be resumable.

Gears will allow the application to give system notifications, in a system similar to growl. It may even provide growl integration. This is to replace informational messages that would normally get JavaScript alert boxes or custom design work.

Closing Thoughts

Google is putting a lot of effort into making it possible to do more powerful things with web applications. While I didn’t come away with anything that helps me today, I did come away with a new vision for the possibilities of the web, and some tools to achieve those possibilities.

Ruby and Unicode Win32 MessageBoxes

2008-06-10T19:53:00Z

Have you ever needed to display Unicode characters in a Win32 MessageBox from a Ruby script? My pair and I needed to do just that and so I thought I would share what we found.

There are a number of ways to access Win32 calls from a Ruby script. The code we were working with did the following:

require 'dl'
def show_message_box(message, title)
  mb_ok = 0
  mb_iconexclamation = 48
  
  user32 = DL.dlopen("user32")
  message_box = user32['MessageBoxA', 'ILSSI']
  message_box.call(0, message, title, mb_ok | mb_iconexclamation)
end

That works well until you need to display Unicode characters in the MessageBox. It turns out the MessageBoxA version of the function is for ASCII characters. There is another version of the API call, MessageBoxW, that can handle Unicode, or wide characters. So the issue becomes converting your Ruby string into a wide string so it can be passed to MessageBoxW. The MultiByteToWideChar Win32 call can do this for you. And the windows-pr gem (from win32utils) adds a nice ruby wrapper around the function.

gem install windows-pr

require 'windows/unicode' 
include Windows::Unicode 
$KCODE='UTF8'

str = multi_to_wide("This is a test")

This seemed to work quite well for the most part. However, from time to time we would see garbage text showing up at the end of our messages. It could easily be reproduced if the message was very short.

Having done enough C/C++ coding to recognize a string that was not being null terminated, we experimented with adding null characters to the end of the string. It turns out a wide null terminator (”\0\0”) is needed. The following code will properly display Unicode characters in a Win32 MessageBox:

require 'dl'
require 'windows/unicode' 
include Windows::Unicode 
$KCODE='UTF8'

def win32_wide(text)
  multi_to_wide(text) + "\0\0"
end

def show_message_box(message, title)
  mb_ok = 0
  mb_iconexclamation = 48
  
  user32 = DL.dlopen("user32")
  message_box = user32['MessageBoxW', 'ILSSI']
  message_box.call(0, win32_wide(message), win32_wide(title), 
                             mb_ok | mb_iconexclamation)
end

show_message_box "MessageBox displayed from Ρουμπίνι", "¡Alert!"

Make strategy like you make software?

2008-05-29T01:54:00Z

Allan Kelly draws some interesting conclusions about Agile software development methods as related to forming business strategy. The impetus for his post was a piece in the MIT Sloan Review entitled “Should you build strategy like you build software?.”

From Allan’s “Make strategy like you make software?”:

...for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes imagine software code as liquid strategy.

...many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.

It is not only software development where managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.

TheCommon.org in the News

2008-05-29T01:47:00Z

More client news:

The idea came to Rick DeVos while he listened to church leaders describe how they were going to use email to help people get involved in church activities.
“It seemed like a nightmare of useless emails filling up everyone’s mailboxes, and an administrative nightmare,” DeVos says. The more he thought about it, the more he realized there was no online tool to help organizations connect people in need with the people who could help.
So DeVos talked to Ben Gott and the two created TheCommon.org, an online site that helps people lend a helping hand.

Grand Rapids innovators develop online ‘helping hand’

CircleBuilder in the News

2008-05-29T01:29:00Z

Client news:

So far the 2-year-old firm based out of Franklin has three full-time employees and has raised more than $1.3 million in seed money from venture capital firms and angel investors.
CircleBuilder, which offers Yahoo Groups-like services to churches, is about to bring in another “big chunk of change” as it prepares to close another round of seed money investing. The firm hopes to open its site to the general public this summer and hire 15-20 people by the end of next year.
“I am trying to do all of my business in Michigan,” Brown says. “My lawyers, CPA and technology firm [that’s us! -ed.] are in Michigan. You have got to start something in this state because we’re too reliant on the auto industry.”

CircleBuilder paces its growth, looks to add 15-20 jobs in two years

Model Generation - Coding for Simplicity

2008-04-30T21:30:00Z

Rails convention calls for test data to be stored in fixtures. This works very well for the first few iterations, but this approach quickly becomes unwieldy. Often, many records are required, which can lead to poor record names like event_46. Even when naming conscientiously, it’s difficult to give each record a meaningful name in a global scope. When adding required fields to models, every record needs to be updated, which can be tedious for large test data sets, and very often the updates have an undesired impact on a broad set of tests.

We’d prefer to build up test data closer to home, in the test itself, so we can see the connection between the data and the expectations. Furthermore, if we structure our tests this way the data is isolated from other tests so we’re free to tinker with it without breaking those other tests. The drawback is that manual creation of ActiveRecord objects in your test code can become as tedious to write and maintain as fixtures.

Enter Generate – a technique that centralizes ActiveRecord model generation for test data, removes the need for fixtures, and avoids the tedium and verbosity of in-test model creation.

Example RSpec usage:

describe Event, '#find_all_by_name' do
  it 'finds events with matching names' do
    event = Generate.event
    Event.find_all_by_name(event.name).should include(event)
  end

  it 'does not find events with different names' do
    event = Generate.event(:name => "some name")
    Event.find_all_by_name("a different name").should include(event)
  end

  it 'does not find private events' do
    event = Generate.event(:private => true)
    Event.find_all_by_name(event.name).should_not include(event)
  end
end

class Generate
  def self.event(options={})
    Event.create!(options.reverse_merge(:name => "sample event name", :private => false))
  end
end

The Generate class makes building an Event very convenient. The test only needs to specify attributes it cares about (if any) and Generate will worry about making the Event valid. If at some point the event requires a starts_at field, the Generate class can simply add that to the default attributes, and all tests will continue to pass without alteration. This becomes especially useful when building webs of objects.

describe Event, '#attendee_count' do
  it 'returns the number of yes rsvps' do
    event = Generate.event(:attendees => [Generate.user, Generate.user])
    event.attendee_count.should == 2
  end
end

class Generate
  def self.event(options={})
    attendees = options.delete(:attendees) || []
    event = Event.create!(options.reverse_merge(:name => "sample event name", :private => false))
    attendees.each do |attendee|
      Generate.rsvp(:event =&gt; event, :user => attendee)
    end
    event
  end

  def self.user(options={})
    @user_count ||= 0
    @user_count += 1
    User.create!(options.reverse_merge(:email => "user#{user_count}@example.com"))
  end

  def self.rsvp(options={})
    options[:user] ||= Generate.user
    options[:event] ||= Generate.event
    Rsvp.create!(options.reverse_merge(:response => "yes"))
  end
end

Once again, the test is very clear. A reader can tell exactly what’s going on without hunting through fixtures. Furthermore, adding attendees to the Event in this test will not affect any other tests.

We’re using this approach on a large project currently under development. As our project has grown, the complexity of our data model has increased, making our ActiveRecord models more and more interrelated. But rather than feeling the pain of fixture maintenance and test adjustment, we’re able to move freely and quickly by updating one or two Generate functions at a time without impacting any other tests, while maintaining the flexibility to test anything new that comes our way.

The nice thing about Generate is that it doesn’t require a supporting library or up-front investment in tool building, short of knowing how to use ActiveRecord to instantiate your models. The trick is in the technique itself – leaving you the option to apply it in your projects in whatever way best meets your needs.

References:

The Generate technique is very similar to the ObjectMother testing pattern. Please see “ObjectMother: Easing Test Object Creation in XP” by Peter Schuh and Stephanie Punke.

Spiffy Updated Bios

2008-04-24T19:42:00Z

I resisted the urge for a pun about meeting the "Atoms Family" or some cringe-inducing line.

We've had some new Atoms join the Molecule (Nate Lokers & Eric Hass). And, we decided it was time to update everybody's bios on our website. We get really positive feedback from customers and potential customers about our bios. The visibility into our company and culture via the bios seems to really connect well with the outside world. So much so that we give periodic attention to them and always feature them as a link on our website's front page.

So, feel free to poke around and meet the Atomic Object Molecule.

We continue to look for good people to hire. If you're interested, start the process.

Simplicity: What We Can Learn About Usability

2008-04-02T14:34:00Z

A Comic by Eric Burke:

via [stuff that happens]

Reality-Driven Development

2008-03-31T18:31:00Z

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 todbits. Reading the entire post is well worth the time.

Integrating Java and Ruby with JRuby

2008-03-24T14:25:00Z

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.

Trailing backslash problem and fix for Rails and SQLServer 2005

2008-03-18T18:12:00Z

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.

For example, if you had a model with a string attribute called name and you tried to do Model.create! :name => 'foo\\' you would get the following error:


  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.

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