- Entwicklung - example.com

xRes-Builds und ZendFramework-Versionen
by Stefan Rank-Kunitz 24 May '16

24 May '16

Moin, Heute gab es Probleme mit xRes- und ZF-Versionen. Ursache war, dass (wegen des Autoloaders) xRes 2.5.1 nicht mehr mit ZF 1.10.6 laufen wird (das fast überall live mit xRes 2.5 genutzt wird) und der xRes Build-Prozess keine Zuordnung xRes-Version->ZF-Version steuerbar macht. Folglich habe OHO und VBE alle Kunden auf ZF 1.12.18 (neuste Version ZF1) aktualisiert und damit leider auch ein BugFix-Deployment von xRes 2.5 heute erschwert. Lösung: * Temporär hatte ich für alle Kunden wieder ZF 1.10.6 bzw 1.11.11 (JT) eingetragen und habe damit xRes 2.5-38 builden lassen. Diese Version ist als BugFix-Deployment live gegangen. * Anschließen habe ich für alle Kunden wieder ZF 1.12.18 eingetragen und damit neue xRes-Versionen bauen lassen. Achtung: Die folgenden xRes-Versionen dürfen nicht verwendet werden: * 2.5-39 und spätere => bitte 2.5-38 nutzen oder erneut ZF auf 1.10.6 zurück drehen * 2.5.1-104 bis 106 (nutzen alte ZF-Version) => bitte mindestens 2.5.1-107 nutzen * 2.5.2-39 bis 41 (nutzen alte ZF-Version) => bitte mindestens 2.5.2-42 nutzen VG SRK -- Mit freundlichen Grüßen Stefan Rank-Kunitz - Lead Developer - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 355 740 - 43 E-Mail: s.rank-kunitz(a)traso.de ________________________________________________________ Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

Update build_customer_config
by Oliver Horn 13 May '16

13 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 moin moin, damit bei euch xres ab der 2.5.1 weiter funktioniert muss auf "build_customer_config" ein pull [master] gemacht werden. Das Directory heißt meines wissens "xadmin_config". - -- Mit freundlichen Grüßen Oliver Horn - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 90 987 45 E-Mail: o.horn(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXNbWvAAoJEJJVTvLi/DO6rhMH/RkrwCPIAM1qt5Ay8aoBYKY5 bIlra2k4ozC+lvMp3+Klf0mAJBoj8oJWt33d88biQjhJjVs80cWHi0kvbs4VI7r0 1Q8u188YDuSDV3zrd/ATDeIvoI18NeTQ4zDWNCGqcEJw2G8oObwLm/T5WkqT9oO9 zX7b+hxwslmzags8v9gtwKqxhelXZ85WnHCIj/c423H2I91R0sHtq0LmHC3j+xtn bwVYpPjeRCAazuBRqK9WXAKj0jhrrvKEHbVJV4rLd0KjI+G0ZdePvjG/CFmZ/g5d bbW+DtmKCwcTVBCsphNwdOvk115qkGFffAnn1C/GMi31dx8b3bNaatnjcGHmueM= =gZpp -----END PGP SIGNATURE-----

1 0

jQuery update - assets - externals
by Oliver Horn 22 Apr '16

22 Apr '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, ich habe soeben das jQuery auf die aktuelle Version geupdated (2.2.3), bitte einmal das externals Repo updaten, sonst funktioniert bei euch der xAdmin ab develop (2.5) nicht mehr. Bei Fragen, helf ich ich gern=). - -- Mit freundlichen Grüßen Oliver Horn - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 90 987 45 E-Mail: o.horn(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXGdj5AAoJEJJVTvLi/DO6RMgH/0NQ3T7drIZObFLfoUrtuygs OR6wqe7n1R0m2Ob/KF036tlCPnSG8F9yXTSFvKKtrGhW6QqICk+5QR2SA1zjGzW9 GAfhuOnLdZsW5CEiPtEnVeWgQrJiY6ccNXvgE62tNVuBXkm1Jff+G56+kh3goKxv q/CsCrRQDQnuOTEb2Bb8v8daZYXqkPWcXs7io/4yIRcvGE8KblgnfFb9WJwT+LT+ VgiPXSjhl1e3mzxsZrOSTxuqWEtMcmRL8boFZx6+eD/fZNyJbqR8kAqUR9KjIUWV nRSujxWhKVQgijWm/XGO85oaFa2ZjbR4AqyfTlQ/tBzdVN3WNZby/XJNIQnZwFY= =9iKq -----END PGP SIGNATURE-----

1 0

Webinar: mongodb-dba
by Stefan Wieden 13 Apr '16

13 Apr '16

http://severalnines.com/blog/new-webinar-series-become-mongodb-dba-if-you-r… -- Viele liebe Grüße Stefan Wieden - JustTheOldGuy

1 0

Deplying with Deployer
by Stefan Wieden 08 Apr '16

08 Apr '16

http://www.sitepoint.com/deploying-php-applications-with-deployer/ -- Viele liebe Grüße Stefan Wieden - JustTheOldGuy

1 0

MySQL-Webinar
by Stefan Wieden 06 Apr '16

06 Apr '16

https://www.percona.com/resources/webinars/introduction-troubleshooting-per… -- Viele liebe Grüße Stefan Wieden - JustTheOldGuy

1 0

Good story on intellectual property and software dependency
by Marcus Puchalla 23 Mar '16

23 Mar '16

Never use something you can write yourself :) http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ -- Mit freundlichen Grüßen Marcus Puchalla - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 909 87 45 / Fax: +49 341 909 87 49 E-Mail: m.puchalla(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

Producer: Validate and Release PHP Library Packages
by Stefan Wieden 23 Mar '16

23 Mar '16

http://paul-m-jones.com/archives/6301 -- Viele liebe Grüße Stefan Wieden - JustTheOldGuy

1 0

Traso Packages (inkl. Beispiel)
by Viktoras Bezaras 16 Mar '16

16 Mar '16

Hallo Team, Weil heutiges Meeting abgekürzt war und ich keine Zeit um Pakete zu reden hatte, schreibe ich jetzt diese E-Mail. Ich habe während letzter Woche sehr viel auch außerbetriebliche Zeit ins Thema investiert. Ich möchte nicht das einfach so liegen lassen, da es für mich sehr wichtig ist. Ich rücke das Thema auch vor, weil ich nicht glaube, dass es ansonsten natürlich bei uns selbst entwickelt. Traso Packages ist ein Thema, was soll am Ende viele Vorteile bringen. Das Wort "uns" ist hier auch wichtig, da ich mehrmals gefragt wurde "was soll es unseren Kunden bringen". Das ist nicht für unseren Kunden gedacht, und ist für die nicht direkt relevant. Das ergibt uns, als Entwickler, eine Bessere Arbeitsumgebung. Eine Umsetzung von svn auf git hat unseren Kunden auch direkt nichts gebracht. Würde ich aber heute als Bewerber kommen und hören dass hier noch svn verwendet ist, würde ich aufstehen und weg gehen. Ich würde mich nicht wundern, wenn es Bewerbers gibt, die wegen eine ältere PHP Version abgesagt haben. Eine sinnvolle Projektstruktur ist in der selben Reihe. Ein nicht technisches Beispiel ist - bequeme Sessels. Das bringt unseren Kunden auch nichts, wir könnten dann die billigere Stuhle haben. Pakete und deren Verwaltung ist ein Industriestandard (nicht nur in der PHP-Welt, aber in das ganze IT), und das ist nicht grundlos so. Ich wiederhole nochmal die Vorteile die wir dadurch bekommen können: 1. Strukturierung des Codes. Modularisierung ist selbstverständlich ein richtiges Konzept. Durch die Umsetzung, kriegen wir die Pakete, die können logischerweise nicht kleiner gemacht werden. Und dann auch größere Pakete, die von den kleineren bestehen. Ein logisches Baum-Struktur wird uns helfen auf die spezifische Teile konzentrieren, als auch besser entkoppeln. Wenn die Firma wachsen wird, es werden immer mehr Leuten die an den gleichen stellen Arbeiten. Wenn ich mir vorstelle, wie würde es aussehen mit 50 Entwickler und unseres aktuelles Struktur, ist mir gruslig. 2. Bessere Übersicht auf die Bestandteile die wir haben. Das bedeutet nicht unbedingt, das wir danach weniger Dateien oder Verzeichnisse haben, sondern sieh Punkt 1., dass die strukturiert werden. Es werden nur einige Verzeichnisse unter /packages geben: Core, Hotels, Flights, Bookings, Export. Eventuell ein Paar mehr, aber grundsätzlich schon klar um welcher Bereich es gerade geht. 3. Bessere Übersicht welches Teil arbeitet mit dem anderen zusammen. Kein Spagetti-Code mehr. Obwohl ist Spagetti immer gern esse, im Code gehört das nicht. Währen ich ein Beispiel Paket gebaut habe, habe ich schon eine Stelle gefunden, die, für mich unerwartet, eine Abhängigkeit hatte. 4. Reusability. Wer werden fähig unseren Code mehrmals verwenden in den parallelen Projekten, wie z.B. Autocheck, oder irgendein Business-Intelligence-Tool. 5. Kleiner Umfang für einer Entwickler. Wenn Artur oder ein externer Entwickler sich einarbeitet, ist das immer einfacher mit kleineren strukturierten Teilen zu arbeiten. Die Umsetzung kann unseren Code auf das neue qualitative Niveau bringen, und dann, bekommen unseren Kunden davon schon was: weniger Bugs, und dadurch mehr neue Features. Ich habe, wie gesagt, schon eine Menge Zeit investiert und habe die Beispiel Pakete gebaut, die findet man unter: http://stash.app.activate.de/projects/PKG Die externe Pakete, findet man unter: http://stash.app.activate.de/projects/EX Dann weiter, habe ich ein xres Branch erstellt: http://stash.app.activate.de/projects/PHP/repos/xres/browse?at=refs%2Fheads… So würde es aussehen. Die Idee mit den submodules war obwohl interessant, leider nicht passend. Ich habe sie ausprobiert und mehrere Probleme sind aufgetaucht. Ich habe also die andere Zwischenlösung gefunden: ein package Verzeichnis hat ein symlink von jedes Modul vendor Verzeichnis. Z.B.: modules/xhotels/vendor -> ../../packages. So, jedes Modul hat eigene Abhängigkeiten in composer.json definiert, die werden dann alle in ein Verzeichnis installiert (/packages, oder auch vendor) und mit xres commitet. So passt es in unseres heutiges Struktur und verursacht keine Probleme. Ihr könnt auch im xhotels das SIDX Importer (import_SIDX.php) euch anschauen (packages Branch), der verwendet schon die Klassen vom Package. Also, das ist schon alles fertig, man muss nur die Hand ausstrecken und nehmen. Ich hoffe auf eure positives Feedback (Das, dass es ein Problem ist wenn ein Paket jetzt nur eine Klasse enthält ist kein konstruktives Feedback). VG Viktoras -- Mit freundlichen Grüßen Viktoras Bezaras - Entwickler - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 355 740 44 E-Mail: v.bezaras(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

Umbau der xRes Verzeichnis- und Repo-Struktur
by Stefan Rank-Kunitz 04 Mar '16

04 Mar '16

Moin, In unserer Besprechung heute haben wir festgestellt, dass die aktuelle technische Struktur der xRes-Software (Verzeichnis- und Repo-Struktur) nicht optimal sind und haben Ansätze für die Lösung besprochen. Probleme: * Das Verzeichnis "lib" ist ein Müllhaufen ohne hinreichende Struktur & Dokumentation und wächst weiter (in Folge der gewünschten Zentralisierung von Funktionen). Es ist nicht hinreichend klar, welcher Code wo im xRes verwendet wird ... oder tatsächlich nicht mehr. => Die Struktur, xRes in "Module" und ein gemeinsames "lib"-Verzeichnis zu trennen, ist nicht flexibel genug. Es ist angemessen, über eine neue und besser dokumentierbare Struktur xRes so zu zerlegen, dass weniger "Müll" entsteht. * Die Konfigurationen (xResConf.xml, configV2, ...) liegen in jedem Modul-Verzeichnis (statt einmal zentral) und wird zum Teil über diesen ÜBLEN Broadcast-Mechanismus verteilt. * Uns ist erneut klar geworden, dass wir nicht wissen, wie ein "leeres xRes" aussieht. Besonder das über alle Kunden einheitliche DB-Schema und die darin zwingend erforderlichen Daten (z.B. ein erster xAdmin-User) sollten für einen nächsten xRes-Kunden ausgearbeitet werden. Grundidee unserer Lösung: * Wir zerlegen xRes in Zukunft in "packages". Jedes Package verfolgt eine bestimmte Aufgabe (z.B. Logging, Buchung, Midoffice, Email, ...) und wird in einem eigenen Repo abgelegt. * Die Abhängigkeiten der Packages untereinander lösen wir per composer.json auf. Jedes Modul und Package bekommen eine solche json-Datei und läd sich beim Build-Prozess die passenden Abhängigkeiten hinzu. * Die Abhängigkeiten werden dabei in jedes Modul als "vendor" abgelegt => was xRes im Dateisystem erheblich wachsen ließe. Alternativ kann auch ein zentrales Vendor-Verzeichnis (mit Option auf einen neuen Müllhaufen) erzeugt werden. Die Umsetzung haben wir in diese Schritte / Reihenfolge gelegt: 1. Zuerst "reparieren" wir das DB-Deployment und vermeiden damit die Probleme, die wir in allen vergangenen Releases mit der Reihenfolge von Schema-Änderungs-Dateien hatten. In Zukunft werden Dateienamen von Schema-Änderungen statt der durchlaufenden Nummer mit einem Unix-Timestamp beginnen. Das DB-Deployment und der zugehörige Unit-Test werden entsprechend angepasst. 2. Dann wird VBE ein erstes "Package" erzeugen und mit mir zusammen den Build-Prozess erweitern. Über eine Mittwochs-Session werden wir dann den Prozess des Umzugs von Code aus "modules" und "lib" in "packages" abstimmen. Der Ansatz für diesen Umzugsprozess ist es noch NICHT, Pakete auch per composer.json zu laden. Statt dessen werden wir eine Anbindung z.B. per git-submodules verwenden, dies wird den Umzug erleichtern und Dependency-Probleme auf später verschieben. Mit dieser Stufe hoffen wir, bis xRes 2.5 fertig zu sein. 3. Im nächsten Schritt wird die Config zentralisiert (also: alle Konfigurationen einer xRes-Instanz). Es gibt dabei mehrere Ansätze, die xResConf.xml statt des bisherigen Broadcast zu verteilen, auf einer Maschine nur einmalig und zentral abzulegen und ggf. gar in einem Repo automatisch zu versionieren. In diesem Schritt sollte ferner das Verzeichnis "modules" entfernt werden und damit das git-Repo der Verzeichnis-Struktur im Livebetrieb angeglichen werden. Nicht zuletzt wäre zu überlegen, ob wir in dieser Stufe des Umbaus ein "webroot" einführen und allen anderen Code an eine Stelle verschieben, die per Apache nicht erreichbar ist. Auf diese Weise können wir die Sicherheit der Software erhöhen (besonders auf dem Service01) und Logs ENDLICH auf die vorgesehene Daten-Partition verschieben. 4. Im letzten Schritt wird die Paketierung auf das Abhängigkeits-System umgestellt. Die Packages werden als Pakete gebaut, zentral abgelegt und per composer zu einem Verzeichnisbaum zusammen geführt. Es muss dafür einmalig aufgeschlüsselt werden, welches Package welche anderen Packages benötigt und daraus eine composer.json erzeugt werden. In diesem Schritt kann auch der Autoloader auf einen vom Composer erzeugten Cache umgestellt werden. 5. Optional kann in einem zusätzlichen Arbeitsgang überlegt werden, ob wir die Versionierung von Paketen zulassen wollen. Aktuell sieht es nach einer nicht erforderlichen Komplexität aus, in Zukunft KÖNNTE es aber hilfreich sein, von einem Package neben der neusten auch alte Versionen vorliegen zu haben und diese in noch nicht aktualisierten Modulen zu verwenden. @VBE: DANKE für den Vorschlag! VG SRK -- Mit freundlichen Grüßen Stefan Rank-Kunitz - Lead Developer - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 355 740 - 43 E-Mail: s.rank-kunitz(a)traso.de ________________________________________________________ Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0