Forum PHP.pl

Tylko jeszcze się rodzi pytanie jak w przypadku takich stron miałaby wyglądać nawigacja warstwowa. Np. na blogu poza kategorią jak wydzielić osie przekrojów aby było 3-10 cech w danym kryterium? Wydaje się że w przypadku bloga lepiej sprawdza się linkowanie wewnętrzne + artykuły powiązane. Zauważ, że wiele blogów/stron informacyjnych optymalizujących ruch nie wyświetla nawet menu na stronach z artykułami bo użytkownicy z nich nie korzystają. Korzystałbyś na przykład z menu na Onecie?

Przykład profili YT jaki podałeś jest ciekawy - faktycznie na niektórych profilach przydałaby się taka opcja jak fajna nawigacja warstwowa albo chociaż dobrze zorganizowana nawigacja tradycyjna, ale przypuszczam że YT nie wprowadził takich opcji bo dla przeciętnego użytkownika zaprojektowanie takiej nawigacji jest bardzo trudne i w skali serwisu przyniosłoby więcej szkody niż pozytku, choć na pewno byłyby pojedyncze profile, które by na takiej organizacji sporo zyskały.

Ale oczywiście są to moje teorie - nie jestem specem od UX. Może gdyby takie opcje pojawiały się częściej i użytkownicy umieli z nich korzystać to by było inaczej. Pamiętam jak lata temu na jednym sklepie zmienialiśmy nawigację z horyzontalnej na warstwową i było wiele obaw czy użytkownicy to ogarną - robiliśmy nawet testy na użytkownikach i reakcje były mieszane - jedni od razu podłapywali, inni nie mogli się przyzwyczaić. Dzisiaj jest to śmieszne bo prawie każdy sklep ma taką nawigację, ale wtedy użytkownicy jeszcze nie umieli z takich opcji efektywnie korzystać. Tak więc może kiedyś Twój pomysł też się przebije.

Nawigacja warstwowa wymaga sporo pracy i przemyślanej struktury - bardzo trudno byłoby coś takiego zaprojektować np. dla blogów. Często zamiast klasycznej nawigacji warstwowej stosuje się filtry, tagi itp. bo łatwiej się tym zarządza. Na blogach użytkownicy raczej poruszają się używając linkowania wewnętrznego, a w 90% wychodzą po przeczytaniu interesującego ich artykułu.
Nawigacja warstwowa wymaga dużej liczby "przedmiotów" + sporej powtarzalności cech. W przypadku bloga jest relatywnie mało artykułów i bardzo rzadko da się z sensem zrobić filtrowanie inne niż kategorie, bo w poszczególnych kategoriach jest mało artykułów. Znacznie lepiej sprawdza się doba wyszukiwarka. Nie mówię, że czasami taka nawigacja by się nie przydała, ale raczej będą to wyjątki od reguły.

Z DNS się raczej nie uda - można ewentualnie ustawić bardzo niski TTL i podmieniać przed planowanymi downtimami serwera. W przypadku awarii itp to tak jak batman wspomniał raczej potrzebne są jakieś loadbalancery. Ale trzeba mieć na uwadze, że konfiguracja takiego środowiska to nie tylko przekierowanie na inny serwer - pozostaje jeszcze kwestia zadbania o integralność danych w bazie danych, zasoby statyczne (np. dogrywane pliki przez cms), sesje użytkowników etc.

Ja używam Thinkpada T490 i moim zdaniem daje radę.
Pracuję na Magento + docker. Zazwyczaj mam odpalone jedno środowisko ~5-6 obrazów dockera + phpstorm + 2 przeglądarki + slack + konsolka i ogólnie nie mam problemów z wydajnością. Szczerze mówiąc to mnie ten laptop pozytywnie zaskoczył (dostałem z przydziału) bo ma tylko 24gb ramu i i5 najnowszej generacji. Myślałem, że będzie "tak sobie" ale póki co nie mam powodów do narzekania. Nawet jak się zdarzy zostawić włączony debugger po wyczyszczeniu cachu to Magento szybko wstaje. Do laptopa udało mi się podłączyć 2 zewnętrzne monitory + monitor samego laptopa też jest aktywny.
Bateria na pod Linuxem starcza mi na kilka godzin - pod Windowsem pewnie by pocągnęła w granicach 8h. Wykonanie spoko. Z minusów to umiejscowienie wejścia rj45 po prawej stronie + ogólnie mała liczba portów. Raczej docelowo trzeba się liczyć z zakupem stacji dokującej. Rozdzielczość na takich małych matrycach też jest zabójcza - trudno mi się na niej pracuje, gdy musi pełnić rolę podstawowego ekranu, ale to chyba znaczy, że czas na wizytę u okulisty. Lenowo ma też dziwnie umiejscowiony lewy ctrl - na szczęście w biosie można łatwo go zmapować z klawiszem FN, który jest w miejscu, gdzie powinien być ctrl.

Na plus na pewno przenośność - laptop jest bardzo lekki i wykonany tak, że nie strach go nosić w torbie. Udało mi się też przetestować odporność na zalania - faktycznie działa ;-)

Co do wydajności to prywatnie mam komputer stacjonarny z 64gb ramu + jakimś starym xenonem, który na benchmarkach jest wyceniany znacznie wyżej niż to i5 z laptopa, niemniej jednak wydaje się, że laptop radzi sobie nawet trochę lepiej z Magento niż mój komputer - przypuszczam, że lepiej się wpisuje charakterystyką w potrzeby Magento niż mój komp stacjonarny, ale ogólnie na sprzęcie się nie znam.

No coś w tym jest, zwłaszcza że zazwyczaj człowiek coś tam na boku zawsze robi i łatwiej na boku robić w Symfony niż w Magento, gdzie bariera wejścia jest bardzo duża - na tyle dużą, że raczej nikt hobbystycznie w ten system nie wchodzi, tylko firmy szkolą pracowników na własny koszt.

Aha jeszcze jedna wada M2 mi się przypomniała - relatywnie mało się koduje własnych rozwiązań. 90% to wpinanie czegoś w logikę Magento trudno więc o coś takiego, że piszesz wszystko po swojemu. Dopiero w sporych projektach pojawia się taka potrzeba, gdzie trzeba napisać na przykład całą warstwę integracji z kilkoma zewnętrznymi systemami itp. W moim przypadku większość zadań to jednak 9h czytania kodu aby zrozumieć jak coś działa i 1h kodowania.

Pracuję w Magento 2. Zarobki b2b (poza Warszawą):
- mid 8-12k netto
- senior 12-16k netto

W Warszawie możesz do tego dołożyć jakieś 2k.

Jest sporo pracy zdalnej. To co robisz zależy od wielkości firmy - w małych pewnie jest jak piszesz. W dużych projektach są fajne i ciekawe taski - dużo integracji z innymi systemami itp. Mi się ogólnie praca w Magento podoba. Na pewno trzeba bardzo dobrze mówić po angielsku bo większość klientów to klienci anglojęzyczni. W Magento jest też fajne to, że nie ma zbyt dużej konkurencji bo programiści PHP jako masa są dość słabi, a Magento ma sporą barierę wejścia, więc jak już się ktoś przebije to z pracą raczej nie ma problemów.

Największy minus Magento to dla mnie to, że nie da się tego robić na pół gwizdka. Zamykasz się w jednym systemie, a od czasu przejęcia przez Adobe Magento bardzo stawia na komercję. Pytanie czy takie podejście przetrwa próbę czasu. Z jednej strony wchodzą duzi gracze przyciągnięci marką Adobe z drugiej system robi się nieopłacalny dla mniejszych firm, bo w Stanach godzina pracy agencji to już 100-200$, a pracując z Magento wiesz ile w tym systemie najbardziej trywialne rzeczy zajmują czasu.

Praca z Symfony wydaje się bardziej rozwojowa jako całość o ile trafisz do firmy, która pisze porządny kod - ale znowu w świecie PHP to wcale nie jest takie pewne.

Ja póki co zdecydowałem się rozwijać dalej w Magento, czas pokaże czy to dobra decyzja.

Niestety trochę błądzisz, ale moim zdaniem to bardzo dobra decyzja, że próbujesz coś napisać samodzielnie zamiast uczyć się frameworka. Frameworki niestety uczą złych nawyków jeśli nie umiesz w porządne OOP.

To od czego bym zaczął na Twoim miejscu to composer. Composer dzisiaj to jest standard w każdym projekcie i warto go użyć już teraz choćby po to aby mieć autoloader.

Druga rzecz to PSR - pisałeś, że czytałeś i starasz się stosować, ale w kodzie tego zupełnie nie widać... Polecam zainstalować php-cs-fixer i odpalić w projekcie, a potem zobaczyć sobie jakimś diffem co zostało zmienione.

Mamy PHP 7.3, a w twoim klasach tego nie widać - nie ma typowania parametrów funkcji, typów zwracanych itp.

Z takich pierdół unikaj jak ognia stosowania if... else, a jeszcze bardziej zagnieżdżania ifów bo to zło wcielone.
Takich rzeczy jak to nie da się czytać


Zobacz o ile czytelniejsza byłaby ta funkcja po refactorze (użyłem wyjątków, ale możesz tu wstawić swoją logikę ze zwracaniem false itd):


Wewnątrz konstruktora (i ogólnie klas) nie powinieneś używać new bo to jest ukrywanie zależności. W dobrym kodzie wszystkie zależności powinny być wstrzykiwane w konstruktorze. Ale to może być dla Ciebie trudne gdy bo nie ogarniasz jeszcze zapewne wzorców projektowych typu fabryki, czy Dependency Injection. Niemniej postaraj się gdzie dasz radę raczej tworzyć klasy bez używanie w ich kodzie new. Czyli przykład:


W php do komentarzy funkcji stosujemy php doc block, a jeszcze lepiej typowanie inputu/output + doc block jako uzupełnienie (np. o rzucane wyjątki, typu elementów w tablicy itp).

Jeśli myślisz na poważnie o kodowaniu, to zacznij w 100% stosować angielski - czemu funkcje są po angielsku, a baza po polsku? Pokracznie to wygląda.



To chyba na początek tyle.

Jak to ogarniesz to na Twoim miejscu spróbowałbym przerobić jakiś tutorial MVC żeby zrozumieć jak wygląda architektura prostej aplikacji w PHP. Robiesz bardzo wiele błędów i masz ogólnie źle zorganizowany kod. Przerobienie dobrego tutoriala na pewno pomoże.

Ogólnie szału nie ma, ale każdy kiedyś zaczynał, a widać że czytasz i starasz się rozwijać, więc to dobrze wróży. Już samo używanie gita i githuba na Twoim poziomie to bardzo dobry znak.Trzymam kciuki.

Ogólnie po zmianach wygląda już znacznie lepiej. Postaram się dać trochę uwag - to jeszcze nie wszystko co rzuciło mi się w oczy, ale nie chcę Cię wszystkim przytłaczać na raz.

1. GIT - w gicie masz coś takiego jak .gitignore pozwalające na nie commitowanie pewnych plików. Dla przykładu w 99% projektów nie komituje się vendorów, a już na pewno nie powinieneś commitować cachu od fixera, czy innych cachy/logów. Tu przy okazji będziesz miał fajne ćwiczenie jak przestać śledzić zmiany w repo czegoś co omyłkowo commitowałeś. No i zdecydowanie popracuj nad opisywaniem commitów - opis powinien być jasny i klarowny, a nie @Update. Jak będziesz kiedyś robił repo, które chcesz pokazać pracodawcy, to historia commitów jest często przeglądana. W firmach zazwyczaj pracuje się w systemach zadaniowych i opis kommita wygląda tak: [Task-abc] Opis taska.

2. PHP coś z tym fixerem poszło nie do końca ok, bo w wielu miejscach nadal masz kod niezgodny z PSR - np. $a=1 powinno być $a = 1; Ogólnie sporo masz tam jeszcze w kwestii PSR do poprawienia. Ale znów - jeśli myślisz o pracy zawodowo, to jest coś na co pracodawcy baaaardzo zwracają uwagę, więc wyrabiaj sobie nawyki.

3. Piszesz, że walczysz z diffem - są do tego narzędzia, które pokazują graficznie. Ja korzystam akurat z wbudowanego w PhpStorma, ale to płatne oprogramowanie, więc pewnie musisz poszukać jakiś alternatyw - może vscode ma podobne wtyczki, albo jakiś wyspecjalizowany edytor. W PphSotrm jest nawet opcja wpięcia fixera jako plugin, który sam poprawia PSR w pliku. Umiejętność pracy z Diffem jest kluczowa w pracy zespołowej, gdzie musisz sprawdzić co kto i kiedy zmieniał. Warto nad tym pracować.

4. Komentarze. Ogólnie tutaj szkoły są różne. Ja jestem zwolennikiem, że kod powinien się dokumentować sam, gdzie tylko to możliwe. Ogólnie komentarze powinny być stosowane gdy wnoszą coś nowego - jeśli są redundantne z metodą to są zbędne. Spójrz tutaj:


Te dwa komentarze nie wniosły NIC oprócz dodatkowego kodu, który trzeba teraz utrzymywać i poprawiać jak robisz refaktor metod.

Przydatne komentarze



Tutaj komentarz coś wnosi bo informuje że w tablicy zwróconej przez metodę dostanę obiekty danego typu + że metoda może rzucić wyjątek danego typu. Zobacz, że już parametru nie ma w komentarzu, bo wszystko wynika z nagłówka metody.

5. Chyba już powoli warto zacząć się zastanawiać nad ubraniem tego w strukturę. Na początek poradziłbym Ci stworzyć wspólny entrypoint dla całej aplikacji. Pokombinuj jak to zrobić, aby wszystkei requestty uderzały w jeden punkt (index.php). W ten sposób wyeliminujesz potrzebę używania require w całej aplikacji. Na początek możesz to zrobić po prostu w formie frontcontrollera, choć docelowo pewnie raczej powinien to byś typowy plik inicjujący aplikację, a front controller już powinien być osobno. Niemniej na razie możesz to zrobić w 1 pliku i potem pomyśleć jak zrobić Refaktor.

6. Podoba mi się, że sam użyłeś strict_types - chyba o tym nie pisałem, a widzę że w klasach się pojawił.

7. Odnośnie pytania z ostatniego postu - łatwiej będzie to ogarnąć przekierowaniem na stronę z odpowiednim komunikatem bo ładnie obsłużych to na wyższym poziomie niż w szablonie.

To o czym piszesz to jest częsty błąd w tutorialach, bo prawdziwe OOP trudno ująć w krótkim tutorialu. Szybciej się go nauczysz pisząc jakąś apkę wspólnie z kimś kto temat ogarnia. Największe oszustwo OOP polega na tym, że ludzie próbują przenosić taksonomie z prawdziwego życia. Na przykład typowy przykład - mam psa i rybkę -> stworzę klasę Animal. To jest w 80% tutoriali o OOP, a jest to anty przykład jak stosować OOP. Tak jak pisałem dzisiaj będzie Ci to trudno zrozumieć bo piszesz zbyt mały kod, ale w prawdziwym kodzie to jest droga do wielkiej katastrofy.
Wpisz w Google jedną z podstawowych zasad OOP "Favor composition over inheritance" - na razie nie zaprzątaj sobie tym głowy bo w Twoim kodzie są większe problemy niż stosowanie SOLID, ale ogólnie dziedziczenia staraj się unikać to zaprocentuje w przyszłości.

* tu taki disclaimer - ja nie jetem przeciwnikiem dziedziczenia. W wielu miejscach jest bardzo przydatne - np. metoda szablonowa etc. Ale na pewno nie w takiej formie jak uczą go w tutorialach dla początkujących. To tylko tworzenie złych nawyków, które potem trudno zwalczyć, a kompozycja jest bardzo łatwym konceptem do ogarnięcia więc można od razu wyrabiać dobre wzorce.

Tymczasem do działa - czekam na kolejną wersję kodu. Jeszcze z 20 -30 iteracji i będzie dobrze ;-)

PS. z tym HTML to chyba źle zrozumiałeś intencje kolegi - chodziło mu o zupełne wydzielenie widoku z logiki, a nie zamianę kodu html na stringi w PHP. Jak poczytasz o MVC to zobaczysz o co chodzi. Nie musisz tu używać TWIGA/SMARTY - widok możesz zrobić na prostym PHP + HTML, ale nie mieszaj widoku z logiką.

Jeszcze taka ogólna uwaga odnośnie dziedziczenia. Ogólnie dziedziczenie nie służy do "przekazywania" kodu do klas potomnych tak jak to robisz, czyli rozszerzając klasę o klasę Database. Dziedziczenie zazwyczaj to zło, chyba że robisz to świadomi i w przemyślany sposób. W większości przypadków lepsza od dziedziczenia jest kompozycja (wstrzyknięcie obiektu przez konstruktor). Jest to bardziej elastyczne rozwiązanie i nie blokuje rozwoju aplikacji. Dziedziczenie w prawdziwych aplikacjach używane jest dość rzadko - raczej stosuje się interfejsy + kompozycję. Na tak małym kodzie jak teraz piszesz może to być trudne do zrozumienia i wydawać się całkiem dobrym pomysłem, ale serio używaj dziedziczenia jak najrzadziej się da, bo przy większym kodzie to się szybko mści.

No prosze a już myślałem, że się poddałeś ;-)

Kod wygląda o niebo lepiej niż pierwsza wersja - wreszcie zaczyna przypominać jakąś strukturę używaną w 21 wieku, więc widać że czasu nie zmarnowałeś. Ale nie będę Ci tu słodził bo nie po to tu piszesz.

Moje uwagi
- brak konfiguracji o czym pisał nospor - rzeczy, które mogą się zmieniać powinny być wydzielone do osobnego miejsca. Np. plik yaml + obiektowy wraper na to pozwalający odczytywać dane konfiguracyje

- jak używasz static to na 99% możesz być pewien, że popełniasz błąd projektowy. Static to taki nowy stan globalny i z aplikacji powinien zniknąć, bo w ten sposób ukrywasz niepotrzebnie zależności. Wszystkie zależności powinny być wstrzykiwane przez konstruktor choćby dlatego, że wtedy widzisz, ze robi się ich w pewnym momencie za dużo i jest pora na refactoring. Tak więc moja rada - usuń wszystkie odwołania static.

- brakuje mi w Twoim kodzie obiektów Request / Response. Echo powinno pojawić się w kodzie aplikacji tylko raz, gdy renderujesz Response. U ciebie tekst jest printowany w kontrolerach, autoryzacji itp. Masz różne dziwne kontrukcje typu przekierowanie headerem w kontrolerze itp... Tak nie powinno być - powinieneś mieć obiekt Response - najlepiej w kilku odmianach typu "NotAuthorizedResposne / NotFoundResponse / RedirectResponse" itp. Contoller powinien zwracać taki Response i front controller albo powinien decydować co dalej z tym zrobić. W ten sposób bedziesz miał piękne polimorficzne kontrollery, które zawsze będą zachowywać się tak samo, czyli zwracać obiekt ResponseInterface lub AbstractResponse. Ewentualnie zamiast zwracać niektóre Respony można rzucać wyjątki typu NotFoundException i przechwytywać je we frontkontolerze (gdyby go miał).

- Brakuje mi obiektu FrontController - > to ten obiekt powinien inicjować Request, Router i obsłgiwać Response zwrócony z kontrolera

- Pytałeś o dziedziczenie po kontrolerze - tutaj jak najbardziej moim zdaniem ma to sens, bo kontroler ma dużo kodu, który jest wszędzie potrzebny, więc dziedziczenie jest uzasadnione.Warto byłoby aby była to klasa abstrakcyjna.

- kod ciągle nie jest zgodny z PSR

Ogólnie błędów jest sporo więcej, ale jak poprawisz to + to co napisał nospor możemy iść dalej ;-)
Gratki za postępy.

Tak w telegraficzny skrócie, to to co zaproponowałeś wygląda jak w miarę sensowny przebieg.
Front controller odpala Router, ten z kolei na podstawie danych z Request dispatchuje przebieg do odpowiedniego kontrolera.
Kontroler zwraca Response. W takiej minimalistycznej wersji Response powinno zawierać:
- body (do body renderujesz np szablon w kontrolerze)
- headery (np. content-type)
- status code (np. 200/404 itd)
Front controller po otrzymaniu responsa "wysyła" go do przeglądarki (lub innego klienta) - zazwyczaj coś w stylu $response->send() - metoda send zajmuje się wyświetleniem / ustawieniem hederów itp. Czyli np. jak response będzie 301 to $response->send() wykona przekierowanie, a jak 200 to wyświetli zawartość w zależności od content-type (bo przecież to może być html ale też np. json lub xml).

Obiektów response zazwyczaj jest kilka i mają one wspólny interfejs - w ten sposób jak za miesiąc Twoja apka będzie musiał w jakiejś akcji zwrócić json zamiast html to po prostu utworzysz sobie JsonResponse implementujący interfejs Response i nic nie będziesz musiał zmieniać w szkielecie.

To jest własnie kluczowa sprawa w OOP żeby tworzyć strukturę, która do rozszerzenia nie wymaga edycji już istniejącego kodu. Jeśli twój front Kontroller będzie akceptował generyczny Response to mu wszystko co się dzieje w $response->send().

Oczywiście to tylko jedno z możliwych podejść.

Najprościej chyba możesz to zrobić przechwytując we front controlerze rezultat zwrócony przez dispatcher np. tak:

Scottie Go - polecam, idealna pod ten wiek. Moja córka ~7 lat fajnie ogarnęła podstawy, Niestety od połowy zadania były już trochę za trudne i gra trafiła na półkę, pewnie za rok zrobimy kolejne podejście. Jej największa zaleta w stosunku do gier na komputerze/tablecie to próg sprawdzenia rozwiązania. Na wersjach elektronicznych bardzo łatwo można było sprawdzić czy rozwiązanie jest ok, przez co często zamiast pomyśleć, klikała i zgadywała. Scottie go to gra planszowa i sprawdzenie odbywa się przez zrobienie zdjęcia, czyli trochę mniej wygodne, przez co znika syndrom szybkiego palca i dziecko dwa razy pomyśli zanim sprawdzi poprawność zadania.

Ale Panowie oddzielmy kilka spraw. Po pierwsze nie ma nic złego w ciekawości i zajrzeniu jak coś działa, nawet jeśli działa i nie trzeba nic naprawiać. To całkiem zdrowy objaw. Jeśli natomiast ktoś chce mieć 100% wiedzy na temat jak działa wszystko to już nie jest zdrowe, chyba że to praca hobbystyczna a nie zarobkowa. W oprogramowaniu enterprisowym tak się nie da, bo po prostu kodu jest zbyt wiele. Nad tym kodem pracują tysiące ludzi, zmienia się praktycznie każdego dnia - w normalnej pracy klienckiej nie da się nadążać za tymi zmianami, a co dopiero mieć głębokie zrozumienia jak WSZYSTKO działa. Dla przykładu request w trybie developerskim ładuje około ~3.000 klas, drobna zmiana w konfiguracji kontenera dependencji może wywrócić całą tą logikę do góry nogami. Do tego dochodzą jeszcze typy wirtualne, konfiguracja, auto-generowany kod, różnego rodzaju varnishe, rabbity, zewnętrzne integracje, systemy typu mcom itp itd.

Ogólnie moim zdaniem w oprogramowaniu enterprise trzeba się po prostu pogodzić z tym, że odpowiadamy za małą cząstkę kodu - dlatego ten kod jest właśnie tak napisany jak jest - tj. w oparciu o SOLID. Póki działa to możesz go używać. Jak potrzebujesz rozszerzyć to zgodnie z OCP jest to tak zrobione, że możesz go rozszerzyć bez zmiany core itd. Idzie ogromy overengenering, kupa abstrakcji itp itd, ale jak klient chce gruszki na wierzbie, to się pytasz jakie mają być duże (i czy go stać ;-) ).

BTW co do różnicy framework vs CMS to w dużym oprogramowaniu to się zaciera. Na przykład znowu w Magento, które jest przecież CMS'em, masz też framework, który złożonością przypomina Symfony.

Tylko rodzi się pytanie, czy my musimy wiedzieć co się dzieje pod maską? Bo w sumie OOP powstało na bazie tego, że programista nie musi wiedzieć co się dzieje tylko ma korzystać z interfejsu i dana rzecz ma działać. Jak nie działa tak jak oczekuje tego programista, to powinny istnieć instrumenty umożliwiające mu zmianę tego działania bez ingerencji w core. Kod jest oczywiście przez to większy i bardziej skomplikowany, ale przypomnijcie sobie ile kiedyś trwało wyklepanie prostego CRUDA, a ile trwa dzisiaj z użyciem Symfony. Ja wiele lat temu bardzo zraziłem się do programowania przez to, że właśnie te trywialne rzeczy zajmowały tyle czasu.

Dzisiejsze programowanie jest na tyle złożone, że nikt tak na prawdę nie wie jak działa wszystko. Mamy teraz czasy osób, które muszą mieć ogólny przegląd pola + specjalizację w jakiejś dziedzinie.

Obecnie pracuję w Magento i bez przesady powiem, że w firmie nie ma ani jednej osoby, która zna ten system/framework na wylot. Myślę, że nawet w samym Adobe nie mają takiej osoby - i mówię tu tylko o części backendowej. Z takim stanem rzeczy się pogodziłem - wystarczy mi świadomość, że mam big picture systemu + jak potrzebuję się czegoś dowiedzieć to mam debugger (bo dokumentacji w przeciwieństwie do Symfony czy Laravela praktycznie nie ma).

PHP dopiero wchodzi w etap kodu enterprise, ale wydaje się (mi), że taka będzie tendencja. Od wersji 7 zaczęły się zmiany w tym kierunku - otrzymaliśmy jeden z najwydajniejszych języków skryptowych z kosmicznie (jak na język skryptowy) rozwiniętymi opcjami OOP, silnym typowaniem, trybem strict, gdyby wersja 8 postanowiła zerwać z kompatybilnością wsteczną w stosunku do części głupich rozwiązań to już w ogóle byłby kosmos.
Język się mocno profesjonalizuje, pojawia się ogromna ilość profesjonalnego kodu, Composer do zarządzania zależnościami itp.

Mini stronki / proste cms'y to już raczej przeszłość. Oczywiście tutaj PHP będzie dalej istniał, bo się do tego zastosowania nadaje, ale też będzie z tego segmentu wypierany przez inne technologie (np. RoR do prototypów aplikacji, Node do prostego backendu, bo wtedy jeden programista ogarnia front i backend itp). PHP moim zdaniem zacznie konkurować z Javą o klienta enterprise. Mnie osobiście to cieszy bo praca ciekawsza i $$$ więcej. Oczywiście nie stanie się to w rok czy dwa, ale taka będzie tendencja -> spadek % udziału w rynku + wzrost udziału w rynku enterprise.

Ogólnie moim zdaniem trzeba się pogodzić z brakiem 100% kontroli, swoją niewiedzą itp i przestawić się na pracę z klockami, ciągłą niepewnością itp. Dokładnie na takiej samej zasadzie jak kiedyś ludzie przechodzili z języków niskopoziomowych na wysokopoziomowe. Oczywiście są też alternatywy - np. nie iść w kod enterprise tylko szukać nisz, gdzie potrzebne jest inne podejście - pytanie jednak czy to będzie php i web ogółem.

No jak tak to odebrałem - np. post Phpiona, czy posty o tęsknocie za starymi, dobrymi czasami. Może faktycznie trochę za dużo między wierszami czytam.

No to ja chyba jakiś dziwny jestem, bo mnie z kolei właśnie jara programowanie w oparciu o interfejsy, wysoki poziom abstrakcji, wyspecjalizowane do maksimum klasy, często z 1 metodą publiczną itp. Po pierwsze i najważniejsze przejście na taki styl pisania dało mi duża frajdę z programowania bo właśnie to "prosto do celu" bardzo mnie męczyło w PHP.
Po drugie wiele razu już zdarzyło mi się, dojść do momentu, gdzie nagle bardzo mocno zmieniały się założenia w jakimś projekcie, spodziewam się, że będzie sporo pracy, otwieram swój kod, a tam jedna klasa do wymiany i bang - działa. Wszystko właśnie dzięki tej abstrakcji i generalizacji.
Czy taki sposób pisania jest szybszy? Sam nie wiem - czasami czuję, że idzie spory overengineering i można byłoby coś napisać odrobinę szybciej, ale z drugiej strony potem mam większą satysfakcję wracając do swojego kodu i mogąc go refaktorować z łatwością.

Ogólnie mi bardzo odpowiada przenoszenie praktyk z Javy do PHP (oczywiście z rozsądkiem) - miałem to szczęście, że ktoś poświęcił mi wiele czasu aby otworzyć mi oczy na to podejście i zrozumieć o co naprawdę chodzi w OOP. Teraz wiele rzeczy jakoś samo mi się w głowie układa i widzę wszelkie zależności, buduje mi się taki big picture z lotu ptaka. W wielu obszarach brakuje mi jeszcze skilii, ale nad tym pracuje. Na przykład ostatnio trochę zerknąłem w testy i próbując napisać trochę testów do swoich starych klas zrozumiałem w praktyce wiele rzeczy, które wkładał mi do głowy mój "mentor", a które trochę olewałem "bo po co tak komplikować".

Druga sprawa to podoba mi się podejście Phpiona (poza tą prostotą i tęsknotą do Kohana ;-) ) i sam chyba też tak trochę mam. Trzeba mieć swoje "core skills", bo one nas żywią, ale warto też robić sporo skoków w bok - a to devops, a to frontend - dobra zajawka na coś jest zawsze na propsie i zapobiega wypaleniu. Ja teraz jestem na takim etapie, że doby mi nie starcza aby liznąć tych wszystkich obszarów, które chciałbym zgłębić.

Po naszych pizzowych rozmowach wydaje mi się, że dobija Cię typ pracy jaki wykonujesz. Freelance ma swoje zalety, ale niestety w większości robisz tam proste i powtarzalne projekty. Pracując w firmie masz kilka pozytywów:
- kontakty społeczne
- wymiana doświadczeń / możliwość pracy z lepszymi od siebie
- większe projekty, gdzie potrzeba wielu kompetencji z różnych dziedzin

Mam porównanie z pracą na freelansie i pracą z większymi projektami. Jednym z głównych elementów, które spowodowały, że chciałem iść do pracy w firmie była świadomość, że utknąłem w rozwoju - ciągle powtarzałem swoje błędy, nie miałem wizji rozwoju, przytłaczała mnie ilość rzeczy do nauczenia i żadnej nie mogłem poświęcić tyle czasu ile bym chciał.

Teraz mam swój backend, w nim się bawię w architekturę, poznawanie PHP itd i tego oczekuje się ode mnie w pracy. A w wolnych chwilach hobbystycznie bawię się nowymi zabawkami - np. obecnie Reactem a w planach już jest Jenkins, DDD i inne rzeczy. Ale to robię dla siebie, żeby mieć większy obraz całości. Ogólnie teraz mam trochę jak Pyton, że w głowie pełno pomysłów tylko czasu brakuje.
Na freelansie faktycznie zawsze jest pogoń bo musisz wiedzieć wszystko i w niczym nie możesz przez to się wyspecjalizować. Ciągle tylko lepisz gotowce bo klient już stoi ze stoperem, a zamiast programować szukasz w Google jak w tej konkretnej bibliotece obsłużyć jakiś edgecase.

Ogólnie mam wrażenie, że bycie fullstackiem w dzisiejszych czasach to droga do nikąd. Technologii jest tyle, że życia nie starczy aby je opanować. Można być fullstackiem hobbystycznie - założyć sobie, że backend robisz w technologii X, frontend w Y i w tym się rozwijać, ale komercyjnie trudno jest skakać pomiędy vue, reactem, angularem, wszelkimi dialektami javascriptu i jednocześnie nadążać za zmianami w backendzie.

Czasami czytam sobie ogłoszenia dla backendowców i mam wrażenie, że nie znam często połowy technologii z ogłoszenia. Rozmawiam z kolegami seniorami i mają podobnie. W ogłoszeniach często są jednocześnie 3 wiodące frameworki, kilka baz noSQL, kolejki, systemy CD/CI, kilka rozwiązań typu WP/Magento itd. Trudno ZNAĆ te rzeczy jednocześnie, ja z wieloma miałem do czynienia, rozumiem ideę, kiedyś nawet użyłem w jakimś projekcie (i już często zapomniałem), ale trudno mi uczciwie powiedzieć, że znam technologię X.
Kluczem do szczęścia jest chyba aby trafić do pracy, gdzie masterujesz 2-4 rzeczy + masz styczność z wieloma innymi, w których masz ludzi, od których możesz się uczyć.

Jak załatwisz ciekawe zlecenia to wchodzę w to ;-) Dla mnie jedyny poważny argument za freelansem to to, że można pracować dla zagranicznej firmy za znacznie lepszą kasę niż w PL. Trochę to załamujące jak moja firma bierze 150-200$ za godzinę, a ja nawet o takiej kwocie w złotówkach nie mogę pomarzyć ;-) Fajnie byłoby mieć projekty z USA i robić je w grupie na własny rachunek.

@smokanalog - to mi się właśnie przejadła taka praca "wszystko po trochu". Skacząc z kwiatka na kwiatek miałem ciągle poczucie, że się nie rozwijam, tylko chaotycznie poznaje podstawy z różnych dziedzin. Gdy ostatnio rozmawialiśmy to miałem właśnie takie wrażenie, że Ciebie też to męczy. Oczywiście w takiej pracy są fajne rzeczy - np. konieczność poznawania różnych domen problemów biznesowych. Zawsze będzie coś za coś.

Na szczęście są jeszcze projekty prywatne ;-)

Zawsze można połączyć 2 światy - np. w firmie być osobą dochodzącą jak są zlecenia (lepsza stawka godzinowa przy okazji) + freelans. Póki dzieci nie ma można się bawić w takie rzeczy bo potem to już się najbardziej stabilizacja liczy i ta rutyna, której tak chcesz unikać.

Portfolio ma sens tylko jeśli zamierzasz je pokazać klientowi końcowemu, czyli np. gdy pracujesz na freelansie. Piszesz o CV, więc zakładam, że chcesz szukać pracy. W takim wypadku szkoda Twojego czasu na to - na rekrutacji nikt na to nie zwróci uwagi. Lepiej opisz najciekawsze projekty w CV i podkreśl tam co było wyzwaniem / jak sobie z tym poradziłeś. Tu też od razu taki hint z mojej strony, że jeśli szukasz pracy w backendzie to w projektach warto mieć inne rzeczy niż stronki - np. jakieś ciekawe libki, czy projekt który robi coś nietypowego - ogólnie coś o czym będzie można porozmawiać.

PHP to taki język, że na każdym poziomie możesz się gdzieś zahaczyć i jest przekrój ofert od zupełnie śmieciowych z minimalnymi wymaganiami aż po bardzo wymagające, gdzie na wejściu wymaga się bardzo wiele. Nie pokazałeś swojego kodu, więc trudno określić co już umiesz, ale po opisie wnioskuje, że raczej niewiele. Wg mnie aby znaleźć sensowną pracę w PHP trzeba:
- ogarniać PHP
- umieć przynajmniej 1 framework lub popularny cms/system sklepowy (Wordpress, Prestashop etc) na poziomie umożliwiającym pracę z klientem
- ogarniać git (podstawowe koncepcje typu marge, branch itp + umiejętność korzystania z repo zdalnego typu gitlab / github)
- ogarniać podstawy fullstacku (czyli html, css, js)
- poruszać się w miarę sprawnie w Linux (czyli umieć postawić system, zainstalować LAMP, podpiąć domenę do tego etc). Nie musi to być na super poziomie, ale z grubsza powinieneś umieć kupić server root i doprowadzić go do takiej postaci, że po wisaniu mojastrona.pl wyświelti się Twoja strona
- Mysql na podstawowym poziomie
- umiejętność korzystania z Google + StackOverflow

To jest ogólnie podstawa, która wg mnie wyznacza zatrudnialność, czyli bycie juniorem, któremu ktoś chce zapłacić. Przy odrobinie szczęście i umiejętności samosprzedania z takim stackiem dostaniesz ~2k na rękę. To jest mz taki poziom, że w mało wymagającej firmie nie będziesz przeszkadzał i jak się szybko uczysz to będziesz rokował, że po 2-4 miesiącach zaczniesz robić coś konstruktywnego. W PHP na 90% będzie to niestety gównopraca, gdzie będziesz robił jakieś rzeczy typu konfigurowanie Wordpressa w agencji marketingowej. Jak masz głowę na karku to szybko z tego typu pracy uciekniesz i zaczniesz się rozwijać.

W to co warto zainwestować:
- angielski na poziomie B2 - w prawie każdej dobrze płatnej pracy w naszym kraju będą od Ciebie wymagali abyś potrafił się porozumiewać w tym języku z kolegami z innych krajów czy klientami + prawie na pewno będziesz pisał dokumentację w tym języku.
- umiejętności społeczne - wbrew pozorom mają ogromne znaczenie w tym zawodzie

Co do Twojego pytania o frameworki to moim prywatnym zdaniem jest tak zaczynasz od PHP, rozwijasz się i dochodzisz do poziomu gdzie zaczynasz rozumieć frameworki rozwijasz się dalej i dochodzisz do poziomu, gidze frameworki zamieniasz na komponenty z których korzystasz, a sam zaczynasz się skupiać na architekturze, rozwijasz się dalej i w pewnym momencie tworzysz koncepty, które piszą za Ciebie inni. Raczej każdy idzie tą drogą. Umiejętność korzystania z frameworków to jest mniej więcej ten moment, gdzie możesz oczekiwać, że ktoś Ci zapłaci a Twoją pracę.

Co do studiów - jak będziesz umiał dobrze programować to w PHP prawie nigdy nie będą Cię pytać o papier. W niektórych językach jest to wymaganie podczas rekrutacji (np. Java), ale w PHP raczej rzadko widuję ogłoszenia, gdzie wyższe techniczne to must have.

Ogólnie jak chcesz iść w tym kierunku to ucz się i szukaj pracy jednocześnie. Nastaw się jednak, że $$$ w tym zawodzie są ok, ale na pewno nie od samego początku. Pewnie z 2 lata od dzisiaj miną zanim dojdziesz w okolice średniej krajowej, a i to może się okazać optymistycznym założeniem. Tak tylko uprzedzam na wypadek gdybyś się naczytał, że programiście zarabiają naście tysięcy. Faktycznie zarabiają, ale Ci dobrzy, a nie wszyscy. W PHP myślę, ze do poziomu 10k + dochodzi nie więcej jak 1 na 10 programistów.

Forum w obecnej formie raczej nie ma większego sensu. Ja już od dawna odwiedzam tylko hydepark. Wszystkie problemy rozwiązuje za pomocą stacka - już szczerze mówiąc nawet nie pamiętam kiedy musiałem tam zadać pytanie, bo wszystkie moje problemy są pośrednio albo bezpośrednio już tam rozwiązane.

Jedyne tematy jakie pojawiają się na forum to dział przedszkole, gdzie ludzie mają problem z podstawami i nie potrafią znaleźć odpowiedzi w języku angielskim... w sumie to czytając te tematy, mam wrażenie że w większości zakładają je osoby, które po prostu nie mają jeszcze nawyku szukania / brakuje im elementarnej samodzielności.

Ogólnie chyba trzeba się pogodzić z tym, że php.pl już jest pod wodą. Gdyby było sensownie prowadzone to mogłoby być centrum "towarzyskim" w stylu 4programmers (czyli ogólnie działy typu hydepark, kariera itp) + przedszkole. Można by to jeszcze rozszerzyć o jakąś koncepcję temat tygodnia/miesiąca, gdzie administracja rzuca temat typu "architektura X" i o tym sobie dyskutujemy. Niemniej na to już chyba za późno, bo użytkowników już praktycznie na forum nie ma ;-(