RubyConf 2013 was held in Miami and it was just as wonderful as always. In fact, I had the honor of speaking about effective debugging. But instead of writing again about speaking at a Ruby conference, I want to discuss one particular statement from RubyConf that inspired me.

Garbage Collecting

Matz, during his opening keynote, first mentioned what became a recurring theme at RubyConf 2013: garbage collecting. In this case, garbage collection isn’t referring to a mark-and-sweep algorithm, but rather to the idea that, as Rubyists, we give back to the community by helping out. And sometimes, helping out includes taking out the garbage. For example, this could mean resolving bugs or building features for an existing library or gem that you use.

I was further inspired by Mark Bates’ excellent talk on Ruby 2.0’s TracePoint API, in which he claimed that Rails makes an astonishing 122,538 method calls. That many method calls to serve one HTTP request sounds insane, so I decided to do a little “garbage collection” of my own to see if there was an opportunity for me to give back to the community. Maybe there would be an opportunity for me to isolate and identify some inefficiency that would require a nice pull request to rectify.

Hello World!

My first task was to replicate Mark’s results, so I grabbed his code. After some hacking and getting comfortable with Ruby 2.0’s Tracepoint library, I had a little cold water to throw on the 122,538 method call claim: the overhead of running a Rails application in development mode accounts for a large part of this enormous method call count.

To get to the bottom of this discrepancy, I started with the lower limit by setting up a “Hello World!” Rack application. I determined that to process a single HTTP request made via command-line curl, 947 method calls are required to process the request. That’s only a few orders of magnitude away.

Next, I set up a “Hello World!” Sinatra app. It was a little tricky to ensure that the Tracepoint code played nicely with the Sinatra framework—the Tracepoint code had to be included before the Sinatra framework. Sinatra ended up clocking in at a respectable 4,375 method calls to process an HTTP curl request.

After setting up a “Hello World!” Rails app, I found that running in development there were only 79,073 method calls for processing one curl HTTP request. I’m not sure what can account for the discrepancy of approximately 40,000 method calls for my experiment versus Mark’s presentation. Correction: In the comments below, Mark points out that he used Chrome so the 40000 less calls in my curl example is because curl doesn’t make subsequent requests for assets. He even showed a video of him creating a default Rails app, which is what I did as well.

However, I felt that using the development environment wasn’t a great comparison to Rack and Sinatra, as they don’t reload code on each request, like Rails does. It is more appropriate to compare Rack and Sinatra to running Rails in the production environment. There, I determined that Rails makes 15,136 method calls to process one curl HTTP request.

I couldn’t stop there, and went on to compare a curl HTTP request in Rails production (15,136) to a Google Chrome HTTP request (21,869). I attribute the discrepancy between curl and a web browser to the requests for assets. I also turned off turbolinks to see what the effect would be: only a few thousand fewer calls for a curl request (14,537).

Leveling up

At the end of this exercise, I had hoped to come away with a pull request that fixed some egregious inefficiency, but instead I’ve settled for a better understanding of the Ruby Tracepoint API, which should set the stage for my contributing more in the future. Even if I were to ignore all of the other benefits of attending RubyConf, I would consider this a good result. Sometimes taking out the trash may mean that I have to level up my skills!

Taking out the trash feels good. Feels real good. What garbage have you collected lately? And how has it made you a better developer?

The post Taking Out the Trash at RubyConf 2013 appeared first on Big Nerd Ranch.

In my professional career, I’ve never felt prouder than when I was accepted as a speaker at RubyConf India. I’ve spoken at numerous user groups, helped organize events, and even performed in front of huge crowds, but this was the first time I had been given the opportunity to speak at a conference.

My goal was to put together a quality presentation on debugging that would help the attendees in at least one small way. If each person, from advanced to beginner, were to walk away with at least one new insight or piece of information, then I would be happy.

I found myself achieving that much and more. I met so many friendly people at this conference, had a lot of good conversations and made a number of #rubyfriends—more than at any other conference I’ve attended. And while the accolades and interest in my talk were wonderful, discussing my work, good code and great co-workers at Big Nerd Ranch was the best part of all.

The Talks

There were many other excellent talks at the conference and I enjoyed all of the ones I attended, but I found myself most inspired by three talks in particular:

1. Siddhant Chothet’s talk on accessibility and Ruby illustrated how easily the Ruby community could improve accessibility for users and developers. This talk wowed us as Siddhant demonstrated the challenges and impressive capabilities of blind developers. I would be remiss if I didn’t note that though Siddhant did have slides, he did not read from them, as he is blind himself. Not only was this his first talk at a conference, Siddhant gave the whole presentation from memory! If you want to support his work, check out the brails project.

2. Sau Sheong Chang created beautiful music for us using pure Ruby, turning tweets into music. He shared just enough of the basics of music theory and the physics of music to walk us through his newly released muse gem. I love music and have played the piano for many years, and I look forward to creating music with one of my favorite tools, Ruby. Step one? Add a hubot script that makes use of muse in some fashion.

3. Our own Andy Lindeman gave the closing keynote. In this talk, he revealed how much we all benefit from open-source software, thanks to the many developers who have given freely of their time and effort. I highly recommend that everyone in the Ruby community see the talk. While Andy’s talk focused only on the code written in Ruby libraries, I find myself flabbergasted at how much benefit we derive from open source, free technologies when considering the full stack of operating system, database server, web server, web browsers and client-side technologies!

Next year

But a summary of a few talks alone doesn’t do this conference justice. It’s definitely a should not miss, and I’m already planning a talk for next year. I hope to see you there.

The post Inspiration and New Friends at RubyConf India appeared first on Big Nerd Ranch.

About three years ago, I worked at a product company where the central functionality in our app consisted of five or six domain models with excessive callbacks. I often found myself attacking the knotty nastiness for days at a time, trying to track down stubborn bugs.

Some time later, I stood up in front of the crowd at the Atlanta Ruby User’s Group and said, “I hate callbacks! What good are they?”

Today, I have the answer.

Let’s try an example

To demonstrate where callbacks are acceptable, let’s use the canonical Rails example, an online store.

As usual, there are Products, Orders, and LineItems, but we’ll be focusing on Orders. An Order instance has many LineItem instances. For optimization purposes, an Order keeps a copy of the total price, which is the sum of all line item prices.

On our sign-up page, we have a check box where a customer can indicate that they’re a returning customer. Returning customers get 10% off of the total price! Order#returning_customer will represent this information in the database.

Two options

So far, we’ve detailed two possible candidates for callbacks necessary to maintain the correct state of an Order:

1. Order#total_price (based on the sum of line items)
2. Order#total_price (to be updated based on whether we have a returning customer)

A naive approach would be to add callback logic to the Order model to sum all associated line items and apply the returning customer discount. However, adding a callback for #1 would violate the Single Responsibility Principle, as an Order would now be required to know about attributes of line items and how to sum them.

Here’s the correct approach.

The simple rule

An Order may have a callback for #2 because there are no external dependencies in the callback logic! That’s it. That’s the simple rule. Use a callback only when the logic refers to state internal to the object.

You may now be asking, but how does an Order then determine the total_price? That’s the responsibility of a higher-level service object that manages the interaction between Orders and LineItems, perhaps a controller action or, preferably, a plain old Ruby object.

When do you use callbacks?

The post The only acceptable use for callbacks in Rails ever appeared first on Big Nerd Ranch.

Hey, have you heard about the first Highgroove-hosted Code Retreat? We’re polishing our silverware and painting the walls in preparation[1] for helping developers to level-up their skills.

Read on to find out more.

Initially, I wanted to use this space to encourage you to “Act fast!” “Do it now!” and “Get On Board!” but our Code Retreat has already reached capacity.[2]

Most importantly, let me implore you to follow us on twitter and facebook to ensure you’re one of the first to hear about any Code Retreats we host in the future.

From the event details:

“Code Retreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of ‘getting things done,’ the Code Retreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.”

1. Not really
2. You may still add yourself to the waitlist and we’ll notify you if any spots open up due to cancellations.

The post Code Retreat Time appeared first on Big Nerd Ranch.

A long time has passed since we’ve last spoken about processing background jobs. Much has changed regarding the tools for asynchronously processing long running tasks in Ruby and Rails. Most recently we’ve favored Resque, especially now that Heroku’s cedar stack supports it.

There’s one problem with Resque. Enforcing strictly serial job semantics is impossible in Resque without custom development or limiting the number of workers.

So, NEVER use resque for serial jobs, OR read on to find how we resolved this dilemma with resque-lonely_job gem, a new resque plugin.

First, let’s review the simple solution. One queue, one worker. Voila, you now have strictly serial job completion.

However, your awesome new serial job semantics reduce throughput. What happens when only some of the jobs in your queue depend upon serial completion? We found ourselves in just such a situation recently.

Here’s the situation. One of our clients would like to offload data importing to background tasks. Due to operational constraints outside of our control and the multi-tenancy requirement of the application, we place all import jobs in the same queue. With a default Resque job and multiple workers, there exists the possibility that jobs for a given account could be executed in parallel. Since there an exists a hard dependency between jobs associated with the same account, we need to find a way to enforce serial job semantics.

To do this, we created resque-lonely_job. With Lonely_job, a worker’s before_perform hook attempts to grab a mutex lock. The interesting aspect of Lonely_job is that you may overwrite what characteristic of the job is used as the mutex.

Since the redis_key method receives all the arguments of the perform method, you can use any level of granularity to distinguish which jobs must follow the serial ordering semantics.

Now, if the worker fails to acquire the lock, the worker re-enqueues the job.

Uh oh, watch out! Here’s where you can get into trouble. Remember, we want strict serial ordering amongst jobs and there’s a distinct possibility that jobs may be re-ordered. To examine whether a job may be performed, a worker removes the first job in the queue. A possible race condition may occur where two workers acquire jobs, both of which are currently blocked due to an existing job being processed by a third worker. When re-enqueueing the blocked jobs, they may reverse the order of the jobs.

Furthermore, with the default re-enqueueing behavior of placing popped jobs at the back of the queue, there could be subsquent jobs after the two blocked jobs that are now before them!

Yikes! This is unacceptable! Moreover, all this crazy complexity is because we have no before_dequeue hook available in Resque. :disappointed: There is another way.

At this point, we have a set of arguments which are passed to the job’s perform method. We’ll subdivide the arguments into two sets. Subset A of the arguments is used as the mutex; let’s call this the account_id to give us something concrete to work with. Subset B is the actual payload that represents the key to performing the work. In Rails, this could be an ActiveRecord id so let’s call this the import_id. The general approach is to create a custom enqueue method for our Job that divorces the account_id from the import_id. Check out the sample implementation.

With this implementation, we no longer have to worry about the order of the jobs in the Resque queue as our “ImportJob:#{account_id}” contains the order of the work to be performed.

What other techniques or frameworks do you use to enforce serial job order semantics?

The post Never use Resque for serial jobs appeared first on Big Nerd Ranch.

As rubyists, we do not suffer for a lack of conferences. Nor for Rails events. Each and every one of these conferences allows us to showcase one of the foundational strengths of ruby, our community.

To be an awesome conference attendee, an amazing community member, and get the most out of any conference, follow our super easy guide to being awesome at a conference. Or, alternatively, what I did wrong at RailsConf 2012.

RailsConf 2012 wasn’t my first conference. In fact, I can officially brandish my grizzled conference bona fides now that I’ve attended rubyconf twice, railsconf, a handful of regional ruby/rails conferences, along with a few non-ruby/rails related conferences.

It has taken me a while but I finally have the Cliff Notes version of what it takes to get the most out of a conference. Following these five simple rules will not only ensure that you get the maximum value, but also that you’ll be one of the people that makes the conference more awesome.

1. Presentations are conversation catalysts.

Yes, yes, presentations are great ways for you to learn about new techniques, tools and/or war stories but don’t stress about noting every detail. Instead, focus on the high notes. What are you going to talk about with others? What further questions would you have for the speaker? After all, you can go back and get the details again later; they’re usually recorded.

2. Don’t try to do everything.

I’ve found that I do everything, and I mean everything, really well… for the first half of the conference and then I struggle to pull myself together for the last half. I attend ALL the talks, take copious notes, attend all the sponsored events, and then socialize some more… and then I crash. Pace yourself for maximum value and enjoyment.

3. Don’t work.

Don’t try to work. Don’t plan to work. Don’t plan to think about work. Instead, plan to meet people. Plan to talk about problems you’ve had. Plan to discuss solutions you’ve discovered. Plan to talk about your goals. Plan to talk about your immediate goals, your five, ten and fifteen year goals. Plan to talk about your pie-in-the-sky goals. This leads us to rule #4.

4. Do have your elevator pitch ready.

In fact, have three of them ready. What do you do? Why do you do it? What do you want to do? You should have a one sentence summary for each of these questions that acts as a great starting point for further discussion.

5. Do have business cards.

I love bump. I want bump to work and most of the time it does. But nothing compares to the speed and ease of swapping business cards. Have some. Have them on you. Give them out. And get others in return.

All the rules facilitate interactions with people. People make the conference. Make sure you are making the conference the most it can be.

What are your favorite strategies for a successful conference attendance?

Image credit: Jaco Pretorius

The post The Super Easy Guide to Everything You Wanted to Know About How to be Awesome at a Conference appeared first on Big Nerd Ranch.

The latest version of Ruby comes standard now with Comma Separated Value support built right in via the CSV library written by one of our very own alumni, James Edward Gray II. You might know CSV as the extremely portable format file used for everything from Excel Documents, to Numbers Spreadsheets, to lists of emails, to even generic data files. The CSV library is quite generic and useful by itself, but sometimes, you really need the expanded capabilities that only an Excel or Numbers document can support. Read on to find out how to generate Excel and Numbers compatible .xlsx files with Ruby.

Another Highgroove alumnus, Emily Price, recently introduced me to axlsx, a Ruby gem which generates “Office Open XML Spreadsheet documents.” axlsx provides support for charts, images (with links), automated and fixed column widths, customized styles, functions, merged cells, and more.

It is super simple to get started. Let’s check out a few of the features.

First, if you plan to use the generated file with Numbers, make sure to set “use_shared_strings” to true.

Next, after creating a workbook via a block, we’ll set up some styles to use later.

Next, we’ll create a worksheet for and add a few rows. Note that the worksheet name is limited to 31 characters.

Finally, we add a few rows using custom styles for each column, merge some of the title cells, and then serialize the file out to disk!

Here’s the completed example.

If you’re an auditory learner, you can check out my tech-talk on axlsx.

To learn more, check out the axlsx blog.

What are some other Ruby gems you love to use?

The post Use Ruby to Generate Formatted Excel Documents appeared first on Big Nerd Ranch.

Waaaayyy back in December, I had the pleasure of attending a code retreat. In that post, I discussed what I learned.

This month, I had the pleasure of facilitating a code retreat a few weeks ago. Thanks to Highgroove, TapJoy, FourAthens, and my co-coordinator Travis Douce, the Athens Code Retreat was a resounding success.

Also, a special shout out to our Code Retreat homies in South Africa led by Corey Haines, who handed off the baton to us late in their day but early in ours.

Read on to find out how lessons learned from facilitating compares to attending, how the general “You” actually means “I” in the blog title, and how many times it takes (me) to learn the four rules of simple design.

The purpose of a Code Retreat is to get better, to practice one’s craft in a setting without the pressure of “getting it done, yesterday(tm).” Throughout the Code Retreat, we emphasize the 4 rules of simple design. Another way to paraphrase them:

1. Tests pass.
2. Good naming.
3. No duplication / Don’t repeat yourself (DRY).
4. Small.

To facilitate self-improvement, we dedicate the last session of the day to the closing circle. In the closing circle, three questions are asked of every participant.

1. What did you learn?
2. What most surprised you?
3. What are you going to do differently going forward?

In my original blog post, I boldly claimed that one could code the Game of Life in 45 minutes if and only if they practice four or five times and skimp on tests. Oh, how wrong I was!

One pair, which included Andy, managed to write a completely functional version in 30 minutes. They even had time to invent their own spaceship. How is this even possible? Other groups took the fast and loose approach. “We know the problem domain. We have the technology. Tests? Where we’re going, we don’t need no stinkin’ tests!”

What was the first pair’s secret sauce? TESTS! GOOD NAMES! DRY! SMALL METHODS! SMALL CODE BASE! Amazing!

I learned magnitudes more facilitating than I did attending. I saw novel approaches that impressed and stretched my understanding of the problem domain. I saw good coding practices win out over the quick and dirty style again and again.

What have you learned when teaching that you didn’t learn as the student?

The post You Must Teach To Be Taught appeared first on Big Nerd Ranch.

In case you missed it, the awesome Globay Day of Coderetreat occurred on December 3rd. The amount of fun I experienced was unexpected and impressive! I learned some things too. Read on to find out what.

(Also, don’t worry if you missed the code retreat, sad kitten has some good news for you at the end of this post.)

I managed to make it out to Knoxville where they held the most awesome code retreat. Congrats to Brian Friesen for putting together such an excellent event.

For those not familiar with code retreats, you pair program with six different people under different constraints during each session. You delete all code between sessions. And you only work on one problem, Conway’s Game of Life.

Lessons learned:

1. You can’t code Game of Life in forty-five minutes. Or you can, if you’re really really good. Or if you’ve done it five times before in the same day and you skimp on tests and still probably not even then.

2. Sometimes you’re the teacher, sometimes you’re the student. Enjoy both!

3. C# is looking cooler and cooler. But not cool enough to pull me away from Ruby. (Sorry .NET recruiters. You can stop emailing me now. Seriously. Stop.)

4. How to make proper use of equality in ruby to generate a unique collection of items.

Let’s talk about number four!

Most of the attendees were C# developers. I was the lone ruby hold out and convinced a couple of my fellow attendees to give ruby a try. They were enjoying the ruby exploration and implementation until we hit a little snag.

I wanted to get a Set of a Point class instances. Given an array of Points, I wanted ruby to spit back out only the unique items. Overriding == didn’t work. Overriding .eql? didn’t work either. Neither did any combination thereof. Gah, this was extremely frustrating.

After a precious wasted 10-15 minutes I, mildly embarassed, threw in the towel. We moved on.. and of course, did not finish implementing GoL in ruby.

The C# devs were still impressed with ruby but I couldn’t let it go. During the lunch break, I spent some time (another 10-15 minutes) googling and came up with:

See it in action here. I based the code on a nice module implementation of equality and further discussion of equality in ruby.

The key is to override both #hash and #eql?.

Upon further reflection, my chagrin at ignorance of implementing equality in arbitrary Ruby classes was misplaced. The point of a code retreat is to practice, to get better. To learn from one another. Sometimes, even when you’re the teacher, you’re still the student. That’s one of the reasons we love code reviews so much at Highgroove).

Have you gone to a code retreat? If so, what did you learn?

p.s. Oh, I almost forgot. The great news for those of you who missed it, or want to again, is that I’m hosting a code retreat in Athens in 2012. Come check it out!

The post Lessons Learned at Global Day of Coderetreat appeared first on Big Nerd Ranch.

At rubyhoedown, the inimitable Jim Weirich gave an awesome presentation on using the debugger in ruby. Before his new found respect for the ruby debugger, Jim told us that puts statements worked just fine for him.

And this is true. You can get by with puts. But, you can get by much faster using the debugger. Read on to find out when to use the debugger and how.

Firstly, when should you use the the ruby debugger? Simple.

Actually, there is one case in which puts is better than the debugger but let’s touch on that later. For now, let us look at how to use the debugger.

1. Require ruby-debug in your source code. Use ruby-debug19 for ruby 1.9+. If in rails, add ruby-debug / ruby-debug19 to your Gemfile.

2. Wherever you would put a puts statement, replace with ‘debugger; true’.[0]

Once you’re in the debugger, you can revert to your puts using ways. puts any expression to evaluate it. Protip: or type in ‘set autoeval’ so you don’t have to use puts!! You can even set this in an .rdebugrc file. Example

The sweet spot of debugger commands.

1. n – step over the next line (don’t step into a function)
2. s – step into the next line (into a function or block)
3. c – continue until another breakpoint or execution completes
4. v l – view all locally scoped variables

For a more comprehensive overview of commands, check out errtheblog’s cheatsheet.

Now, as I mentioned before, there is one time where I like puts over the ruby debugger. When you want to view the change of data throughout the execution of a program, puts to a log file will give you a higher level overview.

Can you think of any others? How do you use the debugger?

[0] ‘debugger’ does not act like a traditional breakpoint. Instead of halting execution before the ‘debugger’ line, the ruby-debugger halts execution after. Therefore, we drop a ‘; true’ to ensure that we don’t step out of a function or into a method.

The post Debugging Best Practices appeared first on Big Nerd Ranch.