-
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.
|
Vermeide: if (myBoolean == true)
04.12.06 - .NET, Base Framework Beitrag von Norbert Eder| | Oft sieht man Code á la
if (myBoolean == true)
oder
if (myBoolean != true)
und jeder hat es zeitweise selbst irgendwo so verwendet. Nichts desto trotz verhält es sich mit diesen Bedingungen wie mit grünem Gras. Oh, moment. Gras ist ja ohnehin für gewöhnlich grün. Oder war es ein weisser Schimmel, oder weisser Schnee? Nun gut, wieder zurück zum Thema.
if (myBoolean)
oder
if (!myBoolean)
ist der saubere Weg dies zu tun - und zeugt auch vom Verständnis von boolschen Variablen.
| | | 12 Kommentare
- 775 mal angesehen
| 1 Trackbacks
| Permalink | Trackback-URL |
Klassen- und Namespace-Informationen zum .NET Framework erfolgreich finden
01.12.06 - .NET, Allerlei Beitrag von Norbert Eder| | Aufgrund eines Kommentares zu meinem Beitrag C#: Welche Datei repräsentiert einen Prozess möchte ich hier kurz aufführen, wie man Informationen zu Klassen des .NET Frameworks einfach finden kann. Hierfür gibt es unterschiedliche Wege:
Object Browser
Dieser ist äußerst hilfreich, wenn beispielsweise nach Klassen gesucht wird, jedoch der Namespace nicht bekannt ist. Alle Klassen, die in bereits referenzierten Assemblies vorhanden sind, können so gefunden werde. Dies betrifft alle Klassen der .NET Framework Core. Zusätzlich können Methoden-, Property- und Vererbungs-Informationen bezogen werden.
Microsoft Developer Network (MSDN)
Microsoft steckt sehr viel Aufwand und Mühe in das Microsoft Developer Network. Darin finden sich unter zahlreichen Artikeln und Hilfestellungen auch die Dokumentationen zu den einzelnen .NET Framework Versionen. Jede Klasse des .NET Frameworks ist darin aufgelistet und großteils mit Beispielen versehen. So lassen sich die entsprechenden Namespaces finden, als auch Hinweise wie die Klassen verwendet werden, ob sie threadsicher sind und viele weitere Informationen. Ein Muss für jeden .NET Entwickler.
Weitere Ressourcen
Zusätzlich finden sich eine Menge weiterer Ressourcen zum Thema .NET im Internet. Wer Beispiele sucht ist auf CodeProject gut aufgehoben. Wer ständig aktuelle Informationen, Informationen zu neuen Technologien und/oder Erfahrungsberichte sowie kurze Code-Beispiele sucht, der sollte sich auf .NET Heute umsehen. Zusätzlich finden sich eine Menge Foren, wie die MSDN Foren.
Zu guter Letzt finden sich viele Personen aus der Community, die doch meistens ein offenes Ohr für unseren Nachwuchs besitzen. Wer ein wenig guten Willen zeigt, wird sicher nicht abgewiesen.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Begriffserklärung: Boxing und Unboxing
30.11.06 - .NET, Base Framework Beitrag von Norbert Eder| | Für die einen ein alter Hut, für andere ein Grund um auf die Suche nach Informationen und Erklärungen zu gehen. Nun, ein wenig Licht ins Dunkel kann ich hiermit bringen. Es erfolgt nicht nur eine Erklärung der beiden Begriffe, sondern auch Hinweise wann diese Techniken eingesetzt werden sollen/können und wann dies zu vermeiden sind.
Boxing ist die Konvertierung eines Wertetyp in einen Verweistyp. Beispiel:
int i = 999; // Werttyp
object o = (object)i; // Konvertierung in einen Verweistyp
Unboxing ist die Konvertierung eines Verweistyp in einen Wertetyp. Beispiel:
object o = 999; // Wert in einem Verweistyp
int i = (int)o; // Konvertierung in einen Wertetype
Boxing und Unboxing versachen zusätzlichen Aufwand, daher sollten diese Operationen vermieden werden. Je häufiger der entsprechende Code-Bereich ausgeführt wird, desto weniger empfhielt sich die Verwendung.
Es sei an dieser Stelle bemerkt, dass auch der Aufruf von virtuellen Methoden, die Strukturen von System.Object erben, unter Boxing fallen. (Beispiel: ToString).
Empfohlene Vorgehensweisen
Um Boxing und Unboxing zu Vermeiden (und somit auch etwaige Performanceprobleme), empfiehlt es sich, einige Punkte einzuhalten. Hier eine (unvollständige) Liste:
- Werden Strukturen definiert, sollten die Methoden GetHashCode, Equals und ToString überschrieben werden
- Bestehen Methoden die Parameter vom Typ object besitzen, die jedoch zur Übergabe von Wertetypen verwenden werden, empfiehlt es sich, Überladungen zu definieren, die auf den jeweiligen Wertetyp abgestimmt sind.
- Anstatt object-Parameter zu verwenden, empfiehlt sich die Verwendung von Generika.
Wann soll Boxing/Unboxing eingesetzt werden
Manche mögen mir jetzt vielleicht widersprechen, aber ich persönlich empfehle Boxing und Unboxing nicht einzusetzen. Selbst bei Code-Teilen die nur selten ausgeführt werden empfiehlt es sich, beispielsweise auf Generika zu setzen oder Überladungen für die entsprechenden Wertetypen zu schaffen. Dadurch erhöht sich um einen die Übersichtlichkeit, die Verständlichkeit und vor allem auch die Performance.
| | | 2 Kommentare
- 1137 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Den Projekt-Sumpf hinter sich lassen. Jetzt!
28.11.06 - Entwicklung, Projektmgmt. Beitrag von Norbert Eder| | Unterschiedlichste Studien (beispielsweise von der Standish Group [1]) zeigen auf, dass nur ein Bruchteil sämtlicher IT-Projekte auch tatsächlich fertiggestellt werden. Populieren wir diese Studien zusätzlich mit Zufriedenheitsdaten, dann sieht die Statistik noch weit schlechter aus.
Woran diese scheitern möchte ich nun anhand meiner ganz persönlichen Erfahrung beschreiben.
Wie schon in der Post Warum "Mein Chef will .."-Projekte meist in die Hose gehen (und in der darauffolgenden Diskussion, siehe Kommentare) beschrieben, sind oft ungenaue Spezifikationen und/oder Beteiligte mit fehlender Kompetenz, Faktoren für das Scheitern von Projekten. Dem kann im Grunde recht einfach entgegengewirkt werden, allerdings entsteht hierfür anfangs ein erhöhter Aufwand, als auch möglicherweise (sogar eher wahrscheinlich) zusätzliche Kosten.
1) Fehlende interne Kompetenz durch externe Berater kompensieren. So kann vermieden werden, dass in den wichtigen Anfangsschritten grundlegende Fehler gemacht werden. Dies gilt sowohl für die gemeinsame Spezifikation mit dem Kunden, als auch der Entscheidung bezüglich zu verwendender Technologien, Entwurf der Architektur und verwandten Themen.
2) Kommen aufgrund der Unternehmensgröße Business Consultants zum Einsatz empfiehlt es sich auf technisch versierte Personen zu setzen. Hier denke ich unter anderem an Spezifikationen die so technisch nicht umsetzbar sind oder den Aufwand ins quasi Unermessliche treiben. Auch Techniker können den Umgang mit dem Kunden lernen und wirtschaftliche Zusammenhänge begreifen. Aus meiner Erfahrung erzielen Business Consultants die größten Erfolge, die in "ihrem Leben davor" die Rolle des Umsetzenden inne hatten.
3) Technische Entscheidungen, Lösungswege etc. sollten auf jedem Fall mit der Entwicklungsabteilung (den zuständigen Personen) abgestimmt werden. Der Kunde versteht im allgemeinen dass bestimmte Punkte nicht sofort fixiert werden können, da notwendige Zusagen der Umsetzenden fehlen. Dadurch erhöht sich für ihn die Chance das zu bekommen was er auch tatsächlich möchte.
Eine zusätzliche Problematik ergibt sich bei der Kommunikation. Oftmals werden bereits vorhandene Kanäle nicht benutzt oder es existiert eine Scheu vor neuen Möglichkeiten. Ablagesysteme für Dokumente aller Art fehlen oft (nun, wer findet ein bestimmtes Dokument als erstes?). Zuständigkeiten, Tasklisten werden oft nicht kommuniziert. Missverständnisse stehen also an der Tagesordnung. Vielfach kommt zusätzlich folgendes Verhalten zu Tage: Ein Thema wird lieber über mehrere Tage hinweg via Email diskutiert, anstatt für 10 Minuten zum Höhrer zu greifen, das Thema zu besprechen, danach kurz in einem Protokoll zusammen zu fassen um es dann endlich erledigen zu können.
Das Thema der Kommunikation ist jedoch nicht nur auf interne Prozesse beschränkt. Ebenfalls wird oftmals die Kommunikation zum Kunden vernachlässigt. So ist ein Projekt spezifiziert, das Projekt begonnen, aber eine laufende Absprache und Kontrolle mit dem Kunden fehlt vollkommen. Der Kunde möchte über den Fortschritt bescheid wissen, kommt im Zuge diverser Demonstrationen auf Veränderungswünsche usw.
Fehlende Kontrolle. Wir bereits angesprochen: In vielen Fällen fehlen Kontrollmechanismen. Nein hier soll nicht der Mitarbeiter überwacht werden, sondern vielmehr der Fortschritt des gesamten Projektes. Denn nur dadurch kann festgestellt werden ob der Fertigstellungstermin zu halten ist. Nur dadurch kann dem Kunden ständig Feedback über den aktuellen Implementierungsstand geliefert werden. Fakt ist: man weiß wo man steht.
Dokumentation. Nein, nicht nur die Software sollte dokumentiert werden. Besprechungen, Telefonate, eben sämtliche Entscheidungen. Dadurch kann festgestellt werden, wann etwas definiert wurde, wer anwesend war und dadurch kann vermieden werden, dass immer wieder über bereits beschlossene Tasks diskutiert wird (sogenannte Endlos-Tasks die wie ein Damokles-Schwert über alle Beteiligten hängen). Zusätzlich zur daraus resultierenden Historie können Entscheidungswege nachvollzogen werden, können beispielsweise auch neue Mitarbeiter einfacher ins Boot geholt werden.
Lange Rede kurzer Sinn:
Ein Projekt erfolgreich abzuschließen ist im Grunde nicht schwer. Es erforderd Konsequenz von allen Beteiligten und eine realistische Planung. Ein Kunde ist bereit einen Monat länger auf die Software zu warten, wenn es zu Beginn so definiert wurde. Aber dann muss sie ausgerollt werden. Er soll ja als Kunde erhalten bleiben ...
Natürlich habe ich jetzt viele Punkte nicht beachtet, aber ich denke, dass ich viele wichtige Punkte erfasst habe. Leider steht jedem Projektmanagement Aufwand und Kosten gegenüber, aber durch eine effiziente und genaue Planung können Kosten, Aufwand, Ungemütlichkeiten, Streit etc. eingespart werden.
[1] Homepage Standish Group Inc
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Warum "Mein Chef will ..."-Projekte meist in die Hose gehen ...
27.11.06 - Entwicklung, Projektmgmt. Beitrag von Norbert Eder| | Aufgrund meiner Tätigkeit bei tutorials.de stoße ich immer wieder auf junge Programmierer die als Praktikant oder als Einzelkämpfer in einem Unternehmen arbeiten, deren Chef ihnen ein Projekt aufträgt, welches den Horizont dieser Person eindeutig sprengt. Selten wird begriffen, dass diese Projekte einfach nur schief gehen können, zumal grundlegende Gegebenheiten einfach fehlen. Hier eine Liste, die ich mir oft bei Fragen zu Lösungen dieser Art denke:
1. Die Anforderungen werden nicht klar genug vorgegeben. "Wir brauchen ein Shop-System". Gut, die grundlegende Anforderung wäre definiert, aber der Rest? Hier liegt es am Entwickler nachzuhaken und alles notwendige in Erfahrung zu bringen. Sonst ab in die Hose mit diesem Projekt.
2. Der Chef (der kein Techniker ist) gibt das Projekt, als auch sämtliche Rahmenbedingungen wie etwaige Verschlüsselungen, Architekturen etc. vor. Auch das wird meist in die Hose gehen, da hier einfach das Know-How des Chefs auf dem Gebiet der Softwareentwicklung fehlt und etwas - nur weil man es zufällig irgendwo gehört hat - nicht unbedingt das Beste für das eigene Projekt ist.
3. Durch Zeitdruck wird dem kleinen Entwickler keine Zeit gelassen, sich mit der Materie zu beschäftigen, sich ein Design auszudenken, mit erfahrenen Programmierern darüber zu sprechen. Raus kommt ein Rucki-Zucki-Projekt, das den ursprünglichen Anforderungen eventuell entspricht, aber spätestens bei der ersten Änderung zusammenbricht.
Diese und weitere Punkte könnte ich an dieser Stelle aufzählen. Daher an dieser Stelle nur der Hinweis: Diverseste Statistiken zeigen, dass die meisten Projekte definitiv in der Hose landen und entweder nicht zur Zufriedenheit gelöst werden bzw. überhaupt gar nicht fertiggestellt werden. Daher: bitte unbedingt jedes Projekt genau spezifizieren, Rahmenbedingungen klären, ToDo's festlegen, Technologien und Techniken evaluieren und erst _dann_ mit der Implementierung beginnen. Es ist keine gute Lösung am nächsten Tag bereits einen ersten Prototypen zu sehen bzw. sehen zu wollen ...
| | | 9 Kommentare
- 1316 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Abwärtskompatibilität in Frameworks
24.11.06 - .NET, Base Framework Beitrag von Norbert Eder| | Wer Frameworks entwickelt stößt vielleicht manchmal auf die gleichen Probleme wie ich. Kernpunkt ist die Abwärtskompatibilität. Generell sollte die Einbindung des Frameworks auch nach einer Aktualisierung auf eine neue Version immer noch funktionieren. Vorzugsweise mit einer Übergangsfrist und der obsolete-Markierung [1]. Nun, in manchen Fällen hat sich jedoch ein Hinkefuss ins Framework eingefunden, der komplett redesigned werden sollte.
Wie handhaben das meine Leser? Wird hier hart umgekrempelt und dies durchgezogen oder versucht ihr mit aller Gewalt die Abwärtskompatibilität zu gewährleisten?
Rückmeldungen wären absolut hilfreich und gewünscht.
[1] Klassen als obsolete (veraltet) markieren
| | | 5 Kommentare
- 785 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Neuestes vom Settings Persistence Framework
23.11.06 - .NET, Base Framework, Tools, SPF Beitrag von Norbert EderC#: Welche Datei repräsentiert einen Prozess
22.11.06 - .NET, Base Framework Beitrag von Norbert Eder| | Da manche Prozesse mehrfach ausgeführt werden bzw. werden müssen, ist es manchmal gut zu wissen, welche DLL oder Anwendung der Ursprung eines Prozesses ist. Der nachfolgende Beispiel zeigt, wie eine die Informationen zur gesamten Prozessliste ausgegeben werden. Achtung: Die Prozesse idle und System besitzen kein main module.
Process[] processes = Process.GetProcesses();
foreach (Process p in processes)
{
try
{
Console.WriteLine(p.ProcessName + " - " + p.MainModule.FileName);
}
catch (Exception ex)
{
Console.WriteLine(p.ProcessName);
//Console.WriteLine(ex.Message);
}
}
| | | 2 Kommentare
- 685 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
.NET: Wo beginne ich als Anfänger?
20.11.06 - .NET, Allerlei Beitrag von Norbert Eder| | Diese Frage wird mir immer wieder gestellt. Womit soll begonnen werden, wie beginnt man ein Projekt, was ist zu beachten und viele weitere Fragen warten darauf, beantwortet zu werden.
Nun, um Grunde ist es nicht ganz so einfach und Anfänger haben oft das Gefühl, von der Informationsflut quasi erschlagen bzw. ertränkt zu werden. Doch es ist nicht ganz so kompliziert.
Zu unterscheiden gilt:
- Kann ich alles, um ein bestimmtes Projekt erfolgreich abzuschließen.
- Wie plane ich ein Projekt von A bis Z?
Die erste Frage muss jeder für sich selbst beantworten. Wenn man etwas nicht kann, muss einfach die notwendige Zeit aufgewandt werden. Komme es wie es wolle. Viele Tests, viele Dokumentationen lesen und mit vielen Menschen sprechen. Das quasi offene Geheimrezept.
Zur zweiten Fragen gibt es jede Menge Bücher zum Thema Projektmanagement. Hier möchte ich mit meinen Ergüssen keine Verwirrung stiften. Eher besser ein allgemein anerkanntes Buch schnappen und los geht's.
Ach ja, es gibt zahlreiche Ressourcen im Netz, die vor allem Anfängern zu Gute kommen. Einfach einmal einen Blick darauf werden.
Hier ein paar Starthilfen:
- Galileo Computing - <openbooks>
- The CodeProject
- Microsoft CodePlex
- .NET Heute
| | | 2 Kommentare
- 600 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
CCTray: CruiseControl.NET Build-Fortschritt im Überblick
20.11.06 - .NET, Base Framework, 3rd Party Tools Beitrag von Norbert Eder| | Thomas Darimont hat mich auf ein weiteres hilfreiches Tool für CruiseControl.NET hingewiesen. CCTray [1]. Damit läßt sich der Build Progress überwachen und das Tool erlaubt es, in einige Operationen einzugreifen.
[1] CCTray Website
| | | 2 Kommentare
- 733 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück Weiter
|
|
|
|
|
|
|
