Tuesday, June 09, 2009

Agile Diary





Dear Diary:

I had a goal in January to write a series of ongoing blog posts called Agile Diary.

While a lot has been written about various Agile methods, rather than a presenting a methodology or case studies, I thought a regular, diary entries might paint a different picture and provide different insights.

I hope to at least talk about:

  • The situation
  • What my initial goals were
  • The initial plan
  • how we were able to follow
  • what we had to adapt to
  • failures as well as success

Naturally as situations will always change, we will always iterate through the above --- Diary Iterations, per se.

So I'm 5 months behind, I'll try to write some fill in articles and catch up.



Forrest

Thursday, April 02, 2009

Creating dates in a time zone w/ActiveSupport

As easy as 1-2-3

eastern_timezone = ActiveSupport::TimeZone["Eastern Time (US & Canada)"]
mon_before_market_opening = eastern_timezone.parse "3/23/2009 07:59:59 AM"

Tuesday, March 10, 2009

Rails, "do what I mean"

A pleasant surprise for me just now. I typed in

script/generate migration add_application_to_content_categories application:string

And the entire migration was generated. The descriptive name I thought of was the right convention to trigger the instant magic. Beautiful.

Jack Bauer 94

I was reminded for some reason of this video I saw last year to share w/my coworkers. Thought I'd share it here. http://www.collegehumor.com/video:1788161

It's 24 if shot in 1994. Amazing how far we've come since


Instant 3 way bi coastal debugging session


courtesy via iChat

Wednesday, March 04, 2009

VirtualBox > VirtualPC

I have available to me a rather muscular 20inch Vista laptop -- that's right, 20 inches, this is a laptop for King Kong.


Anyways, one of the uses for the laptop is to run a Microsoft provided XP VirtualPC image with Internet Explorer 6, unfortunately still a dominant browser and the "Great Satan" for web developers everywhere. As part of the virtualization wars, Microsoft has graciously made VirtualPC 2007 a free download.



I also planned to setup a CruiseControl.rb instance on a linux VM, and the Vista laptop had plenty of resources to spare (even running Vista). Naturally since I was already running the XP image on VirtualPC it made sense to try and to reuse VirtualPC for a Linux VM.


Some googling, and hoop jumpings later I had a Linux VM running, but it was kind of slow, and unstable. The Linux VM never stayed booted up for more than 2 days. MS does not officially support Linux VM's, go figure ;). Apparently there were linux add ons for VirtualPC 2005, but those didn't support Ubuntu, and no one has been able to get them to run with VirtualPC 2007.


So I decided to give VirtualBox a try after hearing good things about it. The install went very smoothly, and the VM is both stable and quick. The VirtualBox VM runs our unit tests in about 1/3 the time of the VirtualPC.

In general I seem happier with using VirtualBox, though I'll have to come up with a different solution. I will say on VirtualPC's behalf, that XP ran fine under VirtualPC

thru-you.com

Wow, just caught this from @obie http://thru-you.com/


It's amazing what "undiscovered talent" there is out there. Though I imagine he won't be undiscoved that long. Makes me wanna play again.

Friday, February 27, 2009

Remote collobaration via 4 Way Video Conference with iChat

Title says it all. Mondo cool.


I stayed home to help watch a sick child, but this came in handy. Normally the 3 on the right are in the same office in Southern California (2 of them are on the call), and the gentlemen at the left is in New Haven, CT.

Pretty nice for free!

Thursday, February 12, 2009

Rapid progress: kudos to JRuby

Courtesy of Facebook

Charles Oliver Nutter JRuby has had over 850 revisions applied since 1.1.6 was branched in December. That's better than 14 commits per day. And 153 issues fixed.

Sweet...

Monday, December 22, 2008

The significance of Red in Red, Green,Refactor


(image from http://weepeixin.blogspot.com/2008/06/red-light.html)

What a lot of people miss is that the Red part of the TDD mantra "Red, Green, Refactor" serves as a test of the test (or spec for the BDD faithful). In seeing a test fail prior to the addition of code and seeing the test subsequently pass after the addition of code you learn 2 things
  1. The test indeed tested something that actually changed with the addition of code
  2. The code added had something to do with that test changing

One really appreciates this when they've been bitten -- written a test w/o bothering to see it fail, and writing code that supposedly makes it pass, but in fact did not. What can happen, albeit infrequently, is that since the test might've passed w/o the addition of new code--- the code added had nothing to with the code passing, or the test didn't test what you thought it did --- both variations of "accidental programming." Unfortunately, you won't be alerted to this since you never had the red turn into green as a result of the new code. This will break the normally "debugger free" cycle of TDD and reduce your coding momentum. I've been bitten, so I'm particularly aware of this phenomenon. Simply making it habit to always see the red, can avoid this.

I think side effects of not being able to "test the test" occurs more frequently test last, whether you are doing so by design (non TDD coding) or by necessity (adding tests to legacy code, working on code that is not easily TDD'd). In such situations, it's often hard, or not worth the ROI to find a way to make the test fail prior to writing the test. Consequently, writing tests last can often just serve as "documenting how the existing code works", rather than testing it.

(image from http://blogs.technet.com/seanearp/archive/2007/10/02/map-active-directory-in-visio.aspx)

I fell prey to this effect while putting some tests on some LDAP/ActiveDirectory code that I had to explore to get working . Normally, I strive to TDD as much as possible, but I couldn't really see how to do so in this case. I did a spike, exercising the LDAP API until it got the results I needed, then proceeding to refactor and add tests to this "legacy code" (as defined by Michael Feathers).

The test in question itself was wrong -- it didn't test what I thought it did, but since I never saw it fail, then pass, I didn't know it. Fortunately, I had a controller test (Rails app) that touched this code which failed and alerted me to the faulty test which also should've failed (yay multi level test coverage).


I'm reminded of Micah Martin's Ruby Kata and Sparring presentation at RubyConf where Micah did an exercise of live coding w/critiques as a device to improve one's coding. He mostly did a by the book "red, green, refactor" TDD/BDD with Rspec. I had pointed out that he had written a test in which he never saw it fail, but went straight ahead wrote the implementation to see the green. Now it was obvious that Micah had coded this problem before, that he pretty much knew what he was going code here, and that it was probably unlikely that there would be existing code to make this test pass, but none the less it's possible he might've written the wrong test, which would've sent him into a debugging cycle at some later point. When I brought this up, another attendee thought it was a spurious criticism, something along the lines that "we were judging his coding, not his adherence to TDD." I feel that person didn't get the significance of Red in Red, Green,Refactor, but perhaps he's never been bitten.