Andi Gutmans, Rod Cope - Keynote: Data is dead, Long live data!

Der Vortrag begann mit Darstellung der Entwicklung einiger Aspekte aus dem Umfeld Daten (Antwortzeiten, Verfügbarkeit von OpenSource Software, Beschaffenheit von Infrastruktur).

Im zweiten Teil wurde in die mögliche Zukunft geblickt, in der die Bereiche Virtual/Augmented Reality, Internet of Things und Machine Intelligence eine entscheidende Rolle im Alltag einnehmen werden.

Beispielsweise stellte der Sprecher sich vor, in Zukunft mit dem Ausspruch "Ich brauche neue Schuhe" einen digitalen Assistenten dazu zu bringen, geeignete Schuhe vorzuschlagen, da dieser alle relevanten Informationen aus der Historie und dem Kontext kennt.

Mit dem Aufruf: "Unlock data and use APIs!" schloss der Vortrag.

Ben Marks - Magento 2 development best practices

Mit Ben Marks stand dann der Community-Beauftragte von Magento auf der Bühne um Praxistipps im Umgang mit Magento 2 vorzustellen:

Allgemeine Hinweise

• Magento 2 als Framework
• Einfaches Beitragen zum Core: Magento2 auf github
• Die Versionsnummern halten sich weitgehend an Semantic Versioning

Empfehlungen für Entwickler

• PHP7 benutzen (v.a. wegen des Leistungsvorteils)
• Coding Standards einhalten (MEQP)
• Dependency Injection nutzen
• @api Methoden nicht erweitern sondern verwenden
• Plugins nutzen das Eventsystem und vereinfachen die Trennung von Modulen

Linkempfehlungen

• devdocs.magento.com
• SnowdogApps/magento2-theme-blank-sass
• OWASP
• Commerce Bug
• magescotch

Taylor Otwell - Building tools people love to use

Taylor Otwell ist Gründer von Laravel, einem inzwischen sehr populären Entwicklungsframework.

Am Beispiel von verschiedenen Laravel Tools ging er auf das ein, was seiner Meinung nach die Grundlage für erfolgreiche Tools ist.

Dabei legt er besonderen Wert auf

• entwicklerfreundlichen Code
• leicht zu lesen
• intuitiv zu schreiben
• keine boolschen Flags als Parameter
• Funktionalitäten, die einfach zu Nutzen sind
• einfache Szenarien sollen vor komplexen Szenarien bedient werden
• vereinfacht das Dokumentieren
• Lösungen für eigene (alltägliche und realisitische) Probleme
• "scratch your own itch for fun and profit"
• "trust your instinct"
• positive Einstellung

Als Motto könnte gelten: "dream driven development (DDD)"

Beispiel:

`$payload = json_decode((string) $response->getBody(), true);` vs.
`$payload = $response->json();`

Laura Thomson - Keynote: Engineering happiness

Gängige und naheliegende Erwartungen sind nicht immer besonders geeignet oder sogar irreführend:

Glückliche Entwickler kündigen nicht

die Betrachtung der Kündigungsquote ist zum Einen eine nachgelagerte Messgröße und deshalb keine besonders hilfreiche. Zum Anderen heißt es nicht, dass die Entwickler nicht glücklich gewesen sind. Sie könnten etwa ein besseres Angebot bekommen haben, eine neue Herausforderung suchen oder das Projekt / die Firma ist "vor die Hunde gegangen".

Glückliche Entwickler produzieren Code

Diese Metrik hilft for allem im individuellen Vergleich unter Berücksichtigung der äußeren Umstände (Aufgabenänderung, Urlaub, Krankheit, ...).

Glückliche Entwickler beschweren sich nicht

Das gilt auch nur für manche. Andere beschweren sich nicht, sind aber trotzdem unglücklich und kündigen irgendwann - oder sie liefern nur schlechte Leistung.

Besser geeignet scheinen die folgenden Metriken:

• Stunden gearbeitet (viele Überstunden sind kein Zeichen für glückliche Entwickler ;) )
• Downtime / Alerts
• Technische Schuld
• Marktanteil
• Einsatz veralteter Technologien
• Reisezeiten (viele Reisen sind wiederum kein gutes Zeichen)
• Firmenpolitische Aufgaben und Veranstaltungen
• Wohlbefinden im Privatleben

Um solche Werte zu beobachten, schlägt sie den Einsatz von Umfragen und Monitors (z.B. Stand Ups) vor.

Was macht einen Entwickler glücklich

• Meisterschaft
• Autononmie
• Zweck / Sinn

Zwei-Faktoren-Theorie von Herzberg

Hygienefaktoren - Faktoren, die beim Fehlen unglücklich machen:

• schlechtes Gehalt
• schlechte Räumlichkeiten
• kein Obst / keine Snacks
• keine Getränke
• etc.

Motivatoren - Faktoren, die glücklich machen:

• spannende Projekte
• Erfolg
• Bekanntheit
• etc.

Damit lassen sich Arbeitgeber in vier Kategorien einteilen:

• gute Hygiene, gute Motivation: RockStar
• schlechte Hygiene, gute Motivation: KoolAid (Startups ...)
• gute Hygiene, schlechte Motivation: PayCheck
• schlechte Hygiene, schelchte Motivation: ohne Worte ;)

Ratschläge

• alle paar Jahre neue Herausforderungen suchen (anderes Projekt, anderes Team, andere Schwerpunkte etc.)
• von besonderen Personen lernen
• Schreiben lernen (Blogs, Bücher, ...)
  
  

Gregory Chris - Lets make your PHP app's even faster

Grundsätzlich finden wir es ja in Ordnung und legitim, wenn Sprecher ein eigenes Produkt, oder das ihres Arbeitgebers vorstellen. Wenn aber ein Vortrag mit diesem Titel die ersten 20 Minuten nur daraus besteht, das wundervolle Tool Z-Ray der Firma Zend durchzuklicken (wir verlinken mit Absicht nicht!) und zu sagen wie toll das ist, kommt man sich dann doch ein wenig verschaukelt vor.

Michael Moussa - Introduction to graph databases with Neo4j

Dieses eigentliche Java Plugin gibt es in verschiedenen Varianten für PHP:

• Neo4j-PHP-Client
• Neo4j-PHP-OGM
• Neo4j-bolt-PHP

Ein trocken gehaltener Blick über den mysql-Tellerrand mit Foliendesign aus dem letzten Jahrhundert erklärte die Grundkonzepte von Graphendatenbanken. Nicht ganz uninteressant, aber für unser Umfeld eher nicht relevant.

Robert Martin - Keynote: Clean architecture

Uncle Bob war einer der wenigen Redner, die ihren Vortrag mit (glaubhaftem) Elan gehalten haben. Er plädierte dafür, in einem Webprojekt das Web als I/O-Device zu betrachten und daher in den Tests die Businessregeln etc. nicht mit einzubeziehen.

Auch die Architektur möge sich nicht an einem Medium orientieren, sondern am Zweck der Anwendung.

Er beschrieb dafür eine Architektur, in der ein Interactor die steuernden Aufgaben in der Businesslogik übernimmt. Dieser koordiniert die verschiedenen Entitäten, Boundaries (Schnittstellen zu den I/O-Geräten), Request- und Responsemodel sowie das Entity-Gateway (Schnittstelle zu der Datenbank).

Webdarstellung und Datenbank versteht er als Plugins in die Businesslogik - Entscheidungen hier können bei guter Architektur sehr spät getroffen werden.

Eine weitere Auswirkung dieser Architektur besteht darin, dass Tests (der Businesslogik) in Sekunden ausgeführt werden können - was den Alltagswert von Tests erhöht.

Leseempfehlungen:

• 8thlight.com
• cleancoders.com

Colin O'Dell - Hacking your way to better security

Colin O'Dell stellt aus den Top 10 Sicherheitslücken des OWASP Projekts seine Favoriten vor:

• SQL Injection
  • Benutzereingaben werden ungeprüft in die Datenbank weitergegeben. So können eigene SQL Queries mit verschiedenen Absichten an die Datenbank geschickt werden
  • Empfehlung: prepared Statements verwenden
• XSS - Cross Site Scripting
  • Über Benutzereingaben können `<script>` Tags zur Ausführung im Browser gebracht werden
  • Empfehlung: die Ausgabe einmalig escapen
• CSRF - Cross Site Request Forgery
  • Ein Session Cookie wird von einer bösartigen Webseite zur Authentifizierung auf einer vom Nutzer besuchten Seite verwendet um dort geschützte Aktionen durchzführen.
  • Empfehlung: zufällige CSRF Tokens verwenden
• Insecure Direct Object References
  • Webseitenbenutzer können ungeprüft IDs (oder Referenzen) auf interne Objekte verändern.
  • Empfehlung: Zugriffsrechte bei der Ein- und Ausgabe prüfen
• Sensitive Data Exposure
  • Interne Daten und Dateien sind frei zugänglich - beispielsweise Lese-/Schreibrechte auf dem Webserver für `.git`, `composer.lock`, ...
  • Empfehlung: Dateisystemrechte beachten
• Security Misconfiguration
  • Standard Accounts mit schwachen Passwörtern
  • SSH root Zugang
  • schwache Verschlüsselung
  • veraltete Software (fehlerhafter Versionen, nicht benutzte Software)

Empfehlungen und Links

• Software aktuell halten
• sensible Daten nicht ins Webroot legen
• starke Verschlüsselung verwenden
• System testen
• Anwendung testen
• im Bereich Security weiterbilden
• an Security-Wettkämpfen teilnehmen
• Informiert bleiben
• Sequel Map
• OWASP Attack Proxy
• National Vulnerabilty Database

Sammy Kaye Powers - My journey to the center of PHP

Sammy Powers beschrieb am Beispiel seines Corebeitrages zum komfortablen Erzeugen zufälliger Werte in PHP, wie ein solcher Vorgang ablaufen kann.

Es sei zwar Arbeit gewesen, entsprechende Aufmerksamkeit und Vertrauen des Core Teams zu bekommen - einfache Arbeiten (Doku, Tests, Bugs verifizieren), Idee skizzieren, mit kritischen Kommentaren auseinandersetzen, Code einreichen. Es wäre allerdings auch nicht so furchterregend, sich in das Zentrum PHPs zu wagen, wie er befürchtet hatte.

Er appelliert an alle Interessierten sich zu beteiligen und zu informieren:

• über die Infosec Leute
• über die PHP Roundtables
• an Dokumentation
• an Bugmeldungen (PHP)
• an Tests (PHP)
• an der Webseite (PHP)
• am Core (C)

Bill Weinberg - Keynote: Securing open source

Bill Weinberg von der Linux Foundation stellte die Arbeit der Linux Foundation vor. Es gibt Weiterbildungen - außerdem fördern sie verschiedene Projekte ...

Vielleicht habe ich durch Zeitverschiebung und klimaanlagebedingten Frost nichts mitbekommen oder Herr Weinberg hat nichts wirklich relevantes gesagt. Das bleibt offen….

Tessa Mero - Consuming REST APIs

Nachdem Frau Mero (wortreich) auf ihre Arbeit bei developer.cisco.com eingegangen war, stieg sie in ihr Thema "APIs" ein.

Als sie nach einer Viertelstunde bei einer ausführlichen Erklärung aller HTTP Status Codes angelangt ist, verlassen wir das ZendCon Kinderparadies und gehen zurück zur Konferenz.

Adam Wathan - Curing the common loop (with collection pipelines)

Verschachtelungen aus `foreach`-Schleifen und `if`-Bedingungen sind ohne Zweifel weder schön noch gut wartbar.

Adam Wathan setzt phpcollection in Verbindung mit Callbacks ein, um solche Codeschnipsel zu Überarbeiten (oder gar nicht erst zu erzeugen).

Das bringt zwar den Vorteil, dass die zyklomatische Komplexität durch Schleifen und Bedingungen in der Methode verschwinden, sowie Methodenaufrufe die chronologisch dargestellt werden. Allerdings empfinde ich den mit callbacks aufgebrochenen Code immer noch nicht als schön oder gut lesbar.

Alena Holligan - Exploiting the brain for fun and profit

Alena Holligan lieferte in ihrem Talk ein paar Auffrischer und ein paar neue Fakten über das eigene Gehirn:

Haupteinflussfaktoren

• Schlaf
  • Informationen werden im Langzeitgedächtnis abgespeichert
  • Schlafmangel lässt die Leistungsfähigkeit des Gehirns sinken, ohne dass man das selbst wahrnimmt
  • Auf Schlafphasen abgestimmt sollte die Schlafdauer ein vielfaches von 90 Minuten sein
  • Routine hilft beim einfacheren Schlafen
  • Ein Powernap von 26 Minuten kann einen Leistungsschub von 34% bringen (sagt eine Studie)
• Ernährung
  • Gesunde Ernährung macht nicht müde und bedingt Leistungsfähigkeit
• Bewegung
  • 75 Minuten Bewegung in der Woche erhöht die Lebenserwartung um bis zu 20 Prozent
    • über walking Desk
    • über walking Meeting
    • über tägliches Yoga / Übungen
    • über eine Timout App
• Information
  • reduzieren: "if you're not using it, get rid of it"
  • auslagern: was man aufgeschrieben hat, kann man nicht mehr vergessen
  • Unterbrechungen eliminieren (Pomodoro ...)
  • Starthilfe: Zero Inbox

Jonathan Reinink - Rethink image manipulations with Glide

Glide liefert eine API für bekannte PHP Bildbibliotheken. Über eine Kette von `GET`-Parametern können viele Funktionalitäten genutzt werden.

Dabei ist die Verwendung von Glide flexibel gehalten - der Einsatz auf einem entfernten System, dem lokalen Dateisystem, der Cloud, in Memory oder einer Kombination (Bilder / Cache) dieser ist ohne weiteres möglich. Caching und Sicherheitsfeatures wie signierte Requests sind ebenfalls bereits vorgesehen.

Adam Culp - Does your code measure up

Adam Culp ist bis hier her nur als organisatorischer Ansager und mit großem Elefant unter dem Arm aufgetreten.

Den Elefanten hat er beibehalten, ist in seinem Talk aber auf verschiedene Metriken eingegangen, u. a.

• zyklomatische Komplexität
• Code Duplikation
• lange Klassen
• Klassenkomplexität
• Fehlen oder übertriebene Nutzung von Kommentaren
• lange Methoden
• nicht benutzte Variablen
• ausgiebiges Nutzen von globalen Variablen
• n-path Komplexität
• Code Smells

Fazit

Alles in allem würden wir den weiten Weg für diese Konferenz nicht wieder auf uns nehmen, auch wenn die Konferenz insgesamt okay war.