-
ACHTUNG - NEUES BLOG
Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
|
Verhalten einer Anwendung per Konfiguration bzw. Laufzeit verändern
27.02.08 - Entwicklung, Diskussionen, Patterns, .NET, Grundlagen Beitrag von Norbert Eder| | Abgrenzung
In diesem Artikel wird folgendes gezeigt:
- Austauschen von Verhaltensweisen via Konfiguration als auch zur Laufzeit
- Austauschen von einzelnen Methoden via Konfiguration als auch zur Laufzeit
Einführung
In vielen Fällen ist es notwendig, Verhaltensweisen über die Konfiguration oder per Laufzeit zu steuern. Als Beispiel: Nehmen wir eine Anwendung, die unterschiedliche Listen zur Verfügung stellt. Nun müssen die Daten für diese Listen geladen werden, damit sie angezeigt werden können. Unter der Annahme, dass alle Daten aus einer Datenbank kommen ist es kaum notwendig, dieses Verhalten zu verändern. Nun kann es aber sein, dass Inhalte für bestimmte Listen nicht aus der Datenbank kommen, sondern aus anderen Quellen. Das Standardverhalten würde nun nicht mehr funktionieren und muss daher ausgetauscht werden.
Ein weiterer häufig auftretender Punkt ist, dass zwar grundsätzlich das Standardverhalten verwendet werden soll, bis auf einen kleinen Teil, beispielsweise eine bestimmte Methode.
Strategy Pattern hilft bei Verhaltensänderungen
Da Verhaltensweisen getauscht werden können, liegt es nahe, sich im Bereich der Behavioral Patterns umzusehen. Darunter ist das Strategy-Pattern zu finden. Dieses ermöglicht, das gesamte Verhalten auszutauschen. Hier eine UML-Übersicht dieses Patterns:
Im Diagramm ist der Aufbau einfach zu erkennen. Grundsätzlich wird ein Interface IStrategy zur Verfügung gestellt. Dieses schreibt die Methode DoWork vor, welche dann die tatsächliche Aufgabe ausführt. Dieses Interface wird von zwei konkreten Klassen implementiert: ConcreteStrategy1 und ConcreteStrategy2. Beide Klassen besitzen also die Methode DoWork. Allerdings unterscheiden sich diese beiden Implementierungen voneinander, sprich das Verhalten ist ein unterschiedliches (sonst würde auch die Erstellung von zwei konkreten Klassen wenig sinnvoll sein). Schließlich gibt es noch einen StrategyContext. Dieser bekommt über den Konstruktor ein IStrategy übergeben. Dieses bestimmt nun das Verhalten. Die Aufrufe erfolgen über den StrategyContext, wodurch die Funktionalität aus dem übergebenen Strategy-Objekt aufgerufen wird. Eine Beispiel-Implementierung sieht so aus:
public interface IStrategy
{
void DoWork();
}
public class ConcreteStrategy1 : IStrategy
{
#region IStrategy Members
public void DoWork()
{
Console.WriteLine("ConcreteStrategy1");
}
#endregion
}
public class ConcreteStrategy2 : IStrategy
{
#region IStrategy Members
public void DoWork()
{
Console.WriteLine("ConcreteStrategy2");
}
#endregion
}
public class StrategyContext
{
private IStrategy _strategy;
public StrategyContext(IStrategy strategy)
{
_strategy = strategy;
}
public void DoWork()
{
_strategy.DoWork();
}
}
Der Aufruf des Konstruktes geschieht folgendermaßen:
class Program
{
static void Main(string[] args)
{
StrategyContext context = new StrategyContext(new ConcreteStrategy1());
context.DoWork();
}
}
Austausch von einzelnen Methoden
Bisher haben wir gesehen, wie gesamte Verhaltensweisen ausgetauscht werden können. Wie sieht es jedoch aus, wenn nur einzelne Methoden getauscht werden und das restliche Verhalten gleich bleiben soll? Hier bietet sich ein Structural Pattern an, das Proxy Pattern. Dieses Pattern beschreibt einen möglichen Weg, wie Aufrufe an ein Ziel weitergeleitet werden können. Dies ist genau das was wir benötigen. Zuerst jedoch das UML Diagramm, um einen ersten Überblick zu erlagen:
Wie zu sehen ist, wird der StrategyContext gegen einen Proxy ersetzt. Dieser erhielt zusätzlich zur eigentlichen DoWork-Methode eine weitere Überladung, dem ein ICommand übergeben werden kann. Damit kann entweder das Standardverhalten (welches durch die konkrete Strategy-Implementierung vorgegeben wird) oder aber ein beliebiges eigenes Verhalten ausgeführt werden. Dies wirft natürlich die Frage auf, warum man nicht trotzdem ausschließlich mit dem Strategy-Pattern arbeiten kann. Der Einfachheit wegen hat dieses Beispiel nur eine einzige Methode, diese Variante kommt jedoch erst bei mehreren angebotenen Methoden zu tragen.
Hier eine Beispielimplementierung (IStrategy und die konkreten Implementierungen haben sich nicht geändert und sind im obigen Sourcecode zu finden):
public interface ICommand
{
void Execute();
}
public class CustomWorker1 : ICommand
{
#region ICommand Members
public void Execute()
{
Console.WriteLine("CustomWorker1");
}
#endregion
}
public class CustomWorker2 : ICommand
{
#region ICommand Members
public void Execute()
{
Console.WriteLine("CustomWorker2");
}
#endregion
}
public class StrategyProxy
{
private IStrategy _usedStrategy;
public StrategyProxy(IStrategy usedStrategy)
{
_usedStrategy = usedStrategy;
}
public void DoWork()
{
_usedStrategy.DoWork();
}
public void DoWork(ICommand customWorker)
{
customWorker.Execute();
}
}
Fazit
Dieser Beitrag hat gezeigt, wie gesamte Verhalten innerhalb einer Anwendung einfach ausgetauscht werden können bzw. einen Weg aufgezeigt, wie dies auf Basis von Methoden realisiert werden kann. Wer dies nun über eine Konfigurationsdatei konfigurieren möchte, der kann sich beispielsweise einen Builder basteln, welcher die Konfiguration ausliest und die darin angegebenen Typen mit Hilfe der Klasse Activator instanziert, den Proxy mit den notwendigen Instanzen füllt und ihn anschließend fertig konfiguriert zurück liefert.
| | | 4 Kommentare
- 1785 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Das schwierige Los eines Entwicklers
23.02.08 - Entwicklung, Diskussionen Beitrag von Norbert Eder| | Jeder Softwareentwickler muss mal klein beginnen. Viele Fragen tun sich auf und oft ist es schwierig, den richtigen Startpunkt zu finden. Wer bereits seit Jahren erfolgreich Software entwickelt, um die Fallen weiß, Patterns kennt und sich auf die Erfahrung verlassen kann, verliert oft die Anfangsschwierigkeiten aus den Augen, mit denen ein „Neuling“ konfrontiert wird.
Durch meine Lektorentätigkeit wurde ich vor allem in den letzten Tagen wieder darauf aufmerksam gemacht, worin tatsächlich die Probleme liegen bzw. sehr wahrscheinlich. Paradigmen wie die objektorientierte Programmierung sehe ich hier gar nicht so als tragisch an. Vielmehr stellen die wirklich zahlreich verfügbaren Möglichkeiten Einsteiger vor ein Problem. Wie vor 10, 15 Jahren stehen auch heute noch Programmiersprachen im Vordergrund, obwohl sie eigentlich nur ein Werkzeug zur Verfügung stellen. Hinter diesen Werkzeugen lauern zahlreiche Techniken/Frameworks, die verwendet werden wollen. Egal, in welche Ecke man guckt, alles und jeder verspricht, dass es damit noch viel viel einfacher geht. Um welchen Preis? Genau, man muss schon teilweise recht hart arbeiten, um am Laufenden zu bleiben. Ganz davon zu schweigen, dass man auch wirklich alles kennen und können kann. Nicht bei dieser Vielfältigkeit. Dass dabei Einsteiger den Überblick verlieren und den Wald vor lauter Bäumen nicht mehr sehen kann nicht verwundern.
Früher hat es gereicht, die CPU mitsamt der ALU und allem was sonst noch so dazu gehört zu kennen und ein paar Register (es mussten nur die richtigen sein) zu schupfen und schon konnte man sein Ergebnis (das was davor lag, lasse ich nun einfach einmal weg). Die Programmiersprache als solches war also auf ein Minimum ausgelegt und konnte so auch einfach benutzt werden. Heute hat ein Neuling schon viel zu tun, um überhaupt alle Möglichkeiten der Sprache zu lernen, mal abgesehen vom dahinterliegenden Framework bzw. den sonstigen verfügbaren Bibliotheken. Hier wundere ich mich ja selbst, wie man das denn selber alles immer irgendwie unter einen Hut bekommt.
Zusätzlich zur Thematik Programmiersprache/Framework kommt noch hinzu, dass ein heutiger Entwickler keineswegs mehr im dunklen Kämmerlein sitzt, sondern durchaus auch soziale Kompetenz mitbringen muss. Der Kunde möchte gut aufgehoben sein und dazu ist Kontakt einfach notwendig (verständlicherweise). Was genau resultiert daraus? Genau! Es bleibt nicht bei der Forderung nach sozialer Kompetenz, sondern der Softwareentwickler sollte sich grundsätzlich in sämtlich angesprochenen Bereichen auskennen. Dies können diverse Prozesse im Unternehmen des Kunden sein, das kann die Branche betreffen, in der sich der Kunde bewegt, betrifft jedoch auch die speziellen Technologie-Wünsche. Nicht oft kommt es vor, dass ein bestimmtes DBMS verwendet werden muss, der Datenaustausch zwischen Client und Server muss via XML passieren und schließlich möchte der Kunde auch noch die Oberfläche selbst anpassen können, wo wir dann wieder bei unterschiedlichsten Bereichen angekommen wären: Für Web hätten wir dann beispielsweise CSS, oder XAML für WPF Windows Anwendungen. Reporting darf auch nicht fehlen, wodurch dann Kenntnisse in XSLT recht hilfreich sind und schlussendlich sollen bestimmte Dokumente als XPS geschrieben werden. Dieses Spielchen könnte man nun schon ziemlich lange spielen.
Jetzt ist die IT Branche aber durchaus noch als eine junge Branche anzusehen, dennoch muss man feststellen, dass sie wohl vielseitiger kaum sein könnte. Rechnen wir noch mal 10 Jahre hinzu, dann möchte ich gar nicht wissen, welche neuen Techniken und Technologien bis dahin zusätzlich Einzug gehalten haben und über welche der heutigen man noch durchaus Know-How mitbringen muss. Ich denke … es wird nicht einfacher für uns und auch nicht für diejenigen, die in diese Branche einsteigen möchten …
| | | 5 Kommentare
- 1139 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Über die Wichtigkeit der Windows Presentation Foundation
07.02.08 - Entwicklung, Diskussionen, .NET, WPF Beitrag von Norbert Eder| | Im ersten Teil meiner WPF-Serie hatte ich bereits über WPF aus Sicht eines Unternehmens geschrieben. Mittlerweile ist etwas Zeit vergangen und viele Diskussionen zu diesem Thema wurden gefochten. Hier ein Zwischen-Konklusio zu diesem Thema.
Vermeintliche Argumente gegen WPF
Wohl niemand (der sich mit der WPF auseinander gesetzt hat) streitet ab, dass die Windows Presentation Foundation eine geile Sache ist. Jedoch kaum jemand setzt wirklich ernsthafte Projekte auf Basis der WPF um (zumindest nicht in meinem Umfeld). Auch im Internet nehmen lediglich Komponenten-Hersteller „WPF“ in ihr Programm auf. Standardsoftware und/oder Tools werden kaum in Form von WPF-Anwendungen angeboten.
Ausrede No. 1: Größe des .NET Frameworks
Die von mir meist gehörte „Ausrede“ hatte mit der Download-Größe des .NET Frameworks (Version 3.5) zu tun. Dem kann ich mich absolut nicht anschließen. Man nehme als Beispiel Java. Hier gibt es eindeutig weniger Berührungsängste, obwohl es sich hierbei grundsätzlich um das gleiche System handelt. Weiters sehe ich täglich, welche Datenmengen über die Leitungen flutschen, da fallen die paar Megabytes durchaus nicht ins Gewicht. Für mich ist dies definitiv kein Argument.
Ausrede No.2: Kunde will nicht
In Newsgroups, aber auch persönlichen Gesprächen musste ich feststellen, dass Kunden keine Anwendungen auf Basis WPF haben möchten. Auch dies halte ich durchaus für ein Gerücht. Natürlich gibt es Unternehmen, die spezielle Prozesse implementierten, wonach die Einführung eines gänzlich neuen .NET Frameworks einen Evaluierungsprozess durchlaufen muss. In kleinen Unternehmen ist dies zu 99% jedoch nicht der Fall. Vielmehr ist ihnen – aus meiner Erfahrung – meist völlig egal, womit die Anwendungen umgesetzt wurden, Hauptsache, sie funktionieren und das möglichst fehlerfrei. Ergo kann auch dieses Argument nicht komplett als solches gewertet werden.
Ausrede No.3: Fehlendes Know-How
Dies ist wohl das einzige Argument (von den von mir aufgezählten), welches ich gelten lasse. Natürlich bekommt nicht jeder Entwickler sofort sämtliches WPF-Know-How geimpft. Es müssen schon Erfahrungen gesammelt werden – und das nicht wenige. Tatsache ist, dass es im Vergleich zu Windows Forms einige Unterschiede konzeptioneller Natur gibt und diese berücksichtigt werden müssen. Die Entscheidung, ein Projekt mittels WPF umzusetzen ohne mit jeglichem Wissen aufwarten zu können ist mehr als gefährlich und sollte keinem Kunden zugemutet werden. Schließlich kann auf diese Art und Weise kein einziger Projektplan eingehalten werden. Dennoch muss man einmal ins kalte Wasser springen und den Schritt wagen.
Windows Forms als WPF-Killer
In den meisten Fällen – wir sprechen hier von reiner Windows-Client-Entwicklung – wird auf die guten alten Windows Forms zurück gegriffen. Diese gibt es seit der Einführung des .NET Frameworks, hier ist Know-How vorhanden, es wurden eigene Steuerelemente entwickelt und man weiß einfach, wie im Falle des Falles zu reagieren ist. Daraus resultiert, dass viele Unternehmen weiterhin zu Windows Forms greifen, WPF als interessant einstufen, aber eben nicht verwenden.
Community als Anlaufpunkt
Zu Windows Forms gibt es zahlreiche Ressourcen. Nicht nur englische Homepages beschäftigen sich damit, auch im deutschsprachigen Umfeld ist einiges an Know-How zu finden. Bezüglich WPF sieht dies etwas anders aus. Hier ist man großteils gezwungen, auf die englische Sprache zu setzen. Kann zwar fast jeder, dennoch liest es sich auf Deutsch einfach besser. Im deutschsprachigen Raum finden sich diesbezüglich kaum Personen, die den Spirit von WPF weitertragen – warum auch immer es so ist. Vermutlich liegt es daran, dass wir Mitteleuropäer um ein Vielfaches kontrollierter sind als andere und der Enthusiasmus sich daher in Grenzen hält.
Fehlende Umsetzungen
Viele Firmen, die kein Interesse haben, als Technologieführer aufzuscheinen warten auf andere Unternehmen, die mit entsprechenden Produkten dem Markt die Richtung vorgeben. Genau diese Produkte fehlen meiner Meinung nach. Wie bereits angesprochen gibt es kaum Anwendungen die auf WPF basieren und daher anderen Unternehmen zeigen, dass eine Umsetzung möglich ist, dass derartige Anwendungen von Kunden akzeptiert werden und dass dafür durchaus Potential vorhanden ist.
Hemmungen ablegen
Einer der wohl wichtigsten Punkte eines Entwicklers ist Neugierde. Diese gewährleistet stete Weiterentwicklung. Leider verharren sehr viele Entwickler in dem, was ihnen bekannt ist und sind daher wenig risikofreudig. Dies ist der falsche Weg, wie ich finde. In vielen Unternehmen ist es leider so, dass Entwickler nicht die Möglichkeit haben, sich mit neuen Technologien zu beschäftigen, Prototypen zu bauen, in Büchern/Zeitschriften/Online zu schmökern. Hier gibt es zwei mögliche Wege: Entweder setzt man dies durch (denn schließlich kommt zusätzliches Wissen auch dem Unternehmen zu Gute) oder man erlernt Neues in der Freizeit (was meist der schwierigere Weg ist).
Unterstützung nötig?
In meinem konkreten Fall kann ich sagen, dass ich mich schon seit Mitte 2006 mit WPF beschäftige und bereits mehrere Anwendungen erfolgreich auf Basis der WPF umgesetzt habe. Mittlerweile gibt es wohl kaum eine Anforderung, bei der mit größeren Problemen zu rechnen ist. Natürlich hat es seine Zeit gebraucht, viel Code wurde umsonst geschrieben, aber alle Projekte konnten in Zeit umgesetzt werden und laufen nun im Echtbetrieb. Anfangs war natürlich Skepsis vorhanden, doch konnte dies meisten aus dem Weg geräumt werden.
Da ich immer wieder Anfragen in diese Richtung bekomme und Bedenken behandelt werden müssen, biete ich auf diesem Wege öffentlich meine Hilfe an. Schließlich stehe ich für technologischen Vorsprung und unterstütze gerne. Bei Fragen kann man sich einfach via Kontaktformular an mich wenden. Hilfe ist asap unterwegs.
Fazit
Aktuell schätze ich die Windows Presentation Foundation eher noch als unwichtig ein, da sich viele – mangels vorhandenem Know-How – einfach nicht getrauen, diese Technik/Technologie einzusetzen. Ich denke aber auch, dass in ein paar Monaten/Jahren kaum ein Weg daran vorbei führen wird – man denke hierbei unter anderem an Silverlight, auch kein unwesentlicher Faktor.
| | | 8 Kommentare
- 2343 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Aufwandsschätzungen verbessern
04.02.08 - Entwicklung, Diskussionen, Qualitätsmgmt. Beitrag von Norbert Eder| | Aufwandsschätzungen gehören quasi zur täglichen Arbeit eines Softwareentwicklers – zumindest sollte es das. Gerade für den Projektmanager ist es nicht unerheblich, über den zu planenden Aufwand Bescheid zu wissen, als auch feststellen zu können, wie der derzeitige Stand ist. Daher müssen Aufwände für erfasst werden für:
- das gesamte Projekt
- daraus resultierende Komponenten
- daraus resultierende einzelne Tasks
Kontrolle der Aufwände
Einer der wichtigsten Aspekte daran ist es, dass die ursprünglich abgegebenen Schätzungen ständig neu betrachtet und gegebenenfalls aktualisiert werden. In vielen Unternehmen unterbleibt dieser Schritt, wodurch das Projektmanagement oft keine aktuellen Zahlen zur Verfügung hat und Verzögerungen nicht sofort erkannt werden.
Aber auch der Entwickler selbst kann von der Überarbeitung der Aufwandsschätzungen profitieren. Zumindest sollten die ursprünglich geschätzten Aufwände mit dem tatsächlichen Aufwand verglichen werden. Dadurch werden Verzögerungen festgehalten und stellen einen wichtigen Ansatzpunkt zur Analyse dar. Unter anderem können dadurch folgende Fragen beantwortet werden:
- Bei welchen Aufgaben wurden die ursprünglichen Schätzungen überschritten?
- Betrifft dies ähnliche Aufgaben bzw. die Arbeit mit speziellen Techniken/Technologien?
- Welche Probleme sind dafür verantwortlich?
Auf Basis der Antworten zu diesen Fragen können Schritte eingeleitet werden, um die Aufwandsschätzungen beim nächsten Mal zu verfeinern bzw. um grundlegende Probleme aufzuarbeiten. Dies hilft nicht nur dem gesamten Projekt, sondern jeder einzelne Entwickler bekommt ein immer besseres Gefühl für die zu schätzenden Aufgaben und schließlich können dadurch eigene Schwachpunkte gefunden und bekämpft werden. Es resultiert also eine Verbesserungsliste der eigenen Fähigkeiten. Ganz gut, wenn man bedenkt, dass damit die Qualität der eigenen Arbeit wesentlich verbessert werden kann.
Gegenüberstellung
Welche Daten sollten nun gegenüber gestellt werden? Ich kann hier hauptsächlich aus meiner persönlichen Erfahrung sprechen und wiedergeben, welche Daten von mir ausgewertet werden:
- Ticket (aus Ticketing-System)
- Ursprüngliche Schätzung
- Gesamter Aufwand
- Abweichung in Stunden
- Abweichung in Prozent
- Bei Problemen eine entsprechende Angabe darüber
Diese Liste kann in entsprechenden Tools (beispielsweise Excel) gut erstellt und gewartet werden. Ebenfalls lassen sich entsprechende Diagramme anfertigen, die anhand des Verlaufs über zahlreiche Aufgaben hinweg eine Tendenz anzeigen und somit auch erkennen lassen, ob Reaktionen auf etwaige Verzögerungen tatsächlichen Einfluss ausüben.
Fazit
Aufwandsschätzungen müssen gemacht werden und in vielen Fällen passiert dies auch durch den tatsächlichen Entwickler. Damit dieser nun an seinen Fähigkeiten arbeiten kann empfiehlt es sich, die eigenen Angaben und Leistungen auch ständig zu messen und zu bewerten. Mit einfachen Mitteln können hier sehr gute Ergebnisse erzielt werden.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Über den Tellerrand geblickt: foreach in C# und Java
23.11.07 - Entwicklung, Diskussionen, .NET, Grundlagen Beitrag von Norbert Eder| | Aktuell bin ich (wie unschwer zu erkennen ist) mit WPF beschäftigt, aber auch Java hat sich wieder ein wenig breiter in meinem Leben gemacht. Und obwohl Java jetzt nicht unbedingt zu meinen Lieblingen zählt, gibt es dennoch Dinge, die (aus meinem Blickwinkel) schöner gelöst sind. Ein schönes Beispiel hierzu wäre foreach.
In .NET sieht das ja so aus:
foreach (String s in myStringList)
{
}
In Java deutet zwar nichts auf ein foreach hin, nennt sich aber dennoch so und sieht wie folgt aus:
for (String s : myStringList)
{
}
Geht doch irgendwie leichter von der Hand, nicht?
| | | 10 Kommentare
- 916 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Code-Dokumentation einfach gemacht!
14.11.07 - Entwicklung, Diskussionen, Qualitätsmgmt., .NET, Grundlagen, Visual Studio, Allerlei, Tools, 3rd Party Tools Beitrag von Norbert Eder| | Die Dokumentation des Sourcecodes ist ein wichtiger - aber leider oft vernachlässigter - Bestandteil der Softwareentwickler. Vor allem Frameworks wollen gut dokumentiert werden, damit ein beliebiger Entwickler sofort damit loslegen kann, ohne sich lange einarbeiten zu müssen.
Nun ist es so, dass Visual Studio hier nicht besonders viel mitbringt. Lediglich das Schreiben der Kommentare in XML-Files, die später via IntelliSense eingebunden werden. Ein Tool zur Generierung von Hilfe-Dateien wird nicht über die IDE zur Verfügung gestellt. Aber es gibt auch andere Lösungen.
Benötigte Tools/Frameworks
Bevor mit der Generierung der Sourcecode-Dokumentation gestartet werden kann, müssen einige Frameworks/Tools installiert werden. Zentraler Bestandteil für diese Variante ist Sandcastle. Hier nun eine Liste der zu installierenden Produkte:
Hinweise: Der HTML Help Workshop ist nur für die Generierung von HTML 2.x Dokumentationen notwendig und muss nur installiert werden, wenn sich dieser noch nicht auf dem Rechner befindet.
Installation
Die ersten beiden Produkte kommen jeweils als MSI-Pakete daher. Daher sind diese sehr einfach in der Installation. Der HTML Workshop kann normal herunter geladen werden und muss nur in der Projekt-Konfiguration im Sandcastle Help File Builder in der Eigenschaft HtmlHelp2xCompilerPath angegeben werden. Nun noch GhostDoc installieren und schon ist man fast fertig.
Vorarbeiten
Wichtig ist, dass beim Build-Prozess XML-Kommentare ebenfalls generiert werden. Dazu ist die Einstellung in den Eigenschaften der jeweiligen Assemblies unter dem Punkt Build zu setzen.
Nun müssen natürlich auch noch sämtliche Kommentare geschrieben werden. Um sich viel Arbeit zu ersparen kann nun GhostDoc eingesetzt werden. Dieses unterstützt bei der Generierung der Dokumentation und liefert auch Vorschläge, die in einigen Fällen noch weiter angepasst werden müssen, aber grundsätzlich ist damit eine solide Basis geschaffen.
Generierung der Dokumentation
Mit Hilfe der Sandcastle Help File Builder GUI kann nun auf einfache Art und Weise ein Dokumentations-Projekt angelegt werden. Hierzu sind die notwendigen Assemblies anzugeben. Die vorhandenen XML-Dateien werden automatisch hinzugeladen und müssen daher nicht extra angegeben werden.
Wurden nun beispielsweise Frameworks á la NUnit, NLog etc. verwendet wird der Builder beim Ausführen beanstanden, dass referenzierte Assemblies nicht gefunden werden können. Anstatt diese über Add hinzuzufügen, empfiehlt es sich, diese im Builder unter Dependencies einzupflegen.
Nun müssen noch Einstellungen getroffen werden, welche Templates für Generierung verwendet werden, ob 1.x, 2.x generiert werden soll, oder gar eine Website und viele weitere Einstellungen wie Überschriften usw.
Ein wichtiger Punkt ist unter Namespaces zu finden: Hier ist es möglich einzustellen, welche Namespaces in der Dokumentation aufscheinen und es kann zusätzlich eine Beschreibung für diese eingegeben werden.
Wurde alles konfiguriert, kann die Generierung gestartet werden. Diese dauert zwar ein wenig länger als man erwartet, dafür ist das Ergebnis (vorausgesetzt es wurde brav dokumentiert) sehr fein und kann für die Weitergabe oder interne Verwendung herangezogen werden.
Fazit
Mit Hilfe dieser wenigen Tools und ca. 10 - 15 Minuten Installation und Konfiguration kann ein komplettes Dokumentations-System aufgesetzt werden. Die Dokumentation selbst kann uns leider niemand abnehmen, aber das soll keine Ausrede sein. Ich persönlich setze obige Kombination schon länger ein und bin bis dato sehr zufrieden.
Sicherlich wird es Möglichkeiten geben, dies weiter zu verbessern, wer hier also eine andere Konfiguration einsetzt bzw. Vorteile für seine Lösung anbieten kann, der sei hiermit eingeladen, mir dies mitzuteilen. Ebenfalls würde mich interessieren, ob ihr Code-Dokumentationen schreibt, oder nicht, inklusive einer kurzen Begründung.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Microsoft, Windows und Aktivierung
27.10.07 - Blog-Intern, Entwicklung, Diskussionen, Kunterbunt Beitrag von Norbert Eder| | Ich habe ja kürzlich mit dem Gedanken gespielt, von Virtual PC 2007 auf VMWare umzusteigen. Im Zuge dessen hatte ich ein vorhandenes Image konvertiert. Das Ergebnis (eigentlich logisch, aber dennoch nicht daran gedacht): die zugrundeliegende Hardware hat sich natürlich geändert. Windows ist da natürlich gleich angesprungen und fordert eine Neuaktivierung. Ok. Online-Aktivierung probiert: fehlgeschlagen. Weiß der Geier warum.
Gut. Dann hatte ich mir folgendes überlegt: Ich hatte mir ja gleich nachdem es erhältlich war Vista Ultimate gekauft und auf einem meiner Laptops installiert. Um Tests etc. durchzuführen und ein wenig unter Vista zu entwickeln. Irgendwann habe ich dort Vista platt gemacht und XP draugespielt. Nun, denke ich mir, ich werde Vista einfach als virtuelle Maschine laufen lassen. Sehr fein, müsste ja alles funktionieren: Unter Virtual PC 2007 installieren, Konverter drüber lassen und unter VMWare Player laufen lassen (denn 189$ für die VMWare Workstation erscheinen mir etwas viel).
Gut, alles installiert, konvertiert. Natürlich möchte jetzt auch Vista aktiviert werden. Ja, kein Problem, denke ich mir. Ergebnis?
Ihr Windows Vista wurde bereits aktiviert ... .... ... neuen Produktkey eingeben? ... telefonisch ....
.... AUSZUCK????
Als Käufer von Windows Vista (und das gilt auch für die anderen Windows Versionen die neu aktiviert werden müssen, wenn sich Hardware ändert) frage ich mich schon wozu das notwendig ist? Das ist doch fast so ähnlich wie bei den DVDs: DVD gekauft und dann darf man sich 10 Minuten diese bescheuerte Anti-Raubkopierer-Werbung ansehen. Aber zumindest kann man die DVD dann überhaupt noch gucken. Windows will ja wegen jeden Furz aktiviert werden.
Gerade als Entwickler kommt es eben mal vor, dass man oft seine Betriebssysteme wechselt, die Systeme auf unterschiedlichen Rechnern austauscht, einmal Vista da, dann doch wieder XP drauf und wo anders Vista usw. Wenn man jetzt jedes Mal bei Microsoft (oder das entsprechende Call-Center) anrufen muss, dann ist das SEHR ärgerlich, zumal man dann jedes Mal groß gefragt wird, was denn da jetzt genau gemacht wurde und wie das aussieht und bla bla bla.
Und ja, mir ist schon klar, dass dieses Problem Microsoft-Intern eher nicht auftritt. Denn ich hab ja keine Corporate-Edition ....
... in diesem Sinne: Jetzt ruf ich bei euch an, Microsoft und wehe mein Vista läuft nicht gleich wieder .... *grml*
| | | 2 Kommentare
- 935 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Die Krise mit Virtual PC 2007
25.10.07 - Entwicklung, Diskussionen Beitrag von Norbert Eder| | Eigentlich hatte ich virtuelle Rechner bis dato eher nur zu Testzwecken (Softwaretests, Plattformtests etc.). Stundenlanges Entwickeln kam für mich dann doch weniger in Frage. Aus unterschiedlichen Gründen (massenweise RAM, sauberes Hostsystem, etc.) habe ich mich dann doch entschlossen ein paar unterschiedliche Systeme einzurichten, vor allem auch, da ich aktuelle Projekte bereits mit Visual Studio 2008 umsetze.
Meine virtuellen Rechner laufen alle unter Virtual PC 2007, was grundsätzlich für Testzwecke bis dato (früher eben noch die Vorgängerversion) ausreichend war. Nach stundenlanger Entwicklungszeit geht mir jedoch hauptsächlich eine bestimmte Einschränkung ziemlich auf den Wecker: die Einschränkung der Auflösung auf 1600x1200. Bei 17" WideScreen (Laptop) bzw. 22" WideScreen (Standrechner) sieht es mit den Auflösungen nun halt ganz anders aus und dann kommt auch noch der Faktor WideScreen hinzu. Grundsätzlich stehe ich dann auch nicht auf schwarze Rahmen bzw. verzerrte Darstellungen.
Nun, via Remote Desktop (ja, irgendwie wie von hinten durch die Brust in die Augen) läßt sich da auch nichts machen. Ich bilde mir zwar ein, dass dies von Vista aus (aktuell setze ich als Hostsystem noch XP ein) funktionieren sollte, ist jedoch eben auch nicht die schönste Variante.
Tja, da bliebe dann noch der Umstieg von Virtual PC auf VMWare. Stellt sich mir die Frage ob ich mir das dann wirklich antun soll. Von meinen Lesern schon jemand mal mit dem VMWare Converter drübergefahren?
| | | 2 Kommentare
- 1040 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF Teil 2: Windows Presentation Foundation oder doch lieber Windows Forms?
24.10.07 - Entwicklung, Diskussionen, .NET, WPF Beitrag von Norbert Eder| | Bisherige Teile:
WPF Teil 1: Die Windows Presentation Foundation aus der Sicht eines Unternehmens
Im ersten Teil der WPF-Serie wurde das Thema WPF und Unternehmen behandelt. Nun stellt sich aber nicht nur in Unternehmen, sondern auch in privaten Projekten die Frage: Soll ich mein Projekt mittels der Windows Presentation Foundation umsetzen oder doch lieber zu den bekannten Windows Forms greifen? Dieser Artikel versucht auf diese Fragestellung genauer einzugehen.
In vielen Artikeln wird Windows Forms immer noch WPF vorgezogen. Die Gründe hierfür sind meist dieselben:
- Funktionsweisen sind bekannt
- Einschränkungen sind bekannt
- Windows Forms Designer ist ausgereift
- Entwicklungsaufwand geringer
Grundsätzlich stimmen diese Argumente. Auf der anderen Seite ist jedoch zu beachten, welche Möglichkeiten WPF mit sich bringt. Diese sind Windows Forms auf jeden Fall überlegen. Daher ist es sinnvoll die einzelnen Bereiche genauer zu hinterfragen.
Der Vergleich
Databinding
Die meisten Anwendungen sind sehr datenlastig. D.h. es werden Daten angezeigt, verarbeitet, verwaltet und dergleichen. Um diese Daten anzuzeigen wird oft Databinding verwendet. Hier sind die Möglichkeiten unter Windows Forms jedoch begrenzt. WPF hat diesbezüglich viele Erweiterungen erfahren, wodurch hier eindeutig ein Vorteil für die neue Technologie zu sehen ist.
Trennung Design - Code
Design, also das User Interface, kann unter WPF wesentlich leichter vom Code getrennt werden. Im Gegensatz zu Windows Forms ist es daher möglich, dass das Oberflächendesign wirklich von einem Designer/Grafiker übernommen wird. Im Idealfall sollte dieser zwar WPF (XAML) KnowHow haben, mit Hilfsmitteln á la Blend ist aber auch das nicht zwangsweise notwendig.
Probleme Designer
Unter Windows Forms kommt es immer wieder zu Problemen mit eigenen UserControls. Hier wurde zumindest von mir die Erfahrung gemacht, dass es durchaus vorkommen kann, dass der WinForm-Designer die Oberfläche komplett verwüstet. Controls, welche die Location bzw. Size komplett verlieren und daher im Designer nicht mehr aufscheinen, bis hin zu fehlenden Events etc. Diese Probleme sind in weiterer Folge im Designer kaum Herr zu werden, daher muss man wohl oder übel entweder auf ein Backup zurückgreifen, oder direkt im Code Hand anlegen. Auch hier sehe ich einen klaren Vorteil für WPF: XAML ist wesentlich einfacher und schneller editiert, als haufenweise Code im InitializeComponents etc. Zudem wird der Code nicht angerührt, wenn sich Änderungen im Design ergeben (sei es durch einen Fehler im Designer, oder durch einen menschlichen Eingriff).
Unterschiedliche Medien, Skins
Egal ob es um 3D-Effekte, um animierte Übergänge zwischen Grafiken, Videos etc. geht, ist WPF klar die Wahl Nummer 1. Hier hat Windows Forms kaum etwas entgegen zu setzen. Ebenfalls sind beispielsweise Skins mittels WPF wesentlich einfacher möglich.
Und wann jetzt Windows Forms?
Natürlich hat auch Windows Forms nach wie vor seine Berechtigung. Werden die neuen, von WPF mitgebrachten, Funktionalitäten nicht benötigt, gibt es keinen Grund, auf WPF umzusteigen. Vielmehr empfiehlt es sich dann, bei Windows Forms zu bleiben. Denn auch hier gibt es unzählige Vorteile:
- Große Community mit vielen Hilfestellungen
- Viele Online-Ressourcen, Artikel, Blogbeiträge, Beispiele, ...
- zahlreiche 3rd Party Controls
Fazit
Grundsätzlich bleibt es dem Entwickler überlassen, wann welche Technologie eingesetzt wird. Die aufgezählten Punkte sollten einen kleinen Überblick liefern, in welchen Bereichen WPF die Nase vorne hat. Jedoch bleibt immer zu bedenken, welche Möglichkeiten die zu erstellende Anwendung tatsächlich nutzen soll und wird. Aufgrund dieser Entscheidung läßt sich auch sehr einfach feststellen, welche Technologie zum Einsatz kommt.
Schließlich muss noch eines angemerkt werden: WPF läßt sich auch in Windows Forms Anwendungen verwenden. Dies gilt auch in die andere Richtung:
WPF in Windows Forms verwenden
| | | 3 Kommentare
- 838 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Der Unterschied: Wissenschaftler vs Normalbürger
12.10.07 - Entwicklung, Diskussionen, Internet, Kunterbunt Beitrag von Norbert Eder Zurück Weiter
|
|
|
|
|
|
|