The Agile Developer

Just to make sure my message was clear at Railsconf...recursion is actually pretty cool & powerful...recursion in the database isn't cool :)

Now more recursive hasselhoff for your viewing pleasure:

Here are my slides and code samples from my RailsConf 2010 talk. Hope you all enjoyed it.

I've been home two weeks now since training a group of developers in Rwanda how to build better software faster using ruby on rails.  Because of Rwanda's recent history, they now get significant donor money to help develop the country. Unfortunately there is not a lot of transparency where the money goes and some figures point to about only 20% of the money for aid really going to help the people of the country. I normally think of aid work as being on the ground helping with starvation, clean water or something else on the ground but I realize now how much can be done to help people using IT skills. Software can signficantly improve the lives of people in developing countries by building better health systems, enabling aid work to be more efficient or making the flow of money and how its used more transparent. 

Traditionally when a developing country needs software they hire some pricey london consulting firm and purchasing crazy costly licenses. Our work was to enable programmers in Rwanda to build the software themselves using free open source tools like ruby and ruby on rails. I liken it to the old proverb about "giving a fish for a day or teaching someone how to fish for a lifetime".

I believe this model of enabling local talent to build their own software cheaply has enormous potential to increase the effectiveness of aid money and improve the quality of lives of those in developing countries.

I've decided to scrap my old blog of over 5 years and all of it's posts except the very few that get the most traction. I'm hoping the move to posterous and their easy way to post encourages me to write more since it has been about 2 years since my last post.

Capistrano makes an assumption that all servers in your application stack
share the same credentials. As much logical sense as this makes, in large
enterprise landscapes it is often not a reality. The nature of this world
(Enterprise) is that trying to shift the mindset of all shareholders
(infrastructure, support teams, security, etc) and then changing long running
practices is not always feasible. This is especially true when doing so on
numerous severs servicing numerous other systems that depend on the already in
place mismatched credentials. For us...we have our normal application servers
and database servers that DO share matching credentials. But along with them
we use a separate server env to store and host our assets (images, css, js)
with its own credentials.

Still desiring to leverage capistrano for its core automation benefits we had
to monkey-patch capistrano so we could supply server specific username and
passwords. Drop this in your lib folder or somewhere else more relevant.
WARNING: This is basically cut-paste from the capistrano internals with some
added sugar - I take no responsibility for the class design and multiple
responsibilities in this rather big method.

This is a core class in the capistrano library. it is overridden so that we can support servers that have different user names and passwords

Your capfile will look something similar to this:

After you configure a resource in your rails routes configuration, you have
access to generate named routes with _path and _url. The main difference
between _url and _path can be demonstrated in the following example.

we can now do the following:

#### _path versus _url

So when do we use one over the other?

The current school of thought is that in the view we use _path (i.e. person_path) as everything is relative to the current url. When we need to do any redirection in the controllers we would use _url (i.e. person_url) because the browser needs a absolute url for redirection.

The perceived advantage of relative paths (_path) in our view is that the less characters you have like href="/people/1" over
href="http://localhost:3000/people/1" then therefore less the bytes that have to be passed across the wire. That is good to note but by using _path in views you are potentially setting yourself up for some problems. Primarily reverse proxy issues that still continue to plague rails. If our rails application is sitting on a server, lets say http://app1.server.com, but we have it behind a load balancer and other various reverse proxies (i.e. single sign on) so that it is publicly accessible with url of "http://my.doman.com/rails-app/" then we will have some troubles. There are several issues to note with the reverse
proxy problems and there are various solutions but for the sake of staying on topic lets only look at the _path _url problem. Standard views generally are fine with relative paths as they will generate '/person/2' so the browser typically will look at the url in our example as "http:/my.coman.com/rails-app/people/1". But any view rendered from an ajax request is going to look to the browser like "http:/my.coman.com/people/1" omitting the sub directory "rails-app".

My suggestion is that if you are not 100% sure of your deployment environment when initially developing a rails application, program a little more defensively for the sake of a couple bytes and use _url named routes instead of _path for all urls. By doing this you can be a little more prepared to adapt to your production environments as all the reverse proxy fixes will only
work with absolute urls and not relative ones.

My article on aspect oriented programming has been published on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/AOPArticle.asp).

Anyone that has worked with me knows that I am anti-datasets and pro-creating
custom business object/entities. Microsoft has spent some time making their
controls, like the _DataGrid_, work very cohesively with the _System.Data_
classes (primarily _DataTables_ and _DataSets_). To take advantage of the same
functionality with my custom collections I have to implement the
_IBindingList_. The _IBindingList_ is the interface that is at the root of the
_DataTable_ and is what the _DataGrid_ and other controls use to effectively
bind data to the UI.

**Sorting**

Along with having a collection of my custom objects, I need a way to sort the
list. I had created a class called _ObjectComparer_ and it implements the
interface _IComparer._ This is the interface the sort method on the
_ArrayList_ accepts as an argument. I created this along time ago but recently
a co-worker brought to my attention another fellow Milwaukee developer that
[implemented something very similar ][1] on his blog.

He did a decent job except that in his example the comparer only compares on
properties of objects that are of type _int, double, string, and DateTime_ and
has a method to handle each specific type. The advantage of using the comparer
I provide below is that it doesn't care or need to know about the type of the
property on the object you are comparing against, as long as the type
implements _ICompareable_ interface (The _IComparer_ counterpart). Many types
in the .Net framework already implement this interface (including the _int,
double, string, and DateTime_). Plus if you create a custom class, you can
also extend your class with it's own implementation of how to compare itself
against another object of the same type by implementing the _IComparable_
interface. This really demonstrates the power of interfaces because my
_ObjectComparer_ code never needs to change to handle any specific types
because it only deals with the _IComparable_ interface. Where as with the
other developers sample, everytime you wish to be able to compare on another
type, you have to edit his object comparer. Below is my implementation of a
_ObjectComparer._

**MultiKey Comparison Sorting**

I first saw the other developer's custom object IComparer last week when he
[posted ][2] on how he changed his original implementation to now handle
multiple properties to do the comparisons on to sort. My co-worker suggested
that we may want to implement the same functionality. When I saw what the
author had changed the inner workings of his class by modifying it, alarms
went off. This is a big violation of the [open-closed ][3]object oriented
principle. Basically the open-closed principle means the "Objects should be
open for extension and closed to modification." By extension, the principle
means either by preferably using inheritance or composition. Modification
means going into "already working" classes and changing implementation -
potentially making your class unstable. So instead of modifying my
_ObjectComparer_ I decided to create a new class called the
_MultiKeyObjectComparer_ which internally (composition) uses several instances
of the _ObjectComparer_ and its already stable working functionality. In the
defense of the original author, some may argue that his API (public interface)
would be friendlier in the sense that you could continue to use his object
comparer and another developer would see the new functionality using
intellisense because of the additional constructors and methods, where as with
my design the developer would have to be aware of the new
_MultiKeyObjectComparer_ that I created to benefit from it.

(On a side point, after implementing this, the next morning another altogether
separate co-worker requested the functionality for a UI he was doing,
completely unaware that I had already been looking into this…weird
coincidence).

[1]: http://www.damonpayne.com/BlogFull.aspx?Guid=b8405b9d-8f6d-
4d53-8e83-8764b2027fb6

[2]: http://www.damonpayne.com/Blog.aspx#0e692666-10f9-4ecc-87df-
bc14ed5784d1

[3]: http://c2.com/cgi/wiki?OpenClosedPrinciple

I was talking to a former associate I used to work with about a new "[Inversion of Control][1]" (IOC) container I had been playing with. He is a big OOP enthusiast but had not heard of IoC before. He later emailed me that after his research that Inversion of Control was nothing new and that it was formulated a long time ago in the "[Dependency Inversion Principle][2]" (DIP).

(FYI: DIP and IoC's primary purpose is to decouple implementations of classes. With that come many benefits too long to go into in this post. But I highly recommend following the links provided in this article to learn more.)

I have heard this before and I agree that IoC is definitely not something new.

But there are some differences. "[Dependency Inversion Principle][2]" is an

Object Oriented Design **principle** where as "[Inversion of Control][3]" is a

Design **Pattern**. Principles are meant to be followed but provide only the

basic guideline to follow where as Patterns are concrete solutions to common

problems so there alone separates their purpose/intent. Personally I think

that Ioc is at the core of DIP, but they both compliment each other but in

different aspects. (Think chicken before the egg?) The only way you can have a

good, successful _dependency inversion_ of a class is by using one of the IoC

patterns (I, II, or III) or also as my friend suggested to me the alternative

design pattern "[plugin][4]".

Then as my friend asked, what is the hype about IoC containers and when do we

use an IoC contatiner over creating our own Plugin? (Paraphrasing here)

First what is a [plugin][4]? To summarize, it links classes during

configuration _rather than compilation_. The plugin depends heavily on

factories and some conditional logic to decide which implementation to return

to the requesting client. The plugin can be used in many contexts but the

[author][5] originally wrote its primary purpose for unit testing or running

an application in multiple environments. Factories can be evil for reasons

like that they usually implement the singleton, or another problem is that now

you may have avoided tightly coupling two object implementations by using DIP

but the requesting client is still tightly coupled to a factory class to get

it's loosely coupled implementation.

What about [IoC][6]. Using an IoC container assists us in DIP without

recreating the wheel. Though each container use different ways (see below) of

binding implementations dynamically during runtime…none of them use a factory

to that. We can also now choose our preferred method of IoC using open freely

available frameworks. I wont go to company A and have to learn company A's

proprietary IoC framework and then do the same again for company B, company C,

and so on. - Standardization is good.

*Very Quick Reference to how IoC is implemented in frameworks. I use the

dependency injection terms (setter, constructor, interface) over the original

IoC terms (I, II, III). Martin Fowler provides us with an [easier way][3] of

understanding this pattern.

  * Setter

    * This usually requires an external configuration file that will bind

classes together. This depends on properties to provide the implementation to

the class needing them.

    * .Net Implementation:

      * [Spring.Net][7]

  * Constructor

    * A Class that requires supporting classes get these through the

constructor as arguments. The client code will request a specific type of

object from the framework. The framework then will Instantiate an instance of

an object of that type or of a class that implmenets that type. Every class

needed will by linked up dynamically.

    * .Net Implementation

    * [Castle Project][8]

    * [PicoContainer][9]

  * Interface

    * The framework will bind up classes that match particular types of

interfaces. I know this is a weak definition but there are lots of sources

that go deeper into these subjects if you wish to learn [more][3].

    * .Net Implementation

      * [Castle Project][8]

   [1]: http://www.martinfowler.com/articles/injection.html

   [2]: http://www.objectmentor.com/mentoring/OOPrinciples

   [3]: http://www.martinfowler.com/articles/injection.html

   [4]: http://patternshare.org/default.aspx/Home.MF.Plugin

   [5]: http://www.martinfowler.com/

   [6]: http://wiki.apache.org/excalibur/InversionOfControl

   [7]: http://www.springframework.net/

   [8]: http://www.castleproject.org/castle/show/HomePage

   [9]: http://picocontainer.org/