Stefan Haslinger | Informatom EDV-Dienstleistungen e.U.

Meine Nerves Story

Mon, 28 Mar 2022 08:00:00 +0200

In den letzten Jahren steigerte sich mein Interesse für IOT-Projekte. Ich lernte Löten, habe mit Raspberry Pies herumgespielt, diese aber zumeist als NAS, oder Proxies (Pi-Hole) verwendet. Später folgte ein Airrohr-Feinstaubsensor auf Basis eines ESP8266, der seit Jahren gute Dienste leistet und seine Daten an https://luftdaten.info/ übermittelt. Die Daten können hier eingesehen werden, wenn ich den Sensor seit Schreiben dieses Posts nicht doch wieder abgebaut habe und den Chip anderwertig verwendet habe.

Etwa Mitte 2021 bin ich dann auf das Nerves Project gestoßen, implementiert in der von meiner geschätzten Programmiersprache Elixir. Nerves ist ein ausgereiftes Frameworks zur Entwicklung von IOT-Anwendungen. Als ich dann vom Buch Build a Weather Station with Elixir and Nerves gelesen habe, war ich doppelt interessiert und habe versucht, mir die benötigten Sensoren zu beschaffen, was nur zum Teil gelang.

Die Komponenten der Wetterstation

Das Projekt besteht aus einer Wetterstation in Form dreier Hardwaresensoren, die über das Qwiic Connect System von Sparkfun per Kabel in einer Daisy Chain an einen Qwiik Hat, der auf einem Raspberry Pi aufgesetzt ist. Ich verwende noch den pHat in Version 1, was aber für das Projekt keinen Unterschied macht, da die zusätliche 5V Stromversorgung am pHat Version 2 nicht verwendet wird.

Bild: SparkFun Qwiic pHAT for Raspberry Pi, Quelle: Sparkfun Produktseite, Bild zugeschnitten, Lizenz CC BY 2.0, die Längskante des Boards ist 65mm.

Im Prinzip kann jeder Raspberry Pi verwendet werden, der über einen 40pin GPIO Port verfügt, ich verwende einen Raspberry Pi 3 Model B, der für diese Zwecke eigentlich überdimensioniert ist.

Bild: pHat auf einem Raspberry Pi 3 aufgesteckt

Als Sensoren verwende ich Qwiic Sensoren von Sparkfun: Ein VEML6075 UV-Sensor, ein BME680 Air Quality Sensor mit Temperatur-, barometrischer Luftdruck-, Luftfeuchtigkeits- und VOC-Gassensor (volatile organic compoints = flüchtige organische Verbindungen). Weiters kommt ein SGP30 Luftgütesensor zum Einsatz.

Bild: SparkFun Qwiik BME 680 Air Quality Sensor Breakout, Quelle: Sparkfun Produktseite, Bild zugeschnitten, Lizenz CC BY 2.0, die Kantenlänge des Boards ist 25mm, die des Sensors in der Mitte, der ein SBC mit I2C schnittellen ist, etwa 2mm.

Bild: SparkFun Qwiik SPG 30 Air Quality Sensor Breakout, Quelle: Sparkfun Produktseite, Bild zugeschnitten, Lizenz CC BY 2.0, die Kantenlänge des Boards ist 25mm, die des Sensors in der Mitte etwa 2mm.

Bild: SparkFun Qwiik VEML 6075 UV Light Sensor Breakout, Quelle: Sparkfun Produktseite, Bild zugeschnitten, Lizenz CC BY 2.0, die Kantenlänge des Boards ist 25mm, die des Sensors in der Mitte etwa 2mm.

Links zur Dokumentation aller Sensoren dieses Projekte, und einiger weiterer Sensoren, die sich in meinem Besitz befinden, finden sich im Wiki des Projektes.

Kein Löten, nur Stecken

Die beschriebene Kombination kommt ohne jegliches Löten aus, was ich auch für einen Prototypen, der in nicht hardwarenahen Firmen präsentiert werden soll, für essentiell halte. Man möchte nicht durch zu lötende Komponenten abschrecken. Genau das ist mit SparkFuns Qwiik Plattform möglich, die Steckverbindungen und Kabel sind genormt, die Stecker sogar verpolungssicher.

Ich bin aber mit Nerves als IOT Plattform nicht auf diese Sensorplattform beschränkt. Sensoren lassen sich auch direkt mit dem 40Pin GPIO Connector des Raspberry Pi verbinden, wenn sie durch dieses Interface angebunden werden können. Es gibt auch zahlreiche andere Hats (Aufsteckboards), die entweder andere Sensoranschlüsse bieten oder Sensoren gleich direkt verbaut haben. Einige Nerves Case Studies lassen sich auf der Nerves Webseite nachlesen.

Meinen eigenen Hardwaretreiber schreiben

Der VEML6075 ist allerdings nicht der Sensor, der im Buch für das Projekt vorgeschlagen wird, dort kommt ein VEML6030 zum Einsatz. Ich dachte naiver weise: „Ist halt ein neueres Modell, der Treiber wird schon passen!“ Das war aber nicht der Fall.

So stand ich vor der Aufgabe, da ich in meinem Leben noch keinen Hardwaretreiber geschrieben habe, die Datenblätter, die mit den Sensoren mitgeliefert waren, zu verstehen, ebenso den Treiber, der im Buch für den VEML6030 entwickelt wurde. Und hier besteht jetzt die große Stärke von Open Source und freien Informationen. Ich hatte nach 2 Stunden Lernaufwand erstmals erfolgreich Daten vom VEML6075 ausgelesen, nach weiteren 2 Stunden einen Treiber, der sogar eine Spur mehr konnte, als der für den VEML6030 im Buch entwickelte. Das macht einen dann auch ein bisschen stolz.

Schnelle Fortschritte

Die beiden anderen Sensoren ließen sich wie im Buch beschrieben, über öffentliche Elixir Pakete (Hex Packages) rasch einbinden. Der nächste Schritt war in einer virtuellen Maschine eine kleine Phoenix-Applikation zu schreiben, die einen JSON-Endpoint zum Annehmen der Daten vom Nerves-Pi anbietet.

Das klappte ganz vorzüglich. Ich konnte mich aber nicht mit dem Gedanken anfreunden, dass dieser Endpunkt völlig offen ist, selbst wenn ich das Projekt nur in WLANs von Firmen präsentieren will, ist ein offener Endpunkt für mich gefühlt nicht in Ordnung und ich habe eine kleine Token-Authentifizierung dazu geschrieben. Hier kommen wieder die Stärken von Open Source und dem Elixir/Phoenix Stack zum tragen. Gerade mal eine zusätzliche Zeile, nämlich die fünfte im folgenden Block, ist für ein hard codiertes Token im Nerves Projekt nötig

result =
  Finch.build(:post, state.weather_tracker_url,
    [
      {"Content-Type", "application/json"},
      {"authorization", "my_secret_token"}
    ],
    Jason.encode!(state.measurements)
  )
  |> Finch.request(WeatherTrackerClient)

Auf Seiten der Phoenix Applikation sind es gerade mal fünf zusätzliche Zeilen, um das Token zu überprüfen:

if List.first(get_req_header(conn, "authorization")) == "my_secret_token" do
  # do the regular stuff
else
  put_status(conn, :unprocessable_entity)
  |> json(%{message: "Auth token not valid"})
end

Datenablage

Die Datenablage erfolgt aus der Phoenix-Applikation in eine Timescale-DB. Bei Timescale handelt es sich um ein Add-On zu PostgresQL, sodass in Richtung der Phoenix Applikation keine Adaption des Codes erforderlich ist und der standard relational Mapper postgrex verwendet werden kann.

In Richtung der Visualisierung durch Grafana (Details im nächsten Abschnitt) ist ebenfalls keine spezielle Anpassung nötig, da Grafana out of the box Timescale Datenbanken unterstützt.

Timescale verbessert das Handling von Zeitreihendaten hinsichtlich Speicherung, Geschwindigkeit und Analyse. Einen Überblick über die Funktionalität bietet die Dokumentation von Timescale.

Visualisierung

Zur Visualisierung der Daten wird nicht die Funktionalität von Phoenix zur Erstellung von Webseiten vorgeschlagen, sondern eine Installation von Grafana.

Um eine Timescale Datenbank aber auch Grafana rasch zu installieren habe ich, wie auch im Buch zum Projekt vorgeschlagen, zwei Docker Container verwendet. Somit ist auch die komplette Konfiguration Infrastructure as Code, also nicht durch menschliche Intervention durchzuführen, sondern völlig gescripted. Das docker-compose file ist dabei noch überraschend kompakt.

Grafana kann eine breite Platte an Visualisierungen von Daten bieten. Ein einfaches Dashboard für unsere Daten besteht zwar aus knapp 1000 Zeilen json, diese werden aber nicht von Hand geschrieben, sondern über die Weboberfläche von Grafana erzeugt. Schlussendlich ist aber damit auch wieder nur Infrastructure as Code und gesamte Code für beide Plattformen kann über Git-Repos geshared werden:

Repo der Nerves Applikation inklusive des selbst geschriebenen Treibers
Repo der Phoenix Applikation inklusive Grafana und Docker Konfiguration

Fazit

Ich hatte Spaß, das ging einfacher als erwartet. Und wann machen Sie Ihr erstes IOT Projekt mit Nerves?

Twitter, mir graut vor Dir!

Thu, 14 Nov 2019 13:00:00 +0100

Ich fuhr neulich mit einem Zug durch Deutschland, als ich auf Twitter über einen Post auf einen Benutzer stieß, der systematisch andere Benutzer auf das Übelste herabwürdigte. Ich hatte derart Übles schon länger nicht mehr gesehen, sodass ich mich genötigt sah, der Benutzer zu melden.

Die Kette der Dialogschritte, die dazu nötig war, unterschied sich deutlich von jener, die ich aus Österreich kenne. Die Texte lauteten wie folgt:

Schritt 1

Hilf uns dabei, das Problem zu verstehen. Was stimmt mit diesem Tweet nicht?

Ich bin an diesem Tweet nicht interessiert
Verdächtig oder Spam
Er ist missbräuchlich oder verletzend
Fällt unter das Netzwerkdurchsetzungsgesetz
Es lässt die Absicht von Selbstverletzung oder Selbstmord erkennen.

Schritt 2

Inwiefern ist dieser Tweet missbräuchlich oder schädigend?

Beinhaltet private Informationen
Diese Person ermutigt zu Selbstmord oder Selbstverletzung oder denkt darüber nach
Fällt unter das Netzwerkdurchsetzungsgesetz

Schritt 3

Was melden Sie? Beachten Sie bitte, dass Ihre Meldung von Twitter nur entgegengenommen und überprüft wird, wenn Sie dieses Formular vollständig ausfüllen und auf „Absenden” klicken. (Für eine zusätzliche Option, bitte nach unten scrollen.)

Hass schürende / verfassungswidrige Inhalte
Terrorismus Gewalt / Bedrohung / Aufforderung zu Straftaten
Sexueller Missbrauch von Kindern
Beleidigung / Üble Nachrede

Schritt 4

Gegen welches Gesetz wird verstoßen?

Paragraph 86 StGB: Verbreiten von Propagandamitteln verfassungswidriger Organisationen
Paragraph 86a StGB: Verwenden von Kennzeichen verfassungswidriger Organisationen
Paragraph 130 StGB: Volksverhetzung

Schritt 5

Diese Aktionen sind …

Gegen mich gerichtet (z. B. @Erwähnung, Name, Spitzname oder Pseudonym)
Gegen jemanden gerichtet, den ich gesetzlich vertrete (z. B. meinen Klienten oder mein Kind)
Gegen andere gerichtet (z. B. einen Freund oder eine Gruppe)

Schritt 6

Über Sie selbst: Ich erstatte die Meldung:

Für mich selbst
Für eine Beschwerdestelle
Für eine staatliche Behörde

Schritt 7

Ich verstehe, dass die gemeldeten Inhalte auf potenzielle Verstöße gegen die Allgemeinen Geschäftsbedingungen von Twitter und/oder das deutsche Strafrecht untersucht wird und dass ich eine Beschwerde einreiche, die gemäß dem Netzwerkdurchsetzungsgesetz zur Löschung oder zur Vorenthaltung von Inhalten in Deutschland führen kann. Ich verstehe, dass ich mit dieser Beschwerde einen schwerwiegenden Vorwurf erhebe.

Alle in dieser Beschwerde enthaltenen Informationen sind wahr und korrekt und ich reiche diese Beschwerde ein, weil ich in gutem Glauben der Ansicht bin, dass eine Verletzung der Allgemeinen Geschäftsbedingungen von Twitter oder diese Angelegenheit an die Lumen-Datenbank gemeldet, im Twitter Transparenzbericht aufgeführt und in gesetzlich vorgeschriebene öffentliche Berichte und Berichte an Behörden aufgenommen werden kann. (Um fortzufahren, bitte nach unten scrollen.)

Ich verstehe, dass sich durch die Einsendung unvollständiger, ungültiger oder falscher Meldungen die Wahrscheinlichkeit verringern kann, dass diese Meldung (sowie zukünftige Meldungen) von den Twitter Systemen überprüft oder akzeptiert werden.

Ich verstehe, dass die Einsendung falscher Meldungen über Verstöße gegen die Allgemeinen Geschäftsbedingungen oder von falschen Rechtsbeschwerden zur Unterdrückung der Inhalte anderer Nutzer ein missbräuchliches Verhalten im Rahmen der Twitter Regeln darstellen kann und dass wiederholte Verstöße zur dauerhaften Sperrung meines Accounts (sowie eventuell vorhandener verknüpfter Accounts) führen können.

Signatur

Ich frage mich nun:

Will ich ein Service weiter benutzen, dass einerseits so unheimlich viele Schritte einer Meldung in den Weg stellt, um nur nicht selbst agieren zu müssen.
Wie finde ich es, dass Twitter mir droht, wenn ich ihm helfen will, seine menschenverachtenden Inhalte zu finden?

Ich genieße die Inhalte vieler Freunde und Bekannter, aber Twitter selbst wird mir mehr und mehr unsympatisch.

Breaking Three

Thu, 17 Oct 2019 08:00:00 +0200

13.Oktober, 13:35. Da stehe ich nun im Englischen Garten in München und habe noch ziemlich genau 5 Minuten Zeit bis zum Start. Zum Start des Münchner Halbmarathons. Und das alles nur wegen Dominik. Der nicht hier ist.

Aber hier ist Friedl. Er läuft seinen zweiten Halbmarathon. Vor zwei Wochen ist er in Ulm schon eine 2:48 gelaufen und heute will er wenigstens eine 2:47 schaffen. Wir haben 3 Stunden Zeit, das ist die sogenannte Karenzzeit. Dann kommt der Besenwagen. Den ich hoffentlich nicht sehen werde. Hinter dem muss man am Gehsteig laufen.

Steve ist bereits vor 5 Minuten gestartet. Im Startblock A. Die Schnellen. Wir sind C. Die Langsamen. Vorne wird geklatscht, Es geht wohl los. Den Startschuss hören wir nicht, wir sind zu weit hinten. Kilometer 0.

Kilometer 1: Nur nicht zu schnell loslegen. Beim Staffellauf in Wien bin ich vor einem halben Jahr schon mal 15k auf Zeit gelaufen. Also 15 Kilometer. Nach 2k war ich das erste Mal kaputt. Zu schnell angegangen. Das passiert mir heute nicht. Mir ist auch zu warm dafür. Und es geht bereits nach 300m bergauf. Ich dachte, in München ist es flach.

Kilometer 2: Eigentlich wollte ich mit den 2:30 Pacern anfangs mitlaufen. Theoretisch wären 2:34 bei mir drin. Sagt die Leistungsmessung der letzten Wochen und Monate. Die Pacer haben wir auf der ersten Steigung aus den Augen verloren. Ich muss also mein eigenes Rennen laufen. Vielleicht auch besser so. Jetzt erst mal von der Steigung erholen. Und ich habe ja noch Friedl. Er läuft genau mein Tempo. Also das, was sich für mich OK anfühlt. 2:47 würde ich jetzt auch nehmen…

Kilometer 3: Der Puls ist konstant bei 160. Das ist OK. Sagt mir auch die Erfahrung der letzten Monate. Ich habe sogar eine Spirometrie unter Laborbedingungen gemacht und weiß, dass mein Maximalpuls bei 182 liegt. Also alles im Grünen Bereich.

Kilometer 4: Friedl ist noch neben mir, mal ein paar Meter vor mir, mal hinter mir. Wir bringen einander automatisch dazu, mit sehr konstanter Anstrengung zu laufen. Das ist gut. So kann man das überstehen. Denn es ist sehr warm.

Über uns ist ein Luftschiff. Eine nette Ablenkung. Ganz ruhig. Rund herum immer wieder Zuschauer, die uns anfeuern. Kleine Kinder, die abgeklatscht werden wollen. Läuft.

Kilometer 5: Die erste Verpflegungsstelle. Und Friedl ist weg. Er läuft durch Verpflegungsstellen durch, trinkt und isst dabei. Ich gehe langsam, habe das nicht so heraus. Aber ich kriege ihn nach 200 Metern wieder, wenn es das nächste Mal bergab geht. Funktioniert eigentlich ganz gut. Habe in den letzten Wochen viel Wert auf Techniktraining gelegt. Die richtige Vorlage. Also sich so ein bisschen vorwärts lehnen beim Laufen. Damit bremst man nicht bei jedem Schritt. Und bergab wird man automatisch schneller. Nur sauber laufen, sonst gibt es Rückenprobleme. Oder mit dem Knie. Oder der Achillessehne. Aber ich bleibe konzentriert.

Kilometer 6: Ist das heiß hier. Fade Strecke, die Sonne brennt. Die Univesität gibt später zu Protokoll, dass die Maximaltemperatur des Tages 25.7 Grad ist. Im Frühjahr habe ich gemerkt, dass ich, sobald es mehr als 16 Grad hat, langsamer werde. Der Traum von den 2:30 ist ad acta gelegt. Macht nix. 3:00 sind das Ziel. Also: Breaking Three.

Kilometer 7: Um Breaking Three zu schaffen muss ich 8:30 pro Kilometer laufen. Bisher geht das leicht. Der schnellste Kilometer war 7:50, alle unter 8:30. Ich baue also einen gewissen Zeitpolster auf. Wie viel? Egal. Zum Rechnen habe ich keine Lust. Der Kipchoge ist ja gestern in Wien gelaufen: Breaking Two. Er hat einen Marathon unter zwei Stunden geschafft. Ich will die halbe Strecke in drei. Jedem seine Ziele. Und meines habe ich Dominik, Steve und TJ zu verdanken.

Kilometer 8: Heiss. Der Dominik hat auf der Ganzohr Wissenschaftspodcastkonferenz vor zwei Jahren spät abends bei Burger und Bier gesagt, er will wieder Sport machen. Und der Steve meinte, er könnte ihn trainieren. TJ und ich haben sich angeschlossen. Und gemeinsam sind wir die 3 Schweinehunde. Steve ist ja der Betreuer. Der scheint keinen Schweinehund überwinden zu müssen und läuft 5x die Woche wie ein Uhrwerk. Wobei nicht ganz. Doch dazu später. Als Podcaster berichten wir 3 Schweinehunde etwa einmal im Monat von unserem Trainingsfortschritt. Trainingsziel ist hier und heute den Halbmarathon zu schaffen. In der Karenzzeit. Aber das hatten wir ja schon.

Kilometer 9: Friedl ist noch da. Steve wohl weit vor mir. Insgesamt sind wir heute sogar 9 Schweinehunde. Einige Hörer:innen haben sich angeschlossen. Sonst wäre das auch traurig. Denn Dominik konnte heute nicht starten. Zuerst eine Verletzung am Fuß, eine Sehnenzerrung. Zuletzt noch 2 Erkältungen. Und während ich mich hier abmühe, frage ich mich, ob die ihm nicht ganz recht gekommen sind. Nein, dafür hat er zu viel trainiert. TJ ist schon länger raus. Details haben wir im Schweinehunde Podcast berichtet. Ob er je wieder mit uns laufen wird? Ich weiß es nicht. Mir ist zu heiß.

Kilometer 10: Einem älteren Herrn vor mir auch. Er kracht torkelnd gegen eine Bande. Ungefähr 50 Meter von den Sanis entfernt. Die kümmern sich gleich um ihn. Alles gut. Aber ich mache mir bewusst, dass ich auch ziemlich am Limit bin. Nicht von der Atmung, die hat sich in den letzten Wochen sehr verbessert. Eigentlich atme ich fast flach jetzt. Aber mir ist heiß. Ich weiß, das hatten wir schon. Aber es dominiert die Gedanken. Aber besser das, als andere Probleme. Vor einigen Wochen hatte ich mit der linken Patellasehne zu tun, das ist die über der Kniescheibe. Jumpers Knee, wie es genannt wird. Habe ich gelernt, wie viel anderes Anatomisches. Konnte ich aber durch Dehnung und Massage wieder los werden.

Hat sich herausgestellt, so heuer im Frühjahr, Steve unser Trainer, ist auch nur ein Mensch. Nach einem Rennen war er ziemlich K.O. Beine wie Gummi, hat er gesagt. Für einige Wochen. Warum konnten auch Ärzte nicht heraus finden. Das ist alles nicht so einfach mit dem Organismus. Manchmal ist die Ursache eines Problems ganz wo anders im Körper zu suchen. Oft im Kopf. Manchmal findet man sie nie und es wird einfach so wieder besser.

Kilometer 11: Friedl ist noch da, er schnauft. Mal sehen, ob ich ihn noch abhänge? Aber tut mir da nicht gerade die Achillessehne weh? Sauberer Laufen! Und schon ist es wieder weg. Vielleicht ein Warnsignal. Mit der gab es auch vor einiger Zeit Probleme. Die beiden sind auch meine Schwachstellen. Wegen ihnen habe ich zuletzt die Umfänge beschnitten, ein paar lange Läufe ausgelassen. Ob sich das noch rächen wird?

Kilometer 12: Es geht in die Stadt. Mehr Schatten. Das tut gut. Aber auch die Energie wird weniger. Und nach jeder Verpflegungsstelle wieder zu Friedl aufschließen kostet Kraft. Ich glaube nun eher, er wird mich abhängen. Meine Leistung sinkt. Anfangs waren es bergauf 240 Watt. Später 215 flach. Jetzt gerade noch 200. Das sagt mir ein Sensor am Schuh, der mit meiner Uhr spricht. Schon cool. Eigenlich sollte ich um die 240 Watt laufen. Aber das ist bei der Hitze nicht drin. Ich will ins Ziel kommen. Lieber etwas vorsichtig sein und nicht überpacen. Ich will mich ja nicht kaputt machen.

Kilometer 13: Puls weiter bei 160. Kardiovaskuläre Dings … Drift. Das Gehirn hat schon etwas zu wenig Sauerstoff. Der Puls steigt langsam, wenn man nicht langsamer wird, das ist normal. Und das wird heute noch lang werden. Friedl ist noch in Sichtweite, aber ich schließe nicht mehr locker auf. Egal.

Das mit Breaking Three muss sich ausgehen. Immer noch jeder km knapp unter 8:30. Der Besenwagen ist so weit weg wie noch nie. Normaler weise könnte ich mir im Kopf einen karierten Zettel vorstellen und Wurzel ziehen. Jetzt nicht mehr. Eigentlich interessant, dass das Gehirn und der Körper das recht locker hinnehmen. Über was man alles nachdenken kann, so beim Laufen. Die Gedanken driften immer wieder weg vom Lauf. Zuschauer feuern uns an. Ach ja, da sind wieder Kinder, die abklatschen wollen. 2m Umweg? Nö. Zu viel Anstrengung. Sorry.

Kilometer 14: Vorbei am Viktualienmarkt über Pflastersteine. Vor einem Jahr hätte ich da noch Probleme gehabt. Die Sehnen in den Füßen waren zu schwach. Habe dann ab Weihnachten die Umstellung zum Mittelfußlauf gemacht. Im April gab es erste Erfolge. Jetzt sind Pflastersteine kein Problem mehr. Ich schmunzle. Das sieht die Sprecherin: “Stefan schenkt uns sogar noch ein Lächeln”. Ich hatte das gar nicht gemerkt. Der Kipchoge macht das übrigens auch. Um den Schmerz zu überwinden. Noch tut nix weh.

Kilometer 15: Friedl ist weg. Die Sonne geht aber auch langsam runter. “Das sollte zu schaffen sein”, spreche ich mit einer Läuferin. “Daran habe ich nie gezweifelt.” In dem Moment sticht die rechte Wade. Jetzt zweifle ich doch. Mit der gab es noch nie Probleme. Egal, hier gibt’s auch wieder Verpflegung. Und die habe ich nötig. Energieriegel und Banane. Burps. Doch zuviel? Nein, geht schon.

Kilometer 16: Wieder mehr Energie. Aber die Wade tut auch mehr weh. Puh. Schade, dass ich mich an Friedl nicht mehr anhängen kann. Er ist endgültig außer Sichtweite. Ich suche mir einen anderen. Der humpelt sogar. Ich bin jetzt so langsam, dass ich mit einem der humpelnd läuft, gerade so mitkomme.

Kilometer 17: Das war’s wieder mit der Energie, aber sind ja nur mehr 4 Kilometer. Alter Schwede: Noch 4 km mit einer stechenden Wade? Aber ich habe noch 3 Gels bei mir. Mal eins nehmen. Jeder Meter fühlt sich bergauf an. Obwohl es hier eher bergab geht. Meine Uhr meint am Schluss 140 Höhenmeter, die von Steve 65. Was stimmt? Eigentlich ist das nur eine Frage der Auflösung der Messung, so eine Höhenkurve ist ein Fraktal. Oha! Das Hirn ist wieder voll da. Um den Schmerz zu genießen? Immerhin ist mit dem Kreislauf alles in Ordnung. Ich bin angstrengt, aber der Puls ist weiter bei 160.

Kilometer 18: Noch 3km. Die Reihen lichten sich, das Feld um mich zieht sich auseinander. Auch kaum Zuschauer. Langweilige Häuserreihen. Mal kurz überschlagen, ob sich das mit Gehen ausgehen würde. Nein. Aber ein paar Meter gehen schon. OK: 100 Meter. Dann wieder Anlaufen. Die Muskulatur in beiden Beinen tut weh. 3 Kilometer noch. Ach, das hatten wir ja schon.

Kilometer 19: Am Wegesrand sitzt einer mit einem Krampf. Ich will ihn aufmuntern, neben mir zu gehen. So langsam laufe ich. Er kann nicht. Aber er wirkt sonst OK. Der bei km 15 am Rettungswagen in der Rettungsdecke war nicht mehr OK. Totaler Blick durch mich durch ins Leere. Ist mit mir alles OK? Ja soweit alles OK. Aber es ist verdammt anstrengend. Mir fehlen die langen Läufe. Aber jetzt habe ich zwei Jahre trainiert und es fehlen mir mehr zwei Kilometer. Aufgeben ist definitiv keine Option. Denken Sie nicht an das Aufgeben! Alter, bin ich langsam, manchmal nur 9:30, und das laufend.

Kilometer 20: Die Polizeimotorräder überholen mich. Kommt schon der Besenwagen? Nein, die wollen nur nach Hause. Das Ziel, das Olympiastadion, ist schon zu sehen. Das letzte Gel hinein. Eigentlich ist der Akku leer. Ich mag nicht mehr. Weiter!

Kilometer 21: Die mentale Barriere fällt weg. Es ist nicht mehr weit, ich werde wieder so schnell wie ganz am Anfang. Beim Einlauf ins Stadium gibt’s dann Gänsehaut für ein paar Sekunden. Jetzt sind es nur mehr 200m. Ich überhole noch einen. Sehe die Freundin, die mich anfeuert. Ins Ziel. Geschafft! Three is broken. 2:55:irgendwas. Egal. Halbmarathon erledigt. Uff! Hinsetz… Nö, der Stadionsprechen wirft uns hinaus - über die lange Treppe geht’s aus dem Stadion.

Ich war nie im roten Bereich, den kenne ich von kürzeren Läufen. Steve hat mich gut vorbereitet, der Trainingsplan war topp. Beim Lauf war alles war unter Kontrolle. Und jetzt? Erstmal ausruhen. Forsetzung gibt’s im Podcast.

Technische Überlegungen zur Entwicklung einer Trainingsdokumetation

Thu, 11 Apr 2019 13:00:00 +0200

Als Softwareentwickler habe ich natürlich immer sofort die Architektur einer Anwendung im Kopf, und die Implikationen, die sich aus der Wahl ergeben, sowohl für die Features, die man gerade plant, als auch für jene, die noch in weiterer Ferne erscheinen. Und so ist die Planung einer Anwendung “auf der grünen Wiese” zwar einerseits eine große Freude, kann man doch den geeigneten Stack selbst bestimmen, andererseits aber auch eine Belastung, legt man sich doch gleichzeitig auf einen fest. Und so ist es auch diesmal:

Wie bereits im letzten Post besprochen, ist Stefan (der andere ;-), Stefan Dillinger) hier ja mit von der Partie, also im Team und ich möchte ihn soweit wie möglich in die Entwicklung einbinden. Was weiss ich denn von ihm? Er ist grundsätzlich technikaffin, ist er doch das technische Mastermind hinter dem Podcast The Random Scientists. Er ist weiters studierter Biochemiker - also Naturwissenschaftler, doch wenn mich nicht alles täuscht, kam in seinem Studium die Entwicklung mit der aktuell in den Naturwissenschaften beliebtesten Sprache, Python, nicht allzu intensiv vor. Ich selbst habe mal Python im Mittelschulrahmen unterrichtet (und dafür auch zuvor gelernt :-) ). Das ist allerdings schon 15 Jahre her. Meine Erinnerungen an Python sind durchwegs positiv, auch wenn die vielleicht interessanteste Art für unser Projekt mit Python zu interagieren, damals noch gar nicht gab: Jupyther Notebooks. Wir könnten darin quasi in einer Art wissenschaftlichem Paper unsere Dokumentation erläutern und auch gleich anhand der echten Daten implementieren. Es gibt sogar eine Python Bibliothek zum Import von Daten auf .fit-files. Zur Erinnerung: Das sind die Dateien, die die Garmin Uhren erzeugen. Allerdings hat dieser Importer bei meinem Test Probleme mit den Stryd Erweiterungen im File - nun, we are digging into a rabbit hole already, würden englischsprachige Entwickler jetzt sagen, wir gehen eventuell mit den Überlegungen schon zu sehr in die Details. Wesentlicher ist allerdings folgendes: Juypther Notebooks lassen sich auch im Web publizieren, allerdings sind die meisten User sie wohl nicht gewohnt. Es wäre vielleicht ein interessanter Einstieg in wissenschaftliche, akademische Bereiche der Leistungsanalyse, John Doe Normaluser ist aber zunächst vermutlich einfach nur überfordert. Im Gegensatz dazu wäre eine Erweiterung, etwa um neue Algorithmen, wohl ein Einfaches. Aber wollen wir uns in eine wissenschaftliche Nische begeben?

Meine Haus- und Hofsprache war für lange Zeit Ruby. Mit Ruby on Rails gibt es ein hervorragendes Webframework, das ich fast 8 Jahre lang ausschließlich verwendet habe. Es gibt einen .fit-Parser (der wieder seine Probleme mit Stryd Daten hat), Teile meiner Tracker Software ließen sich sogar wieder verwenden. Stefan hat von Ruby (außer durch mich) noch nix gehört, und ob er in eine Sprache, die er wohl zu keinem anderen Zweck je wieder verwenden wird, lernen würde?

Warum würde ich ihn eigentlich in die Entwicklung reinziehen wollen? Geteilte Arbeit ist halbe Arbeit. Und es macht auch wesentlich mehr Spaß und Probleme in der Entwicklung sind so leichter zu argumentieren.

Aktuell verwende ich Ruby on Rails für neue Projekte eigentlich nicht mehr. Ich setze für Webanwendungen auf Elixir und Phoenix. .fit-Parser gäbe es hier noch keinen, er ließe sich aber jedenfalls Entwickeln. Phoenix Applikationen skalieren hervorragend - aber um wieviele User geht es eigentlich? Wir hatten doch von self hosting gesprochen: Nur in welchem Sinne. 3 Schweinehunde für ihre Community oder jede:r Läufer:in für sich selbst? Auch hier gilt: Stefan bringt wohl keine Erfahrung mit, bei mir sind es etwa 2 Jahre. Noch einen Haken gibt es: Phoenix Applikationen sind zwar nicht allzu schwer zu hosten, allerdings gibt es relatix wenige Provider, die es “out of the box” anbieten. Für Ruby ist dies wohl etwas besser, für Python wieder etwas verbreiteter, jedenfalls aber kein Vergleich etwa zu PHP, das annähernd jeder Provider anbietet.

Ach ja, ich vergaß: Zu Python gibt es auch Webframeworks, das bekannteste unter ihnen Django, das ähnliche Prinzipien verfolgt wie Ruby on Rails, mir also von den Konzepten vertraut ist. So könnten Teile des Jupyther Notebooks auch in einer Multiuser Webapplikationen verwendet werden.

Bislang sprach ich von Webapplikationen, also Software, die man auf einem Webserver installiert und die dann im Browser (ruhig auch auf einem Smartphone) aufgerufen werden. Aber es gäbe auch einen ganz anderen Ansatz: Den Weg einer mobilen App zu gehen.

Ich habe mich im letzten Jahr mit der Entwicklung von Android Applikationen mittels der Sprache Kotlin beschäftigt. Mit Kotlin Native verspricht die Firma Jetbrains dann auch die Entwicklung von Cross Plattform Mobile Apps, also auch für iOS zu ermöglichen. Allerdings ist dies bislang bestenfalls im Prototypen Stadium. Daher ware ich mit Kotlin bisher recht zögerlich.

Vor kurzem aber tat sich eine weitere Option auf: Das Farmework Flutter, das von Google entwickelt, für die cross plattform Entwicklung (Android + iOS) entwickelt wird. Es ist noch recht neu, aber ich lerne gerade, dass mittlerweile alle Bibliotheken, die wir benötigen würden, wohl verfügbar wären - mit Ausnahme des .fit-Parsers. Der wäre aber auch in Kotlin selbst zu schreiben… Also etwa die Abfrage von APIs (Daten aus Strava, …) ist möglich - ich nenne Garmin hier bewusst nicht, denn man glaubt bei Garmin für den API Zugriff auch die eigenen Daten 5000 EUR verlangen zu können).

Also statt eines Webservers, die eigenen Laufdaten komplett auf dem Handy? Kann das gehen? Ja: Flutter apps kompilieren zu nativem Code, d.h. sie laufen direkt auf der Hardware (etwa im Gegensatz zu Javascript in einer Webseite, das einen Interpreter benötigt). Auch die Datenhaltung in einer Datenbank ist durch SQLite möglich. Dazu eine kurze Abschätzung: Wir laufen in der Vorbereitung auf den Münchenmarathon (den letzten Post haben Sie gelesen?) etwa 150 Läufe. Nehmen wir an, jeder Lauf benötigt im Schnitt rund eine Stunde. Wir sammeln in jeder Sekunde des Laufes einen Datenpunkt (oder Datensatz) der aus Rund 20 Werten besteht. 8 Bytes * 20 Werte * 3600 Sekunden * 150 Läufe = 83 MB Nehmen wir noch einige MB an Daten für die Metadaten auf Laufebene und Läufer:innenebene hinzu, landen wir vielleicht bei 100 MB. Das könnte ein gebräuchliches Smartphone sogar im Speicher halten. Die Speicherung der Daten einer Läufer:in in einer SQLite Datenbank ist kein technisches Problem.

Aber wie würden Läufer:innen dann ihre Daten publizieren? Dazu spontan 2 Ideen:

Es gibt mehrere Static Site Generator für Dart, die Webseite könnte also am Smartphone erstellt und dann auf einen Webserver geschoben werden.
Wir erstellen auch eine minimaltische Webapplikation zur Darestellung, in die die Smartphones dann ihre Daten senden.

Das waren mal die rudimentären technischen Überlegungen, die ich bislang noch nirgendwo geäußert habe. Mal sehen was Stefan dazu sagt :-) Alle anderen bitte ich wieder um Kommentare per Email an stefan@3-schweinehun.de.

Ja ich weiß, auf die Anforderungen Stefans in seinem Blogpost bin ich diesmal wieder nicht eingegangen, das werde ich im nächsten Post machen. Ich glaube aktuell noch, dass diese unabhängig von den hier geschilderten Ansätzen sind und in allen Varianten realisiert werden können. Wir werden sehen…

Trainingsdokumetation und -analyse: Mein Status

Wed, 10 Apr 2019 08:00:00 +0200

Nach beinahe vier Jahren des Schlafens erwacht nun dieser Blog wieder zu neuem Leben. Dies ist hauptsächlich Dr.Stefan Dillinger zu verdanken, dessen Blog Podcast | Running | Science in Folge noch Erwähnung finden wird.

3 Schweinehunde

Es geht nun nicht mehr um die Entwicklung von Mercator, jenes Projekt ist aktuell nicht in Wartung. Auch sonst hat sich in meinem Leben so einiges verändert. Insbesondere für diesen (und vermutlich auch einige folgende) Posts relevant ist Wissenschaftspodcastkonferenz Ganzohr, und davon die Ausgabe im Jahr 2017. Bei jener saß ich mit 3 weiteren Herren abends in einem netten Innsbrucker Lokal an einem Tisch. Als wir gerade (wieder einmal zuviel) gegessen hatten, meinte einer, Dr.Dominic Helm, er sollte wieder zu trainieren beginnen. Der oben bereits genannte Dr. Stefan Dillinger bot an, ihn zu trainieren. Sowohl ich als auch Tobias Lakemann-Grömcke wollten auch wieder zu trainieren beginnen. Innerhalb weniger weiterer Minuten war dazu ein Podcastprojekt entstanden, die 3 Schweinehunde. In dessen Nullnummer - gleich im Lokal aufgenommen - kann man noch nachhören, wie sich das zugetragen hat und lernen, dass wir uns commited haben, monatlich über unseren Trainingsfortschritt am Weg zum Halbmarathon 2019 im Oktober in München zu berichten.

Leistungserfassung

Gut 1 1/2 Jahre später stecken wir voll im Training, auch ich bin noch mit Begeisterung dabei. Ich laufe aktuell bis zu vier mal in der Woche, und zeichne zum Beweis - und zur Analyse - meine Läufe auf. Dazu verwende ich eine Garmin Forerunner 235, die meinen Puls und meinen GPS Track aufzeichnet. Weiters kommt ein Stryd Powersensor zum Einsatz. Mit diesem wird unter anderem die sekündlich die gemessene Leistung an die Uhr übertragen. Es werden auch noch weitere Werte, wie die Bodenkontaktzeit ermittelt, diese werden, falls sie in späteren Posts eine Rolle spielen, dann dort erläutert.

Auswertung

Die erfassten Daten übertrage ich, sobald ich wieder zu Hause bin, zu Garmin per Android App übertragen. Von dort lasse ich Daten weiter zu Strava senden, wo wir eine Laufclub 3 Schweinehunde gegründet haben, dem die geschätzten Leser:innen gerne beitreten dürfen.

Das ist noch nicht alles, die Daten werden auch an Stryd gesendet, auf der Webseite des Stryd Powercenter können die Leistungswerte analysiert werden. Dies ist übrigens bei Strava nicht möglich. Bei Garmin sollten Sehhöhe, Geschwindigkeit, Herzfrequenz, Leistung, Kadenz, Bodenkontaktzeit, Vertikale Bewegung pro Schritt, Beinfedersteifigkeit dargestellt werden, dies ist allerdings nicht bei allen Läufen der Fall, ich kann derzeit kein Muster erkennen, wann es funktioniert und wann nicht.

Die Aktivitäten erzeugen auf dem internen Speicher der Uhr auch .fit-Files. Dabei handelt es sich um ein komplexes, binäres, aber dokumentiertes Datenformat. Die Dateien lassen sich auch ohne weitere Software per Datenkabel von der Uhr direkt auf einen Computer übertragen. Ich mache dies und importiere die Daten dann in Golden Cheetah, eine quelloffene, freie Leistungsanlysesoftware von beeindruckender Komplexität, die ich zwar regelmäßig verwende, die ich aber noch bei weitem nicht vollständig ausnutze. Ich habe mit ihr aktuell auch ein Problem, die Daten des Leistungsmodelles werden nicht kontinuierlich aktualisiert.

Ich habe zeitweilig auch das Webservice Runalyze zur Leistungsanalyse verwendet, mache das aber aktuell nicht mehr. Ebenso verwende ich das Webservice Trainingpeaks aktuell nicht mehr.

Ich trage rudimentäre Daten absolvierter Läufe in einen Trainingsplan in Form eines Spreadshirts ein. Diesen Trainingsplan hat uns dankenswerter Weise Stefan erstellt und sogar persönlich an uns angepasst.

Vor einigen Monaten habe ich den Static Site Generator Jekyll um die Möglichkeit erweitert, Trainingsdaten zu publizieren. Dies Projekt nannte ich Tracker. Die Software ist frei und open source, es gibt auch eine Demosite, auf der einige meiner Läufe publiziert sind. Das Projekt war aber mehr ein Spaßprojekt, es war noch ohne Leistungsanalysemessung und ich habe es nie ernst zur Analyse verwendet. Ich fand es aber sehr erfreulich, dass mit relativ geringem Aufwand eine recht hübsche (siehe Beispiel) Dokumetation der Läufe selbst gehostet stattfinden kann, ohne sich auf proprietäre, kommerzielle Services wie Strava stützen zu müssen.

Insgesamt habe ich aktuell einen sehr guten Plan, auch gute Kenntnis über meinen Leistungsstand, meine Publikation per Strava stellt mich aber nicht zufrieden. Auch meine private Dokumentation ist verbesserungswürde, so erfasse ich aktuell etwa nicht, welche Schuhe eigentlich wie lange benützt wurden und ob sie etwa schon zu ersetzen wären.

Immer wieder erzähte ich in letzter Zeit Stefan von der Idee, die Analyse und Dokumatation auf eine bessere Basis zu stellen. Bei einer weiteren Podcastingkonferenz, der Subscribe 10 war er plötzlich von der Idee angetan. Und das so sehr, dass er einen ausführlichen Blogpost mit seinen Anforderungen an eine selbst gebaute Trainingsdokumentations und -analyse Software erstellte.

Auf diese Anforderungen gehe ich heute noch nicht ein. Dies war einmal nur die Vorgeschichte. Im nächsten Post wird es um einige technische und strategische Überlegungen gehen, die ich in den letzten Wochen angestellt habe.

Bis dahin viel Freude mit dem Lesen von Stefan’s Post, dem Grübeln über eigene Anforderungen. Feedback bitte gerne an mich per Email an stefan@3-schweinehun.de.

Die Programmierung tritt einen Schritt zurück

Mon, 27 Apr 2015 08:00:00 +0200

Marketing und Organisation

Diese Woche hat es mit einigen organisatorische Arbeiten in sich:

Wir arbeiten weiter an unserer Vertriebsvereinbarung
Beim Darstellen des Upselling kam es zu einer Ausnahmesituation, wenn das Produkt ein vom Vertriebsmitarbeiter ad-hoc erfundenes Produkt ist
Beim HP Spotlight Event stellen wir Mercator in einem Vortrag vor und stoßen auf reges Interesse. Bemerkenswert: Seit mehr als einem Jahr sind wir auf keinen Menschen gestoßen, der einen mit Mercator vergleichbaren Webshop gesehen hat.
Bei der Benachrichtigung über Videochatstarts gab es einen Fehler, der nun behoben ist.
Bei der Installation eines Entwicklerlaptops sind wir auf einen Fehler in der Installationsanleitung gestoßen.
Eine Kunde äußerte den Wunsch, dass seine Kunden doch informiert werden sollen, wenn der Vertriebsmitarbeiter tippt. Wir stellen nun keine Animation dar, wie dies in anderen Chatapplikationen der Fall ist, sondern den bislang getippten Text. Damit hier nicht unnötig Daten übertragen werden, erfolgt die Übertraging throtteld, also gedrosselt. Der Textstring wird nur übertragen, wenn sich in der letzten Sekunde an seinem Inhalt etwas geändert hat und die Übertragung erfolgt auch nur einmal pro Sehunde.
Der Konversationsstart wurde neu gestaltet.
Ein Fehler im Algorithmus, mit dem wir nach Daten im Icecat Katalog gesucht haben, wurde behoben.
Das Schnittstellendiagramm wurde angepasst, die Darstellung rund um STUN/TURN Server und Palava war unvollständig.

Schnittstellendiagramm

Zwischenspurt

Mon, 20 Apr 2015 08:00:00 +0200

Vielschichtige Verbesserungen

Scheinbar immer, wenn wir eine ruhigere Woche erwarten, wird dieselbe vielseitiger und intensiver als erwartet. Diese Woche sind Verbesserungen in der Usability gelungen, die wir nicht in dieser Menge und Qualität erwartet haben.

Aus vergangenen Konversation ist es nun per Mausklick für den Kunden möglich, nach einem Berater zu rufen.
Die Navigation für den Konversationsstart wurde verändert.
Wir haben die Konversationsliste für den Vertrieb verbessert, indem wir sie durchsuchbar und filterbar gemacht haben und die Auswahl der dargestellten Spalten überarbeitet haben.
Es ist nun möglich, aus Icecat produktweise einen manuellen Import auszulösen.
Beim Debuggen mussten wir feststellen, dass Icecat bei einem Referenzkunden nicht zu allen Produkten vollständige Daten liefert. Diese müssen vom Kunden manuell ergänzt werden, was im Produktmanager aber problemlos möglich ist.
Der Designer hatte Verbindungsprobleme, die in fehlerhafter lokaler DNS-Auflösung lagen, wir hatten ein Routingproblem im Shop befürchtet.
Für den Icecat Import lässt sich die Artikelnummer, mit der bei Icecat gesucht wird, nun produktweise im Feld alternative Artikelnummer überschreiben.
Das Routing für die Bechloem-Verbrauchsmaterialiensicht wurde geändert.
Angebote und Konversationen erscheinen nun sowohl für Berater als auch für Kunde übersichtlicher in separaten Registern im Browser.
Beim Eintreffen eines neuen Videochatpartners läutet es nun bei den angemeldeten Vertriebsmitarbeitern genauso reihum wie beim Konversationsstart.
Der Button zum Hinzufügen eines Artikels in den Warenkorb wurde neu gestaltet und wird nun über die gesamte Applikation hinweg konsistent verwendet.
Kategorien werden nun automatisch reaktiviert, sobald im Update Job ein neues aktives Produkt zugeordnet wird. Dies ist nicht der Fall, wenn die Kategorie sich im Status abgeschaltet befindet.
Produkte aus den Produktvorschlägen können nun durch Klick auf einen Button in das zuletzt aufgerufene Angebot übernommen werden.
Beim Kopieren eines Komplettangebots ist ein Fehler aufgetreten, wenn in wenigstens einer der Angebotspositionen ein Artikel ad hoc vom Vertriebsmitarbeiter erfunden wurde.
Der Kopfteil einer Konversation wurde übersichtlicher gestaltet.
Für Download link haben wir die Content Type Spoofing Detection deaktiviert. Dieses Feature dient in Rails dazu, dass Seiten nicht in andere Webseiten eingebaut werden dürfen. Eben genau dies möchten wir aber mit dem Cobrowsing auch für die Seiten im CMS erlauben.
Im Bereich der Shop Domain gab es einen Routingfehler, den wir behoben haben.
Sessions haben nun eine Gültigkeitsdauer von einem Monat. Bislang wurden Session Cookies mit dem Schließen des Browsers deaktiviert. Das ist für Kunden unpraktisch und wurde daher geändert.
Beim Löschen von veralteten Usern und Bestellungen wurde zu aggressiv vorgegangen. Ein Entwickler hatte die Methoden delete und destroy verwechselt. Destroy löscht - obwohl der Name dramatischer wirkt - Datensätze unter Berücksichtigung der Restriktionen, die in den Relationen des Modells definiert sind. Delete löscht ohne Rücksicht auf Konsequenzen. Dies ist ein Fehler, der in einem Produktsystem zu sehr unangenehmen Situationen geführt hätte. Benutzer hätten ihre Accounts und damit den Zugang zu Ihren alten Bestellungen verloren. (Es lag aber wenigstens keine Sicherheitslücke vor, die abhängigen Datensätze waren ‘nur’ verwaist).
Die Produkt- und die Kategorienansicht sind nun voll responsive.
Unsere Vertriebskostenplanung schreitet voran.
Für ein Referenzsystem wurden einige Designänderungen durchgeführt.
Ein Bug beim Update von Beschreibung und Lieferzeit in Angeboten wurde behoben. Nur die Artikelnummer und der Preis wurden richtig ermittelt.
Auf allen Sichten werden nun Angebote unmittelbar aktualisiert, wenn diese von Vertriebsmitarbeiter geändert werden.
Bei der Kundensicht des Angebots hatte sich ein Darstellungsfehler beim Rabatt eingeschlichen.
Der Kopfrabatt wird nun nach der Summe der Positionen ausgewiesen.
Im Angebot haben wir auf den Live-Editor umgestellt und ersparen den Vertriebsmitarbeitern damit einige Klicks.
Angemeldete User mit der Rolle Contentmanager sehen Webseiten, die sich im Status “in Arbeit” befinden, in der Navigationsleiste und können diese auch aufrufen und damit testen, bevor sie veröffentlicht werden.
Vertriebsmitarbeitern können nun Artikel aus dem Produktkatalog in den Produktvorschlag übermitteln. Damit haben wir hier eine deutliche Beschleunigung des Workflows erreicht.

Mit einem Klick werden Artikel vorgeschlagen…

…mit einem weiteren angeboten

Zur Erhöhung des Vertrauens in die Applikation kann per Button “Kundensicht” diese dargestellt werden (s.o.).

Polieren

Mon, 13 Apr 2015 08:00:00 +0200

Vermischtes

Auch diese Woche konnten wir wieder einige Verbesserungen durchführen.

Wir sind nun in der Lage, mit einer vom Kunden bereitgestellten Schriftartendatei, serverseitig PDFs zu erzeugen.
Wir haben mit einem Referenzkunden weitere Tests und Schulungen durchgeführt.
Für einen Referenzkunden wurden einige Änderungen am Design der Seite durchgeführt.
Im Administrationsbereich werden der zuletzt gewählte Baustein, das zuletzt gewählte Verzeichnis und die zuletzt gewählte Webseite in der Session gespeichert, um unabhängig vom Navigationsweg diese Elemente beim Aufruf des Contentmanagers vorselektieren zu können.

Automatische Anwahl der zuletzt selektierten Webseite, des Verzeichnisses und des Bausteins

Der Webseitenstatus ist nun unmittelbar aus dem Contentmanager änderbar.
Es gibt für den Berater aus der Konversation einen Link zur Berarbeitung des Userprofils.
Bei der Angebotsanlage wurde das Grundformular mehrspaltig angelegt, um die Eingabe einfacher zu gestalten.
Ein Fehler in der Preisfindung bei der Angebotslegung wurde behoben.

Wieder mal Kleinvieh

Mon, 06 Apr 2015 08:00:00 +0200

Bugsquashing

Einer unserer Referenzkunden hat diese Woche gleich mehrere Leute zum Test seiner Mercator-Instanz involviert und uns eine stattliche Liste geliefert:\ gleich 51 Fehler, Unzulänglichkeiten und Änderungswünsche. Das ist einerseits viel, andererseits ist nun die gesamte Applikation von mehreren Personen, die nicht im Projekt involviert sind, ausgiebig getestet worden.

Alle Fehler konnten bereits diese Woche behoben werden. Eine derartige intensive Phase der Fehlerbehebung wird wenig charmant als “Bugsquashing” bezeichnet.

Auch der Großteil der Unzulänglichkeiten ist behoben, bei den Änderungswünschen haben wir uns auf jene beschränkt, für die wir einen Kundennutzen auch für andere Kunden erkennen können. Für die anderen Wünsche haben wir den Aufwand geschätzt, verpreist und angeboten. Es darf geraten werden, mit wie vielen kostenpflichtig Änderungen wir beauftragt wurden. ;-)

Die relevanten Änderungen

Suchergebnisse wurden fälschlicherweise rechtsbündig dargestellt.
Verbesserungen am Layout des Contentmanager wurden durchgeführt.
Partner Logos können nun auf mehrere Arten eingebunden werden: Im Footer; an den Inhalt der Seite relativ gebunden; und an fixer Position am Bildschirm. Sie verschwinden bei zu schmalem Bildschirm (zum Beispiel am Smartphone dann hinter dem wichtigeren Inhalt der Seite).
Bei den Twitter Boostrap Assets haben wir einige Dateien aus dem Code Repository entfernen können.
Bei Berechtigung der Konversationserzeugung ist eine Regression aufgetreten, interessanter weise diesmal nicht bei uns, sondern im Hobo Framework. Wir haben den Fehler eingemeldet und die Behebung ist bereits in Arbeit. Mittlerweile haben wir einen Workaround mit gerade mal 3 zusätzlichen Zeilen Code in unserer Applikation. Das Schreiben der Zeilen hat weniger Zeit benötigt als das Berichten hier in diesem Artikel. Viel mehr Zeit hat das Auffinden des Fehlers benötigt, da wir sehr lange geglaubt haben, dass der Fehler bei uns liegen muss. Vielleicht ist etwas mehr Selbstvertrauen angebracht!
Formulare, die per Ajax abgesendet wurden, wurden mit dem Absenden nicht geleert. Zum Beispiel blieb nach dem Senden einer Chatnachricht diese im Formularfeld steht, was störend und verwirrend ist.
Leere Registerreiter in der Produktdetailsicht werden nun ausgeblendet.
Es gibt eine zusätzliche Navigation zu den Registerreitern vom oberen Teil der Produktansicht.
Die Größe der Photos in Produkt- und Kategorienansicht wurde angepasst.
Die Produkt Mini Card wurde besser gestaltet, es handelt sich dabei um die Produktdarstellungen in den Relationen zu Zubehör, verwandten Produkten, etc.
Versteckte und archivierte Seiten wurden fälschlicherweise in der Navigation eingeblendet.
Archivierte Seiten konnten bei Aufruf per URL noch dargestellt werden.
Die Darstellung der Navigationsleiste wurde verbessert.
Der Video Chat Link und der Link zum Starten einer Konversation wurden als Tags implementiert und werden nun einheitlich in der gesamten Anwendung verwendet.
Langtexte können nun gekürzt dargestellt werden. Dazu gibt es eine Einstellungsmöglichkeit im Administrationsinterface.
Der Platzhalter für fehlende Bilder wurde durch ein transparentes Bild ersetzt.
Administrationsbereich und Vertriebsbereich sind nun voll responsive.
Untermenüs werden nun auch in der responsiven Darstellung korrekt angezeigt.

Responsives Submenü mit den neuen einheitlichen Buttons für Chat und Beratungsstart

Die Navigation im Administrationsbereich, im Vertriebsbereich und im Vertragsbereich wurde überarbeitetet, vereinheitlicht und vereinfacht.
Ein Routingfehler wurde behoben: Beim Aufrufen der Shopdomain wurde auf die CMS-Domain umgeleitet statt auf die Kategorienübersicht.
Kategorien können nun auch temporär stillgelegt werden. Sie werden dann auch durch das Vorhandensein von aktiven Produkten beim nächsten Updatejob nicht mehr aktiviert.
Weitere Ajax Forms wurden beim Absenden nicht aktualisiert.

Volldampf

Mon, 30 Mar 2015 08:00:00 +0200

Verbesserung an vielen Stellen

Nachdem die Woche gefühlt relativ wenig Fortschritt gebracht hat, sind wir in diesen Woche an vielen Fronten weiter gekommen:

Im Importjob gab es einen Fehler bei der Ersetzung von Zeichen. Im Zusammenhang mit dem im Artikel gemachten Fortschritt ‘Unicode schlägt zurück’ konnten wir diesen Teil des Jobs ersatzlos streichen, da wir alle in Icecat verwendeten Unicode Zeichen nun problemlos importieren können.
Sowohl beim Importjob der Icecat-Daten und als auch bei dem aus Mercator haben wir Verbesserungen durchgeführt, insbesondere loggen wir nun weniger Erfolgsmeldungen, aber mehr Fehler- und Warnmeldungen, was die Lesbarkeit des Logs deutlich erhöht.
Die Benachrichtigung, dass eine Webseite einen Platzhalter aus der Vorlage nicht befüllt, erfolgt nun nicht mehr für alle sichtbar auf den Webseite, sondern nur mehr als Kommentar, das heißt, sie ist für Entwickler noch im Quelltext der Webseite zu finden.
In B2C Shops, also solche, die (auch) an Privatkunden verkaufen, werden nun die gesetzlich vorgeschriebenen Informationen aus dem FAGG (Fern- und Auswärtsgeschäfte-Gesetz) dargestellt und das Lesen ist vom Kunden durch Anklicken einer Checkbox und Absendes des Formulars durch Klick auf einen Button zu bestätigen.
Die Preisfindung berücksichtigt nun konfigurierte Artikel korrekt.
Artikel können als nicht versendbar gekennzeichnet werden. Dann ist nur die Abholung in einer Filiale für den Kunden im Webshop auswählbar.
Bestellungen führen in ihren Positionen nun die Information, aus welchem Inventar bestellt wird.
In der Produktansicht und in der Katalogansicht sind Inventare selektierbar, sofern der Shop entsprechend konfiguriert ist.
Die E-Paymentfunktion ist einfach deaktivierbar.
Auf den Seiten des CMS steht ein weiterer Slider zur Verfügung.
Shops können - je nach Konfigurationseinstellung - Brutto-Preise oder Netto- und Brutto-Preise darstellen
Sessions des Nachrichtensystems sind nun systemspezifisch. Anders formuliert wird unser Messagingserver damit mandantenfähig. Wieder anders formuliert benötigen wir damit für all unsere installierten Instanzen von Mercator nur einen Faye-Messagingserver.
Systeme haben nun eine System ID und einen Systemschlüssel. Damit können durch Unbefugte keine Nachrichten an Messagingserver, die nicht unter Ihrer Kontrolle stehen, gesendet werden.
Die Konfiguration des Miranda-Webshops wurde fortgesetzt und für’s erste (das heisst bis auf weitere Kundenanforderungen) abgeschlossen.