Seiten

Sonntag, 15. August 2010

Bootcamp ist doch nicht schuld

 Da habe ich das liebe Bootcamp doch zu unrecht beschuldigt meine Probleme mit Daemon Tools ausgelöst zu haben. Aber der Reihe nach:
Nachdem ich nun seit einer Woche Besitzer eines neuen Macbook Pro bin und zunächst mal Mac OS einem ausführlicheren Test unterzogen habe wurde es Zeit das Gerät arbeitsfertig zu machen. Da die Nutzung von Visual Studio 2010 auf dem Notebook für mich ein absolutes muss ist, komme ich um eine Windows 7 Installation nicht herum. Nebenbei vermisse ich bei Office for Mac auch OneNote. Die eigentliche Windows Installation ist sehr einfach. Im wesentlichen eine Standardinstallation nachdem man kurz Bootcamp eingerichtet hat.

Da ich auf Windows sowieso mehr Speicherplatz brauche, als auf Mac OS ist die Windows Partition direkt größer geworden. Hat den angenehmen Nebeneffekt, dass ein möglicher Installationsfehler des .NET Frameworks sich auf die größere (leerere) Partition installieren zu wollen direkt umschifft wurde.
Die Software im MSDN Programm wird per Image zur Verfügung gestellt, darum habe ich nach der Installation direkt mal Daemon Tools installiert und rebootet. Lief auch 1A. Anschließend noch ein bißchen gepatcht Anti Virus Software (Avast + Threatfire) dazu getan und angefangen meine Software zu konfigurieren. Abschließend reboot, fertig. Dachte ich zumindest.

Nach der Anmeldung begrüßte mich eine Fehlermeldung:

---------------------------
DAEMON Tools Lite
---------------------------
This program requires at least Windows 2000 with SPTD 1.51 or higher.
Kernel debugger must be deactivated.
---------------------------
OK   
---------------------------
Was zunächst nach nem Kompatibilitätsproblem zwischen Windows und Daemon Tools aussah, entpuppte sich nach einigem analysieren und suchen als Problem von Threatfire. Daemon Tools bzw. konkret der benutzte SPTD Treiber macht Probleme, wenn der Threatfire Service vor dem SPTD Treiber geladen wird. Leider kommen Anti-Viren Programme in der von Windows festgelegten Hierarchie sehr weit oben, Manipulation nicht möglich.
Wer also den Start von Threatfire verzögern möchte muss auf Tools wie Win Patrol zurückgreifen. Aktuell gibt es nur diesen Workaround. Ob es noch eine Lösung geben wird? Fraglich.

Kick It on dotnet-kicks.de

Montag, 9. August 2010

Atomkraft NEIN NEIN! jein!.....hm...ja?

 Die Macht oder der Fluch von 140 Zeichen.....

Ich hatte nicht erwartet, wie kontrovers die Atomstrom Diskussion auf Twitter geführt werden würde. Sonst hätte ich mich wohl nicht zu einer Äußerung "Ich bin pro Atomstrom" hinreißen lassen. Diese steht nun ungefiltertet so im Raum. Ja ich habe das so gesagt.  Ich stehe auch durchaus dazu. Nur eben innerhalb gewisser Parameter.

Zunächst mal den Rahmen abstecken. Atomstrom ist ein zweischneidiges Schwert. Gut für die Betreiber, da sehr effizient und billig, aber schlecht für die Umwelt. Nicht zuletzt auch für den Menschen. Dass Menschen um Atomkraftwerke häufiger an Krebs erkranken, als in anderen Gebieten ist Wissenschaftlich zwar noch nicht erwiesen, statistisch aber zumindest auffällig. Des Weiteren bleibt vor allem immer noch die große Frage der Endlagerung. Ein ungelöstes Problem. Ich hab auch kein allgemeingültiges Rezept dafür parat. Eine Meinung, aber keine Lösung.

Man kann auch schlecht wegdiskutieren, dass es in den vergangenen Jahren immer wieder Störfälle in europäischen Anlagen gegeben hat.  Deutschland, Schweden und wer nicht noch so alles Probleme gemeldet hat. Von 1986 Tschernobyl will ich gar nicht reden. Das dürfte wohl bei allen präsent sein.
Doch trotzdem schreibe ich bei Twitter: "Ja ich bin pro Atomkraft".  Eigentlich ja verrückt bei den Nachteilen.
Realistisch betrachtet sieht es aber doch folgendermaßen aus. Wenn wir zum jetzigen Zeitpunkt alle AKW von heute auf morgen abschalten würden, müssten wir Strom dazu kaufen. Und woher würde der Strom kommen? Aus dem Ausland. Unsere Nachbarländer bauen auch weiterhin neue Meiler. Ob die Sicherheit dabei im Vordergrund steht? Möchte ich nicht beurteilen. Mein Gefühl sagt mir tendentiell, ich traue deutscher Technik mehr als anderer.
Der Ausbau erneuerbarer Energien ist noch nicht soweit, wie er sein könnte. Ein Großteil der Schuld liegt hier nicht zuletzt bei den Politikern bzw. der Atomkraft Lobby. Zu wenig wird hier dem Druck der Lobby entgegengewirkt. Es gibt kaum einen Anreiz für die Konzerne in erneuerbare Energien zu investieren.
Die Frage ist, was können wir selbst tun? Ich würde als einzige Möglichkeit den Wechsel auf Ökostrom sehen. Wobei da auch genügend Schindluder getrieben werden. Ich glaube nicht das wirklich der Ökostrom so öko ist wie da immer getan wird. Proteste usw. gehen den Konzernen doch sonst wo vorbei.
Politiker abwählen? Nun ja.... Die grünen Wählen? hmm...will man das wirklich?

Hat sich mal jemand übrigens mit der Herstellung von Silizium beschäftigt? Das Zeug das nicht nur für PCs, sondern auch für Solarzellen benutzt wird? Die Energiebilanz ist da sehr aufschlussreich.
Man rechnet für eine Anlage, die 3Megawatt Strom im Jahr erzeugt ca. 13 Megawatt an Strom für die Herstellung. Rein an der produzierten Menge hat sich das Panel also erst nach 5 Jahren amortisiert. Bei 15-20 Jahren Laufzeit geht das zwar. Ich finde die erforderliche Menge jedoch trotzdem Gewaltig. Nebenbei verschmutzt das Reinigungsverfahren auch nicht unerheblich die Umwelt.
Kohlekraftwerke sind auch nicht viel besser. Kohleabbau ist auch nicht gut für die Umwelt. Ganz im Gegenteil.

Das Energie Geschäft ist im Endeffekt auch ein Sumpf voller Doppelmoral. Wir alle erzeugen eine unheimlich Große Nachfrage nach Energie. Schauen wir alle immer auf die Ökologie? Nein. Es heißt bei vielen Unternehmen immer "Green-IT". Wieviele schließen Verträge über Ökostrom ab? Da würden mich konkrete Zahlen interessieren. Die Wahrheit ist doch: Der Großteil der Menschen verschließt die Augen vor Wirklichkeit. Strom kommt eben aus der Steckdose. Was geht mich das an wo der her kommt?
Bei Strom sieht man keine sterbenden Kinder in Afrika (Beispiel Biogas Anlagen oder KiK).

Um das ganze Mal auf den Punkt zu bringen: nach derzeitigem Stand wäre eine Lösung mit erneuerbaren Energien zwar möglich, aber nicht realistisch, aufgrund der Interessen der Konzerne. Solange wie wir das nicht ändern, sehe ich lieber deutsche Atomkraftwerke, als ausländische. Klar ist: wenn in Europa eines dieser Dinger hochgeht, haben wir auch was davon. Es spielt also im Endeffekt keine Rolle wo sie stehen.
Und so lange wir die Dinger also nicht komplett in Europa loswerden können möchte ich den Satz so formulieren, wie ich ihn eigentlich hätte schreiben müssen:

"Ich bin pro deutsche Atomkraft und habe nichts gegen eine dezente Laufzeitverlänger im Bereich 3-5 Jahre, solange am Ende die komplette Ablösung durch erneuerbare Energien steht"
Grundsätzlich lieber früher ohne AKWs, als später.

Ich hoffe ich konnte nun ein etwas differenzierteres Bild meiner Meinung darlegen ;-)

Kick It on dotnet-kicks.de

Samstag, 10. Juli 2010

Die "Informatiker" und ihr Ruf

Sie: "Und was machst du so beruflich?"
Er: "Ich bin Informatiker"
Sie: "Oh..."

Tja...der ein oder andere wird sicherlich schonmal ähnliche Erfahrungen gemacht haben. Viele Leute begegnen einem "Informatiker" (ich fasse die verschiedenen Berufsgruppen die es in diesem Bereich gibt einfach mal unter diesem Sammelbegriff zusammen) mit einiger Skepsis und Vorurteilen.
Ich frage mich oft woher das kommt. Die meisten sehen ja nun nicht aus wie Ken Thompson oder Dennis Ritchie. Da erkannte man Informatiker noch an ihrem Äusseren.

Heute ist das alles etwas anders. Eine jüngere Generation ist nachgerückt. Gerade in den beratenden Bereichen sind die Informatiker gut gekleidete Leute mit Benehmen. Viele verdienen auch richtig gutes Geld. Trotzdem, wenn man sagt "ich bin IT'ler" erntet man oftmals fragende oder verständnislose Blicke. Es fehlt anscheinend das Verständnis, wie man so einen Beruf ergreifen kann.
Vielleicht ist es die Hingabe die man zwangsläufig für diesen Beruf haben muss. Ich glaube nicht, dass es viele andere Branchen gibt, die mehr Anforderungen in Richtung Arbeitszeit stellen als die IT (ausgenommen sozialer Sektor, Feuerwehr, Polizei, Krankenhaus). Die meisten reissen ihre Arbeitszeit ab und dann ist Feierabend. Schluss nach Hause und vergessen.
Hand aufs Herz: wie oft sitzt man aber als IT'ler und gerade als Programmierer zu Hause und grübelt über ein Problem; doch noch mal eben ein commit ins repository. Ich merke es bei mir. Mein Beruf nimmt auch einen Teil meiner Freizeit ein: Bewußt! Das sei hier ganz deutlich erwähnt. Mir macht es Spass mich mit komplexen Problemen zu beschäftigen, auf Veranstaltungen wie den Coding Dojos mit anderen der Branche auseinanderzusetzen, gemeinsam Probleme zu lösen.
Vielleicht ist es das was viele so irritiert. Dieser Ruf des "Nerds". "Der lebt doch in einer anderen Welt" - hört man oft als Vorwurf. Vielleicht stimmt das auch. Vielleicht driftet man ab in eine Welt wo man nur noch die IT-Probleme sieht.  Doch das trifft auf nur wenige Leute zu. Zumindest ist das meine Erfahrung.

In meinen Augen ist die Zeit der im Keller hockenden Einzelkämpfer vorbei. Sich ausdrücken, etwas präsentieren, verkaufen. Nur vor dem PC hocken war gestern, eher vorgestern. Kommunikation ist mittlerweile alles in diesem Beruf. Ich hatte bisher das Glück durch diese Beruf viele neue Menschen kennenzulernen. Doch nicht nur im "Real Life" wie es oft so schön heißt, auch und gerade über Twitter, facebook usw. kann man Kontakte machen, die einen beruflich und persönlich weiterbringen (Dies sei einmal als kleines Dankeschön an eben diese Kontakte verstanden ;) ).
So bleibt mir als Fazit aktuell nur eins: Informatiker sind besser als ihr Ruf.
Falls mir aber jemand noch einen vernünftigen Grund für eben diesen schlechten Ruf nennen kann, da wäre ich sehr gespannt!

Kick It on dotnet-kicks.de

Donnerstag, 3. Juni 2010

.NET online Coding Dojo - eine gute Plattform?

Gestern Abend fand das dritte online Coding Dojo mit Albert Weinert statt. Als Moderator war kurzfristig Thomas Wenzl eingesprungen. Dann waren da natürlich noch die 12 mehr oder weniger aktiven Teilnehmer ;)
Als Kata war "RomanNumerals" festgelegt worden. Dabei geht es um die Umwandlung einer Dezimalzahl in das römische Zahlensystem. Da die eigentliche Logik relativ trivial war, konnte man sich sehr ausführlich mit Architektur, Design und sauberer Entwicklung beschäftigen.
Die Durchführung hat sich im Vergleich zum zweiten Dojo etwas verändert. Das Medium war erneut Microsofts Live Meeting Console. Geändert hatte sich jedoch der Modus, in dem die Kata ausgeführt werden sollte: Randori. Randori bedeutet in diesem Fall, das zweier Teams für eine festgelegte Zeit (hier: 10 Minuten) zusammen am Code arbeiten und dann an die nachfolgende Gruppe übergeben. Klarer Vorteil: Jeder muss mitmachen, jeder wird zum denken gezwungen.
Doch bevor es in den zweier Teams los ging, haben wir gemeinsam in der Gruppe die grundlegende Architektur und das Design festgelegt. Die Entscheidung nicht bereits hier mit dem Randori zu beginnen halte ich aus 2 Gründen für sehr sehr sinnvoll:
  1. wenn ich am Design mitwirken kann, identifiziere ich mich mit der Design-Lösung, das führt zu Motivation
  2. bereits die Diskussion über die Architektur birgt die Möglichkeit etwas zu lernen
An dieser Stelle möchte ich mich ein wenig von der konkreten Kata verabschieden und mehr die Plattform "online Dojo" mit ihren Vor- und Nachteilen, wie ich sie gestern kennengelernt habe, betrachten.

Grundsätzlich finde ich, dass die ganze Geschichte mit 3 Punkte steht und fällt.
Da wäre zunächst die Beteiligung der Teilnehmer. Gerade Online ist es relativ einfach sich aus allem herauszuhalten und nur als stiller Zuhörer dem Geschehen zu folgen. Das mag bei einzelnen Fällen noch funktionieren, bei einer großen Anzahl wird es dann kritisch.
Gestern hat das glücklicherweise sehr gut funktioniert. Einen großen Anteil daran hatte wohl die Randori Form. Diese Form halte ich für Ideal für die Plattform Online Dojo. Jeder muss sich beteiligen, gleichzeitig gibt es jemanden als Backup, wenn man selbst einmal nicht weiter weiß. Dies ist auch gleichzeitig mein Argument, warum man es nicht auf einzelne Personen herunterbrechen sollte. Dies würde gerade Anfänger sehr stark einschüchtern.

Des Weiteren ist mir gestern sehr stark deutlich geworden, wie wichtig ein guter Moderator für den Erfolg des Dojos ist. Thomas Wenzl hat das in meinen Augen sehr sehr gut gemacht. Wenn wir zu weit vom Thema abgeschweift sind hat er unseren Fokus wieder zurück auf das Problem gebracht und zwischendurch den ein oder anderen Impuls gegeben um die Gruppe auf dem richtigen weg zu halten. Das erwarte ich von einem guten Moderator. Das hat die Gruppe als ganzes auf dem Weg und bei der Stange gehalten.

Der dritte Faktor ist die Umsetzung des online Dojos. Welche Tools werden eingesetzt, passen gezeigtes und gesagtes zusammen. Die Live Meeting Probleme ist an sich ein sehr gutes Medium, lässt bei der Performance jedoch manchmal etwas zu wünschen übrig. Wie sich gestern gezeigt hat, wissen auch nicht alle Teilnehmer welche Features die Console überhaupt bietet. Dort besteht noch Verbesserungsbedarf. Beispielsweise beim Einsatz der Handout Funktion oder die Nutzung des Chats.
Auch das Zeitmanagement ist online so eine Sache. Bei einem geht das Mikro nicht, dann nutzt man spontan mal ein neues Tool, wieder andere konnten die Kata noch nicht lesen. Ich möchte das jetzt nicht als Kritik an einzelnen Personen verstanden wissen. Im Gegenteil bin ich hier sehr dankbar für das Engagement.
Ich möchte hiermit lediglich Verbesserungen in der Vorbereitung aufzeigen.

- Tools mit denen man in der Handhabung geübt ist
- im Voraus ein Repo mit allen nötigen Dokumenten
- Teilnehmer, die ihr Equipment prüfen ;)


Apropos Zeit: einhellige Meinung gestern war, dass es ruhig eine Stunde länger dauern darf. Also von 2 auf 3 Stunden. Damit kann man einige Probleme der Plattform abfangen.
Abschließend bleibt mir nur noch Albert und Ilker für die Organisation und Thomas für die gute Moderation zu danken. War ein lehrreicher und vor allem auch kurzweiliger Abend.

Konkrete Anregungen können durchaus in der kommenden Woche noch folgen ;)

Kick It on dotnet-kicks.de

Montag, 10. Mai 2010

Einstieg für Programmierer - Erweiterung


In seinem Blogeintrag Dschungelwegweiser für Programmieranfänger gibt Rainer Hilmer einige Tipps für den Start ins Programmiererleben. Ich beschäftige mich nun ein knappes Jahr mit der .NET Plattform / Programmierung und bei mir ist diese Zeit daher noch nicht sonderlich lange her. Ich kann daher sehr gut einige Worte dazu verlieren:

Grundsätzlich sind die genannten Quellen sehr gut, setzen aber voraus, dass man schon sehr genau weiß, wo man am Ende landen möchte. Grade am Anfang sollte man sich meiner Meinung nach zunächst auf eine Sprache festlegen. Viele Einsteiger haben schon dort das Problem sich zu entscheiden. .NET bietet sowohl für Einsteiger, als auch für Profis sehr umfangreiche Möglichkeiten, die man je nach Kenntnisstand nutzen kann. Seien wir mal ehrlich, es gibt für einen Anfänger doch nichts schöneres als wenn er sehr schnell echte Erfolge erzielen kann.Und nach einer Stunde eine WindowsForms Anwendung mit Datenbankanbindung zusammen zu klicken halte ich für sehr motivierend. Ist zwar nicht unbedingt sehr sauber, kein wirklich genialer Code. Aber man hat Erfolg. Und Erfolg ist die Motivation, die die Leute bei der Sprache hält.

Apropos Sprache, welche Sprache innerhalb .NET eignet sich denn am Anfang? Visual C++ und F# scheiden in meinen Augen aus. VB.NET und C# scheinen mir eher eine gute Wahl für den Einstieg zu sein. Eine Entscheidungshilfe bietet z.B. auch der Blogeintrag von Golo Roden.
Anmerkung: Wenn jemand natürlich für die Linux Plattform entwickeln möchte würde ich stattdessen zu Java greifen. Aber sowohl Java als auch C# haben den Vorteil, dass man sich Syntaktisch in der Zukunft recht wenig um gewöhnen muss. Erst Recht wenn man zwischen diesen beiden Sprachen tauscht. Ich persönliche habe mich auch genau aus diesem Grund für C# entschieden. Mir liegt 1. die Syntax besser 2. fand ich die Syntax von VB grausam 3. der leichtere Wechsel zu anderen Sprachen.

Bleibt noch der richtige Einstieg: Ich denke, dass man gerade am Anfang nicht um das Lesen eines guten Buchs drum herum kommt, zumindest als Autodidakt. Empfehlen kann ich da beispielsweise C# von Kopf bis Fuß. Kostet leider Geld, ist aber ein super Einstieg, vor allem mit einem guten Lehransatz. Definitiv ein guter Einstieg sind auch die Bücher von Galileo Openbook, sehr umfangreich und kostenlos. Und das nicht nur zu C# und VB ;) Wenn man sich parallel dazu mit den von Rainer genannten Quellen auseinandersetzt hat man eine gute Basis.

Noch ein Satz zu CCD, TDD und anderen Paradigmen: Ich denke, je früher man mit CCD beginnt (wieso findet man bei der Google Suche nach CCD eigentlich nichts, da muss man mal was machen ;) ), desto besser, wohingegen ich mir Dinge wie TDD aufsparen würde, bis man das entsprechende Handwerkszeug parat hat und sich beim Entwickeln in seiner Sprache sicher fühlt.




Mein Forum der Wahl in Sachen C# ist übrigens mycsharp.de .. gute Leute, gute Artikel und gutes Forum ;)

Schönen Tag noch und ich hoffe die Ergänzungen waren hilfreich ;)

Kick It on dotnet-kicks.de

Samstag, 8. Mai 2010

Strukturen der Softwareentwicklung - oder der Kampf gegen Windmühlen

Gegen Ende meiner Ausbildung habe ich mich immer stärker dafür interessiert selbst Software zu entwickeln. Wenn auch vielleicht nicht die natürliche Domäne eines FiSis, ist es doch zumindest kein völliges Neuland gewesen. Am Anfang begann es mit simplen kleinen Anwendungen, zu einer Zeit in dem CCD, TDD, refactoring und Codequalität noch mehr oder weniger Fremdwörter waren. Von standardisierten oder geplanten Testverfahren mal ganz abgesehen.
Mit der Zeit kommt dann der Wunsch nach mehr Qualität und Professionalität. Das nötige Interesse vorausgesetzt verschlingt man alles an Material was man in die Finger bekommt, nutzt jede Chance zum Informationsaustausch.  Man eignet sich Standards an, lernt Pattern; versucht das zu bekommen, was allgemein als guter Stil bezeichnet wird. Grade die Blogs der diversen deutschen MVP haben mich in Sachen .NET / C#
ein großes Stück vorangebracht. Ein großer Schritt war für mich auch nochmal das Dojo am vergangenen Donnerstag mit Albert Weinert und Ilker Cetinkaya, in dem mir einige Dinge in der vorgehensweise beim TDD nochmal näher gekommen sind. Tja schön und gut. Soweit die Theorie. Wie sieht denn die wirklich eines Softwareentwicklers aus?

Passenderweise fand am Freitag morgen ein Meeting meiner Projektgruppe statt. Mit Blick auf einen verbesserten Entwicklungsprozess habe ich versuchsweise die Kollegen befragt, wie es denn mit dem Kenntnissstand CCD bzw. TDD und agile Methoden aussieht (also die Themen die "in Mode" sind). 2 Hatten es mal gehört die anderen konnten mit den Begriffen nichts anfangen. Mager...ziemlich mager sogar. Tja, bin ich zu ambitioniert? Die anderen desinteressiert? Kann man es sich an der Front nicht leisten Rücksicht auf guten Code zu nehmen? Zählen letztendlich nur Ergebnisse?
Vielen Entscheidungsträgern sind die Vorteile "moderner" Methoden noch nicht klar. Das beginnt schon bei der Beschaffung von Lizenzen. Bis heute gibt es kein resharper Add-in, ein hoch auf meine private Lizenz. Den Zeit Gewinn und damit das Einsparungspotential hingegen möchte wohl niemand sehen. Dort steht erst einmal nur die Investition. Analog sieht es da mit Schulungen und Qualifikationen aus. Zuviel muss hier noch selbst initiiert werden. Keine Initiative der Führungskräfte.
So helfen einem auch die besten Methoden und Werkzeuge nichts, wenn sie bei der Masse an Entwicklern nicht ankommen. Denn Hand aufs Herz, so wie hier beschrieben ist es leider noch viel zu oft.
Nur ein relativ geringer Anteil an Entwickler hat entweder die Chance oder die Muße sich auf dem aktuellen Stand zu halten. Sei es nun aus mangelndem Interesse oder mangelnder Möglichkeit.
Dabei ist doch gerade die Weiterentwicklung und Anpassung alter Strukturen an neue Gegebenheiten unser Kapital als Entwickler.

Ein Beispiel gefällig? Der ein oder andere wird sicher die "null" Diskussion verfolgt haben. In der Vorstellung eines vergleichsweise simplen Codefragments kam die Frage auf, ob null ein aktzeptabler Rückgabewert sei ( Blog von Thomas Bandt). Einige bekannte Köpfe der .NET Szene haben daraufhin ihre Meinung dazu dargestellt. Diese haben jedoch einen nicht zu verachtenden Vorteil: aufgrund ihrer Tätigkeiten haben sie wesentlich größeren Einfluss auf den Verlauf eines Projekt. Für den "normalen" Entwickler liegt hier wahrscheinlich nichtmal ein Problem vor. Wie denn auch wenn er keine Zeit hat darüber nachzudenken?
Natürlich kamen bei der Diskussion einige sehr interessante Ergebnisse heraus. Doch wie Praxisrelevant können dort formulierte Regeln sein? Die zweifellos gut gemeinten Ideen sind sehr wertvoll, kommen jedoch nicht bei dem breiten Entwicklerstamm an.

Tja und ich als Einzelkämpfer? Lohnt es sich den Kampf aufzunehmen und trotz mißtrauischen Blicken im Hinblick auf TDD und dem Versuch, die Werte des CCD zu verinnerlichen dieses Konsequent anzuwenden, auch wenn der Rest des Teams anders arbeitet?
Ich denke ja. Die einzige Chance ist es mit gutem Beispiel voranzugehen und zu zeigen, welche Vorteile in den Möglichkeiten moderner Softwareentwicklung stecken. Wenn zumindest mein Code durch TDD Fehlerfrei läuft und dank den Werten des CCD besser les- und wartbar ist, ist das doch irgendwie auch schon ein Erfolg, oder?
Und wer weiß, vielleicht fängt dann auch jemand anderes an, über den Tellerrand zu schauen.

Kick It on dotnet-kicks.de

Dienstag, 20. April 2010

TDD - öfter mal was neues

Ui ui, schreibwütig heute :>

Irgendwie kommt man ja aktuell um das Thema TDD - Test Driven Development - nicht herum, wenn man sich mit Software Entwicklung beschäftigt. Nachdem ich vor nem knappen halben Jahr auf C# umgestiegen bin und mich desöfteren in einschlägigen Foren / Seiten / Blogs umhertreibe, bin ich nun dabei meine Kenntnisse zu verfeinern und meinen Horizont zu erweitern. Tja, kommt davon wenn man als FiSi dann doch den Drang verspürt Programmieren zu wollen ;)

Tja... TDD, worum gehts dabei eigentlich? Ich konnte mir da zunächst mal nicht sonderlich viel drunter vorstellen (abgesehen von dem bißchen, was man sich vom Namen ableitet). Scheint also was mit Tests zu tun zu haben.
Grundsätzlich geht es darum, dass bevor man mit der eigentlich Implementierung seines Programms beginnt, zunächst Testfälle für die eigentliche Software zu schreiben. Grob gesagt: Man stellt die Anforderungen, die man an die Software stellt, innerhalb der Testfälle dar und kann so relativ leicht feststellen, ob die Software die passenden Ergebnisse liefert.
Ist zugegebenermaßen vor allem für Leute, die sich das Programmieren selbst beigebracht haben, etwas gewöhnungsbedürftig nicht sofort zu beginnen, die eigentlichen Methoden zu implementieren.

Tja soweit die Theorie. Irgendwie war gerade mir als Quereinsteiger das ganze irgendwie ein wenig Suspekt und nicht so ganz klar, wie das funktioniert. Glücklicherweise bin ich dabei auf den Blog von Thomas Bandt gestoßen, der sich auch über das Thema ausgelassen hat. Als MVP auch wesentlich kompetenter als ich. Er hat ein sehr interessantes Video von Gabriel Schenker gepostet, der ein 2 stündiges Videotutorial erstellt hat.
Das ganze ist ebenfalls im Blog von Thomas Bandt verlinkt.

Vielen Dank für die guten Beiträge! =)

Kick It on dotnet-kicks.de