C -> Java programozó

Állást kínál

Sziasztok!

Hosszú távú projekthez keresünk programozót. Egy meglévő, C-ben írt rendszert kell átírni Java alapúra, így mindkét nyelv ismerete szükséges.

Német vagy angol nyelv ismerete szintén elvárt, de papír nem szükséges róla, csak a tudás megléte.

Bejelentett és számlás munkaviszony is megoldható, viszont irodában kell dolgozni Budapesten, időnként bécsi munkavégzés is szükséges lehet.

A határidő szorít, így kérem minél előbb jelentkezzen, akit érdekel az allas at 2 5 6 dot hu címen - lehetőleg egy CV-vel és egy telefonszámmal.

Cég: Littner kft.

Fizetés: nem tudom miért tabu errefelé kiírni a fizetési keretet, de megteszem. Munkáltatói oldalról 500-800k a leendő kollégára költhető keret, amelynek a kivételi módja szintén megegyezés tárgyát képezi.

Ha valami kimaradt, a fórumban is szívesen várom a kérdéseket.

Köszönöm.

(A hirdetés a HUP-Profession szabadkártya felhasználásával került kihelyezésre)

  • 8767 megtekintés

( wauf | 2011. 04. 04., h – 21:01 )

Ez alkalmazottkent, gyerek nelkul 242k-385k netto bert jelent.

Remelem, hogy talaltok megfelelo embert rovid hataridovel ennyiert.

Forrasok: 1 2

A nehezitesek miatt.

Ahhoz hogy egy ilyen project sikeres legyen, egy olyan emberre van szukseg, aki nem csak "egyszeru java fejleszto", hanem jo C es Java programozo is egyben.

Tovabba rovid tavon (vagyis azonnali felvetelre) keresik az embert, ami miatt csak a piacon jelenleg levo emberek johetnek szoba.

Ha ragaszkodnak a kovetelmenyekhez es nincs a piacon megfelelo egyen, akkor muszaj egy jelenleg dolgozot kell meggyozni arrol, hogy valtson, ami nem egyszeru. (ld: forras)

Mi 3-4 honapig kerestunk megfelelo embert, mire talaltunk egy elfogadhatot (es akkor lejjebb kellett adni a kovetelmenyeinket).

Ezek miatt kivantam sok sikert a hirdetonek.

Az, hogy sürgősen keresünk, nem azt jelenti, hogy jövő héten már kezdhet is valaki. Nyílván, ha nem találunk, akkor tovább keresünk, egyáltalán nem ez a legfőbb kritérium.

A project szót többen félreértették, vagy én írtam rosszul, de ezt egy másik hozzászólásban mindjárt kifejtem.

Közép vagy magas? Hát... itt migrációs munkáról van szó, amely nem feltétlen junior kódolás, pláne projektmunkáról, amely nem feltétlen több, mint fél év. Ha hozzávesszük, hogy ez egy architekt jellegű munka a recfactor okán, akkor erre a napi (szuper)bruttó 25-40eFt nem tűnik feltétlen magasnak.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( Summer6529 | 2011. 04. 04., h – 21:34 )

Nekem szimpatikus, hogy megadtátok a kereseti lehetőséget és az ilyen nem profession-os hirdetések is érdekesebbek, használhatóbbak, mert a profession-ösöket megtalálom a profession.hu-n is. Régen nekem tetszett, hogy lehetett szabadabban hirdetni

( Joejszaka v | 2011. 04. 04., h – 22:52 )

Végre egy korrekt hírdetés.

up.

( persicsb | 2011. 04. 05., k – 01:45 )

Jól hangzik a dolog.
Szerk.: A végzettségi elvárás kimaradt a hirdetésből.

Akkor mar inkabb JNA. SZebb, tisztabb erzes, mint a JNI. Nyilvan alacsonyszinten JNI-vel van implementalva, mivel a JVM csak igy tud nativ koddal egyuttmukodni, de a felsobb szintu API lehetne finomabb is, JNInel agyfasz. A JNA okossag, hasznaltam is mar, amikor a Smidla-fele v2 solver libraryt kellett illeszteni.

( gabrielakos v | 2011. 04. 05., k – 07:46 )

T'om hogy abszolút nem ebbe a topicba tartozik, de nem állom meg, hogy ne szóljak: én még ilyen sikeres átírás projektet nem láttam.

Remélem nem egy-az-egyben átírást terveztek, hanem a specifikáció ismeretében újratervezitek a szoftvert. A meglevő algoritmus elemek egy csomó melót megspórolnak az új kódereknek, de a C-s "struktúrákat" nem szabad Java alá begyűrni, nem természetes, nem lesz jó. Különösen a következő verzió nem lesz jó...

--
Gábriel Ákos

Na igen, az szokott az óriási probléma lenni ilyenkor, hogy a forrás rendszerben valami iszonyat gányul van megírva. Az meg külön bónuszpont, ha ilyenkor se (naprakész) specifikáció/dokumentáció, se pedig olyan ember, aki fejlesztői szemmel tudná, hogy mi miért van úgy, ahogy. De a bónuszpont bónuszpontja, hogy olyan felhasználó sincs, aki tudná, hogy mit miért csinál a rendszer úgy, ahogy, mert már ő is csak örökölte és bizony nem ért belőle részeket, hogy miért úgy lett megvalósítva, ahogy. :)

(Természetesen ez csak egy általánosítás, a fenti projektről semmilyen információval nem rendelkezem.)

Én is.

Talán ide írom a projecttel kapcsolatos dolgokat, és lehet, hogy én hibáztam a szó használatával.

Egy 20 éves ügyviteli rendszerről van szó, amit folyamatosan fejlesztettek az elmúlt 2 évtizedben, és higgyétek el, a rendszer igen nagy. Nyílván nem egy ember fog egyedül dolgozni ezen a projecten, hanem sokan, de egy embert keresünk pillanatnyilag a meglévő csapatba.

( Esc | 2011. 04. 05., k – 08:29 )

Csak két megjegyzés..
.. írjátok ki milyen jellegű rendszert kell átírni és milyen kritériumok alapján, pl.:
- web-es alkalmazásról vagy gui-s van szó.. és esetleg mi lenne a cél, ugyanis eléggé tagozódik a web is és a gui is..
- egyrétegűről vagy valami spéci kliens szerver alkalmazásról..
- stb.

A másik tisztán érdeklődés.. hogy miért kell átírni?
A java-nak ugyanis elég sok korlátja van a C-hez képest és relatíve kevés előnye.

És ez hosszú távon költségcsökkentő. Sokan elfelejtik, hogy egy szoftver karbantartási költsége a fejlesztési költségnél nagyobb lehet, így fontos a jó architektúra és a jó platform megválasztása. Technológiai előnye lehet, hogy van a C-nek a közvetlen memóriakezelésben, más előnye nem igazán van (pl. szabvány szerint platform/fordítófüggő részek), a Javanak piaci előnye viszont rengeteg.

Object-XML binding (JAXB)? ORM (JPA, JDO és társai)? Több C++ fordító támogatása? Pl. egy Intel CC-vel fordított lib (forrás nélkül) nem használható fel name mangling és ABI szabvány hiánya miatt. Cloud computing platform (Google App Engine)? Nincs jó C++-os geoinformatikai lib, Javara ott a GeoTools. Qt helyett sokszor Boost libet kell használni. Szabványos (platformfüggetlen) objektumszerializáció sincs. Az x87 CPU trigonometriai függvényei sok esetben rosszul implementáltak, speckó matek szoftvert FPU-ra bízni nem lehet, kell a szoftveres implementáció. Qtban nem tudsz webes rendszert elkészíteni. Qtban nem tudsz klaszterezett rendszert elkészíteni gyorsan (két objektum, két külön VM-ben, de tudnak egymásról és használhatják őket). A valódi moduláris kód elkészültét (pl. SPI-ok) a rendes reflection hiánya (az RTTI egy vicc) korlátozza. Valódi enumok nélkül a régi SDKhoz készített binárisok inkompatibilisek lehetnek az új lib verziókkal, rendes enumoknál nincs ilyen gond. És ez csak pár hiba, ami most hirtelen eszembe jutott.

"Más előny" a C oldalán..
.. gyorsabb
.. kevesebb az erőforrást használ
.. ki tudsz használni XX GB-s memóriát is
.. képkezelés, médiakezelés, stb. ahol a java még pénzért se nagyon rúg labdába
.. egy egyszerű web kamera használata..
és a többi, és a többi.. folytathatnám. Tény érteni kell hozzá, jobban mint a java-hoz.
Speciel én fordított helyzetben vagyok, mint a hirdető, mert egy java rendszer mellé akarok egy C-s átiratot, többek közt a fenti okok miatt (is).

A java piaci előnyét meg érdekes felhozni, mert minden a web irányába megy, ahol max.
enterprise környezetben áll erős lábon a java, máshol nyomokban is alig lehet felfedezni.
Nem tudom mit kell átírni, de ha nem spéci alkalmazás (grafika, fájlkezelés, ..), akkor elég bátorság, vagy inkább botorság nem web-re átírni.

Egyébként fentebb használsz egy két rövidítést.. ez a java-sok sajátja, akik többsége olyan szavakra maszturbál, hogy JPA, JNI, JABX, JDO.. egyszóval mindegy, csak többnyire J-vel kezdődjön, és olyan szakszerűen hangozzon. Az, hogy a gyakorlati életben lehet nélkülük is élni, sőt jó kódot írni, az lassan már nem is számít java-s körökben. Lényeg használj mindenféle keretrendszert, Hibernate, Spring, stb, stb. zabálja a memóriát, legyen a tetű a kód, legyen 100 MB a telepítőkészlet.. na erről szól ma a java-sok 90 százalékának a java-ban kódolás és ezért (is) félnek sokan a java-s programoktól. Meg arról, hogy próbálnak objektum orientáltam programozni és átesnek a ló túloldalára..

Wow ennyi csúsztatást egy hozzászólásban nem sűrűn lát az ember. Kár lenne szétflamelni a hirdető korrekt álláshirdetését, úgyhogy csak _röviden_:
"gyorsabb": nem
"kevesebb az erőforrást használ": talán
"ki tudsz használni XX GB-s memóriát is": java is
"képkezelés, médiakezelés, stb. ahol a java még pénzért se nagyon rúg labdába": így általánosan ez nem igaz
"egy egyszerű web kamera használata": lehet

"A java [...] botorság nem web-re átírni."
Java Web Application elég webes.

"Egyébként fentebb használsz egy két rövidítést [...]"
A szabvány technológiák használata nem fétis.

A csúsztatásokról..
"gyorsabb": "nem" : igen néha felröppennek tesztek, ahol a java alázza a C-t, érdekes módon ezek soha sem komplex kódok, sokkal inkább bűvészmutatványok.
Láttam párat.. valóban nagyon gyakori, mikor a programok csak egy ciklusból állnak, ami mondjuk összead két egész számot.:)
"kevesebb az erőforrást használ": "talán" : értem, akkor semmi köze ahhoz, hogy ennyire elterjedtek akkor a java-s GUI-s programok és web-es környezetek..
"ki tudsz használni XX GB-s memóriát is": "java is": igen, ehcache és egyéb tool-okkal, amik "kiktatják" a gc-t.
"képkezelés, médiakezelés, stb. ahol a java még pénzért se nagyon rúg labdába": "így általánosan ez nem igaz" : 2010-ben összefosod magad, mire egy sima
transparens gif-et előállítasz vele, MPEG4: egyedül az IBM-nek van (pure) java-s lejátszója, senki nem használja, mert szarrá terheli a processzort, egyébként
ez igaz a java-multimédia vonalra anno az egészére..
"egy egyszerű web kamera használata": "lehet" : igen volt egyszer egy.. JMX, ha jól emlékszem, ~8-10 éve.. és már X éve hallott.. semmire sem volt jó.. összességében
ezért sem terjedt el
igazán a java úgy mint a flash, mert egy normális multimédia kezelést nem csináltak hozzá/bele, és ezért nem hozza el a kánaánt a html 5 sem.. bár a w3c az a szervezetet
amire atomot kellene dobni..

"A szabvány technológiák használata nem fétis."
.. hanem többnyire mazoizmus.:-) Nincs még egy olyan nyelv mint a java, amiben 10 percenként születik egy rövidítés és egy szabvány technológia.

De ez tényleg nem technológiai fórum, csak arra akartam kilukadni, hogy java-val sem tejfel az élet.

.. gyorsabb

Nem egyszer cáfoltam már (lásd például http://hup.hu/cikkek/20090517/az_androidra_alapozza_a_jovot_az_amerikai…)

.. kevesebb az erőforrást használ

Valóban van a JVM-nek 20-30MBájt plusz erőforrás igénye, de ez jelenleg el szokott törpülni a program memóriahasználatától.

.. ki tudsz használni XX GB-s memóriát is

64biten G1 GC? Simán képes 32-64-128G memóriát kezelni.

.. képkezelés, médiakezelés, stb. ahol a java még pénzért se nagyon rúg labdába

JavaFX? Java3D?

.. egy egyszerű web kamera használata..

Android? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Srácok!

Ha nyitok egy topicot java vs c címmel, átmentek oda? :- ). Félre ne értsétek, érdekel, amit írtok annak ellenére, hogy 100%- osan egyik mellett sem tudnám letenni a voksom, mivel nyelvet én inkább feladathoz szoktam választani, és nem minden problémára van meg számomra az univerzális nyelv, de ezt inkább ott :- ). Még be is linkelném innen mondjuk "java vs c csata" címmel. Nos? :- ).

Köszi.

.. az első csak azt példázza, hogy nagyon tudsz for ciklust írni. Gondolom Bill után szabadon mindenre elég egy for ciklus!:-)
.. a második, hogy valóban kezel, csak a problémákat ne nézzük.
.. a harmadik vicc volt ugye? Mikor megjelent a JavaFX sirattam is a flash-t:)
.. a negyedik is vicc, mert ugye inkább menjünk be egy boltba.. 10-ből 10-et nem tudsz használni java-val.
Egyébként meg, ha a jövőt nézzük.. láttál Te egy Star Trek filmben is java-s programot? Na ugye!:-)

Nem tudom mit kell átírni, de ha nem spéci alkalmazás (grafika, fájlkezelés, ..), akkor elég bátorság, vagy inkább botorság nem web-re átírni.
Az alábbi inkább kérdés, mint kijelentés: nem érdemes webesre átírni, ha valami összetettebb desktop alkalmazásról van szó. Mi ezt a rendszert fejlesztjük Java-ban (sima Swing a kliens, server tomcatben futó webapp, hibernate-el) és nem tudom elképzelni, hogy azt a rengeteg beviteli formot ami van, a sok validationnel, calculated, meg feltételesen editálható mezőkkel hogy lehetne normálisan megvalósítani browser based-en.
Nem azt állítom, hogy ez lehetetlen webesen, de managelni/implementálni azt a kódot szvsz. sokkal nehézkesebb és nem láttam még ilyen jellegű komolyan (nálunk van form, amin 100+ beviteli mező van - nem mi akartuk, a felhasználó sírt miatta, hogy egyszerre akar mindent látni), összetett webes alkalmazást.

Jaj, ez a 100+ beviteli mezo... na ez halal. Azt csak sejtem, hogy vastag kliensen az, de hogy weben tuti, az biztos. Meg ugy is, hogy nagyon lazy validationjaim vannak, es csak server oldalon validalok.

Van egy ilyen urlapkitoltosdi cimu webapp, abba vannak ilyenek, most volt epp olyan csavar, hogy ha itt meg ott ez meg az van, akkor ugyan mutassunk mar meg neki egy subformot, egyebkent meg felejtos. Katasztrofa, foleg a validalas, meg szerencse hogy az egy subformon levo mezoket nem kell kulon osszekotni, hogy mittomen ha itt 10 van, akkor onnan ki kell venni ket erteket a select-bol.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az elmúlt másfél évem egy olyan java web (wicket) alkalmazás architekt-i és vezető fejlesztői pozíciójában telt, ami minden évben (vagy akár negyedévben) változó adatgyűjtő űrlapok webre adaptációjára épült. Egy 30 éves DOS-os, dbf fájlt floppyn beküldős, 15 ezer felhasználó által használt rendszert váltottunk ki. Vannak több száz mezős űrlapok a rendszerben, saját domain nyelvet írtunk antlr segítségével az űrlapmezők közötti kapcsolatok és szabályok leírására, van a rendszernek adminisztráció modulja ahol pikk-pakk összedobhatsz új űrlapokat, azokat kipublikálhatod az ugyancsak a rendszerben kezelt akárhányezer, historikus adatokkal is bíró intézményeknek, jóváhagyás workflow-val, riportinggal, master data management, kódtárak. Riportokhoz épül egy elosztott adatcache (hazelcast) aminek a segítségével olyan komplex lekérdezések is kezelhetőek, amik több évet, hierarchikus intézményi összesítést és ezeken futtatandó szabályokat tartalmaznak.

--
The reason that half of us are in computing at all is that we see computers as things that we can make beautiful things out of..

Nem fizettek annyit, hogy antlr-t hasznaljak hozza, plusz a kapcsolatok amugy nem tul bonyolultak, csak amikor a validacional fel kell sorolni a subform mind a nyolcvanot baszat, akkor egy ido utan kopni kezd a billentyuzet meg az elszantsag.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ezen a 100+ beviteli mezőn mi is átestünk Wicket-tel, de úgy, hogy itt hozzáad egy új objektumot a listához (pl. címkomponens), ott módosít valamit, stb. Ezután mondtam azt, hogy erre még egyszer nem vagyok hajlandó és legyen valamilyen koncepció aztán kitaláltuk, hogy hogyan kéne. A Wicket úgy oldja meg a dolgot, hogy szerver oldalon történik a validálás és e mellé lehet betenni a kliens oldali js-es validálást, de vannak olyan keretrendszerek illetve a Wicket-hez is vannak olyan komonensek és próbálkozások, ahol a leprogramozott validálást automatikusan generálja le js-be is és beleépíti az oldalba. A számított mezők már más tészta, ott kérdés az, hogy kell-e hozzá a szerveroldal is vagy csak egyszerű hókusz-pókusz is elég a kliens oldalon. A Wicket a számított mezőket is megoldja szerveroldalról.

Mindamellett nekem inkább az a véleményem, hogy azt kell webesen megcsinálni, ahol szükséges, hogy böngészőből használják, mert a fejlesztési idő lazán többszöröse is lehet egy webes fejlesztésnek, mint egy desktoposnak. A különbség az, hogy desktop esetén minden egyből ott van, teljesen állapottartó és eseményvezérelt tudsz lenni könnyedén miközben pixelre pontosan néz ki a felület. Ezzel ellentétben webes környezetben többkörös kliens-szerver együttműködés (mindezt a szigorúan állapotmentes http protokollal!), vacakolni az ajaxszal (amit jobb esetben a keretrendszer nagyon leegyszerűsít), a css-sel és azzal, hogy hogyan fog megjelenni, működni fog-e az adott browserben, stb.

Az keves. Valamit tessek a projektkiirasba is beletenni, mert kulonben vagy tul sok haszontalan jelentkezod lesz, vagy senki nem jelentkezik.

A kovetkezot kell leirni
- Mi a projekt (ugyviteli rendszer)
- Webes / nem webes
- Milyen rendszereken fut jelenleg.

Ezek alap infok ahhoz, hogy az ember tudja, hogy mit szeretnel, ugyanakkor magarol a szoftverrol semmit nem mond, ezeket ki lehet irni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( lzrd | 2011. 04. 05., k – 08:40 )

Végre egy olyan álláshirdetés, ahogyan az összesnek kezdődnie kéne!
Kár, hogy nem vagyok programozó!

--
unix -- több, mint kód. filozófia.
Life is feudal

( ptiszai v | 2011. 04. 05., k – 15:05 )

C/C++ és Java programozó vagyok x éve, de beülni munkahelyre nem fogok, majd ha leadnak ebből akkor jelentkezem .:)
Küldjék el a projektet és átírom.:)))

Meetingre persze.
Minek beülni egy irodába?
Hatékonytalannak tartom.Van Skype stb.Nyugaton nagyon jól megy a távmunka, csak itthon még nem indult be.
Egyébként 15 évig irodába ültem.
Én 6-kor kezdek és néha 19-ig melózom, sokat hétvégén is.
Te ezt megteszed az irodában?

Akkor majd kontrázok a gyerekei apa nélkül nőttek fel résszel ....

Amíg nekem nem volt gyerekem, simán én is mondtam azt, hogy csak arra nincs idő, amire az ember nem akarja. Lelkesen éjszakáztam, hétvégéztem.
Aztán jött a gyerek :)

Azóta - ha az ember lelkiismeretes szülő - akkor nem tud/fog ilyen kilengéseket csinálni ...

Otthon dolgozom, mi ezzel a baj?
Miért jó bent ülni egy irodában? Semmire nincs időd, a főnökök okoskodnak stb.Kevesebbet látod a gyerekeidet mint otthon, 15 évig irodában ültem.
Én 1 időben 2-3 projektet viszek magamtól.
Sokkal hatékonyabban dolgozom otthon,mint ha irodában ülnék, beosztom az időmet.
Fiaim egyetemisták.Ne jöjjön senki nekem a rendes apa dumával....
Kint sokkal többet dolgoznak mint itthon pl. USA vagy Japán.Usában megszokott a távmunka, csak itthon a sok hülye főnök hiszi azt, hogy a közös munka hatékonyabb mint a távmunka.Multinál is dolgoztam, tudom miről beszélek.

nekem semmi bajom az otthoni munkaval :-) hanem a napi 13 ora munkat sokalltam. Marad meg idod barmi masra (pl. feleseg) este 7 utan?

Mert ha mar egyetemistak a fiaid, akkor gondolom, kevesebb az igenyuk a mindennapi kontaktusra. De az en 3 eves nagylanyom mellett ez az eletmod elkepzelhetetlen lenne.

csak itthon a sok hülye főnök hiszi azt, hogy a közös munka hatékonyabb mint a távmunka.

Azert van benne valami, de ez mondjuk pozicio vagy meg inkabb szemelyisegfuggo. De az mindenesetre igaz, hogy sokan gondoljak ugy, hogy ha nem vagy itt, akkor nem dolgozol, ami nyilvan nem feltetlen fedi a valosagot.

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Együtt futunk , bicajozunk, most jöttünk haza.
Persze amgig kicsik voltak a srácok, akkor ez nem ment.
Hétvégén szombaton 8 órát lehúzok, de akkor reggel 5-től, így délután szabad. Vasárnap ha nincs sürgős meló, akkor 4 órát.

3 évig projektvezető voltam egy cégnél, elég jól ismerem a főnöki mibenlétet, elég is volt előle...:)))
Pro-kontra értem.

Oke, hogy kivitelezheto es mukodik, de jo ez neked? Nem unod a munkat? Nincs igenyed tobb szabadidore? Nem erzed ugy, hogy azert elsz, hogy dolgozz, nem pedig azert dolgozol, hogy elj? Mert ha ez valami atmeneti allapot, mert mondjuk sporolsz valamire, vagy adossagot torlesztesz, vagy egyeb szuksegbol van, akkor megertem, de hosszu tavon mar kevesbe tudnam elkepzelni, hacsak nem ennyire elvezed a munkadat.

"Otthon dolgozom, mi ezzel a baj?"
Nem a mi hibánk, hogy nem otthon dolgozunk.Ha a munkavállaló megtehetné, otthon dolgozna. A munkaadó nem szeretné ezt. Márpedig kettőnk közül az ő szava számít. Dolgoztam olyan cégnél, amelyik tagja volt valami távmunka szövetség, vagy egyesület mifélének. Még fennen hangoztatta is, hogy mennyire támogatja a távmunkát. Közben meg egy nagy francokat. Nem nagyon engedte, hogy otthonról dolgozzanak "túl sokan". Sose lesz divat a távmunka, az otthonról dolgozás.
--
unix -- több, mint kód. filozófia.
Life is feudal

Így van, nálunk a főnökök nem ismerik az internet lehetőségéit, bármikor ellenőrizhető az illető, legalább is hogy pc közel van.
51 éves "vén" (ezt kikérem magamnak ha más mondja:))) fejemmel, néha frissebb vagyok az új dolgokra, mint 30-40 éves főnökök.:)))
Folyamatosan tanulok, mint ti is.
Nem állhatunk le, mert elmegy mellettünk a technológia világa.

Picit off> Na ez meg a masik. Ha elmultal 40, akkor az evek szamaval forditott aranyban valtozik a munkalehetoseg: minel idosebb vagy, annal kevesebb. Hogy tapasztalt vagy? Kit erdekel, legyel fiatal, agilis, dolgozz minel tobbet, minel kevesebbert.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nemtom láttad-e a szmájlikat.
BTW mostanában elég soxor indulok, amikor még alszik a fiam és érkezem, amikor már alszik. Ötkor indulok és kilenckor érek haza. Ebben benne van naponta 2x50 perc gyalogtúra a körülmények miatt. Te ezt megteszed? Értelmes dolog ilyenekkel licitálni? Pláne, hogy SZMÁJLIIIII. Hihetetlen gyorsan véget fogok vetni ennek a rendszernek és igyexem a gyermekemmel is lenni minél többet. Annyit akarok dolgozni, amennyit muszáj. Nem többet. BTW 15 évig tartott, mire beültél az irodába? :) <-- ez itten egy szmájli
--
unix -- több, mint kód. filozófia.
Life is feudal

( fn26 | 2011. 04. 08., p – 11:40 )

Örömmel olvastam ma napközben a hozzászólások nagyjából 70%- át :- ), de eljött az ideje, hogy kommenteljem őket, illetve a kérdésekre válaszoljak.

-----

Az eddig beérkezett 3 jelentkezőből kettőt visszahívunk még ezen a héten, a harmadik jelentkezőtől meg megpróbálunk egy telefonszámot kicsikarni emailben.

( Aadaam v | 2011. 04. 06., sze – 23:33 )

Korrekt.

Az otletet, hogy mondjuk meg, mekkora a ceges keret, tamogatom :)

Varom hogy mikor jelennek meg az 'olyan nincs hogy valaki c-ul is meg java-ul is tudjon' hienak,de vegulis az is rejtett up :)

( lzrd | 2011. 04. 07., cs – 08:24 )

Nem ez a cég vagytok, ugye? :)
--
unix -- több, mint kód. filozófia.
Life is feudal

( fn26 | 2011. 04. 08., p – 11:40 )

Jelenleg úgy néz ki, hogy legkésőbb május végéig szeretnénk megtalálni a megfelelő embert jelen munkakörre, bár ha előbb megvan, még jobb.

( fn26 | 2011. 04. 14., cs – 22:33 )

Köszönjük az eddigi jelentkezéseket, de az állás egyelőre sajnos még betöltetlen.

Akinek bármilyen kérdése van, itt nyugodtan felteheti... .

a jelentkezok ezt mar nyilvan vegighallgattak. Mivel pedig o mondta, hogy 'kerdezzetek batran', ezert a HUP az a forum. Nyilvan nem a nevek erdekesek, hanem ugy eloadva, hogy pl. XY ugyan minden szempontbol megfelelt, de a 2M HUF berigenyet cegunk nem tudja jelenleg kigazdalkodni, bla-bla-bla....

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Nos, lássuk csak.

Mindenkinél volt valami elengedhetetlen hiányosság.

Az egyikük nem beszélt nyelveket, pedig valószínűleg jónak tűnt. Nem mondom, hogy mind a két nyelv szükséges (bár ugye az a legjobb), de az egyik nyelv mindenképpen. Ezt a kitételt nem csak úgy odaírtam, hanem például esetenként Bécsben is szükséges tartózkodni, ahol legalább az angol elengedhetetlen.

Az egyik másik jelentkező mellékállásban gondolta volna, ha jól emlékszem, egyetem mellett, viszont ez egy főállású munkakör, valamelyest rugalmas munkaidővel, de nem heti 15 órával. Nála a kellő tapasztalat is hiányzott.

Volt egy majdnem teljesen jó jelentkező, aki - ha úgy vesszük, átment a tudásalapú rostán -, nyelv és tudásismeret is megvolt, viszont Ő nem gondolta hosszabb távon ezt a mnukakört, max. egy évre. Mi jelen esetben 4- 5 évre keresünk valakit, és az elég nagy gondot jelent, hogy mondjuk egy emberke beletanul a munkába adott esetben 3 hónap alatt, és egy múlva elmegy.

Volt egy negyedik jelentkező is, akinél igazából a nyelvek (program) kellő ismerete nem volt meg.

Néhány szoftverfejlesztéssel foglalkozó cég is jelentkezett a project szót meglátván, de mint írtam, itt szükséges az aktív jelenlét.

( fn26 | 2011. 04. 15., p – 17:58 )

Hozzáfűzve az egészhez, ezt a 4 személyi jelentkezést kicsit kevésnek tartottam. Mi az oka szerintetek? Az anyagi keret? A 2 programnyelv? Egy idegen nyelv ismerete? Az irodai munkavégzés? Rémisztő a nagyon ritkán előforduló, de szükséges bécsi munkavégzés? Nem akarok valótlant írni, de szerintem ez max. 3 hetet jelent egy évben, de inkább kevesebbet.

Avagy csak a megfelelő jelölt éppen nyaralt múlt héten, és most fog jelentkezni :- ).

Amennyiben körülnézel a "piacon", nagyon sok java állás hirdetés van/volt amire nem találtak/találnak embert.
Szerintem adja magát miért van "kínálati" piac java téren..
.. a legtöbb java programozónak nagy a feje a sok objektum miatt.. és nem fér be minden nyíláson.:)

Egy javaslatom lenne..
.. hogy adjatok fel egy másik hirdetést is, amiben C-ről gépi kódra kell átírni a projectet.. és máris elégedett leszel a 4 jelentkezővel.:-)

Többen mondottuk volt, hogy ez a keret erre a munkára (refactor + architect) kevés még akkor is, ha csak Java ismeret szükséges, valószínűleg azok mozdultak rá, akik éppen munka nélkül vannak, de ahhoz kevés, hogy egy C/C++ nyelvet olvasó és Java nyelven senior fejlesztő egy biztos helyet hagyjon el egy bizonytalanért.

A 800k keret kb. bruttó 600e forintnak felel meg, ami a jelenlegi senior Java helyeknél valahol a tartomány alja. És ahogy említés volt róla: jelenleg sok helyen keresnek Java fejlesztőket.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ha egy megbízótól kapja egy éven át a pénzt, hamar szagot fog az APEH^W NAV, másrészt pedig számlás 800e mellé kb. 200e bruttó bér a hihető, vállalkozó magának fizet ugye, ebből kb. kijön, hogy nettó 450-500e marad nála, de rezegni fog a léc minden ellenőrzésnél, hogy átalakítják színlelt alkalmazottá. Ennél már az is jobb, ha duplaminimálbér + feketén zsebbe fizettek, de ezt nem én írtam... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Rémisztő a nagyon ritkán előforduló, de szükséges bécsi munkavégzés?
Igen, engem rémiszt. JNI-vel szívesen taknyolnék, és ha mindezért főállás, bécsi fizetés, családdal való letelepedés járna, és max, 3hetet kell Magyarországon tölteni, kevésbé lenne rémisztő.

( kirsa74 | 2011. 04. 16., szo – 11:41 )

pötty

( zoli78 | 2011. 08. 27., szo – 10:14 )

Üdvözlet!

Ha még aktuális, akkor beszélhetünk a dologról.
Nekem van tapasztalatom ilyen jellegű feladatban, az önéletrajzom angolul megtalálható itt: http://hu.linkedin.com/pub/zolt%C3%A1n-nagy/39/945/a85
Jellegéből adódóan nem egyszerű feladat egy ilyen, de érdekes kihívásokkal tud tele lenni és nagy fegyelmezettséget, alaposságot igényel, talán pont ez az amit szeretek benne.

További szép napot!

Szia NagyZ!
Veled régen is élmény volt vitatkozni! :-)

Igen, microchip. Nem teszi hiteltelenné, mert ha elolvassátok, hogy villamosmérnökin végeztem automatizálás szakirányon, akkor már sejthető, hogy van közöm a hardver közeli programozáshoz és a digitális áramkörök tervezéséhez is. Amúgy ez a része a dolognak hobbi volt már gyerekkorom óta is.
Ami meg a kételkedést illeti: akinek nem kell a tudásom, az nem fog nekem hiányozni.

Az angolban igazad van, nem voltam rákényszerítve, hogy élő beszédben használjam nap mint nap, ezért eddig csak pár ezer oldal könyvet olvastam el angolul meg fórumokon koptattam a billentyűzetet. Tudni kell rólam, hogy addig nem merem valamiről kijelenteni, hogy tudom, amíg én nem érzem úgy, hogy tényleg jól tudom. Ettől függetlenül egy turistát lazán útba igazítok és újabban angol nyelvű oktatóvideókat nézek.

Ha így írom akkor jobb? http://www.microchip.com/
Ha nagyon felhúzzátok az agyamat, akkor előkeresem a jegyzeteimet is, hogy milyen típusú chip volt benne! Amúgy szerencsére ezt már C-ben kellett programozni, de ami össze volt benne gányolva (egy egyetemi tanár írta az eredeti verziót, remélem nem programozást tanít! Ez csak vicc volt, nem volt az olyan rossz kód, korábbi munkáiból ollózhatta össze a vázát.) A szívás az volt, hogy a C fordító (ami amúgy negyed millió Ft-ba került) a struct-ot bizonyos körülmények között nem tudta megfelelően lekezelni és nem lehetett reentrant kódot írni. Akinek van némi köze a programozáshoz az tudja ez mit jelent. A többieknek, akik ide járnak másokat leszólni elmagyarázom: a picben nincs olyan szintű veremkezelés, mint egy PC-ben ezért a függvények helyi változóit nem a veremben hozza létre (amitől újra be lehetne lépni egy függvénybe), hanem fixen kiosztja a memóriába és ezeket a memóriacímeket bele is égeti a programba.