Warto porzucić pracę w Javie 11 i Springu na rzecz Guidewire ? Są na tym forum jacyś fani albo antyfani tego eee frameworka? Ten GoSu wygląda w sumie trochę jak Kotlin.
0
2
Gosu wygląda jak dziadek Kotlina, bo generalnie nim jest :P zaczął powstawać w czasach, gdy Java nie miała nawet generyków lub te generyki dopiero zaczynały raczkować. Miał pewne fajne ficzery które pojawiają się również w innych językach, ale starzeje się i ma swoje niedoróbki.
Pytanie, czemu chcesz zmieniać Javę i Springa na Gosu? Jeśli wkurza Cię Java, to lepszym wyborem będzie Kotlin, jest używany szerzej a nie tylko w produktach ubezpieczeniowych, jest aktywnie rozwijany (w przypadku Gosu to nie jest takie oczywiste).
Jak interesuje Cię zakotwiczenie się w jakiejś niszy i odcinanie kuponów, to pewnie Gosu będzie równie dobre jak każda inna tego rodzaju nisza ¯\_(ツ)_/¯
1
Chyba bym odpuścił na Twoim miejscu. Główne wykorzystanie to branża ubezpieczeniowa, ofert raczej nie za dużo, a te które są to nie jest jakiś szał. Raczej standardowe stawki dla seniora.
I oczywiście musisz się zaaklimatyzować w tym środowisku, w moim odczuciu jest specyficzne, nie masz tam takiego wsparcia dla RESTa jak w Springu, raczej się musisz nastawić na SOAPa i takie tam archaizmy.
1
Czarcik napisał(a):
ofert raczej nie za dużo
Z tym to bym nie przesadzał, co najmniej raz w tygodniu dostaję ofertę z "Guidewire" lub "Gosu" w nazwie i opisie - jak na niszę to chyba nieźle.
, a te które są to nie jest jakiś szał. Raczej standardowe stawki dla seniora.
A tu to się nie wypowiem, bo zawsze grzecznie odmawiam i nie dopytuję o szczegóły. No, ale może tak być.
I oczywiście musisz się zaaklimatyzować w tym środowisku, w moim odczuciu jest specyficzne, nie masz tam takiego wsparcia dla RESTa jak w Springu, raczej się musisz nastawić na SOAPa i takie tam archaizmy.
To akurat bzdura, chyba że mówimy o archaicznej wersji InsuranceSuite - ale nie wiem, czemu dziwisz się że coś archaicznego jest pełne archaizmów ¯\_(ツ)_/¯ Co do SOAPa to nie wiem, bo nie musiałem z nim mieć styczności, ale rozgrzebywałem przez chwilę jedno dość świeże xCenter od środka i to, co widziałem to RESTowe API, Swagger i RESTowi klienci.
1
To akurat bzdura, chyba że mówimy o archaicznej wersji InsuranceSuite - ale nie wiem, czemu dziwisz się że coś archaicznego jest pełne archaizmów ¯\_(ツ)_/¯ Co do SOAPa to nie wiem, bo nie musiałem z nim mieć styczności, ale rozgrzebywałem przez chwilę jedno dość świeże xCenter od środka i to, co widziałem to RESTowe API, Swagger i RESTowi klienci.
Nie napisałem, że się dziwię. Być może w nowszych wersjach jest REST, nie wiem nie sprawdzałem. U mnie w organizacji jest taka wersja w której nie ma i integracja przebiega po SOAPie tylko i wyłącznie. Praktyka jest taka, że na naszym rynku nie znam żadnej ubezpieczalni która by miała najnowszą wersję, ale nie jestem "gajdłajerowcem" więc mogę się mylić :)
Zresztą sam proces upgrade'u jest dość czasochłonny, co dodatkowo zniechęca do przechodzenia na wyższe numerki softu.
3
Ja programuję w Gosu od kilku lat i powiem tak, jak w to się wpadnie to ciężko wyjść i być na bieżąco np. z Javą, trzeba nadrabiać po godzinach.
Wcześniej pracowałem w różnych frameworkach Javowych i z perspektywy pracy z Gosu fajne jest to, że wszystko działa out-of-the box, bardziej można skupić się na programowaniu niż na rozwiązywaniu problemów dookoła.
3
Warto jeśli chcesz się udać na programistyczną emeryturkę, zamknąć się w konkretnej niszy, zamienić w niezastąpionego pracownika (czyli nie zwolnią, ale też nie awansują) i generalnie przestać się rozwijać. Sama praca mało przyjemna, takie powolne grzebanie w kupie i dwudziestoletnich rozwiązaniach.
Jeśli chcesz się rozwijać - będzie to krok w tył
1
Gosu jak to Gosu, kolejna narośl na JVM. Nie jest to zły język, ale nie jest to też dobry język.
Najgorszym elementem tego języka i całego GW są sami programiści, którzy nie potrafią sobie poradzić z nullami. Wrzucają je gdzie popadnie. Mogą skorzystać z głupich Optionali z Javy 1.8 - nie, to za duży effort. Mogą skorzystać z Option z guavy, ale mają to samo podejście.
Chyba najbardziej programiści Gosu szczycą się tym, że mieli lambdy wcześniej niż w Javie 1.8. No i co z tego, jak nie potrafią w prosty sposób obsłużyć nulla? Albo nawet lepiej, programować bez nulli. To się da nawet w Javie 1.4
"oddaliśmy" R1 do UATów i wiecie co? NullPointerException... i to jest norma, bo programiści Gosu mają to w dupie, bo ktoś ich nauczył, że tak się robi, a jak coś nie działa to nie ich wina. I tak działa cały ekosystem Gosu i GuideWire.
Także tego, uczulam, że trzeba tu zagryźć zęby. Posiedzieć, popatrzeć, można książki poczytać i kasę odłożyć. Ale tego światka się nie uleczy.
edit, mam parę uwag to tego co kolega napisał:
snakeomeister napisał(a):
Ja programuję w Gosu od kilku lat i powiem tak, jak w to się wpadnie to ciężko wyjść i być na bieżąco np. z Javą, trzeba nadrabiać po godzinach.
Wcześniej pracowałem w różnych frameworkach Javowych i z perspektywy pracy z Gosu fajne jest to, że wszystko działa out-of-the box, bardziej można skupić się na programowaniu niż na rozwiązywaniu problemów dookoła.
Nie zgadzam się z tym, że jak się "wpadnie" w Gosu, to w ogóle trzeba nadrabiać aż tyle zaległości z Javy. Java nie jest aż tak zaawansowanym językiem.
Plusem jest to, że faktycznie wiele rzeczy działa OOTB. Nie trzeba się babrać z HTMLem i CCSami. Działająca webapka, ale dostosowana pod specyficzny rynek.
1
@trojanus:
trojanus napisał(a):
Najgorszym elementem tego języka i całego GW są sami programiści, którzy nie potrafią sobie poradzić z nullami. Wrzucają je gdzie popadnie. Mogą skorzystać z głupich Optionali z Javy 1.8 - nie, to za duży effort. Mogą skorzystać z Option z guavy, ale mają to samo podejście.
Chyba najbardziej programiści Gosu szczycą się tym, że mieli lambdy wcześniej niż w Javie 1.8. No i co z tego, jak nie potrafią w prosty sposób obsłużyć nulla? Albo nawet lepiej, programować bez nulli. To się da nawet w Javie 1.4
"oddaliśmy" R1 do UATów i wiecie co? NullPointerException... i to jest norma, bo programiści Gosu mają to w dupie, bo ktoś ich nauczył, że tak się robi, a jak coś nie działa to nie ich wina. I tak działa cały ekosystem Gosu i GuideWire.
Nie zgadzam się z tym, że jak się "wpadnie" w Gosu, to w ogóle trzeba nadrabiać aż tyle zaległości z Javy. Java nie jest aż tak zaawansowanym językiem.
Nie możesz wrzucać wszystkich do jednego worka, ja się tam wcale tym nie szczycę że lambdy były wcześniej :) Who cares.
Cóż pracujesz w takim razie ze słabymi programistami jeżeli nie potrafią opanować podstawowych zagadnień.
Dlaczego narzekasz na NPE z Gosu? Integrujesz się z GW z innego języka?
Miałem na myśli to, że nie siedzisz na codzień wtedy w jakimś Springu/Hibernate i po jakimś czasie zaczynasz zapominać szczegóły. Po dwóch latach pracy w GW nie pójdziesz sobie tak samo komfortowo na rozmowę jako programista Java jakbyś na codzień używał tych frameworków.
0
@snakeomeister: narzekam ogólnie na NPE i brak obsługi nulli.
Akurat za bardzo w Gosu nie siedzę, popatrzyłem trochę w ten kod i mnie zwyczajnie nie kręci, wolę pisać automaty w Javie.
No i teraz jak mam scenariusz, w którym dev celowo daje nulla i leci NPE, to utrudnia życie nie tylko sobie, ale również BA, testerom i biznesowi. Można tego unikać, ale tego nie robią.
I miałem taką sytuację, zadałem pytanie devowi, czemu nie obsługuje nulla - odpowiedział mi, że nie wie co przychodzi z serwisu, więc ustawia nulla i failuje. Przecież to nonsens.
Można tak napisać kod, że nawet jak poleci dowolny Exception, to proces się nie zatrzyma. To żadna magia, tylko umiejętne wykorzystanie try-catch.
0
trojanus napisał(a):
@snakeomeister: narzekam ogólnie na NPE i brak obsługi nulli.
Akurat za bardzo w Gosu nie siedzę, popatrzyłem trochę w ten kod i mnie zwyczajnie nie kręci, wolę pisać automaty w Javie.
No i teraz jak mam scenariusz, w którym dev celowo daje nulla i leci NPE, to utrudnia życie nie tylko sobie, ale również BA, testerom i biznesowi. Można tego unikać, ale tego nie robią.
I miałem taką sytuację, zadałem pytanie devowi, czemu nie obsługuje nulla - odpowiedział mi, że nie wie co przychodzi z serwisu, więc ustawia nulla i failuje. Przecież to nonsens.
Można tak napisać kod, że nawet jak poleci dowolny Exception, to proces się nie zatrzyma. To żadna magia, tylko umiejętne wykorzystanie try-catch.
Wszystko fajnie, ale nie przypisywał bym takiego stylu programowania każdemu kto programuje w Gosu.
Możesz spotkać programistów innych języków, którzy będą pisać dokładnie tak samo.
Wracając trochę do głównego pytania czy warto.
Guidewire to tylko framework, a Gosu to tylko język programowania.
Jeżeli jednak posiedzisz w tym co najmniej rok to w Javie się uwstecznisz.
Programistów GW jest mniej niż programistów Java, więc jest to nisza.
Dużo zależy od projektu, do którego trafisz i czy lubisz współpracować bezpośrednio z biznesem, proponować im rozwiązania ich problemów itp.
Pracując w GW musisz dobrze rozumieć jak działają procesy biznesowe, które są w nim zaimplementowane, a nie tylko potrafić programować.
Tych procesów jest dosyć dużo i są dość skomplikowane.