• 1997 - 2010: I was an anti-apple, Linux fanboy.
• 18 months ago: I bought an iPad (16GB) instead of a Kindle at my wife’s behest
• 17 months ago: I won a second iPad (32GB)
• 1 year ago: I bought a MacBook Pro so I could be on the same page as my Ruby coworkers
• Six months ago: I won a 13” MacBook Air
• 10 days ago: I started learning Objective-C and iOS development.
• This morning: I searched out iOS developer podcasts
• Currently: I’m planning on getting the next iPhone, the new iPad, and the Apple TV (little black box).

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?

I’ve switched my learning efforts from JavaScript frameworks to iOS development. I’m using my morning 30 minute period of time to study the ”Objective-C Programming” book from ”Big Nerd Ranch”. I’m also taking an hour out of my normal billable hours to study Big Nerd Ranch’s ”iOS Programming”.

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.

Thirty minutes doesn’t seem like much time, especially for programmers. It takes that much time just to get into the “zone”. It takes at least that much time just to research some libraries or problems. You can read a chapter of a book in thirty minutes, but can you imagine working on a project for only thirty minutes a day?

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.

In my post on ActiveRecord’s new explainmethod, I mentioned there were “two” features in ActiveRecord (introduced in Rails 3.2) I wanted to look at. This post covers the second method: ActiveRecord::Base.store.

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

When people hear the words “ceremony” and “tradition”, their first thoughts usually involve religion. Of course it makes sense, all religions have some sort of tradition and ceremony, but while some of the traditions are prescribed, many have come about from some need or requirement. Those which have come about often continue on long after the requirement no longer exists. For example, the communion plates in most Christian churches are stacked and covered to keep the flies out. Flies have ceased to be a problem in our air conditioned mega-churches of the 21st century, but we continue to protect our crackers and grape juice from them nonetheless.

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

With the release of Rails 3.2, comes a host of new features. There are two in particular in ActiveRecord which seem to have attracted a lot of attention, so I thought I would look at them each more closely. This post, as you have no doubt realized from the title, is focused on ActiveRecord::Base.explain

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

I was recently working on a project wherein I needed to present a number padded on the left with zeroes. Most languages have some sort of formatter method which would allow you to do that, but not JavaScript. Instead of following the path of other languages, JavaScript opts to give the developer opportunities to be creative.

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)

During the dot-com boom of the late 90’s, much ado was made about the many perks offered by companies used to attract developers: ping pong and pool tables, catered lunches, video game rooms, alcohol, sign-on bonuses, and oh yeah, stock options! Today, some of those perks are just running gags, but others have become standard to the modern tech company.

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.

I always look for ways to simplify my workflow, and one of the best ways I know is to use shortcuts: key bindings, abbreviations, aliases, cutting through neighbors’ yards, etc. The other day, I ran across DuckDuckGo’s search shortcuts which allow you to use bang operators to localize search to specific sites. So if you know you are looking for widgets from Wikipedia, you can type !w widgets in DuckDuckGo’s search box and see results from Wikipedia.

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.

If you are using the Geocoder gem then your tests related to geocoding are most likely hitting one of the gem’s geolocation providers. That’s probably not what you want: 1) your tests run slower; 2) you use up your request quota for your specified provider; 3) and most importantly, you are not able to control the data returned. A good solution to this is to use the fakeweb gem - and it’s really easy to set it up.

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.