- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
-
PROHARDVER!
Új hozzászólás Aktív témák
-
-
sztanozs
veterán
hogy van a csv-ben most a text qualifier?
PS-ben nincs text qualifier parameter, csak ekzzel tudod feldolgozni a custom text qualifier-t. Amugy a definicio szerint duplazni kell az idezojelet, valahogy igy:
"cegnev","iranyitoszam,"cim"
"Cegnev ""idezojellel a belsejeben"" kft.","1234","Elem utca 123." -
Louro
őstag
Sziasztok!
Ismételten egy Powershell kérdést dobnék be. Legutóbb is sokat segített az itt kapott tanács.
Adott egy CSV, ami tartalmaz cégadatokat. Cégek nevei tartalmazhatnak idézőjeleket. Az import-csv kapcsán megadható text qualifier? A szöveg sajnos nem módosítható, mert sajnos a nevek tartalmazhatnak idézőjeleket. Most az import-csv idézőjeltől idézőjelig egybefüggő stringként kezeli, ami nagyon nem jó.
(5.1 a verzió, amivel dolgozok.)
-
pmonitor
aktív tag
válasz
pmonitor #19936 üzenetére
Egy kicsit összetettebb példakódot is írtam. A leírás itt található. A példa kód pedig itt.
Ezen világosan látszik a típusok címzése különböző típusok esetén.
-
Marky18
aktív tag
Semmi gond nincs a JDK-val, egy nagyon eros ecosystem epult ra, ami egy safe choice, ha valasztani kell egy stacket.
Az a téma megint érdekes lett számomra, és egykoron nem értettem meg azt a célzást, hogy "mert Java fejlesztot konnyu kukazni". Most jó lenne megértenem.
Javat tanitanak mindenhol, valoszinuleg keves olyan fejleszto van, aki ne talalkozott volna vele legalabb egy kis projekt erejeig. Az osszes cloud provider tamogatja, van SDK-juk, a dokumentaciok is az elso 3 helyen hoznak Java peldakat.
Emiatt konnyebb Javara felvenni embert, egyszeruen nagyobb a merites. -
coco2
őstag
válasz
Marky18 #19582 üzenetére
@Marky18 errefelé vagy?
A linkelt post 2023 novemberi. Az a téma megint érdekes lett számomra, és egykoron nem értettem meg azt a célzást, hogy "mert Java fejlesztot konnyu kukazni". Most jó lenne megértenem.
Vagy ha bárki más fel tud világosítani, mi a gáz a java sdk-val szerver oldali alkalmazás fejlesztés kontextusában, örülnék neki. Előre is köszönöm.
-
coco2
őstag
válasz
VikMorroHun #20091 üzenetére
Lehúzod a projektet, telepítesz valami grafikus verzió managert a helyi gépedre, és vissza lehet nézni azt a 100 buildet probléma nélkül.
-
fatal`
titán
válasz
VikMorroHun #20089 üzenetére
File history?
-
VikMorroHun
őstag
Van valami jó módszer arra, hogy a kb. egy évvel és 100 builddel ezelőtt feleslegesnek ítélt és kitörölt kódrészletet hogyan találjam meg GitHubon? Ma rájöttem, hogy mégis szükség lenne rá.
-
bandi0000
nagyúr
válasz
hiperFizikus #20084 üzenetére
Hàt ha nem is chatGpt, de nàlunk a google volt emlegetve, hogy ők is azt hasznàljàk, elolvastam a doksit róla, és 2 dolgot emeltek ki, ami nàlunk nincs meg
1: Tesztekkel tele van, nàlunk indiaik olyan csoda teszteket írnak, hogy nincs assertion, szal nem tesztel semmi
2: Mergelés gyors, na már most nàlunk 10p és 2 óra míg megkapom az approvokat, 1 óra a build, 1 óra a merge, és ez akkor, ha közben nincs mergelés a trunkra, mert akkor rebease és megint 1 óra, a tesztek meg nincsenek futtatva pusholáskor szal hiába is lennének
-
axioma
veterán
válasz
hiperFizikus #20084 üzenetére
fyi Google-ben head -en megy minden... az talan tobb mint egy kozepes projekt ;-)
-
hiperFizikus
senior tag
válasz
bandi0000 #20083 üzenetére
Nem benned van a hiba !
chatgpt/
A trunk alapú elágazási stratégia előnyei és hatékonysága változhat a projekt sajátosságaitól és a csapat méretétől függően. Néhány előnye és értéke:
Egyszerűség: A trunk alapú stratégia egyszerűsége lehetővé teszi, hogy a csapat könnyen követhesse és megértse a kódváltoztatásokat. Ezáltal gyakran hatékonyabbá válik a fejlesztés folyamata.Gyors visszajelzés: A gyakori integráció és a folyamatos integráció révén a trunk alapú fejlesztés gyors visszajelzést biztosít a kódminőségről és a hibákról. Ez segíthet a hibák korai felfedezésében és javításában.
Konfliktusok csökkentése: A folyamatos integráció révén a kódbázisban keletkező konfliktusokat gyorsan fel lehet ismerni és megoldani, mivel a változtatásokat rendszeresen összefuttatják a főágba.
Együttműködés ösztönzése: Mivel a fejlesztők gyakran integrálják a változtatásaikat a főágba, a trunk alapú stratégia ösztönzi a csapatmunkát és az együttműködést.
Azonban a trunk alapú elágazási stratégia nem minden esetben ideális, és bizonyos körülmények között hátrányokat is jelenthet:Nagy projektek bonyolultsága: Nagyobb projektek esetén a trunk alapú stratégia nehezebben skálázható, és könnyebben keletkezhetnek konfliktusok és egyéb problémák a főágban.
Függőségek kezelése: Ha a projekt függ más projektektől vagy külső erőforrásoktól, a főágban történő változtatások könnyen konfliktusokhoz vezethetnek, különösen, ha azokat más csapatok is használják.
Kultúra és tapasztalat: A trunk alapú fejlesztéshez egyfajta fejlesztői kultúra és tapasztalat szükséges, amely nem minden csapat számára lehet természetes vagy könnyen kialakítható.
Összességében a trunk alapú elágazási stratégia hatékony lehet a kisebb és közepes méretű projektek esetén, különösen, ha a csapat megfelelően fel van készítve és betartja a legjobb gyakorlatokat. Fontos azonban megfontolni a projekt sajátosságait és a csapat igényeit a stratégia kiválasztásakor.
/chatgpt -
bandi0000
nagyúr
válasz
martonx #20082 üzenetére
Nemtudom hogy kellene jobban fejleszteni ahhoz, hogy ehhez tudjunk adaptàlódni...
Mármint érted, nyilván szar a kód, nagyobb refactorálást csinálok, 1 osztályba 5-6 fv-t írtam át, aminek folytàn 10-15 osztályt is módosítottam, itt nem nagyon látom, hogy mit tudtam volna máshogy csinàlni
-
bandi0000
nagyúr
Királysàg
Igazàból mi pàr hónapja kezdtük el, de sztem kár volt...
Az érdekelne, hogy olyan esetben, amikor nagyon sok vàltoztatás érintene sok függvényt mit csinàltok?
Nàlunk az a mondás, hogy kb if-be berakjuk a feature-t, ami defaultom false, és így mehet be a trunkba, de pl tegnap amit csináltam 20 file-t érint meg isten tudja hány fv-t, szal nemtudom elképzelni, ilyen esetben mi történik
Ugye elvben a trunk based nek az az alapja, hogy unit testelve van minden, ami le is fut, ilyen esetbe kb nem kellene ez a flages jàték ami nàlunk van, de persze unit testek csapnivalók pàr kivétellel
-
bandi0000
nagyúr
Dolgozik itt valaki trunk based developmentbe?
Lenne pár kérdésem, nem tudom, mi csinàljuk rosszul, vagy tényleg rossz-e, de ha nincs vele tapasztalat, akkor nem is folytatom
-
válasz
VikMorroHun #20071 üzenetére
Megszűnt a kàrtyaregisztrációs fizetés, tehát mostantól csak eseti topup van, vagy direktben kártyás fizetés. Nem kell új kártyát regelned.
-
sztanozs
veterán
válasz
VikMorroHun #20071 üzenetére
Business requirement inkabb, mint feature…
-
coco2
őstag
válasz
VikMorroHun #20071 üzenetére
Gondolom hallottad már "nem bug, feature"
-
pmonitor
aktív tag
válasz
VikMorroHun #20071 üzenetére
Gondolod, hogy jelentkezni fog(nak)?
-
VikMorroHun
őstag
Érdekesség: akartam venni autópálya matricát a mobilfizetés alkalmazásban. Lehet fizetni egyenlegből, vagy bankkártyáról. Vagyis nem lehet, mert hibaüzenetet kapok (nincs internet/szerver nem érhető el). Kiderült, csak úgy működik, ha új bankkártyát regisztrálok, és egyből feltöltöm az egyenleget. Tehát először törlöm a regisztrált kártyát, újra regisztrálom, feltöltöm, majd megismétlem a folyamatot az elejéről, mert van benne 5000 Ft korlát is (az éves megyei matricák meg drágábbak). Ki volt az az idióta, aki ezt így leprogramozta, én nem tudom...
-
Louro
őstag
válasz
sztanozs #20068 üzenetére
Én voltam szerencsétlen. A fájlt egy adatbázis táblába olvastam be. De a mező varchar volt nvarchar helyett. Azt átállítva helyreállt a működés az -Encoding Default paraméterrel.
Amúgy a [System.Text.Encoding]::GetEncoding(1250) kapcsán hibaüzenetet dobott, de valószínűleg azért, mert régi Powershell van a gépen.
Köszi mindkettőtöknek!
-
sztanozs
veterán
-
sztanozs
veterán
-
sztanozs
veterán
vsz a feldolgozóban kézzel van helyettesítve a hullamos betű. Magyar nyelvű a feldolgozó?
Példa fajlt tudsz felrakni valahova?
mod
Hmm, en emlékeztem rosszul, van a CP1250-ben rendes magyar ekezet is...
De most nezem, hogy ha a CP1250 CP1252-kent van beolvasva akkor van ő helyett õ es ű helyett û... -
Louro
őstag
válasz
sztanozs #20064 üzenetére
Ha Total Commander-rel vagy Notepad++-szal nézem, akkor hullámos. Utóbbi szerint ANSI.
A jelenlegi saját fejlesztésű őskövület feldolgozóban 1250-es kódlap van beállítva és az jól kezeli. Mivel ember nincs, aki ismeri azt a feldolgozót - valószínűleg nem dokumentálták és a forráskód sincs meg, így kiváltanám, egy könnyebben kezelhető megoldással.A környezet pedig Powershell 5.1-es. Sajnos a 6-ostól kezelni tudnám, csak hát a cég.... meg van kötve a kezem :/
-
sztanozs
veterán
Milyen powershell verziod van?
a 6.2+ mar ismeri a codepage verziokat:
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-content?view=powershell-7.4#parameters
A default (5.1) verzioval .NET -tel kell beolvasni:$byte_content=Get-Content -Encoding Bytes -Path "c:\valami\akarmi.csv"
$e=[System.Text.Encoding]::GetEncoding(1250)
Out-File -Path "c:\valami\akarmi_unicode.csv" -Value ($e.GetString($byte_content)) -
Louro
őstag
Sziasztok!
Poweshell-lel kapcsolatban lenne kérdésem. Van egy fájlom, ami 1250-es kódlapot használ, de az istennek se tudom beimportálni import-csv segítségével. Az összes felkínált kódolást kipróbáltam, de a hosszú ékezetes magánhangzókkal nem tud mit kezdeni.
Valaki futott már hasonlóba és talált rá megoldást?Az nem megoldás, hogy a fájlt alakítsák át, mert ahhoz nem fognak nyúlni sajnos. Például a töltőállomás vagy az űrmérték szavakkal megszenved a rendszer, mert vagy ékezetesmentesít vagy hullámosra cseréli.
-
válasz
Vision #20046 üzenetére
Igen. Szerintem keveredik a fejedben a 'webes' es a 'krossz-platform' fejlesztes. Az elso generacios krossz-platform fejlesztoeszkozokkel sokszor egy webappot fejlesztettel, ami utana egy beagyazott webbongeszoben futott. Egyreszt ez lassabb (volt), mint a nativ kod, masreszt nem nezett ki ugy, mint a nativ widgeteket hasznalo app.
Viszont a Flutterrel vagy Unityvel fejlesztett krossz-platform appok nem webes technologiat hasznalnak, es kulon fordul egy iOS meg egy Android kod. Kicsit mintha C++-ban irt programot forditanal le Linuxra meg Windowsra is.
-
válasz
martonx #20043 üzenetére
Én most konkrétan a mobilra gondoltam (IOS/Android).
...ha state-of-the art appot akarsz, ami az adott platform legapróbb újdonságait is kihasználja
Ez igaz, kérdés, hogy ez mennyire valós igény. Ami szempontot még hallottam, az a performancia. Például egy számításigényes játék nem nagyon lesz soha multiplatform, miközben egy mobilbank simán lehetne. -
martonx
veterán
válasz
Vision #20042 üzenetére
Van aki ezt mond, van aki azt. A natív appok sose fognak eltűnni, ha state-of-the art appot akarsz, ami az adott platform legapróbb újdonságait is kihasználja, akkor azt adott platformokra külön-külön kell fejlesztened.
vs.
Fele annyi energia befektetéssel több platformra is elkészül ugyanaz a rendszer, amihez némi platform specifikus egyedi feature-t, megjelenési lehetőséget tudsz adni.
Ez volt az elmélet.
Szvsz ez a multiplatform fejlesztősdi kicsit humbug, ha tényleg igazi multiplatform akarsz fejleszteni (mondjuk IOS, Android, Windows desktop és Linux desktop, OSX), akkor azért abba komolyan bele kell állni, hogy mást ne mondjak Mac nélkül lehetetlen iOS-re, OSX-re fejleszteni, Mac-es ökoszisztéma felől nézve pedig nem ideális, de nem is optimális Androidra, más platformokra fejleszteni a sajátot kivéve.
Én inkább ott látom a multiplatform fejlesztés előnyeit, hogy bármilyen nyelven neki tudsz állni, miközben natív appoknál sok választási lehetőség nincs a felhasznált nyelveket illetően. Magamból kiindulva, mint .Net fejlesztő, én MAUI-val állok (pontosabban állnék) neki a cross-platform fejlesztésnek, de ez igaziból a C# miatt, nem pedig az annyira nagy cross-platformitás miatt, és a végeredmény tök jó lesz, agyontesztelve androidon, windows-on miközben remélhetőleg, ha oda kerül a dolog, és valaki Mac-en buildel egy appot belőle, akkor elvileg iOS-en (és OSX-en) is futni fog az app.
-
Mobil vonalon mennyit tudtok a multiplatform megközelítés előretöréséről? Mindenhol azt hallom, hogy szorulnak vissza a natív appok, és megy a nép a flutter / kotlin mp+compose iránybe-
-
hvld
csendes tag
Sziasztok! Figma file-ból viszonylag egyszerű és responsive HTML/CSS weboldal fejlesztéshez tudtok ajánlani valakit? Kevin Powell videói alapján a basic layout és a root elemek már adottak. Köszönöm!
-
pmonitor
aktív tag
válasz
pmonitor #20039 üzenetére
Jaaa. Meg még meg is figyelnek. Illegális felvételeket készítenek rólam. De ugye én paranoid szkizofrén vagyok, úgyhogy lehet, hogy csak beképzelem?? Csak ugye ez mellett még van parkinzonizmusom, szorongással kevert depresszióm is. Ki tudja? Majd csak kiderül valamikor, hogy csak képzelődöm-e a megfigyeléssel kapcsolatban...
-
pmonitor
aktív tag
válasz
pmonitor #20029 üzenetére
Azért gondolj bele: én "megtalálható" vagyok, mert nyilvánosságra hoztam az adataim.
Megtalálható vagyok, de ettől még nem csinálom össze magam. Ami a véleményem a fórumozó "programozókról", azt személyesen elmondom bárkinek. Csak vannak, akik az ember háta mögött szervezkednek. Persze ők is név nélkül.... A háttérben.
-
válasz
pmonitor #20035 üzenetére
Ha ezt a nebulók olvasták, akkor nem tudom, hogy kit szidnak, hogy őket meg ezekkel a vezérlési szerkezetekkel szívatják. És még meg is buknak, ha nem csinálják...
Szerintem félreérthető voltam. Egy munkahelyről beszéltem, ahol alapnak veszik, hogy a belépő kolléga ezeket ismeri. Az egyetemen nyilván buktatnak azért, ha még ezt se ismered. -
pmonitor
aktív tag
válasz
Vision #20025 üzenetére
Ma már nyilván nem az a kihívás, hogy jó vezérlési szerkezetet írjál, hanem hogy ismerd a framework lehetőségeit/korlátait,
Ha ezt a nebulók olvasták, akkor nem tudom, hogy kit szidnak, hogy őket meg ezekkel a vezérlési szerkezetekkel szívatják. És még meg is buknak, ha nem csinálják...
Én személy szerint a harmadik linkemmel értek egyet. Tehát hogy ahhoz, hogy modulokból/legókból(nevezzük, ahogy akarjuk) összerakjon valaki valamit, ahhoz tényleg nem kell zseninek lenni. Ez gyakorlatilag SM/betanított munka. Persze abban az esetben, ha nem kell még "bütykölni" valamit a "beszerzett" kódon.
#20030 JoinR: És a fizettség/kp hol marad?
-
coco2
őstag
>..latency vagy throughput...
A latency logikai szintig kap legalább +3 RTT pofont (logikai adatok szinkronizálása fürtön). Aztán az írási művelet latency-je kap lenyírást a memória miatt. A throughput a memória miatt rendesen több.
Adott gyakorlati helyzetben egy valódi teszt tudná megmutatni, mi hogyan alakul. Olyat az után tudok gyártani, hogy találtam egy értelmes célterületet. És azért tettem fel a kérdést
>BigQuery..
A BigQuery mintha tárhely kihívás lenne
Mit nem értettem meg a felvetésből?
@nemethg66
>..a mostanában felbukkant domain helyett..
A szakma nyelve az angol. A "domain" egy szakmailag korrekt fogalom. Gondolom az "entitás" a másik, amivel hamarosan problémád lesz. Sajnos a szakma területén egyiket sem fogod tudni megkerülni.
-
pmonitor
aktív tag
válasz
nevemfel #20024 üzenetére
Valami igazság van benne. De azért hozzá kell tennem, hogy én a prog.hu-n "nevelkedtem". És ott eléggé szemét volt a vezetés velem(főleg a moderátor). Hát innen ragadt rám, hogy a fórumozó programozókat nem tartom nagyra. Főleg a névteleneket. Azért gondolj bele: én "megtalálható" vagyok, mert nyilvánosságra hoztam az adataim. Azért így teljesen más posztolni, mint névtelenül. Ettől függetlenül amit az elején írtam, az elég mélyen bennem maradt. Na meg a fáradékonyságom is közbeszól.
-
coco2
őstag
Amatőr project kérdés.
Akad-e olyan szakmai domain, amelyiknek tipikusan nagyon gyors adatbázis műveletekre van szüksége? Valami, ami a jelenben talán redis-t használ muszájból, mert anélkül a felhasználói élmény rovására menne a lassú adatfeldolgozás.
Azt forgatom a fejemben, hogy gyártok framework-öt adatbázist memória fürtre rakni. Redis-hez (és társaihoz) képest mondjuk karbantarthatóságból lenne jobb (SQL alapokon működne, egyszerűbb tech stack), és persze támogatna párhuzamos műveleteket (lekezelnék konkurencia helyzeteket).
Bárkinek meglátása, kritikája van róla, őszinte véleményeket kérek. Akár csak annyit, hogy de nagy hü**eség
-
válasz
pmonitor #20023 üzenetére
Most speciel nem hülyeség, amit kapizsgálsz. Ettől függetlenül sajnos de, kőkemény tudás kell, mert hiába húzol be rengeteg libet, attól még vannak specifikus fejlesztési feladatok. Ezek egy részét kikönnyítik a külső modulok, de azok megismerése is időt/tudást igényel.
Ez nem mond ellent annak, amit a kolléga írt, sőt! Ő arról beszélt, hogy senki sem ír már meg 0-ról mondjuk egy CRM rendszert, mert nem rentábilis/hülyeség. Ettől függetlenül az üzleti logikákat implementálni kell. Csak mondjuk egy SSO-ra bízzák a jogosultság kezelést, mert tök felesleges ezt is házon belül megvalósítani, van rá a piacon több stabil, kiforrott megoldás is. Ugyanez igaz mondjuk a networkre, securityre, franc se tudja még mikre.
Enterprise környezetben még az is piszok nehéz, hogy millió korlátot kell figyelembe venni. Egyrészt már mindenhol domain szemlélet van. Nem az van, hogy csak odatoszod a kódot, ahova akarod, kőkeményen szervezve van domainek szerint, ami amúgy újabb megoldandó problémákat szül.
Összefoglalva: a mezei, klasszikus programozó feladatok átalakulnak (itt többen is utaltak rá). Ma már nyilván nem az a kihívás, hogy jó vezérlési szerkezetet írjál, hanem hogy ismerd a framework lehetőségeit/korlátait, értsd és betartsd a vállalati patterneket, jól átlásd a business feature-t, stb. És akkor még nem beszéltünk a devops szemlélet meghonosodásáról, CI/CD problémákról, amik már ugyanúgy fejlesztői feladatok.
-
pmonitor
aktív tag
válasz
#79484416 #20022 üzenetére
Nem érzem találva magam.
Itt arról beszél az illető, hogy:igen, mindig van egy robosztus, teljesen tesztelt open source lib ami ezt es tobbet is tud jobban
De itt is arról van szó, hogy:
Egy fejlesztesnel pont az egyik utolso, hogy hany bajt beimportalni egy libet, sokkal tobb penzt es idot el lehet egetni azzal, ha valamit a 0-rol kellene production ready szintre lefejleszteni.
Továbbá itt is:
az esetek nagy részében az internetről simán letölthető és összedrótozható modulokból áll. Nem kell senkinek rakétatudósnak lenni, hogy egy ilyet összedobjon az elérhető legókból.
Nos, ha minden a programozó hátsója alá tesznek mindent, akkor mihez is kell az a nagy IQ? A modulok(legók) összedobásához sztanozs szerint sem kell rakétatudósnak lenni. Amit megoldottak, az mind elérhető. Ha ingyért, akkor is felszámítják az árban, de ha pénzbe kerül, akkor azt is. Tehát amit a programozó csinál, ahhoz nem kell zseninek lenni.
Egyébként már érted, hogy mi a különbség az érték- és referenciatípusok között?
-
coco2
őstag
válasz
#01881923 #20014 üzenetére
Játék fejlesztés ügyében a domain ismeretek jelentős különbséget tudnak adni. Tegyük fel kezdő szinten foglalkoztál a c++-al, de egy élet óta játék fan vagy, és vénád van játék élmény tervezéshez. Azt beleírod egy motivációs levélbe, és elküldöd valamelyik cégnek hideg megkeresés gyanánt. Ugyan mit veszíthetsz vele?
-
AssAssynn
addikt
Köszönöm mindenkinek a válaszokat. Azt gondolom megértettem a topik többségének a véleményét a kérdésről. Nyilván nem veszem az elhangzottakat félvállról. Agyalok még az ügyön, aztán, ha úgy van jövök még boldogítani. Jó programozást mindenkinek.
-
válasz
#01881923 #20014 üzenetére
Vagy még a frontend webfejlesztés, de az meg gondolom borzasztó telített lehet és a 3 közül az érdekel a legkevésbé. Viszont megtanulni valószínűleg azt lenne a legegyszerűbb.
Ha ez alatt HTML-CSS mókolást értesz, akkor az teljes vakvágány, gyakorlatilag már nem is létezik ebben a formában. Ha valamilyen JS keretrendszert, akkor az piacképes, viszont egyértelműen nem a "legegyszerűbb" kategória.A három közül én az Androidot választanám Java-Kotlin vonalon.
-
#01881923
törölt tag
Hasonló kérdésem lenne nekem is, mint AssAssynn-nak, annyival vagyok könnyebb helyzetben, hogy vannak konkrétabb elképzeléseim meg valamilyen szinten kapcsolódó tapasztalataim.
Kreatív területről (3D látványtervezés, animáció, vfx) gondolkozom, hogy érdemes lenne-e még most váltani...
Az "AI" térnyerése ugye itt is jelentős, engem eléggé aggaszt és elbizonytalanít a jövőt illetően, a programozók viszont valamennyire még optimistábbnak tűnnek.Egyik lehetséges út a gamedev (vagy AR/VR appok) lehetne, mert az Unreal Engine-t használom már most is renderelésre, így legalább azt nem teljesen a nulláról kéne megtanulni. Viszont ehhez C++ kéne, amiről úgy tudom nem egy kezdőbarát nyelv, illetve nem tudom mekkora piaca lehet ennek itthon, nem sok álláshirdetést látok.
Másik ami érdekelne még, az az Android fejlesztés. Abban annyi tapasztalatom van, hogy nagyon régen, akkor még Unity-ben visual scripting-gel "írtam" egy nagyjából Flappy Bird bonyolultságú játékot hobbiból, amit egy darabig elérhetővé tettem Play-en. Meg egyszer Java-ban, tutorialokat követve meg stackoverflow-ra támaszkodva csináltam magamnak egy olyan "youtube appot", ami gyakorlatilag csak egy olyan webview volt, ami lezárt képernyővel is játszotta a médiát...
Vagy még a frontend webfejlesztés, de az meg gondolom borzasztó telített lehet és a 3 közül az érdekel a legkevésbé. Viszont megtanulni valószínűleg azt lenne a legegyszerűbb.
Szerintetek melyik lehetne a legjárhatóbb út ilyen háttérrel, 0,5-1 év alatt lenne egyáltalán realitása bármelyikből egy piacképes tudást felszedni? Vagy 30 felett ne nagyon erőltessem már inkább én se?
-
dabadab
titán
válasz
AssAssynn #20006 üzenetére
Ez önmagában egyáltalán nem újdonság, a szoftverfejlesztés talán a legagresszívebben automatizált munka, az elmúlt lassan száz éve arról szólt, hogy jöttek az újabbnál újabb eszközök, amivel meg lehet takarítani valami programozói munkát, ennek ellenére ma jóval nagyobb kereslet van fejlesztőkre, mint mondjuk 1960-ban
-
Voy15
tag
válasz
AssAssynn #20007 üzenetére
Ha csak pénzt akarsz keresni akkor szerintem hagyjad.
Ehhez azért szerintem kell némi elhivatottság is, ellenkező esetben nem fog működni a dolog.
Pár évvel ezelőtt mikor egy Hello World-del már felvettek _bárhova_ juniornak, akkor talán más volt a helyzet és relatíve kis energiabefektetéssel ellehetett helyezkedni, de ez azóta sokat változott, és gondolom azoknak a junioroknak a 95%-át már ki is szórták mostanra.
Az én rokoni/baráti körömből is sokan érdeklődtek akkoriban nálam, hogy mit-hogyan kéne tanulni, hogy sok pénzt keressenek az "IT-ben".
Egyetlen egynek sem sikerült, nem is értem miért.
Volt aki az any key-t is a billentyűzeten kereste. -
nevemfel
senior tag
válasz
AssAssynn #20007 üzenetére
Én sem vagyok matekzseni, sőt, elég távol állok ettől, de 30 éve foglalkozom szoftverfejlesztéssel. A szoftverfejlesztés összetett dolog, sok mindent kell megtanulni, érteni, felfogni záros időn belül ahhoz, hogy használható dolgokat tudj produkálni. Ha nem elég magas az IQ, akkor szinte lehetetlen, illetve ha idősebb korban vagy, akkor sokkal nehezebb egy csomó új dolgot megtanulni.
Olyat már láttam, hogy valaki 20-25 éves korában váltott szoftverfejlesztésre, és sikerült neki a dolog, műszaki főiskola, egyetem, mindenféle komolyabb műszaki háttér nélkül. 30, 40 év felett egy ilyen példát sem láttam még. Ami persze nem jelenti azt, hogy ilyen eset nincs, de hogy ritka az ilyen, az biztos.
-
nevemfel
senior tag
válasz
AssAssynn #19992 üzenetére
Mit gondoltok érdemes még manapság programozással foglalkozni, vagy az AI kifogja szorítani teljesen a jövőben?
Nem fogja kiszorítani. Az egyszerű kódgeneráló munkafázisokat már most kiszorították a különféle szoftverfejlesztési eszközök használatával, amiknek egy része szintén AI szerűen működik. Az összetett problémákat nem tudja az AI megoldani.
Másik, van olyan programnyelv, amit a gyökereknek is ajánlanátok tanulásra?
Attól függ, mit értesz "gyökerek" alatt. Kell egy minimális IQ ahhoz, hogy egyáltalán érdemes legyen belevágni. Másrészt kell, hogy legyen valami technikai érdeklődés, mert ezen a területen seniorként lehet jól keresni, ahhoz meg hosszú évek-, évtizedek kellenek, tanulással és tapasztalással.
-
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Dell Inspiron 5406 2-in-1i5-1135G7 16GB DDR4 3200 512GB NVME 14" FHD Érintőkijelző W11Pro
- Eladó MacBook Pro 14" M1 Pro (2021) 16/512 99% akku Makulátlan állapotban!
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- Eladó garanciás,új állapotu projektorom kihasználatlanság miatt!
- Acer Nitro V ANV15 - 15.6"FHD IPS 144Hz - i5-13420H - 16GB - 512GB - Win11 - RTX 3050 - 2,5 év gari
- BESZÁMÍTÁS! MSI B550 R7 5700X 32GB DDR4 500GB SSD RTX 3070 8GB ZALMAN Z1 Plus Be quiet! 650W
- Bomba ár! HP ProBook 430 G3 - i5-6GEN I 8GB I 256SSD I HDMI I 13,3" HD I Cam I W10 I Garancia!
- LG 65C3 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- Gamer laptop felvásárlás Magas áron, gyorsan és egyszerűen!
- LG 55C4 - 48" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged