Nadal zbieram się, aby podzielić się z Wami wrażeniami po PHP Srbija 2018, ale ciężko mi to zrobić bez zdjęć. A zdjęcia ciągle są nieprzejrzane i koło się zamyka. Ale…

W poniedziałek byłem na powakacyjnym PHPers Trójmiasto w C200 Office. Jeśli dobrze sięgam pamięcią ostatni raz byłem w 2014 roku (!), kiedy spotkania odbywały się jeszcze w PPNT. W tamtym czasie lokalne PHPersy dopiero startowały (obok Warszawy pojawiło się Trójmiasto oraz Śląsk). Nie wiem skąd wynikła przerwa, może brak systematyczności spotkań i lokalizacja źle skomunikowana.

Czemu wybrałem się tym razem? Dobre pytanie. Może brakuje mi PHPCon Poland i szukam czegoś w zastępstwie w Polsce. Do Pragi na PHP CE się nie wybieram – dla mnie będzie to zupełnie inna konferencja, poza tym grafik spotkań zagranicznych i tak jest już napięty. W tym roku nie było również Zimowiska Linuksowego. I tak trochę PHPers Trójmiasto potraktowałem jako mały event z ograniczoną ilością uczestników. Powiem Wam: było warto!

testy jednostkowe

Poniedziałkowe spotkanie związane było z testami jednostkowymi (w oparciu o phpSpec i phpUnit) oraz podsumowaniem zmian jakie zaszły w Symfony 4, oraz czym tak naprawdę jest Flex.

Ci z Was, którzy byli tam wraz ze mną, wiedzą najlepiej, że ciężko napisać coś o prelekcji i kodowaniu na żywo Leszka Prabuckiego. Nie chodzi o to, że było źle. Leszek bardzo fajnie i szybko pokazał nam jak może wyglądać zwyczajny dzień pracy programisty, gdy dostajemy od Klienta np. zlecenie wykonania rejestracji do systemu. Od spotkania z Klientem, event stormingu itp., poprzez napisanie pierwszych testów (phpSpec), refactoringu, stworzeniu domeny (zalążek DDD) i skupieniu się na tym co chce Użytkownik zrobić, a nie jak. To było po prostu specyficzne doświadczenie.

PHPUnit Good Practices

Natomiast Dariusz Rumiński, który pracuje w Delivery Hero (PizzaPortal), rozwinął myśl Leszka z naciskiem na same testy jednostkowe oraz jak to zrobić dobrze w oparciu o phpUnit. Darek pracuje z phpUnit od wersji 3.3 (2008). Przez lata phpUnit się zmieniał, przechodził metamorfozy, jedne funkcje się pojawiały, a inne niestety znikały. Obecnie phpUnit posiada pewną warstwę abstrakcji, tzn. kompatybilności, ale nie daje ona nam wszystkiego i musimy o tym pamiętać aktualizując phpUnit już w istniejącym projekcie z istniejącymi testami. Oferuje również ponad 100 gotowych porównań (assertions).

Nieraz zdarza się, że nasze testy nie mogą obejść się bez atrap (mocks). Obecnie phpUnit pozwala w różny sposób tworzyć atrapy. Od starodawnego MockObject, poprzez Mockery, kończąc na współczesnym i zalecanym Prophecy, który już nie jest powiązany ze strukturą. I najważniejsze o czym trzeba pamiętać – pisać testowalny kod.

Symfony 4 i Flex

Tematem zamykającym spotkanie był Symfony 4 i Flex. Jakub Zalas niesamowicie poprowadził swoją prelekcję (pomijając fakt wspomnienia jego największego osiągnięcia). Jakub pokazał czym tak naprawdę jest Symfony 4, czyli Symfony 3.4, które de facto jest odchudzoną i zmienioną wersją Symfony 3.3, a te wersji 3.2 itd. Ale taki był zamysł twórców Symfony 2, że kolejne wydania będą często, ale nie będą przynosiły rewolucji (jak Sf2).

W dużym skrócie, jakie zmiany przynosi Sf4? Ulepszona struktura projektu. Nie ma już folderu na aplikacje (/app), a aby dostosować się do całego środowiska PHP zmieniono chociażby /web na /public. Dodatkowo pojawia się .env ze zmiennymi konfiguracyjnymi, które powinno być używane dla środowisk developerskich. Natomiast w konfiguracji nie ma już głównego pliku konfiguracyjnego. Każdy pakiet może mieć swojego yml. Pojawia się również bundles.php do konfiguracji jakich bundle’i chcemy używać w projekcie (wszystkie te informacji dzieją się obecnie automatycznie dzięki autowire i Flex). Flex przynosi również aliasy dla composera (np req templates zainstaluje twig). Core Team wybrał aliasy dla najbardziej zalecanych paczek.

A najważniejsza zmiana, jak dla mnie? Symfony 4 na dysku zajmuje 14MB (Sf3.4 ~ 58MB), tym samym spadła ilość plików do 2.5k (Sf3.4 8.9k). Co przyspiesza działanie aplikacji, ale bez wspomnianego opcache i tak się nie obędzie.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

W lutym świtało dzienne ujrzała pierwsza oficjalna wersja aplikacji demo dla frameworka Symfony. Aplikacja demo istniała już wcześniej i była bardzo ciekawym żródłem z przykładami wykorzystania podstawowych możliwości Symfony – przede wszystkim dla osób nie znających tego frameworka – sam niejednokrotnie polecałem ją na szkoleniach dla początkujących z Symfony. W tym momencie demo ewoluowało, zostało dostosowane do nowości, które pojawiły się zarówno w ostatnich wersjach frameworkach oraz PHP i jest aktywnie rozwijane.

Aby wygenerować aplikację „demo” wystarczy z wiersza poleceń wprowadzić polecenie:

# using Symfony installer
symfony demo

wykorzystując do tego instalator Symfony, który możecie znaleźć tutaj.

Następnie należy załadować dane testowe by móc w pełni korzystać z aplikacji demo. I to wszystko – nie ma potrzeby wywyoływania dedykowanych komend dla danych testowych: zostały odpowiednio przygotowane podczas instalacji projektu demo.

Aplikacja posiada wszystkie podstawowe funkcjonalności jakie możemy znaleźć na blogu wraz z kodem zródłowym i obszernymi komentarzami:

• możliwości przeglądania artyułów wraz ze stronicowaniem;
• możliwość dodawania, edycji i usuwania artykułów z poziomu panelu administratora – dane dostępowe dostępne są po kliknięciu w link: „Przeglądaj panel administracyjny”;
• możliwość dodawania komentarzy do artykułów – wymagane odpowiednie uprawnienia użytkownika;
• formularz logowania i poziomy uprawnień użytkowników – dostęp do panelu admina wymaga wyższych uprawnień niż dostęp do częsci publicznej;
• wielojęzyczność aplikacji;
• RSS feed;

Dodatkowo aplikacja demo pokazuje w jaki sposób korzystać z zewnętrznych bundli (PagerFanta dla stronicowania), w jaki sposób definiować własne typy pól formularza (DatePicker, tagowanie artykułów), jak zarządzać uprawnieniami użytkowników czy też jak prawidłowo definiować realcji pomiędzy encjami w Doctrine2. Kod aplikacji demo znajduje się na GitHubie, gdzie można wysyłać propozycje nowych / brakujących funkcjonalności czy też zgłaszać błędy.

Artykuł Symfony: aplikacja demo pochodzi z serwisu Notatki Programisty.

W końcu Fabien Potencier i spółka podbili numer wersji popularnego frameworka PHP i od 30 listopada możemy oficjalnie cieszyć się z Symfony 3. TLDR: poważniejszych zmian nie stwierdzono, jest to bardziej zmiana z 2.7 -> 2.8, niż poprzedni przeskok 1.4 -> 2.0.

Artykuł Symfony 3.0.0 pochodzi z serwisu Mateusz matipl Kamiński.

W tym roku udało mi się wybrać na konfernecję Symfony Live London 2015, która odbyła się 18 września (+ warsztaty dzień wcześniej) dzięki przychylności losu… Całe spotkanie odbywało się w Queen Elizabeth II Conference Centre, czyli w samym centrum Londynu. Pod nosem metro (Westminster), jak i moc atrakcji turystycznych (Big Ben, London Eye, pałac w Westminter itd.). Mocno na plus, szczególnie, że cena dla Anglików nie była wygórowana (£210.00).

Lasery i algorytmy

Prelekcją otwierającą była „Getting artistic with code”, którą zaprezentował Seb Lee-Delisle. Prezentacja była zupełnie inna niż wszystkie, do których się przyzwyczaiłem na konferencjach technicznych. Na początku zapowiadał się niesamowity gniot, po tym jak Seb pokazał kawałek JavaScript’u z OnMouseOver – od razu pomyślałem, sobie że to przecież kod sprzed 15 lat… Ale Seb chciał pokazać w jaki sposób można tworzyć sztukę, być Artystą używając do tego czystego języku (JavaScript) i zmyślnych algorytmów. Można tworzyć – bawiąc się. Ostateczny efekt był piorunujący i uważam, że każda konferencja powinna rozpoczynać się podobnym wystąpieniem – niby nie związany z tematem, a jednak… Seb Lee-Delisle specjalizuje się obecnie w pokazach laserowych. Poniżej jego algorytmy podczas Smashing Conference w 2014 roku – połączenie algorytmów i laserów:

Później już było konkretnie. Podczas prelekcji „Building a Pyramid: Symfony Testing Strategies” Ciaran McNulty za pomocą piramidy potrzeb Maslowa zaprezentował jak ważne są testy jednostkowe, a dopiero później znaczące są testy integracje i UI. Mam nadzieję, że niedługo pojawią się nagrania z konferencji.

Doctrine 2

Dużym zaskoczeniem były natomiast słowa Benjamina Eberlei podczas „Doctrine 2: To Use Or Not To Use”. Powiedział, że Doctrine jest tworzony zgodnie z zasadą Pareto (80/20), czyli dla 80% przypadków użycia. W ramach tych 80% przypadków Benjamin wymienił CRUD, Symphony Validator + Forms, natywny SQL i dla tych zastosowań Doctrine to wręcz idealne rozwiązanie. Niestety Doctrine nadal nie radzi sobie z dużą ilością zapisów, ma problemy z wydajnością i złożonymi zapytaniami (raporty itp.). Jak również powinniśmy unikać ORM dla batching processing.

Jak również przypomniał, że wywołanie flush() niszczy wiązania w entity / $query->iterate(), przez to powoduje spore obciążenia serwera gdy robimy flushowanie w pętlach etc. Dlatego pamiętajmy, aby wykonywać tą operację tylko po zakończeniu wszystkich operacji.

Pamiętajmy również, że kompleksowe zapytania DQL z duża ilością wiązań (JOINs) są bardzo wolne i należy ich unikać. W takich wypadkach lepiej zrobić dedykowany model View/Read, który operuje tylko na wybranych polach ze wszystkich JOINs.

Very Good: CRUD (& Symphony Validator + Forms) Good: DDD Lite with coupling to Doctrine/DB Okies: DDD (decoupling requires works) Bad: high write throughput

Summary 80%: CRUD, Lazy, Native SQL Risk: Performance Problems, Unsolvable Edge Class, High Coupling, Complexity

Symfony 3.0

Prelekcję końcową wygłosił Fabien Potencier. Po auto-reklamie produktów Blackfire.io, przedstawił małe podsumowanie prac nad Symfony 3.0 (praktycznie to 2.8, która zostanie podbita do 3.0). Fabien podkreślił, że coraz więcej projektów tworzonych jest na komponentach Symfony i to bardzo go cieszy. Niedługo zobaczymy oparte na Symfony:

• Drupal 8
• phpBB
• prestaShop

Wspomniał również, że obiecanie kompatybilności wstecznej w całej linii Symfony 2.x było wielką pomyłką jego i zespołu. Dużo prac ich to kosztowało przez co nie mogli iść do przodu z nowościami. W wersji 3.0 również było sporo takich problemów, dlatego teraz będzie fixowanie w x.y.(z+1), a nie jak wcześniej w x.y .

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

It passed about half year since I scratched Symfony2 Framework surface. Basics are behind me, now it’s time for middle-level stuff. I’m excited to start a whole new Symfony related blog post series. I didn’t wanted to copy typical tutorial topics. It would be waste of your time and my work. I thought it would be nice to show some code related to Symfony Dependency Injection Container.

Tutorials usually show typical container services definition. Boring stuff. I’m going to show you dynamic collection of services passed into processor service. The idea is that collection doesn’t know its elements, so every bundle can define its own services to be added to collection. The secret is tags. To add some spice, tagged service can be defined with priority. And we can specify that this processor should be run at the beginning, and that at the end.

We’ll start with defining common processor interface and some basic implementations.

Now it’s time for a service that processes given argument with all the processors one by one.

We could define typical container definitions and pass processors right into processing service, but remember about requirement that external bundles can define their own processors. We’ll use tags.

Now the key part: compiler pass definition.

Usage:

At the first sight you may think that it’s a lot of logic to run to define stupid processor. What about performance? No worries. Remember, the compilation outcome is dumped into cache file on prod environment. All these foreach loops and priority queues are being run only once. Solution is pretty generic, you can easily adapt to your own needs. Of course code is on MIT license, so grab it and use in your own (even commercial) projects!

Happy PHP container compiling :-)

Continuous deployment environment with Docker, AWS EB and Codeship In the last two episodes we have configured the Docker environment and automated deployment with Elastic Beanstalk, but still the process requires some manual actions and I personally would like to avoid any unnecessary interference in the process. So, today I will walk you through combining […]

The post Putting all pieces together and shipping with Codeship (part III) appeared first on Piotr Pasich.

Continuous deployment environment with Docker, AWS EB and Codeship In the previous part we set up a dedicated Symfony application on Docker virtual containers and prepared environments that may be transferred between developers during project cycle. The next step is to prepare the application for pushing into the cloud. There are many options available on […]

The post Automated deployment with AWS Elastic Beanstalk (EB) – Part II appeared first on Piotr Pasich.