Community News

Automatisierte Testausführung mit NCrunch

.NET User Group Bern Event

Montag, 1. September 2014 (18:00 bis 21:00 Uhr)

Automatisierte Testausführung mit NCrunch - mit Yannik Steiger

Nach der Sommerpause beschäftigen wir uns wieder mit einen Thema aus der Methoden-Kompetenz ;)

NCrunch unterstützt Entwickler bei der automatisierten Testausführung, bei der Erkennung von nicht getestetem Code und beim Debugging von Tests. Zudem bietet NCrunch neben Code Coverage und Performance Metriken verteiltes Testen und einen hoch optimierten Build Process.

Anhand von Beispielen wird uns Yannik aufzeigen wie die Features von NCrunch dich bei der täglichen Arbeit unterstützen können.

Über Yannik

Yannik wurde in Pusan (Süd-Korea) geboren und ist in der Schweiz aufgewachsen. Nach seinem Informatik-Studium legte er seine Spezialinteressen auf Knowhow- und Qualitätsmanagement sowie Team Coaching.

Seit 2007 ist Yannik auch im .NET/C# Umfeld tätig.


Die Anmeldung erfolgt unter Xing Events ohne Xing-Account ist eine Anmeldung über unser Kontaktformular möglich.

Das Hashtag auf Twitter: #dnugbenc

Wir freuen uns auf Deine Teilnahme!

Martin Affolter, Kay Herzam und René Leupold

The Software Grief Cycle
People pile layers on top of layers, abstractions on top of abstractions, complications on top of complications, crap on top of patches, and patches on top of crap until everything collapses onto itself and the singularity appears.
- Source lost on the Internets


After reflecting upon my last Weekend Reader, I came up with some more thoughts about the fact that software is eating the world and the  long-run problems that result from the fact that we create new systems at an ever increasing rate.

Tudor plays with the idea of “Software Environmentalism". This implies that there was a clean environment that gets polluted by software systems. The assumption is, that, as in nature, the environment can only deal with a certain amount of pollution, therefore we must start taking care and according to Tudor's idea:

No system should get away without dedicated tools that help us take it apart and recycle it effectively.


Let’s see what Steve Jobs once claimed about software: Eventually it collapses under it’s own weight!


Let’s repeat:

"It doesn't matter what you do, eventually it will collapse”.

It's like with humans and death ... it's inevitable. We can prolong our lives by living healthy and modern medicine sometimes allows to keep us alive even when it does not make much sense any more ... but we all are getting old and finally we will die.

So there you have another analogy, actually a full bag of analogies.

Any software will age and finally it will die. Some software will age more gracefully than other software, but they all will die. We have to accept that. This is not an easy insight, there are the five stages of grief (denial, anger, bargaining, depression and finally acceptance). Letting the software die might become painful for everybody involved… especially if you try to deny the fact. Often developers are way ahead of management on the stages of grief:  


I would argue that we are still dealing with a very high mortality rate in the software industry today. But we are not dealing with the tragedy of stillborn children or sudden child death. No, in the software industry we mostly deal with monstrous frankensteinian abominations that will not be able to breathe on their own. Still we keep trying to somehow create the perfect monsters ...

Often we are helpless in dealing with dying software. There is also a lot of software that should have died a long time ago, but it was not allowed to. Nowadays there are armies of maintenance developers defibrillating, heart-massaging and mouth-to-mouth breathing thousands of zombie systems all over the world.

Undead code

How can we deal with dead and dying software? Maybe we just have to be more cruel (and more honest) and accept their death. Maybe this enables the rest of the software population to live healthier, maybe even to thrive and prosper… the other important thing here is to get rid of the dead. Make a clean break, don’t keep the dead (or  almost dead) software lying around. Dead or dying software has the tendency to keep you incredibly busy. If you are not cruel, you won’t get rid of it:


Different cultures dealt differently with ageing and dying individuals. A well known example is the senilicide in ancient Eskimo culture: Old people that could no longer contribute to the well-beeing of the group were cast out to die in the snow. This certainly was a very cruel way, but it ensured the survival of the group in times of scarcity.
It is a well known fact, that enterprises have big problems finding developers to maintain their legacy systems. Developers often are not motivated to deal with legacy software. The lack of good developers that deal with legacy software, makes maintaining dying systems even more difficult and can accelerate the rotting of that software.
So maybe this is the cruel way in the software development ecosystem: In times of scarcity, developers choose which systems should die by refusing to work on them ...


Von Zeit und Datenmengen
Bei Datenmigrationen und der Batchverarbeitung kommen 2 Bereiche zusammen bei denen viele Entwickler (mich eingeschlossen) schnell an eine mentale Grenze stossen: Zeit Datenmenge Wohl ist jedem bekannt das ein Tag 24 Stunden hat und ein Terabyte aus 1024 Gigabyte besteht. Und doch kommt es immer wieder zu bösen Überraschungen.   Eine Optimierung am Code ist […] mehr
Weekend Reader, Week 29

IMG 0210

On the News:

Translation of the Apple-IBM romance

You heard it, Apple and IBM are best friends now. But what does it mean? This funny post translates the press release into something that we can understand:

 Enterprises love hand holding more than fat kids love candy. Apple is going to offer them hand holding through IBM.


Reflecting on Software Engineering:

Software Environmentalism

My colleague Tudor is musing about how we can deal with the fact that software systems get larger and larger, and they are being created at an ever increasing rate.

We cannot continue to let systems loose in the wild without any concern for how we will deal with them at a later time.

He proposes:

No system should get away without dedicated tools that help us take it apart and recycle it effectively.

For the profession he concludes:

Software engineering is more about dealing with existing systems as it is about building systems.


The Maintenance Developer Myth and The Noble Art of Maintenance Programming

So, software maintenance and dealing with legacy code is only going to increase as software is eating the world. But introducing a chasm between “real” developers and “maintenance” developers is probably not going to help.


What are good developers anyway?

Why are we interviewing developers by asking architect questions? Is it really what we need? When we deal with legacy, architecture gets less and less important. Problem solving skills are what really matters ...


But software eventually collapses under it’s own weight

(the obligate wisdom from Steve Jobs, which seems fitting at that point)


On JavaScript:

Breach: A browser written in JavaScript

Atwood’s law exemplified: "Any application that can be written in JavaScript, will eventually be written in JavaScript." is on sale!

If you want to learn JavaScript seriously, this screencast is a good starting point.


A JavaScript survival guide

If you are afraid of the pain of learning JavaScript, this post gives you some valuable survival tips.


Tech learning  recommendations:

Modern Structured Logging With Serilog and Seq

This is a interesting course on pluralsight. I am wondering what the alternative would be for the Java ecosystem? I guess I will attend the ELK workshop at ch/open Workshoptage in this regard.


Java Script Jabber Episode 106: Protractor with Julie Ralph

A good introduction to end-to-end testing in general and to the Protractor test framework. The episode also contains good discussions about software testing in general and gives insight about testing at Google.


Getting Started With Protractor and An Introduction to AngularJS End to End Testing with Protractor

If you are interested in Protractor, then this is a short tutorial and a longer introductory presentations


Some facts about Stateless EJB beans

It’s always good to repeat that stuff ...

SyncToy: Ein kleiner Backup-Helfer
An Backups denkt man in der Regel erst wenn es zu spät ist. Vorher ist es immer zu aufwändig und man glaubt eh keine wichtigen Dateien zu haben die nicht noch irgendwo anders gespeichert sind. Um nicht eines besseren belehrt zu werden würde es genügen die Daten nur regelmässig auf ein externes Laufwerk zu sichern. […] mehr

Für die Forumaktivitäten und Termine werden wir vorläufig die Xing-Plattform nutzen. Nähere Informationen findest Du unter dnug-bern.

Veranstaltungshinweis SQL Performance Tuning