I attended the tail end of Startup Weekend at The Factory this weekend. Kudos to Michael Boyink and Aaron Schaap for organizing this in West Michigan. Marc Nager, one of two people who run Startup Weekends all over the country, commented on the energy in the room and the incredible willingness of strangers to get behind ideas and work together. Evidently what we lack in VC we make up for in hard work and generosity.

The final pitches were pretty good considering that some of these ideas weren’t even hatched until Friday afternoon. An app for helping people keep track of things that need to get done even had a pretty functional backend implemented over the weekend. It was great to see eight teams and 40 or so people challenging the economic doom and gloom of our state, putting their ideas out there, listening to others, and taking action to make them real.

I smiled this morning when I typed this command to git-deploy fresh code to three machines in quick succession.

Sure, there’s nothing groundbreaking here that you can’t do with plenty of other tools. But it was still fun.

No, they won’t explode.

Resident cookie-master, Marissa Christy, went the extra mile yesterday for the SoftwareGR meeting. While our meetings always have great snacks, Marissa really raised the bar this time with Atomic Object logo cookies:

If you want some great snacks, and great information too, come to the next SoftwareGR meeting.

Yesterday SoftwareGR hosted Dr. Richard Enbody from MSU. He spoke about security, and he quoted the above security rule from the book Writing Secure Code by Michael Howard and David LeBlanc (sample chapter.)

The main topic of the talk was recent research performed by Richard’s team to develop a new security feature called Secure Bit.

Version 1.0 of the Google Collections library was officially released December 30, 2009. I have been using the library for the past 6 months or so on a variety of Java projects, with great success. Today I gave a brown-bag talk to share with some interested Atoms.

I have included below the sample code I used as presentation material, in case others are interested.

On February 6th I hosted the first Code Retreat to hit West Michigan, and we really couldn't have asked for a nicer day for a Code Retreat. Well, maybe a little bit warmer weather, but hey, it's February in Michigan, what do you expect? So after a quick stop at Panera Bread to get some bagels, scones and muffins, I made my way down to Atomic Object HQ to start the coffee brewing in preparation for the attendees. Shortly after sunrise, Nayan Hajratwala showed up to help with any last minute preparations before everyone else showed up.

Soon about 20 people from all parts of the region had showed up to practice TDD and learn with each other, including one guy who came all the way down from Marquette, MI just to attend. He officially got the "I traveled the furthest" award for the day. We were also joined by Ron Jeffries and Chet Hendrickson, who had agreed to come and be my professional trouble makers for the day. Shortly after 9:00, once everyone had been sufficiently caffeinated, we decided to get started. One of the attendees had mentioned something about Corey Haines putting together a set of Cucumber features at one of the previous Code Retreats in Chicago, so some of the pairs decided to give that a whirl. After some yak shaving we managed to get through the first iteration of the morning and retrospected on what happened and continued on into the second iteration of the day.

My original plan was to just sort of float around, help facilitate, and observe everyone else pairing, however when I noticed Ron Jeffries didn't have a pair for the second iteration, I took the opportunity to pair with him. Neither of us knew Cucumber very well, so we decided to give that a whirl. If ever you get the chance to pair with either Ron or Chet, don't think twice about it, just do it. Ron had at one point in the day managed to - as one participant described "...[kick his] BDD mindset a bit out of place. . . "

Before we knew it, lunch was upon us. It turns out that Corey Haines was hosting another Code Retreat in Seattle that day, so we fired up Skype and greeted our fellow Code Retreaters on the west coast as they were just getting ready to start for the day. Then we all proceeded to enjoy the taco bar that had been delivered for lunch and continued to retrospect on the days events so far. When we were all finished stuffing our faces with Qdoba, Mike Sweiton and myself gave our participants a quick tour of Atomic Object HQ, showing off our open space, stoplight, CI server, and our embedded projects workbench.

Now that our food had a chance to settle, it was back to pairing for a few more iterations of Conway's Game of Life. After one of the afternoon retrospectives, for a little bit of a distraction, we watched a video of someone implementing Conway's Game of Life in APL. This was spawned by an email thread that circulated right before the Code Retreat about how to implement the Game of Life in a single line of APL, which still blows my mind.

Finally, by the time the end of the day had finally arrived, we had lost a few of our fellow coders and we were ready to call it a day. Those of us who were still left standing at the end of the day took a walk around the corner to The Green Well, one of the many local establishments in the Eastown area, for some much needed unwinding. We continued to retrospect on the day's happenings over a few local microbrews and some delicious items from the menu. All in all I would have to say this was a successful Code Retreat. Everyone had a great time, we all got to pair program with some great folks we wouldn't normally get to pair with, and - most importantly - learning happened. Though many of the Code Retreats in the past have used Java as their language of choice, in my opinion I think using Ruby for this Code Retreat was the right choice. It afforded us much less yak shaving than would have probably been necessary had we been using Java. I'm looking forward to hosting another Code Retreat later this year when the weather is a little warmer, and hopefully attending the upcoming Code Retreat being hosted in Philadelphia by Sebastian Hermida.

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