Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Wieso es so aufwendig ist, den Typ eines Querschnitts anzuzeigen


Heute hatte ich hier einen Vorgang, an dem man sehr schön ablesen kann, wieso einige Dinge länger dauern, als man annehmen würde. Außerdem ist es auch eine Art Bilderbuch-Designprozess: Alle Schritte sind leicht nachzuvollziehen – wie ich hoffe, auch für Statiker. Es wird allerdings ein bisschen technisch, ganz ohne Technik geht’s eben nicht.

 

Zur Vorgeschichte: Auf der Dialogbox im Faltwerksprogramm, in der man die Eigenschaften von Stäben einstellen kann, wird auch der Querschnitt des Balkens angezeigt. Nachdem der Querschnitt einfach ein Objekt ist wird er so angezeigt wie auch alle anderen Objekte im Programm: Mit seinem Namen. Nun ist es aber so, das der Name des Querschnitts nicht besonders aussagekräftig ist, denn der ist meist numerisch. Der erste Querschnitt heißt also „1“, der zweite „2“, usw.

 

Nun kann man natürlich für alle Objekte völlig beliebige Namen vergeben – nur ist es bei Querschnitten eben so, dass es hilfreicher wäre, wenn man den Typ des Querschnitts wüsste. Das Ding sollte also immer mit seinem Namen und seinem Typ angegeben werden. Also etwa „1 – IPE 80“.

 

Soweit also die Anforderung. Klingt total einfach – doch das täuscht.

 

Alle Typen (Knoten, Balken, Querschnitte, Materialien…) im Programm haben eine gemeinsame Basisklasse (d.h.: Sie haben ein gewisses Maß an gemeinsamer Funktionalität) und ein gemeinsames Interface. (Für Nicht-Programmierer: Interfaces spezifizieren die Syntax, die man braucht, um ein Objekt zu benutzen. Es legt die Funktionen und Eigenschaften fest, die das Objekt hat.)

 

Dieses gemeinsame Interface ist „IDocObject“ und besagt unter anderem, das alle Objekte eine Eigenschaft namens „ObjectName“ haben, mit der man an den Namen kommt. Für die Anzeige der Objekte auf Dialogen (und an anderen Stellen) gibt es nun ein Objekt namens „DocOb jectNameConverter“. Dieses Objekt kann ein IDocObject in einen String konvertieren – und einen String zurück in ein Objekt. Im ersten Fall bekommt der Converter das Objekt übergeben, und liefert dessen ObjectName zurück. Im zweiten Fall bekommt der Converter einen String (den Namen) und einen Typ und sucht dann in den aktuellen Eingabedaten nach einem Objekt vom richtigen Typ mit dem richtigen Namen, und liefert dieses dann zurück.

 

Nun ist es nicht so einfach diese Basisfunktionalität zu verändern: Die wird überall im Programm verwendet – eine grundlegende Änderung würde massive Umbaumaßnahmen zu Folge haben, und so etwas möchte man lieber verhindern.

 

Daraus resultierte die erste Überlegung: Man definiert ein neues Interface das „detaillierte“ Namen liefern kann. Dieses Interface können Typen dann optional implementieren: Die meisten Objekte braucht man also nicht anzufassen, die Querschnitte implementieren das neue Interface – und schon hat man den „detaillierten Namen“.

 

Nach einiger Zeit kam dabei das folgende Interface bei raus:

 

public interface IProvideDetailedName

{

   string DetailedName { get; }

   string NameFromDetailedName( string detailedName);

}

 

Es gab verschiedene andere Versuche bis genau dieses Interface herauskam: Sowas passiert nicht „zufällig“. Was tut nun dieses Interface?

 

Zunächst einmal haben Typen die es implementieren, eine DetailedName Eigenschaft: Die Instanzen der Typen können also einen ausführlichen Namen liefern „1 – IPE 80“. Die zweite Methode ist aber auch wichtig, denn nur damit kann man von einem detaillierten Namen auf den „echten“ zurückkommen. Hier das Szenario:

 

Der erste Teil ist einfach: Dabei wird die Combo-Box auf einem Dialog mit den Namen aller Objekte eines bestimmten Typs ausgefüllt. Dazu werden alle passenden Objekte eingesammelt und durch den DocObjectNameConverter in strings konvertiert. Beim konvertieren schaut der Converter, ob das übergebe Objekt das IProvideDetailedName Interface hat. Ist das nicht der Fall macht er so weiter wie früher. Gibt es das Interface aber, dann liefert der Converter eben den „DetailedName“ zurück. Pronto: Objekte mit dem Interface werden mit „ausführlichem“ Namen angezeigt, Objekte ohne nur mit ihrem „ObjectName“.

 

Wird nun in der Combobox etwas ausgewählt, muss der ausgewählte Text aber nun in ein Objekt konvertiert werden. Für die Combobox ist die Auswahl aber eben nur ein string – von eventuellen „Details“ weiss sie nichts. Außerdem ist auch nicht bekannt, wie der Implementierer von „DetailedName“ diesen Namen zusammensetzt: Es kann ja zum Beispiel „1 – IPE 80“, „IPE 80 (1)“ oder auch „IPE 80 – 1“ geliefert werden.

 

Das gesuchte Objekt ist aber nur unter dem Namen „1“ zu finden: Es braucht also einen Weg, um aus einem string von dem nicht bekannt ist wie er formatiert wurde, den reinen Namen zu gewinnen. Genau dafür ist NameFromDetailedName() zuständig. Derjenige, der DetailedName implementiert muss eben auch diese Funktion implementieren – dann kommt man auch an den Namen.

 

Damit wäre das Design abgeschlossen gewesen – wenn es denn richtig wäre. Ist es aber nicht. Grund: Beim konvertieren aus einem String und einem Zieltyp in ein Objekt hat man als Information eben nur das: Den string (der Name) und der Typ des gewünschten Objektes. Nun ist es aber so, das die Implementierung von IProvideDetailedName zum Beispiel im Querschnitts-Objekt vorliegt. Das bedeutet aber, dass man, um „NameFromDetailedName()“ aufrufen zu können, eine Instanz dieses Typs braucht. Die hat man aber nicht – man hat nur den Typ. (Damit könnte man natürlich eine Instanz synthetisieren – das ist aber im gegebenen Kontext aus verschiedenen Gründen auf die ich hier nicht weiter eingehe unschön und musste vermieden werden.)

 

Lange Rede kurzer Sinn: Das so schön geplante Interface mit allen dazugehörigen Überlegungen kann man schlicht und ergreifend nicht einsetzen.

 

Was es braucht ist eine Lösung die mit dem Minimalset an Informationen auskommt: Im Fall „konvertieren nach string“ hat man eine Instanz eines Objektes (und damit auch dessen Typ). Im Fall „konvertieren aus string“ hat man im Wesentlichen nur den Typ. Die Lösung muss also eine Implementierung sein, die mit dem Typ alleine auskommt.

 

Also geht’s zum zweiten Ansatz: Man definiert ein neues Attribut, das man an alle Typen vergibt, die einen detaillierten Namen haben sollen: HasDetailedNameAttribute. Das Attribut wird mit einem Parameter erzeugt, der Parameter ist der Typ eines Objektes, das den detaillierten Namen generieren kann, und das auch über die Möglichkeit zur Umwandlung eines detaillierten Namens in einen einfachen verfügt.

 

Im Wesentlichen lagert man also die Erzeugung/Umwandlung des detaillierten Namens in einen externen Typ aus, und erzeugt dann eine Verbindung zwischen diesem externen Typ und dem eigentlichen Typ (Querschnitt) indem man dem Querschnitt ein entsprechendes Attribut gibt.

 

Der DocObjectNameConverter kann dann nachsehen, ob der Typ des zu konvertierenden Objektes (oder der Typ des Zieltyps) ein solches Attribut hat. Ist das der Fall, dann kann er die Instanz des Attributes verwenden, um den passenden externen Konverter zu ermitteln – und den dann die Arbeit tun lassen.

 

Und siehe da: Hier liegt nun tatsächlich ein Design vor, das funktioniert.

 

Es gäbe noch ein drittes, das mit anderen Mechanismen ebenfalls funktionieren würde: Man stellt die Verbindung zwischen dem Typ (1) und dem Typ für die detaillierten Namen (2) her, indem man (2) als Singleton anlegt, der sich im Zuge der Konstruktion bei einem SingeltonManager anmeldet – und sich als zuständig für Typ (1) ausweist. Danach kann man einfach den Singleton-Manager nach einem Umwandler für (1) fragen – wenn man keinen bekommt, dann gibt’s keinen und der „bisherige“ Weg der Namensbildung kann verwendet werden.

 

Was lernt man nun daraus?

 

  1. Ich bin unheimlich geschwätzig.
  2. Bevor man sich an ein Design setzt muss man sich überlegen ob sich die neue Funktionalität mit Typen oder mit Instanzen beschäftigt.
  3. Alles ist viel komplizierter als es beim konsumieren einer bestimmten Funktionalität aussieht.

Mehr als Dübel: Fischer hat nun auch ein Blog


Fischer (-Dübel, -Technik, etc. pp.) hat eine eigene Unternehmensgruppe für Befestigungssysteme. Und die will nun auch Teil der Blogospähre werden. Nicht viele Firmen haben ein funktionierendes Unternehmensblog, und aus dem Bereich der Befestigungstechnik kenne ich gar keine Firma, die so einen Versuch gestartet hat. Mutig sind sie also, die Leute bei Fischer.

Und die ersten Beiträge sind, wenn auch ein wenig unpersönlich, fachlich interessant und mit viel Liebe bebildert und verlinkt. Als Autoren treten unter anderem auf: Dipl.-Ings, Bautechniker, Web-Designer und Wirtschaftsinformatiker.

Hier zu finden: Das fixingBlog. Abonniert.


LEO: Eine wirklich hilfreiche Webseite


Vom Bereich Informatik der TU München gibt es schon seit geraumer Zeit eine sehr hilfreiche Webseite: Das Wörterbuch

Im Wesentlichen findet sich dort ein Formular in das man ein englisches oder deutsches Wort eingeben kann, und Leo liefert dann die Übersetzung. Und das klappt vor allem auch mit technischen Begriffen richtig gut: Ich weiss gar nicht, wie lange es her ist, das ich das letzte Mal ins Oxford Advanced reingesehen habe.


Happy Birthday Website


Dieses Jahr wird www.die.de 10 Jahre alt. Ich kann mich nicht mehr an das genau Datum erinnern, meine aber das die erste Version von www.die.de irgendwann im Frühjahr 1996 ans Netz ging. Wie die Zeit vergeht! Menschen mit eMail-Adressen wurden eher bestaunt als erreicht, Software wurde auf Floppy-Disketten ausgeliefert und Internetzugänge waren rar und, wenn vorhanden, analog. Ich habe auch keine Statistiken mehr über 1996, kann mich aber noch gut dran erinnern, das ich regelmäßig die Logfiles des Servers nach Seitenabrufen untersucht habe. Per Hand - es können also nicht gar so viele Abrufe gewesen sein. Im Juli 2003 - von da stammt die erste Zahl die ich noch reproduzieren kann, waren es aber bereits knapp 10.000 Seitenabrufe. (Im Januar 06 über 80.000). Wer mal einen Blick in die Webvergangenheit werden will, der kann das bei der WayBackMachine: Dort gibt es Schnappschüsse auch von www.die.de aus den letzten 10 Jahren.

Momentan offenbar beliebt: Wörterbuch-Attacken


Bei einer Wörterbuch-Attacke versucht der Angreifer auf eine automatisierte Methode in einen fremden Rechner einzudringen. Dabei probiert ein Programm einfach so lange Benutzernamen und Passworte aus, bis eine passende Kombination gefunden wurde. Das hört sich irgendwie ein bisschen nach einem Filmstoff an, der in der Praxis nicht vorkommt - aber wer so denkt, der irrt. Auf einem Rechner den ich nebenher ein bisschen betreue, sieht es seit einigen Woche so aus:

attacke.png

Im Schnitt gibts alle 4 Sekunden einen neuen Versuch: Irgend jemand ist da wirklich sehr hartnäckig. Letztlich bestätigt das aber eine altbekannte Tatsache: Es ist kein besonders gute Idee, als Benutzernamen oder Passwort einen Text zu verwenden, der in einem Wörterbuch vorkommen kann. Oder in sonst einer Liste aus Texten - im Fall meines "Besuchers" offenbar einer Namensliste.


Award for Customer Excellence


Offenbar bin ich ein exzellenter Kunde für Microsoft: Heute kam ein mittelgroßes Paket per DHL aus Amerika. Darin befand sich ein kleiners Paket und darin ein noch kleinerers Paket. Und darin war das hier:

DSCN1014.JPG

Das ist der "Award for Customer Excellence". Microsofts Somasegar bedankt sich damit for beeing a great contributor to Microsoft Visual Studio 2005 and the .NET Framework 2.0.

Nett ist das schon - wir hatten weiss Gott jede Menge Ärger mit dem Beta und auch bereits mit dem Final. Aber so ein Glasklotz entschädigt ja für vieles :-)


Eine wirklich schöne Tastatur


Ich habe nun seit ein paar Monaten meinen neuen Rechner - und der hat auch eine neue Tastatur. Nun ist es mit Tastaturen ja so eine Sache: Ich muss wirklich damit zufrieden sein, denn schließlich sitze ich jeden Tag mindestens 10 Stunden davor. Bin da wirklich ein wenig wählerisch. Und mit der, die ich momentan benutze bin ich wirklich extrem zufrieden - es verwende das Labtec ultra-flat keyboard. Dabei handelt es sich um eine ganz normale Tastatur, die einen ähnlichen Anschlag wie meine Laptop-Tastatur hat: Das war der eigentliche Grund für die Auswahl.

Das Ding hat aber etwas, was ich bei vielen anderen Tastaturen schon in wesentlich schlechteren Ausführungen gesehen haben: Spezielle Media-Sondertasten. Andere Tastaturen haben auch sowas: Damit kann man dann zum Beispiel die Lautstärke vom Mediaplayer ändern, oder zum nächsten Musikstück vorspringen. Allerdings kannte ich bisher nur zwei Geschmacksrichtungen davon: Die eine Sorte macht das mit Multifunktionstasten. Das bedeutet, das man eine Taste drücken kann - und die reagiert zum Beispiel wie ein Druck auf "F1", oder aber, sie tut was ganz anderes - zum Beispiel die Lautstärke senken. Welche der beiden Funktionen ausgeführt wird ist dann wieder davon abhängig, ob man vorher eine andere Taste gedrückt hat oder nicht.

Die zweite Geschmacksrichtung die ich bisher kannte war die Wir-Haben-N-Frei-Programmierbare-Tasten Sorte. Dabei handelt es sich um Tastaturen die zusätzliche Tasten haben, die man ganz nach Wunsch mit beliebigen Funktionen belegen kann - allerdings zu einem Preis. Und zwar zu dem, das man dafür irgendeine obskure Software vom Hersteller installieren muss. Nun gehören Tastaturhersteller von Haus aus nicht unbedingt in die Gruppe der besonders tollen Softwarehersteller: Darum stellen die ja wohl auch Tastaturen her. Ich würde Tastaturhersteller zum Beispiel in eine Schublade mit Grundig oder Sony/BMG werfen, was die Herstellung von Software angeht. Kurz gesagt: Von solchen Herstellern lasse ich garantiert keine Software auf meine Workstation.

Naja - und mit dem Labtec Gerät kenne ich nun noch eine dritte Geschmacksrichtung: Das Ding hat 9 Sondertasten. Die sind mit den typischen Symbolen beschriftet die man von CD-Playern kennt: Lauter, Leiser, Start/Stop, und so weiter. Und die Tasten tun auch genau das - und sonst nichts. Keine Umschalttasten, keine zusätzliche Software die man installieren müsste... nichts: Man steckt das Ding einfach ein und es tut seinen Dienst. Bin begeistert, auch wenns ein paar Monate gedauert hat, bis ich das gemerkt habe. :-)


Das Kreuz mit der Suche


Auf www.die.de befinden sich einige tausend Dokumente, mit lauter Inhalten rund um die Baustatik und unsere Statikprogramme. Eine zeitlang haben wir versucht, die MSN- und die Google-Suche dafür einzusetzen. In beiden Fällen hat sich aber nach einigen Wochen herausgestellt, das die Searchengines einfach nicht gut genug funktionieren: Einige Texte von denen wir wussten, das Sie auf der Seite vorkommen, wurden erst gar nicht gefunden. Bei anderen wurden falsche Dokumente - teilweise auch nur weniger relevante - als Resulat geliefert. Alles in allem einfach nicht das, was wir uns für die Suche auf www.die.de vorgestellt hatten.

Jetzt sind wird wieder beim Microsoft Index Server angekommen. Der Index-Server ist bei den Windows-Servern (und auch bei XP Pro) von Haus aus dabei, und kann eine Vielzahl von Dokumenten indizieren, und diese so durchsuchbar machen. Das klappt auch mit den "normalen" Inhalten auf www.die.de ganz gut. Dazu zählen die Programmbeschreibungen, die Tutorials, die Liste der häufig gestellten Fragen und andere Dokumente.

Nicht besonders gut klappt die Sache aber mit den Blog-Einträgen. "dasBlog", so heist die Software die wir hier verwenden, legt die Blog-Einträge in XML-Dateien ab. Wird ein Eintrag angefordert, das liest "dasBlog" die zugehörige XML-Datei aus, und stellt den darin abgelegen Inhalt dar. Davon weiss der Index Server natürlich nichts: Für ihn handelt es sich bei XML-Dateien von Haus aus einfach nur um Textdateien. Die indiziert er - und wenn man dann darin sucht, dann erhält man recht merkwürdige Resultate: Nämlich das XML mit allem drum und dran, statt den eigentlichen Inhalt.

Dankbarerweise kann der Index-Server aber auch erweitert werden, und zwar mit dem IFilter-Interface. Wie das im einzelnen geht, wäre an dieser Stelle ein bisschen zu technisch. Im Wesentlichen läuft es aber darauf hinaus, das man eine DLL installiert, die für das indizieren spezieller Dateitypen zuständig gemacht wird. Die DLL ist dann dafür zuständig, den Index-Server mit "vernünftigen" Daten zu versorgen. Der Server schaut also selbst nicht länger in eine Datei hinein, die von einem IFilter betreut wird.

Von diesen IFiltern gibt es eine ganze Menge. Ich hatte mir zunächst überlegt, für unseren Fall - also für die dasBlog XML-Dateien - einen eigenen IFilter zu programmieren, stellte dann aber fest, das es bereits einen fertigen gibt. Der tut (fast) genau das, was man fürs durchsuchen von "dasBlog" benötigt - und kostet auch nicht besonders viel. Darum nehmen wir seit gestern den IFilter von QuiLogic.

Die Suche auf der Startseite von www.die.de. liefert nun wieder "vernünftige" Ergebnisse - und sucht auch in den Blogeinträgen.