PHPGangsta - Der praktische PHP Blog

Nach dem ersten Tag folgt der zweite, und ich kam Viertel vor 9 auf der Konferenz an. Also noch fix frühstücken (großartig!) und dann die Keynote von PHP-Core-Entwickler Pierre Joye über die Änderungen der letzten Monate und den Ausblick auf PHP 5.5. Er zeigte wie einfach es ist, PHP bei GitHub zu forken, mit Hilfe eines einfachen Online-Editors am Manual mitzuwirken, und bat darum früh neue PHP-Beta-Versionen oder Release-Candidates zu testen und Bugs zu melden. Jeder kann auch Ideen in Form von RFCs formulieren und an der Mailingliste teilnehmen, die Hürden der Teilnahme und Rückgabe an PHP war nie niedriger. Einige Stichworte für die neue Version 5.5: Neue Getter/Setter, PBKDF2, password_hash, Generators, foreach list, array_column, empty mit Expressions, intl, Fully qualified classname, parameter skipping, finally. PHP 5.5 wird Spass machen und voll rückwärtskompatibel werden.

Peter Friese gab danach eine Einführung in die plattformübergreifende Entwicklung von mobilen Apps. Er zeigte die aktuellen Möglichkeiten und Unterschiede, Inhalte auf Smartphones und Tablets zu bekommen, seien es native Apps, mobile Webseiten (responsive Design), Client-Side Web (HTML5+Javascript, jQuery mobile etc.), Hybride Apps (eine Bridge zwischen App(JS) und Library(Native) für Events) wie es Phonegap macht, und Interpreted Apps (mittels Javascript auf native Elemente und Funktionen zugreifen, evtl. JS->nativer Code kompilieren) wie es z.B. Titanium macht.

Insgesamt ein toller Überblick, der auch jeweils Vor- und Nachteile aufzeigte, sodass man mit dem Wissen in Zukunft die richtige Lösung wählt für die Bedürfnisse. Vieles zeigte er direkt live auf seinem iPhone mittels eines Rigs, sprich einer Kamera die über das Smartphone gebaut wurde. Einzig gestört hat mich der Spam auf Twitter, denn Peter hatte irgendwie ein „Tweet-from-Keynote“ aktiviert und es gab mehrere dutzend Tweets von ihm während der Session, sodass der Stream einfach nur voll und unübersichtlich war. Bitte nicht noch mal machen oder nachmachen.

Es ging weiter mit High Performance Suche mit Apache Solr. Nach einer kurzen Einführung in ePages berichtete Oliver Trosien vom neuen Greenfield Projekt ePages7, wo alles von Grund auf neu aufgebaut werden soll, git statt svn, Java7 statt Perl, Automated Deployment statt Long Release Cycles, REST statt SOAP, Scrum statt Wasserfall. Ein großes Vorhaben.

Speziell zeigte er uns die Arbeiten an der Suche. Verschiedene Projekte wie SQLite, SQL Fulltext, Google Site Search, Enterprise Search Appliances und OpenSource Tools wie Solr und Elastic Search wurden verglichen, und Solr wurde gewählt. Es galt, die Volltext Suche und das Suggest-Feature umzusetzen mit 2 Solr-Servern (Master-Slave) angebunden an MySQL Server, die die Shopdaten enthalten, ein Webinterface davorzubauen sodass es mittels JSON angesprochen werden kann. Performance-Tests wurden mittels jMeter durchgeführt und miteinander verglichen. Es traten mehrere Probleme auf die gelöst werden mußten. Hat Lucene zu viele Segmente wird es langsam durch die Merges zwischendurch. Oliver gab uns Tipps wie einen möglichst kleinen Index zu nutzen, genug RAM zu haben, auch auf einer Maschine Master+Slave zu betreiben, über Prewarming nachzudenken, ab einer bestimmten Größe (1GB) kein Full-Optimize mehr zu machen da das ewig dauert und eine Menge IO verursacht. Man solle nicht jeden Cache nutzen, der Fast-LRU Cache ist langsamer als der LRU-Cache, man solle Suchen wie Suggest-„a“ vermeiden, Fuzzy-Search mit Bedacht einsetzen da es viele Ressourcen koste und bei Sortierungen nach Preis beispielsweise schlechte Ergebnisse oben auftauchen, Vertipper mit Whitelists lösen, sich Stamming, Snowball, ngrams usw. gut überlegen, und noch einige weitere nützliche Tipps. Insgesamt würde ich sagen es war eine relativ trockene Techniker-Session mit durchaus interessante Interna und Advanced Tipps, die er leider im Sitzen verbrachte, erm.

Das Mittagessen war, wie am Vortag, sehr gut besucht, und ich habe einige wenige ElePHPanten unter das Volk bringen können.

Daniel Pötzinger erzählte uns am sehr praxisnahen Beispiel wie sie den Angry-Birds Online-Shop auf Basis von Magento Enterprise aufgebaut haben in der Cloud, sodass er gut skaliert und bei den Besuchermengen, die erwartet wurden, nicht zusammenbricht. Magento zusammen mit externen Diensten wie einem DRM-Server, einem Mailservice, Braintree als Payment-Dienstleister und ShipWire für die Lagerhaltung und Auslieferung wurden zusammengebaut in der Amazon Cloud und Rightscale oben drauf. Es ging darum Flaschenhälse zu finden wie CPU, Storage oder Bandbreite, und dafür einfache Lösungen einzusetzen. Themen wie HTTP Caching im Browser, CDNs und Varnish werden benötigt und richtig eingerichtet. Application Tuning durch Profiling mit Hilfe von XDebug/xhprof unter künstlicher Last (JMeter) und NewRelic unter Echtlast werden gemacht. Logs werden deaktiviert, Datenbankabfragen optimiert, Cleanup-Jobs laufen, Sessions werden im Memcached statt in der Datenbank gehalten, Reporting wird auf einem Datenbank-Slave erledigt, synchrone Dinge werden asynchron erledigt mittels Queuing, die Suche beschleunigt mit Solr.

Beim Caching geht es hauptsächlich darum Dinge zu cachen die viele Hits und hohe Hitraten haben, das Caching-System muss zum Einsatzzweck passen (APC, Memcached, Redis, File), die Caches aufzuräumen ist wichtig, Cache updaten statt purgen, man muss einen system- und versionsabhängigen Cacheprefix nutzen und Cache-Warmup-Scripte einsetzen.

Er berichtet von Autoscaling bei Rightscale, Gruppenpolicies , min/max, Votingrules for Scaleup/down. 404 Seiten sind teuer und sollten umgeleitet und in Varnish gecacht werden. Gute Tests, und einen vollautomatisierten Build-Prozess bis hin zu Continuous Deployment ist das wichtigste, um keine Angst vor neuen Releases zu haben und schnell auf Fehler reagieren zu können, denn verhindern kann man sie nicht. Insgesamt ein sehr guter Talk, mit einer der besten die ich gesehen habe.

Wie man Software Qualität darstellen kann und sollte zeigte Erik Dörnenburg. Nicht immer sind hunderte von Graphen gut, manchmal sind 5 sehr gut gewählte Graphen, in denen 2-4 Metriken zusammengeführt werden, viel schneller verständlich, und es ist plötzlich einfach einem Manager mit einem Barchart klarzumachen warum man einen kompletten Rewrite benötigt und ein Refactoring keinen Sinn macht. Er geht dabei nur auf einfache interne Metriken ein, wie Zeilenanzahl, Methodenanzahl pro Klasse bis hin zu zyklischer Komplexität aufsummiert in einer Klasse. Mit solchen Zahlen kann man sehr viele Dinge zeigen die falsch laufen in einem Projekt. Er präsentierte einfache Charts, die mittels Checkstyle und Excel die Metriken aufaddieren pro Klasse und dann dargestellt werden, aber auch komplexe Charts, Pyramiden und „Städte“ mittels InfoViz und CodeCity. Auf jeden Fall hat Erik bei mir das Bedürfnis geweckt mehr Zahlen zu errechnen und grafisch darzustellen, um mehr Durchblick und Überblick über komplizierte Codebasen zu erhalten, und über die Zeit beobachten zu können.

Wie SoundCloud skaliert berichtete uns der CTO Alexander Grosse. Häufig sei es schwieriger Leute und Organisationen zu skalieren als Technologien. Wenn die Firma in wenigen Jahren von einer handvoll Leute auf über 100 anstiegt gibt es ziemlich viele und komplizierte Probleme zu lösen. Bei SoundCloud geht es dabei vor allem um Vertrauen, die Reaktion auf Fehler, Innovation, jeder Entwickler ist selbst Tester und deployed selbst Live („You build it, you run it“), es gibt eine freiwillige Hacker-Time von ca. 20%, kontinuierliche Verbesserungen (Retrospektiven, Post Mortems), nicht Fehler um jeden Preis vermeiden sondern eine schnelle Reaktion auf Fehler, „move fast and break things“.

Wichtig sei es auch für ihn, die anfängliche Startup-Kultur beizubehalten, Continuous delivery und jede Minute, die darin investiert wird, sei Gold wert. Mit das wichtigste sei auch die Auswahl bei Neuanstellungen. Wenn dort sehr gut ausgewählt wird, Leute die zum Unternehmen passen und es weiterbringen können, kein Zweifel bei der Neueinstellung besteht, dann kommt das Unternehmen schnell voran und wird nicht ausgebremst durch die vielen Neueinstellungen. Cross-funktionale Teams werden gebildet, es wird alle paar Monate rotiert. Zum Ende gab er noch einige Zahlen zu besten: 1 Master, 9 Slaves, 900GB Daten in Datenbank, auf dem Master 14.000 IOPS (kein Thema mit SSDs!), 1 Slave 1Stunde hinterher als Sicherheit, 3 Cassandra Cluster, ca. 50 Nodes, 50k Reads/Sekunde, Infrastruktur teilweise bei Amazon (Transcoding Worker, Speicher), aber auch eigene Hardware, 5PT CDN Traffic pro Monat. SoundCloud ist schon einige Male ausgefallen, Ausfallursachen bisher: Manuelle Fehler (Live-DB Tabellen bearbeitet), selten Hardwareausfälle, Spam, Snoop Dogg-Effekt (Follower-Rush), DDOS Angriffe. Unbedingt lesenswert ist der Entwickler Blog von SoundCloud.

Von Wooga waren auch 2 Vertreter auf der Konferenz, die am Beispiel von Monster World und täglich mittlerweile über 2 Millionen aktiven Usern zeigten wie sie mit der Zeit das Spiel kontinuierlich verbesserten und weiterentwickelten mittels A/B Tests, dabei Dinge im Auge behalten wie Retension (wie sehr wird das Spiel gemocht, wie lange bleiben Spieler, wie oft kommen sie wieder, wo steigen sie aus im Tutorial), Vitalität (Mundpropaganda über Facebook, wie viele Spieler generiert ein bestehender Spieler) und Monetarisierung (wie viel Geld gibt ein Spieler aus, und wofür). Zahlen sind immer besser als ein Bauchgefühl, jede Annahme bzgl. einer Änderung/Verbesserung des Produktmanagers muss mittels Tests eingebaut werden und in der Realität bei den Usern beweisen dass sie sinnvoll ist. Dazu werden eine Menge Daten gesammelt, das Apache-Projekt Kafka eingesetzt, und dann Konsumenten geschrieben die die Daten abfragen und grafisch aufbereiten. Einfache Graphen wie Neuregistrierungen pro Tag, eingenommenes Geld, aber auch komplexere Graphen wie die Übersicht eines A/B Tests aufgeschlüsselt nach Langzeitmotivation (User die 2 Std bleiben, 1 Tag bleiben, 3 Tage bleiben), um so zu erkennen wie das aller erste Bild auf der Landing-Page auswirkungen darauf hat.

MySQL ist langsam bei solchen Datenmengen und SQL-Abfragen, Exasol sei das Tool der Wahl. Einfache Dashboards, Realtime-Dasboards, und mittels Zahlen herauszufinden wann das Bauchgefühl einen Entwickler/Manager reingelegt hat sind sehr wichtig. 2 kleine Änderungen an der Art und Weise Zauberstäbe zu verkaufen, brachten fast 50% Mehreinnahmen. Wichtig ist die Langzeitmotivation, bevor man die nicht im Griff hat und die Leute nach 2 Tagen wieder verschwinden braucht man sich nicht um Neugewinning von neuen Usern bemühen. Viele Dinge sollten ausprobiert werden, das beginnt bei Farben (Button rot oder blau) bis hin zu komplett neuen Features wie z.B. Langzeitplots (Quests, Missionen, Belohnungen bei Erfüllung von X Missionen), Wecken von Vorahnungen, neugierig machen auf den nächsten Tag, evtl. andeuten dass „das Monsterbaby stirbt wenn man am nächsten Tag nicht wiederkommt“…

Zahlen sind fast immer da wichtigste, es gibt nur wenige Entscheidungen wo Zahlen unwichtig sind. Die beiden Speaker auf der Bühne gehen auch darauf ein dass kombinierte A/B Tests wertvoller sind als Einzeltests. Jesper gibt dann noch Einblicke in die technische Umsetzung, Stichworte sind „UserID modulo Primzahl“ bestimmt Teilnahme an einem Test, dann einfache if-Abfragen im Code. Rollenswitches („Admins“) dann auch leicht möglich, so kann man dann Features sehr früh deployen und Live testen.

Zum Schluss der Konferenz gab es noch mal eine kurze Podiumsdiskussion über die Zukunft der Webentwicklung. Dabei kamen Prophezeiungen zu Tage dass z.B. die Social Networks sich wieder dezentralisieren werden weg von Facebook und Google+, es wieder speziellere Tools für spezielle Anwendungsfälle geben wird. Im Bereich der Heimroboter werden sehr viele Programmierer gebraucht, sodass man zuhause den blechernen Helfer per App sagen kann was er erledigen soll. Erst dachte ich es sei ein gutes Thema, aber in die Glaskugel zu schauen ist schwerer als gedacht, gerade wenn man > 5 Jahre voraussehen möchte.

Die Abschlussrunde brachte einige gute Verbesserungsvorschläge ans Licht, wobei es da wirklich nur um Kleinigkeiten ging wie detailliertere Sessionbeschreibungen, ausgedruckte Programmpläne, einige kleine Bugs im mobilen Programmplan oder die etwas zu klein gewählten Teller.

Alles in allem eine extrem gute Konferenz, die ohne Probleme mit anderen mithalten kann und in vielen Dingen andere auch übertrifft, und das obwohl es erst das zweite Mal stattgefunden hat. Ich freue mich schon sehr auf nächstes Jahr und hoffe wieder dabei zu sein, es lohnt sich auf jeden Fall.