Amíg profession-ön voltam, prémium profil megmutatta nekem, kik jelentkeznek az állásokra, és a statisztikát, hogy mennyit kérnek. Átképzett éttermi dolgozókkal, könnyű fizikai munkásokkal, szállodai ügyintézőkkel meg olyasmikkel van tele az informatikai jelentkezések kétharmada - vagy még nagyobb aránya. Fizetési igények meg ilyen 300-tól 350-ig. Ha beszélsz németül vagy angolul, nézhetsz nemzetközi cégeket, ahova juniort keresnek, egyébként maradj a magyar cégeknél. A magyar cégek szakképzett munkaerőt biztosan nem kapnak annyi pénzért, amennyiért keresnek, ergo gyakorlatilag nem vagy hátrányban. Ha szerény fizetéssel beéred, jó esélyed van megkapni az első esélyt. Aztán majd meglátod, hogyan tovább.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Romániában élek. Beszélek angolul. Jelenleg nem igazán találtam olyan céget amely pályakezdőt keres. Amúgy a junior pozícióra is 1-2 év tapasztalatot kérnek
Mindenképp bele vágok, a kérdés inkább az, hogy melyik nyelvvel...

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Ha ott élsz, ott helyben kellene találni valamit. Remélem, jól beszélsz Románul is.

Vagy az angollal irány a full remote munkák felé. De azokhoz minimum olyan szintű ismeret kell, hogy nyakadba hajítják a még ki sem pucolt problémát, és leteszel az asztalra valami értékelhetőt. Azt vagy be tudod vállalni, vagy nem.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

A Pythonnal konnyebbet nemigen talalsz es lehet benne full-stack alkalmazasokat irni, nem csak backendet. Van tobbfele web framework, DB-driverek, frontenden ha nincs legalabb 8 fele UI framework, akkor egy sem. Nagyon flexibilis, nagyon konnyen hasznalhato, konnyen tanulhato.

https://www.coreinfinity.tech

Junior 1-2 ev nem feltetlen jelent direktben munkatapasztalatot. Hobbiprojektek, barmi, amirol lehet beszelni interjun eleg lehet.
A junior piac telitett, foleg a frontend, ahol relative alacsony a belepesi kuszob. Jo interjuzassal ki kell tunni.

Éppen a frontend lenne telített? A hirdetések jó 80-90%-a frontend problémára hajazik (illetve fullstack). Nagyjából annak érződött, míg skubiztam a profession-ön a hirdetéseket.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Sziasztok!

Először is köszönöm az eddigi tanácsokat.
Picit felvázolom az érveket(ellenérveket) a nyelvek mellett.

Python:
Pro - Talán ez a legkönnyebb
Kontra - Nagyon régen tanultam, keretrendszert is kell külön tanulnom.

Java:
Pro - Ezzel foglalkoztam a legtöbbet, elvégeztem egy tanfolyamot is(fizikailag, nem online).
Kontra - Talán ez a legnehezebb, keretrendszert is kell külön tanulnom.

Flutter - Dart:
Pro - Könnyebb, mint a Java, ezt tanultam legutóbb(Udemy tanfolyam), egyszerre tanultam keretrendszert és nyelvet is.
Kontra - Kevesebb állás lehetőség.

Segít ez nektek tanácsot adni ?
Picit úgy érzem, mint aki ide - oda kapkod és mindig az után lohol ami a legközelebb van
Ezért szeretnék végre dönteni és kitartani valamelyik mellett, hogy ne vesztegessem tovább az időmet.

[ Szerkesztve ]

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Azért egy java-ból hosszab távon lehet többet profitálni, főleg a python-hoz való hozzáállást. De az nem egy két év lesz...

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Stop.

Nem nekunk kell eldonteni, hogy Te mit akarsz csinalni, hanem Neked. Ha ezen tul vagy, valaszthatsz eszkozoket, amelyekkel elerheted a celokat.

https://www.coreinfinity.tech

Tudom, nem is várom el. Csak gondoltam esetleg kikérem olyan emberek véleményét akik jobban rálátnak a témára mint én. Hátha ez(is) segít a döntésben..

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Viccen kívül, végigolvastam a CAP blogot a wiki-n, és ott van a blog végében a PACELC kritikája. Nem csak én gondolom úgy, hogy a CAP kissé figyelmetlen.

Sőt, szerintem a PACELC is figyelmetlen annyiban, hogy akár scriptes jellegű alkalmazások esetén csak egy erőforrás szemafor kiegészítés kell, és akár elosztott rendszerekben az A/C probléma L/C problémává változik. Tranzakció-mentes környezetek számára az adatverziókat már feltalálták az Availability alapértelmezetten biztosítható.

Egyenlőre nem találtam másik gyakorlati megoldást a "közelben", amelyik foglalkozna az A/C -> L/C probléma transzformációval, mint például Redis cluster-t futtatni. Ha te mégis tudsz olyat, sikíts.

Ami vélemények eddig érkeztek, mindegyik tool, amelyik a problémát egyáltalán kezelheti bármilyen szinten, Raft / Paxos alapú. Azt kijelenteni vajon korrekt?

A trollkodást meg nyugodtan hanyagolhatod. Arra nem tartok igényt.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

A PACELC nem kritika, hanem kiegészítés, valójában még jobban leszűkíti a CAP-et.

> Ami vélemények eddig érkeztek, mindegyik tool, amelyik a problémát egyáltalán kezelheti bármilyen szinten, Raft / Paxos alapú. Azt kijelenteni vajon korrekt?

Mi a kérdés? Hogy van-e más a Paxos/Raft pároson túl elosztott konszenzusra? Persze, nyilván van. Vagy nem értem, hogy mit kérdezel.

while (!sleep) sheep++;

Programozni kell megtanulni, a nyelv mindegy, ma ez, holnap az. Ha egy nyelvvel megy pikkpakk át fogsz tudni állni másikra, kezd el az egyiket, és csináld pár évig munkaként, ez a lényeg, szerintem.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

A Java-t már csak meggyőződés nélkül tolják. A mobil aranyláz zászlóshajója volt, ami elsüllyedt. Azóta olyan sokan hagyták a fenébe, hogy a pénzek azért emelkednek. Ha úgyis ezzel foglalkoztál a legtöbbet, próbáld meg ezt.

A Dart-ról még előbb döntse el a Google, mennyire akarja tolni. Tolja immáron egy évtizede, és még mindig nem sok benne az értelem, hogy miért teszi. Talán majd egy újabb évtized után kiderül.

A Python-t illetően van egy olyan vicc, hogy a világ legrosszabb nyelvét már feltalálták. "P"-vel kezdődik a neve, és nem a Pascal az.

Amiket kihagytál:
-programnyelvek gyanánt C#,
-scriptnyelvek gyanánt PHP, Javascript,
-leíró nyelvek gyanánt HTML, CSS

Amíg az exotikumok eldöntik, hogy befutni akarnak-e, vagy éhen dögleszteni a saját közösségüket, ha csak elkezdeni akarod valahogy, maradj a kiforrottabb eszközöknél.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

A Java a mai napig nagyon népszerű, joggal. A nyelv is fejlődik ezerrel, az ökoszisztéma szuper stabil és rendkívül jó teljesítményt lehet belőle kicsikarni.

while (!sleep) sheep++;

Gyártasz legalább 1 hobby project-et. Bármit, amit jellemzően szívesen csinálnál. Felrakod githubra. Linket beleírod jelentkezésbe (vagy linkedin profilba). Aztán bízd mások megítélésére, hogy amit csináltál, az minőségében hol van a junior .. expert skálán hozzáértésben. Próbáld meg nem alábecsülni magad. Ha van tehetséged, kevés idő többet fogsz felmutatni, mint azok, akik évekig koptatták ugyan a széket, és gyűrődtek, épp csak olyan nehéz a fejük, hogy évek alatt is a legtöbb, ami rájuk rakódott, az a kosz a munkahelyre befele utazgatások során.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Írok c-ben egy erőforrás lock-ot cluster-re (linux only). Ha kész, felrakom a forráskódot + felhasználói segédletet php példákkal githubra. Ha nagyon akarod, majd dobok ide egy linket róla. Bár nem nagyon számítok rá, hogy ingyen tesztereket szerezhetek itt. Egyenlőre tervezési fázisban van, és nem fogom az ujjaimat égetve sietni vele, de véges időn belül azért elkészül.

Hanem a gyermeteg stílust leszel szíves hátrahagyni. Téged a szüleid nem tanítottak meg viselkedni?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Nekem némi php/javascript-es előzmények után java backend majd c# .net backend és angular frontend typescript-tel lett az irány. Üzleti alkalmazások.

Java oldalon a Spring (Boot) keretrendszer nagyon bejött. Arról váltani c#-ra .net web api-ra nem volt túl nagy probléma. Az Angular Typescript-tel a backend után, szintén könnyen abszolválható volt.

Java mellett/helyett több helyen használnak Kotlin-t is, elég sok lib elérhető kotlinban is, ami java-ban. Dolgoztam olyan projekten, ahol Spring volt használva Java-val, de újabb modulokat/service-eket már csak kotlinban írtak. Szintén JVM-es világban pl. Scala-s projektekkel is lehet találkozni, illetve ott a Groovy is, amit főleg DSL-ek személyében használnak (pl. gradle).

Jelenlegi munkahelyemen van Flutter iOS/Android/web kombóhoz, kollégák, akik használják nagyon meg vannak vele elégedve. Sokkal jobban, mint a korábbi natív Android Java (kotlin-t nem használtak itt) és pláne az iOS Swift (és még inkább pláne az objective c) után. Azt viszont érdemes tudni, hogy itt is ismerni kell a natív környezetet, vannak megoldások, amiknél a különböző platformokra célzottan kell kódot írni és emiatt szélesebb körű ismeretek is kellhetnek. Platformok terén az apple világa nem éppen baráti .

Python-nal csak minimálisan foglalkoztam, de java/c# után a syntax nagyon nem volt szimpatikus, de ez nyilván csak személyes dolog.

---

Szóval ahogy #18310 sh4d0w is írja első körben azt döntsd el, hogy mivel szeretnél foglalkozni frontend/backend esetleg mobilfejlesztés. Ha ez megvan, akkor nézhetsz állásajánlatokat (itthoni/külfödi) az adott területen bármilyen nyelven, hogy lásd miket várnak egyes helyeken (keretrendszer, adatbázis, környezet, tooling), miknek kéne még utánajárni/megismerni és mi az ami neked szimpatikus. Ezzel persze óvatosan, van ahol a világ minden technológiája is elvárás lenne minden alap nélkül

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

Érdekes, nekem 2 kollégám is van, akik fluttereznek és rühellik a fluttert, főleg kotlin után, vagyis jobban mondva magát a dartot.

Még az is lehet, hogy idővel kukázzuk az egészet és átmegyünk react nativba, ha már a webes cuccok is js-en készülnek.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Rengetegen meg nagyon szeretik, nem tudom, hogy 2 kollega velemenye mennyire relevans.

while (!sleep) sheep++;

Nem volt relevanciáról szó, csupán leírtam a tapasztalatom, ennyi. Nem tudom egyébként mi az oka.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Kinek mi. A személyes preferencia is belejátszik. Ha egy teljesen eltérő syntax-ot kell egyik napról a másikra használni az tud ellenérzéseket kiváltani. Nekem pl. java és az ott használt common formázások után volt jó pár dolog, ami nem volt szimpatikus a c#-nál elterjedt szokásokban, pl. a mindenhol is pascal case. Most meg már arra áll rá a kezem (mondjuk meg nem szerettem ).

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

Ja, lehet, az egyikük js-ről jött, a másik meg c-ről. Nekem például nem volt bajom se a php-val, se a js-sel vb után.

De valahogy az android studio is lehet közrejátszik, amikor látom őket szenvedni vele.

Ezért is nehéz ajánlani bármit bárkinek is, mert ezek annyira szubjektív dolgok is lehetnek, szóval inkább szeresd, amit használsz, mint az állásajánlatok alapján dönts. Persze nem baj, ha kettő egybevág.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Hát igen, VB után bármit is lát az ember, az csak jobb lehet

Ajánlás tekintetében szerintem a terület fontosabb is, mint maga a technológia. Ha nem érdekel a termék és nincs meg a motiváció, akkor nem valószínű, hogy meg lesz a kellő befektetett energia, hogy megfelelő szakemberré váljon bárki (tegyük fel ez lenne a cél). Adott területen belül meg kezdőként bármilyen "bevált" nyelv, framework, lib, akármi lehet ajánlott, hiszen a személyes preferencia majd azzal alakul ki úgyis.

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

Most a karácsonyi kis két hetes szünetben az alábbi side-projektel terveztem foglalatoskodni:

Szinte az összes OLTP workloadot át lehet ültetni DynamoDB-be viszont egyre gyakrabban belefutok abba a dologba, hogy kellene full-text, fuzzy search is, amit ugye nem támogat. A legtöbb OLTP-hez eddig kényelmi funkcióként kellett a keresés, tehát pl egy webshop felső kereső csíkja, ergó a már jól bevált DynamoDB Stream -> Lambda -> ElasticSearch ágyúval galambra lövés, hiszen elég macerás egy ES karbantartása. Meg hát ugye na mégis csak egy EC2n kell futtatni ami meg nem serverless szóval köszönöm szépen kihagyom.

Lelövöm a poént amit kitaláltam már mások is megcsinálták, de a puding próbája az evés szóval:
- Kell egy full-text search lib ami tud fájlba perzisztálni (pl https://github.com/LyraSearch/lyra, de konkrétan bármi másra is ki lehetne cserélni, teljesen nyelv független lesz maga a konstrukció)
- Kell egy indexelő lambda amely a DDB Streamet olvasva frissíti a fenti lib adatbázisát
- Kell egy query lambda amely a fenti libet és a fájlban tárolt dbt felhasználva válaszol a beérkező kérésekre

Mivel a Lambdák alapvetően csak egy temp directoryt kapnak futás után, S3ba perzisztálni meg nincs értelme mert minden invokációnál le kell tölteni a db fájlt ezért marad az EFS szolgáltatás, amit elvileg fel lehet mountolni Lambdák mögé és így invokációkor azonnal elérhető lesz a db fájl letöltés nélkül. Szóval kvázi egy perzisztens network file systemen tárolnám és adatváltozás esetén frissíteném a text-search lib adatbázisát.

Igazából az egészben a legnagyobb szopás az a terraformmal való VPC és EFS setupolás, főleg a VPC..

Na majd jelentkezem mire jutott a dolog.

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

Tuti, hogy az ES csak EC2-n oldható meg? Amazon OpenSearch Service?
Ennyi cuccra a tf kód amúgy pár sor.

[ Szerkesztve ]

OpenSearch az a régi aws managed ElasticSearch. Drága és ahhoz képes hogy managelt eléggé hozzá kell nyukálni, nézegetni, hogy él-e még satöbbi.

Illetve egy klasszikus kedvenc írásom a szolgáltatásról: https://spun.io/2019/10/10/aws-elasticsearch-a-fundamentally-flawed-offering/

Ha most összejön amit akarok akkor az egész nagy felhasználás mellett is bőven az örök lambda free tierben lesz és az egyetlen mozgó alkatrésze az 1 darab fájl lesz egy EFS-en

[ Szerkesztve ]

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

Nekem erre Azure-ban fut B1 linux App Service-en egy MeiliSearch. 5 perc volt belőni, más kérdés, hogy havi nettó 15 EUR a hosting.

Én kérek elnézést!

Igen de most a kis side projektnek kifejezett célja, hogy on-demand és pay-per-request legyen, igazából csak kiváncsi voltam, hogy bele lehet-e ezt is tuszkolni lambdákba.

És a válasz igen, kész van a PoC és működik

Egyetlen egy downside van eddig, aminek próbáltam utántanézni de egyelőre nem sok sikerrel. Tehát EFS-ben van tárolva 1 darab lyra.json fájl ami az általam válaszott full-text search librarynak a szerializált állapota/adatbázia. Van egy serializeToFile meg egy restoreFromFile funkció.

Két lambda van, egy query és egy indexer

Query lambda: cold startok esetén restoreFromFile-val beolvassa memóriába a dolgokat és válaszol a beérkező text searchre.

Index lambda: Az fő adatbázis változásai esetén (DynamoDB Stream) hívódik meg és feladata, hogy az EFS-ben szerializált fájlt frissítse, hogy a Query lambdák a legfrissebb adaatokból dolgozzanak. Ehhez tol egy restroreFromFile + módosítások + serializeToFile kört.

A query lambdából egyidőben végtelen sok lehet, az Index lambda concurrencyjét pedig 1ben maximalzáltam, így tehát egy időben maximum 1 írás lehet folyamatban, szóval nem fognak összekadani, nem kell lockolni a fájlt.

Egyedül az alábbi eshetőségre nem kaptam egyelőre definiált választ:
Mi történik linuxon/EFS-en, hogy ha egyszerre olvas és ír két különböző folyamat egy darab fájlt?

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

EFS elvileg NFS-t használ, amiben a close-to-open konzisztencia (https://serverfault.com/a/73927) miatt nem lehet gond egyszerre történő írás és olvasásból, és mivel írás+írás sosem lesz egyszerre a rendszerben így akkor elvileg jók is vagyunk

Kicsit ilyen adatbázisokból tanult dirty read problémának tűnt amúgy ez az egész

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

Hát, ez jó kérdés, de szerintem ez nagyon cég függő. Nálunk a cél, hogy minél előbb bele a mélyvízbe, mert pénzt akkor lehet termelni, ha önálló vagy, de egy multinál el tudom képzelni, hogy megy a maszatolás sokáig. De nem dolgoztam multinál soha, szóval lehet nem így van.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Nagyon függ attól, hogy hogyan használják a pythont. Ha Django webfejlesztés van, ott teljesen más feladatok lesznek, mintha Machine Learning lenne a téma, vagy ahol csak script nyelvként lenne használva a CI/CD-ben vagy a monitoring/logging környékén.

Én ezt az ingyenes tutorialt tudom ajánlani, valamennyi kontextust ad, ha webdevről van szó. Nyilván csak a jéghegy csúcsa, de legalább van adatbázis, konténerek, frontend dolgok, stb.

[ Szerkesztve ]

Azért elég sok for loopot kell írni

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Nagyobb csapatokban juniorok hibajavításon kívül mást nem kapnak. Kisebb csapatokban pluszban az implementálás rabszolga kóder feladatait sózzák rájuk. Esetleg windows alkalmazás portolása mac-re (forrásokat át kell cipelni, ha hiba üzenet bukkan fel, utána járni). Konkrét task? Leírják neked a céges hibakövető rendszerben screenshot / videók / akármi, hogy mit látnak egy állítólag hibás funkció működése közben, és azt is leírják, hogyan kellene működnie. Mindazt felhasználói szemmel. Aztán az a feladatod, hogy "most rossz, legyen jó"

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Kis cégeknél sem kell promptra úszni, nálunk 6, de inkább 12 hónap, amire olyan feladatot kapsz, ahol nagyobb a falat. Addig meg felügyelet mellett csinálod a projektek, kisebb, majd egyre nagyobb falatjait.

De a cél az, hogy rád lehessen bízni nagyobb munkát is, nem az, hogy örökre junior pista maradjál, az senkinek sem éri meg.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Én kicsi cég alatt a maximum 7-8 fejlesztőt értem. Ami afölött van, az már lehetőséget ad hierarchiára, és onnantól kezdve a hangulat többé nem ugyan az. Meg a munkamegosztás sem. Vajon egész biztos te is úgy méred a cég méretet?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

5-en vagyunk programozók, néha 6-an, de ez a max.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Valami ritka jövedelmező piacon lehettek, ha olyan kicsi csapattal el tudjátok fogadni, hogy "potyautas" van a cégnél, akit betanítani kell.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។