Blog of Dave

I just got back from my first run in my new Vibram Five Fingers KSOs that I got for Christmas.  To call them a minimalist running shoe would be an understatement.  They are essentially a rubber sole strapped to your foot by way of neoprene, nylon, and velcro.  I was first kind of intrigued on the theory of them after seeing this review on wired.com over the summer.  In fact, if you don't know anything about the Vibram Five Fingers, go watch that 2 minute video to see where I am coming from.
 
As that video explains, traditional running shoes encourage us to run in a pattern that our bodies weren't designed for.  The big heals typically cause us to follow a heal-to-toe pattern where the heal - and subsequently your leg - end up taking the shock of each step.  Barefoot runners do not run like this, but instead land more on the ball of the foot, allowing the foot and leg to work together to become a shock absorber.  A lot of studies suggest that the latter approach leads to less of the common injuries associated with running, such as shin splints, calf strain, and plantar fasciitis. 

Over the summer, I began developing a calf strain injury that I simply couldn't shake.  It started when one day I was feeling great and decided to tack on 2 miles to my regular run.  From that day on, my legs absolutely lit up with pain when I would try to run.  Eventually I just took a month off of running an began easing myself back in following the Couch To 5K running program, building up to a longer run.  While that approach has worked, I still feel a constant tinge in my left leg when I run where I feel like I am almost on the verge of hurting it again.

The more that I read about the Vibram Five Fingers and the more reviews that I read from people that have used them, I wondered if they might actually offer me a solution for not only avoiding injury, but getting stronger, and running more like I was designed to run from the beginning!

For Christmas, after hearing me talk about them again and again, my wife surprised me with a pair of the black KSOs (Keep Stuff Out), which are an improvement on the original design in that they come a bit higher on the foot to keep dirt and stuff out from the foot.  And today ( December 26th ) I went for my first run.

I was a little bit apprehensive to be honest.  I had heard a number of people say that it works your legs in a different fashion - most notably your calves - so start by doing shorter runs and working your way up to longer runs over time.  I have had such great results with the Couch To 5K program, both with my introduction into running, and in my calf strain recovery, that I decided to invoke it yet again and start with Week 1 of the program.  This is essentially 9 sets of 60 second run/90 second walk.  Given my running speed that equates to a little less than a mile of actually running, and in hindsight, I feel that I could have definitely pushed a lot harder than that.

It was such a cool experience!  I absolutely loved everything about it.  On one hand, I could feel little things - even the cracks in the sidewalk - but not so much that it created pain or was any kind of interference.  It just made me feel more in tune with my scene.  I found that I had to take slightly shorter steps in an effort to make my foot land where I needed it to, but it became natural in mere moments.  On the 1 mile track that I run there are a couple of steep hills and I found myself digging in on these hills to tackle them rather than feeling dread as I saw them approaching.  There is something about the whole experience that felt very liberating, and gave me almost a primal, tribal pleasure as I kept thinking about the fact that this is how man has run for millenia!

Aside from the mental feeling, I got finished and realized that not a single thought went to my legs.  Over the past 6 months or so, they haven't been far from the front of my mind when I ran as I kept wondering when I was going to push them too far and tweak them again.  I got home and felt completely exhilarated.  My legs feel great, and I am looking forward to my next run!

I recently set up a new site (hikethecanyon.org) on the Google App Engine running OpenBlueDragon.  By default when you set up a new site on GAE (Google App Engine), you choose an ID for your application, which must be unique on their system as it also serves as the hostname of the URL like this: http://[your ID].appspot.com.   For those that would like to use a different domain name, Google App Engine has mechanisms for doing so.  In the administration panel of your application, you can add a domain and then choose hostnames from that domain that the application should respond to.  However, it makes no provisions for serving the "naked domain". 

What does this mean?  For my example of hikethecanyon.org, I originally set the site up with an id of hikethecanyon-org which was initially served as http://hikethecanyon-org.appspot.com.  After adding the domain hikethecanyon.org, I was able to add the host "www" so that it would respond to http://www.hikethecanyon.org.  However, since GAE doesn't support naked domains, I was unable to set it up to respond to http://hikethecanyon.org.  I was able find a workaround using GoDaddy's domain forwarding functionality.  While walking fellow CFML developer Paul Kukiel through the process today, he mentioned that someone should blog this, so here it is with screenshots along the way (edit - it appears that he decided to blog it himself as well!)

For my example, I am going to use a domain I have had sitting around doing nothing for a few years (j4n.org) and walk through the process with some screenshots and explanations along the way. 

First, you need to create your application in the GAE dashboard and deploy your application.  Many people have covered this topic in our community including Paul Kukiel and Aaron Lynch, so I will skip to the next step and assume that you have a running application on Google App Engine. As you can see below, I have set up an app with an ID of j4n-org that is answering on http://j4n-org.appspot.com which is just running a Mach-II skeleton application.

This weekend I had a task in which I needed to add a behavior onto a method in an existing production method in a service object.  The new behavior is more or less notifying a 3rd party application whenever a particular method was being called.  Considering that it is not really an essential part of the process, it didn't really belong inline as part of that method, nor did I really want to affect existing "sealed" production code.  Although I understood that the AOP functionality of ColdSpring was designed for exactly that type of work, I had never actually used it before this task.  I put together a little proof-of-concept application that validated what I wanted to do, then applied it to my application. 

My goal was to set up an "afterReturningAdvice" object/method - that being a method which will be called at the completion of the target method, which is Member.saveMember() - where I could externalize the new behavior without touching the service itself.  While I did get it to perform essentially how I expected, there were a couple of gotchas about this process. One of which makes good sense, the other... not so much. 

For starters, my MemberService was defined in ColdSpring like this...

<bean id="MemberService" class="my.objects.MemberService">
	<property name="someService">
		<ref bean="SomeService"/>
	</property>
</bean>

In order to make this change without causing broad sweeping changes throughout the application (in theory!), we are going to create a proxy object that masquerades as the MemberService that will pass requests onto the original MemberService. 

<bean id="MemberServiceTarget" class="my.objects.MemberService">
    <property name="someService">
        <ref bean="SomeService"/>
    </property>
</bean>

<bean id="MemberService" class="coldspring.aop.framework.ProxyFactoryBean">
    <property name="target">
      <ref bean="MemberServiceTarget" />
    </property>
    <property name="interceptorNames">
      <list>
        <value>RecordUpdatedMemberAfterReturningAdvisor</value>
      </list>
    </property>
</bean> 	

As you can see, our MemberService is now actually of type coldspring.aop.framework.ProxyFactoryBean.   We have defined its target as a bean named MemberServiceTarget which points to our original MemberService that has been renamed.  it now has an "interceptors" property that basically wires in a new bean named RecordUpdatedMemberAfterReturningAdvisor that will serve as an interceptor anytime the "MemberService" is accessed. 

So lets take a look at our interceptor definition:

<bean id="RecordUpdatedMemberAfterReturningAdvice" class="my.objects.aop.RecordUpdatedMemberAfterSave">
    <property name="someNecessaryService">
        <ref bean="SomeNecessaryService" />
    </property>		
</bean>	
	
<bean id="RecordUpdatedMemberAfterReturningAdvisor" class="coldspring.aop.support.NamedMethodPointcutAdvisor">
    <property name="advice">
      <ref bean="RecordUpdatedMemberAfterReturningAdvice" />
    </property>
    <property name="mappedNames">
      <value>saveMember</value>
    </property>
</bean>		

You can see that theRecordUpdatedMemberAfterReturningAdvisor that we declared in our previous snippet is defined here as type coldspring.aop.support.NamedMethodPointcutAdvisor, which is a another built-in type in the ColdSpring framework.  We have defined a property "mappedNames" which will list any methods in our target object that we would like this interceptor to act on.  In our case we are only wanting to act on the saveMember() method, which you see in the property.  The "advice" property tells the interceptor that whenever our saveMember() method is called, that we need to notify our RecordUpdatedMemberAfterReturningAdvice. This is an object at we create that extends the coldspring.aop.AfterReturningAdvice abstract class that is included with the framework.  When you use this advice, you must have a concrete implementation of the afterReturning() method, which is were we will actually put our code that notifies the 3rd party application.  That method will contain the arguments: returnVal, method, args, and target, which will let you know all about the target method that was just called.  Pretty cool huh?

Here is what that RecordUpdatedMemberAfterReturningAdvice looks like:

<cfcomponent output="false" name="RecordUpdatedMemberAfterSave" extends="coldspring.aop.AfterReturningAdvice">


    <cffunction name="init" access="public" output="false" returntype="RecordUpdatedMemberAfterSave">
        <cfreturn this />
    </cffunction>
	
    <cffunction name="setSomeNecessaryService" access="public" output="false" returntype="void">
        <cfargument name="someNecessaryService" type="_components.drmlabs.cd1.member.updatedmemberqueue.SomeNecessaryService" required="true" />
        <cfset variables.someNecessaryService = arguments.someNecessaryService />
    </cffunction>
	
    <cffunction name="getSomeNecessaryService" access="private" output="false" returntype="_components.drmlabs.cd1.member.updatedmemberqueue.SomeNecessaryService">
        <cfreturn variables.someNecessaryService />
    </cffunction>

    <cffunction name="afterReturning" access="public" output="false" returntype="void">
        <cfargument name="returnVal" type="any" required="false" />
        <cfargument name="method" type="coldspring.aop.Method" required="false" />
        <cfargument name="args" type="struct" required="false" />
        <cfargument name="target" type="any" required="false" />
		
        <!--- notify our 3rd party app --->
        <cfset getSomeNecessaryService().goDoTheWork(arguments.args.Member) />
		
        <cfreturn />
    </cffunction>
</cfcomponent>

You can see that our required afterReturning() method is what finally does the work that we were trying to implement.  And all of this with no changes to our original application! 

Well.... not exactly. 

While this is certainly a pretty low impact change to our application, the idea that it would not affect any existing code wasn't the actual reality for a couple of reasons.

•  MemberService is no longer a MemberService!  In about eleventy thousand places in my application, I had services that were wired with a dependency of our MemberService.  Each of these had a getter/setter that looked something like this:
  

  <cffunction name="setMemberService" access="public" output="false" returntype="void" >
      <cfargument name="memberService" type="my.objects.MemberService" required="true" />
      <cfset variables.memberService = arguments.memberService />
  	<cfreturn />
  </cffunction>
  
  <cffunction name="getMemberService" access="public" output="false" returntype="my.objects.MemberService">
      <cfreturn variables.memberService />
  </cffunction>

  
  
  With the changes that we have implemented, our MemberService is a completely different animal!  Every single one of my getters and setters failed since my MemberService is now actually of type coldspring.aop.framework.ProxyFactoryBean.  I altered them all to have type "any" (in case I remove this AOP piece later!) and all works.  I suppose it is a worthwhile change, but it would be nicer if this change was truly transparent to my application.
  
  
• This one is the head scratcher, and as of the time of this blog posting I have no explanation whatsoever.... but a Member isn't always a Member?!?  In my MemberService, I have a getMember() method which returns a type my.objects.Member.  In my initial testing I had no problems with this at all.  However, once I rolled it into production, there was a process that called the MemberService.getMember() method that I had not hit in my initial tests.  When it was called I received the following exception:
  
  Message:The value returned from function fnct_
  673EC50CBDBD5294E06289EE40D44ABE() is not of type Member
  Our proxy MemberService creates a dynamic method that forwards requests onto the original target getMember() method.  For whatever reason, in this one case, it was unable to validate that the returned object was indeed a Member.  I modified my original MemberService to make the returntype of getMember() "any" an all is now working well.  If anyone has an explanation for that one I am all ears!
  

Aside from those two issues, my new AOP functionality is now in production and working exactly as I had hoped.  Overall, I think that this is a very cool feature of ColdSpring, and one that I will definitely be making more use of moving forward.