Staż Java - co wybrać?

Cześć,
dostałem się na staż programistyczny do pewnej firmy. Chcą mnie uczyć od zera, choć wymagają oczywiście poświęceniu się nauce również w domu. Dostałem propozycję wyboru dwóch następujących dziedzin, wraz z technologiami z nimi związanymi:

• Android (bez Kotlina)
• Spring (Hibernate, Angular 6)

Mam ogólnie zagwozdkę, ponieważ nie mam pojęcia, która z nich bardziej mi się spodoba, a wyboru mogę dokonać tylko raz. Nie mam na tyle czasu, aby uczyć się jednocześnie dwóch, aby za miesiąc, dwa podjąć decyzję.
Jeśli mogę powiedzieć coś od siebie - nie mam zmysłu artystycznego, wolałbym działać bardziej w backendzie, choć we froncie też coś zrobię, jeśli zajdzie taka potrzeba. Do tego bardzo podobają mi się bazy danych. Przy wyborze chciałbym się kierować przede wszystkim rynkiem pracy, który będzie za kilka lat. Chciałbym poznać wasze opinie oraz argumenty, co wy byście zrobili na moim miejscu, na jakie aspekty byście patrzyli.
Pozdrawiam i z góry bardzo dziękuję!

No cóż. Nikt za Ciebie decyzji nie podejmie. ¯_(ツ)_/¯

wiciu napisał(a):

No cóż. Nikt za Ciebie decyzji nie podejmie. ¯_(ツ)_/¯

Nikt jej nie ma podejmować. Chciałbym tylko poznać opinie, jakieś pozytywne i negatywne cechy każdej dziedziny :)

Android bez Kotlina i babranie się w Javie 6? To trochę zacofane.

Ja bym wziął Springa bo łatwiej o pracę (no webówka to jakies 80% rynku). Java Developer :)

Jest więcej pracy przy webowych rzeczach niż stricte przy androidzie, poza tym jak zdobędziesz jakieś doświadczenie to możesz skakać sobie w stronę ciekawszych (albo przynajmniej mniej kobylastych) technologii niż Spring - w androidowych mobilkach masz o wiele mniej różnorodny rynek. Dodatkowo masz szansę na ciekawsze (chociaż to zależy od preferencji) problemy niż spotykasz we frontendzie (czy to mobile czy web) - sterowanie główną logiką biznesową, obsługę dużej ilości zapytań, problemy związane z systemami rozproszonymi, inne tego typu rzeczy.

Taka decyzja to nie wyrok. Sam pracowałem trochę w Springu i trochę w Androidzie. Generalnie, najważniejsze żeby opanować solidne fundamenty Javy jako takiej. Potem będzie to tylko kwestia douczenia się jakiegoś frameworka lub biblioteki. Zarówno Spring jak i Android, to po prostu frameworki napisane w Javie. W apkach mobilnych masz trochę inne wyzwania, niż w apkach webowych. Moim zdaniem, obie rzeczy są ok. Jeśli chodzi o rynek pracy, to obiektywnie rzecz biorąc, jest więcej ofert dla programistów apek webowych, niż mobilnych (przynajmniej w Polsce).

Samsung ponoć coś mocno kombinuje z własnym OSem, więc niedługo Android może być takim bieda-systemem dla telefonów "mniej-markowych".

nobody napisał(a):

Samsung ponoć coś mocno kombinuje z własnym OSem, więc niedługo Android może być takim bieda-systemem dla telefonów "mniej-markowych".

Samsung od dawna kombinował ze swoim OSem. Nazywał się Tizen, tylko nie miał wystarczającej siły przebicia, bo nie oferował niczego więcej, niż np. Android i miał toporne API w C++. Teraz chyba żaden telefon tego nie ma (włącznie z telefonami Samsunga). Nie twierdzę, że Android będzie istniał wiecznie, ale na ten moment bardzo trudno będzie go wygryźć z rynku. W zasadzie rynek OSów mobilnych jest zdominowany przez iOS i Android, które dzielą się nim mniej więcej po połowie. Poza tym, Android jest rozwijany przez Google i takiego np. Pixela nie nazwałbym "bieda-telefonem z bieda-systemem".

jak Google wprowadzi system FuchsiaOS, skończy się dominacja Javy. A w Tizenie i WebOS od LG piszę się aplikacje w C++17.

Google wprowadza nowe wersje Androida a ich udział w rynku to pojedyncze procenty, najnowszej to promile.

Google i Microsoft wprowadzają/wprowadzali co chcieli a producenci hardware i tak zrobili swoje.

Androida bardzo łatwo się samemu nauczyć, bierz springa

@grind: @Grzyboo w sumie prawde powiedział. Spring i Webówka to bardziej zaawansowane tematy, łatwiej Androida się samemu nauczyć. Pamiętaj że ze Springiem dojdą bazy danych, może jeszcze komunikacja po jakiś kolejkach, a Android to bardziej klient "końcowy" gdzie jak już to ew. łączyć się ze springowym (czy innym) API.

wiciu napisał(a):

Pixela nie nazwałbym "bieda-telefonem z bieda-systemem".
To coś w ogóle wyszło na rynek? To ja juz chyba więcej "marek" telefonów z biedonki znam...

Nie ma sensu tworzyc nowego systemu na mobile, to tak jakby podcierac sie rozowym papierem zamiast bialym bo jest ładniejszy!!!

Ja bym się bardziej kierował tym co chcesz w przyszłości robić. Jeżeli wybierzesz backend bo jest w tym więcej ofert/kasy a niekoniecznie chcesz to robić to za jakiś czas pewnie pożałujesz wyboru. Tak samo z androidem.

scibi92 napisał(a):

Ja bym wziął Springa bo łatwiej o pracę (no webówka to jakies 80% rynku).

Webówka to więcej ofert, ale i więcej programistów. Web developerzy są znacznie liczniejsi niż androidowcy. Rozpatrywanie jednego w oderwaniu od drugiego jest pozbawione sensu. Liczy się proporcja popytu i podaży, a nie tylko sam popyt.

V-2 napisał(a):

scibi92 napisał(a):

Ja bym wziął Springa bo łatwiej o pracę (no webówka to jakies 80% rynku).

Webówka to więcej ofert, ale i więcej programistów. Web developerzy są znacznie liczniejsi niż androidowcy. Rozpatrywanie jednego w oderwaniu od drugiego jest pozbawione sensu. Liczy się proporcja popytu i podaży, a nie tylko sam popyt.

Nieprawda. Nie tylko proporcje. Powiedzmy ze masz 10000 miejsc na A i 10 000 pracownikow + 1 ty bez pracy. Masz wtedy wieksze prawdopodobienstwo ze ktos z tych 10 000 opadnie z roznych powodow i zrobi sie wtedy miejsce dla ciebie niz w sytuacji gdy jest 10 stanowisk i 10 pracownikow + ty

Skromny Szewc napisał(a):

V-2 napisał(a):

scibi92 napisał(a):

Ja bym wziął Springa bo łatwiej o pracę (no webówka to jakies 80% rynku).

Webówka to więcej ofert, ale i więcej programistów. Web developerzy są znacznie liczniejsi niż androidowcy. Rozpatrywanie jednego w oderwaniu od drugiego jest pozbawione sensu. Liczy się proporcja popytu i podaży, a nie tylko sam popyt.

Nieprawda. Nie tylko proporcje. Powiedzmy ze masz 10000 miejsc na A i 10 000 pracownikow + 1 ty bez pracy. Masz wtedy wieksze prawdopodobienstwo ze ktos z tych 10 000 opadnie z roznych powodow i zrobi sie wtedy miejsce dla ciebie niz w sytuacji gdy jest 10 stanowisk i 10 pracownikow + ty

Trochę już zapomniałem matematyki z zakresu szkoły podstawowej, ale coś mi mówi, że 10 miejsc na 11 kandydatów to nie jest taka sama proporcja popytu i podaży, co 10000 miejsc na 10001 kandydatów.

Mean culpa. Chodzilo mi o miejsca pracy. Wiadomo ze w springu latwiej. Lepiej rywalizowac z 1 000 na 1 miejsce niz miec brak jakichkolwiek miejsc w przypadku tych 10 na 20 lat

Skromny Szewc napisał(a):

Mean culpa. Chodzilo mi o miejsca pracy. Wiadomo ze w springu latwiej. Lepiej rywalizowac z 1 000 na 1 miejsce niz miec brak jakichkolwiek miejsc w przypadku tych 10 na 20 lat

A o czym ja mówię, jeśli nie o miejscach pracy? Podaż to liczba miejsc pracy, a popyt to liczba kandydatów szukających pracy. Stwierdziłeś, że "proporcje to nie wszystko", a jako dowód podałeś... porównanie rynku wysyconego w 110% (11/10) i rynku wysyconego w 100.01% :) Czyli właśnie o zasadniczo różnych proporcjach.

Oczywiście, że na większym rynku panuje większa rotacja, ale znosi się to z faktem, że (w tym uproszczonym modelu) przy większej rotacji przy każdej rekrutacji będziesz "wyciągany" spośród większej puli kandydatów, czyli statystycznie będziesz musiał dłużej poczekać, aż znajdzie się dla ciebie krzesło (odbyć większą liczbę rekrutacji).

Używasz przy tym przykładów karykaturalnie wyostrzonych, bo różnica między wielkością rynków, o których mówimy, nie jest tysiąckrotna, a "20 lat" z uprzejmości przemilczę

Nieprawda. To zalezy od twojego poziomu. Jak jestes dobry to lepiej miec szanse sie dostac gdzies bo zwolnilo sie miejsce z tych 10 000 - co by sie zdarzalo stosunkowo czesto niz byc zajebiscie dobrym i takiej szansy w ogole nie miec przez bardzo dlugi okres czasu, bo nie ma zadnej rotacji dla sytuacji 10/10. Ta druga sytuacji jest lepsza tylko dla kogos kto jest na tyle slaby, aby sie nie mial zadnych szans wygrac z kandydatami, a mialby takich szans sporo. Dla niego jedyna szansa to wlasnie poczekac te 20 lat az ktos sie zwolni z tych 10 obecnie pracujacych

Skromny Szewc napisał(a):

Nieprawda. To zalezy od twojego poziomu.

To jest już inny argument niż ten, ktory podałeś na początku (i który był w oczywisty sposób błędny).

Oczywiście, że wynik rekrutacji zawsze zależy od twojego poziomu.

Na potrzeby zrozumienia, jakie jest działanie proporcji, nie trzeba w ogóle brać pod uwagę tego czynnika - można założyć dla uproszczenia, że wszyscy kandydaci mają taki sam poziom, a rekrutacja jest kompletnie losowa.

Natomiast jeśli twój poziom to 90 centyl, czyli jesteś lepszy od 9 na 10 kandydatów, to kiedy o miejsce stara się 10 kandydatów, statystycznie 1 będzie lepszy od ciebie, a jeśli stara się 100, to średnio 10 będzie lepszych od ciebie, czyli statystycznie będziesz potrzebować większej liczby "rozgrywek", żeby w końcu zająć pierwsze miejsce.

Nie do konca jest to po rowno. Im jestes lepszy tym lepiej aby miejsc pracy bylo wiecej i wiecej kandydatow od ktorych tak jestes lepszy niz malo kandydatow I malo miejsc pracy. Jestes najlepszy I przy pierwszej sytuacji czekasz miesiac a przy drugiej 20 lat

Proponuję, żebyś obkodował sobie to jako symulację. Teraz wiem, jak czuła się Marilyn vos Savant.

kasa -> spring
fun -> android

chociaż w androidzie nie robiłem to domyślam się że jest to przyjemniejsze niż hardkorowy backend :D

A to Google nie przeszło teraz na Kotlina pod Androidem? Z tego co wiem Android zatrzymał się na Javie 8.

V-2 napisał(a):

Proponuję, żebyś obkodował sobie to jako symulację. Teraz wiem, jak czuła się Marilyn vos Savant.

Hehe, jak ty pewnie. Zalozmy ze w A jest 10 000/10 000 w B 10/10. Czestosc nowych stanowisk wprost proporcjalna do wielkosci. Zalozmy omega1=x1=10 000 I omega2=x2= 10. Liczba kandydatow tez pproporcjonalna I dla uptoszczenia
obliczen rowna liczbie stanowisk. Czas trwania na wolne miejsce (dokladniej sredni odstep pomiedzy wolnymi stanowiskami) to odwotnosc czestosci. Zalozmy ten 90%. Czyli w sytuacji pierwszej czekasz 1001 prob bo 10 procent z 10 000 jest lepszych od cievlbie czyli 1001T1=10011/10 000 z kolei w drugim przypadku czekasz 2 razy bo 10 procent z 10 jest od ciebie lepsza a wiec czekasz w sumie 2*1/10. A wiec 1001/10000 <2/10 czekasz mniej prawie 2 razy.