Praca z remote to codzienność w każdym zespole – ale wiele osób używa tylko git pull i ma mglistą świadomość co się właściwie dzieje. Tracking refs, różnica między fetch a pull, kiedy --force-with-lease zamiast --force, i jak naprawdę działają zdalne branche to wiedza, która ratuje przed nieodwracalnymi błędami.
Pytanie „merge czy rebase?” to jedno z najczęstszych w zespołach używających Gita. Obie strategie osiągają ten sam efekt – integrację zmian – ale produkują zupełnie inną historię. Nie ma jednej właściwej odpowiedzi, jest kontekst. Pokażę kiedy co stosować, jak działają konflikty, i dlaczego fast-forward to nie to samo co „bez merge commita”.
Historia commitów to dokumentacja projektu – czytają ją inni programiści, git bisect po niej szuka błędów, a git blame tłumaczy decyzje. Dobre wiadomości commitów, umiejętność porządkowania historii przed merge i znajomość cherry-pick oraz bisect to narzędzia, które odróżniają kogoś kto „używa Gita” od kogoś kto nim „zarządza”.
Większość programistów używa Gita jak czarnej skrzynki: coś wpisujesz, coś się zapisuje, historia jakoś działa. Dopóki coś nie pójdzie nie tak. Żeby Git przestał być magią – zacznij od zrozumienia, co naprawdę siedzi w katalogu .git/. Cztery typy obiektów: blob, tree, commit, tag. Tyle. Reszta to konsekwencje.
Magento 2.4.9 wyszło z oficjalnym wsparciem PHP 8.5. Przez ostatnie miesiące testowałem RC na projektach klientów – teraz jest stable i można planować migracje. Pipe operator, readonly dziedziczenie, nowe array functions – wszystkie PHP 8.5 features są teraz pierwszoklasowymi obywatelami w kodzie modułów Magento. Przeglądam co się faktycznie zmieniło w rdzeniu, co trzeba zaktualizować w własnym kodzie i jak wygląda ścieżka upgrade dla istniejących projektów.
W 2024 napisałem pierwszy wpis o AI w pracy PHP developera. Minęły dwa lata i obraz zmienił się radykalnie. Nie chodzi już o pytanie „czy używać AI” – chodzi o to jak wbudować narzędzia w workflow żeby nie traciły czasu a go oszczędzały. Po dwóch latach codziennego użycia mam precyzyjny obraz co działa, co nie działa i jak zorganizować pracę żeby wyciągnąć maksimum bez polegania na narzędziu więcej niż powinno.
OpenSearch 3.x przyniósł dojrzałe wsparcie dla k-NN (k-Nearest Neighbors) i vector search – fundamentu wyszukiwania semantycznego. Zamiast dopasowania słów kluczowych („buty sportowe”), możesz teraz wyszukiwać po znaczeniu – klient wpisuje „coś do biegania w górach” i dostaje trafne produkty bez dopasowania słów kluczowych. Pokazuję jak zintegrować to z Magento 2 przez własny moduł, bez Adobe Commerce SaaS.
Interpreter to wzorzec GoF który pozwala zdefiniować gramatykę dla prostego języka i zbudować interpreter który przetwarza wyrażenia w tym języku. Brzmi akademicko, ale ma bardzo konkretne zastosowania: reguły rabatowe konfigurowane przez operatorów bez zmian kodu, wyrażenia filtrujące produkty, warunki widoczności komponentów w CMS. Buduję od zera mini-interpreter reguł promocyjnych w PHP.
Przez lata diagnostyka wolnych zapytań SQL w Magento 2 wyglądała tak: slow query log, EXPLAIN, długie wpatrywanie się w plan zapytania. W 2026 mam nową warstwę: wklejam EXPLAIN output i schemat tabeli do LLM i dostaję sensowne sugestie indeksów i przepisania zapytania w kilka sekund. Nie zastępuje rozumienia SQL, ale dramatycznie przyspiesza cykl diagnoza-hipoteza-weryfikacja. Pokazuję workflow na realnym przykładzie z projektu Magento 2.
Podstawy Hyvä – szablony PHTML z Alpine.js, Tailwind, eventy przez CustomEvent – opisałem w 2024. Po kilku latach wdrożeń mam zebrany zestaw wzorców które powtarzają się w zaawansowanych projektach: kompozycja wielu komponentów Alpine.js, komunikacja między izolowanymi widgetami, lazy loading danych przez Magento REST API i wzorzec store’u dla globalnego stanu koszyka. Pokazuję te wzorce z kodem.