Comments for erik dörnenburg

Comment on Metrics Tree Maps by Erik Doernenburg

Erik Doernenburg — Thu, 06 May 2010 01:43:42 +0000

Thanks for the pointer. This article was more about the “theory” and a do-it-yourself approach but there are certainly good tools that include visualisations like this. Sonar is one of them. Panopticode is another: http://www.panopticode.org/

Comment on Metrics Tree Maps by Franck Arnulfo

Franck Arnulfo — Wed, 05 May 2010 16:15:48 +0000

You should take a look at Sonar http://www.sonarsource.org .
It does tree map but also a lot of more other things.
Go to the Sonar live instance for open source projects : http://nemo.sonarsource.org .

Comment on Testing Cocoa Controllers with OCMock by Testing View Controllers « Carbon Five Community

Testing View Controllers « Carbon Five Community — Wed, 10 Mar 2010 18:01:16 +0000

[...] the controller’s behavior. (Erik Dörnenburg has provided a nice example of doing just that: Testing Cocoa Controllers with OCMock) – (void) testViewBinding { TestableSimpleViewController *viewController = [...]

Comment on How toxic is your code? by Ian Cartwright

Ian Cartwright — Wed, 24 Feb 2010 17:34:44 +0000

Noticed a problem with Integer overflows for very large values of NPath complexity, the CheckStyle team fixed the same overflow issue themselves a while back.

The fix is pretty simple, just need to change the declaration for ‘values’ from Integer to Long. See below

Function CalculateScore(n As String) As Variant
If (n = “score”) Then
CalculateScore = n
Else
Dim values(0 To 2) As Long
values(0) = -1
values(1) = -1

Comment on Making build pain visible by Erik Doernenburg

Erik Doernenburg — Sat, 20 Feb 2010 03:30:27 +0000

This is a visualisation on top of what our continuous integration (CI) server provides, a visualisation that shows long term trends, the big picture so to speak.

To answer your question, Thomas, to find out what broke an individual build, we just use the features provided by our CI server. It allows us to see the build output, provides a report on the status of the tests, and it ties that back to the check-ins that triggered the build.

Martin has a good write-up of the practice on his site:

http://www.martinfowler.com/articles/continuousIntegration.html

Comment on Making build pain visible by Thomas Emc

Thomas Emc — Fri, 19 Feb 2010 13:53:22 +0000

That’s interesting.

What are you doing when the light is red? I mean, How do you figure out what is the reason for the broken build? Do you have any report for the changed files or change-sets, merged files etc.?

Comment on How toxic is your code? by Schauderhaft » New Project’s Resolution

Schauderhaft » New Project’s Resolution — Sun, 10 Jan 2010 10:44:08 +0000

[...] We gonna improve that. Appart from the knowledge I took from Clean Code I’ll plan to use the toxicity metric as an important tool for [...]

Comment on How toxic is your code? by Schauderhaft » Developing for Maintainability

Schauderhaft » Developing for Maintainability — Sun, 20 Dec 2009 10:06:18 +0000

[...] linked to maintainability. Cyclomatic Complexity being possibly the best known. I personally prefer toxicity, which is based on Cyclomatic Complexity and a couple of other measures, which contribute to the [...]

Comment on Making build pain visible by Links for November 3

Links for November 3 — Tue, 03 Nov 2009 13:29:26 +0000

[...] visualizes build [...]

Comment on How toxic is your code? by Schauderhaft » How to Use Key Figures and How Not to Use Key Figures

Schauderhaft » How to Use Key Figures and How Not to Use Key Figures — Sun, 16 Aug 2009 13:03:26 +0000

[...] Toxicity [...]