Blog - Hannes Pries - Webdeveloper Blog - Entwicklung mit Shopware, PHP, HTML5 und JavaScript

Java: Eine Fat Jar mit allen Dependencies

Manchmal ist es echt unpraktisch viele kleine JAR-Dateien zu haben und man hätte gerne alles in einer großen. Keine Class-Path Probleme mehr, einfaches Deployen und ein Single-Point-Of-Failure.

Mit Maven geht das zum Glück sehr einfach. Spring Boot und Meecrowave haben eigene Plugins mit denen man auch sehr gut arbeiten kann und die dem Beispiel hier vorzuziehen sind.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>de.hannespries.time.gui.MainFrame</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>

Bremen 2018: Behind the scenes

Am 30.6. war wieder Oldtimer Really in Bremen. Diesmal hatte ich frühzeitig zwei Thinkpad T500 organisiert, falls es Probleme bei der Bereitstellung anderer Notebooks geben sollte. Die Software hatte ich seit dem letzten Jahr nicht mehr groß angefasst. Nur die aktuelle Version der Client-JAR zu finden brauchte etwas. Aber nachdem ich die ganz unverhofft im Projekt-Verzeichnis fand, lief dann alles ohne wieder ohne Probleme.

Wieder 5:00 los und.. KEIN REGEN!!!!!! Auch eine weitere Besonderheit kam hinzu. Das 2. Zeitfahren wurde mit einem anderen System gemessen und später sollten die Ergebnisse beider Systeme für das Gesamtergebnis kombiniert werden. Ein kleines PHP-Script lass alle Renn-Ergebnisse als CSV ein und wertete diese aus. Alle Fahrer die nicht alle 3. Zeitfahrten absolviert hatten.

Nach dem Tag hab ich mir vorgenommen, die Integration mit anderen Systemen zu verbessern. Auch die Clients könnten dann ihre Auswertungen nicht nur per REST-API übermitteln, sondern auch eine CSV generieren, die dann ausgelesen werden kann. Der Import wäre dann so flexibel, dass er auch CSV-Dateien anderer Systeme importieren könnte.

Ein anstrengender Tag, aber die Messungen liefen wirklich gut und es gab kaum Fehlmessungen, durch Fahrtzeuge die zu dicht am Messbereich parkten.

Wer also bei Rennen oder ähnlichen jemanden braucht, der die Zeitmessungen und Auswertungen übernimmt, kann sich vertrauensvoll an die Switch GmbH wenden... auch was Temperaturüberwachung angeht.

Aufbauen

Surface als Messstation, der Client läuft noch in Eclipse

SAAT RFID Reader und Bananen-Auto

Messdaten mit dem Server syncen

In der Natur, aber mit Strom

3 Rennen mit Kontrollrechnung per Hand

Mehr B2B, Projekte und Stillstände

Ich wollte ja das Order-Export in Richtung XSLT bearbeiten... nun wird alle sehr vollständige Überarbeitung daraus. Besseres Export verhalten nach Änderungen an Bestellungen.. auf über das Backend. Insgesamt soll alles etwas flexibler werden und für mehr B2B-Anwendungsfälle passend gemacht werden.

Andere Projekte gehen auch nicht so wirklich weiter. Das Cashless-Paymentsystem ist erst einmal auf HOLD. Ich habe zwar schon fertige Pläne, um es auch als ganz normale Kasse (mit Barcode-Scanner) nutzen zu können und auch die Bons dokumenten-echt als signierte PDF parallel zum Druck speichern zu können.
Auch wollte ich mal eine wirkliche Präsentation (vielleicht mit Video) dafür basteln. Am Ende könnte ich mit wenig Zeit noch ein gutes und fertiges Produkt daraus machen. Leider fehlt die Zeit oder das Geld um bei der Zeit das Projekt neu zu priorisieren.

Aber erst einmal steht auch wieder Bremen am 30.6. an. Diesmal bewaffnet mit unter anderen 2 ThinkPad T500 für echt wenig Geld (Die sind für mich da auch Verbrauchsmaterial.. bei höheren Stückzahlen einfach mal wegen dem Preis direkt anfragen. Auch wegen den passenden Akkus und WLAN-Karten dazu).

Im Hintergrund bei der Artikelseite läuft mein "Eigenschaften im Listing" Plugin als Dataprovider ohne eigene Ausgabe.

Bremen 2017 - Switch Time-System in Action

Am 24.6. war es wieder so weit und das Bremer Oldtimer-Rennen stand wieder für mich vor der Tür. Wie im Jahr davor sollte meine Aufgabe sein, die Zeitmessungen (jeden Falls einen Teil davon) durch zu führen und am Ende die Gewinner benennen zu können. Klingt erst einmal ganz einfach aber für diese Sache, die an sich voll automatisch laufen sollte, ist immer viel mehr zu tun als man so denken würde.

Dafür muss man das Grund-Setup kennen und verstehen. Bei dem Rennen nehmen 170 Autos teil. Jedes dieser Autos wird mit einem aktiven RFID-Tag ausgestattet der den Tag über die Kennung des Autos aussendet. Die Veranstaltung besteht genau genommen aus 3 Rennen. Da es natürlich unfair wäre, bei Autos von 1920 bis 1970 auf Minimalzeit pro Strecke zu fahren, wird immer auf eine Richtzeit gefahren. Der Fahrer, der am dichtesten an der Zeit dran ist gewinnt. Also kann der zweit etwas langsamer als die Zeit sein und der 3. etwas schneller. Es nur um die absolute Differenz.

Am Anfang und am Ende jeder Strecke steht dabei ein RFID-Reader, der alle Autos erfasst, die vorbei fahren.

RFID sendet aber bei einem aktiven Tag mehr als die Sekunde sein Signal und die Reader decken mit ihren Antennen einen größeren Bereich ab. Es funktioniert also grundlegend anders z.B. eine Lichtschranke. Man bekommt also eine Menge an Messwerten, die vom Auto gesendet werden, während es vorbei fährt. Daraus wird nach dem relativ einfachen Prinzip von Zuerst-Gesehen und Zuletzt-Gesehen der Mittelwert berechnet.

Dabei kann an sich schon genug schief laufen. Gerade wenn man kleine und kurze Strecken hat. Wenn das Auto schon soweit beim Start an den Reader heran fährt und schon Messwerte erfasst werden, aber das Auto noch nicht losfährt. Dann wird die Zeit in der das Auto steht, mit Pech mit in die Zeitberechnung mit hinein gerechnet.
Aber auch die Chips und Sender der Tags sind nicht immer zuverlässig. Auch wenn sie 100 mal die Sekunde senden sollen, kann man nicht immer sicher sein, dass es keine Einbrüche in dieser Frequenz gibt. Autos aus Metall können außerdem sehr gut Abschirmen und so die Sendeleistung stark beeinflussen. Bautechnische Probleme wie schlechte oder defekte Schalter zum Ein- und Ausschalten kommen noch dazu.
Diesmal hatten wir im Vorwege das Problem, dass allein durch die Bewegungen der Tags in der Kiste sich einige einschalteten und anfingen zu senden und so Tags empfangen wurden, die gar nicht zum Rennen gehörten.

Durch einen guten Aufbau und ein wenig mehr Programm-Logik kann man fast alle Probleme unter Kontrolle bringen. Aus der Menge der Messpunkte werden konkrete Werte errechnet. Mehrfachmessungen eines Autos werden entfernt und fehlende Messungen werden herausgesucht. Das benötigt etwas mehr Rechenleistung, weswegen die Messstationen mit etwas Leistungsfähigeren Notebooks ausgestatteten sein müssen.

Damit kommen wir erst einmal wieder zurück an den Anfang. Die Vorbereitung und was diesmal alles zu tun war.

Vorbereitung:

Nachdem im letzten Jahr mehr oder weniger spontan Notebooks mit dem Mess-Client ausgestattet wurden und es zu vielen Problemen kam:

- Fehlende Runtime-Umgebungen
- andere Server-Anwendungen die Ports blockierten
- Notebooks auf denen schon so viel installiert war, dass sie langsam waren
- Akkus die nicht mehr lange durch hielten und deswegen immer Strom nötig war (den es nicht immer gibt)

Ich fing also schon 2 Monate vorher an, das Problem in Angriff zu nehmen. Ich entschied mich die Hardware diesmal komplett selbst zu stellen und somit etwas mehr Sicherheit zu haben. Das Alienware sollte diesmal nicht benutzt werden, da es schwer ist und man es nicht mal schnell zur Seite nehmen kann, wenn es regnet. Außerdem ist es einfach nicht dafür gedacht, über den Akku zu laufen.. jedenfalls nicht langer als 15min.
Da ich für Notfälle aber eine Entwicklungsumgebung haben wollte, damit ein Fehler nicht ein Rennen versauen kann oder die Auswertung unmöglich macht, entschied ich mich mein Surface mit zunehmen. Es ist relativ Wetter-beständig und der Akku hält sehr lange. Die Rechenleistung ist nicht wirklich groß, aber ausreichend.

Damit waren meine eigenen Notebook Vorräte aber erschöpft und extra welche Kaufen würde sich nicht lohnen. Also kam ich auf die Idee meine Kontakte als Mitarbeiter bei Notebooks Wie Neu zu nutzen. Ich konnte mir 2 Lenovo Thinkpad T410 leihen. Mit i5, 4GB RAM waren die mehr als schnell genug und Thinkpads sind auch stabil genug, so das ich mir wegen Regen nicht zu viel Sorgen machen musste. LAN und USB Anschlüsse waren auch vorhanden. Der Akku hielt mehr als genug und am Ende waren die Akkus nicht mal halbleer, obwohl die Thinkpads ca. 2h damit beschäftigt werden durchgehend Daten abzurufen und in eine MySQL-Datebank zu schreiben.

Nur eine Sache störte mich etwas.. das war Windows 7. Egal was viele im Internet so schreiben.. bei der Bedienung ist Windows 10 sehr viel schneller und intuitiver als Windows 7. Aber da alles wie Java 1.8 und MySQL laufen, ist es nicht so schlimm, weil die Client-Software sowie so rein über die CLI bedient wird. Eine GUI Version existiert, ist aber noch auf eine Verbindung zum Server angewiesen, was da nicht gegeben war. Ein portabler UMTS-WLN-Router wäre eine gute Lösung gewesen, aber die Idee kam mir zu spät und ich wollte ja gerne den Server bei Problemen schnell ändern und fixen können. Was mit einer lokalen Instanz, die man direkt in der IDE hat, natürlich sehr viel schneller und einfacher geht als mit einem System das auf einem Server im Internet läuft.

Vielleicht bin ich nächstes Jahr mal mutiger. Es hätte auch noch andere Vorteile für die Veranstalter.. aber dazu später mehr.

Die Liste der Teilnehmer konnte ich am Abend vorher importieren und dabei noch 2 kleine Fixes einbauen. Deswegen wollte ich die Liste gerne schon vorher haben.
170 Autos. 170 importierte Rennteilnehmer am Ende. Alles perfekt.

Ich hatte also 4 Notebooks (das Alienware war als Fallback dann doch dabei), Reader, Netzwerk-Kabel und einen Switch. Was man aber immer dabei haben sollte, ist auch Essen und Trinken. Wasser und Energiedrink. Eines für den Durst und das andere für Energie. IBUs für Notfälle und natürlich das Smartphone für Navigation und Informationsbeschaffung. Beim Essen kann man sich ruhig abends vorher was kochen, denn gutes Essen macht es einen sehr viel einfacher, wenn man morgen um 4:15 aufstehen muss und dann noch kein Frühstück hatte.

Immerhin war das Wetter gut und nicht so verregnet wie im letzten Jahr... jeden Falls am Anfang

Der Tag:

Um 4:45 war ich in Stockeldorf bei "die Halle" wo die Switch GmbH ihren Sitz hat. Die Mitarbeiter wuselten durch die Gegend und packen alles in den VW Bus was man so brauchte. Dann wurde ein Karton mit Tags hochgehalten und gefragt, ob die auch mit sollen. "Nein, das sind die, die nicht funktionierten und ausgewechselt wurden".
Klingt erst einmal nicht so schlimm, aber wenn man bei 170 Teilnehmern 30 Tags für jeweils drei Rennen austauschen muss.. also 90 Einträge per Hand bearbeiten, dann klingt es nicht mehr gut. Am Ende wurden also diese Ausgetauschten alle geöffnet und Batterien getauscht. Am Ende waren es pro Rennen nur jeweils ca. 6 Tags, die per Hand übergetragen werden mussten.

Hier fiel mir auch auf, dass die Tags dieses Jahr gefühlt sehr viel Fehleranfälliger waren. Beim Testen wurden noch 4 ausgetauscht, weil sie nicht vom Reader erkannt wurden. Die Schalter schalteten in den Karton bei jeder kleinen Bewegung wie sie wollten.

Und dann kam der Regen. Viel Regen. Alles wurde unter die offene Heckklappe des VW-Bus gestellt und das Surface wechselte erst einmal in eine Plastiktüte.
Es war zum Glück nicht wirklich kalt. Nur sehr sehr nass. Wer glaubt das Regen und die Nässe nur immer von oben kommt, irrt sich. Tropfen fallen auf Tische und spritzen dann in alle Richtungen. Am Ende ist doch alles nass.
Aber es gab auch positives zu berichten. Weniger Tags streuten in den Messbereich und die Erkennung war dieses mal sehr viel besser. Das andere Team meldete sich schon kurze Zeit später und meldete, dass alles laufen würde. Ich bin immer sehr unruhig wenn ich bei so etwas nicht in der Nähe sein kann, um möglicherweise auftretende Fehler zu beheben. Ich kenne das System zu 100% und einfach unerfahrene Benutzer damit los zu schicken.. dazu gehört sehr viel Vertrauen in die eigene Software dazu.
Am Ende war alles super. Alles hatte beim ersten Rennen funktioniert und das Thinkpad konnte zeigen was es konnte. Beim Surface braucht ich so 15min mit Client in der IDE um die Daten zu übertragen. Dabei liest der Client und schreibt der Server auch in die selbe Datenbank, was auch nochmal bremst. Das Thinkpad brauchte gerade mal 4-5 Minuten. Schnelle CPU, schnelles Lesen von der Festlatte. Das Schreiben in die DB auf dem Surface war dann auch sehr entspannt, weil nebenbei nicht so viel gelesen oder gerechnet werden musste. Also Server und Entwickler-Rechner hat sich das Surface mehr als bewährt. Das selbe gilt auch für die Thinkpads als Messstationen-Clients.

Das 2. Rennen war dann die kritische Phase, die dann aber auf Grund der stabilen Bauweise der Reader und viel Nachrechnen und eliminieren von Fehlmessungen, am Ende doch gut ging. Wir hatten kaum Zeit zum Aufbauen, ein Reader lief an einem Diesel-Generator und 50m Lan-Kabel. Die ersten Autos wurden manuell gemessen mit der eingebauten App vom Time-System, während wir nebenbei den zweiten Reader aufbauten, der dann am Alienware lief. Sturm, Regen und noch mehr Regen. Wir saßen im Bus und nur die Kabel zu den Readern im Regen gingen nach draußen. Ich wüsste zwischendurch nicht ob der Reader am Start noch lebte und Daten sendete. 1,5h später war der Regen vorbei und man ordnete sich und guckte mal wieder auf die Terminal-Ausgaben auf dem Surface. Alles lief super. Es fuhr gerade das letzte Auto vor und der Reader meldete den Tag also ob vorher nicht gewesen wäre. Sein Netzteil hing so im Regen und ein Teil des Kabel lag vorher schon blank. Aber kein Aussetzer bei der Datenerfassung. Ich war wirklich stolz auf den kleinen tapferen Reader.
Das Netzwerk-Kabel wurde auch nebenbei als Streckenbegrenzung verwendet. Von der Planung her eine Katastrophe, aber mit den Fallback-Lösungen konnte man alles retten.

Danach ging es zur Test-Strecke von Mercedes und das 2. Thinkpad übernahm das Rennen dort. 1. Rennen war in 20min fertig. Ich hab bevor Korrektur-Funktionen über die Daten liefen immer lieber noch einmal die Daten gesichert. Berechnen lief schnell.
Das 2. Rennen brauchte mehr Zeit. über eine Stunde, da ich viel bei den Korrektur-Funktionen nacharbeiten musste, die Fehlmessungen eliminierten und ich lieber 3 mal die Liste der gefahrenen Autos durch ging, um sicher zu sein, dass wirklich kein Auto übersehen oder nicht gemessen wurde.

Das 3. Rennen ging dann wieder sehr schnell und es gab keine Überraschungen.

Bestes Frauen-Team musste dann per Hand berechnet werden. Waren aber nur sehr wenige Teams, deswegen ging es. Der Gesamtsieger war aufwendiger, weil man über die gesamten drei rennen Rechnen musste, zum Glück sind es doch immer die selben Fehler die vorne liegen. Damit war es ausreichend die 9 Sieger der 3 Rennen zu nehmen und für diese die Werte der 3 Rennen auszuwerten. Kontrolle bei den 4. und 5. Plätzen zeigten gleich, dass von dort keine Konkurrenz mehr kam.
Auch fiel dabei auf, dass man kein großes Kopf-an-Kopf-Rennen hier hatte. Die ersten Plätze waren immer sehr eindeutig, eher am Ende des ersten Drittels konzentrierten sich die Zeiten auf eine geringe Zeitspanne.

Das Fazit:

Das Event lief sehr viel besser als das letzte Jahr und die Zeiten für die Auswertungen war sehr viel geringer. Die automatischen Analysen und Korrekturen von Fehlmessungen hat viel gebraucht und sehr viel besser und zuverlässiger funktioniert, als es per Hand war.
Trotzdem hätte ich gerne eine andere Lösung für das nächste mal. Die Tag an sich sind eine Fehlerquelle für sich und diese würde ich gerne eliminieren. Eine Lösung wäre eine Kamera gestützte Erfassungsmethode mit QR-Codes. Wie Lichtschranken, gibt es da aber Probleme bei parallel fahrenden Autos. Deswegen müsste man ein Gestell haben, um die Kameras von oben auf die Start- und Ziellinie gucken zu lassen. Dann muss man die Autos erkennen, da man so wirklich von vorderen Punkt des Autos messen kann und nicht nur die Position des RFID-Tags (was viele Teilnehmern nicht klar war, sich aber natürlich auf die Messungen auswirkt).
So ein System ist sicher zu bauen, aber braucht seine Zeit. Am Ende hätte man aber sicher gute Ergebnisse mit Beweisfoto.

Auch sollte alles so aufbaubar sein, dass die Technik die Autos nie verlassen muss. Mehr Schutz vor Regen und man kann schneller aufbauen, wenn nur noch Kabel verlegt werden müssen.

Ein großer Traum wäre es, es wirklich als Cloud-Anwendung laufen zu lassen, so dass die Clients direkt vor Ort über einen WLAN-UMTS-Router ihre Daten direkt an den Server schicken können. Vielleicht sogar kurz nach dem sie gemessen wurden. Damit hätte man auch die Möglichkeit eine Echtzeit Anzeige zu realisieren.

Nochmal im NBWN-Blog

Outdoor mit dem Time-System

In den nächsten Tage werde ich meinen Samstag in Bremen beim Oldtimer mit dem Switch GmbH Time-System in einen Blog-Post zusammen fassen. Es geht um RFID, Zeitmessungen, Notebooks als Werkzeug und nicht als Deko-Objekt, Thinkspads, Surface und viel viel viel Regen.

Strom für unterwegs

Manchmal hat man das Problem, dass man vor Ort keinen Strom hat. Notebooks lösen das Problem. Doof nur wenn man auch zusätzliche Geräte wie RFID-Reader oder Netzwerk-Switches mit versorgen muss. Ich werde Samstag mal ein Akku-Pack testen. Eigenlicht ist es für mobile Blitzanlagen gedacht, aber mit etwas Glück funktioniert es auch für andere Geräte.

Manuelle Zeitmessungen mit dem Switch GmbH Time-System

Zeitmessungen bei Rennen müssen nicht immer mit RFID gemacht werden. Man kann auch ganz einfach einen PC, ein Tablet oder ein Smartphone pro Messstation nehmen und eine Person muss nur auf die Teilnehmer-Nummer klicken/drücken, um eine Messung zu speichern.

Für die meisten Rennen im Amateurbereich ist die Genauigkeit mehr als ausreichend. Also ein vollständiger Ersatz für Stoppuhren oder andere Smartphone-Apps, die man sonst für Kontrollmessungen verwenden würde.

Und alles natürlich dann in Echtzeit auf dem Server.

Tasks der nächsten Zeit

Die nächsten Wochen und Monate werden sehr stressig. Meine Pläne sind:

- Umziehen und Renovieren (vielleicht mit Blog-Post über Netzwerk, Server und Überwachungskameras)
- Ein einfaches Shopware Plugin in den Community Store zu bekommen (Das Plugin ist so gut wie fertig.. jetzt kommt die Upload-Theorie* .. schlimmer als der App-Store für Firefox OS kann es sicher nicht sein)
- Einen kleinen aber etwas speziellen Shop online bringen (ich werde berichtigen wie es läuft und ob es am Ende erfolgreich war)
- Zwei Termine mit dem Switch GmbH Time-System stehen an, wo ich auch Blog-Post und so liefern werde.. mehr als letztes Jahr
- Ein Video über die manuelle Zeitmessung mit dem Time-System
- Und nach dem Umbau der letzten 3 Monate am aoop PHP-Framework mit MVC, neuer Verzeichnisstruktur, PHP 7, Namespaces, Composer-Autoloader, etc müsste ich wirklich mal eine neue Version releasen.. ich bin doch relativ stolz auf die neue Version ,weil sie doch etwas ist was man als modern bezeichnen kann

* Anleitung für den Shopware Community-Store

Shopware Forms mit Smarty und Customer-Model?

Der neue GSM USB-Dongle

Heute ist der neue Stick angekommen und nachdem die Software von der Herstellerseite installiert wurde, wurde er auch problemlos unter Windows 10 erkannt.

Der Stick ist ein 4G Systems XS Stick P10 und bei dem Preis kann man wohl erst einmal nicht viel falsch machen.

King Pigeon RTU5023 Anleitung

Das King Pigeon RTU5023 ist ein Gerät zum Messen von Temperatur und Luftfeuchtigkeit. Der Vorteil ist, dass das Gerät diese Messungen dann auch über das Handy-Netz (Quad-Band) per SMS verschicken kann. Mit dem sehr stabilen Gehäuse und dem Anschluss für den Senor kann man damit also ohne Probleme Transporte mit LKWs oder Zügen von einem Standort aus überwachen. Mit einer SMS-Flat entstehen auch kaum zusätzliche Kosten. Die SIM-Karte darf keinen PIN haben, da man an dem Gerät keine PIN eingeben kann und die Programmierung rein über Commands erfolgt, die man dem Gerät per SMS schickt. Antworten tut das Gerät auch über SMS.

Ich habe das Gerät von der Switch GmbH bekommen, um mal heraus zu finden wie es funktioniert und wie man es in vorhandene Systeme integrieren kann.

Das Problem ist, erst einmal etwas über das Gerät heraus zu finden. Bei chinesischen Geräten ist das ja immer das Problem, dass man zwar viele Seiten findet wo man das Gerät kaufen kann, aber kaum Seiten vom Hersteller oder mit Anleitungen. Das ist auch hier so. Die Infos zu den SMS Commands ist schwer zu finden und auch nicht gerade übersichtlich oder gut erklärt.

ABER es gibt einen Vorteil und dieser ist die Android-App im Google Play-Store. Diese macht an sich nichts andere als Eingaben in die App per SMS zu verschicken. Antworten kommen per SMS und werden dort wieder eingetragen.

Also einfach das Gerät anschließen und die App installieren. Als erstes muss man das Gerät anmelden. Nummer eingeben, das default Passwort ist 1234 und den Rest nach belieben ausfüllen und speichern.

Ich wurde erst einmal mit SMS voll gespamt. Meistens dass die Report-Time auf 999 stehen würde. Also diese erst einmal auf 1h gestellt und schon hörte es auf. Man kann sich stündlich Reports der Messungen zusenden lassen oder Alarm SMS, falls die Tempartur- oder Luftfeuchtigkeit-Range über oder unter schritten wird.

Das Tolle ist, dass die SMS natürlich auch einfach im Handy vorliegen. Da kann man dann anhand der Zuordnungen von Befehl und Antwort sich die meistens Commands einfach so erarbeiten.

1234DT001

Das setzt die Report-Time auf 1h.

Als nächstes geht es nun darum SMS zu empfangen und deren Inhalt auszuwerten. Davon ist wohl das Empfangen das Problem, wobei ich noch einen UMTS-Stick rumliegen habe und es da wohl entsprechende Java-Libs gibt.
Damit kann man sich dann ein SMS-Gate bauen und die eingehenden SMS parsen und weiterleiten. Aber das kommt dann nächste Woche.

Entwickler in der freien Natur (für den Job)

Auch wenn sich immer noch das Gerücht hält Entwickler würden Tag für Tag vor ihrem Rechner in schlecht beleuchteten und belichteten Räumen sitzen.. NEIN.. das stimmt nicht, manchmal findet man sie auch mit ihrem Notebook unter Regenschirmen im strömenden Regen auf Marktplätzen oder Rennstrecken. Spätestens wenn ein System das erste Mal wirklich benutzt wird, sind auch die Entwickler dabei.

Dabei sollte man auf einige Dinge achten:

Eigenes und schnelles Notebook mit IDE dabei haben. Denn wenn etwas Probleme macht, kann es gleich direkt Bugfixen und da man nie genug Zeit hat, sollte es ein schnelles Notebook sein.

Regenschirm, Regenjacke und alles dabei haben um sich und das Notebook vor Regen zu schützen

25m-50m Netzwerkkabel, weil man nie weiß, ob man wirklich mit dem Notebook an der richtigen Stelle sitzt oder man andere Hardware doch vom Notebook entfernt aufbauen muss

Kabeltrommel und Verlängerungskabel, sowie Stift und Papier dabei haben. Schnelle Notizen sind immer mal nötig.

Wenn man darauf achtet überlebt der gemeine Entwickler auch ohne Probleme die oben beschriebene Zeit.

Das tollste wäre natürlich ein Notebook, dass einfach Regen übersteht und keinen extra Schutz bräuchte!

User	annonyme	Date	2016-09-10 19:21
Tags	hannes pries, outdoor, regen, rennen, switch gmbh, zeitmessung

Hannes Pries - Web/Shopware/JavaScript-Developer BlogWeil es immer eine simple Lösung gibt!

Hannes Pries - Web/Shopware/JavaScript-Developer Blog
Weil es immer eine simple Lösung gibt!