Covid + rynek juniora

Hej,
Żeby przedstawić własną pozycję to najpierw omówię ją i poniżej zawrę moje pytanie do społeczności:
Od października zeszłego roku do połowy maja br uczestniczyłem w swego rodzaju programie entry level w kierunku .NET : czyli na początek 3 m-ce praktyk i douczania technologii, jako że wcześniej programowałem hobbystycznie od roku w Javie, i potem praca jako Junior.NET dev. Problem w tym że z uwagi na "trudności w prowadzeniu działalności gospodarczej(...)" mój "entry-level program" został zamieniony na poszukiwanie seniora, a mi podziękowano po wykonaniu moich zadań. Po wypowiedzeniu douczyłem się Angulara w stopniu pozwalającym mi bezproblemowo wykonywać np. zadanie rekrutacyjne w tej technologii (w pracy wcześniej robiłem w backendzie tylko) - no na przykład o takie: https://github.com/mariuszbyahoo/TaskAssignementManager. Poznałem także technologię IdentityServer4 by być w stanie stworzyć program w którym można zarządzać użytkownikami i dostępem do zasobów. Zachęcam do obejrzenia także mojego profilu linked in https://www.linkedin.com/in/mbudzisz/
Dodam że bardziej się odnajduję w pracy która obejmuje bardziej "biznesową stronę" .NET i technologie frontendowe, natomiast słabszy już będę z tematów które dotyczą np. programowania na poziomie komunikacji z podzespołami komputera za pomocą tego właśnie .NET, czy tworzenie rozwiązań niskopoziomowych.

Moje pytanie:
Jakie jeszcze mogą być źródła, z których mogę brać ogłoszenia o otwartych rekrutacjach? Głównie mówię o zagranicznych, ponieważ jak mamy w PL justjoin nofluffjobs mamy praca.pl i pochodne, te monitoruje na bieżąco, a nie ukrywam dla mnie kompletnym obecnie priorytetem jest znalezienie jakiejkolwiek pracy w której mogę kontynuować kształcenie, studia także chętnie, miejsce nie ma dla mnie znaczenia. Proszę zatem o ewentualne porady czy sugestie które mogłyby mi pomóc znaleźć tę "Drugą pierwszą pracę" jako że ta pierwsza nie wypaliła z uwagi na pandemię.

Główne pytanie - jakie miasto?

A jeżeli chodzi o szukanie ofert pracy, to poza pracuj.pl, nofluffjobs i justjoin.it, ogarnij sobie workdaye firm do których byś chciał aplikować i monitoruj na bieżąco, ale niestety jest ciężko :)

Robisz "bezproblemowo" zadania z Angulara które konkretnie dostajesz na rekrutacjach i o ich pozytywnej ocenie nie dostajesz propozycji pracy?

https://github.com/mariuszbyahoo/TaskAssignementManager mówiłem o tym zadaniu, jeśli chcesz, przejrzyj, wypunktuj

1. Anemiczny model.
2. Generyczne repozytorium.. w dodatku ta nazwa :D
3. Twoje testy integracyjne w zasadzie nie są testami integracyjnymi.
4. Złe zależności na poziomie api-front.

Poczytaj o clean code, frontu nie sprawdzałem, bo dużo do poprawy jest na backendzie. Jaki feedback dostałeś po tym zadaniu?

@odebra: dzięki za info, poniżej odpowiedź którą dostałem, w niezmienionej formie:
Odnośnie Pańskiego wykonania ,, zadania rekrutacyjnego" to przygotował Pan w sposób bardzo profesjonalny jego prezentację, która spełniała założenia funkcjonalne.
Jednak od strony kodu zostało popełnionych kilka błędów.
Mocne strony kandydata, ocenione na plus:

-wykorzystanie .Net Core 3.1

-ciekawa i profesjonalna prezentacja projektu

• testy

• generyczne repo

• warstwa repo z generycznym interfejsem

• async/await

Zadanie:

• niepotrzebne komplikowanie logiki przy pobieraniu GetEntites (problem z Joinami)

-niepotrzebne nadużywanie SaveChangesAsync

-niepotrzebny strzał do backendu po taski przy tworzeniu nowej grupy (przez co lecą 404 w konsoli)

I teraz moje pytanie do Ciebie:
Jeśli testy integracyjne sprawdzające czy API zwraca spodziewany kod odpowiedzi + spodziewane response body nie są testami integracyjnymi (czyli że nie sprawdzają poprawności współdziałania komponentów aplikacji), czy możesz dać jakiś przykład testów integracyjnych które wg Ciebie nimi na prawdę są? Ogólnie, co waży w Twoim przypadku o tym że te testy to nie integracyjne?
Co jest źle z pomysłem na generyczne repozytorium?
A propos nazwy to innego pomysłu nie miałem, wiem, śmiszkowe takie xd No ale to jaka będzie lepsza? I od razu minusy mi dajesz za ICRUDRepo ? haahah No przecież dodaje edytuje usuwa i pobiera więc dla mnie schluss, nie wiem jaka nazwa byłaby odpowiedniejsza: "IRepositorable"? xDDD
Anemiczny czyli że słaby model (https://sjp.pl/anemiczny), przykro mi ale nie rozumiem, jaki będzie w tym przypadku mocny a co w tym który widziałeś było słabego?
Złe zależności na poziomie api-front : możesz mi wypunktować o które dokładnie zależności chodzi + co one robią źle?

Ze swojej perspektywy dodam, a szukam pracy jako junior czy jak zwał tak zwał od dobrego roku, że o ile w zeszłym kilka rekrutacji przeszedłem włącznie ze spotkaniem w firmie po technicznych zadaniach, tak w tym kiedy obecnie czuję się zdecydowanie mocniej i pewniej w tym fachu to niestety z ofertami jest dramat. Oczywiście wiadomo z czego to wynika, ale sam się już raczej pogodziłem z tym, że trzeba będzie poszukać czegoś innego bo ile można. Plus jest taki, że programowanie sprawia mi mnóstwo satysfakcji i w tym czasie stworzyłem swoją aplikację, którą zamierzam dalej rozwijać, a że być może nie będę tak zarabiał to cóż, życie. :)

<rant>

Sporo tutaj osób piszę anemiczne to, anemiczne tamto. Ja mógłbym powiedzieć DDD jest grube i spasione! a przepraszam puszyste.

Ja wolę się koncentrować na architekturze i to z niej powinno wynikać czy DDD/ES czy może DAO i transaction script. A sama architektura ma wynikać z wymagań!
A na poziomie architektury wygląda to tak (3 najpopularniejsze opcje, jest więcej):

1. Aplikacja 3 warstwowa Prezentacja <-> DTO <-> Service (business logic) <-> encje <-> Entity Framework
   Wrapowanie Entity Framework w generyczne repo nie ma najmniejszego sensu. Repozytorium to przede wszystkim interfejs z ładnie wyodrębnionymi metodami. Napisałem nawet kiedyś o tym posta: https://marcin-chwedczuk.github.io/repository-pattern-my-way

2. "Na Jemmiego Bogarta" CQS: Prezentacja -> Command -> cmd.execute() -> encje <-> Entity Framework i odczyt Prezentacja -> Query -> execute <-> Entity Framework+AsNoTracking lub mikroORM

3. Opcja atomowa: Hexagonal architecture + DDD. Tutaj waga ciężka, interfejsy repozytorium lądują w pakiecie domain. Implementacja w osobnym pakiecie infrastructure. Można dodać CQS/CQRS a więc:
   Prezentacja -> Command -> findAggregate -> aggregate.costam() -> saveAggregate. Agregaty w najcieższym wariancie nie są nawet świadome istnienia entity framework tylko wypluwają z siebie DTO które następnie warstwa infrastrucktury musi gdzieś zapisać, w tym wypadku agregaty odtwarzamy przez Aggregate.from(DTO). Ewentualnie event sourcing - czyli zapis odczyt strumienia eventow ze wsparciem wersjonowania.

</rant>

Najlepszą rade jaką mogę dać to jest ta książka: Adaptive Code via C# - pozycja dla początkujących, lekka i pouczająca.

@0xmarcin: patrząc na to co piszesz to nie wiesz do końca czym jest DDD. Stawiasz to w opozycji do event sourcingu czy też podejścia command-handler jak i piszesz że wolisz się skupić na architekturze która wynika z wymagań- znów, tak jakby to było w opozycji do stosowania (lub też nie) DDD. To samo się tyczy oddzielenia warstwy biznesowej/domenowej od infrastruktury- tu znów to czy stosujesz DDD czy też nie nie ma znaczenia. Poza tym opisujesz DDD czysto technicznie, tak jakby DDD to były tylko repozytoria i agregaty.

Jak by co, to całe repozytorium wzięło się dokładnie z kursu Gill'a Cleerena "Building ASP.NET Core aplications with ASP.NET Core MVC": moduł 5, video numer 6 "Demo: Creating the Real Repository"
jest tam pokazane jak robi sobie implementację interfejsu IPieRepository na którym dokładnie właśnie używa sobie DbContextu w metodach Get GetAll Update Delete & Create.
Albo ICategoryRepository gdzie implementacja tego interfejsu różni się wyłacznie dwoma - trzema linijkami LINQ-a od interfejsu samego w sobie...

@MarioMJR: To na przyszłość wiedz, że jeśli ktoś docenia generyczne repozytorium, to jest to lampka ostrzegawcza, że sam nie jest zbyt profesjonalny.
Pamiętaj, że mógł Cię oceniać junior, który ma 3 miesiące doświadczenia więcej niż Ty. Albo nawet junior, który ma 10 x rok doświadczenia.

Jeśli testy integracyjne sprawdzające czy API zwraca spodziewany kod odpowiedzi + spodziewane response body nie są testami integracyjnymi (czyli że nie sprawdzają poprawności współdziałania komponentów aplikacji), czy możesz dać jakiś przykład testów integracyjnych które wg Ciebie nimi na prawdę są? Ogólnie, co waży w Twoim przypadku o tym że te testy to nie integracyjne?

Czy te Twoje testy wysyłają żądania do faktycznie uruchomionej aplikacji? Jeśli tak, to są w porządku.

Co jest źle z pomysłem na generyczne repozytorium?

Jego całkowita zbędność. Kontekst EF jest sam z siebie generycznym repozytorium. Na dodatek lepszym od Twojego, bo niewykastrowanym z funkcji.
http://commitandrun.pl/2016/05/11/Repozytorium_najbardziej_niepotrzebny_wzorzec_projektowy/

A propos nazwy to innego pomysłu nie miałem, wiem, śmiszkowe takie xd No ale to jaka będzie lepsza? I od razu minusy mi dajesz za ICRUDRepo ? haahah No przecież dodaje edytuje usuwa i pobiera więc dla mnie schluss, nie wiem jaka nazwa byłaby odpowiedniejsza: "IRepositorable"? xDDD

Nazwa powinna oddawać to, do czego dany twór służy. Jeśli nie umiesz nazwać sensownie, to albo robi za wiele, albo jest zbędny.
W tym wypadku odpowiedź jest banalna, wystarczyłoby po prostu IGenericRepository.

Anemiczny czyli że słaby model (https://sjp.pl/anemiczny), przykro mi ale nie rozumiem, jaki będzie w tym przypadku mocny a co w tym który widziałeś było słabego?

Anemiczny, czyli nie posiadający zachowania, a jedynie przechowujący dane. To nie jest nic złego, o ile architektura aplikacji jest dostosowana do takiego podejścia.

somekind napisał(a):

@MarioMJR: To na przyszłość wiedz, że jeśli ktoś docenia generyczne repozytorium, to jest to lampka ostrzegawcza, że sam nie jest zbyt profesjonalny.
Pamiętaj, że mógł Cię oceniać junior, który ma 3 miesiące doświadczenia więcej niż Ty. Albo nawet junior, który ma 10 x rok doświadczenia.

Przykro mi to czytać i jeszcze gorzej... Się z tym zgodzić, no bo przecież słyszałem (czytałem tu na forum) o seniorach z dwu - trzy letnim doświadczeniem...

Czy te Twoje testy wysyłają żądania do faktycznie uruchomionej aplikacji? Jeśli tak, to są w porządku.

No tak, tylko że zamiast odpalać je poprzez TestExplorer to trzeba odpalić CMD: dotnet test i bangla.

Jego całkowita zbędność. Kontekst EF jest sam z siebie generycznym repozytorium. Na dodatek lepszym od Twojego, bo niewykastrowanym z funkcji.
http://commitandrun.pl/2016/05/11/Repozytorium_najbardziej_niepotrzebny_wzorzec_projektowy/

I teraz w zasadzie idea Repozytorium staje się dla mnie bardziej klarowna, jako że przybiera ono sensu w momencie gdy np. użyję Dapper'a (tak bynajmniej zrozumiałem)

Nazwa powinna oddawać to, do czego dany twór służy. Jeśli nie umiesz nazwać sensownie, to albo robi za wiele, albo jest zbędny.
W tym wypadku odpowiedź jest banalna, wystarczyłoby po prostu IGenericRepository.

Ok, przyznam że nawet się nie zastanawiałem nad nazwą tego interfejsu, dziękuję za podpowiedź

Anemiczny, czyli nie posiadający zachowania, a jedynie przechowujący dane. To nie jest nic złego, o ile architektura aplikacji jest dostosowana do takiego podejścia.

Od razu mówię z kąd wziął się ten Anemiczny model w praktyce, otóż mi ogólnie wygodniej od czasu gdzie zobaczyłem takie podejście chyba nawet u Julie Lerman na jednym z jej kursów że robiła oddzielnie projekt Web, Data i Domain, w Domain były właśnie powrzucane modele danych, które tylko modelowały encję na potrzeby EF i nic poza tym, mi się to bardzo spodobało bo nie lubię jak mam naćkane pełno rzeczy np. w projekcie Web, tak żeby tam był i kontekst i encje i jeszcze startup program i kontrolerya no i migracje i bóg wie co. Wydaje mi się to bardziej klarowne, przejrzyste i nie muszę grzebać w przeróżnych folderach tylko mam biblioteki i projekt webowy, ew. w przypadku zabawy z NG to mam jeszcze folder ClientApp w projekcie Web. Jak uważasz, to właściwe podejście?

w Domain były właśnie powrzucane modele danych, które tylko modelowały encję na potrzeby EF i nic poza tym

Problem z tutorialami i takimi example project jest taki ze one generalnie nie mają żadnej domeny ani logiki biznesowej. Są po prostu takim CRUDem/nakładką na bazę danych. I w takiej sytuacji pojawiaja się takie śmieszne, niespotykane w prawdziwym życiu, kwiatki jak model DTO wchodzących/wychodzących z systemu identyczny z modelem "obiektów domenowych" (które w ogóle nie mają żadnej logiki ani zachowania) i identyczny z modelem danych. I do tego jeszcze mappery w obie strony na każdym poziomie. W praktyce te wszystkie modele będą do siebie zupełnie niepodobne, ale trudno na CRUDowym przykładzie to pokazać.

MarioMJR napisał(a):

Przykro mi to czytać i jeszcze gorzej... Się z tym zgodzić, no bo przecież słyszałem (czytałem tu na forum) o seniorach z dwu - trzy letnim doświadczeniem...

Ale co o nich tutaj czytałeś? Bo na pewno nic dobrego.

I teraz w zasadzie idea Repozytorium staje się dla mnie bardziej klarowna, jako że przybiera ono sensu w momencie gdy np. użyję Dapper'a (tak bynajmniej zrozumiałem)

Zrozumieć mogłeś przynajmniej, ale skoro bynajmniej, to znaczy, że nie zrozumiałeś. To nie o to chodzi, co masz pod spodem, tylko o to architekturę. Jeśli nie masz DDD, to nie masz repozytoriów. Nie wystarczy nazwać klasy, aby stała się czymś.

Od razu mówię z kąd wziął się ten Anemiczny model w praktyce, otóż mi ogólnie wygodniej od czasu gdzie zobaczyłem takie podejście chyba nawet u Julie Lerman na jednym z jej kursów że robiła oddzielnie projekt Web, Data i Domain, w Domain były właśnie powrzucane modele danych, które tylko modelowały encję na potrzeby EF i nic poza tym, mi się to bardzo spodobało bo nie lubię jak mam naćkane pełno rzeczy np. w projekcie Web, tak żeby tam był i kontekst i encje i jeszcze startup program i kontrolerya no i migracje i bóg wie co. Wydaje mi się to bardziej klarowne, przejrzyste i nie muszę grzebać w przeróżnych folderach tylko mam biblioteki i projekt webowy, ew. w przypadku zabawy z NG to mam jeszcze folder ClientApp w projekcie Web. Jak uważasz, to właściwe podejście?

Nikt nie mówi, żeby nie dzielić na projekty i katalogi. Po prostu "Domain" to nie są obiekty opisujące strukturę przechowywania danych w bazie, ale to co Twoja aplikacja robi. Miejsce przechowywania to mniej istotny detal.
I też nie twierdzę, że anemiczny model jest z definicji zły, można go rozsądnie używać w niezbyt wielkich projektach z prostą logiką biznesową. Do crudów jest wystarczający.

Shalom napisał(a):

takie śmieszne, niespotykane w prawdziwym życiu, kwiatki jak model DTO wchodzących/wychodzących z systemu identyczny z modelem "obiektów domenowych" (które w ogóle nie mają żadnej logiki ani zachowania) i identyczny z modele danych.

Ta, niespotykane. :P

Muszę przyznać że nie spodziewałem się bogatej dyskusji z której się czegoś nauczę :)
W każdym razie, przypomniałem sobie książkę którą kupiłem rok temu gdy nawet nie rozumiałem co czytam, to ją odłożyłem na półkę, tzn Eric Evans "Domain-Driven Design" myślę że to dobry pomysł się w niej zanurzyć na jakiś czas.