September 2017 - Entwicklung

Code PHP Setter Method template - discussion
by Dragan Mladjenovic 28 Sep '17

28 Sep '17

Hi everybody. I was looking at the wiki page about the code templates https://wiki.app.infra.gs.xtrav.de/doku.php?id=root:traso:entwicklung:codes… I have noticed that the code for *Code PHP Setter Method* has a little change in comparison to the original template in the PHPstorm |/**| |||* @param ${TYPE_HINT} $${PARAM_NAME}| |#if (${STATIC} != "static")| |||* @return self| |#end| |||*/| |public| |${STATIC} ||function| |set${NAME}($${PARAM_NAME})| |{| |#||if| |(${STATIC} == ||"static"||)| |||self::$${FIELD_NAME} = $${PARAM_NAME};| |#||else| |||$this||->${FIELD_NAME} = $${PARAM_NAME};| |||return| |$this||;| |#||end| |}| If you are returning $this, it is called FLUENT setter....so that you can chain setters on the object. This is already a part of the previous template in the wiki page|| || *| |**Code PHP Fluent Setter Method* |/**| |||* @param ${TYPE_HINT} $${PARAM_NAME}| |||* @return self| |||*/| |public| |function| |set${NAME}($${PARAM_NAME})| |{| |||$this||->${FIELD_NAME} = $${PARAM_NAME};| |||return| |$this||;| |} |So In my opinion, no need to return $this from a method which is not made with a FLUENT template. In the screenshot below, we see that we have an option to choose fluent or normal setter. Greetings, Dragan

1 1

GitLab File Tree
by Viktoras Bezaras 26 Sep '17

26 Sep '17

Hallo zusammen, wer Datei-Baum vom Stash vermisst kann gern Browser-Plugin (https://github.com/tomasbonco/gitlabtree) installieren. So schön vom Aussicht ist es nicht, find ich trotzdem viel einfacher die PRs damit zu prüfen. Es gibt auch andere Plugins, die bei mir nicht funktioniert haben. Kann an der neue GitLab Version liegen, und wenn diese aktualisiert werden, werden sie dann besser. VG Viktoras -- Mit freundlichen Grüßen Viktoras Bezaras - Entwickler - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 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

Umzug xRes auf GitLab
by Stefan Rank-Kunitz 22 Sep '17

22 Sep '17

Moin, xRes ... und ALLES andere, was wir im Stash hatten und weiterhin haben wollen ... ist jetzt ins GitLab umgezogen. Stash ist tot, Friede seiner Asche. 1. Bitte prüft, ob alle Repos, die TraSo weiterhin benötigt, im GitLab sind. Was weg ist ... ist weg! 2. Bitte prüft, ob alle Änderungen, die ihr gemacht habt, im GitLab-Repo drin sind. Ich weiß schon, dass der develop nicht aktuell war, das update ich Montag. 3. Lokal müsst ihr NUR die URL Eures origin neu setzen (in jedem geklonten Repo), dann könnt ihr wieder arbeiten. git remote set-url origin <newurl> Dabei ist <newurl> der Wert, den ihr im GitLab auf der Projektseite oben in der Mitte kopieren könnt, z.B. git@git.app.infra.gs.xtrav.de:xRes/xres.git (ein ssh:// davor ist nicht erforderlich). 4. Das Thema Rechte im GitLab löse ich ebenfalls Montag. Ziel ist es, dass alle Entwickler in alle erforderlichen Branches mergen/pushen können ... aber nur dort auch in den "master", wo wir fast nur mit dem master arbeiten (z.B build_customer_config oder flightcheck oder ...). Ich habe im Bamboo alle Build-Prozesse angepasst, es wird NUR NOCH aus dem Gitlab gezogen. Leider bockt Bamboo erheblich dabei, seinen Repo-Cache zu vergessen. Außerdem stehen in Composer-Konfigurationen noch Verweise auf Stash drin, auch das bauen OHO und ich Montag schnell um ... dann wird xRes wieder gebaut. Sport frei! VG SRK -- Mit freundlichen Grüßen Stefan Rank-Kunitz - Lead Developer - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel.: +49 341 355 740 - 43 E-Mail: s.rank-kunitz(a)traso.de ________________________________________________________ Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

xres logrotate
by Soeren Pestner 20 Sep '17

20 Sep '17

Mit unseren Kunden AWT und ASM haben wir das erste mal den Fall das sich beide Kunden einen service Rechner teilen und damit gibt es kleinere Probleme mit dem deployment. Einiges konnten wir schon lösen, danke SRK. Aktuell müssen wir uns Gedanken zum logrotate deployment machen. 1. Aktuell werden logrotates über das config deployment ausgerollt. Diese werden unter /var/xres/kunde/config/etc/logrotate.d/ abgelegt. Per chef und ansible ist aber der Pfad /var/xres/etc/logrotate.d/ inkludiert. Das ist mal so gewesen, bevor wir Kunden-spezifische configs ausrollten und muss angepasst werden. 2. Alle ausgerollten logrotates mache das gleiche, sie beachten also nicht die kundenspezifischen log Verzeichnisse. Sie würden sich also gegenseitig die Dateien weg nehmen. 3. Was soll wie rotiert werden. Bisherige mir bekannte log Verzeichnisse: /var/www/xres_kunde/*/log/ /var/log/xres/hotel-import (wird noch kundenspezifisch gemacht) /var/log/xres/kunde/* 3.a Eine Aussage ist, dass sich die Entwickler selbst um ihre logs kümmern sollen also auch für die richtigen logrotates verantwortlich sind. 3.b Eine andere Aussage hinterfragt die Sinnhaftigkeit der modul- und kundenspezifischen Behandlung der logs. Logs sind logs also warum unterschiedlich behandeln. 3.c Wir haben z.B. mit den xadmin debug logs tatsächlich logs, die speziell rotiert werden, dafür gibt es ein extra script. Idee: ----- 1. Wir verwenden /var/xres/kunde/* als Standard log Verzeichnis. Alles was da hin geht, wird ohne eigenes Zutun wie gewöhnliche logs behandelt. Das logrotate würde über chef bzw. ansible ausgerollt. Scheinbar ist es aber nicht möglich ein Verzeichnis rekursiv abzuarbeiten. Wir müssten uns also auf eine Ordner Struktur einigen, in der alle logs in der selben Ebene liegen. 2. Die logs unter /var/www/xres_kunde/*/log ist Entwicklersache. Diese logs unterliegen alleinig der Obhut des Entwicklers und müssen ggf. über extra logrotates, die deployed werden können, behandelt. 3. Das logrotate deployment wird überarbeitet und bietet dann die Möglichkeit kunden- bzw. modulspezifische Einstellungen vorzunehmen aber eben nur für die /var/www/xres_kunde/*/log -- -- Sören Pestner - Entwickler - TraSo GmbH Nonnenstraße 42 D-04229 Leipzig telefon: +49 341 909 87 49 email: s.pestner(a)traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850)

1 0

TraSo Code Style Extension
by Viktoras Bezaras 08 Sep '17

08 Sep '17

Hello everyone, we agreed some time ago, that we would use PSR-2 code style for xRes development. http://confluence.app.infra.gs.xtrav.de/display/Entwicklung/Codestyles PSR-2 however is a very general recommendation. Many things we do intuitively, I believe it's time to extend a little bit a list of our rules, to make them more clear. My proposal is to partially adopt Symfony Framework Coding Stadard, since it shares a lot of rules with what we already do. https://symfony.com/doc/3.3/contributing/code/standards.html Specifically: - Follow the standards defined in the PSR-0, PSR-1, PSR-2 and PSR-4 documents. - Add a single space after each comma delimiter (E.g. func($a, $b, $c); or [$a, $b, $c]) - Add a single space around binary operators (==, &&, ...). I suggest always use spaces around concatenation as well. (E.g. $a . $b, $a == $b) - Place unary operators (!, --, ...) adjacent to the affected variable (E.g. !$a, not ! $a) - Use braces to indicate control structure body regardless of the number of statements it contains; (E.g. if ($a) { doThis(); }) - Declare class properties before methods; - Use parentheses when instantiating classes regardless of the number of arguments the constructor has; (E.g. new Obj(); not new Obj;) - Do not use spaces around [ offset accessor and before ] offset accessor. (E.g. $a[$b[1]], not $a[ $b[1] ]) - Use camelCase, not underscores, for variable, function and method names, arguments; - Prefix abstract classes with Abstract - Suffix interfaces with Interface - Suffix traits with Trait - Suffix exceptions with Exception - Use alphanumeric characters and underscores for file names (Letters and numbers, no special characters) - For type-hinting in PHPDocs and casting, use bool (instead of boolean or Boolean), int (instead of integer), float (instead of double or real); - Omit the @return tag if the method does not return anything; - The @package and @subpackage annotations are not used. These are just, what I believe we can easily agree on without much discussion. There are more rules in the Symfony document. If you feel some other should also be included - please let everyone know. Best regards Viktoras Bezaras -- Mit freundlichen Grüßen Viktoras Bezaras - Entwickler - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 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

3 6