GE Healthcare infók; megéri-e

Állást keres

Több másik téma is foglalkozik itt különféle cégeknél szerzett tapasztalatokról, de a címben említett GE Healthcare-t még nem találtam meg köztük.

Ahogy láttam, most is folyamatos a felvétel hozzájuk OOP nyelvekben. Akik ott dolgoznak vagy korábban voltak ott, tőlük kérdezném elsősorban, hogy mit gondolnak a cégről, mennyire érdemes odamenni?

Specifikusan a következők érdekelnek:
- Milyen a csapat?
- Mennyire van kihívás a munkában? Tudsz-e benne fejlődni vagy ahogy felvettek azzal a tudásszinttel mész el majd később tőlük?
- A munkák több tudományterületen átívelnek (matek, programozás, egészségügy stb.) vagy inkább csak programozni kell előre kiadott dolgokat?
- Milyenek a juttatások?
- Java vagy inkább C++ a preferált?

( shogy | 2014. 12. 12., p – 17:30 )

2001 ota naluk dolgozok, en elegedett vagyok vele. A kerdeseidre nem mindenhol tudok egyertelmuen valaszolni, mert sok kulonbozo csapat van kulonbozo projekteken, jelenleg tobb, mint 300-an dolgozunk fejlesztesen kulonbozo feladatkorokben: fejleszto, program, product, architecture.

- Milyen a csapat?

Nagyon jo. Az en csapatomban regi es uj emberek is vannak kulonbozo hatterrel, sokat tudok toluk tanulni.

- Mennyire van kihívás a munkában? Tudsz-e benne fejlődni vagy ahogy felvettek azzal a tudásszinttel mész el majd később tőlük?

Egyes csapatok regi termemek fejlesztesen dolgoznak, egy uj reszleg (tobb, mint 100 fo) teljesen uj orvosi platform felepitesen dolgozik. Mindket teruleten akad boven kihivas, az utobbin foleg sok uj technologiat kell megismerni es hasznalni. Ez az utobbi teruleten dolgozok 9 honapja, rengeteg uj technologiat kellett elsajatitanom.

- A munkák több tudományterületen átívelnek (matek, programozás, egészségügy stb.) vagy inkább csak programozni kell előre kiadott dolgokat?

Fugg a poziciotol. Van kodolos munka, bizonyos projektek igenyelnek kepfeldolgozas - es igy matekot -, egeszsegugy specifikus ismeretek mind IT mind kepfeldolgozas specifikusak.

- Milyenek a juttatások?

Nem ismerem a piacot, en elegedett vagyok. A fizetes melle van egy kafeteria keret, amit szetoszthatsz kedved szerint a kategosiak kozott.

- Java vagy inkább C++ a preferált?

Van mindkettobol eleg sok, projekttol fugg. A C++ a regebbi projekteknel, az ujaknal Java Enterprise elsosorban.

Ha egyeb kerdesed van, keress nyugodtan privatban vagy akar itt is.

Én ugyan a veled szemben levő lövészárokban dolgozom, de megerősíthetem, hogy a későbbi karriered szempontjából nem rossz döntés az orvostechnológiai és képalkotó diagnosztika.
Kevés olyan ága van az IT-nak, ahol közvetlenül érezheted, hogy a munkád közvetlenül emberi életeket menthet, tehát haszna, értelme van.

Köszönöm szépen a válaszokat (illetve alant a folyamatos uppolást :))! Nagyon hasznosak és ösztönzőek voltak. Még egy kis ideig (egy-két hónapig) biztos nem lesz aktuális a munkakeresés; fel akarom hozni magam C++-ból, mert az elmúlt időszakban sajnos nem használtam, és így sokat felejtettem belőle.

Az Advantage Workstation a szakmában nagy megbecsülésnek örvend. Linux platform. Régebben itthon is fejlesztették, remélem még most is vannak, akik ezen dolgoznak.

Aztán ott van a Centricity PACS. Nem tudom, hogy ezt mennyire fejlesztik itthon.

De Java Enterprise-ra rakni az új projektet... Hát banyek.
Másik gyártó most írta vissza a PACS megoldását Java-ról .NET-re, például. Ezt már inkább megértem.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az AW-n dolgoztam 9 evig, jelenleg kb. 40+40 fejleszto (platform + apps) dolgozik rajta. A CPACS-et nem itt fejlesztik (a backend ott is Linux egyebkent).

Egy platform fejlesztesenel nagyon sok szempontot kell figyelembe venni, nem hinnem, hogy egyertelmuen kijelentheto: Java rossz, .NET jo...

A Java elvileg kompatibilis, meg platformfüggetlen, de gyakorlatban azért ez mégsincs teljesen így. Ha egy nagyvállalat készít egy mammut szoftvert, amit drága pénzen árul, akkor azt le kell tesztelni. Mert igen is akadnak gikszerek. Valami bizgentyű opció mégsem működik a frissítés után. Egy bazi drága szoftvert használ a user. És milyen verzió a Java? Ja, hogy a legújabb? Az nem támogatott. Mondjuk a termék élettartama 5 év. Ilyen feltételek mellett meg lesz kötve a keze a felhasználónak, hogy milyen Java-t használhat. 5 éves távlatban meg operációs rendszer kérdések is felmerülnek. Ami nagyon kínszenvedés tud lenni a gyakorlatban. Ezek a mindennapok, amiről most beszélek. Minden 1-2 hónapban jönnek az új biztonsági javítások Java-hoz. Nyilván elég nehéz lekövetni a teszteléssel és mindennel. User-nek meg kötelezően fent kell lenni egy régi verziónak. A gép pedig nincs izolálva az internettől. Természetesen .NET-re is jönnek a biztonsági javítások, de jobban körülhatárolható, hogy az ügyfélnél mik lesznek és lehetnek fenn. Illetve, hogy a foltozott .NET a patch kedd után hogy fog viselkedni. És nem kell a szoftver kedvéért egy 2-3, rosszabb esetben 4-5 éves verziót használgatni csak azért, mert nincs elég erőforrás letesztelni.
Ez természetesen csak egy szempont. Felhasználó vagyok és nem vállalati ember. Számokat inkább nem is írok.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Leállás van a Google-nél? :) De komolyan, eddig legalább ez nem szokott problémát jelenteni... Na mindegy.

http://www.evosoft.hu/healthcare

Láttam működés közben a cuccukat, baromi jól működik, nagyon intelligens a szoftver, egy csomó vizsgálatot megkönnyít, de gondolom egy kalap szar, mert a hupuk megmondták, hogy .NET-ben márpedig nem lehet CT-szoftvert csinálni.

És milyen verzió a Java? Ja, hogy a legújabb? Az nem támogatott. Mondjuk a termék élettartama 5 év. Ilyen feltételek mellett meg lesz kötve a keze a felhasználónak, hogy milyen Java-t használhat.

Milyen verzió "A" Java? Melyik "A" Java? Minden valamirevaló alkalmazás saját Java példányt használ, mégpedig azt, amit a vendor jóváhagyott. Innentől kezdve pedig a júzer nem upgradelget úgy általánosságban Java verziót az alkalmazás alatt, hanem alkalmazást upgradelget a hozzávaló Javával együtt. Az, hogy egyébként a gépen a júzer más célokra milyen Java verziót használ, az senkit nem érdekel, mert ellentétben a .NET-tel, a Javából lehet több, egymástól független patch szintű példányt használni.

Természetesen .NET-re is jönnek a biztonsági javítások, de jobban körülhatárolható, hogy az ügyfélnél mik lesznek és lehetnek fenn. Illetve, hogy a foltozott .NET a patch kedd után hogy fog viselkedni.

Ez a Javánál sokkal egyszerűbb: egészen pontosan körülhatárolható, hogy az ügyfélnél mik lesznek és lehetnek fenn (az alkalmazás alatt): az az egy szem verzió, amit a vendor mondott. Pont ugyanannyit kell tesztelni így is, mint a .NET-nél. Azzal a lényeges különbséggel, hogy a vendor kontrollálhatja, hogy egy-egy elbaszott frissítés ne menjen ki a kuncsaftokhoz, és ne kúrja szét az alkalmazást - de ezzel együtt nem kényszeríti rá a júzert arra, hogy más alkalmazásokhoz is csak a régi cuccot használhatja. Ugyanez a .NET-nél nem működik, legfeljebb lehet tanácsolni az ügyfeleknek, hogy most akkor kicsit ne frissítsenek, de az érinti a gép összes cuccát, nem lehet per alkalmazás nem frissíteni.

Sajnos ez nem igaz. Én is ezt hittem a java-nál, és felvilágosítottak, hogy sajnos ott is vannak helyzetek, amikor borul a kompatibilitás. Éppen ezért, major verzió
váltásnál mindig teljes tesztelés szükséges.

http://msdn.microsoft.com/en-us/library/hh367887%28v=vs.110%29.aspx

Tesztelés mindig kell. NET-nél is Java-nál is. Java-nál elég a minor váltás is, hogy ne menjen. Ami nyilván a kódon is múlik - persze...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ezt a csodát eddig az Abev-nél láttam elkövetni, de akkor ezek szerint másoknak is sikerült. Mi kliens és szerver oldalon is fejlesztünk, közel 10 éve,
eddig ilyen problémába még nem futottunk bele (olyanba viszont igen, hogy adott vm-ben hiba volt, de szerencsére ezt pár nap alatt orvosolták)

Arról szólt a rinya, hogy bizonyos java-ban írt programoknak fix verziójú java kell, mert csak azzal mennek, és nem tesztelték újabbal. Erre mondtuk,
hogy és, akkor mi van, megoldható, hogy a java-s program maga mellett tartsa azt a java verziót, amivel működik, így ha a rendszer automatikusan frissíti
magát, és a tisztelt fejlesztők nem tesztelek X verzióra, akkor sincs gond. De ugyanez igaz bármilyen vm alapú nyelvre, bármikor lehet egy inkompatibilis
javítás, amitől borul az egész rendszer, éppen ezért ezeket a rendszereket a hálózatról LEVÁLASZTVA szokták futtatni. Ha pedig szerver oldali, akkor különösen
nem piszkáljuk.

A programmal szállított VM tényleg nem frissül. A CT és MR gépek valóban nincsenek kint a neten, de amiről én írtam az nem CT és nem MR, viszont kint van a neten. És a szoftver kerül annyiba, mint egy CT vagy egy MR. Kliens oldali dologról szólt a példa.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

A helyzet nem egyertelmu kliens gepek eseteben sem.

Nem tudom, hogy a .NET runtime frissitesek mennyire stabilak, de kritikus kornyezetben nem biznek abban, hogy a gyarto nem csesz el semmit.

Arrol, hogy egy kliens gep menyire kritikus lehet, egy pelda: XYZ Hospital az USA-ban, 20000 alkalmazott, 5 korhaz, 10+ CT, 5+ MR, gyakorlatilag a radiologia mukodesetol fugg a beveteluk nagy resze.

Backend
- 2 datacenter (egy sajat uzemeltetesu, a masikat berlik a helyet), redundans berelt vonalakkal osszekotve (10Gb/s) a data centerek egymassal es az osszes korhazzal (kisebb savszel)
- 2 eles szerver, minden adat folyamatosan tukrozve a 2 PACS (kep tarolo) kozott, active-passive kombinacio
- 2 teszt szerver, nap kozben az eles kornyezetbol szinkronizaljak az adatokat a teszt kornyezetbe
- a sw upgrade (miutan a gyarto kiadta a frissitest es atment a tesztelesen)
- teszt rendszer passive node-jara upgrade felrak, node teszt, failover, masik node upgrade, node test, cluster teszt
- heteken, esetenkent honapokon keresztul nyuzzak a backendet kulonbozo verzioju kliensekkel
- ha minden rendben van, akkor a teszt rendszeren alkalmazott modon felrakjak a frissiteseket
- ha valami gond van, azonnali rollback, a gyarto pedig keresheti a problema okat
- mindehhez full time service mernok, aki csak az adott gyarto eszkozeivel foglalkozik

Kliens
- alap, hogy nincs auto upgrade bekapcsolva (ez valoszinuleg minden nagyvallalatnal igy van meg a titkarnok gepein is, nalunk is)
- ha erkezik egy OS vagy barmi frissites, az IT reszleg leteszteli teszt gepeken a korhaz altal hasznalt workflow-kon (a teszt csapatban radiologusok es IT-sok is vannak)
- ha minden jo, akkor az IT elkezdi a dokik gepeire is letolni a frissiteseket, utemezetten
- itt is rollback, ha gond van

Ha a .NET vs Java temanal maradunk: mondhat akarmit a Microsoft vagy az Oracle, teszteletlenul (nem a gyarto, hanem a korhaz szempontjabol) nem fogadnak el semmit! A letuk fugg attol, hogy mukodjon a radiologia (es a tobbi reszleg), mind backend mind kliens oldalon. Termeszetesen kliens oldalon kevesebb tesztelest igenyel es gyorsabban mehetnek a patch-ek.

Nem tudom, hogy magyar korhazakban mi a helyzet, de minden nagy gyarto elsosorban az USA (es egyre inkabb Kina) piacara dolgozik, az elobbinel elengedhetetlen a minimalis es tervezett allas.

Termeszetesen az sem egyszeru, mire egy gyarto kiadhat egy frissitest, a Healthcare nagyon szabalyozott uzletag. Ha erdekel valakit, arrol is irok szivesen.

Én pedig nem szeretném, hogy 2014-ben 6u27-es java legyen fenn, mert a célprogram azzal támogatott. Vagy ez egy indokolatlan igény lenne így 2014-ben?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Akkor mondok még valamit: csak Adminisztrátorként fut a cucc és nincs jelszó.
És egy ilyen gépen legyen fenn 2014-ben 6u27, mert azzal fut a szoftver. Ez aztán a szuper! Java!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Mondok ugyanilyen példát: nem igaz, hogy 2014-ben X verziójú PHP kell egy alkalmazásnak, mert az újabbal nem megy, sőt, nem igaz, hogy bizonyos disztribúciók még csak
nem is támogatják gyári csomag szintjén az újabb PHP-ket (pl. SLES). Sőt, ha már itt tartunk, miért kell még python 2-t felrakni, amikor már python 3 is van, igaz,
baromira inkompatibilis a kettő, de hát a HÜLYE FEJLESZTŐK miért nem updatelik már a programjaikat...

Nincs megkötve a keze, ugyanis java-ból akár több verzió is fent lehet a gépen, illetve mi pl. azt csináljuk, hogy
saját JVM-et csomagolunk a program mellé, és a programunk azzal fut. Innentől kezdve teljesen mindegy, hogy a felhasználó milyen verziójú java-t használ mihez. Ha pedig szerver oldalon futó java-ról beszélünk, ott végképp nem értem a problémát. Akárhány java verzió fent lehet a szerveren, és csak be kell hivatkozni, hogy melyikkel fusson a szerver.

A teszteléses dolgot sem értem, pont azért vannak az automatizált tesztek, hogy a funkciókat végigteszteljék.