About Kent Cowgill
Articles filed under...
abs ab_ripper andylester arms back baggyshorts bestpractices biceps bike birthday blog bugs bus calculator cardio catalyst cgi chart chest chinups code cpan datamodel dbi doctor documentation exercise exhaustion fitness flattire flat_tire google gps heart_rate helmet history home houston html humor journal kate kenpo kenpo_x kettlebell knees lazy legs lisa lisanne maps math matthew michaelmckenna mom montreal motivation movie mysql oops orm P90X pain park patellar_tendonitis patrick pdf perl phb photos physical_therapy plyometrics poor_gait presentation procrastination progress pullups pushups pyramid rabbits racecondition rant refactor rest ribs ride route running shoulders situps slides sore spike sql statistics syntax test testing textile timex training triceps ups versioncontrol video vim vimrc walk warren work workouts yapc yapcna2007 yoga youtube

A R C H I V E S

(3)
(1)
(3)
(2)
(7)
(15)
(16)
(25)
(3)
(4)
(2)
(4)
(11)
(1)
(1)
(3)
(2)
(2)
(10)
(5)
(2)
(3)
(4)
(9)
(21)
(3)
(3)
(1)
(6)
(4)
(1)
(4)
(3)
(2)
(1)


    Is Kent Cowgill Online?
    View Kent Cowgill's profile on LinkedIn
    Add to Technorati Favorites

    Recent Entries...

    Re: Catching up through week 7

    testing video ...

    Re: Porting a non-Moose object to Moose

    Wow, look what I found, greedy genius ...

    Re: Porting a non-Moose object to Moose

    Kevin, You're right, that does seem a little confusing. ...

    Re: Porting a non-Moose object to Moose

    Wait. I'm confused. Moose isn't the tool to reach for. So...

    Re: Porting a non-Moose object to Moose

    You should switch to MooseX::Types to declare your Typed and...

    Porting a non-Moose object to Moose

    I'm currently working with a lot of legacy code in an envi...

    Testing strategy for mocking code

    I keep finding myself using the following idiom for writing ...

    Re: Library Woes on OSX

    Have you considered changing your hosts file so it connects ...

    Re: Library Woes on OSX

    Right now the tests for Device::USB are failing. I've turne...

    Re: Library Woes on OSX

    What's the USB device you are trying to connect?...
    weblog | `web·lôg -läg |
    noun
    Another term for BLOG
    ORIGIN 1990s: from web in the sense [World Wide Web] and log in the sense [regular record of incidents.]
    blog | bläg |
    noun
    A web site on which an individual or group of users produces an ongoing narrative.
    ORIGIN a shortening of WEBLOG.

    Testing and Documenting Legacy Code

    Kent Cowgill

    Posted by
    on Wednesday, September 12 2007, 1:41am

    &qidYou may have guessed by now, but I've taken up a particularly onerous gauntlet at my job. I'm afraid to touch any modules. But holy cow, do they need touching.

    What do we learn from Refactoring: Improving the Design of Existing Code ? Well, we learn that without tests, you can't refactor. Well, you can - it's really not wise to do so, however. It will be difficult to know if you've broken something or slightly altered a particular functionality.

    Of course, tests also help you prove what you've got is a set of modules that performs to their specifications - or in the absense of a specification - proving that the code does what it looks like it's supposed to do based on certain circumstance.

    Given that our codebase is huge, undocumented, and more important untested, I've come up with a few snippets of shell code to really move me pretty far forward with my task.

    First, to create a directory hierarchy to house all my new tests:

    for i in $(find . -name "*.pm")
      do touch $(echo $i | \
    sed -e 's/\./\/path\/to\/dir/' | \
    sed -e 's/\.pm$/.t/')
    done

    And to give the files some default content (it's ugly but it sorta works, YMMV):

    for i in $(find . -size 0)
      do echo '#!/usr/bin/perl' >> $i
        echo "" >> $i
        echo "use strict;" >> $i
        echo "use warnings;" >> $i
        echo "" >> $i
        echo "Test::More 'no_plan';" >> $i
        echo "" >> $i
        echo "use_ok( '`sed -e 's/\//::/' | \
    sed -e 's/\.t//'`' );" >> $i
      done

    These snippets, plus my previously mentioned vim tip are really getting me pretty fair along in creating a comprehensive test suite and a good set of documentation for all of our legacy code.

    Oh, and as a side benefit, I'm getting to know the modules pretty well while I'm at it :)

    Filed under: perl documentation bestpractices testing
    Related Photos: perl
    Comment on 'Testing and Documenting Legacy Code' [ no replies - permalink ]

    Handy vim mapping

    Kent Cowgill

    Posted by
    on Tuesday, September 04 2007, 11:12am

    I'm going through a lot of legacy code lately, and got tired of manually opening up the first legacy file I documented (to make sure I was following the same standard I had implemented - it's not quite in my long term memory just yet), scrolling through the tedious documentation, copying (or retyping(!)) the text into the file I was working on, etc.

    So, I decided to write a quick little mapping for that menial task.

    First step is to create a template for the POD I want to insert:

    ~/podtemplate
    __END__

    =NAME

    =SYNOPSIS

    =DESCRIPTION

    ...

    And then this helpful mapping in my ~/.vimrc

    " Automatically add a POD template
    " to the end of a file
    noremap ,ap maG:r ~/podtemplate<cr>'a

    Mnemonic: Add Pod.

    ... which is at least smart enough to set a mark at your current position, move to the end of the file, insert the contents of ~/podtemplate, and return to your saved position. Caveats: It's NOT smart enough to know if you've already set an 'a' mark, and it's NOT smart enough to NOT insert the template if there's already POD in the file.

    Filed under: vim perl documentation bestpractices
    Related Photos: perl
    Comment on 'Handy vim mapping' [ no replies - permalink ]

    Main Page | Login

    Do you want to buy me ? Find more gift ideas at my wishlist