Dann, hallo? Ich bin Stefan, Simon.
Stefan? Simon? Wir arbeiten bei Icons, das war
jetzt auch schon bekannt. Ich habe hier auch studiert,
das ist schon ewig her, gefühlt bis 2002,
dann drüben bei TIS als wissenschaftlicher Mitarbeiter gearbeitet,
habe dann aber so ein bisschen auch die Runde gemacht und
überall mal Übungsgruppen geleitet und wir haben das auch mal zusammen gemacht mit BlueJ,
macht ihr das noch?
Ja, selbstverständlich. Ja, und bin dann nach einer kurzen Phase
Selbstständigkeit bei der Icons gelandet, bin da jetzt Teamlead in der Webentwicklung
Und ja, unter anderem einer von meinen Entwicklern, Simon.
Ist jetzt fast genauso lange wie ich dabei. Puh,
zwei Jahre inzwischen. Schon mehr. Schon mehr. Und
wir sehen eigentlich sehr häufig dem Vorurteil PHP Sucks gegenüber.
Offensichtlich hier auch immer mal wieder ein Thema,
vielleicht nicht so drastisch ausgesprochen, aber ist ja schon so,
dass man Vorurteilen immer wieder begegnet.
Training Wheels with out the bike. Man kennt das,
man ist auf einer Party und ist irgendwie auch gut was
los, man unterhält sich.
Was machst du denn? Ja,
ich bin Informatiker
Steht man meistens dann nur noch in der kleineren Runde da.
Jungs, irgendwie vielleicht so vier. Und was machst du so für Sprache,
ja, PHP? Steht man auch alleine da gerne?
Wir haben das tatsächlich, wir haben das im Recruiting gehabt.
Da hatten wir irgendwie einen Kandidaten, der hat sich irgendwie
beworben bei uns. Und dann haben wir gesagt, hier,
wie ist es denn, irgendwie Architektur oder noch Entwickler irgendwie?
Wo können wir dich einsortieren? Sagt er, ja,
Architektur, das ist mir alles noch ein bisschen heikel.
Ich glaube, Seniorentwickler, das ist so das,
wo ich mich einsortieren kann. Und dann sagt er,
ach, PHP macht die ja nur, dann ein Architekt.
Das ist also das Selbstverständnis, dass PHP jetzt irgendwie eine Sprache ist.
Ich habe einen Kommiliton, Jan Helwig, ich weiß nicht,
ob das noch. Dem habe ich auch mal gesprochen,
hier, Icon, super Firma, gibt auch kostenloses Mittagessen,
willst du nicht bei uns arbeiten?
Er hat sich nie wieder gemeldet. Ich habe ihm erzählt,
dass wir PHP machen, er kam halt aus der Java-Welt.
Also es sind immer wieder dieselben Geschichten eigentlich. Und auf der Suche,
danach rauszufinden, wie es dazu kommt, war so,
klar, irgendwie mal Google-Fragen, was ist eigentlich am PHP so schlecht?
Und das Erste, was immer wieder genannt wird,
ist halt eine inkonsistente API. Das heißt,
wenn man sich das einfach die Parameter-Reihenfolge in Array und Strupos,
ja, es ist einmal,
gibt es das in dem Array und an welcher Position im String steht irgendwas.
Und die Nädel und der Hasteck sind halt einfach laut API
, vollständig vertauscht. Das heißt,
wenn man nicht sehr viel und sehr intensiv damit arbeitet,
hat man überhaupt gar keine Chance, abzuleiten, wie die Parameter-Reihenfolge sein könnte.
Es gibt die API halt einfach so vor. Anderes Beispiel
ist die Frage, wie verwendet man eigentlich TUB beim Konvertieren?
Strang to Lower, IDN to UTF8 oder bin to Hacks?
Das ist alles offiziell PHP-APIs. Es ist halt einfach durcheinandergewürfelt.
Es ist nicht konsistent. Nicht konsistent und es ist sehr schwer,
es sich zu erarbeiten. Eine andere Frage, benutzt man Unterstrich,
um zwei Worte in einen Methoden oder Funktionsnahmen zu trennen.
Ja, Strip-Slashes oder Strip-Tags. Ja, eins ist mit
unterstrich eins ohne. Und es gibt eigentlich auch seltene Logik,
der das Ganze folgt. Base-64-Endcode, URL-Endcode. Ja,
ist einmal mit, einmal ohne unterstrich. Das heißt,
wenn da so Flame Wars losgehen,
also auf Heise irgendwie immer, sehr beliebt,
dann sind das meistens die Argumente, die kommen.
Dann denkt man, okay, gucken wir uns mal irgendwas, Professionelleres an.
Gucken wir uns mal Wordpress an. Wordpress, State of
the art. Version 3 ist über 30 Millionen Mal runtergeladen worden.
Ich weiß jetzt nicht, wie viel davon wirklich installiert wurden.
Aber man geht von ungefähr 15 Prozent der Top-1 Millionen Websites
aus, die mit WordPress befeuert werden.
In der einen oder anderen Variante. Klar,
jetzt kann man auch sagen, nur weil viele Leute die Bild lesen,
ist das nicht richtiger, was da drinsteht.
WordPress staubt auch immer wieder Awards ab.
Irgendwie. Overall, best, Open-Source-Content-Management-System 2009. Oder Open-Source-Web-App of
the Year Award 2011. Also da denkt man, okay,
vielleicht ist das eine Referenz. So sieht PHP-Code aus.
Und dann bin ich mal reingegangen in so
ein Template
In Is Template 2011, weil die haben also jedes Jahr 2011,
liefern sie dann halt ein Template mit.
2012 gibt es in der aktuellen Distribution zumindest noch nicht.
Und da gibt es eine Datei-Index-PRP und da denkt man,
super, das ist bestimmt ein perfekter Einstieg.
Und dann mache ich die auf. Und muss sagen,
wenn er irritiert, if have posts.
Also das Fire geht wirklich genauso los.
Ich habe die Lizenz oben rausgenommen, glaube ich.
Also irgendwas im Kommentar oben. Aber da war Health posts
nicht erklärt. Und wenn Health posts war es,
dann wird 2011 content nough, nove a both und irgendwo
unten wahrscheinlich auch noch eine Nove Below.
Und Wile Health posts
The Post. Also, okay, alles klar,
The Post. Das wird man sicherlich irgendwo finden können.
Findet man auch. Es gibt da eine Datei,
die heißt WP Includes, Query PHP und eine Zeile 773
ist die Funktion The Post erklärt.
Global EP Query. Und dann wird The Post of VP
Query aufgerufen. Wer ist mit der PHP Syntax vertraut?
Okay, in Java ist dieser Pfeil ein Punkt.
Das ist also eine Methode auf einem Objekt.
Mit dem Dollar ist eine Variable
Ja? Gut. Hervorragend. Was also passiert,
es wird irgendwie WP-Quarry-Global deklariert, was Common Cent sein soll,
dass man es genau nicht tun sollte.
Und dann wird dieselbe Methode aufgerufen auf diesem globalen WP-Quarry-Objekt-Ding.
Ist aber wenigstens auch vernünftig da oben referenziert.
CWP-Quarry, the post. So, jetzt erwarte ich,
es gibt vielleicht irgendwo eine Datei, die heißt WP-Quarry und
da drin ist diese Klasse WP-Quarry und ich habe also weiter gesucht.
In derselben Datei, in Zeile 2778,
gibt es die Definition von The Post.
In der Klasse WP-Quarry
Jetzt haben wir hier ein anderes Global, Post,
es kommt halt irgendwo wohl her und in der Loop wird
auf Schuh gesetzt und wenn Carent Post minus eins ist,
was wohl so viel bedeutet wie The Loop, has just started,
dann wird irgendwas aufgerufen, was sich selbst per Referenz wohl irgendwo hinübergibt.
Was hier auch steht übrigens, ist super dokumentiert,
weil da steht, do action reph Array, Calls,
Loop Start, if Loop has just started.
Obviously va
Macht also keinen Sinn, an der Stelle tiefer einzusteigen.
Aber es ist ziemlich symptomatisch für das Vorurteil, dass PHP immer so entgegenspart.
Vielleicht allen Skriptsprachen, ich weiß nicht, wie ausgeprägt die Diskussion.
Hier sind aber das PHP, ach so. Ja,
und wenn du jetzt mit der Syntax von PHP
wenig Leute vertraut sind, wird das tatsächlich weniger lustig.
Aber viele von uns, die PHP programmiert haben,
da kann ich mich nicht rausnehmen, haben so angefangen zu debuggen.
Das heißt, man hat da irgendwelche Refires und Includes
und weiß sowieso nicht genau, was passiert,
weil es wird halt immer da required und included
Und dann wird eine SQL-Query zusammengesetzt und irgendwie kommt aber nicht
das Ergebnis aus der Datenbank zurück, was man eigentlich erwartet hatte.
Und dann sagt man, okay, ich mache erst mal einen Wardamp.
Wardamp, übergebe ich eine Variable hin und dann schreibt er
mir einfach raus, was es ist. Das funktioniert super,
weil es ist ja interpretiert und ich kann direkt im Browser
wechseln und 5 oder Apfel R drücken und dann zack,
steht da was drinsteht in der Variable.
Auch wenn es so wenig Leute gibt,
die PRP kennen oder die sie zumindest eben gemeldet haben.
Hat jemand eine Idee, was jetzt in Dollar SQL
steht?
Punkt ist Konnkadination
In dem Fall steht, Dollar ist in Dollar SQL oder
was Echo ausgeben würde, wenn man es einen kommentiert.
Also wenn die Kommentare alle weg wären, genau.
Was ausgeben würde. Dann würde Dollar SQL Doppelformulierzeichen ausgeben.
Doch, Wardamp gibt auch aus. Wardamp gibt den Inhalt
von Dollar SQL aus. Ah, okay. Das wäre,
also dann war die Frage, was steht jetzt in Dollar SQL?
Ja. Das ist von innen seit bis zum Ende
und teilen. Naja, also die Funktion da wurden ausgefertigt
Und Some I Team wurde auch ausgewertet, also 1,
3, 3, 7. Mhm. War auch unsere Annahme,
ist ein Real-Life-Beispiel, war ein Bug, der sehr schwer zu finden war,
weil was tatsächlich drinsteht, ist dieser Stream.
Weil, das Minus bindet stärker. Das zeigen die,
das möchte ich dann ein bisschen mal klammern. Ja,
das heißt, da komme ich erst mal auf den Wert
und dann wird der vordere Teil evaluiert zu offensichtlich null,
ja,
weil Autotype-Cast und dann wird noch Komma 6 rangehängt und
dann wird das Ganze in String gecastet
Ist natürlich schon ein bisschen garstig, weil man liest es
auch mehrmals und sagt, ja, da ist offensichtlich kein Fehler.
Und dann kommt man natürlich wieder auf diese Vardamt-Debugging-Geschichte,
weil man sagt, okay, dann geben wir es kurz
aus und es hat dir auch geholfen und den Fehler ja gefunden.
Was uns aber insgesamt zur Typisierung bringt. Ich habe da mal
ein paar Beispiele mitgebracht. Das ist die falsche Funny.
Ich habe da mal ein paar Beispiele an die Tafel geschrieben.
Also PHP offensichtlich nicht streng typisiert. Das heißt,
es werden Autocasts vorgenommen
Jemand eine Vorstellung, was dies hier ergibt,
also ich weiß nicht, ob das jetzt,
da steht True gleich gleich, Typisch in Open False,
Tüdelchen oben. Vielleicht habe ich auch ein bisschen Bock.
Wahrscheinlich wird das Fouls in irgendeinem Holo gewandelt.
Das dringend Fouls wird in dem Sinne umgewandelt, möglicherweise.
Keine Ahnung. Das ist der Faszinpunkt.
Der String ist nicht leer und deswegen ergibt der True,
weil man den Bullen nur anhört.
Das ist schon recht sophisticated, würde ich sagen.
Das heißt,
was kommt raus
So, hier ist dasselbe mit drei Gleichheitszeichen. Das ist natürlich
jetzt wieder die PHP-Geschichte. Wenn das ein JavaScript ist,
würde ich vermuten, dass jetzt vor euch das kommt,
weil das die drei dann da sind,
darf ich da nicht so vieles machen.
Nicht so viele ist schön. Also tatsächlich ist drei Gleichheitszeichen
in PHP eine den Typ berücksichtigende, eine Vergleichsoperation.
Also ich sehe die gleiche PHP. Das heißt,
in einer nicht typisierten Sprache,
die also in Wahrheit quasi dann irgendwie doch weiß,
dass das nicht so cool ist, nicht typisiert zu sein.
Das ist schon leer, es geht so,
dass da noch mit der Abrechnung.
Das ist jetzt
ein Lehrerstring
Ich war ja schon vorgesagt. Vorgesagt, ja. So,
Arhythmetik. Wahnsinn. Andere Vorschläge? Ist insgesamt jetzt nicht
so lebhaft, ne? Wenn einer was gesagt hat,
könnte man ja auch schnell zum nächsten weitergehen.
Wie sieht das denn? Null fallen von Fango Karlsson.
Also 500 sind auch Teile, Zahlen sind der Badekopf.
Also Inti-Gener
Ja, weil es kein Java ist. Ah,
es gibt so einen Notizer-Push, hast du es extra nicht.
Ja, wenn du ein bisschen der 0-12 schreibst,
dann ist es erfahren.
Ja, das ist 10 plus 0-12-20.
Um 10 plus 0-9. Wahrscheinlich denkt er sich da,
dass gar keiner ratalen Teil sein kann,
also macht er einfach mal so raus.
Noch mehr Ideen? Andere Vorschläge? Ich glaube, den
Namen war. Also das Richtige war noch nicht dabei,
ja.
Alles nicht. Er muss ja, muss ja eine Typo-Mannung machen.
Er wird ja wahrscheinlich die 0,9. Versuchen als Oktalzahl aufzufassen,
was nicht geht. Er macht tatsächlich eine Null draus.
Er ist auch 10. 10, ja. Hervorragend. Das
dann jetzt Boring, nachdem wir das x-mal diskutiert haben?
Und das? Das würde ich
auch sagen
Das könnte auch acht raushauen. Ich schreibe einfach mal mit.
Sechs, acht. 0-1-0. Als Mensch
. Auch noch, das war er nicht dabei,
in dem Fall ist es ganz trivial, 15,
weil Strings dann halt einfach als, da interessiert die Null halt nicht.
Ja, und wenn wir schon an Ergebnisse verraten sind,
es wäre ja auch... Also, das heißt ja,
nach welchen, da wäre ich die Präzedenzen, macht er das?
Oder wie ist da die Auswärtungsreihenfolge? Er wertet einfach bei
einem String die Zahlen, Also solange Zahlen kommen in einem String,
werdet er sie einfach aus wie ein Integer.
Du machst das von rechts nach links oder von links nach rechts,
weil ich würde ja erwarten,
also in Java würde das anders ausgewendet werden,
weil das als String gesehen werden,
dann steigen plus 5 und dann sind das Trinkkonkretationen.
Aber eine Stringkonkordination ist ein Punkt im PHP, das würde eh ausfallen.
Okay, also das ist nicht für Strings überladen.
Ein 3-5, dann 0-1,
0-1, 0-1, 0-1.
Bei was? Mal 5? Nee, ist ja nicht Ruby,
ja. Also im Völkelzweh, das glaube ich auch.
Ah, okay. Und das vielleicht auch noch,
das wäre ja zu einfach,
wenn hier tatsächlich jetzt bulsche Werte rauskommen würden,
selbstverständlich kommt hier eins raus und hier nichts
Also im Sinne von, nall, nil, irgendwie sowas.
Also es ist keinesfalls so, dass da dann wenigstens,
also es sind ja irgendwo auch bulsche Werte,
aber in der Repräsentation dann nicht mehr.
Was ist denn dann schon überhaupt? Ist das ein Schlüsselwort
oder ist das irgendwie in der Konstanz wieder auf eins geschätzt?
Das ist eine Schlüsselwort. Reserviert irgendwie. Wir müssen dann
ähnlich, weiß ich nicht, was geht bei TRP.
Ja, intern ist alles ein String.
Und? Erst? Tatsächlich ist das so. Jetzt könnte
man natürlich sagen, was soll dann der Quatsch?
Warum überhaupt PHP? Es scheint ja nicht besonders sinnvoll.
Das Blöde ist,
das Web tickt so ähnlich
Und also das Web hat ja auch keine Typisierung erstmal.
Eine Rest-API ist nicht typisiert. Wenn ich mir die Jason-API von Twitter
angucke, dann bekomme ich sowas zurück. Key Value-Pare,
wo offensichtlich in dem Key, man zahle zwei und drei,
in dem Key schon eingespeichert ist,
was es wohl für ein Typ ist, den ich gerade zurückliefer.
Aber am Ende sind es erstmal alles nur Strengths.
Einmal sage ich nur, ich gebe es als Strength
zurück und vielleicht kannst du was damit anfangen.
Ich mache mal ein Tüdelchen drumherum und einmal halt nicht.
Das ist halt was, was einem es ermöglicht,
gerade bei Webseiten, unheimlich schnell mit Prototyping zu einem Erfolg zu kommen.
Jetzt vielleicht nicht dauerhaft, weil ich habe neuen super Zitat gehört,
we have a lot of crappy code out there that makes are switch.
Also es sind halt sehr viele Seiten, die nicht den
tollsten Code draußen haben und die trotzdem gut funktionieren.
Wenn wir so an Prototypen denken, an mal schnell irgendwas umsetzen,
an time to market, dann ist PHP an der Stelle erstmal recht convenient.
Nur die Frage ist natürlich, wenn ich dann meinen Prototypen habe,
wie komme ich denn zum finalen Produkt nachher?
Das ist natürlich eine ganz andere Frage, die man
auch beleuchten muss. Und recht naheliegend ist zu sagen,
Nehmen wir Java. Da haben wir die ganzen Nachteile nicht,
da haben wir tatsächlich etablierte Enterprise-Great-Komponenten, die wir einsetzen können.
Das macht aus unserer Sicht irgendwie Sinn, so,
auf den ersten Blick.
So, halt.
Achso, ist so
So. Jetzt verstehe ich ein Bild. Das wäre der Quatsch. Ja,
aber PHP ist bei der Icons halt schon seit mehreren Jahren irgendwie im Einsatz.
Also eben schon gesehen, Pokerstrategy.com läuft halt auf PHP.
Und wir haben uns halt dazu entschieden, nein,
bevor wir jetzt unseren ganzen Leuten irgendwie Java beibringen,
einen professionellen Umfeld, probieren wir es doch weiter mit PHP,
weil unsere Seite läuft ja auch.
Und wenn man sich mal so umguckt, naja,
mein Gott, was brauchen wir denn?
Also in Java hättest du halt einen Application-Server,
in dem du deine App da irgendwie laufen lässt.
Das brauchst du im PHP halt nicht.
Du suchst den Web-Server, der irgendwie deine HTTP-Protokollschnackerei abmacht
Da ist es halt eigentlich ziemlich egal, ob du dich da für so
ein Engine X likedty oder den guten alten Patchy irgendwie entscheidest.
Alles kann hinterher irgendwie deine Ausgabe von deinem PHP-Skript irgendwie in die Welt pusten.
Und wenn ich mir halt dagegen mal jetzt irgendwie so ein J-Boss und Liferay,
kennt man vielleicht so ein CMS-System, relativ sophisticated irgendwie,
da brauche ich jetzt alleine nur,
um meinen Application-Server und die App zu bootstrappen, 1,2 Gigabyte-Speicher.
So, einfach nur so. Und da habe ich noch
keinen einzigen Request irgendwie bearbeitet. Bei Poker Strategy sind wir
im Moment so bei ungefähr 8 Mega-Bike, Teamspace pro Request,
also pro Interpreter mit allen Libraries und so weiter und so fort.
Sind da also deutlich schlanker und unsere App-Server laufen halt mit viel weniger ramm,
als ich für so eine Yova-App-Server-Kiste wahrscheinlich bräuchte und können so
natürlich auch ganz gut in die Breite skalieren.
Da können wir natürlich noch ein bisschen weitergehen.
Thema Skalierung ist PHP inzwischen auch ein bisschen weiter.
Also man braucht jetzt nicht mehr so ein Appetchy,
der einem da irgendwie haufenweise Prozesse folgt,
damit man auch ganz viele Requests gleichzeitig abarbeiten kann,
sondern PHP hat jetzt gerade mit 5,4 stabil geworden,
FPN, ein Fast-CGI-Process-Manager.
Das heißt, PHP selbst läuft als Demon auf so einer
zum Beispiel Unix-Maschine und kümmert sich halt selbstständig darum,
bei eingehenden Requests neue Prozesse herzustellen sorgt eben dafür,
dass gerade so Shared Libraries auch nur einmal im Speicher liegen.
Also man hat halt deutlich bessere Speichermanagement und eben gar kein Bootstrapping-Zeit mehr,
weil eben halt doch schon das ganze Framework,
was man zum Beispiel einsetzt, schon im Speicher rumliegt.
Da es PHP inzwischen also schon ziemlich weit und gerade was Skalierung und
halt viele User angeht, ist man da schon ganz gut gerüstet.
Es haben halt auch andere Firmen rausgefunden,
zum Beispiel Sand kennt man vielleicht, also relativ bekanntes Framework.
Die haben da also auch größere Firmen mit überzeugen können,
setzen also schon einige drauf. Es ist sehr,
sehr weit verbreitet und eben der Funktionsumfang von diesem Framework halt unglaublich,
weil egal, was ich halt aufsetzen will hier, Thema Rapid Prototyping,
ich kann damit eigentlich fast alles so out of the box tun.
Ich habe API-Anbindungen an alle möglichen größeren Dienste, was weiß ich.
Und wenn ich ein PDF generieren will,
dann kann ich das damit halt auch tun.
Da steht also dem in nichts nach. Ist allerdings,
also kommt diesem ganzen PHP-Gedanken ganz gut nach, ist halt ziemlich groß und monolithisch.
Aber vielleicht auch schon mal gehört Zymphonie und aktuell ist 5 Uni 2,
folgt da so ein bisschen mehr dem OO-Gedanken. Also auch das,
was wir aus der Java-Welt dann halt irgendwie mitgenommen hätten,
setzt eben ganz stark auf lose Kopplung oder auch Enotations,
die man in Java ja gerne nutzt,
um irgendwie die Konfiguration am Code zu halten.
All das ist ein Zymphonie
eigentlich schon umgesetzt
So Dinge wie Dependency Injection, kennt man sicherlich auch aus Java,
also wie sorge ich dafür in meinem großen Klassenbaum
irgendwie meine Abhängigkeiten zu managen und das Ganze noch zusammenzuhalten.
All das bringt eine Symphonie halt ins Symphonie 2,
halt schon out of the box mit und ich kann aber
trotzdem lose gekoppelt meine Applikation da drauf bauen,
habe also diese ganzen Benefits, die ich da so mitbekomme.
Thema Hypernate, also die Datenbank-Abstraktion von Java jetzt,
da haben wir das Pendant Doc Treen in PHP,
also auch so eine Datenbank-Abstraktion, die mir, man,
SQL-Querries sozusagen eigentlich auch in Objekten versteckt.
Hab da halt Adapter, alle möglichen größeren relationalen Datenbanken,
also von Myers QL bis zur großen Oracle,
ist da irgendwie alles dabei
Und ja, im Moment total hip,
die ganzen No-SQL-Dokumenten-Datenbanken, also Objekt, Dokument-Mapping für Couch,
Mongo und das PHP Content-Repository, was diesen Jazz-R187-Standard,
also für dieses Content-Repository, versucht zu implementieren.
Also da sind wir eigentlich auch schon relativ weit und nicht zu vergessen,
High Jair Unit kommt ja irgendwie von da.
Da gibt es halt das PHP-Unit-Pendant, mit dem ich halt
eigentlich auch recht komfortable Unit-Tests schreiben kann. Und mit dynamischen Mox,
also zur Laufzeit, aufgebauten Mock-Objekten halt Umgebungen,
die ich so benötige, um meine Units zu testen,
kann ich damit eigentlich auch ziemlich schnell zum Ziel kommen,
muss also keine Nockklassen schreiben oder was auch immer.
Hab das eigentlich alles schon so dabei. Ja,
und es ist halt eigentlich nicht nur das, was um PHP drumherum ist,
auch wenn das gerade ein bisschen schlecht gemacht wurde.
Aber wenn ich mir halt PHP angucke,
hat Stefan gerade schon gesagt, es ist halt irgendwie das Web,
es ist halt komplett requestbasiert und es ist halt genau da für diesen,
ja, für diesen Einsatzzweck eigentlich gemacht.
Und ja, eben keine Strecke Typisierung,
wie ich sie eben im Web halt auch gar nicht vorfinde,
weil zum Schluss ist halt irgendwie doch alles ein String,
was ich da so über die Leitung schicke
Ja, und wenn ich mich sonst so umgucke,
was ich alleine in PHP vorfinde, wo ich also gar
keine zusätzlichen Libraries installieren muss, ist halt wirklich krass.
Egal, in welche Richtung ich mich da bewege,
also wir sehen es ja schon, Image, Audio-Manipulation,
egal welche Kryptmechanismen, eigentlich fast alles im Chor vorhanden.
Und ja gut, die Kernfunktionalität, Strang und Array-Manipulation,
also wo halt auch irgendwie ja gerade hier Pearl schon mal gehört,
in die Richtung Skriptsprachen ja eigentlich,
so dass das Standard-Machwerk,
da ist PHP halt nach wie vor
sehr robust
Inzwischen eine mächtige Reflection-API-App bekommen,
also auch das irgendwie aus der Java-Welt bekannt,
kann er sehr gut auch dynamisch in meinen Objekten nachher rumfuhrwerken,
mit Packel und Pearl halt, ja, ein bisschen angestaubt,
aber es gibt halt eine ganz gute Paketverwaltung,
ich kann also jederzeit auch so Sir-Party-Libraries mir recht komfortabel in
meine Installation reinziehen und jetzt inzwischen ging auch mal so kurz durch die Fachpresse PeHP
Composer, also ein etwas ausgewachseneres Abhängigkeitsmanagementsystem, mit dem ich
also auch Third-Party-Lips irgendwie in bestimmten Versionen und mit allen Abhängigkeiten und halt Abhängigkeitsbaumauflösungen relativ schnell in mein Projekt reingekommen
Also die Entwicklung ist da eigentlich ziemlich rasant und es geht wirklich gut voran. Also hier nochmal so eine kleine Übersicht,
eigentlich alles, was ich so aus anderen objektorientierten Sprachen kenne,
habe ich inzwischen dabei mit Autoloading, ist eigentlich dieses,
was wir da vorhin gesehen haben, Require und Includes,
also diese typischen PHP-Statements, die dafür sorgen,
dass man irgendwie so ein Dateiwusted hat,
bei dem man gar nicht mehr weiß,
wer jetzt eigentlich wer ist und was schon included ist und was nicht.
So eine Probleme gibt es eigentlich nicht mehr,
das nimmt einem alles so einen Autoloader ab,
der halt automatisch dafür sorgt, dass Dinge,
die noch nicht im Interpreter liegen,
halt nachgeladen werden
Und das halt völlig transparent, naja, Namespacing,
Tie-Pinting für eben doch strikte Programmierung, also gegen strikte Typen.
Ich kann halt durchaus gegen Interfaces, Klassen oder was auch
immer halt programmieren. Anonyme Funktionen, also für alle Closure-Freunde,
kann sich eure in PHP ganz gut austoben,
gut abstrakte Klassen und so weiter, Exceptions,
halt alles, was so das O-O-Herz eigentlich begehrt,
inzwischen auch in PHP verfügbar und funktioniert ganz gut.
Also, mit PHP kann man doch ganz schön viel erreichen.
Ich glaube, ich muss das an dich übergeben
Also These an der Stelle halt einfach, PHP kann das alles.
Alles das, was ich erwarten würde, was sie als Rüstzeug
habe oder brauche, um irgendwie vernünftige Anwendungen zu schreiben.
Und das Problem ist halt, das geht aber nur mit guten Leuten.
Das ist halt einfach sehr einfach, Mist zu bauen.
Und zwar in jeder Sprache. Es gibt vielleicht Sprachen,
die einen dabei unterstützen,
Mist zu bauen
Das eben nichts zu tun. Aber es hängt trotzdem jeweils
vom Entwickel ab. Und es gibt ja sehr erfolgreiche Seiten,
die auf PHP setzen. Zu einer kann ich was erzählen,
weil wir sie zufällig betreiben. Nimm das kurz als Werbeblock
sozusagen. Nein, einfach was machen wir mit PHP?
Wir haben ungefähr 70 Millionen Seitenabrufe pro Monat mit sechs Millionen registrierten Nutzern.
Haben vermutlich viel zu viel Lines of Code.
Ich weiß gar nicht, ob viele Lines of Code
dann nachher positive oder eine negative Kriterium sind,
wahrscheinlich ein negatives
Jede Menge Traffic, viele Sprachen, 50 Server,
die den ganzen Kram betreiben.
Und das Ganze zumindest so in den letzten zwei Jahren recht stabil.
Also nachdem wir angefangen haben, eine Qualitätssicherung.
Also als Abteilung einzuführen. Muss man sagen, das hat
noch so eine Stabilisierungsphase. Und jetzt kriegt man kaum noch mit,
wenn wir ein Release haben. Was wir jetzt machen wollen,
ist einfach nochmal ein kleines Projekt vorstellen,
was wir für die Seite umgesetzt haben.
Und zwar einen ID-Check. Das Geschäftsmodell quasi,
das Pokerstology zugrunde liegt, ist ein Affiliate-Modell.
Das heißt, es wird kein Glücksspiel angeboten,
sondern es wird quasi eine
Strategie gelehrt, wie Pokern funktionieren kann.
Also Hugger ist halt tatsächlich wohl mehr als nur Glücksspiel,
sie halt so daran abbilden lässt,
dass ein Großteil der deutschen Schach-Nationalmannschaft ihr Geld mit Online-Poker verdient.
Und da gibt es halt Strategien, die zu einem gewissen Grad funktionieren.
Man bringt es den Leuten bei und schickt sie dann
quasi zu einem Pokerraum und gibt ihnen noch Spielgeld.
Also ein echtes Geld zum Spiel sozusagen mit, ging immer
50 Dollar. Und das ist für uns ein Problem,
weil es halt Leute auf den Plan ruft,
die die 50 Dollar haben wollen, aber nicht spielen wollen.
Fraud halt
Und um das zu verhindern, haben wir halt ein recht komplexes Fraud-Team,
das Analysen einfach fährt über N-Parameter von Herkunftsland,
städtischer Raum, ländlicher Raum, Geschlecht, Alter,
wie lange tippt jemand, bis er sein Kennwort eingegeben hat,
wie lange liest er irgendwelche Artikel.
Also man muss ein Quiz bestehen sozusagen,
um die 50 Dollar zu bekommen.
Und wie viele Artikel liest derjenige auf der Seite,
um bevor er das Quiz bestanden hat.
Und es gibt also unzählig viele Parameter und
anhand dieser Parameter erfolgt quasi eine Einstufung
Ob man denkt, dass es jemand ist,
der beschubsen will oder nicht, weil man einfach halt auf
einer Nutzerbasis von sechs Millionen ganz gut plastern kann.
Und wenn da der Verdacht besteht,
wenn die Leute halt aufgefordert, persönliche Dokumente hochzuladen.
Im einfachsten Fall ein Scan vom Personalausweis oder vergleichbaren Dokumenten,
bis hin zu einem Mietvertrag oder so,
der die Adresse quasi beweist, dass man wirklich dort wohnt.
Es schreckt vielleicht viele Leute ab,
aber da besteht halt auch immer schon der dringende Verdacht,
dass es sich um Betrüger handeln könnte.
Und beliebt sind auch Bilder,
wo man dann sein Personalausweis und neben sein Gesicht
halten muss und dann fotografiert werden muss,
damit man es quasi
so nebeneinander angucken kann
Dass am Anfang, als das System neu war,
hatten wir so zu Monitoring-Zwecke noch Zugriff drauf und man muss sagen,
da kommen wirklich lustige Bilder.
Jetzt ist das Ganze natürlich auch zu. Denn,
sieht also so aus, Personalausweis, Hochladen, Beef Page and Start ID-Check.
Und Privacy war natürlich eine der großen Anforderungen. Deswegen können wir
die Bilder jetzt auch nicht mehr sehen. Das heißt,
die Leute müssen in irgendeiner Form um uns vertrauen,
dass die Bilder halt da nicht wieder wegkommt.
Das wäre für uns ein PR-Desaster,
wenn plötzlich irgendwie ein paar Millionen Personalausweisscans irgendwo im Netz auftauchen,
können wir uns halt nicht erlauben
Das heißt, das,
wenn das Bild erst mal einmal angekommen ist auf dem Server,
dann darf ausschließlich ein Thumbnail zurückkommen, an den User gespielt werden,
damit er diese Maske quasi hat,
damit er sieht, was er hochgeladen hat.
War halt wichtig, wenn man sich irgendwie mal verklickt,
hat man plötzlich ein Bild von seiner Katze hochgeladen,
sagen wir mal.
Das will man ja vielleicht gar nicht. Das heißt,
Privacy auf jeden Fall, Performance ein Problem.
Wir hatten maximal 10.000 Bilder pro Tag und maximal 4.000 pro
Stunde zu Peak-Zeiten als Randrahmenkriterien,
Performancekriterien einfach ausgerechnet
Dass sie das Vieh schaffen kann, können soll.
Und auf der anderen Seite aber auch die Furcht,
dass man durch intensives Hochladen, also auch das System missbrauchen könnte,
denn die Bilder müssen auch umgerechnet werden.
Das heißt, nicht nur die Thumbnails werden zurückgeliefert,
sondern es werden halt auch für die Verwaltung,
also der Leute, die Bilder nachher angucken,
wenn so Previews generiert und eben auch die vollen Bilder abgelegt.
Das heißt, diese Bildmanipulation dauert halt eine gewisse Zeit und
es gab halt auch Bedenken, was die Performance angeht,
dass man einfach sagt, wenn er jetzt sehr viele Leute,
sehr viele Bilder gleichzeitig hochladen könnte,
halt der Server einfach den Geist aufgeben.
Was quasi einen erheblichen Einbruch unseres Geschäftsmodells zur Folge gehabt hätte.
Genau, Last-Kontrolle. Habe ich, glaube ich,
alles erzählt. Gut, wie haben wir
es gemacht
Also weiter im Text, ja,
mit solchen Anforderungen kommen dann also so Produktmenschen zu uns und sagen,
yo, das brauchen wir jetzt mal, irgendwie ganz schnell.
Und ja, was haben wir gemacht? Erstmal ist dann natürlich
dieser Sicherheitsaspekt irgendwie, der da extrem reinschlägt. Also als allererstes,
wenn man den ganzen Kram mal wegnehmen von dem ganzen App-Server-Kram,
der da vorne an der Front steht.
Deswegen gibt es da so einen großen hier grün gezeichneten ID-Check-Server.
Das ist halt quasi unser Fort Knox. Und hat halt so
eine API nach draußen. Das ist sozusagen der einzige Weg,
um überhaupt auf den Datenbestand, der da halt verschlüsselt drin rumliegt, zuzugreifen.
Und auch diese API, die übrigens per HTTP befeuert wird,
weil sprechen wir ja PHP
Auch die ist halt nur intern, in unserem internen Netz
überhaupt verfügbar. Das heißt, unsere App-Server,
also sowohl die Frontend-Maschinen, als auch die Sachen,
die eben Backoffice halt für dieses Frowd-Check-Team zugänglich ist,
die sprechen halt über diese API mit dem ID-Check-Server.
Und wir haben ja eben dieses Thumbnail gesehen, was da ausgeliefert wurde.
Das soll ja auch alles so ein bisschen Fair Ajax und Web
2.0 und so. Alles so ein bisschen nett aussehen.
Also haben wir dann noch so ein Ajax-Proxy dazwischen geschnallt,
der sozusagen die Aufrufe, die da aus dem Frontend kommen,
sozusagen umbiegen kann und auf diesen ID-Check-Server weiterleitet,
der dann eigentlich das eigentliche Ausliefern der Bilder sozusagen übernimmt und
eben über so ein Proxy wieder zurück an den App-Server
und zum Schluss halt so ein End-User steuert
Bitte? Als String. Als Stream, genau. Nicht als String.
Gut, gut. Das Ganze soll natürlich ein bisschen sicher sein.
Also hier haben wir ja gerade gehört, Lastkontrolle und Angriffsszenarien.
Das Ganze halt über so ein paar Sicherheitstoken abgesichert.
Das heißt also immer für jeden Upload und auch für
diese ganzen Abrufe werden halt ganz normale Tokens,
nennt man vielleicht so ein bisschen aus der Webentwicklung, generiert,
die halt pro Request eigentlich nur gültig sind und anschließend halt wieder verfallen.
Das heißt, ich kann, ohne dass der Server das vorher weiß,
immer nur einen einzigen Request eigentlich abfeuern und alles andere prallt halt schon am App-Server ab.
Das Ganze läuft halt über eine dritte Datenbank, die da so daneben steht,
auf die halt die beiden Systeme oder Systeme im Verbund halt zugreifen können.
Und darüber hinaus haben wir halt auf Poker Strategy für,
also es gibt halt noch ein paar mehr Systeme,
die da laufen, halt ein Single-Sign-On-Service.
Das heißt, ich kann mich an einem System anmelden und
habe dann sozusagen meinen Log-in-Status oder meine, ja,
meine Credentials und meine Zugriffsberechtigung sozusagen in diesem ganzen Rechnerverbund.
Und darüber wird halt noch zusätzlich die Zugriffskontrolle auf meine
eigenen Bilder sozusagen gesteuert. Das heißt,
ich habe da also schon mehrere Sicherheitsmechanismen,
die ich eigentlich überwinden müsste,
wenn ich da irgendwie an diesen Rechner rankommen will von außen
Das nächste Problem, haben wir gerade schon gehört, okay,
irgendwie maximal 4.000 Bilder pro Stunde und skalieren und Viren scannen.
Klingt jetzt erstmal ziemlich viel für so einen PHP-Server.
Was haben wir gemacht? Wir haben so eine asynchrone Message Queue eingesetzt,
durch von der Java-Welt, wie heißen die alle?
JMS und Rabbit MQ kennt man da, glaube ich, auch ganz gut.
Es gibt auch Gearman, das ist halt auch so eine Alternative.
Das heißt, wir können auf verschiedene Rechner diese ganze Last of Loaden.
Das heißt, wir schreiben die Originalbilder irgendwo hin in so
ein großes Storage und können dann ganz viele Rechner dahinstellen,
die über dieses Gearman Skalierfunktionalität bereitstellen. Das heißt,
die Server,
die die Bilder da abgespeichert haben und gesagt haben, hey,
wir brauchen jetzt mal einen wir einen Scan oder wir brauchen jetzt mal irgendwelche Preview- und Thumbnail-Ansichten davon,
können halt in diese Gearman-Q Bescheid sagen und hey,
schreib mir mal bitte hier diese Bilder in der skalierten Version.
Und dahinter stehen dann halt mehrere dieser Gearman-Worker. Insgesamt sind
das derzeit pro Rechner vier Worker für jeweils vier CPU-Kerne,
die dann halt nacheinander die reinkommenden Requests sozusagen abarbeiten und halt die Skalierung vornehmen.
Dabei haben wir einmal synchrone Prozesse für den Antiviren-Scan und das Thumbnail haben eine Generation,
weil wir natürlich, bevor wir skalieren, erst mal wissen wollen,
mit was wir es überhaupt zu tun haben.
Also wir wollen eben keine kaputten, manipulierten Bilddaten erst mal
überhaupt versuchen zu skalieren und durch irgendeine Bildbibliothek jagen.
Und danach halt direkt das Thumbnail generieren, weil das ist ja das,
was der Benutzer sofort als Rückmeldung bekommen soll.
Hier, hey, das Foto hast du hier gerade hochgeladen.
Das läuft also synchron ab und wir können halt dadurch,
dass wir mit Giermann halt mehrere Rechner dort nebeneinander platzieren können,
diese Prozesse auch durchaus synchron abarbeiten.
Dass später noch diese Preview-Ansichten zum Beispiel für dieses Through-Team skaliert
werden sollen, das läuft dann später asynchron.
Das heißt, die liegen irgendwo in der Cure rum,
diese Aufträge und irgendwann kommt dann mal als so ein Worker,
der gerade Zeit hat und skaliert einem das Bild zurecht.
Das ganze Great Success hat sehr gut funktioniert,
also wir haben ungefähr acht Wochen gebraucht mit zwei Leuten,
das Frontend dafür zu bauen und halt die ganze Backend-Geschichte,
die etwas komplexer war als das Frontend.
Aber wir haben bis heute eigentlich keine Leih-Last-Probleme,
das Ganze läuft auf einer virtualisierten Umgebung und ja,
das muss man sagen, doch recht stabil.
Also wir hatten so die letzten zwei Jahre,
glaube ich, genau gar keine Probleme mehr damit.
Ja,
also Problem gelöst
Dann war da ja aber noch das Problem mit den Entwicklern.
Und die damit behafteten Vorurteile, die man leider zu häufig auch bestätigt kriegt.
Aber nicht bei uns. Warum nicht bei uns?
Was tun wir? Tatsächlich ist es für uns im Recruiting
schon relativ wichtig zu sagen, man grillt die Leute.
Das heißt, wir haben einen recht umfangreichen Bewerbungsprozess,
den wir auch im Devblock bei uns veröffentlicht haben.
Und die Website kommt am Ende nochmal der Werbeblock.
Wo wir unter anderem auch längere Programmieraufgaben eingebaut haben,
um einfach auch die Leute sozusagen in freier Wildbahn beobachten zu können.
Wie nähern die sich dem Problem? Dass danach gestellt wird.
Weil behaupten, die können halt Leute immer erstmal viel.
Klassische Frage im Vorstellungsgespräch, nennen sie mal drei Pattern.
Ja, dann kommen wie Singleton, MVC und M.
Weil Singleton und MVC kennen die Leute halt und dann,
deswegen muss man nach dreien mindestens fragen.
Auf der anderen Seite bilden wir unsere Leute halt weiter.
Wir haben sehr regelmäßig Consultants im Haus,
die zumindest irgendwie im PHP-Umfeld, die man halt kennt,
aktuell sind irgendwie Sebastian Bergmann und Arne Blankerts bei uns.
Arne macht ein Code-Review, was den ganzen Security-Kram von unserem neuen Projekt angeht.
Und Sebastian sitzt bei uns in den Entwicklungsteams heute und morgen
und entwickelt mit denen zusammen Unit-Tests und auch funktionale Tests,
um einfach die Stabilität unseres neuen Projektes oder die Sicherheit der Entwickler,
dass das,
was sie geschrieben haben,
die Funktionalität des Projektes
nicht beeinflussen zu erhöhen
Gut, ansonsten, wir zertifizieren nach Möglichkeit, alle Entwickler
irgendwie mit der PHP-Zertifizierung. Wir schicken die auf Konferenzen,
das ist aber alles, glaube ich, relativ Standard.
Pair-Programming, Peer-Commits, Code-Reviews, also das,
was man tatsächlich so klassisch aus der Vorlesung fast schon kennt,
was irgendwie die Softwarequalität erhöhen soll und vermeintlich erstmal Zeit kostet,
versuchen wir flächendeckend einzusetzen.
Bei Pair-Programming, das ist immer so der springende Punkt,
das kennt dich vielleicht doch jeder selbst.
Das wirkt irgendwann so, als wenn es wirklich nur noch
Zeit kostet, weil man es halt auch runterschreiben könnte.
An den Stellen sind uns aber Peer-Commits ganz wichtig.
Das heißt, bevor jemand irgendwie seinen neuen Source-Code pusht,
muss halt einfach irgendjemand anders draufgucken.
Und wir versuchen auch, da eine Auswertung drüber zu fahren.
Das heißt, in dem entsprechenden Ticket, im Bugtracker,
wird dann immer der Name des Peers notiert und seine Einschätzung.
Daumen hoch, Daumen runter, war mir doch egal. Haben jetzt,
also mir doch egal, weiß ich nicht, wie viele,
aber ungefähr ein Verhältnis von 4 zu 1, was Daumen hoch angeht.
Das heißt, wir haben einmal den Effekt,
dass der Peer-Reviewer sozusagen noch was lernt.
Neue Teile des Codes einfach kennenlernt und sagt, ach ja,
so hast du das gemacht. Wie hat der gearbeitet?
Potenziell auch Fehler findet. Und was man nicht unterschätzen darf,
ist, dass der derjenige, der gerade programmiert,
weiß, dass das, was er demnächst pushen will,
ja nochmal von jemandem angeguckt wird. Das heißt denen,
ja, ich mache das jetzt hier erstmal so teil,
den spart man sich an der Stelle potenziell,
zumindest wenn er leicht zu finden ist.
Ja, nun. Ansonsten, ja, weitgehend Standard tut.
Ja, Standard-Tools halt. Wir haben Continuous Integration Server laufen,
wir haben den Mess-Detektor drüber laufen, irgendwie unsere Coding-Standards.
Wir haben verschiedene Kennzahlengrößen, von denen Manuel Pichler, der bei uns war,
uns die Hälfte auch erklären konnte, warum sie sinnvoll sind.
Und der schreibt so an Continuous Integration Server.
Da kann man ja aber vielleicht, macht ihr sowas auch?
Staatische Code-Analyse? Gar nicht? Ja. Vielleicht können wir
uns da einfach hier nochmal irgendwie hinsetzen oder austauschen,
dass wir da vielleicht nochmal ein bisschen mehr drüber lernen.
Weil wir haben eine ganze Menge in keinen Zahlen,
aber wir wissen an vielen Stellen tatsächlich nicht,
ob wir sie nicht noch besser auswerten könnten.
Jo, kurz zusammengefasst, vorhin schon gesagt, Schrott machen
kann ich potenziell in Niedersprache. Es kann auch einfach,
ein Jahr war eine relativ lange Public Static Voidmain runterschreiben und mich
sehr weit entfernen von dem, wie meine Software eigentlich aussehen sollte.
Ich kann mit guten Entwicklern umgekehrt in eigentlich jeder Sprache auch guten Code machen.
Und wenn ich eine vernünftige Architektur habe und Leute habe,
die sie verstehen und die sie auch umsetzen können,
dann ist das deutlich wichtiger, als zu sagen,
wir müssen jetzt aber eigene Sprache wählen,
weil der Source-Code dann besser wird.
Für uns war es rückblickend die richtige Entscheidung.
Wir haben uns sehr intensiv mit Java als Alternative,
also wir haben erst mal breit geguckt,
aber sehr schnell Java, als ernstzunehmende Alternative reingeholt.
Wir haben relativ lange evaluiert. Du selbst hast wahrscheinlich
zwei Monate irgendwie mit diesem Live-Ray-Viech gekämpft
Wer? Auch. Und es war tatsächlich einfach, ja,
make or buy, life ray halt auf der einen Seite,
aber auch PHP-Geschichten, Groupal,
auf der anderen Seite und haben dann aber irgendwann einen Cut gezogen und gesagt,
okay, PHP ist genau der Weg,
den wir sinnvoll gehen.
Das Skillset ist im Haus, die Leute sind gut,
wir sind schnell am Markt damit, es macht halt einfach Sinn.
Fragen? Nicht würde dieser Einstellungsprozess nochmal interessieren,
weil man liest dann jetzt die wildesten Dinge des Leuten
überhaupt nicht mehr geschleift worden sein können.
Was ist denn
so die Durchfall-Foto-Einstellungsprozess
Komme ich hier irgendwie mit einem Kabel ins Netz.
Da unten liegt was. Naja. Das ist bei den Internet-Kabeln.
Also von den, ich glaube, sind jetzt gefühlte Zahlen,
aber sie stehen tatsächlich ganz komplett für jedermann nachlesbar bei uns im Deathblog.
Das ist zumindest hier verlinkt. Und ich glaube,
unter Deathblog.iconsgmbh.com gibt es das auch direkt. Ich glaube,
mich zu erinnern, dass zwei Prozent der Leute,
die sich schriftlich bei uns bewerben, nachher eingestellt werden.
Und ein Großteil wird tatsächlich nach dem schriftlichen Teil
einfach schon ausgesiebt
Aus verschiedensten Gründen. Man kann häufig schon erahnen,
ob jemand eine Schleife programmieren kann, wenn man die Bewerbung liest.
Es ist aber tatsächlich so, dass man immer wieder auch in Vorstellungsgesprächen,
wo man sehr optimistisch reingeht, doch erschrocken ist,
ob der Qualität, die da abgeliefert wird.
Wir haben die Erfahrung gemacht und das widerspricht natürlich jetzt so ein bisschen dem,
mit PHP kann man alles erreichen, Statement, dass Leute,
die zuvor noch kein PHP programmiert haben oder das zumindest in dem Job,
den sie gerade planen zu verlassen,
nicht gemacht haben,
in der Regel die besseren Entwickler sind
Ich glaube, wenn einer im Lebenslauf stehen hat,
dass er zehn Jahre oder zwölf Jahre oder so PHP-Entwicklung hinter sich hat.
Das gilt zum Beispiel für mich. Dann musste er ganz aktiv zusehen,
dass er am Ball bleibt, weil sich die Paradigmen und
die Sprache eigentlich in dieser Zeit so extrem verändert hat auch.
Und man rennt natürlich ganz offensichtlich einem Java und so hinterher.
Man bewegt sich ja auf eine Sprache zu,
die halt auch Enterprise Great akzeptiert werden kann.
Und wie gesagt, ein Facebook zum Beispiel macht es
ja vor
Und dieses Type-Handing, was jetzt mit 5-2 schon kam,
wird, glaube ich,
jetzt bei 5-4 auch aufs Galare-Typen noch ausgeweitet.
Das heißt, ich habe jetzt tatsächlich in PRP 5-4 die Möglichkeit,
Type-Hinting mit einem String als Parameter vorzunehmen,
was für eine nicht typisierte Sprache doch recht überraschend ist.
Das heißt, die Sprache entwickelt sich weiter und die Leute sollten es auch tun.
Und wenn einer zehn Jahre lang Wordpress für lokale Handwerksbetriebe installiert,
hat er eben auch zehn Jahre PRP-Erfahrung,
aber es bringt uns an der Stelle nicht weiter.
Aber das heißt also, ihr bildet die Leute überwiegend selbst
aus oder bei die zum Beispiel an der Uni Lea nicht unbedingt, Skriptsprachen.
Das ist ja toll. Das ist ja für vor anderen Universitäten vergleichbar.
Das heißt, ihr müsst ja eigentlich ein ziemliches Problem haben,
Leute daran zu kriegen, die schon PHP können.
Ja, aber das ist, wie gesagt, gar nicht die Anforderung.
Die Frage kommt fast immer und deswegen will ich auch Vorbereitung sagen,
Simon zum Beispiel, ist zu uns gekommen,
ohne eine Zeile PHP quasi vorher geschrieben zu haben.
Vergegen Gewährt-PND so schön. Und wir haben ihn halt
einfach überzeugen können. Und du sagst,
es gibt bei uns eine freie Verpflegung und gute Gehälter,
wann willst du anfangen?
Und hat er dann auch gemacht.
Hast du
das vorher gemacht
Java und Dotnet, das ist schade. Und ja,
eigentlich aus der C Plus-Plus-Ecke überhaupt dann zur Objektorientierung gekommen.
Ja, und die Icons hat mich dann aber trotzdem überzeugen können.
Und ja, halt auch gelernt, dass man durchaus mit PHP,
vielleicht ein bisschen mehr Disziplin als in anderen Sprachen,
durchaus auch vernünftigen Code schreiben kann.
Also inzwischen, ja, PHP ist nach wie vor irgendwie...
Eine Hassliebe. Frickelware, muss man ja so sagen,
aber es funktioniert halt auch inzwischen.
Ziemlich gut. Also das erzähle ich schon mit Überzeugung,
was ich hier so sage. Und was das Ausbilden angeht,
muss man sagen, das ist halt kein Ausbilden in dem
Sinne,
Es ist erstmal nur eine Syntaxfrage. Im Idealfall sieht das Viech nachher
ziemlich genauso aus, wie ich es auch in Yava geschrieben hätte.
Ich habe meine Namespaces, meine Klassen, mein DI-Container,
das ist halt alles einfach genauso da,
wie ich es erwarten würde, wie es gut auszusehen hat.
Und die Leute brauchen halt einfach einen kleinen Moment.
Die Zeit geben ihnen natürlich, aber gefühlt sind die nach ein,
zwei Wochen soweit, dass wir sie einfach komplett sinnvoll einsetzen können.
Und nach zwei Monaten tief drin in der Sprache,
weil es ist so, als wenn man halt,
keine Ahnung, nach Bayern zieht.
Die sprechen da, ist Bayer hier
Um nach Franken zieht. Die sprechen halt
ein bisschen komisch da, aber man gewöhnt sich dran.
Und so ist es halt auch mit PHP auch.
Die beiden nach drei Monaten immer noch nicht verstanden.
Ja, ist mit PHP aber besser.
Wie viele Leute, wie viele Entwickler habt ihr denn?
So bummelig 25, würde ich sagen. Und welche,
welche Entwicklungsumgebung benutzt ihr? Von bis. Also,
wenn man tatsächlich mutig genug, dass sie sagen,
freie Betriebssysteme und freie IDE-Wahl
Das heißt, wir haben halt wirklich Windows, Linux,
Mac da und die benutzen dann halt das,
was ihnen da zur Verfügung steht.
Das heißt, vielen natürlich Net Beans, Eclipse,
weil es halt einfach Cross-Plattform da ist.
Clips dann halt mit PDT, also PRP, Development,
Toolkit, Tools oder halt sein Studio.
PRP Storm wird immer beliebter. Was haben wir noch?
Mehr braucht man nicht. Mehr braucht man nicht.
Stormbrei. VI und Demix. Gibt's auch, ja.
Echt? Den einen da hinten mit seinen vier Monitoren.
Gibt es auch einen. Unabhängig von der IDE,
die man benutzt, gehen ja viele Dinge,
sage ich mal, die man ans Werkzeug unterstützen bei Ciao bekommt,
gehen ja bei dynamisch typisierten Sprachen einfach theoretisch schon gar nicht.
Ist das, wenn du ja sagst,
du hast auch vorher Jara entwickelt, ist das nicht etwas?
Also das gibt mir eigentlich mal so. Ich muss sagen,
ich arbeite mit beiden viel, mit Jaro und dem PHP.
Und das ist das, was ich bei PHP eigentlich am
meisten vermisse, ist die umfangreiche Werkzeugunterstützung. Was ich also,
wenn ich Java programmiere, tippe ich eigentlich gar nicht selber,
Ich drücke immer nur Steuerung, Reinsteuerung, Leertaste.
Und das ist das, was... Das würde ich auch
dreckig problemlos hinbekommen. Da muss ich mal eine Lanze brechen.
Tatsächlich für Jetbrains, beziehungsweise PFP-Storm, für die Born of Web Storm.
Und die haben auch, glaube ich, eine Yata-Idee.
Wenn ich mich strikt an diese PHP-53-Features, also die Menschbreches,
Zeitpunkte, und eben halt auch strikte Typen.
Achso, sorry. Und strikte Typisierung, halte.
Dann habe ich in Storm eigentlich genau die Unterstützung,
die ich zum Beispiel auch von einem Eclipse in Yata oder
einem Visual Studio in CPlus irgendwie gewohnt bin.
Also komplette Autovervollständigung und auch ja, das weiß ich nicht,
Import von News-Statements für irgendwelche Klassen und so weiter.
All das habe ich da. Storm bringt jede Menge Refactorings mit,
also ob es ein simple, weiß ich nicht,
Unbenennung projektweit sind oder Extract Method, Field und wie sie alle heißen,
bringen die halt auch mit.
Und solange du dich eben tatsächlich an diese Type-Hins hältst,
kann man eben halt auch über statische Code-Analyse halt genau dieselben Funktionen zur Verfügung stellt,
wie ich sie halt in Yava-Out of the Box halt hätte.
Das heißt, solange ich mich nicht zu sehr von
diesem Pfad entferne,
funktioniert das
ziemlich gut
Und auch wenn es um so Sachen wie Debugging oder so geht,
haben wir ja jetzt hier eben so ein blödes Beispiel,
sag ich mal, aus, weiß ich nicht,
PHP-3-Welt oder so gesehen.
Also mit X-Debug, das ist so der D-Bug-Server für PHP eigentlich,
halt auch frei. Kann ich halt genauso komfortabel eine Applikation debuggen,
wie ich es zum Beispiel auch mit einem Java-Debugger oder,
weiß ich nicht, Dotnet-Debugger machen könnte.
Also da steht dem inzwischen wirklich in nichts mehr nach.
Und ja, tatsächlich,
ob es nun ein Eclipse-PDT oder so ein Netbeans mit PHP-Plugin ist,
das funktioniert eigentlich ziemlich gut.
Also da vermisst man eigentlich nichts mehr
Wie stehst du eigentlich mit der Trennung? Also zwischen Entwickler
und Designer bei solchen Webseiten, gerade bei größeren Webseiten,
schätze ich mal, habt ihr ja wahrscheinlich ein eigenes Design,
die sich in das Playouting kümmern.
Und bei Bleibanwendungen, die ich hier seit Java-Welt kenne,
dann programmiert man halt Java-Code.
Und dann hat man oft irgendwelche XML-artige Frameworks,
in denen dann angeblich die Designer das Layouting dann gespalten.
Und durch diese Trennung kann man dann halt so diese Aufgaben paralysieren.
Aus meiner PHP-Erfahrung, die mittlerweile schon fast der Zehnte hier ist,
kenne ich halt,
dass man also alles in einem Mischmasch irgendwie hat
Waren die Stellen ganz, ganz schwer erst mal gebindet,
wie jemanden rumschrauben muss. Also grundsätzlich bietet PHP auch Template Engines.
Es gibt irgendwie bekanntestes wahrscheinlich smarty. Twick ist jetzt im
Moment hip, weil es halt mit Symphony 2 daherkommt.
Aber es gibt natürlich auch irgendwelche XSLT-Prozessoren oder irgendwas.
Also da versucht man sich genauso aufzustellen. Ich glaube,
dieses alles ist in einer Datei, ist halt einfach dieser Gedanke,
der irgendwie von PHP als Sonne Skript-Kiddy-Sprache,
das Bild hat man ja.
Und da kommt es auch noch her
Tatsächlich finde ich aber, dass die technische Trennung nur die halbe Wahrheit ist.
Wenn du mich fragst, wie das in so Web-Projekten läuft,
dann ist es ja tatsächlich so sauber gar nicht zu trennen.
Zumindest nicht, wenn man dem Ganzen sich irgendwie ein bisschen
agil nähern will. Wenn ich irgendwo ein Wasserfallmodell aufspannen würde,
dann könnte ich natürlich von vornherein sagen, okay,
ich habe folgende Features und Design-Team sagt mir mal, wie es aussehen soll.
Wenn man sich dem aber wirklich agil nähert, dann muss
man ja eh Hand in Hand arbeiten. Das heißt,
dass da jetzt zufällig ein Trick in unserem Fall als Template-Sprache dazwischenhängt,
hilft teilweise den Designern ein bisschen die Angst vor dem Code zu verlieren.
Aber grundsätzlich ist, glaube ich, der Abstimmung,
also wirklich die Kommunikation viel essentieller als die Technologie dahinter.
Oder ging das an der Frage vorbei? Ich glaube,
die Vorstellung, dass ein Designer irgendwie ganz toll in so
einer abstrakten Sprache irgendwie sein HTML-Grundgerüst da zusammenbaut und das hinterher so,
ja, einfach so mit so einem PRP-Feel-Back-Add zusammenspielt,
ich glaube, das ist irgendwie Traumwelt.
Das gibt es, glaube ich, nirgends.
Das gibt es auch, glaube ich, in keiner Sprache.
Also selbst so ein tolles Tool wie Dream Weaver oder so
schafft es ja auch nicht
Irgendwie so eine Sachen miteinander wirklich zu verbinden. Also,
wie Stefan schon sagt, gerade der Kommunikationsaspekt ist da,
glaube ich, wirklich das Wichtigste.
Du kriegst halt auch plötzlich ein Wireframe rein, wo ein Dropdown ist.
Jump to Subboard. Programmierst ein Forum, da ist ein
Dropdown. Das hat irgendwo, ist im UX-Track entstanden.
Und da hat noch nie irgendein Backend-Entwickler von gehört.
Das ist halt einfach da. Und dann kannst du halt sagen,
gibt es halt keine Funktion, müsst ihr da rausbauen.
Oder man redet halt drüber und sagt,
ja, ist für uns eine Sache von einer Viertelstunde.
Das können wir schon unterstützen. Also,
die Schnittstelle ist da halt nicht
die Technik
Wenn ich mir das jetzt so anhöre,
und ich kenne PHPin tatsächlich wirklich wenig oder gar nicht,
dann ist ja PHP quasi das C des Webs.
Weil PHP hat sich ja weiterentwickelt,
genau wie sicher C dann irgendwann mal bekannt 10 plus plus.
Und man hatte immer das Problem bei 10 plus plus,
dass das rückwärts kompatibel sein soll zu ziehen. Das heißt,
man kann in C plus plus extrem sauber und auf einem Boden abstraktionsniveau programmieren,
wenn man weiß, was man tut,
wenn man extrem gut ausgebildet ist,
wenn einfach genau klar ist,
was man machen sollte,
was man nicht machen sollte
Man kann sich aber auch nach wie vor noch beliebig ins Knie schießen.
Und ich habe den Eindruck, das ist jetzt bei BHP
so ähnlich. Man kann die ganzen tollen Sachen,
die jetzt so nach und nach reingebaut wurden, benutzen.
Aber man kann auch nach wie vor sich beliebig ins Knie schießen.
Deswegen kann ich es natürlich verstehen, zu sagen, ja,
gerade bei solchen Sprachen brauchen wir extrem gut ausgebildete Programmierer.
Finde ich sehr nachvollziehbar. Also ich glaube,
das ist eher so ein... Es ist halt so,
wie es ist und deswegen finden wir uns damit ab.
Ihr seid ja jetzt nicht diejenigen, die sagen,
die Zukunft sollte eigentlich nur mit so einem Spatenprogramm geklärt werden
Das ist, glaube ich, eher pragmatisch eurer Hand jetzt heute.
Also für mindestens der Entschluss ist zu tun, war super pragmatisch,
genau, ja. Ja. Also ich denke,
auch der größte Vorteil an PHP und so ist halt einfach,
das ist einfach alles viel leichtgewichtiger aufzusetzen und deployen und dieser ganzen,
also dass das halt alles viel einfacher ist.
Also dass man eben nicht diesen ganzen, also auch gerade auch,
wenn man jetzt keine großen Projekte ranfängt,
sondern die kleinen Projekte,
dass man halt dieses ganze Behubere mit den Happication-Servern hier und
da und Bildprozess und so,
dass man sich das alles einfach spart
Zum Beispiel, wenn man in irgendeinem kleinen Projekt in Obers ändert,
und dann hat einer der Teile uns geändert,
dann spielt man halt die Datei auf Service.
Leuten muss nicht irgendwie da seinen Bildprozess anschmeißen. Ja,
für kleine Projekte gilt das sicherlich. Die Größenordnung,
die wir da jetzt inzwischen erreicht haben,
also gerade wenn du eben halt über so Multi-Server-Systeme und so sprichst,
dann ist Deployment halt immer ein Problem.
Also dann ist es halt auch egal, ob du da
so ein Wahrfeil hast oder ein Fahrfeil für PHP-Archive.
Das heißt, auch wir brauchen halt Bildskripte und es gibt übrigens
auch Fing, als Pendant zu ahnt vielleicht aus der Java-Welt.
Und da nutzt, das nutzen wir halt auch ganz exzessiv,
weil sonst würde man das Ganze halt auch nicht mehr unter Kontrolle bekommen.
Das ist, glaube ich, aber ab einer bestimmten Projektgröße für,
also gilt das, glaube ich, für alle möglichen Sprachen.
Ja, aber ich muss sagen, deswegen fällt es mir eben
auch ein bisschen schwer, nachzuvollziehen. Also ich habe euer Argument verstanden,
dass wir sozusagen das Know-how halt bei euch eher bei PHP lang in der Firma,
aber eben aus diesem Grundfeld ist mir halt immer so ein bisschen schwer zu sagen für große Projekte, nehme ich sowas.
Also ich würde als, also ich persönlich würde bei größeren
Geschichten dann immer irgendwie auf Java dann widersetzen,
weil es dann doch viele andere Vorteile dann mietet.
Welchen jetzt? Also... Naja, zum Beispiel,
dass es irgendwie von Haus aus streng typisiert ist und...
Ja, und dass man, dass man,
es ist ein Mehrentwickler, den könnte man, wie sie...
Also, ich glaube, die Message ist bei uns ja
auch gar nicht, ihr müsst alle PHP benutzen.
Die Message ist jetzt eher das Vorurteil, das herrscht,
ist halt so nicht mehr wahr
Ich glaube, dass halt PHP eine der geeignete Sprache ist,
um auch Projekte in echter großen Größenordnung,
wie wir es aktuell gerade tun, umzusetzen.
Also ich habe jetzt noch so zwei Punkte.
Also einmal das Thema Ausbildung, weil wir machen ja hier
jetzt seit Jahren die Programmierausbildung im ersten und zweiten Semester.
Das heißt, bei uns lernen die Leute hiperative und Objekte,
wir machen das auch Jects Herse, wir machen das mit UJ,
wir machen das mit dem zweiten Semester mit Entwurfsmustern.
Also wir versuchen schon, eine hochklassige Programmierausbildung zu machen
Das heißt, was wir sagen können, ist,
dass die Chance da ist bei uns ein guter Programmierer zu werden.
Ja. Wenn wir aber gucken,
wie viele von den Studierenden diese Chance auch wirklich ergreifen,
dann ist das ja schon nicht mehr ganz so viel.
Also wir haben ja einfach dann Leute,
die fahren durch, steigen aus,
dann die Noten sind ja auch gespreizt von 1-0 bis, ne?
Und also wenn ich jetzt mal sage,
wer bei uns in SE1 mit einer 4-0 besteht,
vermute ich mal, das wird nicht so schnell guter.
Ja. Auf der anderen Seite ist aber der Bedarf
unheimlich groß an gutem Programmierer.
Ich sehe dann immer nur so irgendwie nur diesen riesigen Bedarf in der freien Wirtschaft,
in verschiedenen Kontexten, was wirklich an guten Entwicklern gebraucht wird.
Aber auf der anderen Seite, was wir hier überhaupt nur produzieren können,
was einfach auch an Leuten kommt und wie talentiert die sind
und wie viel Spaß die an Programmieren haben,
weil man kann natürlich in der Informatik auch ganz andere Sachen machen.
Man muss ja nicht irgendwie in die Programmierung,
die Softwareentwicklung des Software-Tech gegeben, man kann ja auch die mit Bildverarbeitung beschäftigen,
dann ist das noch pure Mathematik.
Da ist einfach sehr viel, wo uns einfach auch vielleicht dann Leute weggenommen werden,
die dann eher forschungsintensive machen, wie ihr machen wollen.
Das heißt, das haben wir Leute,
die handwerklich gut sind in der Programmierung und dann auch noch sagen wir,
das so durchdringen und so viel Spaß dran haben,
dass sie das dann auch professionell weiter betreiben wollen.
Die gibt es einfach nicht. Das ist also mein Eindruck.
Es gibt einfach verdammt wenig gute Leute, die mit ihr produzieren.
Da sieht nicht noch unsere Ausbildung, das liegt einfach an den Leuten.
So, und das finde ich, ja,
das ist so ein Punkt, wo ich einfach auch nicht so richtig weiter weiß.
Vielleicht so am Rande erwähnt, es gibt jetzt Überlegungen,
die Informatik ein bisschen kleiner zu machen hier in Hamburg,
in anderen, weil dann wie gesagt, naja,
da brauchen wir ja auch noch mehr Informatik an der Uni.
Der Vorstell gar nichts Leute ist da so und dann könnte man natürlich sagen,
naja, vielleicht bilden wir hier einfach Leute ausführt und dafür sind aber nichts gedacht,
weil wir sind ja keine Fachhochschule.
So, und da gibt es einfach Leute,
die dann die Hände auf den Kopf zusammenschlagen sein,
was wollte ich an der Uni machen,
die wollten die Informatik dicht machen, das kann ja nicht angehen.
Also das ist, das finde ich schwierig damit irgendwie umzugehen.
Eine ganz andere Frage, die ich noch habe,
ihr habt gesagt, ihr habt mit PHP dieses System aufgesetzt,
das ist immer größer geworden und es hat inzwischen irgendwie 500.000 Lines of Code,
ist also ein relativ großes System.
Facebook ist im PHP geschrieben,
ich habe auch schon jetzt in diversen Kontexten auch privat Leute kennengelernt,
die in Firmen arbeiten, die mit irgendeinem netten,
kleinen System schnell groß geworden sind, in PHP irgendwas schnell aufgezogen haben.
Und irgendwann fällt es ihnen auf die Füße,
irgendwann kriegen sie die Komplexität des Systems nicht mehr geendet.
Das heißt, die Frage scheint ja,
das Problem verändert zu sein, dass das nicht schon skaliert.
Also dass man PHP super nehmen kann, um schneller was aufzuziehen,
schnell was aus dem Boden zu standen.
Aber sobald man eine gewisse Größe erreicht,
dann fängt das Ganze an, so ein bisschen an zu taumeln.
Und das ist vielleicht dann einfach bei der Größe dann auch so,
ich kann eben halt nicht so ein großes System mit lauter
Erstklassigen Leuten programmieren lassen
Ja, also ich vermute auch, dass ihr bei 25 Leuten,
da gut, das kann nicht sein,
dass ihr jetzt bei so einer kleinen Firma noch die Möglichkeit habt,
aber Facebook hat möglicherweise auch Schwierigkeiten,
dann da diese ganzen Top-Leute zu nehmen,
dann würde ich wieder weltweit werden, das ist was anderes.
Also, wo es mich hinausfilmt ist, das Spannende ist
doch, gibt es eine Strategie, eine Migrationsstrategie?
Ihr habt jetzt irgendwas angedeutet, dass Facebook sowas macht,
dass die mitschrittweise auch Java umsteigen, oder habe ich das falsch verstanden?
Nee, also grundsätzlich, das sind natürlich verschiedene Baustellen,
das Skalieren an sich, hängt jetzt bei Pogastrology in der aktuellen Version,
einzig und allein an der Datenbank.
Weil wir halt die, dadurch,
dass das alles Request basiert ist und das ist halt quasi
jeder Request im Endeffekt abgearbeitet werden kann und das parallel.
Und zwar beliebig parallel, kann ich halt im Zweifel einfach
neue Kisten dazustellen. Entschuldigung, nicht skalieren,
jetzt verwechseln mit Benutzerzahlen, sondern mit Programmfunktionalität und Programmkomplexität.
Das meinte ich, ja. Okay,
da sind wir tatsächlich gefühlt an einem Ende angekommen,
das einherging mit der Erkenntnis,
dass wir uns nicht dauerhaft abhängig machen wollen von Puckerspielern
Und das ist das neue Projekt, was jetzt schon zwei-,
dreimal hier zwischen den Zeilen fiel, dass wir einfach gesagt haben,
okay, wir starten auf der grünen Wiese,
wie es Informatiker so lieben.
Und dann wird es wohl sauberer im nächsten Wurf,
wo man da auch sehr stark mit diesem Zecken-System-Effekt kämpfen muss,
weil wenn man gleich alles besser machen will,
dann kann man auch gerne übers Ziel hinausschießen.
Aber wenn man halt einfach als neue Strategie im Endeffekt gesagt,
wir bauen ein Framework auf deinem Perspektivisch Tocastragy aufsetzen kann,
aber eben auch beliebige weitere Verticals.
Das heißt, wir haben an der Stelle wirklich einen Schlussstrich
gezogen und gesagt, okay, wir kommen mit dem System
nicht weiter
Ich weiß allerdings tatsächlich nicht. Ich wüsste denen das dann auch wieder.
Das neue System ist auch wieder PHP, aber eine Architektur,
die unserer Meinung nach von Anfang an auf Skalierung ausgelegt ist.
Zukunft wird zeigen. Die ist noch nicht ganz klar,
wo überhaupt diese Annahme herkommt, dass dynamisches oder das Skriptsprachen nicht gut skalieren.
Warum? Also ich habe ja auch schon gesagt,
dass Code Computional Refactoring ist jetzt alles da drin,
also welchen Grund sollte es überhaupt noch geben ins PHP,
nicht ins Vergebnis. Also ich glaube, ein großes Problem,
also um das auch nochmal aufzugreifen, eben gerade diese Funktionsskalierung da drin,
in PHP habe ich halt einfach deutlich mehr Möglichkeiten,
Dinge von auch falsch zu machen oder auch von Grund auf einfach mal selbst zu bauen.
Selbst zu bauen, zum Beispiel meine Datenbank-Anbindung,
was eben auch so ein bisschen auf dieses Request basierte abzielt.
Ja, ich kann so ein Skript schreiben,
das baut halt bei jedem Request so eine Datenbank-Verbindung auf und
dann klappt das auch mit 20 Requests parallel ganz gut,
weil 2000 wird das schon ganz schön knapp,
dann so viele TCP-Verbindungen irgendwie zum Myosqueer-Server meinetwegen zu handeln.
Und da wird es dann halt plötzlich schwierig,
wenn das so überall durch die Applikation durchgezogen ist,
dass dann mal durch irgendwas auszutauschen,
was vielleicht so ein Connection-Tool oder so benutzt jetzt mal als Beispiel.
Da bin ich vielleicht mit so einer Sprache wie Java schneller
auf dem richtigen Weg, weil ich vielleicht viel eher anfange,
sowas wie Heidernate
zu nutzen
Bei dem ich hinterher, also solche Probleme relativ leicht irgendwie angehen kann,
also ich schon viel früher auf Abstraktionen irgendwie aufsetze,
weil mir das Primework ja auch sehr viel bietet und ja auch sehr viel vorschreibt.
Ich glaube, das ist ein Problem in PHP,
aber auch da geht es halt in erster Linie um Disziplin.
Also wenn ich halt weiß, was mir das,
mein Ökosystem da bietet, also vor allen Dingen,
was mir der Core tatsächlich auch bietet,
dann kann ich auch diese grundlegenden Fehler schon sehr früh vermeiden.
Ich glaube, das ist tatsächlich einfach ein Erfahrungsproblem.
Und gerade so kleine Start-ups,
die schaffen es tatsächlich in PHP sehr, sehr schnell,
was umzusetzen,
aber da ist die Codebasis eben tatsächlich oft wohl nicht objektorientiert
Und so wie das WordPress-Beispiel am Anfang ja eigentlich perfekt illustriert,
einfach nur extrem gewachsen und so lange zurechtgetreten, bis es halt irgendwie funktioniert.
Da kann ich dann zwar noch ganz schön viele Requests mit abhandeln,
aber mit Erweiterbarkeit ist da irgendwie nichts mehr.
So, das passiert halt einfach. Was bei dieser Skalierung
aus meiner Sicht niemand PRP besonders schwergefallen ist,
wir haben ja bei Java zumindest einigen Ratschlägen, wird immer vorgeschlagen,
eine hohe Strukturähnlichkeit zwischen meiner Anwendungstermine zu haben und meiner Code.
Das heißt, wenn ich eine Banksoftware entwickle,
finde ich auch irgendwann mal eine Kontonummer als beispielsweise oder ich finde den Kunden als Klasse in meinem Programm. Bei dem,
was ich in der PHP-Welt kennengelernt habe und das Eingangsbeispiel ja wunderbar,
22.000, 2.800 Zahlen Code oder wie auch immer,
dass da diese Strukturdienigkeit nicht,
also das klingt natürlich auch in den Leuten,
aber ich habe auch das Gefühl, das liegt bei der ganzen PHP-Mentalität,
dass das nicht so unbedingt dort geliebt wird in dem Sinne.
Und dass ich einen Code habe,
bei dem ich das nicht unbedingt von außen draufschauend erkennen kann,
was habe ich für eine Architektur, wo sind meine Services,
wo sind meine ganzen Business-Objekte und so weiter und so fort.
Wie ist denn der gesamte Zusammenhang aus diesen ganzen Inclus,
fällt das mir deutlich schwer,
die in dem Zusammenhang in der Software zu erkennen.
Und dass das eigentlich so die Punkte sind,
die zu einer schlechten Skalierung beitragen. Nicht irgendwelche Frannos,
die da drunter ist, irgendwie nicht vernünftig eingesetzt wurden.
Das war jetzt mein Eindruck, aber das liegt natürlich am Entwickler.
Ja, genau, auf die Frage.
Selbst mit eurem guten Entwicklern habt ihr das Gefühl,
dass das, also bei euch im Griff ist,
was diesen Punkt angeht oder ist da, im Griff hast du es nie.
Du hast immer irgendwie wieder, keine Ahnung, zwei Leute,
die zusammensitzen und sagen, so machen wir es.
Aber ich meine, das kann einem, glaube ich,
auch in jeder Sprache passieren
Aber wenn du die Tools einfach implementierst,
das ist halt Reviews, also Peer-Commits heißt das doch.
Durchtauschendes Pair-Programming machst, dann kriegst du es recht gut in
den Griff. Dass wir solche Klassen haben,
die VP Query heißen, oder ich hatte eben gesagt,
wir haben bei Pokerstrategy dieses Quiz, das man bestehen muss.
Da gibt es tatsächlich immer noch so als Altlastende Klasse,
die heißt Basic to Quiz,
die den Pfad des Benutzers von Basic-Status zum Quiz bestehen,
simulieren soll, die diesem Ratschlag halt genau gar nicht folgt.
Das heißt, ja, du musst die Leute skillen,
musst einfach sagen,
so ist es gut und so ist es schlecht und du
musst es begründen und sie müssen es verstehen
Und das versuchen wir halt sehr intensiv on the job zu tun.
Und ich denke, recht erfolgreich. Ein Problem dabei ist,
glaube ich, auch so ein bisschen die Historie von PHP.
Du hast ja eben gesagt, es gibt ja viel mehr Java-Entwickler als PHP-Entwickler.
Ich glaube, es gibt da draußen richtig viele Leute,
die sagen, dass sie PHP entwickeln können.
Die können auch bestimmt alle PHPs schreiben, also darum geht es ja nicht.
Aber wenn ich mir halt so diese typischen alten PHP-3-Skripte so angucke,
dann sind das eben genau so eine verwobenen HTML und irgendwelche IF-Bäume zusammengewürfelt in riesigen Dateien.
Ja, wenn ich dann sage,
ich kann halt jetzt PHP programmieren, dann mag das verschwimmen,
aber dann habe ich halt wirklich ein Problem,
weil ich was Großes bauen will.
Und da kommt PHP halt her. Und ich glaube,
genau deswegen gibt es auch diese vielen Vorurteile.
Also nochmal, ich glaube, es geht wirklich darum,
irgendwie bewusst und mit viel Disziplin irgendwie da ranzugehen.
Also vielleicht auch mit mehr Disziplin,
als ich es vielleicht bei Java bräuchte,
weil mir da irgend so ein Bitecode-Compiler auf die Finger haut,
wenn ich da Blödsinn mache.
Das klappt in PHP halt nach wie vor. Aber da
ist eben der Entwickler gefragt. Also was mich ja nochmal interessieren würde,
ist, wir haben zum Beispiel auch,
also halbtags noch in der Softwareentwicklungsfirma beschäftigt und wir haben dort
unheimliche Probleme,
Leute ranzukriegen,
gute Leute ranzukriegen
Die also im Jahre im Umfeld,
das muss ja bei euch denn also noch extremer oder noch verschärfter sein,
das Problem, weil wenn die sagt,
also uns reichen nicht diese, sagen wir mal, so Dreierkandidaten,
wir brauchen zwei plus mindestens, damit wir das,
also unser System auch recht erhalten oder im Leben erhalten können,
dann so eure zwei Prozent Einstellungsquote spricht ja schon mehr oder weniger Bände,
dass das also,
stemmen euch die Leute momentan nicht aus?
Also verblutet ihr nicht an in einem anderen Nachwuchs?
Super was dazu sagen, dass Theresa aus der HR bei uns
, die kann man vielleicht erst seit Quelle beantworten.
Ja, es stimmt, es werden viele abgelehnt,
also wir kommen auch wahnsinnig viele Bewerbungen rein
Das kann man wirklich aus jeder Ecke mit allen guten Backgrounds für Werbung.
Und es sind doch, also recht häufig, auch gute dabei.
Es ist halt, es hält ja nicht nur das fachliche.
Da muss man natürlich noch auf den persönlichen Füllkrug hoppen.
Habt ihr wirklich auch menschlich, zur Stirn, man passt.
Also wir bekommen auf jeden Fall viele Bewerbungen.
Daran scheitert es auf gar keinen Fall.
Das Schwierige ist dann eben nur wirklich auf jeder Komponente,
das abzuwägen, dass wirklich alles passt.
Weil letztendlich ist es ja für beide Seiten immer profitabler,
wenn es perfekt passt.
Ich kriege immer
diesen Perfektanspruch hat
Dann ist halt sobald der kleinste Zweifel da ist, wird darauf abgelehnt.
Ja, das ist einfach nicht an den Bewerbern.
Aber wir haben letztes Jahr, wie viele?
Zehn Entwickler? Eingestellt. Würde ich mal so schätzen.
Also seit letztem Jahr haben wir irgendwie so eine Vornamensüberladung.
Also es gibt irgendwie ganz viele Michaels und Stefans und Oliversum.
Ja, ja. Also aber daran merkt man,
dass man... Sascha ist nicht mehr alleine.
Da achten wir jetzt auch nicht so drauf, genau.
Wie ist das Verhältnis so dazwischen zwischen Entwicklern und Sonstigen
Also, also wir sind am Standort 75 Mitarbeiter ungefähr.
Das heißt 25, also ein Drittel Entwickler und zwei Drittel sonstige tätig. Ja,
wenn man dann jetzt, also wir haben noch Süß-Obs,
die sind zu 3 plus 3, 3,
die sich quasi um die Infrastruktur kümmern und eher so lokal,
also Windows-Netzwerk-Domäne und 3,
die sich halt um die Server im Live-Betrieb kümmern,
dann haben wir halt die Analytics-Leute noch,
die also genau zum Beispiel diese Player-Quality-Forecasts machen,
die also aus einem sehr akademischen Background eigentlich arbeiten
Dann haben wir Research und Development, zwei, drei, ein kleines Team.
Also dann haben wir noch Applikationsentwicklung, die machen dort nett.
Also der IT-Teil insgesamt ist größer als 25. Ich würde sagen,
das ist sehr bummelig, zwei Drittel ausmacht.
Wie viel seid ihr im zweiten Stock? So, über
den Daumen? 20? Okay. Also ungefähr dann.
Zwei Minuten Technikerin. Ja. Und das ganze Produkt selber wird von
ungefähr 150 Mitarbeitern in die Breiter gepflegt. Das heißt,
da haben wir dann Customer-Service-Community-Management Produktentwicklung selber,
bis auf den CIO oder auch das gesamte C-Level-Management,
sind damals aus rechtlichen Überlegungen, weil es halt einfach unklar war,
wie grau die Grauzone ist, Poker Education anzubieten,
man halt da gesagt hat, das ziehen wir da hoch.
Das heißt, wenn man die tatsächlich noch mitrechnet,
dann sind wir ein ziemlich kleiner Prozentsatz ITler.
Wenn unsere Sprachwahl, die wirken sich eigentlich bei mir fehlen,
hat PHP wirklich aus, wenn ich da zum Beispiel Methode versuche aufzurufen,
die es gar nicht gibt.
Was passiert dann einfach nicht, so etwa drinnen eine Standardmethode aufrufen,
wirklich Stack Trace, warum ist das passiert?
Ja, letzteres
Das Skript der Interpreter bricht halt einfach ab.
Und ja, hast halt dann quasi eine leere Response,
wenn du jetzt über HTTP sprichst. Und im schlimmsten Falle
eben halt so ein Stack-Trace da drin, so das,
was du dem Endnutzer vielleicht dann nicht mehr zeigen willst.
Es gibt da aber auch Abstufungen,
also dass eine Methode aufrufen, die es nicht gibt,
wäre jetzt halt schon so ein fataler Fehler,
dem der Interpreter halt aussteigt.
Aber ich kann halt durchaus zum Beispiel auf nicht deklarierte Variablen zum Beispiel zugreifen.
Das wäre dann halt nur so eine Notice.
Also das Skript läuft dann irgendwie weiter. Und das,
ich glaube, in WordPress ist das auch ganz normal.
Bei uns ist das inzwischen so, der Interpreter ist halt
so konfiguriert, dass er halt extrem strikt ist.
Das heißt, selbst bei so Notice Geschichten bricht er halt ab.
Und da geht es dann halt auch nicht mehr weiter.
Beziehungsweise inzwischen werden diese Notices eigentlich dann auch in Acceptions verpackt,
sodass man die dann halt auch noch irgendwie so halbwegs craceful irgendwie abarbeiten kann.
Heute in 500er und denen normalerweise nett anzeigen.
Ist es in der Praxis überhaupt noch ein Problem?
Also es gibt da jetzt so diese Denkrichtung,
wir haben ja Unit-Tests, da können diese Fehler einigen,
die wir noch nicht positiv wissen.
Ist in der Praxis ein Problem. Wir haben tatsächlich eine Tesla-Abdeckung von,
na inzwischen vielleicht nur noch so 68 Prozent,
wir hatten mal 70 ausgerufen,
aber seit zwei,
drei Entwicklungszyklen verfehlen wir die knapp
Und man sollte annehmen, damit stehen wir gut da.
Aber wir haben jetzt gerade zweieinhalb Wochen extrem das Bugs-Fixen hinter uns.
Haben irgendwie bummelig 300 Bugs aus dem Bug-Tracker rausgeworfen, was gut war.
Aber in der Zeit halt 220 neue reingekommen. Ja,
also sind das dann einfach so logische Bugs,
dass da irgendwas falsch gerechnet wurde oder wären das Bugs gewesen,
die jetzt zum Beispiel ein Statussklubsystem erkannt hätte.
Nee, logisch. Absolut nicht. Absolut logisch. Also gerade dadurch,
dass wir halt mehrere Technologien noch nebeneinander einsetzen müssen,
halt im Freundendbereich hast du halt noch JavaScript,
was ja inzwischen auch irgendwie immer komplexer wird
Halt hübsche Webseiten, die sich irgendwie ganz toll bewegen und so. Jo,
da ist, da steckt halt erstmal sehr viel Fehlerpotenzial drin,
vor allen Dingen, wenn die Dinger dann auch noch unkontrolliert mit den App-Servern nebenbei noch sprechen.
Und ja, da passieren dann halt auch einfach mal so Dinge,
die man halt auch mit statischer Code-Analyse einfach nicht mehr zu fassen bekommt.
Und was dann halt auch häufig so querschnittliche Aspekte werden,
wo du halt gar nicht mehr das Problem in einer Unit irgendwie identifizieren kannst,
die sich falsch verhält, sondern es ist halt mehr so die Komposition aus allem,
was dann irgendwie halt mal gegen die Wand geht.
Und auch das schafft man halt in Java oder CSH problemlos.
Auch Bugs, die Annahmen über Interfaces beinhalten,
die nicht wahr sind, die man technisch gar nicht abfrühstücken könnte.
Oder nur mit Aufwand. Also ich frage an irgendeinem Content-Service
ein Objekt an und erwarte, dass ich es zurückbekomme.
Und die eine Seite des Interfaces nimmt an,
es bekommt nur was zurück, was es auch öffnen darf.
Einfach vom Rechtesystem. Und die andere Seite des Interfaces sagt,
ich gebe es dir zurück und du musst entscheiden, was du später damit machst.
Und das ist in dem Fall noch okay,
weil mir kümmert sich halt einer drum,
aber wenn beide annehmen, der andere kümmert sich,
dann knallt es plötzlich irgendwo und du kriegst halt deinen 500 oder 403 und ja,
dann gräbt man sich halt ein und guckt,
wie es dazu kommen konnte
Ist das nicht, jetzt gerade das Beispiel ist ja ganz,
ganz nett, ein Schüttstellen-Ding und man weiß jetzt nicht,
wer zuständig ist, also dieser Hoffnung hat Zuständigkeiten, sind ja durchaus,
sagen wir, geschärft, wenn man das Vertragsmodell umsetzt.
Ein Vertragsmodell oder Design by Contract, also Vorbedingungen, Nachbedingungen,
Varianten, ist das bei euch auch in der Praxis drin?
Ist das ein VHP üblich in der PHP-Welt,
weil wir lehren es ja auch bei uns hier im ersten und zweiten
Semester auf dem zweiten Semester und es ist in Java nicht unterstützt,
aber wir beobachten, dass jetzt immer mehr Sprachen sowas auch integrieren.
Es gibt also Sprachen, die das haben,
in den neuesten AIDA-Versionen gibt es das Vertragsmodell, also Vor- und Nachbedingungen.
Also irgendwie hier James Gosling, der Designer von Java, hat gesagt,
wenn er gedurft hätte, hätte er es reingebaut im Java,
er hatte es schon drin und dann hat er es wieder rausgeschmissen,
weil die Programmierer zu seiner Zeit das nicht verstanden haben,
dass er da mit dem Weg.
Nein, ist nicht... Ist komplett nicht das Thema,
ja. Also klar, man hat natürlich zu einem gewissen Grad
über Unit-Tests mit Vor- und Nachbedingungen, die ich meine, auch abprüft.
Ja, aber in Varianten kriege ich da nur sehr schwer
dann rein,
Und im Zweifel testet man auch immer genau die Varianten,
die im Feld irgendwie geradezu, die gerade im Feld eben nicht zu Problemen führen.
So, das ist sicherlich nicht vergleichbar. Oder B2PHP,
meine ich, wüsste es auch nichts. Aber wir haben
tatsächlich überlegt, sowas auch mal noch drauf zu setzen.
Also in kleiner Runde und nicht richtig ernst gemeint.
Man kann es ja selber machen. Ja, eben drum,
man könnte einfach die Bug Environment definieren und sagen,
falls das Environment so gesetzt ist, wird halt ein,
keine Ahnung, Decorater nochmal vorgeschaltet oder was.
Und der kann dann zumindest irgendwie sehr intensiv vor und nach Bedingungen
prüfen. Ja, also Die einfachste Möglichkeit ist,
ja, aber auch Vorbedingungen zu formulieren in den Kommentaren,
weil dann schon gezwungen ist, sich zu überlegen,
muss ich jetzt dafür sorgen und dann muss der Klient halt irgendwie auch aufpassen.
Ja. Aber noch eine Frage in diesen ganzen Java-Script-Kram,
schreibt ihr den irgendwie per Hand oder gibt es da auch
so Frames und wie ein Java-GMET oder sowas,
dass man das irgendwie im PHP programmiert und das generieren möchte?
Nee, ich meine, es gibt Frameworks, aber ja,
Script Frameworks halt. Also wir schreiben ja was direkt. Ja,
oder in unserem Fall wird es dann Why UI werden, aber ja.
Das ist vorhin viel, also es ist nicht viel,
aber die weiß Wörter vielen synchron und asynchron.
Muss man sich im PHP damit beschäftigen, oh Gott,
was passiert, wenn ich mitten in der Methode bin und jemand
andersrum gleichzeitig eine andere Methode auf der Kante muss ein bisschen.
Das ist, glaube ich, ein großer Einstiegsvorteil von PHP.
Es ist halt nach wie vor Singles-Reddit,
also von Natur aus gibt es da halt kein Mighty-Shreading.
Das wird schnell zum Problem, wenn du eben halt so Hochlässszenarien irgendwie hast.
Dann ist aber natürlich für den Entwickler erstmal total cool,
wenn man sich halt eigentlich viel weniger und Race-Conditions und so weiter kümmern muss.
Ändert sich natürlich, wenn ich auf externe Ressourcen zugreife.
Also gerade so Datenbanken oder so,
wo man ja auch immer wieder eventuell consistency,
read your own rights und so weiter, solchen Problemen stehst du natürlich dennoch.
Also da hilft dir natürlich auch so ein Singles-Thread-Environment nicht.
Aber es gibt erstmal keine Newtax und auch keine Semafore.
So, ja. Kann halt auch vom Vorteil sein. Ich sag mal so,
wenn man jetzt das nicht so jemand,
der richtig fit in Jarve ist und der musste sich eben auch mit Nebenlatenläufigkeit auskennen,
da sehe ich also ganz die dünne... Ja,
brauchen wir ja nicht.
Es ist noch schmerzer. Ja. Und wenn man
das Kriterium nicht hat, ist es ja gut.
Wobei das in Java ja eigentlich noch ziemlich gut zur Handhauen ist.
Ja, aber trotzdem ist das gut für die Siege und
die meisten
Das ist auch irgendwie die Hölle, spätestens beim die beiden, die komplexen.
Ja, ja, Szenarien. Die beim Tretenfehler dann hinten, ja.
Genau. Oder beim ersten, bei der ersten Log-Ausgabe,
wie dann das 3-0 nochmal verändert.
Naja, wir sind ein anderes Thema.
Aber so eine Probleme haben wir nicht. Nein. Ja
, ich denke wieder sind wir mit der Zeit durch.
Wir können natürlich noch hinterher in Formell noch ein bisschen quatschen,
aber ich würde erstmal sagen,
vielen Dank für den Vortrag und ja