One of the more distinctive aspects of the ruby language is it's aesthetic elegance. Most would agree that so far as programming languages go, ruby is a beautiful language.

At first glance, this might suggest that this so-called beauty is purely aesthetic, surface-level, and provides no real intrinsic value. This led me to hit the 'tubes and find a definition proper for the word beauty:

the quality present in a thing or person that gives intense pleasure or deep satisfaction to the mind, whether arising from sensory manifestations (as shape, color, sound, etc.), a meaningful design or pattern, or something else (as a personality in which high spiritual qualities are manifest). source

To my surprise, this definition jives quite nicely with what has been floating around in my head as beauty relates to code. The gist of those thoughts are that beautiful code makes my brain smile. It puts my brain at ease, because reading beautiful code is much, much easier than reading ugly code. Seems obvious, I know, but I've read enough ugly code to know that many programmers simply don't see the value in crafting beautiful code.

But the title of this post name-drops "business value", so where's the beef?? At this point I should clearly define what I mean by "business value". Put simply, it is that which can be measured, in some form or another (there are many other ways that beautiful code is valuable but not easily quantifiable).

Maintainability FTW

That said, the business value in the beauty of code is maintainability. The more beautiful a given piece of code, the less energy someone else exerts in trying to interpret the utility of said code, and thus, fewer resources (whether measured in time, money, man-hours, brain-power, focus) are exerted in the process of refactoring that code.

So what exactly makes a given piece of code beautiful? Following SOLID design principles in how you choose to design your code, communicative method and variable names, and following ruby conventions. The key reason these things are important as they relate to beauty and business value in code is communication. A good litmus test is simply to ask whether a piece of code clearly communicates its own intent.

In-code Communication

Communication in code is important. Reading other people's code, in my opinion, is one of the harder things to do in programming. If someone else's code is by some judgement, beautiful, this quality also communicates some level of intent of the author. Some care must be taken by the author to create code that is both meaningful and beautiful.

There are also some other side-effects of beautiful code to programmer productivity, though maybe not as quantifiable. One such side-effect is programmer happiness.

I remember quite vividly the first time I read through the sinatra source code. It is such a thoroughly-crafted piece of code, and from a consumer's perspective, it is so easy to understand what's happening. I promise you, this is not by accident. When I read code like this, it makes me happy, and it inspires me to write my own code similarly beautiful. And a happy programmer is a productive programmer.

Homework

So go read some beautiful code, and create some of your own ;) If you're anxious for a good starting point, I highly recommend sinatra. What open source projects do you find to be beautiful? We're anxiously awaiting your suggestions in the comments :-)

Make sure your ack can find haml.

Make sure when you are refactoring your javascript, and you are switching to jQuery from whatever, that you set your ajax dataType option to "script" in order to expect your Rails controller actions to appropriately respond_to format.js ... dag nabbit!

We have been contemplating using jruby for part of our project. This was only bolstered by Charles Nutter's presentation at Ruby Midwest, with such bonus goodies as Mirah.

We haven't even been back a week and we're all out of Ruby Brew. We'll have to go back to Ruby Midwest next year to get some more!

In an effort to speed up our test suite, we've been doing some digging into the rails internals. After profiling start-up times and test suite run times, we determined that a large bottleneck in the initial start-up time is our massive routes file.

When we're running the entire suite, the main bottleneck is database interaction, so the routes file is less of an issue. However, with such a large test suite, we don't run the entire test suite every time we save a file. We're only running the current working file's tests, and having to wait an extra 5+ seconds just to wait for the routes file to load feels like a real damper on velocity. We want a tighter feedback loop with our tests.

We're looking into a way to maintain a local cache of the routes file in certain situations, especially in model specs, or if we're using a tool such as spork to cache rails and other things that we don't need to re-load on every run of the test suite. We'll post our findings and results back here in the near future.

When you have a lot of merge conflicts, it can be very helpful to open all the conflicted files in textmate (or some other editor or diff tool) to resolve these conflicts. Here's the quick and easy command:

git ls-files --unmerged | awk '{print $4}' | sort -u | xargs mate

Hat-tip to Rick Bradley for pointing this out. Enjoy!

Alex said, "Git is like lady parts; their inner workings are a mystery to me."

"We need to hire more married developers," said Alex, after devouring half of a loaf of my wife's homemade banana bread.

Alex brought in some sexy new coffee apparatus. Now we can all observe him conjuring the bloom on his lovingly nurtured cups of intelligentsia.

We are neck-deep in legacy code, and started discussing a way to codify a refactoring process to streamline our efforts:

Review / Refactor Process

1. Code reading
2. Identify smells and design problems / antipatterns
3. Identify design goals
4. Identify functional and behavior goals for change

Alex has put a lot of thought towards this very topic, and has even talked about it at LA Ruby Meetup. The vision is some kind of refactor-driven development tool to carry alongside BDD in your dev toolkit.

Note: Yehuda Katz recently wrote a post explaining some of the design decisions made in bundler. It is a highly recommended read, and would likely be a good preface to this post.

There seems to be quite a bit of confusion around the purpose and utility of Gemfile.lock that bundler provides, so I thought I'd write up a quick post to clarify things a bit. If you're unfamiliar with the gem bundler, it is the new gem packaging and dependency management system that ships with rails 3, and many people, us included, have integrated it into our rails 2.3.x apps.

As Yehuda has explained in a multitude of blog posts and presentations, one of the goals of bundler is to solve the dependency resolution problem that occurs when you have many different versions of gems, many of which may rely on various versions of each other.

Previously, these dependencies were resolved sequentially as they were defined in your application's environment files, and each gem's dependencies were resolved mutually exclusive of each other. In this scenario, if you had two gems that depended on different versions of the same gem, you would get a gem "already activated" error from ruby when you go to require the other.

Now, there's a good chance you've never even seen this error, and if so, consider yourself blessed. But for clarity's sake, try the following in irb:

Now, where does the lockfile come in? The purpose of the lockfile is to have a snapshot of your entire gem dependency graph at any given point in time. This takes a lot of the finger-crossing and guesswork out of the picture when you go to deploy your application.

How? When you run the bundle lock command, bundler resolves all your dependencies and serializes the resolved dependency graph to the Gemfile.lock file. This means that bundler isn't trying to go through -- and possibly fail -- this process for the first time during a deployment. It has already done so, and the results are serialized in the lockfile, which bundler will use when you go to run the bundle install command.

At times, the lockfile can feel a bit cumbersome, but having your dependencies "locked" makes for a much more sane deployment process.