My Professional Blog

I have been making my living for the last 20+ years following processes.  Unfortunately, I have not seen that processes have been maintained, evaluated, and evolved as they should be.  My theory is this: no one collects any metrics anymore, so no one knows how well their processes really work.

There are two adages that I believe apply:

You cannot manage what you do not measure.

What gets measured, gets done.

All too often, processes go stale or drift so far from their intent that it becomes a disadvantage to be process-driven.  If you work for such a company or even if you have your own personal processes, consider putting into place a layer where you measure parts of the process.  I don’t know what those measurements would concern, just start measuring something.

Once you have a reasonable set of data points, attempt to perform some analysis to see if you can draw any conclusions.  At a company I worked for in the past, we measured the effectiveness of peer reviews by tabulating documentation defects and code defects detected by the group and by person.  In a separate activity, we measured defects detected by our QA group and ultimately by the customer community.  My point being, we could take all this data and eventually determine our effectiveness and even predict our future performance.  Being able to predict our performance enabled us to estimate and plan much better and thus be more competitive.
If you are a company that suffers from this, you need to swallow the Red Pill and see the truth.  Measured and analyzed processes can become your Morpheus.  If you swallow the Blue Pill, you will almost certainly continue to languish within old, non-value-added processes that lead you into an uncertain future.

You should now be conjuring up an image of Laurence Fishburne gesturing you to come and get some.

advrailsdallas_5

Originally uploaded by pragdave.

This past week I attended the Advanced Rails Studio in Dallas and had a fabulous time. The picture you see is from our lunch outside on Friday — I am in mid-gesture at the near table on the left.

If you have the opportunity to go to one of these studios, I think you’ll both benefit and enjoy it at the same time. The Rails Community is filled with a smart and optimistic bunch of people who are very fun to be around.

The Studio itself was run with amazing attention to detail. I can tell you that I was very well-fed and not just with bottom-feeding food, either. Kudos to Mike and Nicole for making the logistics so automatic.

Unlike my experience at the basic Studio back in January 2006, this one involved much more discussion and debate. Just imagine 40+ knowledgeable developers getting together to share experiences. Of course, there were class notes, but these served mostly as enablements for discussion. Often, the value of the section was not in the notes, but in the discussion.

I do find that I generally am well-versed in most of the content that I see in the course notes. With the number of Rails and Ruby books becoming available and the amount of blog activity its hard not to be informed these days. So for me, the value of the course was in the sharing and reinforcement that I know the latest practices and that I know any applicable heuristics.

Bottom line: highly recommended.

We have been asked whether GeoKit could be made to support UK addresses and this is something that we’re interested in doing.  I must admit that I was incompletely uninformed as to how different these addresses really are.  Just have a look at Wikipedia has to say about UK addresses.  In specific, we’ve been asked to support this geocoding service: www.postcodeanywhere.co.uk.

So since we’re looking into this, I thought it might be a good idea to solicit other suggestions for geocoding services and address variants which GeoKit doesn’t already support, but which would be useful to the Rails community.  It appears there will be some refactoring involved, so it makes sense to do a little due diligence by broadening the input process.

So drop me or Andre a note or comment and let us know.

We just checked in code which improves the readability of GeoKit’s finders. Its quite obvious from the code, so just take a look at these examples:

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

# Find the nearest store.
stores = Store.find(:nearest, :origin => an_origin)

# Find the farthest store away.
stores = Store.find(:farthest, :origin => an_origin)

# Find within a radius.
stores = Store.find(:all, :within => 5, :origin => an_origin)

# Find outside a radius.
stores = Store.find(:all, :beyond => 5, :origin => an_origin)

# Find within a range.
stores = Store.find(:all, :range => 5..10, :origin => an_origin)

In the last couple of days, I added a couple of minor feature tweaks.

First, the finders will now all accept optional :units and :formula keys to enable you to override the units and formula used by the model by default. This makes it possible to serve distance queries in miles or kms and even to modify the formula used in the query. Overriding the formula might be important if you know the proximity is close and you don’t care about precise accuracy. It might also be helpful in the event that your dataset grows beyond that which would perform using the more taxing Haversine (:sphere) formula.

The second feature is a bit more subtle and edge case-like. If you steer away from our defaults and customize the lat / lng attributes, then the :origin was previously unable to handle taking an instance of those rows that you seek. I made a change to enable it to detect that situation. So now, you can do this. I did find one issue and that’s with the distance_from method which counts on lat / lng. Hopefully, I can add the same introspection and tidy that up as well. This will enable full customization for lat / lng attributes. Of course, you can write your own accessors to get around this, but still…

If you have any additional feedback, feel free to send Andre or I an email.

UPDATE: The update is complete, you can now compare the distance of Mappable instances which customize their lat / lng attributes when running as acts_as_mappable. If you don’t understand what this means, you probably don’t need the feature, so don’t sweat it.

On Friday when GeoKit was released, I wrote a pretty lame write-up.  I am fixing that now with some live examples.  I’m working on them as I write this, but you can check now or come back later.  They are located here.

I was amused recently when I read two of Guy Kawasaki’s recent book reviews.  The two books reviewed are The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t and Mavericks at Work: Why the Most Original Minds in Business Win.

What amused me was that I recognized myself as being an asshole (not a flattering quality).  But then I also recognized myself as being a maverick (much more admirable).  So I’m justifying the former with the theory that to be a maverick, you must also be an asshole.

The trouble with my theory is that if you are going to claim to be a maverick, you need to have the occasional win on your scorecard; mine resembles a golf scorecard (this is to say that low scores don’t win in this case).  Unfortunately, my asshole qualities to some might be considered undebatable.

And so now I subscribe to still another theory: people are a product of their environment.  So see, its not my fault after all…