Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Frohes neues Jahr


Ich wünsche allen Kunden, Anwendern und Lesern ein gutes und erfolgreiches 2016 – haben Sie ein tolles Jahr !

(Dieses Posting wurde aufgezeichnet: Bin momentan noch in Urlaub)


Zum Jahresende


Die Feiertage nähern sich rapide und das Jahr hat bald ein Ende… Eine gute Zeit für einen Rückblick auf das vergangene Baustatik-Jahr – und einen Ausblick auf das kommende.

Das ist passiert

Bei der Baustatik hat sich in diesem Jahr eine ganze Menge getan. Die wichtigsten Dinge waren dabei wohl die folgenden:

  • Erhebliche Erweiterungen beim Export nach VCMaster
  • Support für die Datenermittlung (Wind/Schneelasten) von Basis von Postleitzahlen
  • Der Dach-Designer “kann” nun auch Satteldächer
  • Support für den Export der Ausgabe im .docx Format für aktuelle Word-Versionen
  • Windows XP wird nicht länger unterstützt
  • Erhebliche Erweiterungen beim Export nach DXF
  • Die Updates werden nun vollautomatisch verteilt und in den meisten Fällen ohne zutun des Anwenders installiert
  • Platte und Faltwerkselemente können nun auch im Zustand 2 berechnet werden.
  • Es gibt nun eine automatische Lastweiterleitung
  • … und natürlich ist noch vieles mehr passiert. Die gesamte Liste findet sich im Update-Protokoll.

Und natürlich werden wir auch im nächsten Jahr mit Volldampf weiterarbeiten. Die nächsten größeren sichtbaren Spuren werden folgende sein:

  • Erheblicher Ausbau der Lastweiterleitung: Es soll von und nach allen Dokument-Arten weitergeleitet werden, bei denen das Sinn macht.
  • Erheblicher Ausbau der Kommunikation mit Word: Man wird eigene Word-Dokumente und Deckblätter in den Ausdruck mit einfließen lassen können, und auch insgesamt an der Formatierung mit Word besser Hand anlegen können.
  • Integration von bisher fehlenden Dokument-Typen: Zunächst wird es in der Baustatik dabei Ersatz für die Querschnittsprogramme geben.

Nachdem ich ab in Kürze bis vermutlich zum 6.1.2016 nicht mehr im Büro sein werde: Ich wünsche schöne Feiertage, einen guten Rutsch und ein tolles und erfolgreichen 2016 !


So behalten wir unsere Test im Auge


Ich habe ja schon hin- und wieder darüber berichtet, das wir jede Nacht eine 32bit und eine 64bit Version der Baustatik auf Basis des aktuellen Entwicklungsstandes herstellen, und dann mit diesen Programmversionen eine Vielzahl an Dateien komplett durchrechnen – und die Ergebnisse dieser Berechnungen dann mit Referenzdaten vergleichen. Sinn der Sache ist es sicherzustellen, das eine durch die Weiterentwicklung entstandene Veränderung am Programm sich nicht auf die berechneten Ergebnisse auswirkt. Oder wenn, dann eben nur, weil das vom Entwickler auch gewünscht war.

Zur Zeit berechnen wir dabei pro Version ca. 3500 Eingabedateien (also insgesamt 7000). Und pro Datei gibt es dann natürlich noch jede Menge unterschiedlicher Ergebnissarten – und die an jeder Menge Stellen. Also zum Beispiel alle Auflagerkräfte für alle Lastfälle und Überlagerungen, aber eben auch alle Verformungen und Bemessungsergebnisse aller Faltwerkselemente in allen FE-Punkten. Mit einem Wort: Das sind echt viele Zahlen. Viele.

Und so machen wir das…

Zunächst mal haben wir 2 virtuelle Hyper-V Maschinen im Betrieb, beide mit installierter Quellcodeverwaltung und Visual Studio. Auf beiden werden abends Jobs angestoßen, und diese Jobs tun folgendes:

  • Aktuellen Quellcode runterladen
  • Programmversion herstellen (die eine virtuelle Maschine die 32bit Version, die andere die 64bit Version)
  • Aktuelle Testdateien runterladen
  • Für alle Testdateien alle möglichen Ergebnisse berechnen und protokollieren
  • Alle Ergebnisse mit den Referenzergebnissen vergleichen und eventuell aufgetretene Unterschiede protokollieren

Alles was protokolliert wird landet in einer Datenbank (in Azure), und dafür wiederum haben wir eine (interne) Webseite, mit der man sich die Daten ansehen kann. Die liefert zunächst mal eine Übersicht, aus der hervorgeht, welche Version überhaupt gebaut werden konnte, wo Testläufe durchlaufen wurden, und wo Testläufe fehlschlugen:

image

Im Fall eines Fehlschlags kann man auf den Testlauf klicken und bekommt eine Übersicht über diesen Testlauf. In dieser Übersicht sieht man dann auch schon, in welchem Bereich der Fehler lag:

image

Dort kann man dann wiederum auf den Fehler klicken und bekommt alle Details dazu, was genau nicht geklappt hat:

image

Danach kennt man also schon mal die Dokumente, bei denen es ein Problem gab und eine Zusammenfassung des Fehlers. Klickt man nun noch auf die Datei, gibt es auch (zum Teil etwas kryptische) Informationen darüber, welcher Teil der Berechnung genau nicht geklappt hat – und was genau der Fehler war:

image

Wenn man nicht ganz so tief in die Details gehen will, dann gibt es natürlich auch etwas höher angeordnete Statistiken, zum Beispiel wie viele Testläufe durchlaufen wurden, und wie lange das gedauert hat. (Wenn sich hier was ändert, dann ist zwar nichts wirklich falsch – aber langsamer werden soll die Sache natürlich auch nicht):

image

Insbesondere bei der Zeit sind kleinere Unterschiede aber zu erwarten, das bringt schon allein die Verwendung der virtuellen Maschinen mit sich: Wenn der physische Rechner in dem die sich befinden gerade etwas “interessantes” tut – also zum Beispiel ein automatisches Update einspielt – dann verändert sich die Performance der virtuellen Maschine darin – und darum kommt es zu anderen Laufzeiten. Die sollten aber immer nur gering sein – sonst stimmt mit dem Programm etwas nicht.

Und das ist im großen und ganzen die Methode, mit der wir die Übersicht über unsere Test – und das Verhalten der Baustatik – behalten: Viele, viele, viele Daten – in hübsche Graphiken verpackt. Eigentlich genau so, wie die Baustatik selbst Smiley


Blogs nun auch mit SSL


Wir haben die Umstellung unseres Web-Angebotes auf SSL nun abgeschlossen: Das letzte Problem waren unsere Blogs. Die hatten zwar schon SSL, aber es gab ein Restproblem mit der Blog-Software. Bei der erfolgt die Anzeige aller Bilder nämlich über einen Bilder-Handler. Das bedeutet im wesentlichen, das das Bild nicht direkt als Quelle im IMG-Tag angegeben wird, sondern es wird statt dessen der parametrisierte Handler aufgelistet. Und der ist – zumindest in der Version die wir verwenden- fest kodiert, und zwar mit einer HTTP-URL.

Nun habe ich damals beim einrichten der Blog-Webseite den Fehler gemacht das ganze nicht auf dem Quellcode der Blogsoftware beruhen zu lassen (was gegangen wäre), sondern ich habe die Binäre Distribution verwendet. Das war damals einfacher, macht aber heute Änderungen schwieriger. Mit der Quellcode-Variante hätte man das Programm einfach so ändern können, das es eine HTTP-UPR ausgibt, bei der binären Variante geht das aber leider nicht.

Darum produzierte das Blog weiterhin fröhlich Webseiten, die zwar per HTTPS erreichbar waren, aber ihrerseits Referenzen auf HTTP-URLs verwendete. Wegen diese Referenzen wurden die Blog-Beiträge darum von allen Browsern als nicht vollständig sicher eingestuft (zu Recht) – und die Adressleiste enthielt darum auch nicht die “grüne” Farbe bzw. das Schloss-Symbol, mit dem die sichere Verbindung gekennzeichnet wird.

Das ist aber nun geklärt- und auch die Blog-Seiten und Beiträge sind vollständig per SSL erreichbar. (Anders als auf der normalen Webseite www.die.de erzwingen wir aber zur Zeit die sichere Verbindung nicht: Wer will, kann also noch “unsicher” surfen.)

Wer sich für die technische Lösung interessiert: So haben wir es gemacht….

Das wesentliche Problem ist, das das ASP.NET Programm das HTML erzeugt, das dann, wenn alles fertig ist, an den Client geschickt wird. Am eigentlichen Prozess der HTML-Erzeugung konnten wir nichts beeinflussen. Man musste das HTML also verändern, nachdem es von der Blog-Software erzeugt wurde, und unmittelbar bevor es an den Client gesendet wurde.

Das ist aber bei ASP.NET kein Problem: Dazu muss man nur ein IHttpModule  implementieren und in web.config eintragen. Die Implementierung ist in diesem Fall trivial: Im “Init” hängt man einen Eventhandler an das PostRequestHandlerExecute Event. Dort, falls es sich beim “CurrentHandler” um die Page handelt, hängt man an den Response-Filter einen neuen Filter.

Der Filter erbt von Stream und muss die gängigen Methoden überladen, die einzig wichtige ist aber “Write”. Dort hat man den kompletten Puffer mit dem HTML, und kann dort – in diesem Fall – den Text einfach mit string.Replace() ersetzen, und dann das eigentliche Write aufrufen.


“Alte” Dokumentation wieder verfügbar


Die Programmdokumentation für die “alten” XFEMily-Programme wurde vor einiger Zeit vom Webserver entfernt. Es gab danach vereinzelte Anfragen nach dieser Doku – zwar wirklich nur seltene Fälle, aber gegeben hat es sie… Darum: Ab sofort ist die “alte” Dokumentation wieder über unseren Webserver erreichbar. (Ab dem nächsten Update wird diese URL auch von der Hilfe in den alten Programmen verwendet.)


Infrastruktur in der Cloud


Wir haben einen Teil der Arbeitszeit des letzten Monats dafür verwendet, praktisch die gesamte IT der Geschäftsführung in die Cloud zu verlegen: Alle Datenbankserver, Datenbanken sowie die Vorlagen für Schriftstücke und der Briefverkehr befinden sich nun auf Servern in Microsofts Azure.Natürlich gibt es noch lokale Workstations – aber die Daten mit denen gearbeitet werden liegen nur noch in Form von Sicherheitskopien im Büro vor, die eigentliche Arbeit wird mit Cloud-Servern durchgeführt.

Schon davor hatten wir ja Teile der Infrastruktur in der gleichen Art ausgelagert: Webserver, Webservices und alles was sonst noch an www.die.de (und blogs.die.de ) dranhängt läuft schon seit einiger Zeit in Azure.

Seit ein paar Tagen passiert diese Umstellung auch mit der Infrastruktur für die Entwicklungssysteme. Ein großer Teil unserer Quellcodeverwaltung ist bereits umgezogen (eigentlich alles, außer der eigentlichen Baustatik – da braucht es noch ein wenig weitergehende Vorarbeiten), und seit Ende letzter Woche werden auch die Daten aus allen unseren Testcases (das sind im wesentlichen ca. 6000 mit der Baustatik berechnete Systeme pro Nacht) in Azure SQL aufbewahrt, statt bisher lokal.

Der nächste Schritt ist das auslagern der Build-Servers, der für die Herstellung der tatsächlich ausgelieferten Version der Baustatik zuständig ist: Auch der ist seit heute nicht mehr Teil unserer lokalen Infrastruktur, sondern läuft ebenfalls in einer virtuellen Maschine in Azure.

image

Auf unsere Kunden sollte all das keine Auswirkungen haben – außer, das wir uns mehr auf Entwicklung und Support konzentrieren können, statt unsere IT Infrastruktur zu warten: Das macht ab sofort Microsoft für uns Smiley


64bit–warum umstellen?


Nur noch etwa 10% der Rechner unserer Kunden sind 32bit-Systeme, alle anderen laufen mit einer 64bit Windows-Variante. In diesem Kontext habe ich mir heute ein paar Telemetriedaten aus Fehlermeldungen angesehen und dabei was interessantes festgestellt: Diese 10% der Rechner produzieren etwa 40% aller bei uns gemeldeten Fehler im Programm – und in nahezu allen Fällen handelt es sich um Fehler, an denen wir nichts ändern können. Und ändern können wir darum nichts, weil diese Fehler fast alle darauf zurückzuführen sind, das dem Programm der Speicher ausgeht.

Manchmal sind es tatsächlich ganz einfach zu große Systeme, also welche, die mit der unter 32bit zur Verfügung stehenden Speichermenge einfach nicht mehr gerechnet werden können. Manchmal laufen neben der Baustatik noch diverse andere Programme, sodass diese auch für eine kleineres System einfach nicht mehr genügend Speicher vom Betriebssystem bekommt. Und in anderen Fällen gehen einfach die Window-Handles aus, obwohl eigentlich noch genug Arbeitsspeicher zur Verfügung stehen würden: Der Wechsel von 32 auf 64bit entfernt deutlich mehr Einschränkungen, als die reine Menge an Arbeitsspeicher.

Wir beantworten natürlich auch die Fehlermeldungen die aus Einschränkungen bei der Verwendung der 32bit Version resultieren – nur ändern können wir nicht wirklich was: Das muss der Anwender selbst tun, und zwar durch den Wechsel zu einer modernen 64bit Version von Windows Smiley . Und das möglichst schnell…


Ein paar hilfreiche Links


Hier ein paar hilfreiche Links, wenn es Problem bei der Installation von Software gibt – ganz allgemein, aber heute aufgekommen, weil ein Kunde ein genau passendes Problem hatte:

Das .NET Framework Repair Tool

FixIT für Probleme bei Installation und Deinstallation

Manuelle Reparatur des Windows-Installer Dienstes

In meinem speziellen Fall lag folgendes vor: Beim installieren der Baustatik funktionierte zwar der Teil, mit dem die vorliegende Installation beseitigt wird, aber der Teil, der die aktuelle Version installieren sollte brach beim Versuch den BaustatikUpdateService zu installieren mit der Meldung ab: “Auf den Windows Installer Dienst konnte nicht zugegriffen werden”.

Die Meldung bedeutet aber nicht unbedingt, das der Windows-Installer ein Problem hat. In meinem Fall war es so, das der Installer seinerseits einen Dienst installieren und starten sollte – den BaustatikUpdateService – aber das nicht gelang. Nun ist der “installieren” Teil davon unaufwendig, es wird einfach nur eine einzelne Datei kopiert. Das “starten” sollte in der Theorie auch einfach sein – dazu wird das Dienstprogramm gestartet und in der Registry als Dienst eingetragen.

Und genau dieser Schritt ging nicht. Nun ist es so, das der Start des Programms eigentlich nur aus 2 Gründen nicht klappen kann: Entweder, das Binary an sich ist kaputt – was im vorliegenden Fall unwahrscheinlich war – oder eine Abhängigkeit davon ist defekt. Die Abhängigkeit ist in diesem Fall der Service-Installer des .NET Frameworks, und genau daran lag es dann auch: Das NetFxRepairTool reparierte die Registrierung dafür, und danach klappte die Installation dann auch.