Asp Forum - [ANN] KABLAME! 0.2.1 Released

Jacob Dunphy

6/22/2008 2:07:00 AM

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.rub...

Check out the source at github:
git://github.com/jdunphy/kablame-gem.git

11 Answers

Axel Etzold

6/22/2008 8:42:00 AM

-------- Original-Nachricht --------
> Datum: Sun, 22 Jun 2008 11:07:10 +0900
> Von: "Jacob Dunphy" <jacob.dunphy@gmail.com>
> An: ruby-talk@ruby-lang.org
> Betreff: [ANN] KABLAME! 0.2.1 Released

> This is the first "announced release" of KABLAME!

Dear Jacob,

>
> 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.

caveat: I am part of the (maybe minority) of Ruby coders who don't use
any Rails whatsoever, so what follows might not apply to Rails development ...

> It uses scm blame commands to determine how many lines project contributors have
> written. It currently works with git and svn.
>Example output:
>++++++++++++TOTALS++++++++++++
>**WINNER** tom **WINNER**
>tom ==> 1115
>dick ==> 750
>harry ==> 369
> **LOSER** harry **LOSER**

But I feel that the longer I've used Ruby, the more concise my coding becomes,
so counting numbers of code will turn out those people as losers who actually
make use of advanced concepts, to keep their code short, and easily maintainable, including by others.
When it comes to counting lines of code, I've no doubt I'd still win hands down against most
of the experts coming up on this list to solve problems once and for all, but I can't really enjoy that victory :(

I am not sure if I really can help out with answering the question, 'who is contributing in a team to get things
done', but maybe one can use some combination of profiling of the code at hand, comparing it with profilings
of similar code, and arrive at statements like, 'to get task X done, you shouldn't be using 99 percent of processor
power for ten hours, so person Y, who wrote that part of the code should go back and work through it again.' --
so maybe you could combine your existing project with some coder-specific evaluation of profiling ?

Please view this just as an attempt to defend concise-writing people in your company.

Best regards,

Axel

--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/s...

Florian Gilcher

6/22/2008 10:27:00 AM

-----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.rub...
>
> 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

6/22/2008 4:27:00 PM

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.rub...
>>
>> 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

Florian Gilcher

6/22/2008 5:11:00 PM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> 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.
>

Thats quite another way of putting it. From your original post, it
looked like
it was used to blame other people in front of a manager. Using it for
visual
confirmation for someone that doesn't know where he stands in relation
to others is quite different. (I assume that he was in denial of the
fact that he
was the "weakest" tester.)

Using such a tool as a way of friendly criticism is okay (see my
"praise" statement),
but it seemed like you used it aggressively. I'm happy that this was a
mis-
understanding.

Regards,
Florian Gilcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkheiBoACgkQJA/zY0IIRZa6cgCfRtiu+CzG/hH3WejTlD/5AKfh
NLQAoJ1xWK7gEmRCDk9iScpG93RHKGP6
=9c70
-----END PGP SIGNATURE-----

M. Edward (Ed) Borasky

6/22/2008 5:39:00 PM

Michael T. Richter wrote:
> On Sun, 2008-06-22 at 11:07 +0900, Jacob Dunphy wrote:
>> So give it a try and see if you're the most prolific coder on your team.
>
> So... lines of code is good? Cut-and-paste coding, here I come!
>
> --
> *Michael T. Richter* <ttmrichter@gmail.com
> <mailto:ttmrichter@gmail.com>> (*GoogleTalk:* ttmrichter@gmail.com)
> /I can see computers everywhere - except in the productivity statistics!
> (Robert Solow)/
>

Dijkstra once said that he referred to that metric as "lines of code
*spent*". :)

Joel VanderWerf

6/22/2008 6:11:00 PM

Michael T. Richter wrote:
> On Sun, 2008-06-22 at 11:07 +0900, Jacob Dunphy wrote:
>> So give it a try and see if you're the most prolific coder on your team.
>
> So... lines of code is good? Cut-and-paste coding, here I come!

Adopt the practice of gnirotcafer.

irb(main):001:0> "refactoring".reverse
=> "gnirotcafer"

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Eleanor McHugh

6/24/2008 8:06:00 AM

On 22 Jun 2008, at 17:26, Jacob Dunphy wrote:
> 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.

You are aware that code 'quality' is a far more complex concept than
'has lots of tests'?

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-...
----
raise ArgumentError unless @reality.responds_to? :reason

Jeremy McAnally

6/24/2008 1:33:00 PM

I'm sure he does. I'm sure he also realizes that C0 analysis like
rcov doesn't do much good, documentation analysis for dcov isn't a
true tell for how easy the code is to understand, complexity analysis
from flog isn't a good indicator of how well something is solving a
problem, and so on ad nauseum.

Tools are just that: tools. And they help you solve problems that you
see that you are having. If he saw a _people_ problem with TDD (as
in, "Oh, there are enough tests!" or "Tests aren't needed!") then
perhaps this tool solved his problem.

Knocking it because it doesn't solve every people or technical problem
related to testing is like knocking Rails because it doesn't write the
web app for you.

--Jeremy

On Tue, Jun 24, 2008 at 3:06 AM, Eleanor McHugh
<eleanor@games-with-brains.com> wrote:
> On 22 Jun 2008, at 17:26, Jacob Dunphy wrote:
>>
>> 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.
>
> You are aware that code 'quality' is a far more complex concept than 'has
> lots of tests'?
>
>
> Ellie
>
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-...
> ----
> raise ArgumentError unless @reality.responds_to? :reason
>
>
>
>

--
http://jeremymca...
http:...

Read my books:
Ruby in Practice (http://manning.com...)
My free Ruby e-book (http://humblelittlerub...)

Or, my blogs:
http://mrneig...
http://rubyinpr...

M. Edward (Ed) Borasky

6/24/2008 2:19:00 PM

Jeremy McAnally wrote:
> Knocking it because it doesn't solve every people or technical problem
> related to testing is like knocking Rails because it doesn't write the
> web app for you.

Ah, but the perception outside of the Ruby and Rails communities was
that Rails *did* write the web app for you. ;)

But you're right ... when the only tool you have is an inclined plane,
you have to be careful where you are standing.

Wait ...

<ducking>

ara.t.howard

6/24/2008 2:38:00 PM

On Jun 21, 2008, at 8:07 PM, Jacob Dunphy wrote:

> Example output:
>
> ++++++++++++TOTALS++++++++++++
> **WINNER** tom **WINNER**
> tom ==> 1115
> dick ==> 750
> harry ==> 369
> **LOSER** harry **LOSER**

it would seem you've got the order reversed!? seriously ;-)

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama

comp.lang.ruby

[ANN] KABLAME! 0.2.1 Released

Jacob Dunphy

Axel Etzold

Florian Gilcher

Jacob Dunphy

Florian Gilcher

M. Edward (Ed) Borasky

Joel VanderWerf

Eleanor McHugh

Jeremy McAnally

M. Edward (Ed) Borasky

ara.t.howard

x Login to ForumsZone