Normally, this would be a cause for concern, that perhaps the feature should be avoided altogether or even removed, but callbacks are still part of Rails. Maybe the problem goes deeper.

What is a Callback?

As you likely already know, callbacks are just hooks into an ActiveRecord object’s life cycle. Actions can be performed “before”, “after”, or even “around” ActiveRecord events, such as save, validate, or create. Also, callbacks are cumulative, so you can have two actions which occur before_update, and those callbacks will be executed in the order they are occur.

Where Trouble Begins

Developers usually start noticing callback pain during testing. If you’re not testing your ActiveRecord models, you’ll begin noticing pain later as your application grows and as more logic is required to call or avoid the callback.

I say, “developers usually start noticing callback pain during testing” because in order to speed up tests or to get them to pass, it becomes necessary to “stub out” the callback actions. If you don’t stub out the action, then you must add the supporting data structure, class, and/or logic to each test in order for it to pass.

Here’s an example of what I mean:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class Post < ActiveRecord::Base
  has_many :followers
  after_save :notify_followers

  def publish!
    self.published_at = Time.now
    save
  end

  private

  def notify_followers
    Notifier.post_mailer.deliver
  end
end

describe "publishing the article" do
  it "saves the object with a defined published_at value" do
    Post.any_instance.stub(:notify_followers) # Codey McSmellsalot
    post = Post.new(:title => "The Problem with Callbacks in Rails")
    post.publish!
    expect(post.published_at).to be_an_kind_of(Time)
    expect(post).to_not be_a_new_record
  end
end

In order to get that example code to pass, notify_followers must be “stubbed out”. If it isn’t, and if followers are used within the mailer, the test will fail because it’s not able to execute the delivery (i.e. it’ll error out due to nil values).

What About Observers?

Rails developers who’ve begun moving into a more Object Oriented mindset might ask, “What about using observers instead of callbacks?” It’s the right direction: by creating an observer, you move responsibilities which don’t belong in the object being observed to the observer.

The problem is that observers in Rails are kind of like ninja callbacks: they perform the same function as callbacks, they just work in the shadows. Unless you look at the file system, you are very likely to forget Observers even exist in your application.

Furthermore, observers are assigned to their appropriate class when Rails starts up, and Rails starts up when you run your tests. Once again, you’ll start feeling pain in your tests first, because in order to avoid observer calls in your tests, you will need to either create all the dependent objects or install a gem such as no_peeping_toms. Just like callbacks, observers run every time their condition is met.

Aside: Herman Moreno wrote a good post on undocumented observer usage: Fun with ActiveRecord::Observer.

Why Are Callbacks So Problematic?

In his post on ActiveRecord, Caching, and the Single Responsibility Principle, Joshua Clayton noticed “after_* callbacks on Rails models seem to have some of the most tightly-coupled code, especially when it comes to models with associations.”

It’s no coincidence. “before_” callbacks are generally used to prepare an object to be saved. Updating timestamps or incrementing counters on the object are the sort of things we do “before” the object is saved. On the other hand, “after_*” callbacks are primarily used in relation to saving or persisting the object. Once the object is saved, the purpose (i.e. responsibility) of the object has been fulfilled, and so what we usually see are callbacks reaching outside of its area of responsibility, and that’s when we run into problems.

Solving the Problem

Jonathan Wallace, over at the Big Nerd Ranch, ran into to same problems and came up with one simple rule: “Use a callback only when the logic refers to state internal to the object.” (The only acceptable use for callbacks in Rails ever)

If we can’t use callbacks which extend responsibility outside their class, what do we do? We make an object whose responsibility is to handle that callback.

Before Example

Let’s look at a hypothetical example. This is what we might originally have:

1
2
3
4
5
6
7
8
9
10
11
12
13

class Order < ActiveRecord::Base
  belongs_to :user
  has_many :line_items
  has_many :products, :through => :line_items

  after_create :purchase_completion_notification

  private

  def purchase_completion_notification
    Notifier.purchase_notifier(self).deliver
  end
end

1
2
3
4
5
6
7
8
9

class Notifier < ActionMailer...
  def purchase_notifier(order)
    @order = order
    @user = order.user
    @products = order.products

    rest of the action mailer logic
  end
end

In the above example we can see that when an order is saved, it’s going to shoot off an email to the customer. That Mailer is going to use the order object to retrieve the ordering user and the products which were purchased and likely use them in the email. Pretty simple, right?

In a test, however, any time an order is saved to the database, user, line_items, and products will need to be created, or the purchase_notifier method will need to be stubbed out – Order.any_instance.stub(:purchase_notifier) (Ugh).

After Example

Here’s what happens when we move some responsibilities:

Our Order model is much simpler.

1
2
3
4
5

class Order < ActiveRecord::Base
  belongs_to :user
  has_many :line_items
  has_many :products, :through => :line_items
end

Here’s our new class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class OrderCompletion
  attr_accessor :order

  def initialize(order)
    @order = order
  end

  def create
    if self.order.save
      self.purchase_completion_notification
    end
  end

  def purchase_completion_notification
    Notifier.purchase_notifier.deliver(self.order)
  end
end

What we’ve done above is moved the process of saving the order and sending the notification out of the Order model and into a PORO (Plain Old Ruby Object) class. This class is responsible for completing an order. Y’know, saving the order and letting the customer know it worked.

By doing this, we no longer have to stub out the notification method in our tests, we’ve made it a simple matter to create an order without requiring an email to be sent, and we’re following good Object Oriented design by making sure our classes have a single responsibility (SRP).

It’s a simple matter to use this in our controller too:

1
2
3
4
5
6
7
8
9
10
11

def create
  @order = Order.new(params[:order])
  @order_completion = OrderCompletion.new(@order)

  if @order_completion.create
    redirect_to root_path, notice: 'Your order is being processed.'
  else
    @order = @order_completion.order
    render action: "new"
  end
end

Wrapping up

As much as I complain about callbacks, they’re really not bad as long as you remember the rule: “Use a callback only when the logic refers to state internal to the object.” And really, that can be applied to any method.

When you start to feel those first twinges of pain from your tests, whether from callbacks or otherwise, consider if what you are trying to do exceeds your class’s responsibility. Creating a new class is a simple matter, especially compared to the pain and frustration caused by not doing it.

Many thanks to Pat Shaughnessy for proof-reading and providing feedback.

Excitement, frustration, discovery, passion, elation, disappointment, hunger, failure, conquest, defeat, insight, freedom, dominance. These are not subtle words, and I’ve chosen them because they are descriptive of programming, and more specifically, growth as a programmer. Not one word standing above the others, but all of them, in any order, and of varying durations. Do you know these words? Do you know them now, or are they a memory?

I’ve been thinking a lot lately about how to determine if you’re growing as a programmer. It’s easy to see growth when you are first beginning; you see the progress of acquiring knowledge. But as your mastery increases, quantifying growth moves from that based on knowledge, toward a growth based on understanding and application. What are the metrics for determining growth then?

An Experiment

To give us an idea if we are growing, let’s try an experiment. Answer the following questions:

• List three new things you’ve learned in the last week about your current technology of preference.
• What new idea, concept, pattern, or technique have you played with or tried to use in the past week.
• What was the last technical book you read for fun? When did you read it?
• Do you program outside of work? (For fun, not freelancing)
• When was the last time you had an exciting conversation with a peer about programming?
• Do you look forward to going to work?

Did your responses to those questions give you an idea about your current state of growth? Simply put, the best metric for determining if you are learning and growing as a programmer - probably as anything - is this: “Are you having fun?”

So, are you?

Go back to the first sentence of this post. When in your programming career have you felt those words most intensely? When you were learning, right? But weren’t you also enjoying yourself? Weren’t you having fun?

Being Stuck

If you had trouble providing positive answers for the questions above, maybe you’re in a bad spot. I know what that’s like. I know what it’s like to have every idea shot down because that’s “not how we do things.” I know what it’s like to have your creativity constrained because “failure’s not an option.” I know what it’s like to want to do better, but be told “it’s good enough.” I know what it’s like to be stuck.

Being stuck is a horrible state to be in. Maybe you’re stuck because of the technology you’re using, or maybe it’s your boss or your organization, maybe it’s the system, but whatever the case, there you are, unchanging, unmoving, not growing, stuck.

Needless to say, being stuck is not fun.

Encouraging Growth

The whole premise of this post is that if you’re having fun, you’re most likely growing as a developer; if you’re not having fun, then you’re not growing as much as you could. If you’re not growing as much as you would like, then something needs to change, and maybe several “somethings”.

What follows is a list of some ideas you should try in order to rekindle your love and excitement for the art. This is not an exhaustive list, and I would love to hear from you what things you’ve tried to get the development juices flowing.

• Keep lists of researchables: I have a list - it sounds more organized than it is - I use to keep track of words, concepts, and ideas that I want to research. When I get a few minutes (between test runs) I go and look things up.
• Develop a low pain threshold: We create applications to solve problems. Pay attention to those little annoyances and find a programmatic way of solving them. e.g. Be annoyed by the way your editor behaves and find a way to fix it.
• Play more:
  • Take some time to tweak your configuration files; especially emacs, VIM, Git, or shell configs.
  • Experiment with a new library or language
  • Force a limitation on yourself: examples, try to use recursion instead of loops; use methods instead of constants; read source code in place of documentation; etc. See also Creative Limitations
  • Participate in a Hackathon
• Find other developers who are passionate and start hanging out with them, especially if they’re better than you.
  • Check out your local user groups
  • Go to conferences
  • Find a mentor
  • Find a way, but make those connections
• Start contributing to a FOSS project
• Try playing with some Arduino or Raspberry Pi projects?

The point is to play and to have fun, and to remind yourself how much fun programming is. Yeah, at times programming is difficult and sometimes it’s even a chore, but you know from your past that it doesn’t have to be that way, and you know from your experience that it shouldn’t be that way. If you are at a point where you find yourself incapable of growth, maybe it’s time for a change; maybe a drastic change.

Because, let’s face it, “If you’re not having fun, you’re doing it wrong.”

It sounds harsh, but it was really what I needed to hear. My wife worked in sales for a number of years and she recognized immediately the effort required to complete all the activities I had on my list. More importantly, she understands me and the effect it would have on me.

You see, as of this writing I am finishing up two projects and I’m gearing up to start three new ones - one which includes an unfamiliar technology. My wife knows that if I meet all my clients’ needs AND attempt to meet all ten of my marketing goals, something will have to give; probably a lot of somethings. And because I’m highly goal oriented, she knows I would beat myself up for not meeting all my expectations, and waste a lot of energy and time trying to figure out why I couldn’t get it all done.

My wife’s years of sales experience helped her recognize the obvious: I was trying to do too much. Part of what kept me from recognizing the same was my own inexperience with the demands of marketing, the rest was me blindly following recipes out of a book.

But from her insight and fresh perspective, I’ve come up with a new marketing strategy for myself which I’ve dubbed…

Workload Based Marketing

It’s not rocket science, and it’s certainly not an earth-shattering discovery, but it was eye-opening for me and where I was at. It starts with these three rules:

1. Focus on Current Clients First

Here’s the deal, you already have actual clients. Marketing represents clients you might get, and who might have money. If you have to choose between marketing and investing in relationships with your current clients, choose the latter; it’s the only decision guaranteed to pay dividends every time.

2. No Marketing Effort is Too Small

Like I said, clients always come first, but I also know none of us are heads-down 24/7. There’s always time in a week for at least something. Maybe it’s making a couple phone calls one day, eating lunch with a contact another day, or just getting a paragraph or two on that next blog post.

The point is to keep up the momentum. Momentum from small efforts can lead to big opportunities.

3. Waiting is Stupid

In “Get Clients Now”, the author instructs you to start your system on a Saturday. I had planned on starting mine on the first Saturday of the new year, after the holidays were over.

My wife asked, “Why do you want to wait to find clients?”

Ummmm….

The Plan(s)

With those rules in mind, let’s look at the plan itself.

Based on the name alone, you should already get the basic idea of “Workload Based Marketing”: if you have a lot of work on your plate, don’t push yourself to market so much; if your workload is light, increase your marketing efforts accordingly.

More than that, though, and before you start anything, devise plans for yourself which you can execute according to the intensity of your workload. To keep it simple, create three plans: one for when your workload is light; one for when it’s moderate, and then one for those times when you’re swamped. For example, I’ve created plans for myself based on possible workload, each with a variety of activities suggested from “Get Clients Now” or from my own marketing preferences.

Having these plans established ahead of time allows you to “just go on autopilot” rather than burning a lot of cycles trying to figure out what to do. You won’t need to waste time thinking about things, you’ll just be able to go. Organizing your plans around a weekly schedule is probably the simplest solution.

“Get Clients Now” is a great book, and every freelancer should read it at least once and consider the author’s suggestions. In it, she gives some great advice for getting started, setting goals, and strategies for the different stages of the marketing cycle. But remember also, no system is perfect. Adjust whatever system you settle on to match your own needs, and prepare your plans ahead of time so that when storms hit, you can be ready with something to do, rather than wasting precious time and energy.

One last thought, review your plans in light of the end goal: right clients, right projects, and right price. Make certain your strategies and tactics are aimed at the right audience. Use your time wisely on existing clients first, and then pick the plan matching your workload to find the prospects who fit the profile you desire.

For the past couple of months, I’ve been reaching out to companies, asking them to sponsor Ruby Midwest 2013, a technology conference I’m helping to organize. Every company I’ve had contact with has been super nice and many have chosen to support us either financially or with products or services. Some companies have chosen not to sponsor for a variety of reasons, and that’s cool, I get that. There are definitely reasons not to become sponsors. But in this post, I want to look at some of the results decision-makers are expecting, and some which they might not consider, and which, if they do, might change their outlook on sponsorship.

Just looking at sponsorship from a general perspective, most companies are seeking to advertise, increase brand awareness, make sales, and maybe find new employees. The hope is that the amount of money invested will be offset by what is returned. And of course this works, which is why you see some of the same companies sponsoring so many conferences.

Take, for example, publishing companies O’Reilly and Addison Wesley. I can’t imagine a conference which didn’t have books from either of these companies to give away. The results of these minor investments are advertising and increased brand awareness (people get to see the books handed out), and increased sales by way of the book recipients buying more products from the same publisher, and also from them telling their friends or writing reviews. It’s nothing but “win” for these guys.

Since I am currently seeking sponsorship for Ruby Midwest, I am a little hesitant to say this, but investing in a conference may not be the best choice for a company if it is only looking for sales and advertising. Part of the problem is that those running the conference are usually developers (like myself), and, well, we’re not really known for our ability to sell and market companies and products (or even have “normal” conversations.)

The other part of the problem is the target audience. Most people attending tech conferences are company-employed developers (i.e. not the decision-makers). So even though a company might be selling the new whiz-bang product, we may not be in a position to do anything about it other than make the case to our management, (and again, we’re not really known for our ability to sell.)

Selling books or developer tools is one thing; developers are usually the decision-makers. Selling other types of products, especially those focused on companies, are a different matter; developers, even if they’re the target audience, may not be in a position to purchase.

And so at this point you may be asking yourself, “If we’re unlikely to make sales, get a good advertising push, or increase our brand awareness, why should my company sponsor a regional conference?” In short, by sponsoring conferences, you are telling your development staff that you support them and their passion, you inform the local development community that you “get it”, and you add to your reputation as a company who understands technology. Let’s break this down a bit.

I’ve written about this before in my post on ”Attracting Good Developers”, but in short, developers want to know they’re supported and needed. You can do that in a number of ways (and you should) but one way is to invest, not just in them (which you should), but also their interest: i.e. conferences they want to attend. By doing so, it’s understood that your company is taking an interest in their growth and improvement. That matters.

When you sponsor conferences, you not only tell your own development staff you support them, but that you support the local community and you’re a company who understands technology. Believe me, we notice.

Don’t underestimate the value of this. Good developers want to work for “cool” companies, because, well, to be honest, it makes us “cool”. Not “cool” like James Dean, but “cool” as in, we are good enough to work there. This can be a huge confidence boost, and can unleash hidden potential. Developers who once just thought of themselves as the line-workers of the 21st century, might now - with the added confidence - begin to think of themselves as something more, and increase their contribution to your organization.

Used with permission from KCITP’s post: 3 Reasons Why Developers Need To Attend Hack The Midwest

Alright, let’s pretend my arguments have convinced you to sponsor a conference, which ones to you sponsor? Here are three things to look at:

1. If you’re local, stay local: If you are a company localized to a certain city or area, sponsor those conferences and developer communities resident in that area; in your market
2. If you’re big, go BIG: If you’ve got offices all over the nation or world, you should probably be sponsoring the major events: OSCon, PyCon, RubyConf, Velocity, etc. But hey, don’t forget the to sponsor the regional conferences your offices are located.
3. Stay with what you know: Unless you are trying to recruit talent from another technology area, don’t feel like you have to sponsor everything; just sponsor the conferences relevant to your company.

Tech conferences occur in every semi-major city around the globe and every company with a good development staff or who wants a good development staff should be sponsoring at least one a year. Sure, sponsorships can bring in new sales extend your company’s brand, but more than that, it can improve your company’s reputation among your own staff and in the development community.

In the end, sponsoring conferences isn’t just about investing in your company’s representation of itself, it’s really about investing in your development staff and in your company’s culture. It’s worth it.

Step 1: Creating and Configuring a New Rails App with minitest

For the sake of simplicity, we’ll assume that we’re creating a new Rails application. To do so, we’ll want to skip the standard usage of Test::Unit

1

rails new <app_name> --skip-test-unit

Immediately after this, we’ll need to install and initialize the minitest-rails gem

1
2
3
4
5

group :test, :development do
  ...
  gem 'minitest-rails', '~> 0.3.0` # as of this writing
  ...
end

bundle install and then initialize the gem in the app.

1

rails g mini_test:install

The last thing we’ll do is make sure our generators behave accordingly. To do that, add the following logic to the config/application.rb config block:

1
2
3

config.generators do |g|
  g.test_framework :mini_test, :spec => true, :fixture => false
end

This turns on minitest’s spec functionality and turns off fixture generation. If you don’t want to use minispec or if you do want to use fixtures, just alter the values accordingly.

Step 2: Setting up Cucumber

Okay, at this point we have our foundational test suite set up. Now we need to add cucumber to the mix.

Add cucumber-rails to your Gemfile as you normally would.

1
2
3
4

group :test do
  gem 'cucumber-rails', "~> 1.3.0"
  gem "database_cleaner", "~> 0.9.1"
end

Call bundle install and then call the cucumber Rails generator:

1

rails g cucumber:install

Now, add the following lines of code to features/support/env.rb. (I placed mine near the top.)

1
2
3

require 'minitest/spec'
World(MiniTest::Assertions)
MiniTest::Spec.new(nil)

For greater separation, the previous lines of code above can be added to a different support file.

Step 3: Running the Tests

At this point, everything should work. Let’s find out with a couple simple tests.

minispec Test

Create the following test file and model:

1
2
3
4
5
6
7

require_relative "../minitest_helper"

describe Foo do
  it "must be valid" do
    Foo.must_respond_to :new
  end
end

And the corresponding model file:

1
2

class Foo
end

Notice in the first line of foo_test.rb that we’re using require_relative instead of a normal require call. We do this to avoid the need to use rake. Now, rather than running bundle exec rake minitest:models and running all the models, we can execute bundle exec ruby test/models/foo_test.rb.

Cucumber Test

Create the following Cucumber “feature” file:

1
2
3
4
5
6
7
8

Feature: test
  In order to test cucumber
  a user
  wants to successfully land on the home page

  Scenario: foo
    Given I am on the home page
     Then I should see "Ruby on Rails: Welcome aboard"

And an associated step file:

1
2
3
4
5
6
7

Given /^I am on the home page$/ do
  visit "/"
end

Then /^I should see \"([^"]+)"$/ do |string|
  page.has_content?(string).must_equal true
end

Run the test and everything should be green.

1

bundle exec cucumber features/test.feature

Final Thoughts

I like minitest a lot, mainly because it’s fast, it’s simple, and it’s included in Ruby 1.9+, but there are drawbacks; the two main ones for me are its readability and the lack of integration with the vim-rails plugin. Neither of these “drawbacks” are deal breakers, however: the vim-rails plugin will eventually support it, and there are gems to make the suite more “civilized” (listed below).

So if you like the idea of a really simple and fast test suite, and you don’t mind the syntax, give minitest a go on your next project. Oh, and let me know how it works out for you.

Further Reading

• minitest on GitHub: https://github.com/seattlerb/minitest
• minitest RDoc: http://docs.seattlerb.org/minitest/
• minitest-rails: https://github.com/blowmage/minitest-rails
• including minitest in Cucumber: https://github.com/cucumber/cucumber/wiki/Using-MiniTest
• Capybara integration for minitest-rails: https://github.com/blowmage/minitest-rails-capybara
• TURN - minitest Reporters: https://github.com/TwP/turn
• PurdyTest from tenderlove: https://github.com/tenderlove/purdytest

A little over a year ago, I was invited to a BNI networking event. I thought it would be the same thing I’ve seen at any large gathering of people: people gathering to those they already know, new people getting ignored, uninteresting small talk, etc.

I was wrong.

From the moment I stepped through the door, I was greeted with a dozen hands thrust out to shake mine, people asking me my name, what I did, where I was located, then telling me their name, telling me what they did, wanting to know my pitch, telling me theirs, asking me if I was a member, if I wanted to be a member.

It was too much.

As soon as I could, I got out of the room and into a hallway, and called my wife. Yes, I wanted to talk to her, but at that moment, I also needed an excuse to escape and focus on one person. I slipped back into the room once the meeting had officially started, and counted the minutes until I could leave.

Since then, I’ve been to a number of other networking events. Each event had its own characteristics and quirks, and I’ve learned more about networking from each event I’ve attended.

Tip #1 :: No One Expects the Spanish Inquisition

Expectations are everything, and we enter in to every situation with at least some sort of preconceived idea of what is going to happen. Under normal circumstances, being a little off about what to expect isn’t a problem, but when your expectations are completely wrong, as mine were at the BNI event (and my 10th grade Geometry class), it can be difficult to recover from.

Knowing this about myself, I find it helpful to do a little pre-networking research. Not a lot, but just enough to have a better grasp of what to expect. Here are some of the things I look for:

• Setting :: Where is the event taking place?Is it a bar or restaurant? A business? On a college campus?
• Size :: How many people are expected to attend? This is an important one for me.
• Format ::
  • Is this a presentation plus networking event?
  • Is it just networking?
  • Is there a structure to the event?
• Topic :: Is there an overriding theme to the event?
• People-group :: Is the event specific to a particular profession or more generalized?

The Spanish Inquisition Sketch

Tip #2 :: What is Your Quest?

“Why are you going to this event?” Have you ever asked yourself that question? Obviously you’re going there to increase your network and meet people, but really, to what end?

Are you looking to make a sale? To find someone to partner with? Are you looking for investors, or employees? Are you going just to practice networking (don’t laugh)?

Having a purpose in going to an event can 1) help determine if you should even go; 2) help determine if the event in question is going to help meet that goal; and 3) keep you on track while you are at the event.

If you don’t have a purpose in going to a networking event, you probably shouldn’t be going.

Three Questions

Tip #3 :: Are you the Judean People’s Front?

Okay, so you know where the event is going to be and what it’s going to be like, and you have a purpose in going, the last thing you need to know is who to talk to. If you’ve figured out why you are going to the event, this part should direct you to the people you should look for.

As an example, if I go to a networking event and my goal is to find a new client, I’m not going to spend a lot of time speaking with other freelancers, except to find out if they are looking to offload a client. Instead, I’m going to target IT decision makers in the markets I’m looking to get into.

Simple, right? But as introverts, it’s a lot easier to gravitate to those people we know, and to corners we feel safe in. Sometimes, you just have to embrace the suck and talk to people.

So based on your purpose for going to the event, who are the people who would best help you meet your goals?

The People’s Front

Bonus Tip :: Why Did You Say “Good Morning”?

Okay, last point. Most networking events - thankfully - last less than three hours. That means you have that much time to acclimate yourself to the environment, figure out how to meet your goals, and then find the people you need to meet. The last thing you need to do is waste the time with small talk.

I don’t care what the Bene Gesserit say, small talk, not fear, is the mind-killer.We fall in to the trap of small talk because it’s safe and it’s comfortable, but it’s also completely forgettable. The point of networking is to connect with people. If your conversation is forgettable, what value is the connection?

So what do you talk about? I like to use some of the following questions and roll on from there:

• Why are you here and what kinds of people are you looking to connect with?
  • You will probably want to ask that less directly. The point is just to find out if there is potential value in the connection.
• What do you do? It’s cliche and small talky, but it has to be asked.
• What is your favorite part about what you do?
  • I ask this solely to ensure there is a positive experience to the time. Well, that, and it’s usually fun to see people get excited about their work/family/etc.
  • Note: I don’t ask what their least favorite part is
• What are some of the struggles you are currently facing in your work?
  • This isn’t asking what they don’t like.
  • This is discovering if you can fix their problems.
• and so on…

Silly Job Interview

As far as networking goes, I usually prefer meeting people for coffee or lunch. It fits my temperament, it’s less intense, and it generally makes for a better conversation. That’s the advice most “networking for introverts” articles provide. While more intimate types of networking fits the introverts’ personality, it doesn’t address the problem of what to do if you’ve managed to stumble into a larger event, which is to say, find out what to expect, figure out your purpose, know who you want to meet, and avoid small talk.

If all else fails, you can always hide out in the hallway and talk to your wife on the phone.

I am so completely excited about Google Fiber, I could burst, and I am terrified that rather than opening our doors to the future and to future growth, our local governments will instead see this as an opportunity to make a buck and flex its muscles.

The Internet represents freedom. We need to open our arms to it.

Ladies and Gentlemen of the Governing Body of Shawnee,

My name is Samuel Mullen. I’m a freelance programmer specializing in web and iPhone development. As such, I am very keen to learn what, if anything, has been done to encourage Google Fiber to come to Shawnee. Obviously we are some distance from the initial locations selected by Google, but they will inevitably spread out, and I am anxious for it’s arrival. I am convinced my business can only grow with its arrival: through new companies, technological improvements, and networking.

I believe the greater Kansas City metro area is in a unique position to usurp the technology crown which Silicon Valley currently wears. New businesses, new ideas, new people, and new opportunities are all on the horizon, we must be prepared to take up the mantle of Silicon Prairie.

Please let me know that you, the current leaders of Shawnee, are as excited about this technology as I am, and that you are doing everything in your power to eliminate road blocks which might hinder the arrival of Google Fiber.

Thank you, Samuel Mullen

If you live in the Kansas City metro area and you are not part of the Google Fiber rollout, I would encourage you to contact your city officials as well.

Update: August 24, 2012

The City of Shawnee did end up reaching out to Google. This is their letter.

IRB

.irbrc

Under the hood, the Rails Console is just IRB (Interactive Ruby), so anything you can do with IRB, you can do in the console. This means you can modify your IRB environment and .irbrc file to define methods to use at the console. Here are three methods I frequently use:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

\# return a sorted list of methods minus those which are inherited from Object
class Object
  def interesting_methods
    (self.methods - Object.instance_methods).sort
  end
end

\# return an Array of random numbers
class Array
  def self.test_list(x=10)
    Array(1..x)
  end
end

\# return a Hash of symbols to random numbers
class Hash
  def self.test_list
    Array(:a..:z).each_with_object({}) {|x,h| h[x] = rand(100) }
  end
end

Of course this isn’t even scratching the surface of what’s possible. Check out what other people are doing:

• Example .irbrc files on github
• What’s Your Favourite IRB Trick? (StackOverflow)

The Last Expression

While working in the console, have you ever typed out a bit of code to return a value and then realize you forgot to assign the returned value to a variable? You then have to go back into the console history, move your cursor to the beginning of the line, add the variable, and then execute the code again.

Ugh, what a pain!

Unbeknownst to most people, IRB places the output of the last command into the _ variable. Here, let me show you:

1
2
3
4

 > Array(1..10)
 => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
 > _
 => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Now, as cool as that is, you have to understand that _ always contains the output of the last expression. This means if you try call a method on it, it will then contain the output of the method executed.

1
2
3
4
5
6
7
8

 > Array(1..10)
 => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
 > _
 => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
 >  _.map {|i| i * 2}
 => [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]
 > _
 => [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

Forking IRB

When working in the console, it’s sometimes desirable to have another instance to play with. It may be that you don’t want to lose what you were working with, or you just need another scratch area, but whatever the case, you can create a new console (IRB) session by calling irb at the prompt (note: you’ll use irb for the rails console as well).

I typically don’t use this. If I need another IRB instance, I just open a new tmux pane or window and work there.

If this sort of method fits your workflow, I highly recommend reading Gabriel Horner’s in depth post on IRB commands

The Rails Console

Models

One of the things you will want to make extensive use of in the console are your app’s models. The Rails console is a great way to play with your models and an alternative way of accessing your data.

1
2
3
4
5
6
7
8
9
10
11

 > u = User.find 1234; nil
=> nil

 > u.name
 => "Foo Man"

 > u.email = "fooman@example.com"
 => "fooman@example.com"

 > u.save
 => true

The “app” object

The app object is used by test processes to mimic system interactions. Through this object, we can access routing information and even make requests to our app.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# displaying path information
 > app.users_path
=> "/users/

 > app.user_path(User.last)
=> "/users/42

# making app requests

 > app.get app.user_path(User.last)
=> 200

 > app.response.body
=>  => "<!DOCTYPE html>\n<html>\n  <head>\n    <title>..."

The “helper” Object

I really don’t think I can do a better job on this than what Nick Quaranto already did in his “Three Quick Rails console tips” post.

Reloading the Environment

If you make changes to your app while still in the console, you will need to reload your console session with the reload! command. You will also need to reinstantiate objects which existed prior to the reload for them to recognize your changes.

1
2
3
4
5
6
7
8

 > u = User.find 1234; nil

\# changes made to User model outside the console 

 > reload!
Reloading...
 => true
 > u = User.find 1234; nil

Better Output

At one time it seemed like everyone was writing a gem for improving the IRB experience, but it appears like that particular endeavor has since been largely ignored. The one project that appears to be currently active is the awesome_print gem.

I’ve used this gem in the past, and it really does improve the output and IRB experience. It also supports pry.

In a pinch, you can format the output as YAML with the y command.

1
2
3
4
5
6
7
8

 > y Array.test_list(5)
---
- 1
- 2
- 3
- 4
- 5
 => nil

Avoiding Output

Running commands in the console can get pretty noisy. Output follows every command which is run. To get around this, just end your command with a semicolon and nil.

1
2

 > u = User.last; nil
=> nil

In the above example, u still contains the “last” user record, it just doesn’t print out all the output that would normally be produced.

The Sandbox

Sometimes it would be nice to open up a console session and mess around with the data to see what happens. But if you do that, the data’s messed up. The solution to that is to lunch the console with the --sandbox flag. When launched, you can handle the data, tweak it, and destroy it, all without fear of harming any of your data.

1
2
3
4
5

rails console --sandbox

Loading development environment in sandbox (Rails 3.2.1)
Any modifications you make will be rolled back on exit
 >

Conclusion

In my workflow, the rails console is an indispensible tool. It allows me to test out ideas, access the database, run minor tasks, and even calculate basic math. I can’t imagine developing Rails applications without it, because I know how painful it is to be deprived of such a tool in other languages and frameworks.

What are your favorite IRB and console tricks?

Anyway, I needed a validator to test whether an attribute was either true or false and I couldn’t find anything among the standard validators, so I wrote my own.

Just plop this file in your app’s lib/validators directory.

1
2
3
4
5
6
7

class TruthinessValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    unless value == true || value == false
      record.errors[attribute] << "must be true or false"
    end
  end
end

In your model, add the validation like so:

1
2
3
4
5
6
7

class SomeModel < ActiveRecord::Base
  ...

  validates :field_name, :truthiness => true

  ...
end

For more information on writing validators, see Getting Started with Custom Rails3 Validators.

Perhaps it is because of this love of “good” code or perhaps it is because of what we know we can do in more familiar languages, or perhaps, even, it’s because we know what we don’t know, but it seems there is a sort of barrier between learning and using a new technology (by technology I mean a language, framework, methodology, etc.).

Rather than doing, sometimes it’s easier to continue reading and researching. “Just one more section”, “just one more chapter”, “just one more book”. It makes sense, of course, we have to have some sort of foundation upon which to build; and so we read a little bit more.

But the argument that we need to learn just a little more before we begin doing is a hollow argument: we learn far more by doing than by reading. Think back upon when you’ve learned the most: was it when you were in class listening to lectures, or in lab applying what you learned; when you read the chapter, or when you completed the exercises; when you read the API, or tried to implement it?

But the “doing” is difficult, we end up hitting speed bumps and roadblocks, we go in circles in roundabouts, and occasionally we even find ourselves in dark alleyways or hit dead ends, but eventually, if we persevere, we find our way onto the right path. It’s those little success which make all the difference. Finding out what doesn’t work is a learning experience all to itself, but it is the successes, both large and small, which make all the difference. It is the successes which provide us with the energy and motivation to continue on.

With this in mind, go ahead and write crummy code. Write obtuse, ugly, poorly thought out code. Disregard methodologies and best practices, violate principles, ignore everything which hinders you from learning and playing. Fool around and explore, find the speed bumps, the roadblocks, and even the dark alleyways; it’s how you learn and how you eventually succeed.

So to Hell with being ready and writing perfect code; go have fun. If you’re not having fun, you’re doing it wrong anyway.

Things got really weird somewhere in that mess, and I have no idea how it happened. I still see myself as a Linux guy, but I can no longer deny my appreciation for Apple products. Who says I’m closed-minded?

Many of the chapters of the “Objective-C Programming” book have exercises at the end to help the student cement what he or she has learned. As I’ve been going through them, I’ve become very frustrated with needing to open a new XCode project for each exercise. It would be a lot easier for me just to code up the solutions in Vim and compile them at the command line.

I wasn’t sure it was possible, but after a quick Googling, I ran across a sample chapter from “Programming in Objective C” which had the solution.

In a nutshell:

1. Create an objective-c implimentation file (*.m)
2. Add the necessary code
3. Compile it using the following command

1

$ clang -fobjc-arc –framework Foundation filename.m -o output_filename

For those who are familiar with GCC or other command-line compilers, that should be enough to get you started. For the rest of you, you may want to stick with XCode. Seriously, I’m not sure how long I’ll stick with this method.

You should note that writing and debugging Objective-C programs from the terminal is a valid approach. However, it’s not a good long-term strategy. If you want to build Mac OS X or iOS applications, there’s more to just the executable file that needs to be “packaged” into an application bundle. It’s not easy to do that from the Terminal application, and it’s one of Xcode’s specialties. Therefore, I suggest you start learning to use Xcode to develop your programs. There is a learning curve to do this, but the effort will be well worth it in the end.

As stated at the end of the linked article (chapter), this is not something you’ll want to use to build MacOS or iOS applications. I’m only doing things this way to simplify completion of exercises.

But if thirty minutes a day is the only amount of time you have, the question changes from “can you?” to “do you want to?”.

I get around thirty minutes to myself in the mornings before my family wakes up and I have to get everyone ready for their day. For a long while I used that precious amount of time to read blog posts, twitter, email, or pitter it away in some other manner. I’ve not done that this year.

Since January, I’ve used those thirty minutes to write ten blog posts and read three books. It doesn’t sound like much, but if I were to keep up that pace, I would have forty blog posts written and 12 books read by the end of the year. That’s not too shabby…If I were to keep up the pace.

I’ve been wanting to learn Backbone.js for a while now, but the free time I have during the rest of my day involves my family. The only time I have is my thirty minute window. So I’ve decided to use that time to work on a project using backbone.

I won’t have time to write - although I have found time this Saturday morning - and I won’t have as much time to read, but I really want to learn backbone.js.

I get thirty minutes a day. It’s not much, but it’s mine, and it’s not wasted.

Store provides a simple means of accessing and storing key/value pairs related to a model. The API documentation uses the example of a User model which has settings. “Settings” may not in themselves warrant their own model, but there still needs to be a means of accessing them. This is where Store comes in to play.

Behind the curtain, store is just a Hash which gets serialized and deserialized upon save and load. It has a few accessors added in to make it look less hashy, but the hash is still there nonetheless as we’ll see later.

Prior to Rails 3.2, if you needed this functionality you had three choices: 1) implement it yourself; 2) Muck up your table with a bunch of extra fields; 3) create another table to store all the fields.

For the sake of laziness, I’ll use the same project I used in my previous post: https://github.com/samullen/ar_explain

Setup

In our example, we’re going to allow users to toggle the different types of email they want to receive. The first thing we’ll need to do is add the field in which to store the settings.

1
2
3
4
5

class AddContactSettingsToUsers < ActiveRecord::Migration
  def change
    add_column :users, :contact_settings, :string, :limit => 4096
  end
end

You’ll likely need some space for your settings so set the string limit to something large. Alternatively, you can use text instead of string if you like, but I tend to run more conservative.

Next, we’ll need to let the user model know we’ll be using the contact_settings field as a store.

1
2
3
4
5

class User < ActiveRecord::Base
  store :contact_settings, accessors: [ :daily_email, :weekly_email, :account_email ]

  has_many :owner_restaurants
end

Well that wasn’t too difficult.

Usage

Like I said, the field used as the store is really just a hash. You can see that in the console when I retrieve the first user record:

1
2
3
4
5
6
7

1.9.3p125 :001 > u = User.first
  User Load (0.3ms)  SELECT `users`.* FROM `users` LIMIT 1
 => #<User id: 1, name: "John Galt", email: "john@galtsgulch.com", created_at: "2012-03-08 01:50:22", updated_at: "2012-03-08 01:50:22", contact_settings: {}> 
1.9.3p125 :002 > u.contact_settings
 => {}
1.9.3p125 :003 > u.contact_settings.class
 => Hash

Instead of accessing the attributes through contact_settings as you would a normal Hash, you access them as if they were attributes on the model itself.

1
2
3
4
5
6
7
8
9
10

1.9.3p125 :005 > u.weekly_email = true
 => true
1.9.3p125 :006 > u.account_email = true
 => true
1.9.3p125 :007 > u.daily_email = false
 => false
1.9.3p125 :008 > u
 => #<User id: 1, name: "John Galt", email: "john@galtsgulch.com", created_at: "2012-03-08 01:50:22", updated_at: "2012-03-08 01:50:22", contact_settings: {:weekly_email=>true, :account_email=>true, :daily_email=>false}> 
1.9.3p125 :009 > u.contact_settings
 => {:weekly_email=>true, :account_email=>true, :daily_email=>false}

As mentioned earlier, store fields are just hashes. This means you can access them and use methods on them just like any other hash. You can even add attributes not defined in the store.

1
2
3

1.9.3p125 :010 > u.contact_settings[:foo] = "bar"
1.9.3p125 :012 > u.contact_settings
 => {:weekly_email=>true, :account_email=>true, :daily_email=>false, :foo=>"bar"}

If we were to save the record and look at it in the database (without :foo => "bar"), it would look like this.

1
2
3
4
5
6
7
8
9
10
11

mysql> select * from users;
+----+--------------+----------------------+---------------------+---------------------+-------------------------------------------------------------------+
| id | name         | email                | created_at          | updated_at          | contact_settings                                                  |
+----+--------------+----------------------+---------------------+---------------------+-------------------------------------------------------------------+
|  1 | John Galt    | john@galtsgulch.com  | 2012-03-08 01:50:22 | 2012-04-04 11:23:47 | ---
:weekly_email: true
:account_email: true
:daily_email: false
 |
|  2 | Howard Roark | howard@architect.com | 2012-03-08 01:50:22 | 2012-03-08 01:50:22 | NULL                                                              |
+----+--------------+----------------------+---------------------+---------------------+-------------------------------------------------------------------+

Pros

I think many of the “pros” for ActiveRecord.store are pretty obvious: it eliminates the need for yet another table or extra fields; simplifies adding new attributes; they work just like normal model attributes. Did I mention that validations work on Store attributes? They do, and Rafal Wrzochol has a great write up on using them

So what are the drawbacks?

Cons

There are a number of philosophical reasons against using the new Store feature. The main argument against is that the data really isn’t normalized. But we’re using Rails, which means we have a tendency to abuse normalization for the sake of the application anyway.

Another minus is that dirty attributes don’t work quite as well in the Store. For instance, you can’t call User#weekly_email_changed?. The only thing you can do is check if the Store field has changed (e.g. User#contact_settings_changed?). Again, it’s not really a huge issue and I imagine this will get resolved in future releases.

Really the main “con” with regard to using store - and this really is a big deal - is that you can’t perform efficient searches on the field. The only way to perform a search is by surrounding the search term with “%” characters.

1

SELECT * FROM users WHERE contact_settings LIKE '%weekly_email: true%';

If the percent sign was just on the end, that would be one thing, but with the leading “%” it’s now the slowest possible way of searching the database.

I really think the new Store feature in Rails 3.2 is a nice feature. They’ve done it well and made its usage fairly seamless (i.e. store attributes look and act like any other attribute). If your application’s database is fairly large or if you plan on running a lot of queries against the attributes in the Store (e.g. gathering lots of metrics) you may want to use a separate table. For most applications out there, however, this is a very safe and sane solution.

Further Reader

• ActiveRecord::Store
• Ruby on Rails 3.2 Release Notes - Section 8
• Using ActiveRecord::Store with Rails 3.2

Businesses have ceremonies and traditions as well, only we call them “processes” and “systems”. In the world of programming we call it “technical debt”. Regardless of the name used, the only way to reduce what is unnecessary is by refactoring. The best definition of refactoring that I am aware of was provided by Martin Fowler:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Businesses refactor all the time, but again the terms are different: “streamlining processes”, “downsizing”, “pivoting”, and “reorg” are only a few examples. But in the world of programming, we don’t always have the luxury of refactoring like we want, and we really want to.

When you refactor in business, there is usually some sort of immediate, “tangible” result: Suzy, Johnny, and Sally were axed so now our expenses are x amount less. In programming, if I refactor a library of code, the end result may only be that I increase its readability. How do you quantify that? When it can’t be quantified, refactoring is only seen as an expense and something to be avoided, and so the technical debt grows.

As alluded, the results of a refactoring are not always measurable. There are certainly instances which result in measurable improvements, but improvements such as increased performance are not always important. So why allow your development staff time to refactor?

Although “increased performance [is] not always important”, it oftentimes is. With increased performance and efficiency come reduced hardware requirements, translating into either lower expenses or greater output. If you have a website, it means a better user experience, greater retention, and increased revenues. Look at some of these stats provided from Velocity 2009:

• Bing - Bing found that a 2 second slowdown changed queries/user by -1.8% and revenue/user by -4.3%. Google Search found that a 400 millisecond delay resulted in a -0.59% change in searches/user
• Google - One experiment increased the number of search results per page from 10 to 30, with a corresponding increase in page load times from 400 milliseconds to 900 milliseconds. This resulted in a 25% drop-off in first result page searches.
• Shopzilla - A year-long performance redesign resulted in a 5 second speed up (from ~7 seconds to ~2 seconds). This resulted in a 25% increase in page views, a 7-12% increase in revenue, and a 50% reduction in hardware.

But application performance is only part of the picture, if your application or system has customers - and it does - then those customers are going to want the occasional change made or problems addressed. The time it takes to accommodate the request is proportional to the complexity of the system (i.e. the more complex the code, the longer it’s going to take).

By providing your development staff time to refactor, you not only shore up an application’s foundation, you reduce the cost of future development. In other words, decreased complexity equates to increased productivity, resulting in happier customers.

There is one more consideration with regard to encouraging regular refactoring, and if the truth were to be told, it’s my whole motive for writing this post: working with code that has a high technical debt is miserable and it’s a morale killer. When you know that each new feature request or bug fix that comes in will require sifting through years of spaghetti code, the sense of dread becomes palpable. Who wants to work in a system where any change, any minor tweak, could result in hours of bug hunts, shoring up crumbling foundations, and frustration? So developers avoid and procrastinate, and sometimes we start looking for a new job and a new system.

I’ve worked in shops where management allowed the development staff to either completely rewrite or perform a massive overhaul on a system, and the immediate improvement in developer morale was dramatic. We began talking about work again, how to do things right, how to make it faster, we began caring about what the customer wanted again, and we weren’t dreading coming to work each day.

Of course, I’ve also worked in shops where refactoring was too “expensive” for the company. It’s one thing to “overhaul” a project which has been neglected for too long, it’s quite another to have to build upon what is already there. It’s like the difference between cleaning a house owned by a “hoarder”, and being forced to live in one.

Technical debt creeps in to every project, and that’s okay. The point is to manage it, and the only way to manage it is by regularly refactoring your code and your design. If allowances are made for refactoring with each bug fix or new feature, keeping the technical debt low is a small investment. If allowances are not made, well, it’s kinda like the differences between patching a house’s foundation and mudjacking it. Either address the problems in the foundation as they arise or watch the house it’s supporting slowly come crashing down.

Further Reading

• You can’t refactor without tests. Find out why Tests are Pain
• You should be reading Martin Fowler
• You should Refactor Mercilessly
• More than you really wanted to know on Technical Debt and Paying Down Technical Debt

This may come as a shock, but explain is only new in Ruby on Rails; it - or similar features - has been around in the database world forever. Stated most simple, “The EXPLAIN statement provides information about the execution plan for a SELECT statement.” (MySQL 7.8.2. EXPLAIN Output Format) In other words, when you explain a query, the database returns information about how it is going to go about finding all the data. It’s a very useful tool which can help developers uncover why queries are running slowly and what might be done to speed them up.

Let’s look at an example so we can see the value of explain.

Schema Setup

We’ll need a couple tables with data for our example. I’ll use users and user_restaurants.

1
2
3
4
5
6
7
8
9

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :name
      t.string :email
      t.timestamps
    end
  end
end

1
2
3
4
5
6
7
8
9
10

class CreateUserRestaurants < ActiveRecord::Migration
  def change
    create_table :user_restaurants do |t|
      t.integer :user_id
      t.string :name
      t.boolean :like
      t.timestamps
    end
  end
end

The users table is self-explanatory. user_restaurants, on the other hand, is a table of restaurants a user likes (I guess that’s self-explanatory as well.)

Well need a couple of users, so let’s add them here.

1
2
3
4
5
6

class AddUsers < ActiveRecord::Migration
  def up
    User.create(:name => "John Galt", :email => "john@galtsgulch.com")
    User.create(:name => "Howard Roark", :email => "howard@architect.com")
  end
end

And our users will want to “like” or “dislike” restaurants, so we’ll need to create the liked restaurant records. I’ll name the restaurants “Restaurant n” to save myself from having to come up with 100,000 restaurant names. We’ll split those restaurants between the two users and define 20% of them to be restaurants the users did not “like”.

1
2
3
4
5
6
7
8
9

class AddRestaurants < ActiveRecord::Migration
  def up
    users = User.all

    100000.times do |i|
      UserRestaurant.create(:user_id => i % 2 == 0 ? users.first.id : users.second.id, :name => "Restaurant #{i}", :like => i % 5 == 0 ? false : true)
    end
  end
end

Model Associations

The last thing we have to do is associate the users table to the user_restaurants table.

1
2
3
4
5
6
7

class User < ActiveRecord::Base
  has_many :user_restaurants
end

class UserRestaurant < ActiveRecord::Base
  belongs_to :user
end

Explain Round 1

Okay, we’ve created our tables and populated them with data, and we’ve got our models and associations. Let’s run a query to find “John Galt’s” favorite restaurants and see what’s going on.

1
2

User.where(:email => "john@galtsgulch.com").
  joins(:user_restaurants).where("user_restaurants.like = 1")

When I run this from the Rails Console, explain kicks in automatically and returns the table below (this is output from MySQL, PostgreSQL looks and is worded differently). “Active Record monitors queries and if they take more than [config.active_record.auto_explain_threshold_in_seconds] their query plan will be logged using warn.” (What’s new in Edge Rails: EXPLAIN)

Note: To manually execute explain on a query, just append .explain to it.

1
2
3
4
5
6

+----+-------------+------------------+------+---------------+------+---------+------+--------+--------------------------------+
| id | select_type | table            | type | possible_keys | key  | key_len | ref  | rows   | Extra                          |
+----+-------------+------------------+------+---------------+------+---------+------+--------+--------------------------------+
|  1 | SIMPLE      | users            | ALL  | PRIMARY       | NULL | NULL    | NULL |      2 | Using where                    |
|  1 | SIMPLE      | user_restaurants | ALL  | NULL          | NULL | NULL    | NULL | 100041 | Using where; Using join buffer |
+----+-------------+------------------+------+---------------+------+---------+------+--------+--------------------------------+

The columns you’re going to be most interested in are “key” and “rows”. The “key” columns lists the indexes, if any, the database uses to find data. “The rows column indicates the number of rows MySQL believes it must examine to execute the query.” 7.8.2. EXPLAIN Output Format

In the output above, we can see that the query would use no indexes, and would have to search through 100,041 rows (Hey, that’s more rows than are in the database). “For InnoDB tables, this number is an estimate, and may not always be exact.” 7.8.2. EXPLAIN Output Format

Database Refactoring

Let’s add some indexes to a couple of the key table columns and see if we can’t reduce the pain.

1
2
3
4
5
6
7

class AddTableIndexes < ActiveRecord::Migration
  def up
    add_index :users, :email
    add_index :user_restaurants, :user_id
    add_index :user_restaurants, :like
  end
end

Now, when we run our query it still issues an explain (because it’s a really stupid example), but we now see how adding the indexes improved performance.

1
2
3
4
5
6

+----+-------------+------------------+------+------------------------------------------------------------------+-----------------------------------+---------+---------------------+-------+-------------+
| id | select_type | table            | type | possible_keys                                                    | key                               | key_len | ref                 | rows  | Extra       |
+----+-------------+------------------+------+------------------------------------------------------------------+-----------------------------------+---------+---------------------+-------+-------------+
|  1 | SIMPLE      | users            | ref  | PRIMARY,index_users_on_email                                     | index_users_on_email              | 768     | const               |     1 | Using where |
|  1 | SIMPLE      | user_restaurants | ref  | index_user_restaurants_on_user_id,index_user_restaurants_on_like | index_user_restaurants_on_user_id | 5       | ar_explain.users.id | 25010 | Using where |
+----+-------------+------------------+------+------------------------------------------------------------------+-----------------------------------+---------+---------------------+-------+-------------+

Improvements

Looking at the new explain output, we see two things: 1) the query is now using the indexes we created; and 2) the number of potential rows that have to be searched through has been quartered.

It may not seem like a big deal that we went from two to one for the search by email, but imagine if you had 10,000 users, and by using the index here it was still able to go directly to that one record. And if the data we were searching for was something other than a boolean, as it is with the “like” column, we would be able to further reduce the number of potential records through which were searched.

Of course, if we didn’t have our handy dandy explain tool we might not even have realized it was a database problem to begin with.

As I alluded to in the beginning, there is nothing new about explain. It’s an excellent tool which provides insight into what course of action the database will take to find the data you are searching for. I’ve been using explain for some time directly from the database command line; it’s nice to finally have it accessible from the Rails Console.

I’ve purposely ignored the various implementations and configurations of explain in order to focus more on why it’s useful. If you are interested in configuration and implementation, check out What’s new in Edge Rails: EXPLAIN.

Further Reader

• What’s new in Edge Rails: EXPLAIN
• MySQL: EXPLAIN Output Format
• MySQL: Optimizing Queries with EXPLAIN
• SQLite: EXPLAIN Query Plan
• PostgreSQL: Using EXPLAIN

After a quick search, I ran across a very elegant solution from Pau Sanchez which I have turned into a the following function and added some smarts to allow the padding to be changed as necessary.

1
2
3
4
5
6
7

var lpad = function(value, padding) {
    var zeroes = "0";

    for (var i = 0; i < padding; i++) { zeroes += "0"; }

    return (zeroes + value).slice(padding * -1);
}

Note that this doesn’t account for numbers which are longer than the padding value; they get cut off. Most of the time you deal with left padded numbers, you’re dealing with a fixed width and this isn’t going to be a problem. I’ll leave it as an exercise for the user, if this is not the current case for you.

Here it is again in CoffeeScript:

1
2
3
4
5

lpad = (value, padding) ->
  zeroes = "0"
  zeroes += "0" for i in [1..padding]

  (zeroes + value).slice(padding * -1)

A lot has changed in the past fifteen years, but not the need for good developers. The big companies still offer all the crazy benefits to attract top talent (just think of every story you’ve heard about what it’s like to work at Google), and sometimes they just buy companies to acquire the developers therein.

For the sake of argument, let’s assume you represent a smallish company which has established itself to some degree and you’re looking to bring on new developers - and by “new developers”, I mean developers who care about the work they produce (i.e. hackers). With so much demand for these developers, how do you compete?

It should come as no surprise that the first thing you must do is to understand how developers think. We’re a different lot. We don’t stop working just because we’ve left the office; we hack on our own projects, we do side work for more experience, and we attend user groups and contribute back to our technical communities. We live and breathe technology; it’s who we are. Understand this, and you’re halfway there. Learn to encourage this in us, and you’re home free.

Attracting developer interest really isn’t hard, it just requires putting your name and support behind what we’re interested in. Here’s just a sample of things you can do:

Support Local User Groups

Although developers are generally thought to be introverts, we do enjoy getting together to share ideas and new technologies. One of the ways we do this is by going to user groups, and companies which support user groups are generally seen in a favorable light.

Supporting user groups is cheap and easy. The simplest, and possibly the most appreciated, thing you can do is provide snacks, food, and/or beverages. It doesn’t have to be extravagant, snack trays, pizza, sandwiches, or soda is good enough.

Another way you can support local groups is by providing a place to meet. It’s not easy to find a meeting place once a group begins to grow, and providing that meeting spot will be greatly appreciated. What better way to get your name out there and scout new talent than to open your offices to these groups?

One last thing about user groups, they oftentimes need speakers, so encourage (don’t coerce) your own developers to speak.

Coding Competitions and Hackathons

Not only do developers get together to discuss technologies, we get together to play too. Most languages have some sort of competition (Rails Rumble, Node Knockout, Django Dash, etc.); major open source projects often have bugmashes leading up to new releases; and new projects or releases may announce hackathons to build excitement in a product or release.

Support for these sort of events is similar to supporting user groups. Providing snacks and beverages, a place to meet, and your developers would all be welcomed. Your support and name will be remembered.

Technology Conferences

Unlike user groups and hackathons, involvement in technology conferences requires a greater investment in money, time, resources, or a combination therein. With the increased expenses, however, comes an increase in visibility.

Running a conference is expensive, and the organizers are usually really good about promoting sponsoring companies. Blog posts, “Sponsor” pages, Twitter and Facebook posts, T-shirts, and in-conference announcements are just some of the ways sponsors get promoted.

Whereas user groups may average ten to twenty developers, conferences often have 150 or more (some of these being “rock stars”). By supporting the conference, showing genuine interest in the developers, and by being available to talk, your company should have no problems attracting developer interest.

Like I said, attracting developer interest isn’t hard, but drawing us in is a little different, because we need to know that who your company appears to be lines up with who your company really is. There are at least three things your organization can do to show that you are developer-friendly: Give back to the community; Encourage a hacker culture; Support your current developers.

Giving Back to the Community

Chances are, your organization is using open source software, but chances are also that your organization is not giving back to those same projects. I’m not necessarily talking about money, although open source projects are always happy to receive contributions, I’m talking about giving code back to the community.

In his post, ”Why Open Source Company Culture is Important”, Michael Bleigh expounds upon why it’s important for companies and organizations to open source as much as they can. For our purposes, this one quote says it all:

Why do you care about happier developers? Well, every company should care about happy employees, but software development is a black magic mix of science, artistry, and craftsmanship. While some work can be done by “forcing it”, a good deal of that work requires inspiration and passion, something you won’t be getting out of developers that feel stifled and isolated from the development community at large.

Open source makes developers happy. You want happy developers. When you open source your code, you are showing that you “get” the community and that your organization is developer-friendly.

Encouraging a Hacker Culture

Creating a culture within a company is no small feat. In many companies, culture arises naturally, but in others, such as Apple, culture is actively developed and nurtured. And while there is not enough room in this post to describe all that goes into defining company culture - and I am in no position to speak to that - I would like to provide some tips which can allow a hacker culture to be born and grow.

Support Failure

I have worked in companies in which there was no room for failure. It’s stifling, it’s demotivating, and it’s a horrible condition to work in. “When there is no room for failure, there is no room for creativity.”

Failure happens a lot in computer programming. It happens because programmers are human, but it also happens because we’re trying new ideas and we’re growing in our discipline. Failure is a part of growth, so continue to support your devs when they stumble, and celebrate them when they succeed.

Support Experimentation

Technology is changing rapidly, and nowhere is that more clear than in programming. By allowing your developers to experiment with new technologies, they get a feel for what direction the industry is going and how the organization will inevitably need to respond.

Besides allowing your developers to test out new technologies, encourage them to try out new development techniques as well. Pair programming, standing desks, test driven development, Agile software development, and open seating arrangements can all ignite developer excitement.

Let’s face it, we are talking about getting your developers to try to be more productive, should there ever be a reason not to do that?

Support Play Time

You probably already knew this, but Google has the concept of 20% time. The idea is that employees are allowed to use 20% of their work time to work on side projects they find interesting . It is estimated that 50% of all of Google’s products have come out of “twenty percent” projects, including Gmail, Orkut, Google News, and AdSense. (source)

20% is a lot of time, and Google can really only do that because they are overstaffed compared to many companies. But what if you took a couple days a month (10%) to allow your developers time to work on something completely new?

Red Nova Labs, a local Kansas City tech company, recently embarked on what they called Operation Launchpad. The whole company took an entire week off and organized themselves into smaller teams to work on completely new business ideas. The result, as I understand it, is two completely new products which are already close to launching. What could your company do in a week?

Support Your Current Developers

Finally, support the developers you currently have on staff. Are we the most business-savvy people? No. Do we know technology and where it is going? Unquestionably. If you really want to support your developers, then listen to them. Yes, we’re nerds and geeks, but as John Stewart recently noted, “I believe the term you are looking for is ‘expert’.”

I can’t stress how important respect is. Most developers I know would rather take a cut in pay and be valued, than be payed well, but whose voice went unheard. If you do not value your developers, one of three things will happen: 1) they’ll leave (most likely); 2) they will work less on work, and more on their own interests; or 3) they will become the replaceable cogs you imagine them to be.

Unfortunately for your organization, it is a seller’s market. We know we are in demand and we use that knowledge to leverage what we want. What is fortunate for your organization, however, is that most competing companies don’t know how to make developers happy - pool tables and free beer just aren’t enough. Furthermore, developers don’t always know what kind of environment they be happiest in. But if your organization can show outwardly that it at least tries to support the community developers live in, and internally provide an environment in which developers can thrive, there should be no lack of good developers from which to choose.

Update 20120306: So what do you do once you’ve attracted developer attention? Jeff Atwood wrote a great post on ”How to Hire a Programmer”. You should go read it; he’s wicked-smart.

In discovering DuckDuckGo’s shortcuts, I stumbled upon a similar ability in Google Chrome. Normally, if you wanted to localize your search to a site such as GitHub you would enter site:github.com linux in the location bar. After following the steps below, you will be able to type gh linux to localize your search to GitHub.

Step 1 - Preferences

In Google Chrome, open up the preferences page. You can do that by typing “about:settings” in the location bar or by going through the menu.

Once there, click the “Manage Search Engines…” button.

Step 2 - Edit an Existing Entry

Look through the list of available sites and select one which you search frequently. Now, click on the entry in the second column and change the text to something simpler and easy to remember: if it’s ”github.com”, change it to “gh”; if it’s ”catch.com”, change it to “c”; etc.

Step 3 - Search Using the New Shortcut

Now that you have tweaked your search engine preferences, you can use your shortcuts to localize search. Open up a new tab and type one of your shortcuts followed by a space or tab. Notice that when you type the space/tab, the location bar adds a “Search” highlight area to show you what site you are actually searching. Go ahead and add your search query after this and hit enter.

Cool, right?

Bonus Step - Adding Your Own Sites

If the site you want to search is not listed, you can add it. Go to the bottom of the list of sites on the preferences page. In the last entry, fill in the three fields: “Search Engine”, “Keyword”, and the search address.

To determine the search address, you’ll need to go to that site and perform a search. Highlight the portion of the location bar which contains the URL and the query string, and paste that in to the third column of the new entry. Now, just replace the search term you used on the site with a “%s” and you’re finished.

For the image above, I would change “https://kippt.com/#/search/vim” to “http://kippt.com/#search/%s” in the “search address” field.

I’m really just tickled to have found this feature in Google Chrome. I’ve been using it a lot since finding it, and I’ve set up several shortcuts which I’ve been making heavy use of: GitHub, kippt, catch, and rubydoc.info to name a fiew. It reduces clicks, it simplifies my workflow, and it makes the web a nicer place to live.

The Steps

First, add fakeweb to your Gemfile under the :test group and then “bundle install”.

1
2
3
4
5

group :test do
  ...
  gem 'fakeweb'
  ...
end

Now, put the following code in a file under spec/support (or test/support). I use geocoding.rb, but you can name it anything you wish.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

google_json = <<-JSON
{
  "status": "OK",
  "results": [ {
    "types": [ "street_address" ],
    "formatted_address": "45 Main Street, Long Road, Neverland, England",
    "address_components": [ {
      "long_name": "45 Main Street, Long Road",
      "short_name": "45 Main Street, Long Road",
      "types": [ "route" ]
    }, {
      "long_name": "Neverland",
      "short_name": "Neverland",
      "types": [ "city", "political" ]
    }, {
      "long_name": "England",
      "short_name": "UK",
      "types": [ "country", "political" ]
    } ],
    "geometry": {
      "location": {
        "lat": 0.0,
        "lng": 0.0
      }
    }
  } ]
}
JSON

FakeWeb.register_uri(:any, %r|http://maps\.googleapis\.com/maps/api/geocode|, :body => google_json)

To reference the above file in Cucumber, add the following line to your features/support/env.rb file:

1

require Rails.root.join("spec/support/geocoding")

The Explanation

Even though there is a lot of text in the geocoding.rb file, there really isn’t much going on. In the “here document” (the parts between google_json = <<-JSON and JSON) a big blob of JSON data gets assigned to the google_json variable. That’s it.

On the last line, we tell the FakeWeb gem that any call to Google’s API needs to be captured and then return a blob of JSON data (what’s stored in the google_json variable) “successfully”. Note that the URL used above is a regular expression and is only a portion of the full address in order to capture everything sent to that location.

It is entirely likely that you are using an alternate provider to Google. If this is the case, you will need to retrieve the appropriate JSON data yourself. You can find this data in the Geocoder test fixtures. Look for the files beginning with your provider and ending with “madison_square_garden.json”.

Alternate URLs for providers can be found in the Geocoder “lookups” files. The URLs reside in the query_url method.

If you’ve done everything correctly, your test should now stay local to your machine and return only the data you’ve specified. From here, you can set up tests for failures, alternate geolocation providers, specific latitude/longitude coordinates, and more. You now have all that is necessary to test geolocation calls.