Die Rolle technischer Projektleiter und deren Bedeutung erlebte ich das erste mal, als ich für ein Partnerunternehmen tätig war. Dort gab es diesen einen Menschen, der mir als Entwickler stets zur Seite stand: Wie ist meine IDE einzurichten, welche infrastrukturellen Eigenheiten gibt es und wen muss ich ansprechen, wenn ich Fragen zu einer Technologie habe. Mirco war sein Name und ich war nicht nur fasziniert von seiner Kompetenz, sondern auch von der Verantwortung die er ausstrahlt. Er traf technische Entscheidung und war der erste Ansprechpartner bei Problemen. Er hatte immer ein offenes Ohr und war nie so autoritär, dass man das Gefühl hatte übergangen zu werden.
Ab da an begann ich mich mit der Rolle des technischen Projektleiters auseinanderzusetzen. Was sind dessen Aufgaben und warum gibt es eine solche Person? Was sind die Qualitäten und wann braucht es eine solche Rolle im Unternehmen? Diese Fragen versuche ich in diesem Post zu beantworten und lasse dabei meine persönliche Erfahrungen einfließen.
Möchte man XDebug für Debugging in z.B. PHPStorm mittels Postman-Request triggern, reicht es aus folgenden Parameter als Query-Param an die URL zu hängen:
Mittels bash ist es möglich auch ohne Install-Tool einen neuen Backend-Admin-Benutzer zu erstellen. Einfach auf das entsprechende System die bash öffnen.
Wenn viele Docker-Container auf einen System laufen, kann zu unerwarteten Problemen kommen. Um alle laufenden Container aufzulisten, kann folgender Befehl verwendet werden:
Symlinks in einer Linux-Umgebung sind so normal wie Reis in Asien. Trotz der Möglichkeit wird in einer Windowsumgebung nur selten davon Gebrauch gemacht.
Daniel Stockner beschreibt in seinen Beitrag sehr anschaulich wie man mit unterschiedlichen Datumsformaten in Sprachen in TYPO3 umgeht und diese in Fluid-Templates korrekt verwendet.
Am 25. Mai findet offiziell die DSGVO/GDPR Anwendung. Genau dieses Thema ist im Update 4.9.6 der zentrale Punkt: Einstellung einer zentralen Datenschutzseite, Anonymisierung, Export, Löschung benutzerbezogender Daten und noch vieles mehr. Zudem kann in Plugins die benötigte PHP-Version angeben und in der Mediathek nach eigenen Uploads gefiltern werden. Ein Update und Blick in den Changelog lohnt sich also auf jeden Fall.
Bereits 2008 hat Tim Pope einen Beitrag zum Thema Commit Messages in Git veröffentlicht. Folgende Best Pratice schlägt er dabei vor:
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
Eine Commit Message sollte immer aus einem Titel bestehen, der sich in der ersten Zeile befindet. Dieser Titel sollte nicht mehr als 50 Zeichen enthalten und das Thema kurz und bündig beschreiben. Nutzt dafür die Befehlsform (Imperativ) mit Schlagworten wie „Fix“, „Add“ oder „Change“.
Nach dem Titel folgt eine Leerzeile, gefolgt von der Beschreibung. Diese sollte nicht mehr als 72 Zeichen pro Zeile enthalten. Um das zu erreichen sollten an den entsprechenden Stellen Zeilenumbrüche gesetzt werden. Weitere Paragraphen sind mit einer Leerzeile möglich. Ebenfalls möglich sind Auflistungen mit Bindestrichen oder Sternchen. Bei mehrzeiligen Auflistungen immer zwei Leerzeichen lassen (hängende Einzüge).
Do’s
Schreibe den Titel im Imperativ. Nutze dabei aussagekräftige Wörter wie „Add“, „Fix“, „Change“ oder „Remove“ an Stelle von „Added“, „Fixed“… etc.
Der erste Buchstabe des Titels muss groß geschrieben werden
Die Zweite Zeile muss eine Leerzeile sein, da sie den Titel von der Beschreibung trennt
Nutze Zeilenumbrüche und Leerzeilen in der Beschreibung um die Commit Message lesbar zu halten
Dont’s
Der Titel sollte nicht mit einen Satzzeichen enden. Titel haben keine Satzzeichen am Ende. *g*
Die Beschreibung sollte recht ausführlich erklären welche Anpassungen in euren Commit enthalten sind. Recht ausführlich heißt: Weder ein Einzeiler, noch ein Roman.
Nice2Know
Wird die Beschreibung zu umfangreich, teile den Commit in einzelne Commits auf.
Auflistungen sind mit Bindestrichen oder Sternchen möglich (bitte nicht mixen)
Alle größeren IDE’s unterstützen euch bei der Einhaltung dieser Richtlinen
In der IDE PHPStorm können die Richtlinen für einen Commit angepasst werden.
Fazit
Weiterführende Informationen findet ihr z.B. in der offiziellen Distribution Guideline oder direkt im Beitrag vom Tim Pope. Dort begründet er bspw. wieso eine Zeichenbegrenzung sinnvoll ist. Zusammenfassend lässt sich sagen: Mit einheitlichen Commit Messages bleibt nicht nur die Git History toolübergreifend sauber, sondern auch das Projekt für alle Beteiligten nachvollziehbar.
Am 22.02.2018 stand wieder einmal ein größerer Urlaub an – diesmal eine Woche Miami und zwei Wochen Costa Rica. Mit meiner frischen Sony Rx100 Mark III konnte ich zahlreiche wunschöne Fotos und Video aufnehmen. Hier eine kleine Auswahl der für mich schönsten Shots (unbearbeitet und frei zum Download).
Der MVC-Pattern ist eines der wichtigsten Entwurfsmuster in TYPO3. Dennoch gibt es oft Szenarien, in der auch außerhalb eines Extbase-Controllers ein FLUID-Template gerendert werden muss. Hier hilft uns TYPO3 (ab Version 7.3) mit den sogenannten Standalone views.
