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).
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.
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
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:
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 .
Kanał ATOM
