-
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.
|
www.norberteder.com wieder online
26.02.06 - Blog-Intern Beitrag von Norbert Eder| | Seit heute ist meine Website www.norberteder.com wieder online. Die Seite war ja in den letzten Monaten durch einen Serverausfall down.
In den letzten Tagen habe ich etwas Zeit gefunden, um die Seite in einem neuen Design online zu stellen. Der komplette Content ist noch nicht online, wird jedoch in den nächsten Tagen nachgezogen.
| | | Kommentar hinzufügen
- 3 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
C# Beginner: Beispiel für den Aufbau eines Strategie-Spieles
24.02.06 - .NET, WPF Beitrag von Norbert Eder| | In diversen Foren wird oft nachgefragt, wie denn man denn ein Strategiespiel angehen könnte. Im Vordergrund stehen dabei keine Probleme á la Pathfinding, sondern bereits das Aufbauen des Spielfeldes bereitet oft Probleme.
Daher habe ich aus Lust und Laune eine kleine Demo erstellt, aus der man diverse Ansätze herauslesen kann.
Das Aussehen der Demo hatte hierbei keinen Vorrang und kommt daher mit folgender Oberfläche daher:
Nun zur Erklärung einige Punkte:
Darstellungsfläche stellt in diesem Beispiel ein ganz normales Panel dar, welches lediglich zum besseren Erkennen eingefärbt wurde. Wird nun der Button Generate Matrix betätigt, wird quasi eine Matrix auf die Spielfläche gelegt. Diese wird automatisch berechnet und kann durch den Parameter Length gesteuert werden. Dieser gibt die Seitenlänge des Quadrates an.
Der Button Add Building dient dazu, ein Building anzulegen. Es ist so vorzugehen, dass der Button zu klicken ist, danach ist auf eine beliebige Stelle des Panels zu klicken. Ist der Platz noch nicht belegt, wird das Gebäude auf diesem Feld "gebaut", andernfalls erscheint die entsprechende Meldung.
Dies ist im Endeffekt auch schon die gesamte Funktionalität dieser Demo. Trotz der Kürze der Entwicklungszeit habe ich dennoch versucht, dies möglichst einfach und erweiterbar zu gestalten, so dass aufgrund dieser "Vorlage" recht schnell unterschiedliche Bauten etc. eingefügt werden können.
Vorstellbar wären sicherlich noch Dinge wie Wiesen, Personen und auch Gebäude, die nicht auf ein Feld beschränkt sind. Ebenfalls müsste noch ein Pathfinding-Algorithmus implementiert werden und danach wäre eine erste spielbare Demo fast fertig.
Sollte ich Zeit finden werden noch die einen oder anderen Erweiterungen in diese Demo fließen, aber grundlegend sollte eine Basis für simple Strategie-Spiele vorhanden sein.
Hier noch das Demoprojekt inkl. Sourcecode: MatrixTestGame
| | | Kommentar hinzufügen
- 3 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Patent: Webapplikationen, AJAX, Flash etc.
23.02.06 - Internet Beitrag von Norbert Eder| | So wie es aussieht gibt es wohl ein Patent welches Webapplikationen die AJAX, Flash, etc. verwenden zugrunde liegt.
Nähere Informationen liefert golem.de.
Vielleicht muss man ja auch bald Lizenzgebühren bezahlen, wenn man die eigene sanitäre Einrichtung benutzen möchte.
Schön langsam reicht's dann ...
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
.NET User Group Styria Treffen
21.02.06 - Internet, Community Beitrag von Norbert Eder| | Heute ist es wieder soweit, das nächste Treffen der .NET User Group Styria steht an. Zu bewundern gibt es heute den Vortrag von Max Hauser zum Thema SQL Server 2005 Reporting Services.
Die Verstaltung findet heute um 17:30 Uhr im Campus02 (Hörsaal C 203) der WIFI Steiermark statt.
Da ich beim letzten Treffen leider krankheitsbedingt verhindert war, freue ich mich heute umso mehr darauf.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
C#: Google Web API schon getestet?
16.02.06 - .NET, Allerlei Beitrag von Norbert Eder| | Nein? Dann wird's - wie bei mir - nun absolut höchste Zeit.
Als ersten Schritt muss man sich die Google API unter http://www.google.com/apis/ downloaden und sich einen Account erstellen. Nach dem Account bekommt man eine Google ID zugesendet, mit der 1000 Requests pro Tag durchgeführt werden können.
Nun, als nächsten Schritt einfach ein neues Projekt im Visual Studio erstellen. Nun eine Web-Referenz auf http://api.google.com/GoogleSearch.wsdl erstellen und dem Teil am besten den Namen Google geben. Nun ist das wildeste erledigt.
Eine Abfrage sieht dann in weiterer Folge so aus:
Google.GoogleSearchResult r = s.doGoogleSearch(googleID, keywords,
0, 10, false, "", false, "", "", "");
int estResults = r.estimatedTotalResultsCount;
Google.ResultElement[] elements = r.resultElements;
Damit lässt sich dann schon etwas machen. Und beispielsweise könnte eine sehr einfach Abfrage-Anwendung so aussehen:
| | | 3 Kommentare
- 1780 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Unit-Tests und Aufwand
16.02.06 - Entwicklung, Software Testing Beitrag von Norbert Eder| | Danke für die vielen Rückmeldungen, die ich vor allem in Form von Emails erhalten habe. Dabei stand fast immer die Frage nach dem Aufwand im Vordergrund.
Zu diesem Thema kann ich folgendes sagen/behaupten:
Natürlich verursacht das Erstellen von Unit-Tests einen entsprechenden Aufwand, da jede Methode in allen erdenklichen Varianten getestet werden soll. Sinnvollerweise wird der Unit-Tests parallel zur zu testenden Klasse entwickelt. Dadurch erhöht sich zwar der Aufwand für die Entwicklung von Klassen, man bedenke aber das große ABER:
Durch die ständigen Test-Durchläufe kristallisieren sich sehr schnell Fehler heraus bzw. wo es nach einer durchgeführten Änderung ein wenig zwickt. Sollte dann doch einmal ein Fehler durchrutschen, kann mit Hilfe der Unit-Tests dieser recht schnell nachvollzogen bzw. überhaupt gefunden werden. Das erspart sehr viel Zeit. Vermutlich mehr, als man sich durch das Nichtschreiben von Unit-Tests sparen würde.
Jeder Leser kann sich nun selbst ein Bild davon machen. Einfach die durchschnittliche Anzahl der Bugs heranziehen und kurz darüber nachdenken, wie schwer so manche davon zu finden sind. Viele davon wären mit Unit-Tests erst gar nicht zustande gekommen.
Ich hoffe dieser Beitrag regt zum Nachdenken und Nachrechnen an und liefert so für jeden von Euch ein Ergebnis bezgl. der Sinnhaftigkeit von Unit-Tests.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
[Tutorial] Unit-Tests mit Visual Studio .NET
14.02.06 - Base Framework Beitrag von Norbert Eder| | Unit-Tests unter Visual Studio .NET
Inhalt
1. Einführung und Ausblick
2. Begriffserklärung
3. Notwendige Tools
4. Installation
5. Vorarbeiten
6. Ein konkretes Beispiel
7. Konklusio
1. Einführung und Ausblick
Bei fast allen Fragestellungen in diversen Foren gibt es Fragen zu Fehlern, die auf dreierlei Arten auftreten:
1. Mangelndes studieren der zur Verfügung stehenden Quellen. Dies inkludiert nicht nur diverse Artikel, die es im Internet zu finden gibt (ein Beispiel hier wäre die MSDN), sondern auch in Form von Büchern oder den zu den verwendeten Werkzeugen mitgelieferten Ressourcen.
2. Fehlendes Verständnis und Wissen rund um den Debugger. Immer wieder muss ich feststellen, dass der Debugger wenig bis gar keine Beachtung findet, obwohl sich durch ihn das wohl beste "Werkzeug" überhaupt offenbart. Auf schnelle Art und Weise können nicht nur Syntax-Fehler gefunden werden, nein, es können auch Variableninhalte abgefragt werden, Objektinformationen bezogen und sogar Abfragekommandos an den Compiler übergeben werden.
3. Ignoranz von Unit-Tests. Die Verwendung von Unit-Tests wird in vielen Fällen nur Profis zugetraut und aus diesem Grunde wird ihnen kaum Beachtung geschenkt - oder aber, einfach das fehlende Wissen um diese Möglichkeit.
Dieser Artikel soll zeigen, dass selbst Programmier-Anfänger sehr einfach Unit-Tests verwenden können.
2. Begriffserklärung
Bevor wir aber tiefer in die Materie einsteigen, muss der Begriff Unit-Test erklärt werden.
Durch Unit-Tests ist es möglich, Testklassen zu schaffen, die automatisiert andere, vorhandene Klassen testen.
So werden pro Testklasse folgende Dinge der zu testenden Klasse angegeben und getestet:
* alle Methoden
* alle Überladungen
* in allen erdenklichen Übergabeparametern (auch sinnlosen Varianten)
Vor allem die "sinnlosen Varianten" sind für die Tests sehr wertvoll: Dadurch werden Überläufe, und vor allem auch Fehleingaben durch User (diese passieren immer und überall) mit in den Test einbezogen und im Fehlerfalle kann dies bevor das Produkt den User erreicht nachgebessert werden.
Der Sinn hinter solchen Tests ist der, dass wie oben beschrieben, problematische Parameterübergaben im Fehlerfalle behandelt werden (da auf das Testergebnis entsprechend zu reagieren ist). Da eine Software laufend weiterentwickelt wird, werden auch ständig an allen erdenklichen Stellen Änderungen vorgenommen. Dadurch ist es in manchen Fällen schwer zu sagen, ob eine andere Stelle noch korrekt funktioniert. Durch diese Unit-Tests kann dies einfach festgestellt werden. Dazu sind nach der durchgeführten Änderung die Tests auszuführen und wenige Sekunden bis Minuten später (Abhängig von der Projektgröße) hat der Programmierer Gewissheit.
3. Notwendige Tools
Zu Beginn muss natürlich geklärt werden, welche Tools notwendig sind, um Unit-Tests unter dem Visual Studio verwenden zu können.
Aus meiner Erfahrung haben sich folgende Produkte als äußerst hilfreich erwiesen:
* TestDriven.NET [1]
* NUnit [2]
Bei TestDriven.NET handelt es sich um Unit-Testing Add-In für Visual Studio, welches mit unterschiedlichsten Unit-Testing-Tools zusammenarbeiten kann. Zu erwähnen wären hier NUnit, MbUnit und csUnit.
Bei NUnit handelt es sich um ein Test-Unit Framework, mit dessen Hilfe Unit-Tests durchgeführt werden können.
4. Installation
An diesem Punkt möchte ich nur an die entsprechenden Installations-Hinweise der Hersteller verweisen:
NUnit: http://www.nunit.org/index.php?p=installation&r=2.2.6
Bei TestDriven.NET ist lediglich die Installationsdatei zu starten. Daraufhin wird das Add-In im Visual Studio registriert und steht fortan zur Verfügung.
5. Vorabeiten
Um nun für ein neues oder bereits bestehendes Projekt Unit-Tests anzuwenden, sind kleine Vorabeiten notwendig.
Idalerweise empfiehlt es sich, Unit-Tests in ein eigenes Projekt auszulagern. Dieses Projekt muss natürlich Teil der Visual Studio Solution sein.
Nach dem Anlegen dieses Projektes, ist eine Referenz auf die nunit.framework.dll zu setzen. Ist dies geschehen, kann es mit einem konkreten Beispiel weitergehen.
6. Ein konkretes Beispiel
Gehen wir davon aus, dass unser Projekt einen Logger besitzt. Dieser hat die Aufgabe, allfällige Fehler in eine Logdatei zu schreiben. Natürlich muss dieser getestet werden, ob er auch den an ihn gestellten Anforderungen gerecht wird.
Dazu erstellen wir eine TestKlasse LoggerTest. Die neue Klasse muss zusätzlich mit dem Attribut [TestFixture] markiert werden. Danach erstellen wir die einzelnen Methoden, welche die einzelnen Tests darstellen. Beispielsweise könnte dies folgendermaßen aussehen:
public void LoggerLog()
{
try
{
Logger log = new Logger();
log.LogPath = @"C:temptemp.log";
log.Log("test");
Assert.IsTrue(true);
}
catch (Exception ex)
{
Assert.Fail(ex.Message);
}
}
Wie an diesem Beispiel zu sehen ist, müssen die zu testenden Methoden mit dem Attribut [Test] versehen werden.
Mit einem Rechtsklick auf die entsprechende Datei kann nun mittels "Run Test(s)" der Test gestartet werden. Wird dieser Befehl auf das Projekt angewandt, werden alle darin enthaltenen Tests gestartet.
Nach dem Durchlauf der Tests erscheint im Ausgabe-Fenster die Angabe, welche Tests durchgelaufen (also erfolgreich waren) und welche nicht.
Wann ein Test als erfolgreich und wann als nicht erfolgreich gilt, muss vom Entwickler selbst angegeben werden. Im Falle einer Exception darf der Test natürlich nicht als erfolgreich angeführt sein. Wurden alle Punkte durchlaufen und stimmt das Ergebnis, kann der Test als erfolgreich markiert werden.
Dafür zuständig ist die Klasse Assert. Diese hat einige Methoden, die für diese Aufgabe sehr hilfreich sind:
Assert.Fail: Hier ist ein String zu übergeben, der angibt, um welchen Fehler es sich handelt. Dies kann die Message-Eigenschaft einer Exception sein, oder auch ein selbst definierter String, um mitzuteilen wo bei was ein Fehler aufgetreten ist.
Assert.IsTrue: Hier werden normalerweise Vergleiche angegeben. Beispielsweise das Ergebnis der Methode und das Ergebnis, welches die Methode liefern sollte. Sind beide Ergebnisse ident, ist der Test durchgelaufen, andernfalls nicht.
Assert.IsFalse: Dies funktioniert wie Assert.IsTrue, nur in die entgegengesetzte Richtung.
7. Konklusio
Dieses kleine Tutorial lieferte einen kurzen Einblick in das Thema Unit-Tests unter Visual Studio und zeigt durchaus, dass sich dahinter keine komplizierten Abläufe verbergen. Stöbert man ein wenig in den angegebenen Internet-Ressourcen herum, können sehr schnell gute und hilfreiche Ergebnisse erreicht werden.
Sollten dennoch Fragen zu dem Thema entstehen - welche durch die angegebenen Ressourcen nicht abgedeckt werden können, kann der werte Leser mich unter csharp@gmx.at erreichen.
Referenzen
[1] http://www.testdriven.net
[2] http://www.nunit.org
| | | 3 Kommentare
- 3628 mal angesehen
| 2 Trackbacks
| Permalink | Trackback-URL |
Objekte und relationale Daten in einer Datenbank
13.02.06 - .NET, Datenverwaltung Beitrag von Norbert Eder| | Auf die Beiträge von Thomas und meiner Wenigkeit hat sich auch Alex zu Wort gemeldet. Sein Ansatz (angelehnt an den Microsoft SQL Server 2005) verfolgt das Ablegen von Objekten und relationalen Daten ein einer einzigen DB.
Auch hierzu ein paar Gedanken von mir:
Prinzipiell gibt es den Ansatz der ORDBMS (Objektrelationale Datenbank Management Systeme). Dabei wird ein relationales System um objektorientierte Fähigkeiten erweitert. Oft wird auch nur ein objektorientierte Zugriffsschicht darüberlegt. In der Tat werden allerdings keine Objekte mit relationalen Daten vermischt.
Wie würde das Speichern von Objekten zusammen mit relationalen Daten in einer Datenbank in der Praxis aussehen?
Prinzipiell stehe ich dem Vermischen von Objekten mit relationalen Daten eher negativ gegenüber. Der Ansatz von XML-Feldern in einer Datenbank (siehe SQL Server 2005) ist durchaus praktisch und in manchen Fällen auch sinnvoll. Dies jedoch zu nutzen, um Objekte abzulegen macht eher weniger Sinn. Aus folgenden Gründen (wenn ich von Serialisierung spreche, beziehe ich mich auf die XML-Serialisierung):
- Aufwand der Serialisierung. Bedingt durch diesen Aufwand können die Daten ohnehin wieder in eine relationale Struktur gequetscht werden. Performancemässig wird es hier (allerdings hab ich das jetzt nicht getestet) nicht sehr viel Unterschied geben.
- Weiters verleitet dieser Ansatz dazu, eine Tabelle mit mehreren XML-Feldern zu erstellen und darin serialisierte Objekte abzulegen. Eventuell noch von unterschiedlichen Typen. Spätestens dieser Punkt würde durchaus Probleme aufwerfen.
- Durch das einfache serialisierte Ablegen würden in der Datenbank Referenzen nicht mehr ersichtlich sein. In einem reinen relationalen oder reinen objektorientierten System bleibt dieser Vorteil erhalten. Referenzen in XML sind zwar möglich, aber selbst bei einem eigenen XML-Serializer nützt das Einfügen dieser Referenzen wenig, wenn sie durch die Datenbank nicht dargestellt werden können.
Abfragen sind natürlich auch in dieser Form noch auf der Datenbank möglich ohne alle Daten zu laden, aber durch die Vermischung von SQL und XPATH etc. würde ich meinen, dass der Performance-Vorteil eher gering ausfällt -> dürfte wohl im Minusbereich angesiedelt sein.
Und zu guter Letzt: Diese Variante würde kein gemeinsames Ablegen von Objekten und relationalen Daten implizieren. Das einzige was Sinn machen würde, wäre das Ablegen von relationalen Informationen (Metdaten etc.) zu Objekten - aber ich denke das übernimmt ohnehin die Indizierung für uns.
Soweit mal meine ersten Gedanken dazu. Weitere werden vermutlich noch folgen, wenn ich allen "neuen" Gedanken nachgegangen bin ;-)
| | | 3 Kommentare
- 1434 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
SQL Server 2005: Erstellung einer Replikation
12.02.06 - SQL Server Beitrag von Norbert EderSQL Server 2005: Managed Code
12.02.06 - SQL Server Beitrag von Norbert Eder
|
|
|
|
|
|
|
;)
;)
