PHPCon Poland 2022
28 - 30 Oct 2022 at Villa Verde Congress & Spa Hotel

Zdarza Ci się, że kod, z którym przyszło Ci pracować, jest trudny do zrozumienia a zmiany, które chcesz w nim wprowadzić wcale nie poprawiają jego stanu? Słyszałeś o refaktoryzacji ale po zastosowaniu podstawowych technik czujesz, że utknąłeś, a osiągnięty cel jest daleki od tego, o czym początkowo myślałeś? Z pomocą przychodzą wzorce projektowe. Podczas warsztatu poznamy wybrane wzorce i ich zastosowanie a także zastanowimy się nad ich wadami. Wiedzę wykorzystamy w praktyce podczas ćwiczeń. Wymagania: - podstawowe doświadczenie w pisaniu obiektowego kodu PHP – warsztat jest przeznaczony dla osób początkujących lub chcących usystematyzować swoją wiedzę, - laptop NIE JEST wymagany – warsztat odbędzie się w formule mob programmingu gdzie uczestnicy na zmianę będą implementować wzorce projektowe na laptopie zapewnionym przez prowadzącego, - kod powstały podczas warsztatów zostanie opublikowany na platformie GitHub, - celem warsztatu jest zaznajomienie uczestników w szczególności z wzorcami strukturalnymi i behawioralnymi. Wzorce kreacyjne nie są priorytetem warsztatu i będą poruszane w dalszej kolejności. Jeśli ktoś zdecyduje się mimo wszystko na zabranie własnego laptopa, powinien mieć skonfigurowane środowisko z PHP 7.4 lub nowszym na swoim ulubionym systemie operacyjnym.

Wchodząc w świat Domain-Driven Design trudno nie otrzeć się o koncept Aggregate. Ten, dobrze zastosowany wzorzec taktycznego DDD pozwala bezpiecznie przeprowadzać złożone modyfikacje danych w systemie, tworząc go kuloodpornym właśnie w zakresie spójności i poprawności danych. W trakcie warsztatu przejdziemy proces analizy, modelowania i implementacji agregatów o różnych poziomach złożoności. Zapoznamy się także z zasadami, dobrymi jak i złymi praktykami modelarskimi, możliwymi sposobami persystencji agregatów w bazie danych oraz sytuacjami, kiedy wzorzec ten przyniesie więcej problemów niż korzyści.

„If it hurts do it more often” – mówi jedno z powiedzeń i podejść do budowy oprogramowania. W praktyce oznacza to m.in. automatyzację monotonnych czynności naszej pracy. O automatyzacji najczęściej mówi się w kontekście budowy infrastruktury, a Terraform jest świetnym narzędziem do osiągania tej automatyzacji. Pozwala m.in.: - Zapisać cały proces budowy infrastruktury jako kod - dzięki temu infrastruktura jest dostępna dla każdego na żądanie, - Stworzyć pełne środowisko testowe (kopię produkcji) w kilka minut bez czekania na tzw. ticket u administratora i bez zastanawiania się co dzieje się „pod spodem”, - Przetestować aplikację na infrastrukturze z nową wersją PHP czy innego dependency jak np. baza danych, paczka/biblioteka itd., - Stworzyć w kilka minut ogromną infrastrukturę składającą się z nawet tysięcy instancji (serwerów) – ograniczeniem jest jedynie karta kredytowa. Terraform jest ponadto narzędziem bardzo prostym i szybkim do przyswojenia! W trakcie warsztatów: - Zakodujemy w Terraform na infrastrukturze chmurowej kompletne środowisko aplikacji PHP, - Infrastrukturę zbudujemy w podejściu polycloud tzn. w oparciu o kilku dostawców (m.in. AWS ale nie tylko), - Poznamy też zasady budowy dobrej infrastruktury “as code”, które stosuje się bez względu na dostawcę usług czy wykorzystywane narzędzia. Zajęcia będą prowadzone w formie mob programmingu z rotacją programującego co 1-2 minuty – zagwarantuje nam to równe i pełne zaangażowanie każdego uczestnika podczas całych warsztatów. UWAGA! Od uczestników wymagana jest podstawowa znajomość narzędzi Docker oraz Docker Compose: - Umiejętność samodzielnego „zdockeryzowania” aplikacji PHP, korzystającej z bazy danych, i wymagającej do uruchomienia konfiguracji np. w postaci zmiennych środowiskowych (a przynajmniej umiejętność korzystania z takiego zdockeryzowania). - Innymi słowy podstawową znajomość volumes, przekazywania do kontenerów zmiennych środowiskowych, znajomość komend docker-compose up, down, stop, docker run, exec, pull, push, ps, logs. - Mile widziana jest również umiejętność budowania obrazów w tym mechanizm entrypoint czy cmd, a także umiejętność konfiguracji usług Docker Compose (plik yml). Dzięki temu będziemy mogli skupić się tylko i wyłącznie na samym narzędziu Terraform oraz niuansach usług AWS. Uczestników prosimy o zabranie na warsztaty laptopa z zainstalowanym systemem Linux (idealnie Ubuntu/Debian) bądź macOS. System Windows jest również akceptowalny, jednak w ostatniej kolejności.

Wykorzystaj Rabbitmq do pracy w systemie z wieloma nadawcami i odbiorcami. Z warsztatu dowiesz się jak stworzyć i skonfigurować Exchange, VHosty z użytkownikami do przetwarzania danych.

Jak zbudować nowoczesne środowisko deweloperskie? Z jakich technologii skorzystać aby efektywnie i w prosty sposób pracować nad swoimi projektami lokalnie a jednocześnie móc w elastyczny sposób dostarczać produkcyjne artefakty? Podczas warsztatów zaczniemy z „czystym” laptopem i zbudujemy na nim prosty i przejrzysty system deweloperski a następnie zbudujemy „szablon” projektu webowego tak aby móc go swobodnie rozwijać i pracować na nim lokalnie a jednocześnie móc w każdej chwili zbudować z niego produkcyjny artefakt. Wymagania sprzętowe: Laptop z dostępem do internetu jest koniecznym minimum ;) Jednak z uwagi na czas zalecam aby mieć wstępnie zainstalowanego docker’a w wersji wspierającej docker compose v2 oraz repozytorium GIT w aktualnej wersji. Jeżeli wasze laptopy mają jakieś „customowe” konfiguracje sieciowe, może być konieczność ich tymczasowego „wyłączenia”. Wymagany poziom wiedzy: Przydadzą się podstawowe informacje z zakresu działania protokołu http (omawiam środowisko do aplikacji webowych) oraz równie podstawowa wiedza z zakresu Docker’a (Docker compose będzie dodatkowym “bonusem”, ale nie jest konieczny).

Na warsztatach zajmiemy się analizą Twojego projektu, może być to projekt służbowy (jeżeli NDA na to pozwoli) lub podpowiemy który z dużych projektów open-source wybrać. Nabyte umiejętności są przenośne do każdego rozmiaru projektu (choć im więcej się w nim dzieje, tym lepiej). Skupimy się na sprawdzeniu w sposób mierzalny i przedstawialny biznesowi, w jakim stanie jest projekt pod kątem potrzeby refaktoryzacji oraz co należy refaktoryzować w pierwszej kolejności. M.in. damy wam do ręki argumenty dla biznesu. Zaczniemy od tego co sam GIT umie powiedzieć o projekcie (tę część wiedzy można zastosować do projektu napisanego w dowolnej technologii), następnie przejdziemy do narzędzi dedykowanych pod PHPa (m.in. PhpStan, Psalm, Deptrack,…) Przed warsztatami dostaniesz listę narzędzi, które warto mieć już przygotowanych na laptopie, aby nasza praca przebiegała sprawniej. Bez obaw, nie musisz ich wszystkich znać i umieć używać, to zrobimy w trakcie.

Zastosujmy Kubernetesa w praktyce - napiszmy aplikację mikroserwisową, zamknijmy ją w helm charcie i zdeployujmy na wspólnym klastrze. Wykorzystajmy funkcjonalności Kubernetesa, aby spiąć napisane aplikacje. Podczas warsztatu uczestnicy będą pisali własne aplikacje (lub korzystali z dostarczonych szablonów) które będą komunikowały się między sobą. Efektem warsztatów będzie przetestowana w praktyce wiedza o tworzeniu aplikacji i mikroserwisów w Kubernetesie, oraz umiejętność tworzenia i zarządzania Helm Chartami. Skrócona agenda - Przygotowanie środowiska pracy, logowanie do klastra. - Zapoznanie się ze środowiskiem pracy i obiektami istniejącymi w klastrze. - Pierwszy deployment - hello world. - Pierwszy Helm Chart. - Chaos Monkey i zabezpieczenie aplikacji. Wymagania wobec uczestników warsztatu: - własny komputer z dostępem do sieci, dowolny system operacyjny

Warsztat, który przeprowadzi Cię przez wszystkie etapy zastosowania trunk based development w istniejącym projekcie. Od zbudowania podstawowego, prostego pipeline CI/CD, przez techniki tworzenia kodu schowanego za feature flagami, po usprawnienie procesu wydawania i kontrolę nad flagami na produkcji. Podczas warsztatu przećwiczysz sytuacje związane z implementacją nowych, refaktoryzacją istniejących oraz usuwaniem feature'ów. Staniesz przed problemem migracji danych oraz doświadczysz sztucznie wywołanych awarii, które obsłużysz z wykorzystaniem feature flag.

Oko człowieka potrafi rozpoznawać bardzo dużo obiektów w perspektywie czasowej rzędu milisekund. W poprzedniej epoce byliśmy lepsi od komputerów, ale czy to już przypadkiem nie jest pieśń przeszłości? Na warsztacie nauczymy się teorii sztucznej inteligencji oraz różnych technik, które pomogą nam przy rozpoznawaniu obrazów. Przejdziemy przez kilka podstaw: - matematycznych – spokojnie, nie musisz przypominać sobie jak działają całki i pochodne – napiszemy do tego sofcik, - teoretycznych – jak mózg interpretuje i przekształca sygnały z oka w coś zrozumiałego, - programistycznych – dla wszystkich tych, którzy nie korzystali wcześniej z Pythona, - data science – czyli o obróbce ogromnej liczby danych „szybko”. Plan warsztatu: - wykład z teorii sieci neuronowych (1h), - programowanie – własna sieć i regresja liniowa (1h), - wykład o rozpoznawaniu obrazów (0,5h), - programowanie – rozpoznawanie obrazów i własny projekt (1,5h). Na warsztat uczestnicy powinni zabrać laptopa z przeglądarką internetową. Będą korzystać z Google Colab – dzięki temu nie ma żadnych wymagań wstępnych co do sprzętu czy software. Nie ma też żadnych wstępnych wymagań, jeśli chodzi o niezbędny poziom wiedzy.

Prelekcja jest pełnym studium przypadku: w jaki sposób aplikacja napisana „klasycznie” została przekształcona na model w architekturze Layered Architecture z pełnym wykorzystaniem Domain Driven Design, podejścia EventDriven oraz CQRS wraz z (kilkoma) agregatami budowanymi w oparciu o Event Sourcing. W trakcie postaram się pokazać w jaki sposób można wykonać migrację dowolnego projektu i jakich technik użyć aby taką migrację wykonać niewielkimi przyrostowymi krokami, bez konieczności ponoszenia nadmiernego ryzyka związanego z wielkim refaktoringiem.

CQRS jest uważany za przekomplikowany i akademicki wzorzec. Taki co go fajnie zobaczyć na prelekcji, ale niekoniecznie wykorzystać w pracy. Dookoła niego obrosło wiele mitów, że wymaga szyn zdarzeń, że potrzebne są dwie bazy danych, straszne eventual consistency, event sourcing itd. W trakcie swojej prelekcji zmierzę się z nimi i postaram się (co najmniej) kilka z nich obalić. Pokażę, że CQRS może być prosty, pragmatyczny i zupełnie praktyczny.

Czy wiesz co dzieje się z twoimi aplikacjami po wdrożeniu do chmury? W jaki sposób możesz określić ich stan i jakie procesy oraz narzędzia mogą Ci w tym pomóc? Na jakie wyzwania można się natknąć po drodze? Na podstawie własnych doświadczeń oraz raportów ze świata devops Karol przybliży temat Observability w kontekście systemów PHP.

Podejście DevOps to obecnie standard w większości firm cloud-native, ale dla wielu firm oferujących systemy cloud, wiązało lub wiąże się to z procesem zmiany i wprowadzeniem nowych zupełnie metod i technologii m.in: GitLab Pipelines, Testy w Dockerze, Playbooki Ansible i skrypty Terraform. Do tego dochodzi trochę ideologii i wskaźników, które stały się ważnym branżowym benchmarkiem: deploy frequency, change lead rate, change failure rate, mean time to recovery. Podczas prelekcji opowiem o wszystkich kluczowych aspektach DevOps, obrazując to praktycznymi przykładami na podstawie transformacji jaką przeszła - lub przechodzi, bo proces doskonalenia się nigdy nie kończy ? - firma eDokumenty, jeden z liderów rynku ECM w Polsce.

…a czego my moglibyśmy nauczyć ich? Na podstawie kilku niezwykle nietypowych produktów i usług, wymyślonych przez bohaterów popularnego serialu lat 90 - "Świat według Kiepskich", zaprezentuję rady i antyrady dla Product Ownerów, a potem przeniosę je do rzeczywistości IT. Wezmę pod lupę takie czynniki jak innowacyjność, czas wprowadzenia na rynek, kompetencje, strategie cenowe, ROI i kilka innych. Pokażę dla nich przykładowe metryki i implementacje.

Każdy kolejny rok naszej kariery to nowe techniki, architektury, języki, frameworki, biblioteki, narzędzia, bazy danych... Dobry specjalista musi nie tylko znać obecne rozwiązania, ale także śledzić rozwój nowych technologii i umieć odpowiednio dobrać je do stawianych wymagań. Nie jest łatwo nadążyć za ciągłym rozwojem branży, ale można zmienić swój sposób myślenia – zrozumieć zasadę działania zamiast zapamiętywania tysięcy szczegółów. Equational Reasoning to termin pochodzący z programowania funkcyjnego, który opisuje sposób myślenia oparty o funkcje i transformacje informacji. Odpowiednio dopasowany do kontekstu, pozwolił mi na zrozumienie wielu pozornie różnych obszarów programowania, dzięki czemu nowe wersje już znanych konceptów przestają być straszną niewiadomą, a wejście w nieznany projekt staje się o wiele łatwiejsze wiedząc gdzie szukać kluczowych informacji.

Tematyka: - uzasadnienie użycia technik CI/CD, - produkcja oraz rozwój oprogramowania w konteneryzacji, - trunk based development w CI/CD?, - budowa oraz utrzymanie ścieżek CI/CD, - obsługa kodu na kontenerach produkcyjnych, - wygodny dostęp do kodu w kontenerach produkcyjnych,

Zmiana. Jedyna stała rzecz w życiu i projekcie IT, bo przecież niemal zawsze wymagania będą ulegały kolejnym zmianom. I tu czasem powstaje duży problem, ponieważ zmiana w jednej części systemu pociąga za sobą kaskady zmiany w innych miejscach. Ale w naszym developerskim toolboksie mamy narzędzia Bounded Contextu i Context Mappingu, dzięki którym możemy zapanować nad tym chaosem, zaprojektować granice modeli w systemie czy ustalić sposoby ich łączenia. A to otwiera nam już drogę do strategicznych decyzji architektonicznych i organizacji zespołów. Krótki mówiąc - dziel, łącz i zwyciężaj!

Najbardziej wydajne zespoły dostarczają oprogramowanie w tempie kilku deploymentów na produkcję dziennie przez pojedynczego programistę, co na 5-8 osobowy zespół przekłada się na 150-200 i więcej deploymentów na produkcję w miesiącu. Osiąga się to m.in. przez tzw. Trunk-Based Development, czyli pracę bez branchy, gdzie całą pracę pushuje się bezpośrednio na master i deploy’uje na produkcję. Niezwykle częstym pytaniem i przeszkodą w osiągnięciu takiego flow są testy, które często potrzebują kilkudziesięciu minut czy nawet kilku godzin oczekiwania na ich rezultat - gdyby tylko zawsze “zielony”… Jak się jednak okazuje testy KAŻDEGO projektu, a przynajmniej każdego z którym prezentujący i jego rozmówcy mieli do czynienia, można zorganizować w taki sposób, aby feedback z pipeline’u CI/CD nadszedł w czasie krótszym niż 5 minut. Podczas prezentacji dowiesz się jak to osiągnąć! Zostaną wyjaśnione konkretne techniki i przykłady: - pracy z kodem testującym, a więc np. testów PHPUnit, zasady tworzenia klas XxxYyyTest, metod testujących testXxxYyy() i co najważniejsze kodu, który znajduje się w ich środku, - organizacji infrastruktury czyli tzw. pipeline’u CI/CD. Ponadto odbędzie się demo live, w trakcie którego „zazielenimy” w 5 minut baterię testów, której uruchomienie na środowisku developerskim zajmuje 5 godzin!

Google Cloud oferuje blisko 200 różnych usług chmurowych - w tym maszyny wirtualne oraz rozwiązania serverless. Które z nich sprawdzą się najlepiej dla aplikacji napisanych w PHP? Podczas prezentacji omówię różnice między Compute Engine, App Engine, Kubernetes Engine, Cloud Run oraz Cloud Functions. Podpowiem też jakie usługi towarzyszące wybrać dla baz danych, przestrzeni dyskowej czy kolejek.

Czy zdarzyło Ci się grać w papier, kamień, nożyce z kolegą, by określić kto pierwszy merguje swojego brancha do gałęzi głównej? Czy bywało tak, że branch rozwijany przez dłuższy czas stał się nagle głównym branchem w Twoim projekcie? Czy masz branche, które zmieniają ponad 10k linii kodu? Czy robiłeś kiedyś code-review przez kilka godzin? Przestań tracić czas i nerwy na rozwiązywanie konfliktów i zacznij częściej puszczać zmiany na produkcję wykorzystując trunk based development i feature flags.

W prezentacji chciałbym opowiedzieć dlaczego wszystkie nasze projekty skazane są przez naukę na klęskę i śmierć i skończą jako wielka kupa błota* zjedzone przez dług technologiczny i co możemy z tą sytuacją robić. Powiem między innymi o tym czym jest dług technologiczny, jakie zachowania powodują przyrost tego długu, jak możemy z nim działać i go unikać. *) błoto można sobie zastąpić inną mieszanką substancji o podobnej gęstości

Od wielu lat rozmawiamy o tworzeniu systemów, które są lepiej podzielone. Łatwiejsze w rozbudowie i utrzymaniu, pięknie napisane i dobrze podzielone na moduły. Wiele czasu poświęciliśmy na dyskusje o mikroserwisach, CQRS, event sourcingu, itp. Ale czy można prościej? Postaram się przybliżyć proste podejście do event-driven architecture, wspomnę też o wadach.

W swojej prezentacji przedstawię, czym jest biblioteka Symfony Messenger oraz jak z niej skorzystać. Omówię podstawowe koncepty publikowania oraz konsumowania eventów wraz z zagrożeniami, które na nas czekają. Następnie opowiem o różnych rodzajach transportów ich wadach oraz zaletach. Podzielę się moim doświadczeniem związanym z retry policy, który w wielu przypadkach pomogł zapanować nad fatalnymi sytuacjami. Na koniec zaprezentuje produkcyjne podejście uruchamiania workerów korzystając z Kubernetesa.

Opowiem o badaniu zespołów Google, przeprowadzonego kilka lat temu (Projekt Arystoteles). Wynikiem projektu jest opublikowana lista pięciu czynników sukcesu zespołu. - Bezpieczeństwo psychiczne - Niezawodność - Struktura i przejrzystość - Znaczenie - Wpływ. Przedstawię praktyczne porady, jak sprawdzić poziom bezpieczeństwa psychicznego w Twoim zespole i w jaki sposób wspierać ten czynnik w codziennej pracy w biurze i z domu :)

Języki używające programowanie funkcyjne de facto wprowadzają nowe funkcjonalności do innych języków, nie omijając PHP – Garbage Collection obecny w PHP był już w pierwszych wersja Lispa w 1958 roku (tak, 64 lata temu!) Niestety w PHP 8.1 nie ma jeszcze Generyków, ale pojawiły się inne funkcjonalności. Chciałabym przedstawić cześć konceptów używanych w FP takich jak: - Higher-Order Functions (HOF), - Closure, - Partial Application, - Currying, - Function Composition, - Pure Function, - Side effects, - Contracts, - Functor, - Referential Transparency, - Lambda, -Lazy evaluation, - Monoid, - Monad, - Lens, - Type Signatures, - Algebraic data type, - Sum type, - Product type, - Option, a następnie sprawdzić, czy są one dostępne w PHP 8.1, uwzględniając dostępne biblioteki.

Pisanie dokumentacji API to dla wielu developerów przykry obowiązek. Ponadto często musimy zawrzeć kontrakt API między frontendem a backendem jeszcze przed implementacją funkcjonalności po obu stronach. Dawniej zajmowało to dużo czasu. Ale tutaj z pomocą przychodzi nam Swagger i standard OpenAPI. Dzięki niemu możemy w kilka minut przygotować dokumentację

W obecnych czasach praca dewelopera w większości odbywa się lokalnie. Nasze laptopy często emulują działanie całych złożonych „produkcji”. Skoro więc spędzamy w tym środowisku dużo czasu, to powinniśmy zadbać aby samo środowisko było maksymalnie proste w obsłudze i przyjemne w pracy. Zobaczcie jak to można osiągnąć.

Composer to narzędzie, które powinien znać każdy programista PHP. Jego wydanie rozpoczęło nową erę w zarządzaniu pakietami w PHP. Pomimo, iż od premiery pierwszej wersji alpha Composera minęło już 9 lat, wciąż możemy spotkać projekty, które nie do końca wykorzystują jego potencjał. W mojej prezentacji opowiem o kilku istotnych optymalizacjach, które powinniśmy stosować w naszej codziennej pracy, także na przykładzie workflow, który przyjęliśmy w firmie Droptica. Pokażę też najczęstsze błędy popełniane przy konfiguracji Composera.

Przez kilkanaście lat pracy zawodowej wielokrotnie padłem ofiarą mitów i przejściowych trendów przemysłu IT. Bałem się wysłać CV na widok ściany wymagań. Wprowadzałem Scruma "na siłę", przepisywałem systemy od zera, budowałem wymyślną architekturę. Umknęło mi wiele ważnych rzeczy, na które dziś pragnę zwrócić Waszą uwagę. Opowiem jak możecie ruszyć swoją karierę "z kopyta" poprzez skupienie się na 20% rzeczy, które dadzą 80% rezultatów. Pokażę, jakie praktyki realnie pozwoliły mi osiągać duże sukcesy u klientów z całego świata.

Czy php-fpm faktycznie jest szybszy od mod_php? Które z tych rozwiązań jest lepsze i w jakich zastosowaniach? Porozmawiajmy o tym, jak można efektywnie uruchamiać kod PHP, jak zrobić aby działało to niezawodnie i szybko. Porozmawiajmy też o alternatywnych podejściach, takich jak php-pm.

Język PHP mocno się rozwija, a wraz z nim narzędzia wspomagające proces wytwarzania i weryfikację jakości. Poza frameworkami do testów istnieją jeszcze narzędzia, które mogą pomóc wyłapywać potencjalne problemy i nie wymagają stałego narzutu, jaki wiąże się z pisaniem testów. Są też takie, które pomogą nam iść z duchem czasu i korzystać z dobrodziejstw jakie niosą nowsze wersje języka lub przeprowadzą automatyczną refaktoryzację umożliwiając upgrade zależności do nowszych wersji. Przyjrzyjmy się im i temu jak można je wdrożyć w proces Continuous Integration.

Wielu z nas, programistów, doświadcza bólu przepisania aplikacji monolitycznej do architektury mikrousługowej. Ważymy za i przeciw różnych opcji biorąc pod uwagę projekt, nasz zespół, naszą wiedzę i umiejętności. Reguła głosi, że każda mikrousługa jest właścicielem własnych i niezależnych danych więc nie powinniśmy korzystać z centralizowanej bazy. Zatem w przypadku legacy możemy borykać się z procesem synchronizacji danych i wyborem technologii, która najpewniej na długi czas zdefiniuje nasz komfort pracy. Niniejsza prezentacja, bazująca na moim doświadczeniu, skierowana jest dla osób, które chcą zdobyć lub usystematyzować wiedzę na temat wymiany danych pomiędzy mikrousługami a istniejącymi systemami i chcą zagłębić się we wzorzec przechwytywania danych (z ang. Change Data Capture) oraz jego realizacje, z szczególnym uwzględnieniem Debezium.

Chciałbym opowiedzieć o kilku swoich doświadczeniach związanych z tym jak wygląda programowanie w Javie okiem wieloletniego doświadczonego programisty PHP. - Co jest największym, a co najmniejszym szokiem z mojej perspektywy? - Kiedy doszło do mnie, że Java to nie język programowania, a stan umysłu? - Dlaczego PHP powinien być podstawowym językiem do pisania wszystkiego? - Dlaczego świat programistów śmieje się z PHP, a powinien z Javy? Na te i inne kontrowersyjne pytania postaram się odpowiedzieć w całkowicie subiektywnej i stronniczej krótkiej prezentacji.

W ciągu ostatnich lat pracując dla jednej z większych firm iGamingowych mieliśmy sposobność walczyć z procesami ciągłymi, co skutkowało optymalizacją ich pod kątem zużycia pamięci i ich wycieków. Doświadczenie pozwoliło nam zgłębić wiedzę i wyciągnąć odpowiednie wnioski, którymi nasz zespół chciałby się podzielić.

Testy jednostkowe „betonujące" kod wymagają sporego nakładu pracy na ich utrzymanie. Zamiast nas chronić wprowadzają tylko większy stres, frustrację oraz podwajają czas developmentu. Łatwiej byłoby je po prostu porzucić… Zamiast tego może lepiej jest spojrzeć na problem z innej perspektywy? Chciałbym na podstawie swoich doświadczeń pokazać, że istnieje wyjście z tej sytuacji.

Jeśli ktoś miał okazję uczęszczać na jakąkolwiek alma mater, na pewno miał również wątpliwą przyjemność siedzieć na wykładzie i słuchać prowadzącego, który być może i miał wiedzę, ale sposób jej przekazywania pozostawiał wiele do życzenia. Głos usypiał, slajdy zawierały wszystko i nic, z sali wyszedłeś z poczuciem zmarnowanego czasu i braku sensu życia. Tak nie musi być. W trakcie wystąpienia przekażę garść informacji, jak opowiadać o developerce w sposób jak najbardziej przystępny. Podzielę się również wskazówkami, jak ułatwić życie organizatorom konferencji z perspektywy opiekuna technicznego sali. Wisienką na torcie będzie również parę słów na temat tego, jak sobie samemu ułatwić przejście od zapowiedzi do braw.

Ile potrzeba pudełek aby efektywnie zapakować sprzedane towary? W jakie pudełka zmieszczą się sprzedane towary? Jak można go próbować rozwiązać za pomocą algorytmu pakowania LAFF (Largest Area Fit First).

Twoim efektem pracy są lata doświadczenia i specjalistycznej wiedzy, co daje nam unikalny punkt widzenia. W końcu każdego nas to spotyka. Przychodzi do nas ktoś i prosi o wyjaśnienie. Świat IT, szczególnie programistów jest zdominowany przez umiejętności twarde - wiedzę, doświadczenie i chłodną analizę. Z tego powodu, gdy przychodzi do dzielenia się wiedzą techniczą, jest nam ciężej znaleźć ludzi potrafiących to zrobić w najlepszy sposób. Jako organizator programu mentorskiego PHPCon, chciałbym podzielić się swoimi spostrzeżeniami oraz podsumować go. Chciałbym Cię przekonać, że jeśli nigdy tego nie robiłeś/aś, zawsze możesz spróbować. Prezentacja szczególnie dla osób które uważają, że przemawianie jest nie dla nich i im się nie przyda.