February 2016 - Entwicklung

Traso Packages: ein Vorschlag
by Viktoras Bezaras 19 Feb '16

19 Feb '16

Hallo zusammen, ich möchte gern eine Idee teilen, was ich schon seit einige Zeit hatte. Ich glaube jeder weißt dass classlib ein Codestapel ist. Es gibt bestimmte Probleme, die ich gern angehen möchte. Also Probleme: 1. Unstrukturiert. Sucht ihr auch nach der Dateien mit "Find in path" oder Shift+Shift, da es überhaupt nicht klar ist wo das Ding liegt? 2. Hat irgendjemand eine gute Ahnung was da liegt und was nicht? Ein Verzeichnis von alle Klassen oder so? Ich glaube man kann doch noch Dinosaurier Knochen finden. 3. Nehmen wir eine Beispiel Klasse. Wer verwendet diese Klasse? Welche Module? In eine Factory, wo der Name vom String aufgebaut ist? 4. Unspezifische Namen. classlib/Exporte, classlib/Request, classlib/Debug. Hotel Exporte oder Flug? Request an wem? Welches Debug (wie haben doch 3, oder)? Ich meine, kann man verstehen worum es geht ohne alle im Büro nachzufragen? 5. Wenn ich eine Klasse ändern möchte, die ist vom alle Modulen verwendet ist, tja.. viel Spaß beim Testing. 6. Wenn ich nur eine Module separat verwenden möchte (z.B. ganz spezifische Data-Machine nur für ein Flug Import) muss man trotzdem komplette lib mitnehmen. Ja, ich weiß, es geht irgendwie noch. Brennt nicht. Kann man gewöhnen. Die Lösung die ich vorschlage ist: Traso Packages. Eine interne Repository mit verschiedenen einzelnen unabhängigen Pakete, die werden mit Composer gesteuert. Unseren eigenen Packagist. Was bringt das? 1. Strukturiert. Wenn ich z.B. HBD Client Klasse brauche - suche ich nach HBD Packet. Im Paket ist natürlich die Klasse, aber auch Tests, Doku, Nutzungs-Beispiele, wenn der Entwickler super fleißig ist. 2. Eine Liste der Pakete gibt eine gute Vorstellung was wir haben. Wenn wir natürlich das richtig organisieren. 3. In jede Module findet dann man eine composer.json Datei, wo ist genau geschrieben welche Pakete braucht diese Module. 4. Namespaces. Die Klassen können immer noch Exporte und Request heißen, jetzt aber in einem Namespace: /Traso/Xres/Flug/Exporte u.s.w. 5. Im composer.json kann man genau definieren welche Version ist hier nötig. Wenn ich eine Request Klasse aktualisiere, ich setze auch bei mir in der Module die Version hoch, die andere Module gehen immer noch mit der alte. Was noch? 6. Wenn wir weitere Tools bauen (Business Intelligence, Import Checker, was auch immer) - man kann ruhig die Pakete verwenden. 7. Paket-Spezifische PR's, Forks, Hirarchy (Paket A verwendet Paket B) 8. Zukünftige Vorteile: wenn ein Praktikant/Bewerber kommt, kann man ihm einzelne Pakete zu Arbeiten geben, statt kompletten xres. Genauso mit Externe Entwicklern ( Thorsten Curschmann). Es muss nicht auf einmal alles umgebaut werden. Wir starten mit kleine Dinge und werden graduell sehen ob es alles uns passt. Meinen Vorschlag wäre auch eine Software wie GitLab zu verwenden (sehr ähnlich wie GitHub, kann aber bei uns installiert werden) - da kann man die Pakete anschauen, PR erstellen, auch Probleme melden u.s.w. Bitte aufpassen, das ist ein Konzept. Ich möchte nur jetzt wissen ob ihr mit der Idee grundsätzlich einverstanden seid. Dafür möchte ich gern Anfang nächste Woche eine Kurze Meeting haben um eure Meinungen zu bekommen. Vielen Dank für die Aufmerksamkeit 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 Bamdoo-Deployment ohne Fingerprint-Check
by Stefan Rank-Kunitz 18 Feb '16

18 Feb '16

Moin, Durch einige Einträge in der Datei /mnt/data/bamboo_home/.ssh/config auf der Code-Maschine habe ich dem Bamboo beigebracht, beim Ausrollen unserer Deployments bitte nicht mehr den Fingerprint des Servers zu prüfen. Auf diese Weise werden neue Maschinen oder neu ausgerollte Maschinen nun sofort ohne manuellen Eingriff in "known_hosts" ausgerollt. 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

HA Mysql and PHP
by Stefan Wieden 17 Feb '16

17 Feb '16

http://severalnines.com/blog/high-availability-read-write-splitting-php-mys… -- Viele liebe Grüße Stefan Wieden - JustTheOldGuy

1 0

build_customer_config pull
by Oliver Horn 03 Feb '16

03 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, durch eine Änderung im xadmin ab 2.4 müsst ihr ein pull auf build_customer_config machen. Dannach sollte in xres/modules/[xadmin]/config/configV2.inc.php Zeile 119 folgendes stehen "define('ASSETS', $httpDefault . 'assets/');" - -- 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) iQEcBAEBAgAGBQJWserEAAoJEJJVTvLi/DO6aC0H/0ZgVMmPFQ0EIh0XcfUH+/Go q4bSq/qtPPrf5IVdx+ukNTRoaeHWi78AQ3b7O04yaU1ybge/IM3qXckNl3VHaajF eyJcVOtdg4cfJxH9qKsVxob3AQ0NYT6lp3Z344pvcCdp1JSIx3LMzE9DSdXR0FF7 3hE8HGdxA8BwKgd0rwaxlSll3pt7rfWrYgZsIN0GIv0ET4QC7rtVveXnvxEym3ac LM7UOLNxDHMescPz0NyMRb87UKiMShiz7ZEuO4m12MzvHUNWTd+TlhnhLR/eek1E C0Y26MimgKL55aR1VKoWP5muzRVGE3cGCe2KjH7qNEX4lQ3K7nGZ5dcigGjj49o= =QMDW -----END PGP SIGNATURE-----

1 0