Die nächsten Wochen und Monate werden sehr stressig. Meine Pläne sind:
- Umziehen und Renovieren (vielleicht mit Blog-Post über Netzwerk, Server und Überwachungskameras)
- Ein einfaches Shopware Plugin in den Community Store zu bekommen (Das Plugin ist so gut wie fertig.. jetzt kommt die Upload-Theorie* .. schlimmer als der App-Store für Firefox OS kann es sicher nicht sein)
- Einen kleinen aber etwas speziellen Shop online bringen (ich werde berichtigen wie es läuft und ob es am Ende erfolgreich war)
- Zwei Termine mit dem Switch GmbH Time-System stehen an, wo ich auch Blog-Post und so liefern werde.. mehr als letztes Jahr
- Ein Video über die manuelle Zeitmessung mit dem Time-System
- Und nach dem Umbau der letzten 3 Monate am aoop PHP-Framework mit MVC, neuer Verzeichnisstruktur, PHP 7, Namespaces, Composer-Autoloader, etc müsste ich wirklich mal eine neue Version releasen.. ich bin doch relativ stolz auf die neue Version ,weil sie doch etwas ist was man als modern bezeichnen kann
Zum 10. Geburtstag meines PHP-Frameworks wird sich da viel ändern und es damit dann wieder etwas mehr zu anderen Frameworks aufschließen können.
Mein eigener Class-Loader fliegt raus und es wird noch der ClassLoader vom Composer verwendet. Meiner kann zwar auch mit PSR4 umgehen, aber nach dem Umstieg muss ich dann auch alles darauf umstellen und habe keine Ausrede mehr, weil die Kompatibilität weg fällt.
Es gibt nun ein public-Verzeichnis so dass alle Config-Dateien und Classes außerhalb des Bereiches liegen, auf dem Benutzer zugreifen können. Das sorgt für mehr Sicherheit, macht das Laden von CSS und Bildern aus dem Theme-Verzeichnis aber komplizierter. Ich überlege hier auf Assetic umzusteigen. Momentan läuft meine Lösung aber sehr gut.
Und das Beste und wichtigste was aber auch am meisten Arbeit machen wird (darum habe ich ganz viele alte Module erst einmal gelöscht und lasse auch die alten PHP-Pages drin) ist, dass Module-Pages nun wirklich mit Controller und Twig-Template gerendert werden. Die Twig-Templates könenn vom Theme und von eigenes Templates in der Instance überschrieben werden und so kann man nun endlich das Aussehen der Module leicht und schnell anpassen.
Smarty war schon länger drin, wurde aber nie benutzt und ist jetzt raus geflogen.
Mein erstes Projekt damit wird sein, die Zeiterfassung für Kunden-Projekte neu zu schreiben und für alle brauchbar zu machen. Das wird wohl am Ende nur 1-2 Tage dauern. Also nichts im Vergleich zum Umbau des Frameworks.
PHP kann ja Zahlen, die als String vorliegen, direkt als Zahl casten. Was sich erst einmal ganz praktisch anhört ist leider sehr seltsam umgesetzt, da nie validiert wurde, ob der String im Ganzen eine gültige Zahlennotation enthält.
$a = "05" + "10dings";
Der Ausdruck liefert 15 zurück. Jeder aus Java Integer.parseInt() kennt, wird es bei so einem Umgang nur kalte Scheuer über den Rücken jagen.
Einige halten dieses Verhalten zwar für vollkommen korrekt und besonders praktisch, weil einem so der Benutzer durch unsinnige Eingaben die Berechnung nicht kaputt machen kann... aber wenn man mal ehrlich ist, ist "5 stück" + "0.5 eier" + "draussen dunkel" = int(5.5) nicht wirklich ein brauchbares Ergebnis.
Ja da kommt wirklich 5.5 raus.
Aber zum Glück gibt es jetzt mit 7.1 wenigstens eine kleiner Verbesserung. Es wird eine Warnung geworfen.
Number operators taking numeric strings now emit E_NOTICEs or E_WARNINGs when given malformed numeric strings.
Damit ist man schon mal soweit, dass man seinen Code sicher machen kann, wenn man möchte. Man muss es leider nicht, aber dass man es kann ist schon mal ein Fortschritt.
Beim Umstieg von einer alten PHP Version auf PHP7.0 werden viele sicher gleich sich daran machen auch den ganzen Rest mal auf eine aktuelle Version zu migrieren. Dazu gehört dann oft auch eine aktuelle MySQL-Version.
Aber manchmal laufen dann ältere Queries nicht mehr. Das Beste ich dann natürlich das Query anzupassen. Wenn man aber nicht so viel Zeit hat oder sich erst später mit den Problem beschäftigen möchte, hilft es oft die problematischen neuen Modes zu deaktivieren.
Besipiel wäre hier der ONLY_FULL_GROUP_BY-Mode
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
Bei PDO kann man das Stament direkt als PDO::MYSQL_ATTR_INIT_COMMAND setzen, so dass es bei jeder neuen Verbindung gleich gesetzt wird.
Das Verhalten von Sessions haben sich in PHP7 etwas geändert. Jedenfalls hatte ich das Problem jetzt schon mehrfach, wobei es lokal mit einer älteren 7.0.0 noch nicht auftrat. Mit einer 7.0.7 und einer 7.1 trat es dagegen immer auf.
Es kommt ja vor, dass man während session_start() z.B. durch einen eigenen Class-Loader schon versucht auf Daten aus der Session zu zugreifen. Hier wird man schnell merken, dass zwar die Einträge in der Session schon sichtbar sind, aber alle vom Typ UNKOWN sind. Ein Array oder Boolean aus der Session zu lesen, funktioniert
also noch nicht.
Bei meinem ClassLoader habe ich es einfach so gemacht, dass er nicht die schon gespeicherten Pfade aus der Session verwendet, solange die Session nicht komplett rekonstruiert wurde (unserialized). Sobald die Session wieder da ist, kann ich wieder auf die schon hinterlegten Einträge zugreifen und muss nicht mehr im Dateisystem meine Klassen suchen, sondern habe wieder mein Array mit Klassen/Pfad Zuordnungen.
Gerade in der letzten Zeit mit PHP7 hat sich wieder einiges in der PHP-Welt getan und einiges hat damit einen großen Schritt nach vorne gemacht. Betroffen davon sind z.B. die Bereiche der PHP-Arrays (was im GRunde ja eigentlich HashMaps sind) und der Objekte. Es gibt ein paar wirklich gute und Ausführliche Artikel zu den Themen, die sich mit den Grundlagen beschäftigen. Dies sind keine Grundlagen für Anfänger sondern gehen wirklich in die Tiefe und man sollte beim Lesen auch keine Angst vor etwas C-Code haben.
Besonders der Bereich mit den Packed Hashmaps ist sehr interessant, weil dort erklärt wird, wie man ein fast echtes Array in PHP bekommt, das ohne Translation-Table und die Erzeugung von Hashes auskommt sondern wird einfach 0-n als Index verwendet und dies direkt auf ein entsprechendes C-Array umsetzt. Das spart etwas Speicher, aber auch sehr viel CPU-Zeit und bringt mehr Performance. Bevor man also als Index irgendwelche Ids oder so verwendet sollte man noch mal überlegen, ob man das wirklich benötigt oder ein einfaches und schnelles Array doch von Vorteil wäre.
Unter Ubuntu < 16.04 PHP 7.0 zu installieren ist gar nicht schwer, wenn man erst einmal weiß, wie es geht. Man muss sich ein zusätzliches PPA einrichten und sonst nicht viel machen.
Damit ist PHP 7.0 an sich schon installiert. Das kann man sehen wenn die Version überprüft (immer die zuletzt installierte Version wird hier verwendet)
php -v
Wenn man nun eine Liste an Modulen haben will bekommt man diese so:
sudo apt-cache search php7-*
Wichtig ist, dass XDebug weiterhin unter php-xdebug zu finden ist und deswegen hier nicht in der Liste auftaucht. Also alles aus der Liste installieren was man braucht.
Das man in einer PHP-Seite mal in eine Exception läuft ist ja nicht schlimm, nervig ist nur, wenn man merkt, dass diese Exception wiederum aus einen catch-Block stammt und man erst einmal Debuggen muss, um an die original Exception zukommen und den wirklichen Fehler zu sehen.
try{
$a = 1* array(2,3);
}
catch(Exception $e){
throw new Exception("something went wrong");
}
Man sollte immer, wenn es mögich ist, die original Exception mit an die eigene Exception ran hängen.
try{
$a = 1* array(2,3);
}
catch(Exception $e){
throw new Exception("something went wrong", 0, $e);
}
Ich weiß, dass der TIOBE-Index nicht immer wirklich aussagekräftig ist, aber er zeigt doch immer ganz gut Tendenzen an. Dieses Jahr ist Java eindeutig der Sieger. 6% Zuwachs im Vergleich zum Vorjahr sind schon sehr viel. Aber das führt mich wieder zu einem anderen Thema und einer Behauptung von mir. "Durch den Verlust der Desktop-GUIs wird Java keinen Schaden nehmen".
In der Zeit wo Java 6% zulegte, verlor Java auch viele Anteile im Bereich der Desktop-Anwendungen basierend auf Swing und JavaFX. Ich würde damit ist widerlegt, dass ohne den Desktopbereich, Java und die JEE-Welt Schaden nehmen würde.
Wenn man dieses Diagramm mit dem aus diesem Post über JavaFX vergleicht, sieht man dass Swing und JavaFX insgesamt einen ähnlichen Verlauf nahmen wie Java nur den letzten Aufschwung nicht mitgemacht haben. Die Stärken und Neuentwicklungen von Java liegen also wo anders und reichen insgesamt aus um Java insgesamt zu Pushen und die Verluste im Desktop-Bereich mehr als auszugleichen.
Java hat und hatte schon immer seine Stärken auf der Server-Seite und da ist wohl auch noch genug Luft nach oben. Konkurrenz gibt es mit PHP und Node.js genug und es wird wirklich spannend, ob PHP mit PHP7 wieder mal etwas zulegen kann. Von der Performance her lag Java schon immer weit vor PHP, aber jetzt sollte PHP etwas aufholen können. Es wird spannend.. auch wenn PHP sicher etwas Zeit benötigt. In der PHP-Welt werden Neuerungen irgendwie immer sehr skeptisch aufgenommen. Die Migration auf PHP7 ist meistens sehr einfach und schnell. Java lebt momentan von Microservices, Reactive-Programming und bietet auch Event-Driven Frameworks wie Vert.x als Konkurrenz zu Node.js.
Ich bin mir unsicher, ob PHP da mithalten kann. WebSockets und Server-Sent Events sind im Tomcat 8 von Haus aus dabei, während man bei PHP da noch mehr basteln muss.
heute habe ich meinen ersten Test mit PHP 7 durch geführt. 1&1 ist so nett und bietet für jeden schon an PHP 7.0RC3 einzustellen. Ich hab mir eine Subdomain angelegt und diese auf PHP 7 konfiguriert. Ich wollte mal sehen, ob mein System mit PHP 7 läuft oder ich noch etwas ändern muss. Bis jetzt lief meine Homepage produktiv mit PHP 5.5 und wurde mit 5.6 entwickelt. Bei PHP7 fallen ein paar Altlasten weg, die man eigentlich schon vor Jahren hätte mal anpassen sollen. Das hatte ich vor paar Wochen gemacht:
Die alten Konstruktoren durch __construct() ersetzen. Ich weiß nicht warum die alten nicht mehr untersützt werden sollen in Java funktioniert die Art und Weise super und auch mit PHP hatte ich keine Probleme.. ist aber eben jetzt anders
Die alten msyql-Function sind nun nicht mehr dabei. Aber dafür gibt es noch die mysqli-Funktionen (auch in Form von Klassen für OOP). Da alles in einer Klasse gekapselt war, bedeutete das nur die Klasse zu kopieren und an jedes "mysql" ein "i" ran zuhängen. Also in 2 Minuten erledigt. Selbst ein automatisches Replace über alle Dateien hätte funktioniert.
Mehr hatte ich nicht geändert und es lief unter 5.6 alles sehr schnell und stabil. Dann folgte der Test auf PHP 7.. und es lauft. Gefühlt ist es immer noch stabil und schnell. Performance-Messungen habe ich noch nicht gemacht, aber werde in den nächsten 1-2 Wochen wohl mal welche nachreichen.
Fazit Ich glaube es wird kaum bis wenige Probleme beim Wechsel geben, wenn der Code strukturiert ist und nicht seit 10 Jahren nicht mehr angefasst wurde. Das "Problem" mit den mysql-Funktionen klingt schlimmer als es ist bei alten Legacy-Code wo die DB-Queries wild im Sourcecode verteilt sind. Ein Replace und es ist erledigt, das Schlimmste was passieren kann ist das man ein paar Kommentare mit umbenennt. Also keine Angst haben und einfach mal ausprobieren.
Was haben PHP und Java gemeinsam? Deren unterste Schicht der VM/Engine ist in C geschrieben. Aber was interessiert die VM oder Engine? Irgendwann kommt man an den Punkt wo man Performance-Probleme hat und dann muss man verstehen warum etwas Langsam ist. Die Frage dann sollte auch nicht lauten: "Wie bekomme ich die Anwendung schnell?" Sondern eher: "Wie habe ich sie langsam bekommen?" Denn erstmal muss man die Gründe kennen, um dann Lösungen zu finden. Lösungen sind nicht immer so einfach zu finden, weil manche Dinge sind einfach langsam und manchmal muss man sein ganzes Vorgehen ändern. Assoc-Arrays sind toll, aber es sind eigentlich keine Array sondern Hash-Maps und die sind nun mal nicht ganz so performant.
Aber warum das so ist und warum die in PHP7 viel besser implementiert sind, erschließt sich aber nicht einfach so, wenn man nicht weiß, wie die Engine arbeitet. Auch einen Garbage-Collector gibt es in PHP, der genau wie in Java zu 98% super läuft. Aber wenn er Probleme macht, muss man wissen wie er arbeitet um ansatzweise überhaupt das Problem zu verstehen. Zirkel bei Referenzen sind ein großes Problem, wenn er die Objekte zum freigeben markieren will. Reference-Count gibt es auch dort.
Jedem der sich auch für die Interna der Zend Engine 5.x und 7 interessiert und sich etwas über Performance informieren möchte kann ich diese Artikel empfehlen:
Der erste Release Candidate von PHP 7 ist verfügbar und der auch von HHVM gibt es eine neue Version. Ich würde mir beides gerne mal ansehen. Aber ich habe nicht die Zeit mir alles komplet einzurichten und mir noch extra ein Linux zu installieren. Ich benutze Windows und werde auch erstmal dabei bleiben. Also fällt leider HHVM schon mal für einen kurzen Test raus. Aber PHP7 ist für Windows verfügbar und auch Bitnami bietet schon ein WAMP-Paket mit PHP7 an. Also werde ich mir das in den nächsten Tagen mal ansehen. Einmal kurz gucken, ob aoop darauf funktioniert oder nicht. Ich bin mal gespannt.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
