Seite 2 - Entwicklung

Probleme mit NUnit und .NET 4.0

nospam@example.com (Michael Fuchs) — Fri, 07 May 2010 23:46:15 +0200

(english version below)

Gestern Abend verzweifelte Fehlersuche: Beim Benutzen von NUnit stellte ich ein seltsames Verhalten fest. Die einzelnen Tests liefen problemlos durch, jedoch war ein vernünftiges Debuggen nicht mehr möglich. Visual Studio behauptete, dass keine Debuggersymbole geladen seien [1] und so wurden keine Breakpoints mehr angesprungen.
Völliger Blödsinn natürlich, ich war mir ganz sicher dass ich die richtigen Einstellungen getroffen hatte.

Nach einer Stunde herumsuchen war dann klar: Alle Optionen sind so wie sie sein sollen. Nun war gute Rat teuer. Bis mir einfiel, welche Änderung es seit dem letzten Testlauf gegeben hatte: Das Frameworkversion war von 3.5 auf 4.0 verändert worden. Schnell mal probeweise wieder die ältere Version eingestellt und siehe da: es geht.
Das Problem findet sich dann bei NUnit selbst. Die Binaries wurden mit .NET 2.0 erstellt. Kann man auch problemlos mit eigenen Projekten verwenden die 3.0 oder 3.5 nutzen, ab 4.0 geht es aber nicht.

Glücklicherweise ist NUnit aber OpenSource, also flugs den Sourcecode besorgt und mit .NET 4.0 Unterstützung neu gebaut. Naja, so schnell ging es dann nicht [2], aber nach getaner Arbeit funktionierte alles wieder so wie es sollte.

Wer das gleiche Problem hat, sich aber das Neukompilieren ersparen will, kann die erzeugten Binaries auf http://blog.http.net/allgemein/probleme-mit-nunit-und-net-4-0/ herunterladen.

Short english version: Problems with NUnit and .NET 4.0
If you use NUnit with a .NET 4.0 project, you have to recompile NUnit with the same framwork. Otherwise breakpoints are not working [1].
You can download a .NET 4.0 - NUnit version at http://blog.http.net/allgemein/probleme-mit-nunit-und-net-4-0/

[1] The breakpoint will not currently be hit. No symbols have been loaded for this document.

[2] Anscheinend fehlen mehrere Dateien in dem Source-Archiv, daher musste ich erst einmal eine Weile Abhängigkeiten prüfen bis die Kompilierung erfolgreich war.

Eine Frage des Designs

nospam@example.com (Michael Fuchs) — Sun, 29 Nov 2009 22:46:00 +0100

Den meisten Spaß macht es natürlich, wenn man in eigenem Auftrag entwickelt. Dann wird alles so, wie man es sich vorgestellt hat [1]. Allerdings verdient man meist auch nicht allzu viel Geld damit.

Damit kommt eine Komponente ins Spiel, die mehr oder weniger konkrete Vorstellungen davon hat, was am Ende herauskommen soll: der Auftraggeber.
Das Problem ist nun: Wie vermittelt man diesem Auftraggeber die Unterschiede zwischen Will ich! und Geht!?
Oder noch schlimmer, zwischen Will ich! Geht auch! und Sollte man aber nicht so machen?

Das schlimmste Art von Entwicklung ist Webdesign. Im ungünstigsten Fall kommt der Kunde mit einer obskuren Layoutvorstellung und will diese entgegen jede Rat auch so umgesetzt haben. Und zum Schluss kommt dann tatsächlich ein Design in Altrosa heraus. *grusel*

Aber auch Kunden ohne konkrete Vorstellungen können mit schlechtem Geschmack alles zunichte machen. So erging es mir vor Jahren einmal. Unser Designexperte hatte zwei wirklich gute Vorschläge aufwändig vorbereitet. Damit die nicht so einsam aussahen bat ich noch um einen dritten. "Das kann auch schnell und schmutzig gehen, ist ja nur als Kontrast zu den anderen beiden."
Natürlich fand der Kunde diese in dreißig Minuten zusammengeschusterte Machwerk grandios. Zu meinem Entsetzen. Nur eine Änderung wollte er haben: Das ziemlich hässliche Orange sollte durch ein noch ekelhafteres Dunkelgrün ersetzt werden.

Kommen dann noch Wünsche hinzu, die sämtlichen Prinzipien des Web widersprechen kann man sich nur noch eines sagen: "Hoffentlich weiß niemand, dass ich dafür verantwortlich bin!"

Ich wünsche also jedem einen Auftraggeber, der soviel Verstand besitzt dass er sich auch beraten lässt.

[1] Vorausgesetzt die eigenen Fähigkeiten reichen dafür aus.

Kopfschmerzen

nospam@example.com (Michael Fuchs) — Wed, 21 Oct 2009 11:04:32 +0200

Dim salt As String = "Was schönes buntes kann auch manchmal Kopfschmerzen machen!"

Was immer der Programmierer da nimmt, er sollte weniger davon schlucken.

Eigenentwicklung

nospam@example.com (Michael Fuchs) — Fri, 19 Jun 2009 23:45:00 +0200

Als Entwickler neigt man irgendwie dazu, für alle Probleme eine eigene Lösung zu bauen. Völlig egal ob es schon zwanzigtausend ähnliche Systeme auf dem Markt gibt. Man verzettelt sich dabei leicht. Ein Kollege formulierte das Problem so:

Eigentlich brauchst Du nur ne Kalenderfunktion,

aber die Groupwares taugen nichts.

Also musst Du eine eigene schreiben.

Als Du damit beginnst, stellst Du fest, dass Du ja eigentlich was zum Loggen brauchst.

Und dann, dass Du viele Aufgaben hast.

Dann brauchst Du nen Bugtracker für die Aufgaben.

Um den zu schreiben 'nen OR-Mapper.

...
...
...

nachdem Du das Betriebsystem geschrieben hast, um Deine eigene fertige Datenbank darauf zu hosten, stellst Du fest, dass ein Papierkalender ja auch ganz OK wäre.

Hm, ich bastele gerade an einem einfachen Groupwaresystem und einer Projektverwaltung. Leider haben meine vorherigen Recherchen wirklich keine passende Lösungen ans Tageslicht gebracht. Oder ich bin zu anspruchsvoll.

Leer

nospam@example.com (Michael Fuchs) — Fri, 09 Jan 2009 11:36:00 +0100

Der VB-Quellcode des Tages lautet:

Try



Catch ex As Exception
  Throw ex
End Try

Schön das manche Programmierer wirklich sichergehen und alle Eventualitäten abfangen wollen.

"missing separator" mit make

nospam@example.com (Michael Fuchs) — Thu, 08 Jan 2009 12:00:00 +0100

Makefile:2: *** missing separator.  Stop.

Nanu, was habe ich falsch gemacht? Zumal die Makefile ja eben noch unter Windows funktionierte. Unter Linux jedoch nicht. Seltsam.

Am Dateiformat kann es eigentlich auch nicht liegen, Notepad++ speichert Zeilenumbrüche brav nach UNIX-Art. Nachdem ich die Datei mit vi geöffnet habe und dort ganz viele rote Zeilen sehe, befrage ich die Suchmaschinen noch ein bisschen. Und das Ergebnis ist wirklich idiotisch. Ich habe Notepad++ und gedit so eingestellt, dass sie keine Tabulatoren speichern, sondern automatisch in zwei Leerzeichen umwandeln. make besteht aber darauf, dass die rules eines target mit einem Tabulator beginnen.

Wer ist eigentlich auf diese bescheuerte Idee gekommen? Welchen Sinn hat es ausgerechnet auf Tabs zu bestehen? Hat vielleicht historische Gründe, aber warum kann make nicht etwas toleranter werden?

Unter Windows wurde meine Makefile übrigens von Borlands TurboMake interpretiert. Dieses stört sich nicht an Leerzeichen.

Benutzerfreundliche Passwörter

nospam@example.com (Michael Fuchs) — Fri, 21 Nov 2008 10:26:00 +0100

Eine neuer Benutzeraccount wird eingerichtet und der Systemadministrator oder das Programm selbst muss ein Passwort vergeben. Es sollte möglichst lang und kompliziert sein, damit der Benutzer es nach dem ersten Anmelden sofort ändert. Hierfür bietet sich die Verwendung einer UUID an. Die Wahrscheinlichkeit dass zwei UUIDs gleich sind, ist sehr gering. Damit ist natürlich auch ein Angriff darauf recht schwierig. Und das Format ist hinreichend kompliziert, dass kaum jemand solch ein Passwort auswendig lernen wird.
Normalerweise sehen UUIDs so aus:

0FB33339-5388-4CAC-B976-12F88785F4E0

Beim Einsatz für Passwörter sollte man aber die Bindestriche zwischen den Gruppen weglassen und lieber dieses Format nehmen:

0FB3333953884CACB97612F88785F4E0

Ohne die Bindestriche können Benutzer einfach auf das Passwort doppelt klicken und es so markieren. Werden die Bindestriche gesetzt, ist eine manuelle Markierung durch Bewegen der Maus nötig. Und dabei ist es für viele Benutzer schwierig das Passwort richtig zu "treffen". Oftmals werden am Anfang oder am Ende Leerzeichen mitkopiert.

Programmieren mit Schlagworten

nospam@example.com (Michael Fuchs) — Tue, 11 Mar 2008 12:40:00 +0100

Die Art und Weise, wie wir programmieren entwickelt sich immer weiter. Strukturiert, prozedural, modular, schließlich objektorientiert.
Zur Zeit ist die Phase der Schlagwort-Programmierung aktuell. Schlagworte wie Framework, Dependency Injection, Business Objects. Besonders gerne werden solche Worte von Redakteuren der "Fachliteratur" genutzt, in Zeitungen mit wohlklingenden Namen wie "Der Entwickler", "DotNetPro", etc. In den gleichen Zeitungen bieten diese Redakteure dann Schulungen an, bei denen man für 4000 EUR (für 2 Tage) dann die Verwendung dieser modernen Technologien lernt.

Der Grundgedanke, der hinter allem steckt, ist die Generalisierung. Nichts doppelt schreiben, sondern Altes wiederverwenden.

Wenn man in den Quellcode sieht und dann den gleichen Code hintereinander wiederfindet, nur jedes Mal auf eine andere Liste von Dateien angewandt, kann man berechtigterweise fragen, warum der Programmierer solches nicht eine eigene Funktion ausgelagert hat.
Sieht man die Objekte Kunde und Lieferant, die beide über die gleichen Eigenschaften (Adresse, Ansprechpartner, Telefon, E-Mail, etc.) verfügen, liegt es doch sehr nahe beide von einer Klasse namens Kontakt abzuleiten.
Die Generalisierung sollte natürlich nicht übertrieben werden. Sonst landet man eventuell bei folgendem Szenario:
Für einen Zeitschriftenverlag soll ein Abrechnungssystem für Abonnements entwickelt werden. Doch weil der Projekleiter gerne generalisiert und die Chance wittert in den nächsten zwei Jahren auch einem Pizzalieferdienst ein Abrechungssystem zu verkaufen, wird es soweit generalisiert, dass es für beide Zwecke einsetzbar ist.
Nun kann das System also beides, nur nichts richtig. Vielleicht kann es auch erst einmal gar nichts, weil die Entwickler so sehr abstrahieren müssen, dass die Arbeit zehnmal solange dauert, als wenn man einfach zwei Systeme entwickelt hätte.

Es ist also wichtig, den richtigen Mittelweg zu finden. Wenn es um immer wiederkehrende Techniken wie Datenbank-Ein-/Ausgabe geht, lohnt es sich auch immer wieder auf die gleichen Komponenten zurückzugreifen. Fertige Frameworks wie iBatis sorgen dabei für eine Zeitersparnis, die die nötige Einarbeitungszeit schon bei einem mittleren Projekt rechtfertigt.

Kommt man jedoch in den Bereich der spezielleren Anwendungslogik, sollte man mit dem Generalisieren vorsichtig sein. Vielleicht kann man dann wirklich bei zukünftigen Projekten Zeit sparen, vielleicht muss man aber dann auch die generalisierten Komponenten wieder aufwendig einbauen und spart eigentlich nichts. Irgendwann steigt einem der Kunde aufs Dach, weil das Projekt zehn Monate im Verzug ist.
Fängt man dann noch mit speziellen Techniken wie Dependency Injection oder Microkernel an, verliert man irgendwann auch den Überblick und die Kontrolle über den Code. Natürlich kann man Software so entwickeln, dass alles von außen steuerbar ist. Sei es mit Parametern oder Konfigurationsdateien. Die Wartbarkeit eines Systems wird damit aber nicht unbedingt gefördert. Im Gegenteil, andere Entwickler die später ebenfalls mitarbeiten wollen, müssen sich irgendwann durch fünfzig verschiedene Dateien lesen, um eine Programmfunktion zu verstehen. Und das nur, weil irgendein Programmierer die totale Technologiegeilheit verspürt. Lieber sollte man seine Zeit in eine gute Dokumentation investieren.

Dünne Linien bei dia

nospam@example.com (Michael Fuchs) — Tue, 29 Jan 2008 15:30:00 +0100

Eine Sache die mich an dia etwas stört, sind die recht Dicken Linien in der Ansicht. Zum Einen sieht es unschön aus, zum Anderen ist es schwerer Text zu lesen, der direkt an einer Linie steht. Besonders wenn Unterstriche enthalten sind.

Ein kleiner Trick schafft Abhilfe: Die Zoomstufe auf 99,99% stellen und schon springt sie wieder auf 100% zurück, die Linien sind nun aber viel dünner.

Das funktioniert allerdings nur, wenn die Kantenglättung deaktiviert ist.

Verbesserung

nospam@example.com (Michael Fuchs) — Thu, 04 Oct 2007 15:00:00 +0200

Warum gibt es eigentlich keine integrierte Rechtschreibprüfung für Visual Studio? Würde den Beta-Testern viel Zeit ersparen.