Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Convert FugBugz cases to Visual Studio Online workitems


We have been using FogBugz for several years and actually have been quite happy with it. Recently, i wanted to switch to FogBugz On Demand which is a managed service offering the same functionality. They advertise 18$/month for up to 5 users, which would have been sufficient for our needs. So i asked for a quote and let’s just say i wasn’t very happy with their response. Displeased, actually.

So instead i decided we’d use the bug/issue tracking system that comes with Visual Studio Online (Visual Studio Team Services), and which is free for up to 5 users. Of course we needed to move our data from the FogBugz database to VSO. Which, it turned out, isn’t all that hard. I’ve written a little program that does that conversion. Worked for us, should work for you, just don’t expect any error handling or suchlike.

So in case you’d also want to move off of FogBugz and into VSO: Grab the code here. It’s a VS 2015 solution and you’ll need to restore the packages before you can build it. Also, you’ll find some // TODO: parts. Those are in there to tell you what you need to do in order to make this use your credentials, your areas and suchlike.

Enjoy!


Kommende Attraktionen: Lastweiterleitung ins Fundament


Im nächsten Update wird das recht sicher drin sein: Die Lastweiterleitung ist dann so erweitert worden, das man auch Lasten ins Fundament weiterleiten kann.

image

Anders als bei den bisher bekannten Varianten kann man sich allerdings schon bei der Schnelleingabe für den Import aus einer Stütze entscheiden:

image

Die von den schon existierenden Varianten bekannte Methode mit der Definition eines Lastimport-Objektes gibt es aber natürlich auch.


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.)


Änderungen bei den Makros


Die Baustatik konnte man schon vom ersten Tag an mit selbst programmierten Makros erweitern: Das bietet sich zum Beispiel dann an, wenn man immer wieder sehr ähnlich Bauteile berechnet, bei denen sich nur wenige Parameter ändern – zum Beispiel Hochregal-Systemlager. Andere Kunden gehen da sogar deutlich weiter, so existiert beispielsweise ein Makro, das automatisiert die Berechnungsergebnisse der Platte in eine Datei exportiert, die vom CAD-System ZEIG gelesen werden kann.

Allerdings hat sich an den Makros auch nicht besonders viel getan. Bis jetzt: Denn ab dem nächsten Update gibt es eine völlig neue Makro-Umgebung. Das betrifft sowohl das Fenster zur Auswahl der auszuführenden Makros, als auch den Makro-Editor selbst.

image

Das beste Werkzeug zum bearbeiten von Makros ist weiterhin Visual Studio – aber zum schnellen bearbeiten oder für kurze Korrekturen gehts mit dem Editor eben einfach schneller.

Und das ist neu am Editor:

  • Es gibt nun keine “merkwürdigen” Dialoge zum anlegen oder öffnen von Makros mehr. Statt dessen gibt es die ganz normalen Windows-Fenster zum öffnen und speichern von Dateien.
  • Es gibt nun Undo und Redo
  • Es gibt ein ganz brauchbares Syntax-Highlighting für den C# Makro-Code.
  • Funktionale Blöcke können “gefaltet” werden:
    image

    image
  • Es gibt (endlich) eine gut funktionierende Zwischenablage
  • Man kann das Makro nun auch ausdrucken (auch mit Druckvorschau)
  • Und schließlich werden Fehlermeldung vom Compiler nun besser markiert.
    image

Insgesamt ist eigentlich alles nun deutlich aufgeräumter als zuvor: Das etwas merkwürdige Config-File für den Editor und den Compiler wird nicht länger benötigt – und bei der Gelegenheit haben wir auch die beiden mitgelieferten Beispielmakros an den neuesten Programmstand angepasst und wieder lauffähig gemacht.

Insgesamt sicher keine Aufwertung für viele Anwender – aber für alle, die diese Funktionalität verwenden, ganz sicher eine dramatische Verbesserung.


Neue Version der Programmierer-Referenz


Alle Kunden die Makros für die Baustatik schreiben konnten bisher auf die Programmierer-Referenz auf unserem Münchner Webserver zugreifen. Allerdings war die Referenz schon etwas in die Tage gekommen (das Material wird bei weitem nicht so oft upgedatet wie das Programm selbst).

Es gibt nun aber endlich eine neue Version davon, zu finden unter der bereits bekannten URL http://muenchen.die.de/API/.

Nun ist es so, das diese aktuelle Referenz deutlich umfangreicher ist als die alte – und darum vielleicht auch ein bisschen unübersichtlicher. Wir haben die alte darum aufgehoben: Wer die lieber mag, findet sie unter dieser URL: http://muenchen.die.de/APIold/


Kundenmakro: Export von AS-Werten nach ZEIG


Vom Ingenieurbüro Balster gibt es ein neues Makro für die Baustatik – um genau zu sein: Es gibt ein Paket das aus einem Baustatik-Makro und Prozeduren für unser CAD-System Zeig besteht.

Exportiert werden die berechneten AS-Werte aus der Baustatik, und importiert werden die dann nach ZEIG, und dort “halb” automatisch zu Bewehrungsplänen weiterverarbeitet.

Folgendes passiert (Beschreibung von Herrn Hobbensiefken, von dem das Makro stammt. Er ist auch bereit darüber hinaus im gewissen Umfang Fragen dazu zu beantworten):

1. Es werden nur die Bewehrungsdaten der ersten Bemessungsgruppe übergeben.
2. Automatisch erzeugte Bemesungsergebnisse werden nicht erfasst.
3. Das Export-Makro ist nicht fehlertolerant, soll heißen: o.g. Bedingungen werden nicht überprüft.
4. Die VEC-Datei mit den Bewehrungsdaten wird im Ordner der Xfalt-Berechnungen abgelegt (keine Auswahlmöglichkeit)
5. Die Bewehrungsrichtungen werden in der VEC-Datei als Layer abgelegt (asxu - 11, asxo -12, asyu -13, asyo -14, asw -15)
6. Für die automatische Erstellung der VEC-Datei wird der Zeig-Bildschirm-Maßstab auf 1:100 und der Zeig-Plot-Maßstab aus 1:50 festgelegt.


Zur Bearbeitung der Daten unter Zeig dient die Prozedur ASXYAB.PRC unter folgenden Bedingungen:

1. Die Datei mit den Bewehrungsdaten wird in eine VEC-Datei (z.B. zu bewehrender Grundriss) in die Detail-Ebene geladen.
2. Der Grundriss enthält vor dem Zuladen noch keine Detail-Ebene.
3. Die Funktionsweise unter Zeig auf Basis PicturesByPC Version 3.2 ist noch nicht getestet.


Die Arbeit mit den eingelesenen Bewehrungsdaten erfolgt momentan händisch über die Kommandoeingabe.

Nach dem Zuladen der Bewehrungsdaten in die Detailebene eines Grundrisses sind normalerweise alle Layer (11 - 15) der Bewehrungsdaten aktiv und die Texte stehen übereinander. Die Größe der Bewehrung wird als Text angezeigt. Der Startpunkt des Textes (ma ....  - Zeichenbefehl im Edit der VEC-Datei) ist die Lage des gerechneten Bewehrungspunktes. Die Farbe der Texte (6 - magenta) darf nicht verändert werden, da die Zeig-Prozedur in ihrer Funktion darauf abgestellt ist.

Mit den Befehl 'ly' können die gewünschten Layer ein- und ausgeschaltet werden. "ly -d 11..15" schaltet alle Bewehrungslayer aus. Mit "ly -e 11" kann Layer 11 (asux) wieder sichtbar geschaltet werden.
Der einfache Aufruf von "ly" öffnet den Layer-Dialog und die gewünschten Layer können im Dialog an/aus geschaltet werden.

Die Prozedur 'asxyab.prc' erstellt bei der ersten Benutzung der Bewehrungsdaten eine Sicherung der Bewehrungsdaten, sodass mit 'asxyab -u' der Anfangszustand wieder hergestellt werden kann, egal wieviel Operationen bis dahin ausgeführt worden sind. Mit 'asxyab -f (Skalierung) kann die Textgröße der Bewehrungsdaten prozentual geändert werden, dabei bedeutet z.B. 'asxyab -f 1.2', dass die Texte um 20% vergrößert werden.
Wird z.B. eine Grundbewehrung mit einer Matte Q-335A gelegt und es sollen die noch abzudenkenden Spitzen angezeigt werden ist 'asxyab 3.35' der benötigte Befehl. Es können beliebig oft Werte abgezogen werden, da mit dem Parameter '-u' der Grundzustand wieder herzustellen ist. Alle Befehle der Prozedur 'asxyab' wirken auf alle Bewehrungslayer gleichzeitig. Änderungen der Textgröße werden mit dem Parameter '-u' nicht zurückgenommen.


Soweit zur derzeitigen Verwendungsmöglichkeit des Bewehrungsdaten-Exportes nach Zeig. Wir verwendet diese Routinen in erster Linie bei größeren Decken mit ungleicher Belastung oder bei sehr unterschiedlichen Feldkonfigurationen.

Die mir von Ihnen zur Verfügung gestellten Methoden habe ich mit den entsprechenden Änderungen in das Makro integriert und umbenannt, um die Originale im Programmcode auszusparen. Zur besseren Verifizierung zwischen Ihren ursprünglichen Methoden und meinen Änderungen, bzw. den bis heute im Programm vorliegenden Methoden habe ich Ihnen die alten Dateien noch mit in die Zip-Datei gepackt.

Wer mag, kann alles zusammen hier herunterladen.


Makros in der Baustatik


Die Baustatik ist vollständig vom Anwender programmierbar und damit erweiterbar. Ein gutes Beispiel für eine solche Erweiterung ist die Variantenkonstruktion, also eine Art der Konstruktion, bei der immer ähnliche Konstruktionen mit veränderten Parametern angelegt werden.

So sind zum Beispiel die Regale der Firma Heiss konzipiert. Die sehen ungefähr wie folgt aus und haben auch die ersichtlichen Parameter:

image

Dafür gibt es nun ein Makro – und wer will, kann das auch ausprobieren. Dazu ist folgendes zu tun:

Sie gehen in der Baustatik nach "Optionen -> Makro -> Makro herunterladen".  (Der Rechner muss dazu einer Internetverbindung haben.)

image

Das zeigt das Fenster mit den Makros an. Dort wählen sie "Regalerzeugen.cs" aus, und klicken dann auf "Speichern". Dadurch wird das Makro auf Ihren Rechner herunterladen und dort abgelegt. (Man kann es auch alternativ direkt vom Server aus ausführen, aber dann müssen Sie sich immer wieder verbinden, und können auch nichts ändern.)

Dann legen Sie ein neues leeres Faltwerks oder Rahmendokument an, und gehen dann auf Optionen -> Makro -> Makro ausführen. In der Liste taucht das "Regalerzeugen.cs" Makro dann wieder auf: Da drücken Sie auf "ausführen".

image

Das Makro startet dann, und öffnet zunächst ein Fenster, in dem die Parameter fürs Regal erfagt werden:

image

Die einfach eingeben (alle Abmessungen in [m], und "Kommas" mit ".") und OK drücken -> Das RegaL wird erzeugt. Die Stäbe darin haben dann bereits die "richtig" sortierten Querschnitte - die sind aber noch "leer" und Sie müssen also die Querschnittsdefinitionen über die Dokumenten-Ansicht noch ergänzen.

Wenn man das getan hat, sieht die ganze Sache ungefähr so aus – und alles mit nur 6 eingegebenen Werten:

image


Kleine Statistik zur Baustatik


Weil ich kürzlich mal wieder drauf geschaut und darum die Zahlen zur Hand habe: So sieht die Baustatik aus Entwickler-Sicht aus:

Eigentlicher Quellcode: circa 19.000 Dateien, 3000 Ordner mit insgesamt etwa 1.5 GB
Testumgebung: circa 8600 Dateien in 65 Ordnern mit etwa 3.7 GB
Begleitende Webseite (Doku, Case-Management, etc.): circa 3700 Dateien, 120 Ordner, 500 MB.

… alles zusammen also etwa 30.000 Dateien. Schon eher ein größeres Projekt Smiley