Dev-Blog Donnerstag 11/16

Dev-Blog Donnerstag 11/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Die schon vorletzte Woche gestarteten Refactorings (User-Input konsequent und zentral behandeln) weiter fortgesetzt. Da das nur bedingt Spaß macht, mache ich das in eher kleinen Häppchen. Wir haben ja kein Feuer auf dem Dach, da uns aktuell keine Lücken bei der Eingabeprüfung bekannt sind. Trotzdem ist mir sehr wichtig, am Ende alle Eingaben einheitlich zu behandeln, weil es das Leben in Zukunft auf jeden Fall vereinfacht.

Letzten Donnerstag habe ich ein eintägiges Seminar zum Thema „Geistiges Eigentum in Theorie und Praxis“ besucht. Die Vortragenden waren absolute Experten im Gebiet von Patenten / Patentrecherche sowie dem Aufbau einer IP-Strategie (Intellectual Property) eines Unternehmens. Auch wenn das aktuell kein Thema für mich ist, so hat sich der Besuch des Seminars in jedem Fall gelohnt.

Dann habe ich mich wieder recht intensiv mit der Amazon Elastic Compute Cloud beschäftigt und den eXperinox Chat fertig aufgesetzt und auch zum Laufen gebracht. Details dazu findet ihr im Blog-Artikel am Samstag.

In diesem Zusammenhang habe ich mich nach über 15 Jahren wieder einmal etwas mehr mit Linux beschäftigt, insbesondere mit der Linux Shell. Ziel: die Log-Files, welche unser Chat in der Cloud erstellt, sollen an shlainn und mich gemailt werden. Automatisiert per CronJob. Eine sehr empfehlenswerte Seite  ist LinuxCommand.org: Learn the Linux command line. Write shell scripts.

[Iwan (shlainn)]

Weiterhin gibt es wenig aufregendes zu berichten während wir systematisch durch alle  Eingangspunkte von experinox pflügen und den neuen Code in Stellung bringen. Und da ich eh gerade dabei bin jede einzelne Seite manuell zu testen, dachte ich mir dass das ein einmalig guter Moment ist,  automatisierbare Tests dafür zu schreiben. Dazu verwenden wir, wie schon einige Male erwähnt, das codeception Test-Framework.

Nachdem wir jetzt doch eine Menge Tests und Checks haben die bei jedem Push in unser git Repository durchlaufen, wurde die  Gesamtlaufzeit auf unserem Jenkins CI Server immer länger. Um dem entgegenzuwirken (und die 16 Prozessorkerne unseres Servers etwas besser auszulasten) habe ich unseren Build-Prozess umgestellt. Mittels des Plugins „MultiJob“ kann man einen Jenkins Job in mehrere Phasen unterteilen. Alle Jobs in einer Phase laufen parallel – was es uns ermöglicht Tests und Stylechecks gleichzeitig laufen zu lassen. Das verkürzt den Prozess um mehrere Minuten – und wird in Zukunft sicherlich noch mehr bringen, wenn wir mehr parallelisierbare Jobs haben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.