Symfony Live Warszawa 2019

     Była to moja pierwsza konferencja Symfony Live (ostatnia w Polsce była zorganizowana całe wieki temu bo w 2013) a jestem w sumie nowy w tym środowisku (używam dopiero od paru miesięcy). Co prawda zdawałem sobie sprawę jak duża jest społeczność Symfony (najpopularniejszy frejm w Polsce), ale to co zobaczyłem tak czy inaczej zrobiło na mnie duże wrażenie. Na konferencji zebrało się około 350 uczestników, kilkunastu prelegentów (doskonale znanych w środowisku PHP) oraz oczywiście ekipa SensioLabs z Fabien'em na czele. 

     Poziom jaki prezentowały wszystkie prezentacje był bardzo wysoki. Wiadomo, że dla każdego coś innego i tak dla mnie niektóre prezentacje były czymś w rodzaju "ok teraz sobie posłucham po raz kolejny jak dobre jest x", a inne wysypywały w moim kierunku wiedzę którą zbierałem garściami i nie chciałem uronić żadnego szczegółu. Tak czy inaczej nawet te znane przeze mnie zagadnienia ubrane były w nową formę/inny kontekst co sprawiało, że świetnie się ich słuchało. Naprawdę dobrze!

     Tak jak pisałem - generalnie poziom był bardzo wysoki ale największe wrażenie zrobiły na mnie:

DDD, CQRS, ES, Hexagon... oraz Symfony 
Tomasz Kowalczyk

     Tomasza widziałem już wcześniej na konferencjach, ale do tej pory jego prezentacje (ok, raczej poruszane tematyki) nie robiły na mnie wrażenie. Jednakże pierwszy dzień konferencji sporo zmienił. Sam tytuł jest ok i faktycznie odnosił się do treści, ale nie do końca ujmował to o czym mówił prelegent. W pierwszej części wszyscy zgromadzeni usłyszeli dość radykalne oświadczenie jak na zaistniałe okoliczności zlotu Symfony: Nienawidzę frejmworków*... krótka konsternacja i słowa wyjaśnienia (gwiazdka) dlaczego Symfony jest dla niego wyjątkiem od tego stwierdzenia. Generalnie to stanowiło pierwszą cześć prezentacji. Pozbawione technicznych aspektów, bardziej skupiające się na błędnym (pozbawionym refleksji) podejściu developerów do projektowania i sposobu w jaki wykorzystują dostępne narzędzie. Druga część to wymienione w tytule prezentacji buzzwords'y zastosowane w kontekście Symfony - czyli jak projektować lepiej. 


Krótka historia o tym jak możemy projektować i implementować aplikacje Symfony przy użyciu TDD 
Leszek Prabucki

     Prelegent opowiadał głównie o podejściu TDD do którego używa PHPSpec. Prezentacja bardziej na luzie, Leszek często rzucał ciętymi tekstami przez co publiczność wybuchała śmiechem. Widać, że podczas przemówienia czuje się swobodnie i prowadzi je na swój charakterystyczny sposób. Jak będziecie mieli okazję zobaczyć go na jakiejś konferencji to naprawdę zachęcam do uczestnictwa. Jak sam się przedstawił: Lubię piwo - uwierzcie mi... nadmienię tylko, że też posiada certyfikacje ZCE & Symfony, organizuje PHPers'ów, ponad 10 lat związany z Symfony, prowadzi własną firmę CoCoders. 


Statyczna analiza aplikacji Symfony
Jakub Zalas

     Jakub na co dzień prowadzi własną firmę świadczącą pomoc przy prowadzeniu zewnętrznych projektów. Przedstawił całe tony narzędzi i metodyk z którymi pracuję, pomagające zrozumieć co w danym projekcie stanowi problem i gdzie należy skupić swoją pracę by podnieść jego jakość. Z analizą statyczną nie miałem wcześniej styczności, ale prezentacja pana Zalasa otworzyła mi oczy na pewną sprawę - tworzenie dobrego projektu to nie tylko skupienie się pisaniu kodu, ale też analiza tego co do tej pory zostało napisane. 

Framework agnostic application - will it fit with Symfony? 
Dariusz Drobisz


     Wiele już słyszałem o podejściu Framework Agnostic czy architekturze hexagonalnej. Jednak materiały z którymi się zetknąłem (internet, konferencje) przedstawiały zagadnienia dość teoretycznie nie skupiając się na implementacji nie mówiąc nawet o przykładach w PHP. Dariusz pokazuje jak można to zastosować w Symfony, pokazując strukturę aplikacji, jak czyścić modele, tworzyć repozytoria, czy stosować wzorzec Command. 







Źle używasz Doctrine'a ! 
Tomasz Surowiec

     Jak autor podkreślił na starcie - tytuł miał zaintrygować, trochę podpuścić publiczność i było to clickbait. Generalnie cała prezentacji to same konkrety, przykłady co możesz zrobić lepiej w swoim projekcie by efektywniej wykorzystać Doctrine i napisany kod był przyjemniejszy w utrzymaniu. Dla mnie była to wiedza którą z dnia na dzień można wcielić w życie w projektach komercyjnych.

Podsumowując

Można powiedzieć (pół żartem pół serio) że tematami przewodnimi całej konferencji były:

• Rejestrowanie użytkownika (xD),
• Marco Pivetta nie lubi YAML (xD),
• Dokumentacja Symfony pokazuje tylko jak wykorzystać Symfony i nie jest wyznacznikiem projektowania aplikacji,
• Uniezależnienie się od frejmworka. 

Zend Framework zmienia się w Laminas po pieczą Linux Foundation

ang. Laminas - liczba mnoga od Lamina - w wolnym tłumaczeniu 'bardzo cienka warstwa'. Ma to przedstawiać główną ideę twórców - elementy kompozycyjne bądź warstwy aplikacji (Layered Architecture). 

Historia Zend Framework

Pierwsza stabilna wersja ujrzała światło dzienne w 2007 roku lecz pracę nad nim sięgają roku 2005. Jest to w zasadzie oficjalny framework PHP - mogę tak pisać bo firma z której się wywodzi sprawuje pieczę na PHP. 

Na przestrzeni ostatnich lat jego popularność spadła (413 milionów pobrań i tak robi wrażenie) na rzecz Laravel'a i Symfony. Tak czy inaczej był to pierwszy tak popularny framework PHP'a, w którym pisane były znaczące projekty, a developerzy z całego świata starali się o certyfikację.  

Od samego początku istnienia, pieczę na ZF sprawował Zend Technologies, później Rogue Wave Software - to oni całymi latami przewodzili projektem jak i wykładali na niego pieniądze. Koniec końców wykrystalizował się mały, dodatkowy zespół developerów-pomocników, odgrywający bądź co bądź duży wpływ przy codziennym utrzymaniu ekosystemu i prowadzeniu stron z nowościami dzięki czemu główny zespół mógłby skupić się na tym co najważniejsze. 

Co teraz

Wszystkie projekty z całego ekosystemu Zend (Expressive, Apigility, MVC i inne niezależne komponenty) stają teraz pod szyldem Laminas. Zebrani specjaliści napiszą odpowiednie oprogramowanie do przerzucenia jak dotąd napisanego kodu, zmienią przestrzenie nazw i umożliwią zachowanie kompatybilności wstecznej, dbając o utrzymanie napisanych przy pomocy tych narzędzi aplikacji biznesowych. To czym był do teraz ZF zostanie zarchiwizowane i dalej dostępne na GitHub'ie tylko do odczytu, a wszystkie projekty dostępne na Packagist oznaczone jako Deprecated. Dla developerów pragnących podnieść wersję legacy systemów stojących na ZF wkrótce zostaną udostępnione narzędzia to umożliwiające, dzięki czemu cały proces zostanie zautomatyzowany i przeprowadzony możliwie najmniej boleśnie. 

The Linux Foundation

Jak można przeczytać na oficjalnej stronie, jest to organizacja wspierająca projekty open source zarówno finansowo jak i zapewniając zasoby intelektualne, zaplecze techniczne czy organizacyjne (konferencje, warsztaty itp.). Jak rozkłada się to na realne liczby? 

• ~16 miliardów dolarów przeznaczonych na rozwój stu największych projektów,
• 35 tysięcy specjalistów rok rocznie biorących udział we wszelkiej maści wydarzeniach, 
• 1 milion profesjonalistów partycypujących w projektach pod pieczą fundacji. 

Do licznego grona projektów pod skrzydłami LF należą:

• Jenkins,
• Kubernetes,
• Linux,
• NodeJs,
• JQuery.

Kiedy

Twórcy zakładają że może to być 2-3 kwartał tego roku. Wszystko zależy od zebrania odpowiednich ludzi jak i kwestii technicznych.

Źródła

1. https://www.linuxfoundation.org/
2. https://getlaminas.org/
3. https://framework.zend.com/about

#1 PHP Errors & Exceptions - obiekty i klasy

• PHP 7.3
• bez deklarowania strict_types=1

Klasy i obiekty

FATAL ERROR - Instancjonowanie nieistniejącej klasy
new Example();
// Fatal Error: Uncaught Error: Class 'Example' not found

// -----------------------------------------
class Example {}

FATAL ERROR - Wywołanie nieistniejącej metody (ze statyczną jest tak samo)
(new Example())->doesntExists();
// Fatal Error: Uncaught Error: Call to undefined method Example::doesntExists()


FATAL ERROR - Wywołanie nieistniejącego pola statycznego
Example::$nonExistentProperty;
// Fatal Error: Uncaught Error: Access to undeclared static property: Example::$nonExistentProperty

NOTICE - Wywołanie nieistniejącego pola 
(new Example)->nonExistentProperty;
// Notice: Undefined property: Example::$nonExistentProperty

// trochę inaczej

NOTICE NOTICE - Ciekawy przykład zahaczający o Variable variables
class Example {
public $a = 5;
}
echo (new Example)->$a;
// Notice: Undefined variable: a
// Notice: Undefined property: Example::$

Jak wiadomo pierwszy Notice nie przerywa wykonywania kodu więc jak interpreter próbuje wywołać zmienną nic to okazuje się że nie ma pola nic klasy Example 

// -----------------------------------------

FATAL ERROR - Wywołanie pola prywatnego (z protected tak samo)
class Example { private $a = 5; }
(new Example)->a;
// Fatal Error: Uncaught Error: Cannot access private property Example::$a

FATAL ERROR - Wywołanie funkcji prywatnej (z protected tak samo)
class Example { private function foo() {} }
(new Example)->foo();
// Fatal Error: Uncaught Error: Call to private method Example::foo() from context

// -------- PHP 4 style constructor --------

class Example {
  public $a = 1;
function Example($a) {
$this->a = $a;
}
}

echo (new Example(2))->a; // 2


Powyższe wywołanie w PHP wersji 7.x powinno zwrócić E_DEPRECATED (jeżeli w klasie nie jest zadeklarowany __construct()) - ale co mnie dziwi - w przypadku moich testów, stary styl konstruktora klasy po prostu zadziałał bezbłędnie. Takiego komunikatu się spodziewałem: 

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; Example has a deprecated constructor

Więcej na:

https://www.php.net/manual/en/migration70.deprecated.php

// -----------------------------------------
DEPRECATED FATAL ERROR - Wywołanie metody z $this w statyczny sposób
class Example {
public $a = 1;
function foo() {
echo $this->a;
}
}
Example::foo();
// Deprecated: Non-static method Example::foo() should not be called statically 
// Fatal Error: Uncaught Error: Using $this when not in object context

// -----------------------------------------
FATAL ERROR - Wywołanie nieistniejącej stałej klasy
class Example {}
echo Example::NON_EXISTEN_CONST;
// Fatal Error: Uncaught Error: Undefined class constant 'NON_EXISTEN_CONST'
// -----------------------------------------
RECOVERABLE ERROR - Kastowanie obiektu na string gdy jego klasa nie ma zaimplementowanej metody magiczne __toString()
class Example {}
$recoverable = new Example();
echo (string)$recoverable;
// Recoverable fatal error: Object of class Example could not be converted to string

RECOVERABLE ERROR - Kastowanie obiektu na string (poprzez wyświetlenie go konstruktem echo) gdy jego klasa ma zaimplementowaną metodę magiczną __toString() zwracającą integer
class Example {
public function __toString() {
return 1;
}
}
$recoverable = new Example();
echo $recoverable;
// Recoverable fatal error: Method Example::__toString() must return a string value

• E_RECOVERABLE_ERROR (4094) (od wersji 5.2) - Fatal Error do przechwycenia. Określa prawdopodobnie groźną sytuację, ale nie pozostawia silnika PHP w niestabilnym stanie. Jeżeli programista nie napisał własnego handlera do obsługi błędu (set_error_handler()) to program przerwie wykonywanie jak w przypadku E_ERROR. Warto nadmienić że w PHP 5.x powodowało to z mety zatrzymanie skryptu, od wersji 7.0 się to jednak zmieniło.

// słowo kluczowe final... i nie tylko -----
FATAL ERROR - Dziedziczenie po klasie finalnej gdzie istotny czynnik odgrywa fakt, że klasa rodzica korzysta z nazwy zarezerwowanej (tak samo ze słowem kluczowym self)
final class Parent {}
class Child extends Parent {}
Fatal error: Cannot use 'Parent' as class name as it is reserved
Generuje błąd nie do przechwycenia. 

FATAL ERROR - Wywołanie nieistniejącej stałej klasy
final class Parent1 {}
class Child extends Parent1 {}
// Fatal error: Class Child may not inherit from final class (Parent1)
Generuje błąd nie do przechwycenia.