Wilko Waitz - Merksätze

Network Storage Link for USB - Aus Spass an der Freude II

Wilko Waitz — Sat, 26 Jan 2008 20:08:56 GMT

Neues von der Front!

Endlich, ich habe es geschafft. Die Debian-Installation hat wunderbar funktioniert und das aus meiner Sicht geniale Installationsverfahren hat sofort für viel Freude und Wiedererkennungseffekt gesorgt.

Nachdem ich alle benötigten Pakete installiert hatte; erstmal die Wohlfühlsoftware ala vim und dann die Dinge zum Verrichten der Arbeit, konnte das Konfigurieren losgehen. Zuerst wurde Kerberos konfiguriert, damit die Authentifizierung mit dem DC klappen kann. Das bedeutet Realm einrichten, Passwordserver bekanntgeben und hoffen das es funktioniert. Welch wunder, es ging

Als nächstes kam dann die winbind- und Sambakonfiguration dran. Mit korrektem Kerberos eigentlich kein Problem aber man glaubt nicht, welcher Unsinn so im Netz kursiert. Zum Teil von der ganz üblen Sorte. Nach einigem hin und her habe ich es dann zum laufen bekommen.

Ich konnte den "Rechner" in der Domain anmelden und wbinfo -u listete mir alle Domainnutzer auf. Der Zugrifftest vom Windowsclient funktionierte natürlich nicht; Mist. Die Rechner wird korrekt aufgelistet und ein Blick auf die Freigaben offenbart mir das gewünschte Bild. Leider erfordert er beim Aufrufen der Freigabe eine Authentifizierung. Hallo? Genau das sollte doch nicht passieren!

Wie es immer ist: Es beginnt die Suche nach der Nadel im Heuhaufen.

Kerberos (Check)
Winbind - Test mit wbinfo -u und wbinfo -g (Check)
Samba - Alles unnötige rausgelöscht, Kommentare entfernt - sieht gut aus (Check)

Nix geändert, kann nicht gehen. Mist!

Also habe ich den Computer wieder aus der Domain rausgeschmissen und ihn erneut hinzugefügt. Nix geht. Test mit kinit und klist, ich bekomme gültige Tickets. Warum geht es nicht? Nochmal die Sambakonfiguration durchschauen und alle Einstellungen welche auf Rechtebeschränkung abzielen auskommentieren. Ups, es geht! Soviel zu obiger Behauptung: Alles unnötige rausgelöscht.

Das Problem war letztlich eine Einstellung in der smb.conf.

valid users = %S

Hmm... komisch, überall wird es so empfohlen/angegeben. Wie dem auch sei, jetzt funktioniert es erstmal. Warum %S nicht klappt muss und werde ich noch herausfinden.

Wenigstens kann ich, wenn auch nur auf Umwegen, einen neuen Merksatz ableiten:

Merksatz 4.0
Wenn der Wagen nicht läuft, solltest du erst nach den Zündkerzen sehen und nicht gleich den Motor austauschen.

Versionsverwaltung und deren praktischer Einsatz

Wilko Waitz — Mon, 05 Nov 2007 16:55:12 GMT

Versionsverwaltungen sind schon eine nette Sache. Insbesondere für mich, da ich zuweilen an drei unterschiedlichen Rechnern entwickle. Auf diese Art und Weise habe ich immer und überall den aktuellen Entwicklungsstand. Dumm nur, wenn man vergisst am Ende des Tages seine Arbeitsergebnisse einzuchecken. Dann ist obiger Ansatz blanke Theorie. So geschehen am Wochenende.

Jetzt sitze ich hier, mehr als 600 km vom aktuellen Entwicklungsstand entfernt und könnte in die Tischkante beisen. Ich stehe vor der Wahl:

meinen Angehörigen am Telefon zu erläutern, wie sie die Arbeitsergebnisse in die Versionsverwaltung bekommen oder
erläutern wie man in der Firewall den Port für eine Remotedesktopsitzung öffnet
die Arbeit doppelt zu machen.

Egal welche Alternative ich wähle, es kostet mich Zeit und Nerven. Ich werde in der Zukunft wieder auf das Tupel; externe Festplatte und Versionsverwaltung umsteigen. Es könnte nur sein, das ich die Festplatte desöfteren vergesse. Aber davon hört ihr zu gegebener Zeit. Nun noch den Merksatz, damit er sich einprägt und ich vor solchen Unannehmlichkeiten in Zukunft verschont bleibe.

Merksatz 3.0
Am Ende des Arbeitstages sind die Arbeitsergebnisse einzuchecken!

Ein paar Gedanken zur Ausnahmebehandlung

Wilko Waitz — Fri, 02 Mar 2007 15:33:31 GMT

Warum dieser Beitrag

Exceptionhandling ist zum Teil eine Frage der Philosophie und der Einstellung. Einige behandeln Ausnahmen überhaupt nicht und andere Verfahren nach der catch all Philosophie. Beides ist suboptimal.

Wie sieht vernünftige Ausnahmebehandlung aus

Grundsätzlich verfahre ich immer nach folgendenden Merksätzen:

Merksatz 2.0
Behandle nur Ausnahmen, welche du auch lösen kannst.

Dieses Verfahren gaukelt dem Benutzer einer Bibliothek nicht vor, dass sie sich im Normbereich bewegt. Weiterhin kann er für seinen Anwendungsfall geeignete Lösungsstrategien implementieren. Handelt es sich nicht um eine Bibliothek, sondern um das eigentliche Programm, erleichtert es das Testen und das Ermitteln von Grenzbereichen, welches dann wiederrum die Ableitung von geeigneten Lösungsstrategien ermöglicht. Sowohl für die Bibliotheken als auch für die Anwendung.

Merksatz 2.1
Ausnahmen sind bei der Entwicklung eines Produktes notwendig und willkommen. Sie verbessern die Qualität des Produktes, wenn sie frühzeitig auftreten können/dürfen.

Macht eine Anwendung von Log-Mechanismen Gebrauch, so ist nichts dagegen einzuwenden, wenn Codeblöcke existieren, welche der catch all Philosophie folgen, um die Ausnahme zu protokollieren. Wichtig ist nur, dass der Fehler an übergeordnete Schichten weitergeleitet wird. Hierzu ein Beispiel:

try


{

...

}

catch(
... )

{

...

}

catch(
Exception ex )

{

log.Error("Unbehandelte
Ausnahme", ex );

throw;

}

Im konkreten Beispiel wurde log4net verwendet. Wichtig für das Thema ist jedoch, das der rethrow-Mechanismus von .NET verwendet wird.

Wann sollen eigene Ausnahmen erzeugt werden

Eigene Ausnahmen sind sinnvoll, wenn diese ausserhalb eines Exception-Blocks geworfen werden. Sie testen beispielsweise ob die Parameter eines Methodenaufrufs innerhalb eines gültigen Wertebereiches liegen. Dann können und sollten Sie bibliotheks- und programmspezifische Ausnahmen werfen. Gern darf hier von vorhandenen Exceptions abgeleitet werden. Im konkreten Fall und unter .NET von einer ArgumentException.

Das Erzeugen einer eigenen Ausnahme innerhalb eines Exceptionblocks sollte wohl überlegt sein. Es erzeugt auf seiten des Nutzers zusätzlichen Aufwand, auslesen der InnerException, und macht somit den Grund der Ausnahme nicht vollends klar. Es ermutigt den Entwickler, die Programmsteuerung auf Basis von Ausnahmen vorzunehmen.

Sollte man sich dennoch für eigene Exceptiontypen innerhalb eines Exceptionblocks entscheiden, so muß unbedingt die eigentliche Exception, als InnerException, weitergeleitet werden. Andernfalls kann eine Fehlersuche sehr aufwändig werden.

Fazit

Die Ausnahmebehandlung ist ein wichtiger Bestandteil der Softwareentwicklung. Es bietet sich an, zu Beginn des Entwicklungsprozesses, nur wenige Ausnahmen zu behandeln. Im Verlauf der Entwicklung, durch Testen, werden die Gründe für Fehler klarer und können effektiver behandelt werden. Das Verstecken von Fehlverhalten nützt niemanden etwas, sondern führt zu nicht nachvollziehbaren Programmverhalten. Im schlechtesten Fall nach der Auslieferung eines Produktes.

Einlesen eines Konfigurationsbereiches

Wilko Waitz — Mon, 08 Jan 2007 08:51:05 GMT

Wenn eine ConfigSection mittels

System.Configuration.ConfigurationManager.GetSection("section")

eingelesen wird, ruft .NET den für die Section angegebenen Handler auf. Der Handler, welcher vom Typ IConfigurationSectionHandler ist, gibt lt. Schnittstelle ein Objekt vom Typ object zurück. Soweit so gut.

Wer nun denkt, das beim nochmaligen Aufruf von ConfigurationManager.GetSection(...) der Handler wiederholt aufgerufen wird, liegt falsch. Der ConfigurationManager gibt das selbe Objekt wie beim ersten Aufruf zurück. Man sollte vermeiden, irgendwelche Verlaufsdaten in diesem Konfigurationsobjekt abzulegen. Es kann sonst passieren das Daten ungewollt, über Sessions hinweg, gemeinsam genutzt werden.

Merksatz 1.0:
Die Section dient der Konfiguration von Geschäftsklassen und ist nicht selbst die Geschäftsklasse.