Highgroove requires everyone to attend a conference every year, and begrudgingly I agreed to head to Hawaii for Aloha Ruby. The flight was long but well worth it, the weather was amazing, and the conference was packed with useful information.

Performance is Key

The reccurring theme for the two-day event was performance. Some of the big takeaways for me were:

We’re all used to hearing that “Rails is slow,” but that’s just a quick jump to a “root cause” that doesn’t tell us anything. Rails 4 (which is creeping towards its release date) has several performance-related fixes, but slowness in an app is almost always the result of poor choices in data structures or algorithms:

• Are you requiring tons of files and gems? In MRI, Ruby’s ‘require’ compares each file you load to all the previously loaded files, making the problem exponentially worse with every file you add. This is why your Rails app takes so long to start.

• Are you using set operators in Redis without understanding their performance implications? Is there a good chance that the data you are sorting is already sorted? If you haven’t thought about the big-O impacts of your code, you’re probably doing it wrong.

Specific performance tips, including some from Richard Schneeman:

• Don’t queue web requests, as this only scales while your request is lower than your available concurrency. As soon as you hit that number, everything will fall apart.
• Set config.active_record.auto_explain_threshold_in_seconds to get details about slow queries in your log so that you can address them.
• Use the ‘cache_digests’ gem in Rails 4.
• Set config.static_cache_control = "public, max-age=2592000" to let assets cache properly.
• Set config.asssets.digest = true to fingerprint files for better caching.

Videos you should watch

There were many more interesting talks than I can talk about here, but all the videos will be up on Confreaks soon enough. Here are a few I specifically recommend:

• For some of the gritty bytecode aspects of various Ruby interpreters, make sure to watch Konstantin Haase talk internals in “Message in a Bottle.”
• Find out about building a service-oriented architecture from James Rosen in “Carson: On the Path from Big-Ball-of-Mud to SOA.”
• See how easy it is to do Bad Things with Ruby gems in Benjamin Smith’s “Hacking with Gems.”
• Watch Matt Aimonetti’s talk on mruby to find out why we need another Ruby interpreter.
• Learn 101 neat things that Ruby can do from James Edward Gray II.
• Get convinced that legacy code is good and what you want to write, after watching Chad Fowler’s “Legacy” talk.
• See what makes a Ruby library great in Mitchell Hashimoto’s “Building a Ruby Library: the Parts No One talks About.”

More than code

Lastly, were reminded that it’s not just about the code. Being a great developer means growing into new roles to build something bigger than just your own interests. What starts as contributing to open source grows into creating or maintaining a major open-source project, which grows into enabling other people to maintain the project for you (see Wesley Beary’s talk “Maintain Less, Mentor More”). Or pulling things together for designers turns into learning some key design fundamentals and getting to a minimum viable product sooner (see Glenn Gillen on “The Designers are Coming”).

I also learned that mai tais are good, and while Aaron Patterson’s cat has a twitter, cats are getting pretty played out, and several speakers chose to include photos of dogs and sharks instead. The hotel had an awesome daytime and nighttime view, and I got to sneak in some touristy things too, from sunrise on Diamond Head hike, to a luau, to ziplining.

Aloha Ruby gave me a lot of insights to new knowledge and helped me rethink things I already knew. What about you? What have you learned from the conferences you’ve attended lately?