TPF_grant_update_7.md.html

<h1>A Final TPF Parrot Embed/Extend Grant Update</h1>

<h2>Really TLDR: The Parrot has landed.</h2>

<p>It brings me great joy to announce that I have completed all milestones for my
<a href="http://perlfoundation.org">TPF</a> grant regarding the Parrot <a href="http://news.perlfoundation.org/2010/11/2010q4-grant-proposal-improve.html">Embed/Extend subsystems</a>!
Not only that, but all of my grant work was included in the most recent release of
Parrot, <a href="http://parrot.org/news/2011/Parrot-3.5.0">3.5.0 "Menelaus"</a>.</p>

<p>The actual TLDR of this update is "many tests were written, code coverage is
above <a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-embed-api-c.html">95%</a>
<a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend-c.html">for all</a>
<a href="http://tapir2.ro.vutbr.cz/cover/latest-c_cover/src-extend_vtable-c.html">systems described</a>
in the grant, docs were improved, many
Parrot Trac tickets were created and <a href="http://leto.net/dukeleto.pl/2010/12/parrot-embed-grant-update-1.html">many</a> <a href="http://leto.net/dukeleto.pl/2011/01/parrot-embed-grant-update-2.html">a</a> <a href="http://leto.net/dukeleto.pl/2011/02/parrot-embed-grant-update-3-now-with-dragons.html">blarg</a> <a href="http://leto.net/perl/2011/04/parrot-embed-grant-update-4-the-journey-continues.html">toast</a> <a href="http://leto.net/dukeleto.pl/2011/04/parrot-embed-grant-update-5-zen-pebbles.html">was</a> <a href="http://leto.net/dukeleto.pl/2011/05/parrot-embed-grant-update-6-still-hackin-less-slackin.html">cooked</a>.</p>

<p>For those of you that have a thirst for knowledge unquenched (I know who you are),
you are welcome to pondiferously peruse the Impending Technical Details.</p>

<h2>The Deets</h2>

<p>The last portion of this grant definitiely challenged me to think in new ways
about testing and I am now only beginning to reap the benefits. I was charged
with adding code coverage a few rarely-if-ever-used C functions in Parrot's
embed/exted subsystem, which allows you embed Parrot into other applications
and other funky stuff.</p>

<p><a href="http://whiteknight.blogspot.com">Whiteknight++</a> greatly helped me write a test for <a href="https://github.com/parrot/parrot/blob/master/src/extend.c#L700">Parrot_sub_new_from_c_func</a> which
takes a C function and a string that describes the function signature of the C
function and returns a <a href="https://github.com/parrot/parrot/blob/master/src/pmc/nci.pmc">NCI PMC</a>, which can be invoked.</p>

<p>I also learned many lessons about code coverage during the final stage of this
grant, even though I thought I was at such a level of expertness that it would
be hard to learn drastically new and important perspectives on testing. This
pattern of thinking is always wrong.</p>

<h3>Lesson 1</h3>

<p>Sometimes you are the underdog and you have to interpret the rules in a new way
in order to have a chance at winning. You need to be Ender Wiggins from <a href="https://secure.wikimedia.org/wikipedia/en/wiki/Ender's_Game">Ender's
Game</a>: continually inventing new tactics to keep a winning edge over the
competition.</p>

<p>I noticed that a large portion (about 80%) of the uncovered code in one file
was a macro that was copy-and-pasted into two places. I refactored this into a
single macro called <a href="https://github.com/parrot/parrot/blob/master/src/extend.c#L331">POP_CONTEXT</a>, which reduced the total number of lines in the file by
roughly 10, while simultaneously decreased the number of uncoverd lines in the
file by ~20 lines, which had a combined effect of pushing the code coverage
over the necessary 95% mark.</p>

<p>This change definitely increases the maintainability and modularity of the
code, but it feels a bit like gaming the system. Nonetheless, it saved the day.</p>

<h3>Lesson 2</h3>

<p>The simplest useful test that you are avoiding is the most valuable next test to
write, because it has the best ROI (Return on Investment, where investment is the
time it takes to write the test, and the return is having an automated way of
verifying that the feature works.</p>

<h3>Lesson 3</h3>

<p>Software developers are very optimistic about time estimates. We forget about all
the possible things that could go wrong and often quote estimates on something
approaching "base case scenario". As a rule of thumb, I think all software developers
should think long and hard about a time estimate for a given project, write down
the estimate, then multiply that time estimate by pi for a REAL estimate.</p>

<p>I theorize that pi is the factor of time it takes to debug and write tests for
behavior of hard-to-recreate edge cases.</p>

<p>I originally thought my grant would take about 3 months, but it ended up taking about
9 or ten. QED.</p>

<p>Finally, I would like to thank my grant manager Makoto Nozaki for providing
lots of feedback, support and encouragement, as well as everyone else at the
The Perl Foundation for funding this grant.</p>