I'd like to take the opportunity to apologize, here.  The original
purpose was to verify that some of our team was not conforming to TDD
policies on a regular or useful basis.  The gem, in its current form,
is what I consider a "novelty gem."  It serves no practical purpose,
other than to start an amusing conversation with your co-workers.  I
have no faith in the gem as a performance metric or a judge of
quality.

The only positive effect KABLAME! ever had was turning one of our team
members into a serious TDD believer.  When he saw the first print-out
and realized he was 10th on the list, he had visual motivation (on top
of my hounding and harassment) to start writing tests with every
feature he worked on or changed.  He started writing tests everywhere.
 He started writing them in his personal projects.  The quality of the
code reflected the new drive to be a more comprehensive tester.  That,
of course, is only one isolated case.  I'm sure the KABLAME! would
also rob babies of their candies and push old ladies into mud puddles.

Sorry to anybody who took KABLAME! seriously.  It wasn't released to
produce anything other than laughs.

-Jacob Dunphy
Manufacturer of Novelty Gems


On Sun, Jun 22, 2008 at 3:26 AM, Florian Gilcher <flo / andersground.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Jun 22, 2008, at 4:07 AM, Jacob Dunphy wrote:
>
>> This is the first "announced release" of KABLAME!
>>
>> KABLAME! started as a way for me to show my managers that half of the
>> development team wasn't writing any tests.  It was a stupid Rails
>> plugin that I've now turned into a stupid gem.  It uses scm blame
>> commands to determine how many lines project contributors have
>> written.  It currently works with git and svn.
>>
>> The gem installs a pair of binaries, git-kablame and svn-kablame,
>> which can be used to KABLAME a project.
>>
>> Usage example:
>>
>> git-kablame lib specs  -> Runs git blame on every .rb file in these
>> directories and returns a list of contributors and the lines they've
>> written.
>>
>> Example output:
>>
>> ++++++++++++TOTALS++++++++++++
>> **WINNER**  tom  **WINNER**
>> tom          ==> 1115
>> dick         ==>  750
>> harry        ==>  369
>> **LOSER**  harry  **LOSER**
>>
>>
>> So give it a try and see if you're the most prolific coder on your team.
>>
>> gem install kablame
>>
>> Check out the (very limited) docs at rubyforge:
>> http://kablame.rubyforge.org
>>
>> Check out the source at github:
>> git://github.com/jdunphy/kablame-gem.git
>>
>
> This scheme is faulty not only because of the assumption that more lines
> make better code (i once worked on a project where creating one of [simple]
>  page pdf took the original coder 4000 LOC - he would be the clear winner),
> but also because it is pretty easy to beat - without actively doing
> something bad.
>
> If my company would use such a scheme, i would go against accepted practices
> and correct every tiny whitespace error (in my/the projects fashion of
> indention and paranthesis). Thats 2 seconds of work and at least one line
> per correction. "Convert Tabs to Spaces" is also a command that gets you a
> long way on you quest of "tagging" lines with you name. ("Sorry, my text
> editor does that by default. Forgot to switch it off.")
>
> If you do wish to show that someone doesn't commit on some arbitrary subtree
> (e.g. /trunk/tests, as it seems to be you case) a simple "svn log tests |
> grep ..." would suffice.
>
> There is a reason why I prefer "svn praise" to "svn blame" because it should
> only be used in a constructive sense. (e.g. being able to contact the
> original author)
>
> Regards,
> Florian gilcher-----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkheKT8ACgkQJA/zY0IIRZZeoACgs+ZAKVtp14UFUM9yhAQfLDbm
> T70AmwVU/yBX4M8n0VXBTFRL7HOMkWHp
> =C3oe
> -----END PGP SIGNATURE-----
>
>



-- 
Jacob Dunphy
626.318.2566