For a business that by definition occupies a highly technical domain, we have some relatively low-tech means of conveying information internally. Sure we e-mail, Twitter, Yammer, and even Skype with each other on a regular basis, but we also make use of yarn, note cards, cork boards, and old traffic equipment. I’m talking about our information radiators, objects around our office that align the team by sharing important information in a fun and hard-to-miss way.

Later this month, Shawn Anderson will be going back to Cali, his previous home, to make back-to-back presentations at two different conferences: LA RubyConf and SCALE (the second time in two years). For both, he is presenting on developing 2D games using Ruby and open source tools (including a library that he wrote).

Last weekend I had the privilege of attending a UX Agile Retreat at Cooper. The retreat was an informal event where ~33 practitioners from the UX and Agile fields came together to discuss how we can better create effective and successful products. The event schedule was loosely defined and it self organized based on the trending topics. We used a variety of exercises and discussion techniques to voice our experiences, concerns and ideas to help build a vision of a better, collaborative future.

Where We’ve Been

The UX and Agile communities have been flirting with how they could integrate their practices more seamlessly and respectfully. Both groups respected one another yet remained uneasy about having to alter their respective approaches for an integrated vision and process. UX Designers were worried that some of their practices would be minimized or marginalized due to Agilistas’ strong belief of minimal upfront design. Fear existed that quality design would be sacrificed to the almighty iteration once an agile project was underway. Agilistas were worried about designers doing too much work up front without creating functioning software. Developers were ignorant of the UX Design process and the immense value it provides. Individuals, like Jeff Patton and Lane Halley, have been working very hard to increase knowledge and respect between the two groups. Anders Ramsey organized and dedicated himself to making last week’s event happen. He did an outstanding job. The UX and Agile camps are coming together because they recognize and respect each other’s dedication to the craft of creating high quality products.

Where We Are

Most of our discussions during the retreat focused on vision, values and principles instead of outlining a strategy for collaboration. I’m glad the group was able to remain focused at such a high level because good process stems from alignment and a mutually shared vision.

We took a stand that the “Us and Them” mentality is dead and that we have to move forward as “We.” Management and business processes have kept our groups apart in the past due to a focus on efficiency and a misunderstanding of what it takes to create successful digital products. Management often times does not know how to ask us for what they want, nor do they know how to properly manage creative teams. We believe that we can create better products more efficiently by focusing on being effective. We believe that effectiveness is increased by working together closely.

The Future

The new vision is forming. The retreat group is committed to evangelizing and furthering this vision. I left the retreat with strong feelings of alignment, momentum and excitement. We are the makers of amazing, complex things and we are taking a stand on how we’ll bring the dreams of others into the world. We’re building a case for businesses to employ design thinking at all levels, to focus on the satisfaction of their customers and and to let individuals who understand the creative process to manage it for effectiveness.

Why in the world would you want to embed JRuby into your application instead of relying on a regular Ruby or JRuby installation? I can think of three reasons.

Note: this is a sister post to my description of the arguments needed to run JRuby via jruby-complete. Here I discuss the rationale for using JRuby like this.

What’s the upside?

You can bundle your Ruby runtime dependence into the application.

If you don’t know what I’m talking about here then you should probably stop reading right now. An old post by Err the blog summarizes the “vendor everything” principle quite well:

Quickly: fix it! Tell everyone to install the gem locally. Install the gem on your staging server. Carefully install the gem on your production server. Phew. Everyone’s got the same version, right? Right. Well, maybe. (At least the build works.)

1. I don’t want to ask my users to install anything outside of my application. I definitely don’t want to count on the end user having something installed. Depending on end users having a compatible version of Java is frustrating enough, let alone a JRuby installation. Depending on the JRuby installation can be annoying for developers as well. Take culerity as an example. You could spend a bunch of time screwing around with getting your system-wide JRuby installation just right. Or you could embed JRuby directly into culerity and be done with it.
2. I don’t need to worry about version incompatibilities between the various runtimes. Incompatibilities can mean features I depend on are unavailable, subtly different, or outright broken. An interesting example of “subtly different” came up in an application I recently developed. At one point the sort implementation in JRuby changed from a stable sort to an unstable sort. As far as I know, Ruby doesn’t guarantee sort stability one way or another, so the change was ok from a Ruby perspective. Not so much for me. It turns out my application assumed a stable sort. Had I been dependent on the user’s Ruby installation, my application may have been using either the stable or unstable sort implementation, which was a variance it could not tolerate. (I’m glad I had automated integration tests that revealed this problem to me. I eventually concluded that the application’s behavior was fine with either the stable or unstable sort.)
3. Using JarJar and a few tricks means you can distribute your Ruby application as a single jar file.

Your application may need to run in a constrained environment where you can’t install much, but Java is available.

A couple of years ago I started development on a new application for monitoring PeopleSoft services. Installing Ruby on the servers I was deploying to was not an option. Java was already there to support PeopleSoft. Thank goodness JRuby 1.0 had just been released.

Managing one file is easier than managing many files.

Copying around one jar file is easier than copying a directory with hundreds of files in it. Yeah, manipulating a directory isn’t always a pain, but the times where manipulating a big directory is a pain can be a really big pain.

What’s the downside?

Your application gets bigger.

jruby-complete is currently (as of version 1.4.0) sitting at around 11.5 megabytes. Do I care? Nope. This can be annoying but it generally doesn’t bother me. Especially when my application is already measured in tens of megabytes.

Figuring out and typing the correct commands to run your application isn’t trivial.

This part sucks. Running commands through jruby-complete is tedious when you don’t have any help from something like Rake tasks. The JVM boot time sucks as well. For these reasons I don’t recommend using jruby-complete for everything: when running small, one-off scripts, there’s just too much overhead. Thankfully, when I do depend on jruby-complete, I’m already working on an application where I’m using Rake to automate all kinds of things. So running lengthly java commands isn’t a big deal because my Rake support is already there.

Thankfully, this companion post is chock full of tips for alleviating the pain from those nasty commands.

One of the great things about the JRuby project is that it’s easy to run Ruby programs without installing Ruby. In fact, you don’t even need to install JRuby. All you need is a JVM runtime and jruby-complete.

Rationale

Check out this other post for a discussion of my reasons for locking down your JRuby runtime. In summary, embedding jruby-complete gives you complete control of your Ruby runtime. That’s a good thing. The downside is that discovering and executing commands through jruby-complete can be a pain. The rest of this post describes how to ameliorate the pain.

Running jruby-complete

java -jar jruby-complete-1.4.0.jar

java -jar jruby-complete-1.4.0.jar -e "puts 'Hello'"

java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar -e "puts 'Hello'"

java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar -e 'load "META-INF/jruby.home/bin/jirb"'

1
2
3
4

irb(main):001:0> puts "Hello"
Hello
=> nil
irb(main):002:0> %

1
2
3
4
5
6
7
8
9
10
11
12
13
14

JRUBY_COMPLETE = "jruby-complete-1.4.0.jar"
JRUBY = "java -Xmx500m -Xss1024k -jar #{JRUBY_COMPLETE}"

namespace :jruby do
  desc "Run JRuby help"
  task :help do
    sh %+#{JRUBY} --help+
  end

  desc "Run any command with JRuby"
  task :run do
    sh %+#{JRUBY} -e '#{ENV["cmd"]}'+
  end
end

Now I can type rake jruby:run cmd='puts "Hello"'. Shell escaping is becoming a real annoyance at this point. Thankfully, I’m usually not using jruby-complete to run silly little commands. By the time I’ve introduced a Rakefile I’ve got a real application with tasks oriented around testing and running it, so it’s rare that I’m using a task like jruby:run very often.

1
2
3

task :run do
  sh "#{JRUBY} lib/application_bootstrap.rb"
end

1
2
3
4

fletcher-git/github/jruby-complete-example(master) rake run
(in /Users/fletcher/git/github/jruby-complete-example)
java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar lib/application_bootstrap.rb
Hello from application_bootstrap

1
2
3
4
5
6
7

  namespace :spec do
    desc "Run RSpec against a specific file"
    task :run do
      raise "You need to specify a spec with spec=" if not ENV["spec"]
      sh %+#{JRUBY} -S spec -f specdoc #{ENV["spec"]}+
    end
  end

1
2
3
4
5

describe "John Galt" do
  it "does not tolerate logical fallacies" do
    "A".should == "A"
  end
end

1
2
3
4
5
6
7
8
9
10

fletcher-git/github/jruby-complete-example(master) rake spec:run spec=spec/unit/objectivism_spec.rb
(in /Users/fletcher/git/github/jruby-complete-example)
java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar -S spec -f specdoc spec/unit/objectivism_spec.rb

John Galt
- does not tolerate logical fallacies

Finished in 0.123 seconds

1 example, 0 failures

1
2
3
4
5
6
7

fletcher-git/github/jruby-complete-example(master) which sp
sp () {
        rake spec:run spec=$@
}
fletcher-git/github/jruby-complete-example(master) sp spec/unit/objectivism_spec.rb
(in /Users/fletcher/git/github/jruby-complete-example)
java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar -S spec -f specdoc spec/unit/objectivism_spec.rb

Alright, so now that my application has been built up, I might want to start compiling the .rb files into .class files. Here comes jrubyc:

1
2
3
4
5
6
7
8
9
10
11
12

require "rake/clean"

namespace :jruby do
  output_directory = "classes"
  directory output_directory
  CLEAN.include output_directory

  desc "Compile Ruby files in lib"
  task :compile => output_directory do
    sh %+#{JRUBY} -S jrubyc -p com/atomicobject -t #{output_directory} lib+
  end
end

1
2
3
4
5
6
7
8
9
10
11

fletcher-git/github/jruby-complete-example(master) rake jruby:compile
(in /Users/fletcher/git/github/jruby-complete-example)
mkdir -p classes
java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar -S jrubyc -p com/atomicobject -t classes lib
Compiling all in '/Users/fletcher/git/github/jruby-complete-example/lib'...
Compiling lib/application_bootstrap.rb to class com/atomicobject/lib/application_bootstrap

fletcher-git/github/jruby-complete-example(master) rake jruby:run cmd='require "classes/com/atomicobject/lib/application_bootstrap"'
(in /Users/fletcher/git/github/jruby-complete-example)
java -Xmx500m -Xss1024k -jar jruby-complete-1.4.0.jar -e 'require "classes/com/atomicobject/lib/application_bootstrap"'
Hello from application_bootstrap

1. enabling antialiasing in Apple’s JVM via a Java property.
2. tweaking Substance’s widget behavior via a Java property.
3. enabling Yourkit Java Profiler via the -agentlib parameter.
4. including libraries and directories in the JVM’s classpath via the -cp parameter.

Since these parameters need to be passed before the -jar parameter, a more sophisticated method for setting up the JRuby command is needed than the constant I’ve used. A method like that is specific for your application and beyond the scope of this post, but is not be difficult to create.

Conclusion

There are an uncountable number of good things about JRuby and jruby-complete is one of them. A little help from scripts and your shell means you can build and run your application with a controlled Ruby runtime.

Additional resources

• The Rakefile, jruby-complete, and other files used in this post are available in this GitHub project.
• JarJar Links is an ant library that is useful for combining multiple jar files together.
• I wrote a post a while ago about using JarJar to combine jruby-complete and other application dependences into a single file.
• The AGI Production Simulator is built using the jruby-complete commands described in this post as well as the above jar-rolling technique.

1. Replicating the true jruby behavior is way, way beyond the scope of this post. Check out the jruby script if you really care. Most of the time the JVM heap and stack sizes are the most important things to worry about. ↩

Edit 2/6/2010: Reduced -e ‘load…’ parameters to -S

Atomic Object has been using Yammer internally for about a month. Yammer is enterprise level micro-blogging. Essentially, it is a private Twitter service.

Yammer has proven to be a great way to share information within our organization. Unlike Twitter, the service is restricted to our organization so the team can freely discuss internal projects, company tactics, and technology information. If any of the commentary is interesting to the outside world it is then broadcasted through the company twitter feed.

Our favorite part about Yammer is that it has provided a channel for our off-site Atoms to connect with the rest of the office. It has helped the team stay connected that much better, and is quickly replacing company wide emails.

Working with some new customers this year has given me fresh perspective on how confusing the terminology of the testing world can be. I think terms and definitions matters a lot, and not just because I’m a recovering academic. Several times recently I’ve found myself in a conversation taking a position in apparent opposition to my companion, only to eventually determine that we were in fact talking about the same thing. Or we might have been using the same words, but actually meaning very different things. I don’t know that the testing world is any more inconsistent in their terms than other technical fields, but it sure seems like it sometimes.

Eric Sink, of Source Gear was January’s SoftwareGR speaker. Twenty five or so people turned out for the meeting. Eric chose to speak on the topic that he’s passionate about: version control. This is a deeply nerdy interest and his wife is tired of the subject, evidently. Version control in a nutshell is undo & history of change.

We’ve always believed in hiring for brains, attitude, and general skills. This approach has served us very well, and while we’ll often chat with candidates about their specific technology experiences, that’s not what makes the difference in deciding whether to make an offer or not. Until fairly recently we’d only had the opportunity to apply this approach to hiring developers. Last summer we branched out some—I’m happy to report our strategy works for hiring Art Historians as well.

Yes, the Atomic art collection had really become unmanageable. From our original piece (an early nuclear-inspired gift from an aspiring artist who was a friend of my partner Bill’s mother) to a cast off (and semi-scandalous) discrete nude painted by an anonymous GVSU art student, we were really in a quandary as to proper display, cataloging, and preservation of our art. Oh, and pretty much everybody was grousing about answering the phones, greeting visitors, and watering the plants, too. So we decided to go looking for someone to help with a few of these things. The trouble was, we almost certainly didn’t have enough work for a full-time person, yet we needed full-time coverage. [Nerdy sidebar – we recognized that this position was all about response time, not throughput. Since our profit hinges on high utilization, this took some getting used to.]

Our old building has hosted an interesting variety of occupants since its opening in 1916: Movers, USPS workers, telephone company operators, rock recording artists, software developers. Throughout its 90+ year history, it has also spent some time standing vacant.

When we went looking for the best location to set up AO’s shop, we knew we wanted to contribute to the re-birth of Grand Rapids’ urban core. One of the best first-step strategies endorsed by the green building movement is to work with an existing building on an existing site – that not always attractive notion of reusing and adapting what already exists, rather than creating something brand new.