-
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.
|
Ü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
- 2384 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
- 919 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
- 943 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
- 1044 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
- 844 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Der Unterschied: Wissenschaftler vs Normalbürger
12.10.07 - Entwicklung, Diskussionen, Internet, Kunterbunt Beitrag von Norbert EderWPF Teil 1: Die Windows Presentation Foundation aus der Sicht eines Unternehmens
01.10.07 - Entwicklung, Diskussionen, .NET, Grundlagen, WPF Beitrag von Norbert Eder| | Wie bereits angekündigt, werde ich hier eine Umsetzungs-Serie zum Thema WPF starten. Im Zuge dieser Serie werden einige interessante Themen besprochen.
Eine Einführung zum Thema Windows Presentation Foundation werde ich an dieser Stelle nicht bieten, hierfür müssen die beiden von mir erstellen Tutorials zu diesem Thema reichen:
Windows Presentation Foundation - Teil 1: Einführung
Windows Presentation Foundation - Teil 2: XAML und Layouts
Vielmehr möchte ich hinterfragen, welchen Stellenwert WPF in Unternehmen hat und welche Überlegungen mitspielen, um auf WPF umzusteigen.
Auch heute noch - WPF gibt es nun ja schon länger - wird die Windows Presentation Foundation als neue Technologie gehandelt. Beispiele gibt es dazu ja bereits einige und durch Silverlight hat XAML sicherlich einen neuen Hype erfahren. Dennoch scheuen sich sehr viele Unternehmen diese Technologie einzusetzen. Warum ist dem so?
Hier spielen sicherlich mehrere Faktoren eine wichtige Rolle:
Nicht jedes Unternehmen ist dazu gemacht, ein Innovator bzw. ein früher Adopter zu sein (siehe Erklärung). Dies bedeutet, nicht jede Firma setzt auf neueste Technologien. Aus unterschiedlichsten Gründen: Viele vertrauen auf Bewährtes. Es bestehen wenig Risiken (damit haben sich bereits Jahre zuvor andere auseinander gesetzt), Informationen sind breit verfügbar (Foren, Blogs, Bücher) und es gibt durchaus genügend Entwickler die sich mit Bestehendem auskennen und somit im Notfall eingesetzt werden können. Bei einem Innovator sieht es hingegen anders aus: Aktuellste Technologien werden eingesetzt um der Konkurrenz gegenüber einen technologischen Vorteil zu schaffen. Informationen sind rar (SDK Dokumentation, wenn verfügbar). Know-How-Träger müssen kostenintensiv aufgebaut werden, wodurch die Produktivität anfangs sinkt und natürlich das Risiko besteht, das vorgesehene Projekt nie abzuschließen.
Eng mit dem ersten Punkt ist die Tatsache, dass Zeit geschaffen werden muss, um sich eine Technologie anzueignen. In Zeiten wie diesen - Microsoft veröffentlicht laufend neue Technologien - ist es sehr schwierig mit den aktuellen Entwicklungen Schritt zu halten und am aktuellen Stand zu bleiben. Gefordert sind hauptsächlich Entwickler, denn diese müssen dem Unternehmen bzw. dessen Führung die Vorteile der neuen Technologien schmackhaft machen (und sie selbt auch erlernen). Unternehmen, die die Möglichkeit bieten auf neue Technologien umzusteigen können daraus sicherlich Vorteile generieren. Dennoch ist der Faktor Mangelware an dieser Stelle Zeit. Zeit ist eine große Hürde die es zu überwinden gibt. Neue Technologien stellen ein große Herausforderung an das gesamte Unternehmen, vor allem an das Entwicklerteam, welches unter Zeitdruck steht und dennoch Erfolge bieten muss.
Umstiegskosten: VIele Unternehmen setzen auch heute noch Visual Studio 2003 ein. Dabei ist Visual Studio 2005 fast ein Jahr alt und die 2008er wartet bereits darauf fertig zu werden, um auf den Markt geworfen zu werden. Die Produktzyklen werden immer geringer und immer weniger machen den Schritt tatsächlich mit. Aus Kostengründen, denn Visual Studio ist nicht billig. Und WPF ist nun in der 2003er nicht verfügbar, vorhandene Projekte wollen nicht umgestellt werden, auf zwei Schienen entwickeln ist auch nicht unbedingt das Wahre usw.
Die Überwindung: Schließlich muss man sich überwinden, um tatsächlich ein Projekt auf Basis WPF durchzuziehen. Klar, wunderschön, man kann klar zwischen Designer und Entwickler trennen. Oft kann diese Trennung jedoch nicht vollzogen werden - aus Mangel an Designern. Allrounder sind also gefragt und diese müssen oft erst dazu bewogen werden. Sind Designer vorhanden, müssen diese erst Grundlagen der WPF erlenen, denn ganz ohne geht es dann auch nicht.
Wahrscheinlich ließe sich diese Liste noch fortführen. Tatsache ist, dass es viele Gründe gibt, warum Unternehmen WPF nicht sofort einsetzen, sondern auf einen günstigen Moment warten, auf das richtige Projekt, die richtigen Entwickler, oder möglicherweise gar nie diesen Schritt wagen. Fakt ist, dass dieser Schritt irgendwann vollzogen werden sollte. Die Möglichkeiten sind groß, aber eine vorhandene Anwendung wird nun eben nicht von Heute auf Morgen umgestellt - wobei auch die Sinnhaftigkeit einer Umstellung hinterfragt werden sollte. Doch auch neue Projekte werden lieber mit Windows-Forms entwickelt. Und warum? Vermutlich weil es einfach an allgemein bekannten Anwendungen fehlt, die mittels WPF entwickelt wurden. Entsprechende Patterns sind ebenfalls Mangelware (dazu kommen wir in einem anderen Teil).
Was also sollte in meinem Unternehmen passieren um auf die neue Technologie zu kommen? Diese Frage ist immer schwer zu beantworten. Grundsätzlich sollte durch Visual Studio 2005 (bald 2008) die Grundlage gelegt werden. D.h. auf das .NET Framework 3.0 sollte umgestiegen werden. Diese muss nicht zwangsläufig für alle Anwendungen gelten. Es ist ok, sich nur eine kleine Anwendung (auf wenn diese nur für interne Verwaltungszwecke verwendet wird) heraus zu nehmen und diese quasi als Übung mit Hilfe der neuen Technologie umzusetzen. Mit den gewonnenen Erfahrungen kann man sich an größere Projekte wagen.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Technologie einmal umweltbewußter? Es wäre an der Zeit ...
01.10.07 - Entwicklung, Diskussionen, Kunterbunt Beitrag von Norbert Eder| | Technologie. Bei diesem Begriff denkt man unwillkürlich an Fortschritt, an vereinfachte Arbeitsabläufe (oft gar nicht der Fall) und an tolle Errungenschaften. Dabei auf der Strecke bleibt wohl großteils die Umwelt. Nicht nur, dass Tonnen von Rohstoffe für einen PC verbraucht werden, irgendwie muss das Teil auch Strom bekommen und hier sind wir natürlich auch noch lange nicht bei 100% Wasser-, Wind- bzw. Sonnenenergie angelangt.
Tatsache ist, dass in den letzten Jahren alles nur schneller und kleiner (bei manchen Geräten auch größer) sein musste. Man nehme das Thema Grafikkarten: Noch bessere Auflösungen, mehr Details, noch mehr Polygone. Wenn das nicht reicht, dann stecken wir einfach zwei Grafikchips auf eine Karte. Was wurde hier vergessen? Nun, der Stromverbrauch. Wozu bitte ein 1000 Watt Netzteil? Wieso wird nicht einmal versucht die aktuelle Leistung beizubehalten mit gleichzeitiger Senkung des Stromverbrauchs? Nicht nur, dass durch den erhöhten Bedarf an Strom die Kosten für eben diesen in die Höhe schnellen, auch schädigen wir damit unsere Umwelt.
Nächstes Thema - vielleicht jetzt weniger auf den IT-Sektor bezogen, aber dennoch ein schönes Beispiel: Milliarden werden beispielsweise in die Formel 1 gesteckt. Mit welchem Ziel? Nun, Fahrer können noch mehr Geld verdienen (wozu bitte??) und die Autos sollen schneller werden. Werden sie zu schnell, dann werden wieder Reglements getroffen damit die Motorenhersteller wieder von vorne beginnen können (und die Teams mit ihrer gesamten Technik). Wie wäre es einmal, wenn man die Formel 1 (und den Ralleysport etc.) um alternative Möglichkeiten zu entwickeln und zu testen? Das Geld wäre doch vorhanden und DAS würde nicht die Umwelt verpesten, nein, sondern die Menschheit vielleicht sogar wirklich einen Schritt weiter bringen.
Hierfür gibt es viele Beispiele. Technologie muss nichts Schlechtes sein. Sie muss nur richtig eingesetzt werden und manche Entscheidungsträger sollten einfach einmal genauer über die Sinnhaftigkeit ihrer (Nicht-)Entscheidungen nachdenken.
Und vielleicht sollte auch jeder von uns darüber nachdenken. Ewig kann es so nicht weitergehen und es liegt auch an uns Akzente zu setzen. Muss es wirklich die schnellste und beste Grafikkarte sein, um ein paar Zeilen Code zu tippen?
| | | 1 Kommentar
- 592 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück Weiter
|
|
|
|
|
|
|
;)
;)
