Technologia na „nowy czas”

Witajcie.
Programuje w PHP od jakiegoś czasu. Zastanawiam się nad nauką czegoś nowego (żeby mieć jakąś alternatywę gdyby coś). Po koronawirusie nie wiadomo jak będzie wyglądał rynek phpowy i chciałbym się w jakiś sposób „zabezpieczyć”. Chciałbym też zwiększyć swoje ewentualne zarobki. Bawiłem się ostatnio Pythonem - podoba mi się, ale ofert pracy jest stosunkowo mało. Rozkminiam też Node i wydaje mi się bardzo spoko. Trochę składnia „dziwna” (js), ale też mi się podoba. Znajomi polecają mi c#/ASP .net - jako uniwersalne środowisko i stosunkowo duża ilość ofert. Nie jestem jednak do tego przekonany - wydaje mi się rynek .net bardzo „zatkanym”.

Jakie są Wasze sugestie w tej kwestii? :)

Java albo C#, ale do tego musisz się nauczyć wielu wzorców projektowych, DDD, UML, i tym podobnych. Jak już będziesz w tym wszystkim biegły to na luzie 15k+ netto / miesięcznie, a za granicą o wiele więcej.

Jeżeli coś jeszcze bardziej ambitnego to A.I. w powiązaniu np. z biologią molekularną / cybernetyką / automatyką / eksploracją kosmosu. Świat potrzebuje geniuszy aby np. jak najszybciej zacząć wydobywać minerały z asteroid, albo dokonać innych przełomowych rzeczy.

TomRZ napisał(a):

UML

prawie od 20 lat w tym zawodzie, a UMLa widziałem jedynie na studiach...

abrakadaber napisał(a):

prawie od 20 lat w tym zawodzie, a UMLa widziałem jedynie na studiach...

Są w PL tacy, którzy namiętnie modelują w praktyce, i dobrze na tym wychodzą. Na przykład p. Jarosław Żeliński, napisał nawet o tym książkę: https://helion.pl/autorzy/jaroslaw-zelinski

Wiesz jak fajnie cały algorytm widzieć w UML zamiast grzebać po kodzie? To się opłaca, chociaż wymaga pracy.

TomRZ napisał(a):

DDD

Programuję zawodowo od 8 lat i DDD widzialem tylko w książkach i na konferencjach

KamilAdam napisał(a):

DDD

Programuję zawodowo od 8 lat i DDD widzialem tylko w książkach i na konferencjach

Ja mam inaczej, programuję zawodowo od ponad 20 lat, i pewne elementy DDD od wielu lat stosuje: encje, usługi, agregaty, fabryki, value object. Tylko repozytoria wolę realizować przez active record, w sensie, że encja to active record, więc tak do końca nie jest encją w sensie DDD, u mnie jest to tutaj akurat trochę pomieszane.

Czyli Waszym zdaniem „bezpieczna przystań” to bardziej c#/ASP .net niż Node? :)

TomRZ napisał(a):

abrakadaber napisał(a):

Są w PL tacy, którzy namiętnie modelują w praktyce, i dobrze na tym wychodzą. Na przykład p. Jarosław Żeliński, napisał nawet o tym książkę: https://helion.pl/autorzy/jaroslaw-zelinski

Wiesz jak fajnie cały algorytm widzieć w UML zamiast grzebać po kodzie? To się opłaca, chociaż wymaga pracy.

Napisac książkę na pewno się opłaca - praktyce.

Ale poza tym to sa bzdury. Ale można na jakiś czas zając część bezużytecznych i przeszkadzających ludzi z biznesu zając rysowaniem ludzików - tylko trzeba pilnować, żeby Ci użyteczni tez w tym nie utkwili.
Raz na jakiś czas jakiś diagram można te dla ludzi narysowac - ważne, żeby OSTENTACYJNIE nie był on w UML, bo zespół zacznie tracić czas na dyskusję czy rombik zamalowany czy nie i mamy przegrane.

Ogólnie problem z diagramiami polega na tym, że w wiekszości nie pozwalają na duży poziom abstrakcji.

@jarekr000000:

Ogólnie problem z diagramiami polega na tym, że w wiekszości nie pozwalają na duży poziom abstrakcji.

Myślałem, że właśnie odwrotnie. Co pozwala na większy poziom abstrakcji?

Silv napisał(a):

@jarekr000000:

Ogólnie problem z diagramiami polega na tym, że w wiekszości nie pozwalają na duży poziom abstrakcji.

Myślałem, że właśnie odwrotnie. Co pozwala na większy poziom abstrakcji?

OK. Też diagramy, ale nie UML, tylko te od Bartosza Milewskiego.

Ukradzione z https://bartoszmilewski.com/2014/12/23/kleisli-categories/

Nie rozumiem. Mogę się domyślać… Spojrzałem na źródło, ale tam o tym rysunku nie widzę informacji (nie czytałem całego artykułu co prawda). Czy chodzi Ci o to, że diagramy powinny mieć jakieś znaczenie dla tych, którzy je czytają, a diagramy UML zazwyczaj nie znaczą dla nich zbyt dużo z uwagi na swoją ogólność?

jarekr000000 napisał(a):

TomRZ napisał(a):

abrakadaber napisał(a):

Są w PL tacy, którzy namiętnie modelują w praktyce, i dobrze na tym wychodzą. Na przykład p. Jarosław Żeliński, napisał nawet o tym książkę: https://helion.pl/autorzy/jaroslaw-zelinski

Wiesz jak fajnie cały algorytm widzieć w UML zamiast grzebać po kodzie? To się opłaca, chociaż wymaga pracy.

Napisac książkę na pewno się opłaca - praktyce.

Ale poza tym to sa bzdury.

Bzdury to mocno powiedziane. Z tego co ja wiem, p. Żeliński jest praktykiem, i zrealizował już wiele niebanalnych projektów biznesowych, wszystko na początku opierając o UML, w którym zaczyna rysować już przy pierwszej rozmowie z klientem, a dopiero na końcu klepie kod.

Tyle, że on jest w tym biegły, a w naszym kraju jakoś się to po prostu nie przyjęło (w odróznieniu od "Zachodu"), jest to traktowane po macoszemu, a szkoda, bo przy większych projektach potrafi oszczędzić czas, szczególnie kiedy zmieniają się ludzie w zespole.

W waszym kraju to różnie bywa, ale w Szwajcarii to UML dawno już nie widziałem (co mi akurat odpowiada).
Poza tym wystarczy zajrzeć do linked in aby sprawdzić, że ten Pan zajmuje się głównie nauczaniem... Na uniwersytecie UML działa dość dobrze.

Silv napisał(a):

@jarekr000000:

Ogólnie problem z diagramiami polega na tym, że w wiekszości nie pozwalają na duży poziom abstrakcji.

Myślałem, że właśnie odwrotnie. Co pozwala na większy poziom abstrakcji?

BPMN na przyklad

UML jest problem, że jest on nadto skomplikowany i właściwie to element wielkiej machiny co się zwie RUP. Hierarchia klas, diagramy stanów, sekwencji, czy przypadków użycia są pomocne, ale przez to, że nikt nie zna dokładnie UML tworzą się "dialekty" znane w jednej firmie. Nie wiem czy to dobrze, czy źle. Może potrzebna jest prostsza notacja? Warto projektować w jakiejś notacji przed klepaniem. Problem w tym, że taki projekt/dokumentacja staje się straconym czasem w momencie jak przestajemy ja utrzymywać.

Widziałem projekty oparte o UMLe i uważam że jak ktoś ma za dużo $ to kto bogatemu zabroni ;) Problem w tym, ze cięzko takie diagramy utrzymywać, bo kod się zmienia. A takie diagramy to kupa roboty żeby były aktualne, a zysk żaden. Zresztą dobrze napisany kod, z odpowiednią separacją poziomów abstrakcji, czyta się tak samo jak taki diagram. Ba, taki kod powinien nawet mocno diagram przypominać.

Ja Ci dam uniwersalną radę (która być może nie jest dobra) - nie ucz się konkretnych technologii, ucz się programowania (wzorce, paradygmaty, algorytmy), sieci, systemów operacyjnych, metodyk i przede wszystkim współpracy z ludźmi.

To czy wybierzesz C#, Node czy zostaniesz w PHP ma mniejsze znaczenie. Pytasz o bezpieczną przystań - lepiej dla Ciebie będzie założyć, że coś takiego nie istnieje.

C#, Java, PHP w 2019 (pytasz o C#, Java, PHP - ponad rok temu)
Web - Python czy JS/Node? (pytasz i Python, JS/Node - kilka msc. temu)

Jak sam widzisz, takie pytania będziesz zadawał co rok - i zamiast się głowić którego języka się nauczuć, poucz się tych rzeczy o których pisałem wyżej - wtedy łatwo zmienisz język w razie potrzeby.

Shalom napisał(a):

Widziałem projekty oparte o UMLe i uważam że jak ktoś ma za dużo $ to kto bogatemu zabroni ;) Problem w tym, ze cięzko takie diagramy utrzymywać, bo kod się zmienia. A takie diagramy to kupa roboty żeby były aktualne, a zysk żaden. Zresztą dobrze napisany kod, z odpowiednią separacją poziomów abstrakcji, czyta się tak samo jak taki diagram. Ba, taki kod powinien nawet mocno diagram przypominać.

Hmm, diagramy robi się przed pisaniem kodu, a nie po, więc co tu utrzymywać? ;) Chyba, że chodzi Ci o dokumentowanie kodu diagramami? To wtedy owszem, ciężko utrzymywać, ale po co dokumentować kod diagramami? Koncepcje, funkcjonalności tak, ale kod?

Schemat bez utrzymania jest mało warty. Zaimplementowales system i co dalej? Rozwijasz go i jak nie utrzymasz schematy to możesz wyrzucić go do kosza bo zmarnowałeś kasę wydana na jego zrobienie oraz w przyszłości zmarnujesz czas na odkrywanie kodu przez nowych (nie koniecznie niedoświadczonych) devow.