Thomas Woelfers Baustatik Blog

Baustatik-Software und was sonst des Weges kommt

TuneUpUtilities–Just say No!

Ich kann es gar nicht oft genug sagen: Installieren Sie die “TuneUpUtilities” NICHT. Ich hatte gerade mal wieder ein Gespräch mit einem Kunden, der das doch getan hatte. Leider Pech gehabt: Dieses “Tool” führt Änderungen an einer normalen Windows-Installation vor, die eindeutig zu Folgeproblemen, teilweise in größerem Umfang führen.

Im Beispiel heute konnte man das Installationsprogramm der Baustatik nicht einmal mehr starten. Dabei ist das Installationsprogramm nichts ungewöhnliches: Es handelt sich um ein stinknormales Windows-Installer MSI File – die komplette Installation wird vom Windows Installer durchgeführt. Nur eben nicht, wenn die TuneUpUtilities installiert sind.

Kaum waren die deinstalliert, lief alles so, wie man das erwarten würde. Darum nochmal: Hände weg von TuneUpUtilities. Wer das aber schon installiert hat: Einfach deinstallieren – vermutlich verschwinden dann diverse Probleme die man mit dem Rechner hat auch gleich mit.

Baustatik-Update: Leider noch ein Problem

Bei der Korrektur-Version die wir gestern veröffentlicht haben, trat leider auch ein Problem auf. Die Korrektur hatte eigentlich nur die eine Änderung, das einige der Programmdateien (i.b. der Timeserver) nicht mehr digital signiert waren. Trotzdem waren im zugehörigen Installationsprogramm defekte Datenbank-Tabellen enthalten. Ich kann mir das eigentlich nur mit einem nicht erkannten Festplattendefekt erklären – denn die zugehörigen Quelldateien waren unbeschädigt, und die daraus resultierenden Dateien in der Vorversion völlig ok. Nach dem erneuten Herstellen des Installationsprogramms verschwand das Problem auch wieder, ohne das irgendwelche Veränderungen vorgenommen wurden.

Wie dem auch sei: Ich habe gerade nochmal eine neue Version (140) veröffentlicht, bei der keine der Probleme mehr auftreten. Um sicherzustellen das auch das Installationsprogramm nicht beschädigt ist, habe ich auch dieses nochmal manuell auf einen anderen Rechner transferiert und getestet: Es sollte nun wirklich nichts mehr auftreten.

Für die Zukunft müssen wir uns offensichtlich noch einen Mechanismus einfallen lassen, mit dem nicht nur die Baustatik an sich mit Testfällen geprüft wird, sondern auch das Installationsprogramm dafür.

So wird man das Problem nach dem Update auf Version 138 wieder los

Durch die Installation des Updates auf Version 138 (vom 3.2.2016) kam es bei einigen Kunden zu einem Problem im Zusammenhang mit dem TimeServer und bei anderen im Zusammenhang mit den “alten” XFEMily Programmen.

Dummerweise ist das TimeServer-Problem etwas nervig: Der TimeServer stürzt beim starten ab, und wird dann immer wieder automatisch gestartet. Das macht es, falls der TimeServer automatisch gestartet wird, praktisch unmöglich ein weiteres Update zur Korrektur zu installieren. Man muss also den TimeServer aus der Autostart-Gruppe von Windows entfernen. Das ist allerdings je nach Version von Windows auf eine andere Art zu erledigen. Um die Sache einfacher zu gestalten, können Sie den folgenden Schritten folgen: Die beseitigen das Problem.

  • Deinstallieren Sie “DIE Anwendungen” über die Systemsteuerung
  • Wichtig: Starten Sie den Rechner jetzt neu
  • Laden Sie die aktuelle Version (139) aus dem Download-Bereich von www.die.de herunter
  • Installieren Sie diese Version

Danach läuft alles wieder wie gehabt.

Ich entschuldige mich für die Störung. Den eigentlichen Grund suche ich noch, diese Update behebt aber auf jeden Fall die störenden Symptome.

Betriebssystem-Update wäre jetzt notwendig

Die allermeisten der Baustatik-Anwender verwenden ein “aktuelles” Betriebssystem: Etwa 75% verwenden Windows 7 mit aktuellem Service-Pack, 24% verwenden Windows 81 und Windows 10, und nur 1% verwenden Windows XP oder Windows 8. (Und irgendwo gibt es auch mindestens einen Windows-Vista User…)

Das Windows XP schon seit langem von Microsoft nicht mehr unterstützt wird, darauf habe ich schon mehrfach hingewiesen: Wer noch immer XP benutzt, sitzt eigentlich auf einem einzigen großen Sicherheitsleck, denn es gibt seit langer Zeit keine Sicherheitsupdates mehr für XP, und es wird auch in Zukunft keine geben. Man sollte wirklich updaten.

Seit gestern ist aber auch der Support für Windows 8 ausgelaufen, und wer noch 8 verwendet, sollte schleunigst – mindesten auf 8.1 updaten. Das Update ist kostenlos und über den Windows-Store erhältlich. Mit 8.1 bekommt man dann auch wieder einen langjährigen Support von Microsoft: 8.1 wird bis 2023 unterstützt. Alternativ kann man auch kostenlos auf Windows 10 umsteigen – das gilt übrigens auch für die Windows Vista und Windows 7 Nutzer – in dem Fall gibt es Support bis ins Jahr 2025.

Ich empfehle:

  • Wenn Sie XP verwenden: Ein Update auf Windows 10 durchführen. (Vermutlich ist der Rechner dann auch schon recht alt – es könnte nicht schaden in dem Fall auch mal über neue Hardware nachzudenken.) Unabhängig davon: Sie erhalten bei XP auch keine Updates mehr von uns – und die neuen Baustatik-Versionen können einige sehr interessante Dinge, die man bei XP eben einfach nicht bekommt.
  • Wenn Sie Vista verwenden: Auf Windows 10 updaten
  • Wenn Sie Windows 7 (Mit SP1) verwenden: Man muss nicht zwingend tätig werden. Allerdings gibt es das Update auf Windows 10 zur Zeit noch kostenlos, aber das wird nicht so bleiben. Der Support wird 2020 beenden, mit dem Update auf 10 gewinnt man also außerdem noch 5 Jahre.
  • Wenn Sie Windows 8 verwenden: Auf jeden Fall auf 8.1, oder besser auf 10 updaten.
  • Wenn Sie Windows 8.1 verwenden: Es ist nicht dringend notwendig, etwas zu unternehmen. Es gilt aber auch, das man eben jetzt noch ein kostenloses Update auf 10 bekommt. Außerdem kann man mit 10 definitiv besser arbeiten, als mit 8.1. Ich würde daher updaten.

Details zum Support-Lebenszyklus von Windows finden Sie hier.

Umstellung bei der Infrastruktur

In nicht gerade regelmäßigen Abständen müssen wir bei uns Änderungen an der Infrastruktur vornehmen – und in den Weihnachtsferien dieses Jahr war unsere Revision Control System dran: Dabei haben wir nicht nur ein Update durchgeführt, sondern gleich auch das Produkt gewechselt. Das alte Vault wurde durch die Visual Studio Team Services (früher Visual Studio Online) ersetzt. (Über lang oder kurz werden wir wohl auch mit unserem Issue-Tracking System diesen Wechsel vollziehen.)

So ein Wechsel ist nicht ganz so einfach, denn es hängen viele Dinge direkt vom Repository ab: Zunächst mal arbeiten natürlich alle Entwickler damit – das ist ja der Kern der Sache: Neben der Versionsverwaltung (sowas haben Sie übrigens auch in der Baustatik) ermöglicht RCS eben auch die parallele Arbeit mehrere Entwickler am gleichen Projekt. Wechselt man also die Verwaltung, müssen auch die Arbeitsplätze aller Entwickler umgestellt werden. Darüber hinaus haben wir aber auch noch andere Dinge, die an das Repository angekoppelt sind. So wird zum Beispiel die online verfügbare Dokumentation der Baustatik einmal pro Tag automatisch auf den neues Stand gebracht: Jedesmal, wenn jemand bei uns eine Änderung an der Dokumentation vornimmt und diese ins Repository eincheckt, landet diese Änderung spätestens nach 24 Stunden auch automatisch auf unserer Webseite. Auch dieser Mechanismus musste also an das neue Tool angepasst werden.

Darüber hinaus haben wir ja auch noch die Testcases, mit denen wir jeden Tag (eigentlich jede Nacht) automatisch sicherstellen, das die Änderungen vom Tag nicht dazu geführt haben, das sich irgendwelche Ergebnisse ändern. (Es sei denn, es handelte sich um eine Korrektur, und sie sollten sich ändern Smiley ). Dazu gehören ein paar tausend Baustatik-Dateien, die natürlich auch im Revision Control System liegen – und alle internen Tools, die damit zusammenarbeiten, mussten ebenfalls angepasst werden.

Die Umstellung sollte nun aber eigentlich vollständig vollzogen sein – es wird zwar sicher noch die ein- oder andere kleine Störung geben, aber im großen und ganzen ist das nun abgeschlossen.

Was ändert sich dadurch für den Anwender? Nichts – außer, das wir nun ein etwas besseres Toolset haben, und damit hoffentlich (noch) schneller an Verbesserungen unserer Software arbeiten können…

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…