Atomic Spin - Home

Lazy thread-safe collections in Java

2010-03-18T14:24:00Z

I recently needed to update some Java code that was frequently making unecessary calls to an external web service. Depending on the particular UI component, or the item being displayed in that component, a large set of the data being retrieved ended up not being displayed. My task was to update the code so that it only made external calls to the web service when the data was going to be displayed.

My first thought was to pass along a flag from the view layer that would indicate whether or not to retrieve the data in question. This would require updating all of the UI classes that displayed the data, as well as passing the new flag through several additional method calls to prevent the data from being collected when it wasn’t needed.

I did not care for this solution because it meant changing several classes so that details of the view could be passed down into the data retrieval logic. Instead, I came up with an alternative solution, the crux of which is a generic, thread-safe, delayed evaluation Map.

Instead of the business layer service returning a fully populated Map of data, it returns a Map that will contain that data, if it is accessed. If no user interface components request the data for display, the data will never be retrieved. This meant that I did not have to change any code outside of wrapping the logic for populating the Map with a new LazyImmutableMap. Here is an example of how it is used:

public Map<String, String> getData(final Integer id) {
  return new LazyImmutableMap<String, String>(
    
    new Callable<Map<String, String>() {

      public Map<String, String> call() throws Exception {      
        return externalService.getSomeData(id);
      }
    
  });
}

The call to externalService.getSomeData() will only be invoked if something tries to access an element in the LazyImmutableMap. Implementing the class itself turned out to be extremely simple with the help of Google Collections’ ForwardingMap (see this previous post for more on Google Collections) and the standard Java concurrency class FutureTask.

public class LazyImmutableMap<K,V> extends ForwardingMap<K,V> {
  public static class AccessException extends RuntimeException {
    public AccessException(Throwable cause) {
      super(cause);
    }
  }

  private final FutureTask<Map<K, V>> task;

  public LazyImmutableMap(final Callable<Map<K,V>> eval) {    
    task = new FutureTask<Map<K,V>>(new Callable<Map<K,V>>() {
      public Map<K, V> call() throws Exception {
        return ImmutableMap.copyOf(eval.call());
      }
    });
  }

  @Override
  protected Map<K, V> delegate() {
    task.run();
    try {
      return task.get();
    } catch (InterruptedException e) {
      throw new AccessException(e);
    } catch (ExecutionException e) {
      throw new AccessException(e.getCause());
    }    
  }
}

The constructor creates a FutureTask that when accessed will return an immutable copy of the Map provided by the passed in Callable.

Extending ForwardingMap means that I only needed to implement the delegate method to get a fully compliant Map class. The FutureTask takes care of preventing the passed in Callable from being executed more than once, and it’s thread-safe, so any number of threads can access an instance of the map simultaneously.

Unfortunately Java’s checked exceptions add quite a bit of clutter to an otherwise very clean and simple class. The AccessException is needed because the normal Map interface does not allow for checked exceptions to be thrown. The get() method on a FutureTask can throw two different types of exceptions. They need to be handled differently, so they are both caught and properly wrapped in an AccessException (a subclass of RuntimeException) and re-thrown.

Using this technique I was able to retrieve the external data if and only if it was going to be displayed to the user. And I was able to do it without breaking the separation between the view and the business logic.

Environment Configurable

2010-03-15T14:27:00Z

During our last big rails project, Bloomfire, we found ourselves integrating with all kinds of external services. Because of this we had a diverse set of environment dependent configuration variables. A consistent pattern started to arise where we would extract our configuration variables into a YAML file and then wrap the configuration using a small class wrapper. This eventually gave rise to Environment Configurable, a library that makes environment dependent configuration easy in rails.

Installation

Add config.gem “environment_configurable” to your environment.rb file
rake gems:install
rake gems:unpack

Usage

Code:

 class S3Helper
  include EnvironmentConfigurable
  configure_with "config/s3.yml"
  
  def self.connect!
     AWS::S3::Base.establish_connection!(
        :access_key_id     => config.access_key_id,
        :secret_access_key => config.secret_access_key
      )
  end
end

YAML:

production: &DEFAULTS
  access_key_id: ACCESS_KEY_ID
  secret_access_key: SECRET_ACCESS_KEY
  bucket: the-prod-bucket

staging:
  <<: *DEFAULTS
  bucket: the-staging-bucket

development:
  <<: *DEFAULTS
  bucket: the-development-bucket

test:
  <<: *DEFAULTS
  bucket: the-test-bucket

Engineer Thinking, Making People Feel Like Idiots & The Failure of Empathy

2010-03-14T23:39:00Z

Matt Legend Gemmell on Engineer Thinking:

All too often, when faced with a decision about how to implement certain functionality, engineers take the extreme position that:

A feature must be exactly what 100% of users want.

If the above isn’t true (and it almost never is), the feature must be configurable.

This binary approach is gravely wrong, and unjustly offloads decision-making onto the user of the software. We’ve all seen where this approach ends up: multi-row sets of tabs, scrolling panes of checkboxes, nested radio-buttons and a general overload of configuration.

Matt Linderman (37signals) saying Computers shouldn’t make people feel like idiots:

For those of us surrounded by the minutiae of computers all day, it’s easy to forget there’s a world of people out there who just don’t get it. And it’s not their fault. It’s ours.

Mike Monteiro (Mule Design Studio) on The Failure of Empathy:

As an industry, we need to understand that not wanting root access doesn’t make you stupid. It simply means you do not want root access. Failing to comprehend this is not only a failure of empathy, but a failure of service.

(via ignore the code)

Don't forget the basics: opening keynote of the Michigan Agile and Beyond conference

2010-03-13T18:59:00Z

The Michigan Agile and Beyond Conference brought 450 people together this weekend in Dearborn, Michigan to teach, learn and debate the broad subject of agile software development. The “beyond” part of the theme bothered me a little, for the same reason that it irritates me when I hear companies explaining that they do “practical agile”. Both statements miss the point that agile is about nothing more than delivering valuable software frequently and regularly. What can be more practical than that? Why do we need to move “beyond” that?

Ron Jeffries & Chet Hendrickson offered the best advice I heard all day in their opening keynote. Namely, to go beyond, you must travel through. Their point was that if you’re not in the “agile space” now, successfully using the core practices, then get there before you start tinkering or adapting. It reminded me of the debate in the early 2000s of whether you had to use all (then) 13 practices of XP to claim you were doing XP. Someone (might even have been Ron) responded that you’re doing XP when you’ve mastered all 13 practices and figured out which ones you need and how to use them on your project.

Chet cut straight to the chase when he said it matters what you do, because “agile isn’t any damn thing.” Ron followed that by quoting Emerson Codd: “The truth isn’t like a bunch of puppies running around where you chose your favorite.” Their talk was as casual, funny, and inspiring as always. They shared some of the simple truths about software development:

Software development is all about people (Funny Ron quote: “When I got into computing, it was not with the intention of hanging out with other people.”) Tools can’t replace or compensate for people.

Requirements need to get into the heads of the people building the software. Documents are a poor way of doing this.

If you can’t ship working software every month, try two weeks. If you can’t do it in two weeks, try one week. You learn to build software by building and shipping working software.

Waterfall doesn’t give you accurate information until it’s too late.

If your software isn’t bug free, you can’t trust your velocity.

If you’re manually testing everything your need for testers grows at least linearly with the number of iterations. You’ve got to automate some of those tests.

If you can’t refactor, you can’t do evolutionary design.

They summarized by identifying the three non-negotiable core practices to being agile:

Ship software regularly
Test as you go
Refactor to evolve the design

While their message, at least to me, was fundamentally one of “don’t forget the basics”, Chet and Ron also addressed the “beyond” part of the conference. They cited relationship to management, human resources, and dealing with projects that don’t fit in a single room as challenges that are still beyond the scope of accepted agile thinking. Ron called out Pillar Technology and Atomic Object as examples of companies pushing the boundaries of agile. They also reminded us that we have an obligation to share our experiments, both our failures and successes, to grow the body of agile knowledge. Chet added that these experiments push agile into new territory, but are still grounded in the simple statements of the Agile Manifesto.

Responsible Estimation Tool

2010-03-03T19:53:00Z

Many times during the sales process we are asked to give a cost estimation based on our early understanding of an application’s core features. In order to responsibly and efficiently estimate, we conduct a 50/90 range analysis. We use this technique because we want to establish a responsible middle ground between our optimistic and pessimistic estimates. Our estimate is appropriately buffered for the risk we see in the defined tasks.

This spreadsheet is the tool that we use to conduct our analysis. Tasks can be estimated in any time duration that you choose (i.e. hours, days, weeks). At the start of a large project we generally estimate tasks in days or weeks.

Startup Weekend in Grand Rapids

2010-02-28T22:36:00Z

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.

git-deploy to three servers in 83 characters

2010-02-26T22:42:00Z

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.

Atomic Cookies

2010-02-24T17:08:00Z

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.

"All input is evil until proven otherwise. That's rule number one."

2010-02-24T16:34:00Z

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.

One of the biggest classes of vulnerabilities out there is the buffer overflow. Richard showed a list of vulnerabilities taken from CERT’s homepage the preceding day and showed us a slide full of recently discovered buffer overflows. He told us he’s always been able to fill a slide using just the first page.

Buffer overflows are caused by feeding the software some carefully crafted input that allows a malicious user to redirect the flow of execution. Richard’s research discovered that a vulnerability can be present even when the user can’t inject bad code – it turns out that taking over the execution is sufficient. Read more about buffer overflows on Wikipedia.

We heard about an interesting technique for finding these vulnerabilities: fuzzing. This is a way of partially automating an attack. It works by feeding the target software a randomized stream of inputs and waiting until a fault occurs. These faults (and the recent inputs) can be logged and analyzed to discover an attack – for both attacking systems and for fixing your own. Richard’s team developed an ingeniously simple defense against buffer overflows, called Secure Bit. It is a very simple algorithm:

Label all input as tainted.
Forbid jumps to a tainted address.

This is accomplished with a combination of software and hardware changes. Richard adds a single bit to every word stored which indicates whether the input is tainted or not (called the secure bit). This addition can be done at the operating system level and is a relatively simple change. In the Linux kernel Richard’s team was able to make it happen in 4 lines of code. The jump protection is added at the hardware level in the processor. This was tested by making the change in a CPU emulator. The simplicity of this approach means that the instruction set doesn’t have to change and the code stays binary-compatible. For this to be installed on a system, all it would need is the updated hardware and the kernel – no other software needs to be aware of it.

Richard’s test system ran Red Hat, and they tested out a number of known exploits against vulnerable targets and demonstrated that the Secure Bit approach does protect against malicious code execution.

Read all about it on Richard’s web site.

Software GR meets on the fourth Tuesday of the month from 6PM to 8PM at Atomic Object offices. The latest schedule can always be seen at softwaregr.org. Meetings are always free and open to the public.

Better Java with Google Collections

2010-02-23T01:59:00Z

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.

Note: As I was putting this post together I read that Google Collections is now part of Google’s guava-libraries project, which has not been officially released yet.

Code Retreat GR Recap

2010-02-17T14:06:00Z

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.

Information Radiators

2010-02-08T15:23:00Z

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.

Perhaps the best example of this is the large traffic light positioned in the center of our office. The stoplight is rigged to our continuous integration monitor (which displays the integration status of all active projects), displaying an aggregate of this information. A red light points out a problem, a yellow light shows that we’re processing a recent change, and a green light means that everything is running smoothly.

Another information radiator is our Atomic Spin Blog visitor tracker, a large cork board positioned in the center of our office. Each day, after our stand up meeting, I update the chart for the previous day, making any appropriate “annotations,” like the primary source of traffic for that day. I also like to add people’s photos to the board when they create a new blog post. Last month, for instance, our shooting star Scott Miller literally jumped off the chart with his post on TDD.

These information radiators are not intended to be a sole source of information. The stoplight follows our continuous integration monitor, and the blog board is a somewhat artistic interpretation of the information already stored in Google Analytics, annotations and all. But these visual and dynamic sources of information are not just about the “what” but also about the “how.” The stoplight is able to represent in a very simple way a company value – creating high-quality, ridiculously good, tested and working software at each step. It also provides an opportunity for us to talk about our development methods with visitors to the office. In the same vein, if someone has a hugely successful blog post, what is the best way to share that information? Spam the office with a company-wide email? Tell everyone to access the analytics account themselves and keep tabs? Or is it to get out a ladder so that you can tack a big yellow star near the ceiling? There is something about yarn and stars that just works.

And how do I know? People have told me. “I really want to blog now – so I can get a star.” Okay, so that was probably sarcastic, but the chart nevertheless has the power to encourage all of us to pay attention and contribute to the blog. It makes it very easy to represent – for instance – the fact that this month’s line is higher than last month’s line, or that so-and-so’s blog posts contributed to that success. The chart provides a connection between blogging effort and the popularity of our blog. And it makes me do my job better and promote our blog like crazy.

In sum, the information radiators do more than radiate information. They do it in a way that – because it’s highly visual and fun – is able to rally the team and create excitement about the various goals and objectives we have as a company.

PS – Help me get a star by sharing this article!

Shawn Anderson to present at LA RubyConf and SCALE

2010-02-05T17:05:00Z

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).

From an early age, Shawn distinguished himself as one who enjoyed gaming. Unlike other kids who were “reading” or engaging in “outdoor sports,” Shawn was content to stay in and finish off King Hippo in Punch-Out!. Over the last couple years he has renewed this early childhood interest. Since college, he has been using his free time to develop games in Ruby; he has even created his own library for gaming in Ruby – Gamebox. Gamebox was designed to spring board game development. It allows the developer to define business rules about a game very quickly without having to worry about resource loading, sound/music management, creating windows, or messing with viewports. Shawn says he wrote Gamebox for two reasons: first, to aid in 48 hour game writing competitions and second, to allow him to write simple educational games for his kid(s). He is currently working on a game called Snelps RTS (noneducational, from what I’ve seen), and the slightly educational Free Radicals.

This workshop is intended for people who already know Ruby but are interested in writing games in Ruby. At the end of the class the participants will have a basic understanding of how 2D games work and will have created a small space invaders clone with animation and sound.

Links:

Info for Shawn’s LA RubyConf Presentation

Info for Shawn’s SCALE Presentation

Getting Started with Gamebox (Source Code)

Snelps Screenshot:

Free Radicals Screenshot:

Beyond UX and Agile

2010-02-01T22:24:00Z

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.

The case for embedding jruby-complete into your application

2010-02-01T13:11:00Z

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.)

I like vendoring the Ruby runtime for several reasons:

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.
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.)
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.