No i niestety przy zetknięciu się z zadaniami rekrutacyjnymi prawda okazuje się dość brutalna. A myślałem do tej pory że są nic nie warte a tymczasem dość skutecznie weryfikują umiejętności. Przychodzi do realizacji stosunkowo prostego zadania które przy użyciu frameworka który znam od lat wykonałbym w mgnieniu oka, tak przy zetknięciu się z nowym nie ma najmniejszych szans na realizację tego w wyznaczonym czasie. Tu już nawet nie chodzi o to jak wysoki próg wejścia ma Symfony czy Laravel tylko przejście na każdy nowy framework wygeneruje problemy. Czyli nie ma sensu nawet startować dopóki się nie ogarnie nowego frameworka do takiego stopnia żeby czuć się tak samo dobrze jak w tym w którym się działało od lat. Ale odpowiadają, zresztą już nie pierwszy raz tak było, w firmie Symfony, ja w CV miałem to co miałem i nie przeszkadzało żeby odpowiedzieli, dopiero w kolejnym etapie gdzie jest sprawdzanie umiejętności okazywało się ile to jest warte. No cóż, będę musiał trochę posiedzieć, coś ciekawego napisać tylko w dalszym ciągu nie mogę się zdecydować: Symfony czy Laravel. Człowiek głupieje całkowicie.
Twoim głównym problemem nie jest brak znajomości jakiegoś tam frameworka (bo to można dość prosto nadrobić). Twój prawdziwy problem, to brak jakiegokolwiek doświadczenia w pracy w grupie i jak sądzę, również brak doświadczenia w czymś większym, niż projekt, który można skończyć samodzielnie w miesiąc.
Mam doświadczenie zarówno w Symfony, jak i w Kohanie i faktycznie, jest spora różnica na korzyść Symfony w kontekście możliwości, które framework oferuje, zgodności z prawidłami OOP, jakości itd. Kohana to framework z poprzedniej epoki, zresztą wiele lat już będący "deprecated", Koseven to trochę takie sztuczne podtrzymywanie przy życiu. Generalnie mam dobrą i złą wiadomość.
Dobra jest taka, że absolutnie nie wiem co w samym Symfony jest trudnego, przynajmniej w podstawach. Sam framework, po utworzeniu pustego projektu to wręcz microframework, do którego dołącza się w razie potrzeby kolejne elementy, lub też wybiera się zdefiniowany stack (typu --webapp), gdzie z automatu są dociągnięte i skonfigurowane podstawowe zależności. W zasadzie z automatu masz skonfigurowanego PostgreSQL, połączonego z frameworkiem, a sam projekt można w celach deweloperskich uruchomić jedną, wbudowaną komendą:
symfony server:start -d
Zazwyczaj bardzo dobrym, uporządkowanym sposobem wejścia w temat Symfony dla osób mających doświadczenie w pracy w innych frameworkach był "The Fast Track", gdzie bodaj autor Symfony krok po kroku, na konkretnym przykładzie, wszystko tłumaczy w zwięzły sposób (z odnośnikami typu "want's more?" na końcu), jak z angielskim u Ciebie miałoby być na bakier, to jest nawet polska wersja (ale polecam oczywiście angielską, jako że jest to język techniczny de facto)
Materiały w tej książce online obejmują też większość "nowoczesnych", pokrewnych aspektów wykorzystywanych w frameworkach z dzisiejszych czasów typu Rabbit MQ, Docker, SPA itd., oczywiście w podstawowym stopniu. Mam wrażenie, że właśnie ta książka to niejako spina całą dokumentację w jedną całość - dokumentacja jako taka opisuje po prostu interesujące Cię części frameworka, ale nie daje całościowego oglądu tego, co jest potrzebne.
Co ważne, ta polecona przeze mnie książka online jest aktualna dla najnowszej wersji Symfony. A i nazwa "Fast Track" jest nieprzypadkowa - nie jest to wielomiesięczny kurs, więc może ten materiał plus wspieranie się dokumentacją czy forum tam, gdzie coś okaże się dla Ciebie niejasne. Polecam ten kurs, jak czegoś nie wiesz, dawaj znać na forum.
Druga dobra wiadomość jest taka, że żeby zacząć "coś" robić w Symfony nie trzeba kupy czasu - opanuj jak działa routing w Symfony (podstawy), stwórz kontrolery, pobierz dane z requesta, zwróć sobie dane do widoku Twigowego, pobaw się funkcjami Twigowymi, być może formularzami (chociaż teraz częściej front się tworzy w większym odseparowaniu od Symfony niż kiedyś). Spróbuj zrobić też nową akcję w tym kontrolerze, która zwraca JSON-a, spróbuj w widoku Twigowym załączyć prostego AJAX-a, który wywoła tą akcję i odbierze dane z niej.
Następnie przejdź do Doctrine - stwórz encję oraz repozytorium dla niej, skorzystaj albo z doctrine migrations do wygenerowania tabeli automatem dla tej encji, albo odpal komendę doctrine:schema:update, zobacz jak encja jest reprezentowana przez tabelę w bazie. Potem dodaj sobie przykładowe rekordy, najlepiej na razie ręcznie w kontrolerze typu $user = new User(); $user->setName('abcd'); $entityManager->persist($user); $entityManager->flush();. Jak pododajesz rekordy, pobierz sobie kilka z nich używająć repozytorium dla encji User - początkowo repo może być puste, korzystaj ze standardowych metod typu find, findAll() etc, poczuj jak to działa.
Następnie zapoznaj się z tym jak w Doctrine są definiowane relacje pomiędzy encjami:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.14/reference/association-mapping.html
...możesz posiłkować się tymi przykładami, sam zobaczysz, że jest to proste. Jak porobisz relacje, spróbuj dodać do jednego z repozytorów funkcję, która korzysta w środku z QueryBuildera / DQL do budowania nieco bardziej rozbudowanego zapytania, najlepiej z JOIN-ami. Jak poczujesz Doctrine, stwórz sobie jakąś klasę Serwisu - po prostu zwykłą klasę usługową, która robi cokolwiek, co ma związek z logiką biznesową - niech to coś liczy, przetwarza itd. Wrzuć klasę serwisu do kontrolera, wywołaj ten serwis, zwróć wynik do frontu.
W dużym uproszczeniu wiele funkcjonalności sprowadza się do powyższego, a to tak naprawdę kilka wieczorów roboty. Mając background 13 lat doświadczenia z Kohany, powinno dalej być łatwiej poczuć co jest co.
Paradoksalnie to, co opisałem jest też złą wiadomością. Bo o ile są to podstawy do szybkiego załapania, tak naprawdę większość systemów, które tworzyłem były dużo bardziej rozbudowane i zaawansowane. I framework oraz jego znajomość to mały pikuś w kontekście ogarnięcia logiki Klienta, która jest do zaprogramowania, doboru rozwiązania technicznego, zaimplementowania tego tak, aby całość działała wydajnie. Co więcej, samo Symfony to był tylko element całości, często po stronie frontu był React, a dalej w backend przydałyby się podstawy DevOpsowe (choćby czucie tego o co ogólnie chodzi).
Stąd jeśli ten etap, po tym co opisałem faktycznie okaże się trudny, to potem łatwiej nie będzie, bardzo delikatnie rzecz ujmując :) I jest to głównie zła wiadomość w przypadku, gdy z Senior Kohana Developer chciałbyś przeskoczyć na poziom Senior Symfony Developer. Natomiast jeśli jesteś tego świadom, a chyba jesteś skoro startujesz na stanowiska juniorskie, to jest nieco bardziej optymistycznie i ten Fast Track, plus to, co opisałem to duża część wiedzy przydatnej na poziomie junior, gdzie będziesz się rozwijał i pewnie ze względu na doświadczenie szybciej wrócisz na poziom Mid / Senior.
Swoją drogą, w kontekście Symfony vs Laravel...ten pierwszy framework zdecydowanie w większym wymiarze daje wolną rękę programiście w kontekście architektury oprogramowania, plus gdzieś od wersji 4 dąży do bycia frameworkiem, w którym w większym stopniu stosuje się ogólno przyjęte dobre praktyki programowania obiektowego. Symfony daje Ci microframework do którego dopinasz kolejne klocki. Symfony ma Doctrine ORM, które jest wzorowane na Hibernate z Java, o ile dobrze pamiętam. Co do ogółu Doctrine jest nieco trudniejszy, ale stosuje nieco bardziej "czyste" wzorce projektowe w sobie. Symfony jest chyba też nieco popularniejsze na rynku europejskim, czy też wężej patrząc polskim.
Laravel jest frameworkiem nastawionym na czytelność, prostotę, szybkość tworzenia oprogramowania, wygodę programisty. Jednocześnie tam jest stosowana masa rzeczy, które łamią SOLID (static statica staticiem pogania), czy też są na pograniczu antywzorca, jak mega wygodny Active Record, ale jednak budzący różne wątpliwości (w sumie to taka mini boska klasa od wszystkiego).
Niemniej jednak w praktyce jest to równie dobry framework jak Symfony, o trochę innej charakterystyce (szybkość i prostota > czystość, wzorce, gotowość do super zaawanasowanych projektów), a jako że w PHP zazwyczaj fejsbuki nie powstają, tylko ciekawe, ale średnio-zaawansowane projekty, ten brak zgodności z wieloma prawidłami OOP w praktyce nie wadzi. Laravel też jest zdecydowanie bliżej Kohany niż Symfony, ze względu choćby na te częste statici, czy też wspomniany Active Record. Ale nie mam tu aż tyle wiedzy aby przedstawić Ci jakikolwiek tip na rozwój w tej technologii, jako że tam mam bardzo ogólną wiedzę i mało robiłem :) Laravel jest mega popularny w USA, gdzie bodajże też powstał.
Właśnie dla takich przypadków warto zainwestować i poznać algorytmy oraz struktury danych, to jest wiedza która się nie przedawnia.
Tego typu zagadnień jest więcej np. wzorce projektowe, projektowanie systemów oraz integracji.
Dużo jest firm, które to sprawdzają i nie interesują ich technologie które zmieniają się szybciej niż w kalejdoskopie, bo wychodzą z założenia na podstawie Twojej znajomości ADS, że jesteś w stanie to szybko opanować.
BTW. Ja też jestem specjalistą w 1 technologii.
Moja strategia jest taka, że trzymam w zapasie drugą technologię na średnim poziomie znajomości.
Jeżeli drugi zapasowy stack w tym czasie się przeterminuje to zmieniam na inny.
Jeżeli nie będzie pracy w mojej głównej działce to z poziomu expert A przechodzę na moda w obszarze B.
Ja mam wrażenie, że autor robi spaghetti code (jesli nie to moze dostaniemy próbkę tego prostego procesu rejestracji/logowania, jakie MVP, PoC, OP majac 13 lat expa to chyba sie nie narobi przy tym).
W kilku miejscach spytałem z czym jest dokładnie problem, ale nie widzę odpowiedzi. A z czym maja najczęściej osoby pisząc spaghetti?
- z separacją odpowiedzialności
- z faktem, że powinno się wykorzystywać interfejsy
- z brakiem swiadomosci, ze service container czy inny "container" zaleznosci to podstawa
- z brakiem wiedzy, że kod napisany zgodnie z wzorcami i po odpowiedniej separacji odpowiedzialnosci jest latwiejszy w utrzymaniu i testowaniu
Tak prawdę mówiąc nieważna jest tu wojna Laravel vs SF, bo i tu i tu mozna pisac dobry kod. Myślę że problem leży bardziej w podejściu, że autor chciałby coś już mieć na szybko, zamiast poświęcić chociaż 1 dzień na przerobienie oficjalnego tutka symfony czy laravela.
ja robie w php, python, c++, c#, JS (frameworki), swift
Nie wiem czemu się dziwicie? Patrząc po tym, czasem tu piszą ci, którzy znają tylko Delphi/Lazarusa a nigdy nie używali współczesnych technologii można odnieść wrażenie, że prawie cala wiedza o Delphi jest wiedzą bezużyteczną, a nawet może przeszkadzać bo są to złe nawyki. Więc przejście z Delphi np do .Net to nie jest to samo co przejście z Javy do C#. Jest to o wiele trudniejsze, bo więcej dotychczasowej wiedzy idzie wprost do kosza.
@gajusz800: Ja kilka lat temu przeszedłem z C++/Python + OpenGL do C# + Unity 3D.
Nie żałuję, że rozstałem się z OpenGL. Nawet się cieszę, że nie muszę się nim przejmować :D
Ale wiedza wyniesiona z grzebania w starociach nie jest bezużyteczna. Wiesz co chcesz zrobić, tylko szukasz jak to zrobić w innej technologii.
Może trudno się przemóc, bo z poziomu mistrza stajesz się znowu uczniem i wszystko na początku się wolniej robi, ale potem tylko na tym korzystasz.
@drorat1 czytając twoje wpisy mam wrażenie, że ty nigdy nie byłeś programistą, a jedynie klepaczem kodu. po co się tak zamartwiasz każdą najmniejszą rzeczą? jeśli pisałeś X lat we frameworku devowym to raczej znasz podstawowe koncepty, które frameworki webowe ze sobą dzielą i na samej znajomości tych konceptów potrafisz zademenstrować swoją wiedzę i to, że kumasz o co chodzi. znasz OOP, SOLIDa, MVC, podstawowe design patterny, DI, co to ORM, IoC, ogarniasz parę głupich akronimów typu DRY czy YAGNI, interesujesz się nowinkami w nowych wersjach PHPa to jesteś w stanie aplikować nie tyle co na oferty z innymi frameworkami ale stwierdziłbym, że może i z PHPa udałoby ci się uciec jeśli czułbyś taką potrzebę. jeśli nie znasz większości z tych konceptów, to znaczy, że się zasiedziałeś i jest to wyłącznie twoja wina
i czego ty się boisz w takim frameworku? większość z nich jest prostsza niż te legacy gówna, w których pracujesz/pracowałeś, przestań komplikować sprawę i patrz na to w taki sposób, że na sam początek (ale też w sumie większość twojej pracy) potrzebujesz wiedzieć jak do aplikacji dodać nowy endpoint (gdzie wrzucić kontroler i gdzie jest routing), jak działa autentykacja, jak wykonać zapytanie do bazy, jak zmieniać/tworzyć jej scheme i jak wygląda env. jak chcesz odpalić jakiś worker to to googlujesz i godzinę później wiesz co i jak, jak chcesz coś scachowe'ać analogicznie, gdzie tu filozofia? przy takim crudzie jedyne co robisz to nakładka na twoją bazę danych, to nie jest lot na marsa xD
drorat1 napisał(a):
No i niestety przy zetknięciu się z zadaniami rekrutacyjnymi prawda okazuje się dość brutalna. A myślałem do tej pory że są nic nie warte a tymczasem dość skutecznie weryfikują umiejętności. Przychodzi do realizacji stosunkowo prostego zadania które przy użyciu frameworka który znam od lat wykonałbym w mgnieniu oka, tak przy zetknięciu się z nowym nie ma najmniejszych szans na realizację tego w wyznaczonym czasie.
Jeśli to zadania domowe, to zwykle masz kilka dni na ich zrobienie.
Nikt nie musi wiedzieć, że robiłeś je kilkanaście godzin przez kilka dni, mimo że powiedzieli, że to robota na jedno popołudnie.
Jeśli to zadania na żywo, to jest to loteria trochę, plus dużo zależy od tego, czy masz gadane. Ale ostatnio pojawił się wątek o tym na forum, jak się przygotowywać do takich zadań (tam @jarekr000000 dobrze to opisał Jak się przygotowujecie do live codingu na rozmowie? )
Tu już nawet nie chodzi o to jak wysoki próg wejścia ma Symfony czy Laravel tylko przejście na każdy nowy framework wygeneruje problemy. Czyli nie ma sensu nawet startować dopóki się nie ogarnie nowego frameworka do takiego stopnia żeby czuć się tak samo dobrze jak w tym w którym się działało od lat.
Może masz problem, że nie lubisz być słaby w czymś? Tylko, że czasem trzeba wyjść ze strefy komfortu.
Zresztą nie jesteś jedyny - od czasu do czasu pojawiają się wątki, że ktoś podobnie jak ty się okopał w jakichś technologiach (zwykle się zasiedział w jednej firmie przez kilka lat i odpadł z rynku, nie zna nowoczesnych standardów, bo w jego firmie nie używali itp.) i teraz ma problem, bo żeby znaleźć nową pracę, musi się od nowa uczyć programowania w pewnym sensie. Inni z kolei zmieniają język programowania/technologię i się boją, że będą musieli się cofnąć do poziomu juniora z zarobkami i też mają dylematy.
To nie jest tak, że jesteś jedyną osobą, która się zasiedziała w jakiejś technologii i teraz musi się nauczyć nowej i zejść z piedestału i cofnąć do podstaw.
Ale z drugiej strony nie jest tak, że jak w starej technologii byłeś ekspertem i dla ciebie bycie ekspertem stało się standardem, to teraz będziesz musiał stać się ekspertem w nowej technologii, żeby cokolwiek zdziałać. Możesz być sobie początkującym, a później średniozaawansowanym, ale już będziesz coś umiał i miał jakieś poszukiwane na rynku skille.
Ciemną stroną mocy każdej specjalizacji jest proces buraczenia. Takowy postępuje jak nabierasz doświadczenia i tego branżowego i tego życiowego. Takowy objawia się na różne sposoby.
My programersi widzimy to po dziale ajti który częściej jak rzadziej robi łachę że da wjazd do jakiegoś środowiska albo zreanimuje windowsa który się przekręcił. Mimo sporego eXperience, dużego snioritY warto być człowiekiem i widzieć w drugiej osobie człowieka. Kropka.
Z całym szacunkiem, ale historia opisana przez OPa @drorat1 to nie jest wg mnie problem specjalizacji, tylko problem nauczenia się jednej rzeczy, zasiedzenia się i braku rozwoju oraz poszerzania horyzontów. Programowanie to nie jeżdżenie TIRem, że raz się czegoś nauczysz i po sprawie. Sam pisałem stronki i aplikacje w PHP i Kohana Framework ale było to chyba z 11 lat temu, albo jeszcze wcześniej xD. Nawet nie wiem, czy ten framework jest dalej rozwijany i na jakim poziomie stoi. Dużo lepszym frameworkiem był poprzednik Kohany - CodeIgniter. Pamiętam, że dokumentacja i uporządkowanie tego wszystkiego stało tam na wysokim poziomie. Kohana miała być kolejną wersją tego frameworka dla nowszej wersji PHPa, ale sam framework i dokumentacja stały IMO na gorszym poziomie niż CodeIgniter. Od tamtego czasu, dawno olałem tego PHPa, pisałem w javie wszelkiej maści apki - od mobilnych, poprzez backend i streaming, aż po kotlina, pythona, swifta i iOS. Java pozostaje moją główną technologią, ale nauka czegoś nowego nie stanowi dla mnie problemu. Poza tym, nie trzeba być szerlokiem, aby stwierdzić, że specjalizacja w niszowym frameworku i nisko płatnej technologii (PHP) i JS to słaby pomysł i lepiej się douczyć nowych rzeczy.
@wiciu: Świete slowa panie wiciu, ja sie zasiedzialem kiedys w firmie i robili na Larvie 5.5. Jestem Swietny w programowaniu i kazdy kto tez taki jest wie ze po miesiacu zaczynamy sie nudzic i nie chce nam sie juz klepac ciagle tego samego. To sie nazywa chyba wypalenie w pracy xD wiec zeby sie zresetowac zaczalem grzebac w innym jezyku i tak bylo ze swiftem, napisalem jakies aplikacje a potem gry na zegarek. Zajalem sie frontendem na powaznie czyli tam te VUE 1,2,3,4,5 Angulary, alpinejsy i inne. W koncu pomyslalem ze stworze uniwersalny produkt. napisalem aplikacje MASTEr -> SLAVE na ipada gdzie mozna zbierac informacje od klientow. Zbieranie informacji to kwestia konfiguracji w bazie danych a aplikacja sama generuje widoki i zakladki. Proste, ale dochodowe jak sie okazalo :)
W koncu odszedlem z firmy i oani chyba z Larvy 5.5 nie mogli sioe przesiac na larve 7 bo za duzo tam bylo syfu juz. i musieli przepisywac od nowa program. ale nadal uzywali JS , potem tam ktos podobno zaczal wstawki z VUE 2 ale ogolnie dla mnie bylo tam za malo rozwojowo, a wiecie gdzie widze sie za 5 lat? hahahaah u laryngologa bo juz sie zapisalem xDDD
chomikowski napisał(a):
@wiciu: Świete slowa panie wiciu, ja sie zasiedzialem kiedys w firmie i robili na Larvie 5.5. Jestem Swietny w programowaniu i kazdy kto tez taki jest wie ze po miesiacu zaczynamy sie nudzic i nie chce nam sie juz klepac ciagle tego samego. To sie nazywa chyba wypalenie w pracy xD wiec zeby sie zresetowac zaczalem grzebac w innym jezyku i tak bylo ze swiftem, napisalem jakies aplikacje a potem gry na zegarek. Zajalem sie frontendem na powaznie czyli tam te VUE 1,2,3,4,5 Angulary, alpinejsy i inne. W koncu pomyslalem ze stworze uniwersalny produkt. napisalem aplikacje MASTEr -> SLAVE na ipada gdzie mozna zbierac informacje od klientow. Zbieranie informacji to kwestia konfiguracji w bazie danych a aplikacja sama generuje widoki i zakladki. Proste, ale dochodowe jak sie okazalo :)
W koncu odszedlem z firmy i oani chyba z Larvy 5.5 nie mogli sioe przesiac na larve 7 bo za duzo tam bylo syfu juz. i musieli przepisywac od nowa program. ale nadal uzywali JS , potem tam ktos podobno zaczal wstawki z VUE 2 ale ogolnie dla mnie bylo tam za malo rozwojowo, a wiecie gdzie widze sie za 5 lat? hahahaah u laryngologa bo juz sie zapisalem xDDD
"ale nadal uzywali JS "
JS to programowanie? (chce myśleć, że tak bo się tym bawię, ale bądźmy poważni..; )
"i musieli przepisywac od nowa program"
Ja od 3 tygodni 3 raz przepisuje program od nowa. I nie dlatego, że muszę, bo widzę jaki może być.
Jeśli widziałeś, że "muszą" to może mieliście inne podejście, tak czy inaczej już nie jesteście razem.