NuGet: Dont you mess with the Cache!

Caching ist prinzipiell cool. Allerdings kann ein Cache auch Probleme "kaschieren". Benötigt ein Projekt-Build ein Package schaut NuGet erst in seinen lokalen Package Cache und lädt es erst vom Server herunter wenn es dort nicht zu finden ist. Super Sache. Für Entwicklungs-Builds will man die Version nicht immer hochdrehen sondern verwendet stattdessen gemäß Semantic Versioning die sog. pre-release Syntax. Lokal ist das kein Problem, man weiss ja dass der lokale Package Cache nutzerspezifisch unter %LocalAppData%\NuGet\Cache zu finden ist. Also einfach Package-Datei aus dem Cache-Verzeichnis löschen und weiter geht's! Aber wo ist der Package Cache auf einem Build-Server?

New Programming Jargon:"Reptile Code"

With New Programming Jargon Jeff Atwood added all the modern programming metaphors to the  Jargon File. With Reptile Code i would like to propose one myself.

In "The Science of Discworld (1)" [1], chapter Mammals on the Make, biologist Jack Cohen elaborates on of one of science's remarkable misjudgments. At this time, the concept of DNA was often referred to as Blueprint of life. And it still is today:

It seemed to be a natural conclusion to approximate a species' level of evolution or its complexity by the length of its DNA strand, i.e. the longer the DNA code the more sophisticated the species.

This intuitively made sense. By analogy, the engineering blueprint of Jumbo Jet is a lot longer than that of a simple paraglider.

The embarassing result: Empirically, the DNA of a frog is much longer than the human DNA. Confusion took hold. Could it be that God considered simple reptiles higher than his flagship creation, man?

Later, it was found that human DNA is so much shorter because it is organized better [2].
Put simply, frog DNA contains a variety of contingency plans for environmental changes that accumulated in the course of evolution as lots of code patchwork. For instance,

if temperature between -14° und -7° do this,
else if between -7° and 0° do that,
else if ... etc.

Warmbloods like man escape this complexity through the elegant statement

set internal temperature to 36°.

Especially for developers, i find this view very accessible, because they very well know about metrics like Lines of Code (LoC) oder Cyclomatic Complexity (McCabe) from their own experience [3].

Hitting such code, you could probably say in Mr.Spock voice:

Fascinating! This component is likely to be hard to maintain: The average cyclomatic complexity of their methods differ with 57.63 significantly from that of the World Code Health Organization (WCHO) which recommended a maximum 20.

Compared to Mr. Spock just stating

Woah! Reptile Code!

really hits home and feels more natural.

Footnotes:

1. As a teenager i loved reading Terry Prattchet Discworld-novels, especially the series Science of Discworld which were written together with co-authors Ian Stewart und Jack Cohen and which uniquely prescribes the wonderful cosmology of Roundworld and is amongst the best introductory works on evolution after Richard Dawkins.


2. Later, it turned out that DNA-Code at times can "reorganize" and shift to a whole new organizational level of abstraction. It seems, evolution knows the concept of "refactoring" but she is a lot more cautious on eliminating "dead code" (perhaps of the deep coupling of SCM and the code itself).


3. In general, long codes with a high McCabe-Complexity are a lot harder to maintaint, cf.:
   
   
   
   • Halstead-Metrik
   • Lines of Code (LoC)
   • McCabe-Metrik
   • Function-Points

Links:

• DNA Reorganization, The Science of Disc World, p. 324 ff.
• The Science of Disc World [YouTube]

Hanselman about Portable Class Libraries

Scott Hanselman über Portable Class Libraries.

Der "Von Neumannsche" Jenkins

Ein Teilaspekt des neuen Build Server ist dass er sich im Von Neumannschen Sinne selbst reproduzieren kann. Nun ja, nicht ganz alleine - Man muss noch den Knopf "Jetzt bauen" auf dem entsprechenden Job: Neuer Jenkins oder einen Post-Commit-Hook auf dem scripts-Repository aufsetzen.

Wordsmithing...

In On Writing Interfaces Well gibt Jonas Downey Tips zum Schreiben guter Fragen und Antwort-Optionen in Oberflächen. In seinem Team gibt es eigene Commits nur für das Feilen and den Formulierungen mit dem Tag Wordsmithing.

Testing Threading

Asynchronen Code zu testen ist schwierig. Umso leichter haben es Bugs sich dort einzurichten wo man schlecht mit dem Besen hinkommt. Ein kurzer Bericht aus dem Projektalltag.

Neuerungen in Grails 2.3

Im Rahmen eines Projektes hatten wir für einen REST-Adapter die Verwendung des auf Groovy basierenden Web-MVC-Framework Grails erwogen, dies aber dann verworfen. Der vorgeschobene Grund war Zeit und Budget im Griff zu behalten. Der ehrliche Grund ist wohl eher das Eingeständnis von Grails keine Ahnung zu haben und daher nicht vergleichend einschätzen zu können wie aufwendig eine Grails-Implementierung gegenüber Groovy ist.