nettigkeiten.ch

nettigkeiten.ch goes Mobile!

Dani — Thu, 24 Jul 2008 22:22:42 GMT

Dank der MobileFeeds-Applikation meines früheren Arbeitgebers Connvision kann mein Blog nun auch komfortabel auf einem Mobile-Phone gelesen werden (mit entsprechend angepasster Darstellung).

Als Leckerli erhält man bei MobileFeeds auch gleich einen BeeTagg der auf den Mobile-Feed linkt. Die Software die man benötigt, um den BeeTagg zu lesen kriegt man hier oder auch über Wap-Push (weitere Infos: beetagg.com).

Ist der Reader erst installiert, kann man den untenstehenden BeeTagg lesen und wird auf den MobileFeed geleitet.

Hier noch eine kleine Demo wie kinderleicht das mit dem BeeTagg scannen so funktioniert:

Restaurant-Tip: Focacceria, St. Gallen (CH)

Dani — Tue, 22 Jul 2008 19:22:20 GMT

Ein kleines Novum hier im Blog. Ab und an will ich in Zukunft auf, meiner Meinung nach, besonders erwähnenswerte Restaurants hinweisen. Ich verstehe dies auch als kleine Belohnung für die jeweilige Crew, welche sich abgemüht hat, meiner Begleitung und mir einen schönen Abend zu ermöglichen. Schliesslich gibt es ja leider genug andere Beispiele.

Wer die Focacceria betritt, wird von einer warmen, etwas rustikalen und trotzdem modern angehauchten Atmosphäre empfangen. Im Erdgeschoss ist quasi der Imbiss-Bereich – wobei dies einen etwas negativen Touch hat, der hier wahrlich nicht angebracht ist.
Im hinteren Bereich erwartet einen dann eine Theke voller mediteraner Köstlichkeiten, welche einem direkt an einen italienischen Feinkosthändler erinnert. Da reihen sich feinste Antipasti neben selbstgemachten Pasten (z.B. Oliven) ein. Die Stars der Theke sind aber die x verschiedenen Käsesorten sowie de grosse Auswahl an verschiedenen Leckereien für den Fleischesser. Hier darf man nun also sein eigenes Focaccia zusammenstellen. Es gibt drei verschiedene Grössen, wobei zumindest ich für das Grösste schon einen rechten Hunger brauche. Dann kann man sich eine Fleisch- oder Käsesorte auswählen, zwei Antipasti sowie eine Paste. Salat (z.B. Ruccola) gibt’s gratis. Das Fleisch wird frisch angeschnitten und mit den anderen Zutaten in das erwärmte Focaccia gepackt. Nun noch ein prickelnd frisches Gazosa dazu, und die Ferien-Stimmung ist perfekt.

(Bild focacceria.ch)

Wer sich die schmale Treppe nach oben getraut, findet dort ein etwas eleganter aufgemachtes kleines Restaurant. Der obere Stock ist bedient. Man kann dort, neben den Focaccias auch von einer sehr kleinen aber feinen Karte aussuchen. Die Karte wird täglich geändert und offeriert einem gluschtige Tagliatelle, Suppen und Salate. Nach dem Essen sollte man sich unbedingt auf einen Dolci-Vorschlag der Bedienung einlassen, da gibt’s wirkliche Leckereien darunter.

Alles in allem ein wirklich gelungenes Lokal welches die totale Italianità versprüht. Die Preise sind zwar nicht ganz ohne, aber dafür erhält man auch wirklich qualitativ hervorragende Lebensmittel sehr gut zubereitet.

(Bilder focacceria.ch)

Die Focacceria befindet sich an der Metzgergasse 22, 9000 St. Gallen.

Alles neu!

Dani — Thu, 17 Jul 2008 21:06:32 GMT

Tattaaa! Happy New Year! Der erste Post 2008! Naja... ist ja erst Mitte Jahr

Die üblichen Entschuldigungen spar ich mir mal und konzentrier mich hier lieber auf die wichtigen Sachen. Ich habe mich, wie so manche andere auch in letzter Zeit, von dasBlog verabschiedet und mich für SubText entschieden.

Die Umstellung war recht harzig und mühsam und mit diversen Stolpersteinen versehen. Aber zum Glück gibts ja nette Leute die ihre Erfahrungen der Öffentlichkeit hinterlassen. Allen voran sei hier Oren Eini erwähnt, der sogar das UrlRewriting von SubText erweitert hat, so dass auch die meisten alten dasBlog-Links noch funktionieren sollten.

Solltet ihr trotzdem etwas nicht finden, dass noch nicht funktioniert, wär ich um eine kurze Meldung dankbar.

Auch wenn die alten Links dank Oren noch funktionieren sollten, passt eure Einstellungen doch trotzdem bitte auf die neue URL http://blog.nettigkeiten.ch an.

Schon komisch... da gibt's ein halbes Jahr lang kein Lebenszeichen, und kaum muss ich ins Militär, gibt's grad einen Relaunch... Naja, mal schauen, je nach Lage an der Front reichts dann vielleicht auch noch gleich für ein bisschen "anmalen".

Adventskalender bei entwickler-press.de

Dani — Sat, 01 Dec 2007 13:22:17 GMT

Heute schiessen ja die Adventskalender auf den verschiedensten WebSites geradezu aus dem Boden. Einer, dessen Besuch sich wirklich lohnt, ist auf entwickler-press.de zu finden. Dort gibts nämlich jeden Tag ein eBook gratis und franko zum Download, ja man muss sich noch nicht mal registrieren.

Heute gibts Managed Direct X und C#.

KeePass und Ubuntu

Dani — Sat, 01 Dec 2007 13:09:51 GMT

KeePass war mir unter Windows ein ständiger Begleiter und passte für mich perfekt zur Verwaltung meiner Passwörter. Mittlerweile ist meine Passwort-Datenbank auch schon recht angewachsen... blöd nur, dass es das Ding nur für Windows gibt.

Trotzdem - mal googlen... aah...

KeePassX, eine Portierung von KeePass für Linux- und Mac-Systeme - und ja, es kann die KeePass-Datenbanken lesen - und auch umgekehrt. So kann ich also weiterhin die bestehende Datenbank nutzen und diese unter Linux mit KeePassX und unter Windows mit KeePass lesen.

KeePass
KeePassX

Ich geh fremd!

Dani — Wed, 28 Nov 2007 19:34:33 GMT

Nachdem ich schon seit längerem ein Doppelleben führte, habe ich mich nun definitiv entschieden! Seit der Version 7.10 bin ich vollständig auf Ubuntu umgestiegen. Wieso denn das?

Durch mein Studium musste ich mich zwangsweise das eine oder andere Mal mit Linux auseinandersetzen, und je länger ich damit arbeitete, desto mehr stieg meine Begeisterung dafür. Die Arbeit damit ist einfach effizienter, die typischen Slow-Downs die ich unter Windows immer wieder hatte (Vista kann man fast als andauernden Slow-Down bezeichnen ;-) ) bleiben unter Linux eine wirkliche Seltenheit.

Dazu kommt noch, dass es eine ganze Menge an kleinen feinen Tools gibt, die natürlich allesamt Open-Source sind.

Natürlich komme ich, als .NET-Entwickler, nicht um Windows rum - aber dafür gibts ja VMWare.

Eine professionelle Entwicklungsinfrastruktur für (fast) lau (Teil 2 von 5) - IDE

Dani — Wed, 28 Nov 2007 18:33:53 GMT

Mit knapp 2 Monaten Verspätung folgt nun also der zweite Teil dieser kleinen Serie :-)

Die IDE ist das meist täglich gebrauchte Werkzeug eines jeden Entwicklers. Unter .NET ist das mit Abstand am meisten verbreitete Exemplar dieser Gattung Visual Studio in den verschiedenen Ausprägungen. Wie bereits in Teil 1 geschrieben, erachte ich die Wahl der IDE als sekundär, Hauptsache der Entwickler findet sich damit zu Recht - also vergleichbar mit den Kochmessern eines Küchenchefs :-)

Dieser Artikel wird zeigen, wie man mittels Visual Studio 2008 seine Projekte mit UnitTests testet. UnitTests sollten genauso ein Selbstverständnis für einen Entwickler sein, wie auch alle anderen Punkte dieser Serie. Ich möchte hier nicht ins Detail gehen, das machen andere schon sehr gut - trotzdem aber die wichtigsten Punkte, um was es beim Unit-Testing geht. Zuerst also etwas Theorie.

Definition

Für ne schlaue Definition muss wiedermal Wikipedia herhalten:

"(...) unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application."

Also - man testet den kleinst-möglichen testbaren Teil einer Applikation - und das ist per Definition in einer OO-Anwendung natürlich die Methode. Dieser scheinbar unspektakuläre Satz, beeinhaltet schon einige der Grundsätze von Unit Tests.

Jeder Unit-Test testet genau eine Methode, nicht mehr und nicht weniger. Es werden also keine ganzen Abläufe (z.B. Abfolge von Method-Calls) getestet.
Das Resultat eines Unit-Tests sagt aus, ob die Methode (und nur genau die) gemäss dem definierten Testfall korrekt funktioniert.

Unit-Tests sollten immer möglichst einfach gehalten werden, dies reduziert das Risiko von Fehler im Test selbst.

Test-Driven Development

Im Zusammenhang mit Unit-Tests wird oftmals von Test-Driven Development (TDD) gesprochen. Wie der Name schon sagt, geht es dabei darum, mittels Tests zur eigentlichen Implementation zu kommen. Neue Funktionen werden stets gegen die zuvor definierten Testfälle implementiert und getestet. Eine Funktion gilt dann als implementiert, wenn diese alle für sie definierten Testfälle erfolgreich durchlaufen kann. In diesem Zusammenhang ebenfalls wichtige Konzepte sind

KISS - Keep it simple, stupid
YAGNI - You ain't gonna need it

Wichtiger Punkt im TDD ist also, nur genau das zu implementieren, was auch gefordert wird - und alles was gefordert wird, muss als Testfall hinterlegt sein. Jede Funktion die zusätzlich implementiert wird, quasi als gutgemeinten Bonus, ist nicht getestet (zumindest durch Unit-Tests) und stellt daher eine Verletzung dieser Prinzipien dar.

Die Regeln des Test-Driven Development

Der Ablauf beim TDD erscheint vielen Entwicklern anfangs etwas umständlich und gewöhnungsbedürftig. Auch scheinen die Regeln teils etwas überbestimmt. Trotzdem hat jede dieser Regeln ihre Berechtigung.

Schreibe den Test
Hier werden viele bereits stutzig. Den Test vor der eigentlichen Methode schreiben? Genau! Denn die Methode soll ja vom Test abhängen und nicht umgekehrt. Andersrum besteht immer die Gefahr, dass der Test um die Methode gebaut wird. Man testet das, was man weiss das die Methode kann - und nicht was sie können sollte.
Implementiere die Methode so, dass sie (und der zuvor definierte Test) gerade mal kompiliert, der Test aber fehlschlägt
Dieser Punkt wird oft ignoriert, da er so trivial erscheint. Der Punkt, dass der Test aber immer zuerst fehlschlagen soll, ist sehr zentral, da auch ein Test - wie jedes andere Stück Software auch - prinzipiell Fehler enthalten kann. Das heisst, der Test könnte immer erfolgreich sein, obwohl der Case gar nicht erfüllt ist. Dieser Punkt ist also quasi der Test des Tests.
Implementiere die Methode so, dass sie den Testfall besteht
Nun gehts also ans Eingemachte, die Methode soll ihre Implementation erhalten, und zwar so, dass sie den zuvor geschriebenen Test erfolgreich durchläuft. Wichtig dabei ist, dass hier noch nicht die ultimative Super-Lösung gebaut werden soll. Es soll in erster Linie mal einfach funktionieren. Nachdem in Punkt 2 ja getestet wurde, dass der Test fehlschlägt wenn er soll, muss jetzt ja auch mal gezeigt werden, dass er zu einer funktionierenden Methode auch sein "OK" gibt.
Refactor
Nun wird die laufende Lösung von Punkt 4 mittels Refactoring "verschönert". Der Test muss danach natürlich immer noch korrekt durchlaufen werden.
Starte wieder bei Punkt 1
Eine Methode hat in den seltensten Fällen nur einen Testfall. Da die Fälle sehr einfach gehalten werden sollen, gibt es hier meist ein ganzes Set von Tests pro Funktion. Dieser Punkt streicht den iterativen Ansatz dieser Methodik hervor. Die Implementation wächst also iterativ mit jedem Testfall, und ist genau dann fertig, wenn keine weiteren Fälle mehr zu definieren sind und alle definierten Fälle erfolgreich abgeschlossen werden können.

Wieso denn nun das ganze? Die Vorteile die aus dieser Vorgehensweise entstehen sollten für sich sprechen:

Fehlerfreie Software?
Nicht ganz - aber man weiss zumindest, und kann auch jederzeit nachprüfen, dass eine Funktion mit den definierten Testfällen klar kommt. Natürlich heisst das noch lange nicht, dass damit die Software korrekt funktioniert oder gar fehlerfrei ist. Jedoch kann man von einem gewissen Grad an Korrektheit ausgehen. Sollten trotzdem Fehler auftreten, waren die Testfälle nicht ausreichend.
Entspannte Änderungen
Jeder kennt das, man muss an einer Software etwas ändern und man ist sich vielleicht nicht ganz 100%ig über die Konsequenzen im Klaren. Side-Effects treten ja meist an den Stellen auf, an denen man sie am wenigsten vermutet. Kann der Entwickler jedoch nach seiner Änderung auf eine Fülle von erfolgreich abgearbeiteten Testfälle blicken, wird das sein Vertrauen merklich steigern. Auch hier gilt aber natürlich Vorsicht, die Änderung kann trotzdem Fehler verursachen! Evtl. müssen für die Änderung auch neue Tests eingeführt werden.
Dokumentation
Auch diese Situation ist wohl den meisten bekannt - man hat eine Methode vor sich und kann irgendwie nicht so greifen, was diese überhaupt genau macht. Die "erklärenden" Sätze in den Kommentaren machen das ganze auch nicht einfacher. Die Testfälle hingegen zeigen mit sehr übersichtlichem und einfachem Code, was die Methode zu erfüllen hat.
Lose Kopplung
Dies kommt praktisch gratis mit TDD mit. Denn wer so vorgeht, wird automatisch wenig Abhängigkeiten erzeugen. Abhängigkeiten sind immer irgendwo problematisch beim testen - da wird man sich also hüten.

Die Krux mit den Abhängigkeiten

Wie bereits geschrieben, sind Abhängigkeiten ein grundsätzliches Problem beim Unit-Testing. Man stelle sich zum Beispiel vor, man möchte eine Methode einer Datenbankzugriffsklasse testen. Beim schlichten Aufruf dieser Methode wird automatisch auch die Datenbank aufgerufen. Was test man so nun? Funktioniert das Db-Statement? Ist die Datenbank erreichbar? Oder doch nur ob die Funktion korrekt funktioniert? Ja genau - alles zusammen, und doch wieder nichts. Wenn was schief geht, ist nicht klar warum. Daraus ergeben sich einige Grundregeln, die man beim Schreiben der Tests beachten sollte:

Ein Unit-Test sollte nie

I/O-Funktionalität aufrufen (Filesysteme, Datenbanken, Netzwerk... alles tabu)
auf ein Konfigurations-File angewiesen sein
von anderen Unit-Tests abhängig sein. Jeder Test muss für sich allein funktionieren.

Solche Abhängigkeiten werden mit Hilfe von Mock-Objekten nachgebaut. Hierzu wird nächstens ein eigener kleiner Artikel folgen.

Wer all dies berücksichtigt - wird glücklich mit TDD - da leg ich meine Hand ins Feuer :-)

TDD mit Visual Studio 2008

Das neue Visual Studio (wie auch das alte :-) ) bietet alles, was man zu TDD benötigt. Zur Veranschaulichung ziehen wir mal so ein Szenario durch. Als Beispiel dient uns eine Applikation, die beliebige Zeichenketten durch verschiedene Sortieralgorithmen sortieren kann - so zum Beispiel mit QuickSort, ein beliebter "Divide and Conquer"-Algorithmus.

Als Ausgangslage dient uns folgender Aufbau der Applikation:

Program.cs beinhaltet etwas Code zur Verarbeitung der Eingabe sowie die schlussendliche Ausgabe des Resultates. ISortAlgorithm ist ein Interface, welches die Schnittstellen eines Sortieralgorithmus' vorgibt - nämlich:

public interface ISortAlgorithm
{
  string Sort(string toSort);
}

Nun haben wir ja vorhin einen schönen Ablauf definiert, also sehen wir mal ob der was taugt:

Punkt 1 - Test schreiben:

An dieser Stelle erlaube ich mir bereits die erste kleine Abweichung obiger Regel. Und zwar erstelle ich mir jeweils aus Bequemlichkeit bereits die Klasse sowie den Methodenrumpf bevor ich den Test schreibe. Das hat den Vorteil, das man beim Test schreiben auf IntelliSense zurückgreifen kann und nicht alles komisch rot unterstrichen erscheint. Ausserdem kann man sich das Gerüst für die Tests gleich in Visual Studio generieren lassen.

Ich erstelle also die Klasse QuickSortAlgorithm und implementiere das obige Interface ISortingAlgorithm. Das ist's dann aber auch schon. Danach genügt ein Rechtsklick ins Fenster zum Erstellen des Test-Projektes.

In dem generierten File findet sich dann eine Methode SortTest. Dies ist nun also unser Test, dessen Logik wir nun noch zu definieren haben.

       [TestMethod()]
       public void SortTest()
       {
            QuickSortAlgorithm target = new QuickSortAlgorithm(); // TODO: Initialize to an appropriate value
            string toSort = string.Empty; // TODO: Initialize to an appropriate value
            string expected = string.Empty; // TODO: Initialize to an appropriate value
            string actual;
            actual = target.Sort(toSort);
            Assert.AreEqual(expected, actual);
            Assert.Inconclusive("Verify the correctness of this test method.");
        }

Das TestMethod-Attribut gibt an, dass es sich bei der Methode um einen Test handelt. Dies ist notwendig, damit Visual Studio damit zu Recht kommt.

Um dies zu tun, muss man sich natürlich über die Anforderungen im Klaren sein. Unit-Tests sind WhiteBox-Tests - der Entwickler weiss also von der Implementation, dies ist auch nötig, wie wir später noch sehen werden. Also die Anforderung ist, dass wir der Methode einen String übergeben können und dieser sortiert zurück kommt. Entsprechend passen wir den Test an:

        [TestMethod()]
        public void SortTest()
        {
            QuickSortAlgorithm target = new QuickSortAlgorithm();
            string toSort = "bda";
            string expected = "abd";
            string actual;
            actual = target.Sort(toSort);
            Assert.AreEqual(expected, actual);
        }

Sehr schlicht und einfach also das ganze. Gut - und nun zu Punkt 2.

Punkt 2 - Methode implementieren, dass der Test fehlschlägt

Einfach, aber wichtig - also, wir geben einen Wert zurück, der den Test dazu veranlassen müsste, fehlzuschlagen - also zum Beispiel einen Leerstring.

Nun lassen wir den Test ein erstes Mal laufen um zu schauen, ob das Erwartete auch wirklich eintrifft. Ein Weg den Test zu starten ist wiederum über das Kontextmenü der Testmethode:

Und erhält folgendes Resultat:

Wenn das Resultat hier auf "Passed" wäre, wüsste man nun, dass der Test noch fehlerhaft ist, da er offensichtlich falsche Daten also korrekt klassifizierte.

Auf die restlichen Punkte muss hier nicht genauer eingegangen werden. Nun geht es einfach noch darum, die Implementation korrekt zu machen, und weitere Testfälle zu definieren, die sicherstellen, dass der Algorithmus korrekt funktioniert.

Weitere Testfälle wären zum Beispiel:

weitere Strings die korrekt sortiert werden müssen (spezielle Daten!), erwartet korrekt sortierte Rückgaben
ein Leerstring als Übergabe, erwartet einen Leerstring als Rückgabe
null als Übergabe, erwartet eine NullReferenceException
usw.

Das Beispiel mit einigen definierten Testfällen gibt's zum Download.

Code Coverage

Die Code Coverage gibt an, wieviel Prozent der Code-Statements durch einen Test abgedeckt werden. Dieser Wert sagt zwar prinzipiell nicht sehr viel aus, man sollte die Coverage aber dennoch immer etwas im Auge behalten. Ziel sollte ein Wert jenseits der 90%-Marke sein.

Mit Visual Studio lässt sich die Code Coverage sehr einfach messen. Hierzu müssen aber zuerst die Assemblies ausgewählt werden, auf denen die Messung stattfinden soll. Das entsprechende Menu findet man hier:

Danach kann man, nachdem die Tests durchgeführt wurden, das Code Coverage-Fenster öffnen und sich die Resultate zu Gemüte führen.

In dem Fenster kann man sich dann auch gleich anzeigen lassen, welche Zeilen durch einen Test abgedeckt werden und welche nicht. So kann man seine Testfälle optimieren.

Dies zeigt nun auch, wieso Unit-Tests eben WhiteBox-Tests sein müssen. Damit die Testfälle alle Verzweigungen einer Methode berücksichtigen kann, muss der Entwickler des Testfalls wissen, wie die Methode implementiert ist.

Natürlich sagt eine CodeCoverage von 100% nicht sonderlich viel aus - es ist weder ein Qualitätsmerkmal für den Code noch für die Testfälle. Es geht dabei mehr darum, zu entdecken, ob gewisse Code-Teile nicht getestet werden.

Fazit

Unit Tests und TDD sind ein grosses und wichtiges Thema. Visual Studio ermöglicht einen komfortablen Einsatz. Seit der 2008-Version, weden Unit-Tests bereits in der Professional-Variante unterstützt. Allerdings geht es auch ohne - Tools hierfür gibt es wie Sand am Meer. Erwähnt seien hier NUnit, NCover und TestDriven.Net (kostenpflichtig).

Viel braucht es also nicht, um Test-Driven entwickeln zu können. Trotzdem stellt sich der Anfang als eher harzig heraus, da es doch eine etwas andere Denk- und Vorgehensweise erfordert. Die Vorteile überwiegen aber doch klar, und wer sich einmal daran gewöhnt hat, wird es nicht mehr missen wollen.

Und hier noch das Beispiel-Programm zum Download:
StringSort.zip (57.99 KB)

Referenzen

Literatur

Eine professionelle Entwicklungsinfrastruktur für (fast) lau (Teil 1 von 5) - Überblick

Dani — Wed, 19 Sep 2007 15:59:54 GMT

In dieser Artikelserie möchte ich aufzeigen, was man benötigt um eine (meiner Meinung nach) professionelle Entwicklungsinfrastruktur aufzusetzen. Nun, wahrscheinlich hat jeder so seine eigenen Vorstellungen davon, was unter professionell zu verstehen ist. Gut möglich auch, dass einiges was der eine als professionell auffasst, der andere als unnötig oder übetrieben erachtet. Nichtsdestotrotz gibt es wohl den einen oder anderen Stützpfeiler in der Software-Entwicklung, der sich etabliert und eine gewisse Daseinsberechtigung erarbeitet hat.

Was ist also eine professionelle Entwicklungsinfrastruktur bzw. welche Ziele sollten bei der Einrichtung einer solchen verfolgt werden?

Geht es einfach darum dem Entwickler Freude zu bereiten, ihm ein "gutes Gefühl" zu vermitteln?
Dem Projektleiter und Kunden ein Gefühl von Sicherheit zu vermitteln?
Oder einfach nur das Projekt rechtzeitig und gemäss Anforderungen abzuschliessen?

Richtig - idealerweise werden alle diese Punkte (und noch einige weitere) erreicht.
Eine gut funktionierende und unterstützende Infrastruktur ist zwar nicht die Garantie für all das, aber zumindest bietet sie einem das Werkzeug und die Hilfsmittel, diese Ziele zu erreichen.

Ich werde in diesem Artikel einen Überblick über die Komponenten aufzeigen, die aus meiner Sicht in eine Entwicklungsinfrastruktur gehören - also nicht "wäre noch nett"-Komponenten, sondern "ohne die mach ich keinen Fingerzeig"-Komponenten. Die nächsten Artikel werden dann jeweils detaillierter auf die einzelnen Komponenten eingehen. Die vorgestellten Tools habe ich dabei rein subjektiv ausgewählt. Wer bessere oder einfach andere Altnernativen bzw. Ergänzungen hat, ist angehalten diese per Kommentar mitzuteilen.

Die IDE

"An integrated development environment (IDE), also known as integrated design environment and integrated debugging environment, is a type of computer software that assists computer programmers in developing software." (Wikipedia)

Die IDE (=Integrated Development Environment) ist wohl das Tool, womit die meisten von uns am meisten Zeit verbringen. Und doch ist es für die Erreichung unserer Ziele wahrscheinlich das unkritischste von allen. Ob der Entwickler nun mit einer "echten" IDE wie VS 2005 oder einfach nur mit einem simplen Texteditor wie Notepad arbeitet, ist letztendlich seinen Angewohnheiten und Vorlieben überlassen. Für das Projektresultat ist die Wahl der IDE bzw. des Editors also insofern wichtig, dass der Entwickler mit seiner IDE quasi harmoniert und sie auch handhaben kann.

Vertreter dieser Kategorie: Visual Studio, SharpDevelop, Eclipse, IntelliJ, JBoss, etc.

In dieser Serie werde ich Visual Studio 2005 TS einsetzen.

Der Artikel zur IDE wird sich auf die Entwicklung von UnitTests mit VS 2005 beschränken.

Versionskontrolle

"Revision control (also known as version control (system) (VCS), source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models and other critical information that may be worked on by a team of people." (Wikipedia)

Die SCC ist ein absolutes Muss für jeden der auch nur halbwegs professionell Software entwickelt. Erfreulicherweise ist der Einsatz eines entsprechenden Systems auch die Regel - aber leider bestätigen natürlich auch hier die Ausnahmen selbige. Eine gute SCC bietet neben des impliziten BackUps der lokalen Kopie, vorallem auch den Vorteil der Versionierung. Weiter sollte es möglich sein, Source Code auf verschiedenen Zweigen (= Branches) voranzutreiben bzw. Tags oder Labels vom Code zu erstellen. Was das genau ist und wie man damit umgeht, wird in Teil 3 dieser Serie besprochen.

SCC-Systeme werden meist mit Diff- und Merging-Tools ergänzt, da dies natürlich Funktionalitäten sind, die sich bei der täglichen Arbeit mit einer SCC notwendigerweise ergeben.

Die Wahl der SCC ist auch hier eher unbedeutend und sollte halt einfach die jeweiligen Bedürfnisse und Vorlieben abdecken.

Auch hier, einige Vertreter dieser Kategorie: CVS, Subversion, Visual SourceSafe, Sourcegear Vault

In der Serie wird Subversion eingesetzt.

Build-Script

Build automation is the act of scripting or automating the process of compiling computer source code into binary code. This automated build is in contrast to a manual build process where a person has to perform multiple, often tedious and error prone tasks. (Wikipedia)

Ein Build-Script ist keine eigentliche Software-Komponente, sondern halt nur ein Script. Was das Script dann schlussendlich tun soll, ist abhängig von den Wünschen und Anforderungen der Projektteilnehmer. Was es aber grundsätzlich natürlich immer kann bzw. können sollte, ist das schlichte kompilieren des Codes. Als erweiterte Möglichkeiten wären zum Beispiel folgende Punkte denkbar:

Erstellung der Datenbank
IIS Automatisierung (virt. Directories erstellen, Konfigurationen vornehmen etc.)
Umgebungsabhängige Konfigurations-Dateien erstellen (Stichwort: ConnectionString)
Automatisierte Test-Durchführung (z.B. UnitTests)
SCC-Operationen
und und und...

Seit .NET 2.0 haben .NET Entwickler die grosse Erleichterung, dass jedes Solution- bzw. Projektfile von Visual Studio 2005 selbst bereits ein MSBuild-Skript darstellt, welches zumindest mal die Solution oder das Projekt durch einen simplen Kommandozeilen-Aufruf von "msbuild mysolution.sln" kompilieren kann. Damit ist bereits die wichtigste Funktion eines BuildScripts abgedeckt, mit der auch schon einiges erreicht werden kann (z.B. automatische Kompilierung über Scheduled Tasks).

Vertreter dieser Kategorie sind zum Beispiel das eben genannte MSBuild, (n)ant oder auch die klassischen make-Files.

In dieser Serie werden wir auf MSBuild setzen.

Build-Server / Continuous Integration Server

"Continuous integration is the name that emerged in the Extreme Programming community for the software engineering practice of immediately committing every change, no matter how small, to a revision control system. Other developers should always work with the latest version of the codebase." (Wikipedia)

Build-Server im eigentlichen Sinne sind eigentlich heutzutage recht out.In aller Munde hingegen ist Continuous Integration oder kurz CI. Wo genau die Unterschiede sind, wird im entsprechenden Artikel behandelt - wobei der Schwerpunkt klar auf CI-Servern gelegt wird.

Vertreter dieser Kategorie sind Cruise Control (.NET), Team Foundation Server, TeamCity, Bamboo

Wir werden uns mit Cruise Control .NET beschäftigen.

Dies war mal so ein kleiner Überblick über die Themen dieser Serie. Jeder der folgenden Artikel wird dann ein einzelnes dieser Themengebiete genauer beleuchten.

Um nochmals auf die eingangs erwähnten Fragestellungen zurückzukommen:

Geht es einfach darum dem Entwickler Freude zu bereiten, ihm ein "gutes Gefühl" zu vermitteln?
Der Entwickler wird automatisch ein gutes Gefühl erhalten. Automatisch ausgeführte Builds, Tests etc. werden ihm stets das Gefühl verleihen, dass das Programm auf gutem Weg ist. Allein schon die morgendliche Nachricht, dass der Nightlybuild ohne Fehler durchgelaufen ist, wirkt hier Wunder. Im Artikel über CI werden wir aber noch einiges weiter gehen (Nightlybuilds != CI)
Dem Projektleiter und Kunden ein Gefühl von Sicherheit zu vermitteln?
Durch den Einsatz von CI können wir ein stets lauffähiges System vorweisen (das heisst nicht das alle Funktionen bereits vollständig implementiert sind etc.). Es gibt doch nichts Schlimmeres, als wenn der Kunde etwas sehen möchte und der Entwickler ihn mit lauter kryptischen (aber im Entwicklungsprozess) normalen Fehlermeldungen konfrontiert.
Oder einfach nur das Projekt rechtzeitig und gemäss Anforderungen abzuschliessen?
Hierfür brauchts natürlich noch einiges mehr, als eine gute Infrastruktur - aber ein erster Schritt ist damit getan.

Alle verwendeten Komponenten bis auf Visual Studio sind frei erhältlich, der Kostenpunkt sollte also zumindest was die Lizenzkosten anbelangt keinen Grund darstellen, auf diese wichtigen Komponenten zu verzichten - wie es mit dem Aufwand aussieht, werden die nächsten Artikel zeigen.

Geschafft die zweite

Dani — Wed, 19 Sep 2007 15:59:43 GMT

Ist zwar mittlerweile auch schon wieder ein paar Wochen her, aber es sei trotzdem erwähnt: Auch das zweite und letzte Vordiplom sitzt nun fest in meiner Tasche! Neben dem neu errungenen Zettel hat das vorallem auch die Konsequenz, dass das Grundstudium nun abgeschlossen ist, Adieu Mathe, Physik & Co. Dafür darf ich mich jetzt im ersten Semester des Fachstudiums mit folgendem befassen:

Systemsoftware (Systemnahe Entwicklung mit C, insbesondere Multithreading-Applikationen mit Pthreads)
Datenbanksysteme
Data Mining
Paralleles Rechnen

Vielleicht findet ja das eine oder andere Thema auch noch in dieses Blog.

Regionerate

Dani — Wed, 27 Jun 2007 17:00:45 GMT

Regionerate ist ein interessantes kleines Tool mit dem man C#-Code per Mausklick nach einem definierten Template umformatieren kann (zB. Fields, Properties, Methoden etc. in Regions trennen). So kann man sicherstellen, dass der Code immer gleich formatiert ist.

Dieser Screencast gibt einen guten Einblick in die Funktionen des Tools.

Das ganze funktioniert in VS 2005, Orcas und SharpDevelop.