Projekt z JAVY na miarę inżynierki.

Cześć! Od roku pracuję jako c++ dev, w lutym 2021 będę bronił tytuł inżyniera. Po obronie chciałbym zacząć pracę jako JAVA dev (pewnie zmienię projekt lub firmę). Na chwilę obecną posiadam całkiem solidne podstawy Javy, bo oprócz wiedzy ze studiów zdarzyło mi się coś domergowawć do repozytoriów Javowych w naszym produkcie, a więc kod komercyjny w Javie też nie jest mi obcy.

Przez najbliższe kilka miesięcy chciałbym zająć się pisaniem pracy inżynierskiej, natomiast mój problem tkwi w doborze technologii i tematu. Mianowicie, chciałbym napisać coś fajnego, dużego i ambitnego, a przede wszystkim takiego abym mógł relatywnie gładko wejść w nowy projekt Javowy bez problemów.

Oprócz Javy samej w sobie sądzę, że must-have w tym projekcie będzie Spring. Zastanawiałem się nad jakąś apką, gdzie też pojawi się JavaScript i do tego opakować to w React. A może Angular? Vue? Doradźcie mi proszę, co teraz jest gorące na rynku i czego warto się teraz nauczyć. Będę też wdzięczny jeżeli nakierujecie mnie na jakiś temat, w którym możnaby zrealizować taki stack technologiczny np. Java + Spring + JS + React. We własnym zakresie oczywiście wdrożę też jakieś narzędzia DevOpsowe.

@admin
Zadaję te pytanie tutaj, a nie w dziale edukacja, gdyż sądzę, że tu częściej zaglądają spece od Javy, jeśli się pomyliłem to proszę przenieś. Dzięki.

Jak chcesz fajnie, ambitnie to słowo Spring jest tu w sprzeczności.
Taką prozę to będziesz miał w pracy, ja popieram, że chcesz wyjść ponad pańszczyznę.

Może serwery nie-servletowe? Jakiś Ratpack, te klimaty?

Nie wiele mi to mówi, z twojego postu wnioskuję, że nie powinienem uczyć się Springa tylko iść w zagadnienia serwerowe. A co z innymi technologiami, które wymieniłem w pierwszym poście? @AnyKtokolwiek rozwiń proszę :)

Dobierasz temat do technologii czy technologie do tematu? :)

@Charles_Ray: Sęk w tym, że nie mam jeszcze ani tematu ani dokładnie sprecyzowanych technologii. Najpierw chciałbym wybrać ciekawy i sensowny stack technologiczny, a następnie temat.

sucioguapo napisał(a):

Nie wiele mi to mówi, z twojego postu wnioskuję, że nie powinienem uczyć się Springa tylko iść w zagadnienia serwerowe. A co z innymi technologiami, które wymieniłem w pierwszym poście? @AnyKtokolwiek rozwiń proszę :)

Jak architekt rysował mi dom, pozwoliłem mu użyć jego talentów i miał dużo do powiedzenia (dom wyszedł z tych prostych, ale nie starzejących się).
Zapytałem o inne projekty, jak klient każe tu zrobić wielkie okno, tu "gotycką" wieżyczkę, tu fizdrygiełko itd... Odpowiedział: Rzygam i rysuję

Springa pewnie będziesz musiał, taka jest średnia branży, ale czy szukać w tym przyjemności???

@AnyKtokolwiek: Chciałbym wejść dobrze w pozycję Java dev z C++ dev, jeżeli trzeba będzie nauczyć się czegoś co jest nieprzyjemne, ale konieczne, to trudno, spłacę ten dług technologiczny :D Natomiast to dalej mnie nie przybliża do meritum sprawy.

Spring nie jest technologią dedykowaną do jakiegoś konkretnego tematu tylko technologią ogólną. Każdą aplikację którą można zrobić w Javie, można zrobić z użyciem Springa i bez użycia Springa.

Mogę Ci pomoc ewentualnie wybrać temat, który bardziej pasuje do Javy ze Springiem (rozumiem, że najważniejszy jest aspekt nauki technologii, a nie odkrywanie nowej galaktyki), natomiast to Ty powinieneś wykonać proces myślowy i coś zaproponować. W przeciwnym przypadki to trochę jak pytanie „co mam w życiu robić?”

@Charles_Ray: Wstępnie myślałem o czymś takim, żeby zrobić serwis webowy do rozpoznawania ludzi, coś w stylu takiej aplikacji inwigilacyjnej. Nie chodzi o samo rozpoznawanie twarzy, ale też detekcja kształtów, np jeśli nie da się rozpoznać osobnika po twarzy to weryfikacja, że jest to na przykład mężczyzna w wieku 30-35 lat i aktualnie w bazie znajduje się takich x osób do których ten opis pasuje, chociaż twarz nie zgadza się. Może sama apka nie brzmi super, ale można tutaj wykazać się nie tylko samą Javą ale także bazami danych (być może nawet mikroserwisami jeśli bazę gdzieś w chmurze postawić albo skorzystać z jakiegoś api do face recgonition). Poza tym możnaby też tu pobawić się troszkę w webówkę, a może nawet bardziej taki full-stack jeśli dołożyć do tego jakiś JS framework. Brzmi rozsądnie?

Jeśli dobrze rozumiem co chcesz zrobić, to cześć Javowa będzie przelotką do modelu ML i bazy. Brzmi spoko, tylko: skąd weźmiesz zdjęcie twarzy i co najważniejsze - jak wytrenujesz i zdeplojujesz model?

@Charles_Ray: Do bazy wgrałbym z 10 - 15 zdjęć na których są ludzie, można takie zdjęcia użyć z internetu pod warunkiem odpowiedniej licencji. Wytrenowanie i deployowanie modelu to największy problem, najpewniej część bym zaimplementował, a w części bym skorzystał z jakiegoś gotowego chmurowego serwisu. Tak jak wcześniej wspominałem bardziej chciałbym poznać nowe technologie i lepiej się obyć z Javą niż komplikować to implementacyjnie, więc jeśli tylko to co sobie wymyśliłem na sens to pochylę się nad tym bardziej.

Dla mnie to jest projekt stricte ML-owy z dodatkiem małej aplikacji Javowej, która obsługuje żądania użytkowników i jest klientem tego modelu. Brzmi fajnie, natomiast 90% czasu zajęłoby mi ogarnięcie tego modelu, chociaż może są jakieś gotowce/tutoriale oparte o TensorFlow (nie znam się). Może zastanów się jak wyeliminować te cześć ML-ową pozostając w tematyce. Masz bazę zdjęć, co dalej?

@Charles_Ray: w następnych krokach pewnie myślałbym o rozbudowaniu części Javowej, może jakiś serwer postawić, rejestrację użytkowników serwisu, zlecenie takich skanów, czyli jakiś system rezerwacji ... W zasadzie sky is the limit jak tak dłuższą chwilę się nad tym zastanawiam.

To może jakaś aplikacja z możliwością logowania się takim „Face ID”? Sam proces logowania mógłby być tematem pracy

To tak naprawdę powstaje CRUD jak każdy inny: zarejestruj, zaloguj, złóż zlecenie

Charles_Ray napisał(a):

To może jakaś aplikacja z możliwością logowania się takim „Face ID”? Sam proces logowania mógłby być tematem pracy

to brzmi fajnie!

@Charles_Ray: Samo logowawnie Face ID brzmi bardzo fajnie! Tylko pytanie co po tym jak już się twarzą zalogujemy, jakiś serwis też pod spodem bym chciał mieć, ale to nie problem, tutaj pomysłów może być milion. Okej to mam już jakiś zarys, w którą stronę iść. A jak do takiego właśnie projektu dobrać stack technologiczny aby był ciekawy? :)

Co to znaczy ciekawy? Jeśli chcesz poznać „średnią rynkową”, to ciśniesz Spring/JPA w tej apce. Bardziej ambitnie to już na każdej warstwie praktycznie możesz eksperymentować - od bazy danych (np. NoSQL jakiś), przez kod (vavry, RxJavy, webfluksy, ratpacki, micronauty) po frontend (Vue, Reacty, Angulary) - onanizm techniczny na całego. Jak zrobisz moduł do uwierzytelniania, to chronionym zasobem może być cokolwiek, np. dane konta - to nie jest clue problemu.

Po roku pracy komercyjnej powinieneś już wiedzieć (co najmniej z opowieści kolegów z pracy) że wybieranie najpierw rozwiązań a dopiero potem problemów to proszenie się o większe problemy i powody do frustracji, których dałoby się uniknąć ;)

Jak chcesz zrobić ambitną inżynierkę, to nie ładuj się w pisanie wielkiego (bo jak ambitne, to musi być duże) enterprise projektu w enterprise frameworkach w enterprise językach:

w następnych krokach pewnie myślałbym o rozbudowaniu części Javowej, może jakiś serwer postawić, rejestrację użytkowników serwisu, zlecenie takich skanów, czyli jakiś system rezerwacji ... W zasadzie sky is the limit jak tak dłuższą chwilę się nad tym zastanawiam.

Nie warto się bawić w sky is the limit, serio. Będziesz dokładał sobie tony takiej małpiej roboty - bo muszę dołożyć entitkę, a do niej repository, a do tego serwis... i tak dalej z tą cebulą / lasagne, a efekt końcowy będzie taki, że całe mięcho jakie miało być w tej pracy zagubi się w wielkiej górze Springowych kartofli. Przepraszam - beanów. Albo nie Springowych, tylko jakichś innych. Obojętnie.

Zrób tyle, żeby aplikacja pozwalała w miarę przystępnie dobrać się do mięcha pracy i żeby to mięcho było wyeksponowane, przykuwało uwagę i wołało "zjedz mnie!" - i zrób to po prostu jak należy ;)

Moim zdaniem popełniasz błąd już w miejscu, w którym stwierdzasz, że twoja praca inżynierska ma być ambitna, obszerna w dodatku napisana w technologiach enterprise, których nie znasz. Coś takiego ci w życiu nie wypali. Polecam ci odróżnić te dwie rzeczy - pisanie pracy inżynierskiej oraz zmiana pracy. Do inżynierki możesz podejść na dwa sposoby - chcesz mieć fajną i pewną inżynierkę - wybierz technologię, którą znasz. Po prostu jak pracowałeś w tym c++ to możesz napisać ambitną inżynierkę w c++. Język to tylko narzędzie.

Druga opcja to jest ryzyko czyli pójście w nieznaną ci (dotąd) technologię + ambitny temat. Nie łudź się, że masz dużo czasu. Każdy kto wybierał tą opcję pluł sobie potem w brodę. Termin zacznie się zbliżać, pojawią się nieoczekiwane błędy, coś nie działa do końca, temat ambitny i nie ma za bardzo kto pomóc, w dodatku technologia niszowa. Prosta metoda na stworzenie klapy.
Po prostu ambitna inżynierka w nieznanej technologii - to nie jest droga dla każdego. Zależy wszystko od tego jaki masz charakter. Jeżeli masz problemy z organizacją, prokrastynacją itd to może być ciężko. I dolicz sobie bardzo istotny aspekt - jeżeli teraz pracujesz na etacie spędzasz 8 godzin przed komputerem praktycznie codziennie. W weekendy pewnie masz uczelnie? Pisanie pracy inżynierskiej to raczej kilka miesięcy, a nie jeden weekend. Po 8 godzinach z jednego kodu do drugiego - przez kilka dni, tygodni będzie ci łatwo, ale w końcu zacznie cię to frustrować. Siedzenie przy kompie po 12-14 godzin to prosta sprawa, pod warunkiem, że nie robisz tego codziennie i wszystko ci wychodzi. Ale jak będziesz się czegoś uczył pierwszy raz i codziennie 4-6 godzin po pracy wkuwania i jeszcze coś ci nie wychodzi - mózg ma swoje limity. Może skończyć się tak, że w rezultacie inżynierkę zrobisz na odpie***l bo nie wytrzymasz psychicznie presji. Do tego zaliczaj inne przedmioty ze studiów, nie każdy profesorek poluzuje ci na ostatnim semestrze, niektórzy dalej będą robić wymagające kolokwia, nie obchodzi ich twoja inżynierka :)

Moim zdaniem najgorsze co możesz zrobić to pisać inżynierkę pod pracodawcę jak CV. Przecież nawet jak zrobisz ciekawą pracę inżynierską w pythonie z machine learningiem, a zaaplikujesz na stanowisko Javy to nic się nie stanie. Będziesz mógł się pochwalić tą inżynierką i potem na rozmowie to sensownie uargumentować, że chcesz pracować w Javie, bo widzisz się w Javie, a inżynierkę napisałeś w pythonie, bo jarał cię temat i zawsze chciałeś coś takiego zrobić, do niego dobrałeś technologię. Takim podejściem zyskasz uznanie w oczach pracodawcy. Bo pamiętaj, że w pracy programisty nie chodzi o pisanie kodu, tylko o rozwiązywanie problemów. Jak można użyć automatycznej koparki to nie ma sensu brać łopatę, taczkę i ręcznie kopać. Nie musisz konkretnie brać nudne i komercyjne frameworki do inżynierki, żeby jednocześnie zaimponować pracodawcy. Najważniejsze, żeby temat pracy cię jarał, a wybór narzędzia to inna sprawa.

@CoderOne: Wow, dzięki za bardzo rzeczową odpowiedź :)
To o czym wspominasz to jest drugie podejście, które gdzieś tam z tyłu głowy się ze mną kłóci, mianowicie jestem świadom tego, że mam już taką wiedzę, że bez problemu stworzę coś ciekawego w technologiach już mi znanych. Być może masz i rację, że powinienem oddzielić pracę inżynierską od zmiany pracy/technologii. Boję się tylko, że nie starczy mi czasu jednocześnie na pracę na etacie 8h (pod warunkiem, że jenkins zielony :D), studia dzienne, pisanie pracy inżynierskiej oraz samodzielną naukę nowych technologii - po prostu zastanawiam się czy da się upiec dwie pieczenie na jednym ogniu. Inna sprawa, że możesz mieć rację - nie koniecznie jest to dobry pomysł. Wiadomo, że język to tylko narzędzie, jak mi ktoś kiedyś powiedział "najmniej istotna część programowania to pisanie kodu" :D Natomiast mam obawy, że bez solidnego portfolio HR-ka wyrzuci CV, różnie z tym bywa. Na chwilę obecną spróbuję się pobawić w kontrybucje do jakiś Javowych projektów open-source :)

@superdurszlak
Trochę mnie sprowadziłeś na ziemie, ale trudno się z tobą nie zgodzić :)

@Charles_Ray
Widzę, że są różne opinie na temat Springa, zacznę się silniej kształcić w tym zakresie bo chciałbym wiedzieć jak to faktycznie jest