Remaking Prodigy’s Smack My B**** Up using Ableton

Very cool video showing a producer named Jim Pavloff re-creating this Prodigy classic using Ableton music production software, bringing in the samples one at a time and modifying them eventually building the entire track.   I need me some Ableton! …. and some talent. :(

http://www.youtube.com/v/eU5Dn-WaElI&feature=youtube_gdata
Making Prodigy’s “Smack My Bitch Up” in Ableton by Jim Pavloff

First Run in my Vibram Five Fingers KSOs

Vibram Five Finger KSOs on the sidewalkI 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!

Naked Domains in Google App Engine with GoDaddy

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.

The next thing that we want to do is add the j4n.org domain to this application.  When you go into the GAE dashboard, you will see that option under the “Application Settings” section labeled “Domain Setup”

On this page you will see a note that tells you that the domain you add must be set up for Google Apps, a service that allows all sorts of functionality, including email services and more.  NOTE:  You do not have to use any of those services, you simply need to sign up!

By clicking the link that says Sign up for Google Apps, you will be taken to a page like this:

Walk through the process filling out your personal information and you will come to a screen that looks like this:

For our example, we are going to choose to create a new CNAME record in DNS to prove to Google that we own the domain.  By choosing that option

At this point we need to go to the GoDaddy DNS manager and create a host name google46353a9a2d07a035 and point it to google.com.  You can see what that looks like below:

Once that record is in place we can go back to the Google Apps page and click the button labeled I’ve completed the steps above.  If all goes well, you will see a page directing you through additional setup.  For our purposes in this example, we are done with Google Apps for the time being.  Now we want to go back to the GAE dashboard and tell it that we want to use the j4n.org domain.

When you enter that domain you should see a message that looks like this:

This will bring us back into the Google Apps control panel for the j4n.org domain and we can add hostnames to our application like this:

When you click add you will see an page like the one below instructing you to add another CNAME to GoDaddy for the host “www”.

In the screen below you will see that we have successfully added the “www” host and while we were in there I went ahead and deleted the temporary CNAME that we had to create earlier to validate the ownership of the domain.

At this point we can actually reach our application with the address http://www.j4n.org as you see below:

While this is pretty cool and all, we still can’t access our application with http://j4n.org.  For this, we will count on GoDaddy to do the rest.  Go back into the GoDaddy domain manager look for this link:

On the next page, you will want to fill out the field like you see before.  However, before you do, click the “learn more” link in the bottom left corner.  On that page there is a very important note:  For your domain to forward, your domain’s A record must be

64.202.189.170

. If you note my DNS information above, that is not what the default parked domain IP is.  I won’t bore you with yet another screen shot, but make sure you alter your domain’s A record.  Now when we ping j4n.org we get a response from 64.202.189.170.

Once we enter in www.j4n.org you can see that our plan is going to work by hitting the “Preview” link to the right and seeing a snapshot of our app!

You will notice that we accepted the default settings which actually does a 301 redirect from http://j4n.org to http://www.j4n.org.  This means that we will never actually see http://j4n.org in the address bar after the page has loaded.  If you click on the advanced settings you can select “masking” which allows the url to remain in the address bar as http://j4n.org.  Each option has its own advantages.  Select what is right for your application and choose OK.

That is all you need to do!  Now, a word of warning… we have all gotten spoiled by the seemingly instant DNS changes in recent years.  You will find that when you make this forwarding change, you may need to wait up to half an hour or so before you can see the finished product (your mileage may vary).

Relaunched HikeTheCanyon.org on OpenBD and GAE

Around a year or so ago, I inadvertently took hikethecanyon.org offline in a server move.  Considering that it is a very low traffic site that is little more than a scrapbook of hiking pictures and descriptions, there is no active user community to send me nasty messages begging for me to bring it back online.  Finally this past weekend, I spent a bit of time and revived the code base off an old server, moved all the images out to Amazon S3 and brought the site up running under OpenBlueDragon on the Google App Engine.  Other than a very rudimentary Lightbox drop-in I did on the gallery to replace a no-longer functioning Flash image gallery, I didn’t actually touch the codebase or the design.  So if it looks dated to you, that is because it is!

For those interested in hiking, you may want to give it a look.  It documents a hike of the Grand Canyon that I took with my dad in 2005 with a very detailed trip report and over 300 pictures.  Enjoy!

HikeTheCanyon.org – Rim-to-Rim through the Grand Canyon on North Kaibab and the Bright Angel Trail

Setting up ColdSpring AOP and interesting behavior with return types

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">
	<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">
    <property name="someService">
        <ref bean="SomeService"/>
    </property>
</bean>

<bean id="MemberService">
    <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">
    <property name="someNecessaryService">
        <ref bean="SomeNecessaryService" />
    </property>
</bean>

<bean id="RecordUpdatedMemberAfterReturningAdvisor">
    <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.