Évek óta slágertéma Magyarországon a programozóképzés és azok a páratlan lehetőségek, amelyek az elképesztő mértékű munkaerőhiány miatt feltárulnak az ember előtt, ha programozásra adja a fejét. Nem csoda, hogy cégek sokasága repült rá a témára, majd üzletet alapoztak arra, hogy az egyetemi képzésnél rövidebb idő alatt bárkiből junior programozót faragnak. Viszont időközben a fejlesztőcégek óvatosak lettek, a világban zajló makrogazdasági folyamatok nem kedveznek a juniorok elhelyezkedésének: beszűkültek a lehetőségek.
Forrás: https://index.hu/gazdasag/2019/08/22/green_fox_programozokepzes_junior_…
Mondjuk a cikkben megszólaltatott végzett hallgatók beszámolói és a képző cég beszámolója ellentétes egymással, szóval mindenki derítse ki, kinek hisz.
Hozzászólások
Olvastam ma reggel. Nem vagyok meglepve. Írni egy működő kódot és írni szép működő kódot kb 10 év gyakorlati különbség. Továbbá írni kódot és meglátni a valóságban a mintát valamint azt algoritmizálni, megtervezni a szoftver szerkezetét már a tapasztalattól függetlenül is csak kevesek kiváltsága legalábbis alkalmassági szinten.
Nem is arra kellenek, hanem a kulimunkára.
Pont úgy fognak járni mint az építőiparban a tucatmunkát végzők: amint beüt egy pici visszaesés rögtön utcán lesznek.
--
Gábriel Ákos
Ez a tanfolyam semmiben nem kulonbozik egy OKJ-s hegeszto tanfolyamtol. Ott is olyan fizukat dobnak be mint amilyen az egyik ismerosomnek volt (a London Eye-on dolgozott valami specialis hegeszto varazslokent) csak azt felejtik el ,hogy ezek az emberek vagy termeszetes tehetsegek tehat kb 100.000-bol 1 vagy mondjuk van 30 ev tapasztalata a szakmaban.
Aztan a befizetett penz es a suli elvegzese utan valahogy nem jonnek a melok illetve barhova jelentkezel kb korberohognek...
Naja...
"Túl kevés volt a cég, olyan tíz körül, ezek nagy része Budapest és akörüli cég, de volt túl nagy és szörnyű cég, amely robotokként dolgozó programozókat keresett."
Egyébként látható sok területen, piaci munkalehetőség, képesség, fizetőképes kereslet hiányában inkább oktatni kezdenek vállalkozások. Remekül meg tudnak élni a sokszázezres tanfolyamok díjaiból, kb alapismeretek mellett, azok oktatásával. Ezeknél a felkapott fejlesztő képző cégeknél annyi a csavar, hogy a munkaközvetítéssel kombinálták.
Mint a Linux Akadémia DevOps Akadémia :)
Szerintem aki alkatilag, szellemileg, motivációban alkalmas az informatikai munkára, az kigyúrja magát, csak annyira van szüksége, hogy a kezdőlökést megkapja, és erre bármelyik IT-s kulimunka megfelelő. Ha nem, akkor meg hiányzik valami, ami miatt így sem, úgy sem fog menni a dolog.
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene
+sok
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
True.
Van nálunk egy srác, aki egy gyorstalpaló után érkezett hozzánk egy éve. Nem vágja az elméletet, a bubble sort-ot, vagy a formális nyelveket, de rengeteget fejlődött, és hasznos eleme volt a csapatunknak, most pedig egy másik projekten bizonyít. Egyik se kulimunka. Egyrészt akarja, másrészt van benne valami amitől fogékony rá. Pedig pszihológiát tanult, és nulla programozási tapasztalattal indult neki a pályának.
Ezzel szemben két srác is volt nálunk, aki végigjárta a "hivatalos utat". Egyetemen programozni tanultak (nem tudom milyen szakon), de egyszerűen alkalmatlanok voltak rá, nehezen értették meg a feladatokat, folyton támogatni kellett őket, ami minket is csak lassított. Pedig ők tudták mi az a turing gép :) (legalább is egyszer meg kellett tanulniuk)
Persze nem azt mondom, hogy a gyorstalpalók jók, mert hiába vannak jó példák, végül a cég az aki szűr, és veszít pénzt azokon akik nem elég jók a feladatra.
Az egyetlen sort amit ertek az a bogo, mehetek hozzatok dolgozni?
--
"You can hide a semi truck in 300 lines of code"
A Scientific American a 80-as évek második felében megjelentetett egy cikket. Azt vizsgálták, hogy kik a legjobb szoftveresek. Az előképzettség nélküli bölcsészek kerültek ki győztesként. :-D
Az az ember, aki nem érti meg a feladatot, nem tud megfelelő eszközt és megoldást találni, vagy elmondok neki tíz mondatot, de nem képes sem megérteni, sem megjegyezni, az csak segédmunkásnak való. Egy szoftveres tanfolyamon vagy akár egyetemen megtanulhatod a kalapács és véső fogalmát és használatát. Utána lehetsz szobrász, villanyszerelő, kőműves vagy segédmunkás. Napjainkban már igazi segédmunkás sincsen (itt most szó szerint), és úgy látszik, hogy ez begyűrűzött a programozó szakmára is. Ha valami jól működő dolog kell, akkor maradnak a 40+, vagy inkább a 40++ kollégák, - ha éppen ráérnek, vagy egyáltalán szeretnének óvodában dolgozni. ;)
mindegy
Nekem a legelső rendes IT-s munkám úgy zajlott hogy majdhogynem rátörtem az ajtót egy IT-s cégre ahol egy rokonom dolgozott, és elértem náluk hogy meghallgassanak. Elmondtam hogy lelkes érdeklődő vagyok, iszonyúan szeretnék tanulni, tapasztalatom nincs, pénzt alig kérek, és mindent igyekszem majd felfogni / megérteni, csak engedjék meg hogy velük dolgozhassak. Aztán ott maradtam 3 évig, felelősségi köröket kaptam, root accesst éles rendszerekhez, fejlesztettem, BA-kkal beszélgettem, tesztelőket támogattam, meg mindenféle. Hasznos kickstart volt. :)
Azt hiszem ezt nem is érdemes másképp csinálni. Ha az ember el akar jutni a mezeinél valami jobb szintre, akkor az nagyon sok áldozattal jár. Direkt nem írtam IT-t, mert szerintem ez az élet minden területére igaz, nálunk az informatikára. :)
Biztos, hogy nem én gonoszoltam le!
Nem mindenkinek van rokona IT cégnél...
Nem mindenkinek van rokona IT cégnél...
Nem azért vettek fel mert bárkinek is a rokona voltam.
"És nem is az a lényeg, nekem a mondandód át is jött.
Biztos, hogy nem én gonoszoltam le!
Persze hogy nem mindenkinek, nekem sem volt. Én azt hiszem sikerült megjárnom az önszopatás minden szintjét, mire eljutottam egy használható szintre. Pénztelenség, depresszió, lesajnáló szemek, stb. De csak mentem előre, mert tudtam, hogy nem akarok mást csinálni. Maximalista vagyok, ezzel sem egyszerű élni, dolgozni, mert nekem semmi sem elég jó, sokáig a saját értékeimet, tudásomat sem ismertem fel. Tehát nem tudtam az IT-s táplálékláncban elhelyezni magam. De legalább most már ott tartok, hogy a havi nettó 500 000 kevés, felette indítom az alkut, és gyakorlatilag azt a projektet viszem el amit akarok. Háromból kettőt simán viszek.
Egyébként a kálváriámnak még ma sincs vége. Folyamatosan jöttek törések az életemben, amik gyakorlatilag visszalöktek anyagilag, lelkileg a nullára. Ugyanakkor szakmailag folyamatosan fejlődtem. Valami nyomi átok miatt az életem küzdelem, de még itt vagyok, és amíg meg nem halok kurvára nem adom fel az álmaimat! :)
Biztos, hogy nem én gonoszoltam le!
Keep it up :)
Hozzam kerult junior fejleszto ilyen (hasonlo, de nem a greenfox) cegtol, nem volt vele gond, beletanult abba amibe kellett, elegedettek voltunk vele. Igaz, nem is kulimunkara alkalmaztuk.
Ja, csak az a helyzet, hogy a rutinmunkára is olyan ember kéne, aki érti is, hogy mit csinál. Mert bármikor eljöhet olyan munka, ami nem rutinfeladat.
Mint a sebész. Attól, hogy elvégzett már életében 500 vakbélműtétet, attól még mindegyiknél előjöhet olyan komplikáció, ami miatt tényleges szakértelem kell, és hozzáértés.
Vagy hogy egy hasonlatot mondjak még, attól, hogy valaki össze tud szerelni egy lapraszerelt bútort, még nem lesz asztalos.
Ezek a cégek meg azt mondják, hogy megtanítunk 3 séma szerint bútort összeszerelni, és máris jól menő asztalos lehetsz.
Francokat.
"Pont úgy fognak járni mint az építőiparban a tucatmunkát végzők: amint beüt egy pici visszaesés rögtön utcán lesznek"
Az epitoiparban? Abban az orszagban ahol azzal viccelunk, hogy evek mulvara van a komuvesnek idopontja? Te melyik gazdasagi hazugsaggyarat nezed?
Raadasul az IT-ban is megis milyen visszaeses lenne az automatizalas koraban? Visszamegyunk a papiron pecsettel jegyzett tozsdei papirokhoz, "mert most visszaeses van", vagy hogy gondolja Szakerto Ur?
A beruházások azok, amiket a cégek (vagy akár háztartások) legelőször visszafognak a gazdasági környezet változása esetén (ami egyébként a kapitalizmus velejárója): ez az építőipart érinti legelőször.
Szerinted az IT-t nem érinti az automatizáció?
Nézz körbe, hogy milyen infrastruktúra és fejlesztő eszközöket használtunk 15 évvel ezelőtt és most.
Mondjuk itt nincs ellentmondas, 10 eve masszivan felfele megy a buli, majd akkor nezzuk meg ujra a komuvesek naptarat, amikor bedol a gazdasag, es ottmaradnak a felkesz hazak. :)
Az inkább 4 év, nézd a vokumeneket:
https://www.ksh.hu/docs/hun/xstadat/xstadat_evkozi/e_oe001.html
Több ismerősöm van, aki már gyerek korában 10-12 évesen kezdett el kódolni C64-en pl, vagy XT-n, 286-oson, basicben, majd assemblyben, C-ben, Pascalban, Clipperben, stb... Később C++, Java, stb... Kb behozhatatlan tapasztalatuk, alapismereteik vannak még azokkal szemben is, akik egyetemen-főiskolán, vagy közvetlenül utána kezdenek el programozni. Ezzel szemben hallottam vezetőt úgy nyilatkozni, hogy szerinte 1-2 év kitanítani rendesen egy programozót. Gondoltam magamban, hogy mennyire nincs igaza...
Nekem a kis süldőként C64-en programozás kimaradt teljesen, én gimi végén kezdtem csak el érdeklődni a terület iránt és igazából egyetem alatt rázódtam bele.
Saját környezet alapján ezek a gyerekkori tapasztalatok nem ultimate előnyök azért. Igazából sokkal többet számít az, hogy milyen alapanyagból lett gyúrva az emberünk, mennyire gyors a felfogása, mennyire szorgalmas. Ja, meg a jó soft skillek se hátrányok, sokszor sokkal messzebb lehet jutni velük, mint a pure szakmai tapasztalattal.
Ismertem olyat aki végigkódolta a gyerekkorát, akkora volt az arca emiatt mint a ház, egyetemet első év után ott is hagyta a fenébe ("értelmetlen fasság az egész"). Azóta is meg van rekedve kb. ugyan azon a szinten.
Meg ismertem persze olyat is, aki nagyon sokra vitte, de ő pl. biztos vagyok benne, hogy ha csak egyetemen kezdi, akkor is sokra vitte volna.
En is C64-el kezdtem. Lattam mar mindenfele embert, olyat is akit atkepeztek ilyen cegnel. Altalanossagban elmondhatom, hogy teljesen mindegy, hogy hol tanult es milyen kepesitese van, az szamit, hogy mennyit hajlando beletenni (ezt mar irtak masok is). Ez meg eleg erosen ember tipus fuggo.
Na marmost aki C64-en tudta tolni, az hidd el sokat tett bele :)
#nostackoverflow #nogoogle #nointernet #friends #community #books
Az, hogy valakinek kesobb elment a kedve, na hat van ilyen... Ha szetnezel a veled vegzettek kozott, ott is van am olyan, hogy a vegen ugyved lett belole vagy akarmi mas. Van gepesz kollegam, aki zsenialis Java fejleszto.
Van egy ismerosom, akirol azt gondoltam sose lesz belole semmi, aztan 3-4 ev alatt akkorat fejlodott, hogy leesett az allam.
Aztan volt egy kozepes fejelszto, aki talalkozott az elvarasokkal es nagyon gyorsan adaptalodott. Otthon tanult, nem szegyelt kerdezni...
Szoval megtanultam egy eletre, hogy nem kell beskatulyazni senkit, midnenkinek jar a lehetoseg (meg a "gyorstalpalonak" is)!
Én is láttam ilyet, átment könnyített szakra, tudását nem ismerem, de eladta magát egy multinál.
Volt korosztály akinél számított, apuci tolt-e gépet a gyerek elé vagy sem. Sajna ebbe estem és elém nem toltak, de nem az ő hibájuk, elég rosszul is alakultak a dolgok.
"C64-en pl, vagy XT-n, 286-oson, basic" tapasztalatok értéke egészen pontosan nulla a mai világban. Sőt egyeseknél egyenesen hátrány a hülyén megtanult paradigmák miatt.
Ha magas szinteken repkedsz, akkor talan igen, de meg akkor is ad egy jo szemleletet.
A tapasztalat/alapismeret itt nem a paradigmak miatt ertekes.
Programoztál már mikrokontrollert?
Már az akkumulátorok töltéséhez is mikrovezérlőt használnak. Ott aztán lehet ám java-zni 16/32/64 kbyte-on.
Felépítésükben a C64-re hasonlítanak, csak sokkal kényelmesebb programozni. A magasszintű nyelvekkel semmit sem érsz: C és C++ van.
És?
Az autodat, kazanodat, mosogepedet ilyenek mukodtetik :D
Nem arrol van szo, hogy mindnekinek ertenie kell a low-level dolgokzhoz, de ez is jo moka, nem nulla az erteke...
Igen, értem, hogy működtetik. Kérdés viszont továbbra is fennáll, hogy és akkor mi van? Legtöbb szoftverfejlesztő nem ezen a magasságban dolgozik. Nem azt mondom, hogy nem kell róla tudni, mert néha tényleg van, hogy érteni kell, hogy mi történik a vason, csak az idő 99,99%-ában irreleváns.
De tényleg érdekelne, hogy milyen olyan alapvető tudás van egy mikrokontroller kapcsán, ami alapvető, fundamentális ismeret mondjuk egy webalkalmazásnál? Vagy egy microservice infrastruktúránál? Egy mobilalkalmazásánál, vagy desktop alkalmazásnál?
Ellenben még él 10 évvel ezelőttről a C64/Amigan szocializálódott bitbaszó volt kollégámról az emlék, aki agyon akart optimalizálni egy adatbázist, mert egy plusz kapcoslótábla számára nagyon pazarlónak tűnt és inkább egy char tömbben próbálta letárolni, hogy melyik termék melyik kategóriában van. Ez egy PHP+MySQL-es weboldal volt. Csak aztán egyszer csak több lett, mint 255 kategória...
A C64 a számítástechnika egy fejlődési szakaszról szól. Működőképes számítógépet mindenkinek: a mai számítástechnika alapja akkor született.
A C64 BASIC-ben minden változót két betűvel lehetett jelölni. AB, BC, DA, ... Miután megírtak 1000 soros kódokat, rájöttek, hogy ez baromság, a PROFI ASSEMBLY-nél már 8 betűs neveket is lehetett használni.
Az akkori világban a C64 technikai csoda volt. A világ túlhaladta, voltak hibás beidegződések: nem kell spórolni a SPACE-eken, mert nem kell 64k-ba beférned.
Túlhaladta a kor, de akkor korszakalkotó technológia volt.
Azért spóroltál a bitekkel, mert kevés volt. Kellett.
De tényleg érdekelne, hogy milyen olyan alapvető tudás van egy mikrokontroller kapcsán, ami alapvető, fundamentális ismeret mondjuk egy webalkalmazásnál? Vagy egy microservice infrastruktúránál? Egy mobilalkalmazásánál, vagy desktop alkalmazásnál?
Nincs ilyen. En csak arra probaltam ravilagitani, hogy az nem igaz, hogy nincs relevanciaja az ilyen tudasnak ma.
Azt en sem ertem, hogy az en idomben miert tomtek brutalisan az agyakat x86 assembly-vel es meg sok mas baromsaggal, a programozok tobbsege nem erre kell, nem fognak safety RTOS-eket irni.
A low level cuccok csak azert kellenek, hogy ra lehessen pakolni mindent, ami magasabb szintu, alapvetoen szvsz ez gazdasagi es szakmai cel is.
Lehet ugy nezni, hogy kellenek a foldmunkasok, hogy alapot assanak. Persze lehet ugy is, hogy a sok idiota azt sem erti, hogy mi tortenik a dobozon belul de nyomkodjak ...
Akkor mi van ? Van akinek ez jon be, jol van ez igy... :)
Hát, igen, 80386-os architektúra, az is korszakalkotó volt.
Emlékszem, megjelent a 80386-os 1985-ben. Igazi 32 bites rendszer volt, multitaszkos, ugyanazon a címet több procesz futhatott, védett mód is megjelent, a proceszek nem írhatták egymás adatait, memória swapping lemezről.
Hatalmas találmány volt: a 80386 talán az internettel vetekszik, akkora ötlet volt.
A vicc az, hogy 1993-ra volt képes a Microsoft eljutni odáig, hogy tisztán 32 bit alapon lefejlessze a Windows NT-t. 8 év kellett ahhoz, hogy szoftver legyen a processzorra, mert mindenki a 16 bites DOS módban használta.
:)
"Hatalmas találmány volt: a 80386 talán az internettel vetekszik, akkora ötlet volt."
A védett mód, a virtuális memória, az mind-mind létezett már előtte, IBM System 360 Model 67, 1965-ből, azaz 20 évvel az Intel 80386 már virtuális memóriát használt, és védett módban szeparálta a processzeket. Maga a virtuális memória koncepciója 1956-os, a Berlini Műszaki Egyetemről ered.
Egy kicsit még ismerkedj a számítógépek történetével.
Félő, hogy nem férne be a szobámba. :(
Meg se tudtam volna venni az egész életem keresetéből sem.
És még szar is, mert a vidóz se fut rajta.
Ráadásul a buta NASA is inkább 386-ot rakott a zűrhajókra.
Pedig még én is csináltam védett módot 8085-re is. Gondolom, a virtuális memória is ment volna.
Nem is értem, hogy az Intel meg az IBM mit fejleszt az utóbbi időben, mikor már minden régen kész volt.
Barátunk tán a desktop gépekre gondolt vón'?
FYI: egyetemen ma is tanítanak x86 ASM-et, digitális technikát és elektronikát. Aki akarja nagyjából az áram szintjéig lehet fogalma, hogy mi történik a dobozon belül.
Ja, de az a mernokinfos/vilanyos szak ;)
De tényleg érdekelne, hogy milyen olyan alapvető tudás van egy mikrokontroller kapcsán, ami alapvető, fundamentális ismeret mondjuk egy webalkalmazásnál? Vagy egy microservice infrastruktúránál? Egy mobilalkalmazásánál, vagy desktop alkalmazásnál?
Tényleg semmi. Aki ezekhez a fejlett technológiákkal tisztában van és dolgozik vele, igen magas absztaktziós szinten, az általában egy betűt sem tud kiírni. Pontosan úgy jár, mint a matematikaprofesszor, akit a ravasz trafikos egy doboz gyufa vásárlásakor jól átver. ;)
Magasabb szinten már semmi sem számít, és a C64-hez képest (megsaccolom, mert én 8085-tel dolgoztam) manapság legalább 4 milliószor gyorsabbak még a házi számítógépek is. Ha annyi millióm lenne, ahányan emiatt a tévhit miatt szar terméket állítottak elő, akkor a Holdon szivaroznék a pálmafák allatt. :-D
Az általad hozott bitbaszó példa nem túl jó, legfeljebb a kollégád nem tudott továbblépni. Mert ha továbblépett volna, akkor most devops lenne. Érdekes, hogy pont amikorra kialakult a roppant fejlett szoftvertechnológia, keletkezett egy olyan szakma, amely illeszti a nagy elméleteket a vashoz. :-)
Éppen ebben a pillanatban is egy php, java, C#, stb. stb. profi szoftveres munkáját kerülgetjük, mint a kutyaszart. Egy desktop alkalmazásba kellene beolvasni usbhid-ről egy adatsort, majd megjeleníteni. Az első blokk után következik az ötvenedik - eddig sikerült eljutni. Triviális a megoldás, ehhez hardveres bitvadász kell! Nonemá'!
Én többnyire Java-ban programozok, abban vagyok a legjobb, és abban tudok a leggyorsabban megoldást adni egy szoftveres problémára.
De diákkoromban hobbiból x86 assembereztem és felnőttként hobbiból és melóból is írtam ATMegára C/ASM hibrid programokat. Illetve egyéb C nyelvű beágyazott projektekben is részt veszek. Így ismerem ezt a világot is.
És pontosan azt látom, hogy akik nem értik hogy mi van a lentebbi rétegekben, azok írják a béna megoldásokat magas szinten. Hiába a Java virtuális gép, az alatta lévő vas hajtja végsősoron végre az utasításokat, és tudni kell, hogy hogyan. És akkor pont azt az adatot fogjuk primitív tömbbe, vagy akár direkt ByteBuffer-be tenni, amit ahhoz kell, hogy rendesen működjön a program.
A legtöbben ott elvéreznek, hogy megsaccolják, hogy mennyi adat és mennyi CPU kell egy feladatra. Vagy hogy megérezzék, hogy hol van a szűk keresztmetszet. Pláne hogy megmérjék :-). Ha van egy becslésed, hogy egy feladatra hány órajel kellhet, akkor már tudod is, hogy érdemes-e optimalizálni? Abban a tartományban vagy-e, ahol kis erőfeszítéssel tízszerezni lehet a sebességet, vagy ott ahol vért izzadva duplázni? Nem mindegy, mert az előbbi esetben áramot pazarolsz (ma leginkább ez a jellemző), a másodikban pedig fejlesztőt.
Összességében a mennél több területről jövő tapasztalatnak óriási értéke van, pláne amikor komplex rendszereket kell tervezni úgy hogy még működjenek is, ne csak a tervezőasztalon nézzenek ki jól. És ebbe a tapasztalatba beletartozik a bitmachinálás is.
Pont mikor ide irtam vettem eszre az egyik kollega kodjaban, valami ilyesmit:
assertTrue(String.format("%02x", commandCode).equals("0a"));
:D
Azert jo ez a tudas, mert valoszinuleg te ilyet soha nem kovetnel el, persze normalis Java fejleszto sem. Namost ha latott volna egy cpu utasitaskeszletet, azonnal leesne neki, hogy ezt lehet egyszerubben is.
ebben két hiba is van:
- felesleges string konvertálás
- meg true / false assert, amiből nem derül ki, hogy 0d jött-e, csak hogy nem 0a
Egy IBM-es kolléga frappáns mondása volt: Az IBM még nem tudott akkora processzort gyártani, amin a java kielégítő sebességgel futott volna. ;) (Ez nem személyeskedés, csak eszembe jutott.)
Azt szerettem a POWER+AIX szerverekben, ha még a gép a boltban is volt, de már meg lehetett jósolni a feladat futásidejét. A becsültnél legfeljebb 30%-kal volt gyorsabb. Próbálj meg hasonlót megkérdezni egy Windows rendszermérnöktől! :-D
Ugyanitt adtam ki úgy feladatot, hogy az eredeti futásidő 19 óra volt, de a cél 14 perc 2x gyorsabb gépen és 1/3 adattal. A végeredmény: 14,0 perc. Az ok pedig nem bitvadászat, hanem át kellett térnünk 24 óránkénti futtatásról 6 órára. A teljes rendszer futásideje ekkor már elérte a 26 órát, (24 óra alatt ;), és egy hónapon belül tartott a 130 felé!) de a gép cseréje nem lett volna elegendő. Ennek a végeredménye 2 óra lett. A fenti 14 perces program - egy kicsit gyorsabb hardveren, az eredeti adamennyiség 7x-esével 65-90 másodpercig futott, mert kicsit gyorsítottam rajta. Az össz futásidő 17 perc. Ezt túl gyorsnak is találták - egészen az első olyan üzemzavarig, amikor kiderült: az újrafuttatás gyorsabb, mint a backup betöltése. Persze pont ezért backup sem volt - ez tervezési kérdés. ;)
Félreértés ne essék, nem hencegni akartam!
Csak az a kérdésem, hogy milyen végzettség kell ilyen feladatok megoldásához és hol lehet megszerezni?
Egy régesrégi csapatban én voltam a "hardver szakértő". A clipper program már órák óta dolgozik...
- Gyere csak ide és hallgasd meg a winchestert!
(Kitt-katt-kiti-katt...)
- No, mutasd a programot!
...
- Ezt a három sort rakd át ide!
(Nincs katt, 10 perc alatt lement.)
Nem hencegtél. Nem a te érdemed, hogy elbaszott rendszert örököltél. :)
"akik nem értik hogy mi van a lentebbi rétegekben, azok írják a béna megoldásokat magas szinten. "
Ez szükséges, de nem elégséges feltétel. Ha nem tudod, hogy a két réteg váltásánál mi történik - pl. mit csinál egy fordító, JIT-ter, stb. - akkor ugyanúgy meg van szexualizálva az egész.
Kedvencem az "én tudom mi a gyorsabb a processzoron" kóder, aki elkezdi mikrooptimalizálni a kódját, mert ez vagy az az ASM művelet gyorsabb. Aztán meg ezzel keresztbe tesz a fordítónak, mert az meg a tipikus kódfordulatokra van felkészítve és arra egy lépéssel hátrébbről nézve tudna valami jobb megoldást odafordítani.
-- dupla --
Nálunk már az egyetemen is tanították 20 éve, hogy a program 5%-ában megy el az idő 95%-a. Ha nem a megfelelő 5%-ot optimalizálod, akkor igazából semmit sem ér az egész.
A helyes algoritmus az, hogy érthetően, átgondoltan, logikusan megírod a programot. Ahol pedig a perfmon kimutatja, hogy lassú vagy, ott optimalizálsz.
Ellenkező esetben olvashatatlan kódod lesz, jutalmul meg 1%-kal gyorsabban fog futni a rendszer.
A karbantarthatóság, "jövőtállóság" az esetek 99+%-ban többet ér a futásidőnél.
Itt egyesek azon az 1%-on lovagolnak.
Segítek: ha a kód 99%-t karbantarthatóra írod meg akkor arra az 1%-ra 5x annyi időd lesz mintha az "egészet optimalizálod".
Ha többen dolgoztok ugyanazon akkor ez a hatás hatványozottan jelentkezik.
--
Gábriel Ákos
A mesében. ;)
Egy (sok) tipikus rendszeren szerzett tapasztalataim alapján, ha az 1 óra futásidejű feladatot 15x gyorsabb gépen sikerül minimum 20x lassabra megcsinálni, akkor bármelyik testnyílásodb is felhelyezheted a perfmont.
A forró pontoknak nem a profilozáskor kell kiderülni. Elég hozzá gondolkodni, megismerni a kezelendő adatokat, kapcsolatokat stb. Ha valaki nem látja át, akkor csak segédmunkás.
Az algoritmus sok esetben nem elég, de a cég sem fog venni 1000x gyorsabb gépet.
Szóval az egyetemen is taníthatnak sok baromságot. Pont a fenti performanciával jellemzett rendszer készítésekor szálltam vitába egy egyetemi tanár adatbázis szakértővel. Nekem lett igazam, de nem számítottam arra, hogy ennyire. ;)
"Felépítésükben a C64-re hasonlítanak, csak sokkal kényelmesebb programozni. A magasszintű nyelvekkel semmit sem érsz: C és C++ van."
Mert C64-et lehetett C és C++ nyelveken programozni?
Arduinot már programoztam 8-bitest is, szerintem egyáltalán nem C64 világ de cáfolj meg! Ez utóbbit csak emulátorból ismerem felületesen.
Amikor öreg motorosok lelkesen belemerülnek első számítógépük csodálatos világának mesélésébe, mindig spriteoknál meg hasonló korabeli grafikai varázslatoknál kötnek ki ami nagyon nem mikrokontroller világ. Nyilván lehetett volna fűtést is szabályozni C64-ről, mégsem erről szólnak annak a kornak a nagy legendái.
> Mert C64-et lehetett C és C++ nyelveken programozni?
Én a C nyelvet C64-en tanultam meg, a C++ akkor még igencsak gyermekcipőben járt. Pascalban is lehetett egyébként programozni.
Miért gondolod, hogy a C64 más volt? Alacsony órajel, bármit ráköthettél a buszra, úgy forrasztottál, ahogy nem szégyelltél. Nem ugyanaz 1 MHz-es buszra kütyüt csinálni, mint 300 MHz-re. Órajelciklusra tudtad, hogy mi mit csinál. Egy mag van, interruptok kezelik a párhuzamosan történő eseményeket, nincsenek taszkok, kiszámítható, nem érnek meglepetések, könnyen kifagy, ...
Megnézel egy AVR-t, nincs olyan, hogy "start_timer" függvény. Pont ugyanúgy programozod Atmega328P alatt a timert, mint C64-en a $DC00/$DD00-n elhelyezkedő CIA chipeket. Kézzel gányolsz a regiszerekben. Az Arduino a timerek funkcionalitásának 5%-át használja ki. Ha valamit akarsz, le kell menni az IO regiszterek szintjéhez. Egy mai PC kirúg téged a fenébe, ha IO regisztereket akarod piszkálni. Az a driver feladata.
Egy mai PC-n fogalmad sincs arról, hogy mi az a DMA. A driver-ek elintézik neked az egészet, nincs kapcsolatod a mikroprocesszorral.
A mikrovezérlők világa hardver közeli világ, ahol érzed a rendszer lüktetését. Ne gondold, hogy másképpen működik egy 8 bites AVR, mint a 8 bites C64.
És ott van a memória és a sebesség. Szinte nap mint nap szembesülsz azzal, hogy kevés van belőle. Kísérteties hasonlóság amikor egy stringet nem RAM-ban, hanem a FLASH-ben tárolom, mert kevés a memória. Nézegetem az assembly-t, látom, hogy a gép 32 bitesre fordította, pedig 8 is elég lenne, módosítom a kódot és gyorsabb is lesz.
Munkahelyen ha short int-et, vagy unsigned char-t használnék ciklushoz, minimum hülyének néznének. Miközben egy C64 alatt ez mindennapos.
> Munkahelyen ha short int-et, vagy unsigned char-t használnék ciklushoz, minimum hülyének néznének.
Mert ott vannak a szabványos int8_t és int16_t névváltozatok, vagy akár az uint8_t és uint16_t!
32 bites és nagyobb gépeken az int8-nak és int16-nak jóformán semmi értelme. Elvétve használod. Még ESP8266-on, STM32-n is int-et használok, mert gyorsabb.
A portolhatóság miatt szoktam ezeket használni. Ha emellett betartunk még pár szabályt (amik nem is olyan egyszerűek, lásd MISRA), akkor a leírt kód pontosan ugyanazt jelenti minden platformon, nem éri az embert olyan meglepetés, hogy 8-ról 32 bites platformra váltva a programok elkezdenek nem működni. Persze ennek csak akkor van értelme, ha szándékban van, hogy más platformon is fogjuk futtatni a programot. Én mostanában a hobbi projektjeimhez is csinálok korrekt HAL-t, és PC-s szimulátort, összességében egyszerűbb így fejleszteni. (Kivéve a ledvillogtató szintű példaprogramokat.)
Arduinohoz van ilyen, amit ajánlanál?
Az Arduino nem ad ilyet magától, neked kell megvalósítani. A HAL réteget én mindig ott húzom meg, ahol éppen adja magát :-). Átalálban nem érdemes periféria szinten szimulálni, hanem magasabb absztrakciós szinten érdemes.
Pl ha fordulatszámot mérsz úgy, hogy input capture-rel méred az impulzusok között eltelt időt, akkor nem érdemes ezeket szimulálni, hanem a mért fordulatszám legyen az absztrakt API-n, amit megvalósíthatsz szimulátorban. És akkor lehet egy csúszkád, amivel a fordulatszámot állíthatod pl. De a szimulátorban nincsenek tickek, meg input capture.
Például van egy kis OLED képernyőm, ott nem szimulálom az I2C üzeneteket PC-n, hanem van egy memória pufferem amibe rajzolok (1 bit 1 pixel), és az API az, hogy azt mondom: ezt a puffert jelenítsd meg. Aztán interruptokon át kitolja a datát a képernyőre, és mikor kész jelzi, hogy kész. PC-n meg átmásolom egy másik pufferbe, átalakítom RGB-re, és kidobom a képernyőre.
(Tipikusan amik interruptban történnek, azok a HAL-ban vannak, tehát interruptot sem kell szimulálni, viszont cserébe többszálúságra szükség lehet.)
De ha azt akarnám szimulálni, ahogy mennek a bitek az I2C-n, akkor ott kellene meghúzni a HAL layert.
Vagy van 4 fizikai gombom, ott az az API, hogy le tudom kérdezni az állapotukat, vagy hogy be van-e nyomva.
Ha az Arduino alatt az Arduino IDE-t értjük, akkor elég nehézkes ezt megcsinálni. Úgy lehet, hogy ezeket az API-kat library-kben valósítod meg, a főprogramot is library-ban valósítod meg, és az INO-ban csak annyi van kb, hogy setupprogram(); loopprogram();
(Mert INO-t nem tudsz gcc-vel fordítani, a libeket viszont rendes C-ben kell megírni. Persze az Arduino preprocesszort is használhatnánk, de én nem úgy csináltam meg.)
És ha van egy rakás forrásfájlod, akkor úgy szervezed a kódot, hogy külön fájlban legyen, ami HAL, és külön ami platformfüggetlen. És ha ez megvan, akkor a HAL-t megírod szimulálva is, és ahhoz is írsz buildet. Tehát a forrásaid nagyrésze ugyanaz a két rendszerben, és ami ugyanaz azt tudod próbálgatni, vagy rendesen tesztelni PC-n. Ezzel csomó időt spórolsz, mert mire a mikrovezérlőre égeted a kódod, addigra már alapfunkciókat nem kell validálnod, hogy működik-e egyáltalán, meg nem kell "business logic"-ot debuggolnod.
Lehet tehát sokmindent kifordítva Arduino IDE alatt is csinálni ilyet, vagy talán egyszerűbb is kézzel írt makefile-okkal megírni mindent, amit Arduino alatt csinálnál. Az Arduino libraryt használhatod Arduino-n kívülről is sima Makefile projektekben is. Én mindkét megközelítést kipróbáltam 1-1 projektben és még mindig nem vagyok biztos benne, hogy melyik a nagyobb szívás :-).
A források nagyrésze tehát teljesen ugyanaz PC-n és mikrovezérlőn. Hasonló a BSP Board Support Package megközelítéshez, amit itt ismerhetsz meg: http://www.state-machine.com/quickstart/ a Lesson 22-től kezdve van szó RTOS-okról, amikbe belecsempészi a BSP fogalmát is, ami lényegében egy HAL. Érdemes megnézni, amit láttam ebből a sorozatból, az zseniális.
Én tovább bonyolítom azzal, hogy a HAL-t JNI-vel Java alá teszem, de ez már csak a saját dilim: Java-ban írom meg a GUI-t és onnan futtatom a teszteket is. De ezt már tényleg nem kellene terjesztenem, mert kicsit perverz :-)
Ettől kezdve nem is scifi, amikor a farmer megépítette a fészerben az űrhajót. ;)
Bocsi, ez csak poénkodás volt minden bántó célzás nélkül.
Azért csak elmodom a véleményemet és nem hiszem, hogy egyetértesz vele.
Ha már mikrokontrollerről meg hordozhatóságról beszélünk, akkor nézzük először a hordozhatóság oldalát!
Az a kérdés, hogy a mikrokonrollerre készült entitást mikor kell hordozni? Egy picike 8 bites mcu esetén előfordulhat-e olyan, hogy egy sokkal nagyobb platformra kerüljön ugyanaz a kód? Esetleg olyan jót írtál arduinóra, hogy át kell tenni rpire - és ott ugyanolyan perifériák lesznek-e?
Avagy mennyire kell egy 100 soros assembler programnak hasonlítania egy RTOS alá megírt szoftverhez?
Egy pillanatra zárjuk ki a hobbiprojektet, ahol rpivel ledet villogtatsz, aduinoval meg bonyolult számításokat és vezérléseket végzel, hálózatot és monitort hajtva. Vagyis tegyük fel, hogy az alkotóelemek megválasztása mögött üzleti döntések állnak.
Ha van egy határvonal a kis és nagy feladat között, akkor valószínűleg mindegyikhez a megfelelő eszköztárat érdemes használni. A kis feladatoknál zavaró, ha egy egyszeű programocskából operációs rendszer szerűen kezeled a perifériákat. Nagyobb rendszernél meg éppen igény van rá.
Ugyanide tartozik az embedded rendszer fogalma is, aminek a mibenlétét már oly sok topic taglalta, bár elég sokszínű véleménnyel. Mégis itt húzom meg a határt. Az embedded rendszeren mondjuk operációs rendszer fut, a kissebbeken meg firmvare, ami működhet önállóan vagy kapcsolódhat valamihez.
Eljutottunk a HAL és az RTOS fogalmakig. Ezek a rövidítések operációs rendszer és szoftver környezetben fordulnak elő. Kisebb rendszeren megírom pl. a TIMER1 inicializálását 6 utasítással, az indítást és leállítást meg 1-1 utasítással. Ezeket esetleg elrakom egy makróba, ha zavarnak. Másik mcu-ra vagy változatlan lesz a forrás, vagy írok egy másik makrót is. De csak egyszer, mert utána készen van. Tehát ezen a szinten az "alacsony szintű device drivert" csak egyszer kell megírni, de ez nem is az. Hiszen csak egy TIMER, ami megfelelően működik, lehet használni is. Utána a főprogramban (ok, legyen business logic ;)), már csak ennyi látszik: "írj az eepromba egy blokkot innen oda" vagy "küldj egy blokkot az usb-re innen". Ettől kezdve írhatod C-ben, de C# ban is. ;)
De ez nem HAL vagy device driver, csak függvény illetve szubrutin hívás.
A bonyolultabb főprogram részletet vagy függvényt - ha szükséges - megírom awk-ban és kipróbálom. Utána az awk scriptet bemásolom az assembler forrásba és átírom. ;) Se emulátor, se debugger.
Most már talán én sem tudom mit akartam mondani... ;)
A 100 soros assembler program az a LED villogtató kategória. Írtam, hogy ami kicsi, arra nem éri meg HAL-t meg szimulátort csinálni.
De a 8 bites mikrovezérlő kategória ennél sokkal többre képes - ahogy valaki helyesen leírta nagyságrendileg C64 szintű teljesítménye van. És bizonyos esetekben meg is éri ezekre a többletfunkciókra építeni. Ha bele lehet tenni a funkcionalitást egyetlen mikrovezérlőbe, akkor általában érdemes. Hobbiprojektnél is, mert nem kell összehuzalozni egy Raspberryvel az Arduinot, élesben megy nyilvánvalóan csökkenti a gyártás költségeit. Mondjuk egyszerre több dolgot kell mérni, és ezek alapján vezérelni, vagy van egy kijelző gombokkal. Ez még simán mikrovezérlő szint, de nem 100 sor lesz a program. Azért egy ATMega 2560-ba nagyon sokminden belefér, nézd meg hány láb és mennyi periféria, a harmadát sem kezeled 100 soros ASM-ből. Csináltam már olyat, amin egyszerre ment kommunikáció két másik modullal, ment valós idejű mérés, képernyő frissítés, gombkezelés és még nyomtatás is. És ez még a procinak meg sem kottyant, lehetett volna többre is használni.
A hordozhatóság nem csak azért fontos, mert tényleg másik processzoron akarod valaha is futtatni élesben, hanem azért mert így tudod szimulálni PC-n. Ami megint csak a móricka példák felett már határozott előny. Ha például van egy menű egy kis kijelzővel (4 gomb és kb 64 karakternyi képernyő periféria), akkor ott már elég sok kombináció lehetséges. Erre már érdemes állapotgépet (menű) és szimulációt is csinálni. Egyszerűen gyorsabb lesz fejlesztés közben a visszajelzés, ha nincsen benne az égetés, átülés a vashoz, stb a folyamatban.
De pont láttam már olyan projektet, amit 8 bites vezérlőről kell másikra portolni. Hardware obscolescence miatt meglepően sokszor kell portolni manapság, egy termék az élete alatt akár többször is új vezérlőre kerülhet. Sajnos nagyon gyors lett a hardverek kivezetésének a tempója.
Meg olyan is előfordul, hogy ahogy adják hozzá a funkciókat, a termék kinövi a vezérlőt, és akkor nagyobbra kell lépni. Mondjuk 10 évvel a termék indulása után. Ilyet is csináltam már, a megelőző módszerekkel már nem tudták uralni a komplexitást.
Automatikus teszteket is egyszerűbb PC-n csinálni, és automatikusan futtatni. Megint csak móricka példánál nagyobbra van ennek jelentősége.
Az is, hogy megírom a programot egyszer, és soha többé nem nyúlok hozzá, kicsiben működhet, de több évig támogatandó termék esetén nem lehet megcsinálni. Előfordulhat hogy újabb funkciót kell hozzáadni, vagy neadjisten hibát kell javítani. Ilyenkor egy több emberhónap értékű programot nem fognak újraírni azért mert bucko szerint azt úgy kell. Hanem szépen előveszik a forrásokat, átírják a HAL-t az új procira, és mindenki örül.
Mondjuk van egy új "divat", hogy a PC-n megcsinálják a szimulációt Julia-ban, majd azt rárakják egy rpi-re, meghívják a GPIO kezelő rutint és onnan megépítik a prototípust, kb ugyanazzal a kóddal. Mikor minden stimmel, akkor írják meg az élesben használható kódot mondjuk C-ben.
valaki helyesen leírta nagyságrendileg C64 szintű teljesítménye van
Csak nem helyesen. Eltekintve a speciális hangcsiptől és a nagyobb memóriától, egy mai szerkezet (PIC16/18, 8-16MHz utasítás-órajel) kb. 30x gyorsabb. Ráadásul a beépített periféria választék is olyan, hogy "minden van", akár egy 8 lábú tokban.
Nem is állítottam olyat, hogy 100 sor mindent kezel, hanem egy kérdés volt:
Avagy mennyire kell egy 100 soros assembler programnak hasonlítania egy RTOS alá megírt szoftverhez?
Már 85 óta állapotgép - de nem menü, hanem eseményvezérelt automata (FSM) alapú programokat készítek. Elég megírni az eseményhez tartozó akciót, ami általában rövid. Ha szükséges, lehet debuggolni, de minden esetben felesleges. Legfeljebb a "print" alapú követést vagy állapotkijelzést használom. Úgy is van USB, amihez elegendő egy HID terminál. Ha meg nincs, akkor soros port és putty. Itt egy kis példa, ami ugyan nem 100 bájt, de legfeljebb 94 utasítás. Hálózatra szinkronizált hiányzó impulzus detektor. Ha Sanyi kolléga lekapcsolja a villanyt a fürdőszobában, akkor még - jumper segítségével konfigurálhatóan - 2 vagy 4 percig megy a ventillátor. Ez egy eseményvezérelt végesállapotú gép, főprogram nincs. Ez a könnyebben olvasható C átirat. (Nem biztos, hogy működőképesek vagy komplettek az átiratok!) Debuggolni, szimulálni minek.
De a 10k méretű assembler program is így készül.
Sajnos nagyon gyors lett a hardverek kivezetésének a tempója.
Akkor ebben a Microchip sokkal jobb. Nagyon sokáig gyártja a mikrokontrollereket. Ha valami megszűnne, akkor van olyan típus, ami kód kompatibilis. A perifériák uniformizáltak és egy osztályban processzorok egyformák. Az ATMega 2560 meg nagyon drága.
gyorsabb lesz fejlesztés közben a visszajelzés, ha nincsen benne az égetés, átülés a vashoz, stb a folyamatban.
A 80-as évek végén kölcsönkérték az EPROM égetőnket. ;)
Az asztalomon ezek voltak:
- XT V20 processzorral, amin futott a natív 8080 kód és így az Intel Isis-II fejlesztőrendszer is.
- nyomtatókábel
- a fejlesztett hardver +4k RAM
A lefordított programot kiküldtem, amit a hardverben a betöltő program relokált és futtatta.
Az algoritmust egy kollégám tervezte, de csak bipoláris processzorokhoz értett. Én az egyes hardverelemek kipróbálása után (Vajon jól rakta-e össze a műszerész?) megírtam az egyes részek működtetésére szolgáló programocskákat és makrókat, meg a seek-hez szükséges perc:másodperc.frame számításokat. A fő algoritmust egy hétvégén átírtam 8085-re, és hétfőre működött egy CDROM. Az egész fejlesztés jó 12 hétig tartott, hárman csináltuk. Ennek tetemes részét tette ki az embargós lopott CDROM szabvány, a Reed–Solomon és a másodlagos hibajavítás tanulmányozása, illetve az optomechadeck kicsit hibásan működő parancskészletének kicselezése.
Meg még az osztályvezetőnek is kellet szerezni egy AT-t, meg nekem az XT-t, hogy legyen min dolgoznom. ;) Az ilyen "adminisztrációs" feladatokat a csapat harmadik tagja végezte.
A program szerkezete egy kicsivel bonyolultabb volt a fenti példánál:
- A főprogram nem volt üres, mert ellenőrizte, hogy megnyomták-e a tálca nyitás nyomógombját és standby állapotban vagyunk vagy olvasunk. Az utóbbi esetben meghívta a vezérlés által bekészített szubrutint.
- A többit az 5db huzalozott megszakítás intézte. (A 8085 ennyit tud.)
Meg olyan is előfordul, hogy ahogy adják hozzá a funkciókat, a termék kinövi a vezérlőt, és akkor nagyobbra kell lépni.
Ilyet nem igazán tudok elképzelni, ha jó volt az alkatrészválasztás. Persze, ha a tíz évvel elzelőtti kenyérpirítóból azóta űrhajó lett, akkor talán. ;) Ugyanabban a 8 bites családban nincsen sokkal gyorsabb elem, így legfeljebb a 8-16 bites váltás marad, de az drágább. Meg a csak 5V-os verzióban létező szenzorokat újra kellene illeszteni a 3,3V-os processzorhoz. Szóval csak a baj lenne vele. Az összes többi problémára meg ott van az I2C busz, amire lehet port extendert és memóriát is kötni - és még olcsóbb is. A program mérete a komplexitással egyre kevésbé nő. Nekem 12k a legnagyobb programom a 16k területen. Ha ezt kinőném, akkor ott a 24k-s verzió is.
Két eset volt csak, amikor majdnem megszorultam. Nőtt a bemenetek száma és a hozzá tartozó analóg hardver mennyisége is. Ekkor közölte a tervező bácsi, hogy még egy ellenállás és jön a 4 réteg - bár hely az még van. A másik esetben meg majdnem elfogytak a portok, pedig csak USB, egy nyomásmérő, egy nyomógomb, egy eeprom és egy túlbonyolított tápegység volt a panelen.
Szerintem az a baj, ha szoftveres akar szoftver eszközökkel hardvert fejleszteni és a fejlesztést szoftverrel támogatni. :-D Nekem meg mindegy miben írom, ezért az algoritmust tesztelem awk-ban és megírom assemblerben.
Vitatkoztam már hasonlón egy szoftvermérnökkel. Nem értette, hogy ha egyszer elkészül egy firmware és működik, akkor ahhoz nem kell többé hozzányúlni. Mert ha kellene, akkor nem jól működne, azaz kész se lenne. ;) Tehát én hibátlanul programozok. Vagy mégse? ;) Szóval néha tényleg kell javítgatni, de a működés és használhatóság kívülről nézve mindig ugyanaz marad.
Bár egyszer vissza kellett hívni 10db terméket. A főnököm a "teszteld" helyett azt értette, hogy "add el". ;)
Parttalan a vita, de azért 1-2 dologba beleválaszolok/kérdezek:
>Ugyanabban a 8 bites családban nincsen sokkal gyorsabb elem
Pont ez a lényeg, hogy ha teljes újratervezést kell csinálni, akkor legalább a szoftver nagyrésze maradjon változatlan. Nem feltétlen gyorsaság probléma van, lehet memóriaméret, vagy lábszám probléma is.
> Bár egyszer vissza kellett hívni 10db terméket.
És akkor újraírtad a teljes programot, vagy a meglévőt javítottad?
Kicsit off: amugy a gyartok is alkalmazkodtak sokat, mindenki nyomja az MCAL-t, ami gyarkorlatilag elfedi az MCU-t.
Nekem nem igazan jon be mert sokat elvisz, de ha nem idokritikus es van szabad kapacitas, akkor akar jo is lehet.
... Software Module
GPT (General Purpose Timer) Driver
Device driver using on-chip MCU timer
Initializes GPT, performs timer count
Ez az első pont és innen már felesleges továbbolvasni.
Egy PIC mcu-ban alapvetően nem GPT-k vannak, hanem TIMER0, TIMER1, TIMER2 és TIMER3 típusú timer(ek). Ezen típusok mindegyikének más-más extra tulajdonsága és felhasználási területe lehet. Ezeket GPT-ként kezelve olyan eszköz marad a szoftverben, amivel nem használhatók ki ezek a funkciók.
A megoldás csak annyi, hogy szoftveres ne nyúljon hardverhez, mert nem ért hozzá.
Hat ezt nem a PIC kategorianal nyomjak, hanem inkabb az autoipari mcu-knal! Ott ugye ez a lenyeg, hogy kis dobozok/komponensek legyenek.
De amugy egyetertek :)
A Microchip szerint a 8 bites PIC-ek is mennek az autóiparban. Ismerek néhány autóiparis arcot, és ők sokszor úgy gondolkodnak, hogy mennél egyszerűbb annál jobb: annál kevesebb dolog mehet tönkre.
Mennek, de nem minden ASIL szinten.
Olyat nem lelni ECM-ben :)
Megnézhetnéd ezt a linket: https://www.microchip.com/design-centers/automotive-solutions/automotiv…
Csak azért néztem meg, mert számomra az "autóipari mcu" nem mond semmit. Legfeljebb rá lehet fogni, hogy az extended vagy high hőmérséklettartományú, esetleg a LIN vagy CAN - már ha kell.
Inkább a szoftver hordozhatóság miatt a "Core Independent Peripherals" a lényeg. Ez a borzasztóan kicsi (PIC10) és a 32 bites, idegen core felhasználásaval készült mcu-kra is igaz. Majdnem értelme van a HAL-nak is. ;)
Lényegében a Microchip szinte a teljes termékpalettát felsorolja, mint automotive. ;) Valójában ez a kvalifikáció sok esetbe a 17V-os eszközt jelenti.
Amiről írtam az meg olyan dolgokat eredményez, amikor a specializált perifériák nincsenek kihasználva. Pl.
- A sarki bótban 300Ft-os PIC16 - még 8x8 bites szorzóegység sincs benne, de egy 64bites PID vezérlő van. Erre használhatsz szoftvert is, de rögtön 16 bites és jóval gyorsabb eszközre lesz szükséged.
- Hasonló (írtam is valahol) a dsPIC-en szoftverrel számított FIR filter. Nem nagy durranás, mert kicsit optimalizálva nekem még 8 biten is elég gyors. Csak az mcu kis nevében a "ds" azt jelenti, hogy DSP regiszterei és utasításai vannak. ;)
- Az esetek java részében még bitbang módon sem tudod programozni azt, ami szükséges. A beépített perifériákat megfelelő módon összekötve - ahogy a gyártó kitalálta - szoftver nélkül is működni fog az áramkör. Csakhogy ez hardvertervezés, amihez a szoftveres nem ért. A "szoftver" csak beírja a regiszterekbe a szükséges konfigurációt. Utána a hardver teszi a dolgát.
- Minden mikroprocesszor azzal a fránya órajellel megy. Ha ahhoz képest aszinkron eseményeket kell kezelni, megint csak az uniformizált perifériákhoz kell fordulni és megfelelő módon konfigurálni őket.
Szóval a GP lib lehetővé teszi, hogy nagyobb, gyorsabb és drágabb, de általános célú mcu-t használj.
Hat itt foleg az MMU meg ugye tobb dolog duplan van megvalositva, pl. van egy olyan kulonallo core is van ami ellenoriz.
Autoiparban ilyeneket max multimedia / AC vezerlesre esetleg ulesek/tukrok allitasara hasznalnak, semmi "komoly" feladatra, mert nem kapott plecsnit.
Nem mondanám, hogy kissé offtopic vagy - tekintettel a topic címére, meg a kis elkanyarodásunkra. ;)
Értem én, hogy a 600MHz-es 32bites ARM R52 is MCU, meg ASIL és hibrid és Tesla...
Sőt, roppant biztonságosnak is kell lennie, mert hát múltkor is behatoltak a cédéjátszón keresztül az ECU-ba és megállították az autót. XD
Szerintem meg a POWER10 A CPU, minden más meg tranzisztor.
Pedig csak a C64 bitvadászokat szidva kanyarodtunk erre, viszont a világon még rengeteg dolog létezik a fenti mcu-n kívül. És nem csak a tükrök állítására.
Lefordítom mit írtam oda: Az MCAL-t inkább általános mcu esetén használják, de nem célszerű speciális perifériákat programozni vele, mivel nem is lehet.
Ennek köze nincs az ASIL-hoz, mert az meg egy funkcionális megfelelőségi minősítés.
Bár nem vagyok Microchip bérenc, de ezt a két oldalt megnézheted:
https://www.microchip.com/design-centers/functional-safety
https://www.microchip.com/design-centers/8-bit/functional-safety
"De amugy egyetertek :)"
Csak azért néztem meg, mert számomra az "autóipari mcu" nem mond semmit. Legfeljebb rá lehet fogni, hogy az extended vagy high hőmérséklettartományú, esetleg a LIN vagy CAN - már ha kell.
A biztonsagot itt a vegrehajtasra kell erteni, nem security oldalrol. Ha baromsag van a kodban, akkor azt fogja vegrehajtani, biztosan :)
Megneztem mit kinal a MC, le vannak maradva a versenytarsakhoz kepest.
Akkor amit linkeltem, azt nem olvastam, nem értettem, vagy csak egyszerűen hülye vagyok? ;)
Nem bonyolult a dolog: bizonyos hardver funkciók megléte (hardver esetén) és/vagy bizonyos tesztek sikeres végrehajtása = minősítés. Akár az ISO9001. Az is lehet jól csinálni, meg lehet csak egy plecsni, miközben abszolút rossz a működés.
A Microchip nem igazán gyárt olyan nagyágyúkat, amit idéztem. Sőt a Core i7-nek sem a versenytársa. ;) A specializált és uniformizált perifériákat viszont odateszi a vásárolt 32 bites core mellé. (Ez már maga a HAL! ;)) Azaz még 32 bites platformot sem gyárt igazán, de nem is ebben jó. A kivezetett mcu-k is olyanok, amik csak általános felhasználásra jók (kutya sem használna ilyet), vagy van helyettük több funkcióval redelkező kód kompatibilis példány.
A minősítés meg csak egy alkatrész vagy szoftver minősítése. Mondok egy példát:
Ha egy mcu nem rendelkezik watchdog timerrel, akkor kap -1 pontot, így a végén gyengébb lesz a minősítése. Ha kiegészíted külső watchdog áramkörrel, akkor a funkció is biztosított, de valószínűleg az előálló termék is visszakapja az 1 pontot. Jobb esetben akár többet is, mert független eszközzel biztosítja ugyanazt a funkciót.
Szóval a minősítés csak minősítés, de még engem is érhet meglepetés! Dolgoztam már olyan C fordítóval, ahol egy oldal apró betűs felsorolás taglalta, hogy milyen ipari szabványoknak felel meg. De az, hogy a Microchip C fordítója bárminek is megfelelne... :-D
Nem vagy hulye, de picit ugy erzem elbeszelunk egymas mellett. Jelenleg jarmuiparban dolgozom, tudom mirol beszelek :)
Ezt erdemes elolvasni: https://web.archive.org/web/20150906100246/http://www.ti.com/ww/en/mcu/…
Illetve nezd meg, hogy nez ki egy viszonylag regebbi MCU belseje: https://www.nxp.com/docs/en/data-sheet/MPC5744P.pdf
Egy mai autoban van Automotive Ethernet, CANFD/FlexRay, LIN, es meg sok mas. Pl. Gyorsna rakerestem es FlexRay-es MCU nincs is a kinalatukban.
Az uj cuccokrol a neten meg semmit nem lehet talalni, ugy titkoljak a specifikaciokat is, mintha az atombomba tevrei lennenek.
Szoval meg sokat kell fejlodniuk...
Ennek ellenere pl. sajat home automation cuccaimat, PIC hajtja. Olcso, jo.
Hát persze, hogy elbeszélünk! A kiindulási alap egy C64 kaliberű, de egycsipes szerkezet volt. Hiába vetem össze csak egy POWER8 képességeivel. Pedig az is mikroprocesszor. ;)
Az automotive certified/grade stb. meg az ASIL-D akkor sem szinonímái egymásnak. Amikről beszélsz, hasonlókról már hallottam eddig is, csak más szakterületen. Én csak apró motordiagnosztikai műszereket fejlesztek. A bonyolultságuk és követelményrendszerük alacsony. A célt inkább úgy fogalmaztam meg, hogy nem romolhat el. A garanciális ügyek elvinnék a nyereséget. ;) Az automotive besorolás naponta szembeköszön az adatlapokon. Pedig szó sincs olyan minősített, fault tolerant "nagyszámítógépekről", amiben gondolkodsz.
Ezek a biztonságtechnikai szabványok nem igazán hatnak meg. Lehet, hogy ez az autóipar főcsapása, de egyúttal a tömeggyártás és a felesleges túlbonyolítás végeredményét is láthatjuk. Ne feledd, hogy a gazdaságos termelés egyik alapfeltétele, hogy olcsó mukaerő olcsón tudjon tömegtermelni! Erre ráhúzható egy olyan szabályrendszer, amihez az alapot a kisszámú magas képzettségű szakember adja. Így készül a roppant bonyolultságú processzor, és arra a közepes képességű munkaerő írhatja a szoftvert.
Egyetertek! Naponta latom, hogy van 10 ember aki valojaban ert hozza a tobbi csak kalapal. Bar ennek itt a processzor belso strukturajahoz koze nincs, inkabb az RTOS-hez ami azon fut.
Szivesen folytatnam az eszmecseret egy sor mellett, mert mar nincs ledvem itt irogatni :D
ha teljes újatervezést kell csinálni, akkor legalább a szoftver nagyrésze maradjon változatlan
A lábszám miatt "teljes újratervezés"?? Erre ott a válasz: Az összes többi problémára meg ott van az I2C busz, amire lehet port extendert és memóriát is kötni - és még olcsóbb is.
És nem véletlenül írtam.
- Ha hirtelen 30x annyi memória kell - az egy durva mcu család váltás. Ha a feladat egyébként ugyanaz, akkor berakok egy 300Ft-os memóriát.*
- Ha hirtelen 8-16 porttal több kell, akkor berakok egy 300Ft-os port extendert.*
* A 16 bitesítés kb. 1000Ft többlet lenne, a nagyobb memória még több. Ugyanannak a családnak a "rengeteg lábú" verziója meg az előbbieknél is több.
Tehát marad az eredeti mcu és program is. Mindössze az olcsó bővitések kezelésével kell bővülni.
A visszahívott termékek programját nem kellett újraírni, csak betölteni az időközben befejezettet. A sztori pont arról szólt, hogy a főnök a fejlesztés alatt álló és tesztelendő programot tartalmazó hardvert sitty-sutty eladta. Azóta csak a program befejezése után adunk neki bármit is. :)
Azt meg megirnad, hogy az awk-ot hogy hasznalod erre? Ugy emlekeztem, az inkabb ilyen egyszeru szovegfeldolgozasra valo, nem asm-ben uC kod fejlesztesere. Erre irnal egy peldat?
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
nem asm-ben uC kod fejlesztesere
Ezt nem is állítottam. A beszélgetés arról szólt, hogy kell egy HAL + szoftver, és ezeket az elemeket lehet pécén szimulálni. Ennek az ellentétjeként írtam, hogy a vezérlő algoritmust az mcu-ra kell írni. Az egyéb tesztelendő algoritmust meg bármin lehet tesztelni, majd könnyedén át lehet emelni akár C->C, akár awk->asm, stb.
Az (eredeti) awk, tényleg egy pattern processing language. Is. De tetszőleges programot is lehet benne írni. Vagy akár C programot, szinte egy az egyben át lehet rakni. A GNU awk meg már annyira túlfejlett, hogy szinte bármilyen feladathoz rendelkezik beépített függvényekkel. (És az awk-ban még int sincsen, csak 55 bites lebegőpontos ábrázolás.)
Inkább úgy mondanám, hogy bármit bármilyen nyelven, vagy eszközzel meg lehet írni. Gondolj csak bele, hogy tanultam automatizálást, de azokat a "programokat" hidraulikára vagy kis- és nagynyomású pneumatikára kellett "írni". :-D Állítólag valamelyik űrsiklót is - tesztelésként - leszállítottak egy pneumatikus számítógéppel.
Van olyan programom is, ami egy exportált Windows logoból kiszedi az ssh userek be- és kijelentkezését, és ezt az eredményt átadja egy shell scriptnek, amely egy sql adatbázis loginlog táblájába írja. A program sed-ben készült, pedig arra azt mondanád, hogy egy stream editor. De lehet programot is írni rá.
Láttam olyan Excel táblát, ami egy élő, működő termelésirányítási rendszert valósított meg. Aki bemutatta, éppen a köztársasági elnök szárnysegédje, valamint katonai és informatikai tanácsadó volt. ;)
És itt a feladat - az awk program.
Van egy műszer, amiben 4 nyomásmérő adatait kell előfeldolgozni. A teszthez bájtonként hexdumpolt text formátumú adatok állnak rendelkezésre, a számformátum little-endian. Ezen belül, soronként az 5-6. mező (bájt) egy timestamp, amit a 9-10. mezőtől 7x4 mérési nyomásérték követ, rendre az 1-2-3-4 nyomásmérőről. (Ez az első filter.)
A bájtok számokká alakítása után mindegyik nyomás sorozatban keresni kell a (bizonyos ideig fennálló) minimum értéket és "megjelölni". A két minimum közt eltelt idő meg kell a fordulatszám számításához. A túl nagy vagy túl alacsony periódusidőt meg nem használjuk fel.
Ez a program a jobb láthatóság kedvéért RPM értéket közöl, de a megvalósításkor csak periódusidőt. A fordulatszámot a pécén futó szoftver számolja. Az eredeti négycsatornás tesztnek itt már csak az átíráshoz szükséges egycsatornás változata látszik.
A tesztprogram eredménye excel táblázatba kerül, ahol a nyomás és a kijelzett fordulatszám megjeleníthető.
A fenti tesztprogram számításai átkerülnek a firmware-be. Az egyes awk sorokat a comment-ben láthatod. Annyi a különbség, hogy a számításokat egy csatorna egy mérésére kell elvégezni és az eredményt elrakni a következő mérésre. Nem tudjuk és nem vizsgáljuk, hogy hol van az előző adat. Lehet hogy az előző bufferben, amit már az USB hardver foglal, stb.
Tehát az ix csatorna index nem látszik, mert azt a környezet állítja be. Így tudjuk, hogy az algoritmus mindig a megfelelő adatsorra fog futni.
Ugye nem is bonyi.
Én nem Assembly kóddal dolgozom, hanem C-ben, de okkal úgy készítettem egyes kezeléssel kapcsolatos kódokat, hogy akár módosítás nélkül át tudjam egyes részeit tenni másik kontroller alá. Ennek részeként pl. I2C, SPI kezelésére saját függvénykönyvtárat használok és az adott kommunikációt végző rész ezeket hívja.
...az adatok tényleges felhasználása meg már másik szinten van.
Így van olyan kódrészlet, ami MSP430, AVR és STM32 vezérlőn is futott már, ill. fut.
Egyes programrészeket pedig PC-n írok először, esetleg problémás részeket átemelek PC-re és ott tesztelem.
Tehát vannak olyan részek, amik elég jól hordozhatók, a kontroller közeli részeket viszont külön kell megcsinálni, igaz, kontrollerenként csak egyszer, utána pl. a szenzorkezelő kódok már problémamentesek.
Nekem a terepasztalom van emulálva, nehéz odébb vinni, amikor fejlesztek rá. Maga az arduino a szimulátor is.
16 szakaszra van bontva, képes egyszerre 2 vonatot irányítani, kiszámítja a sebességüket és körbe-körbe mennek. A videón látni, ahogy a gyorsabbat lefékezem.
https://www.youtube.com/watch?v=ByYkM7yomEM
A perifériákat emulálom és I2C helyett UART-on nyomom az emulált perifériák válaszát (sajnos I2C lett, akkor még nem tudtam, mekkora elektromos zajjal jár egy terepasztal).
Maga az Arduino az emulátor, UART-on kapja az emulált adatokat. A terepasztalon webről követheted a vonatokat, a web részt egy ESP8266-os szolgáltatja.
Amikor emulálok, akkor az ESP8266 a szimulált komponensek válaszait is leküldi, amikor élesben fut, akkor értelemszerűen a vonat-vezérlő, váltó-vezérlő, világítás vezérlő valódi adatokat küld.
Egy táskába egy Arduino - ESP8266 komponens befér, szimulációnál tud kamu szakaszfoglaltsági adatokat szolgáltatni. Az Angular-on web interfészt is frankón lehet így fejleszteni.
Senior hozzáértő programozót nehéz találni, olyat meg még kevésbé, aki szívesen támogatja a "kezdők között is kezdő" (idézet a cikkből) emberkéket. Tehát sok cég vagy a tech debtbe fullad bele pár év után, ha nagy projektbe vágnak, vagy ha sok kicsi projekt van (pl. weboldalak), akkor előbb-utóbb jön egy másik cég, aki hatékonyabban, tizedannyi munkával, generikusan megoldja ugyanazt.
Egyébként támogatom a képzést, és jó lenne azt látni, hogy egy ilyen kezdő képzés után valaki ráérez, továbbfejlődik, de ez valószínűleg csak a töredéke lesz. A hazudozó sales-esek meg szégyelljék magukat mindettől függetlenül.
Őszintén szólva azért nagy esély volt rá, hogy nem jön el majd a Kánaán pár hónap OKJ-től..
--
God bless you, Captain Hindsight..
Szerintem egy vegzett mernoknek siman eleg, hogy felkeszuljon erre a szakmara.
Erettsegivel ez keves.
Megy az diploma nélkül is.
Kulcsszavak: motiváció , akarat, kitartás, szorgalom.
--------------------------------
...úgyis jönnek...
Bizonyos szintig.
Pl Machine Learning "Hello World"-je a Lineáris Regresszió. Az úgy kezdődik, hogy parciális derivált. Értem, hogy meg lehet tekinteni az MIT Single Variable Calculus-t előtanulmánynak, majd a Multivariable Calculust. Aztán kell a Lineáris algebra. Ez a minimum beugró, hogy utánna Kolmogorov-ot is menjen. Ez kell ahhoz, hogy értsed mi történik. A gyakorlati felhasználásánál ezeken zsigerben kell lennie, hogy akár egy a megfelelő implementációt válaszd ki, értsed, hogy mi miért van benne... stb. Google, Apple, MS,...stb ezekre a pozícióknál az a minimum követelmény, hogy mester diplomád legyen, de a PhD az ajánlott. Ez csak az egyik ilyen terület. Ehhez kapcsolódik a Data Science ahol szintén hasonló a helyzet (lévén, hogy kapcsolódó terület), valamint ugyanez van Robotikában, Biomatikában...stb. Ezek az IT egyre nagyobb részét adják.
Szokás azzal viccelődni, hogy amiben nincsen AI és blockchain, abban a technológiában már nem is hiszünk. Persze ez nem azonnali váltás, hanem folyamatosan történik évek alatt, de ez már évek óta zajlik. Ezek a folyamatok nem várhatóak, hogy "egyzerűbbek" lesznek. A következő buzzword a "quantum".
Azért ne fussunk el rögtön a machine learning -ig meg a tech giant -ekig. Tökig van Magyarország is mezei üzleti szoftverfejlesztéssel. Persze az igaz hogy ezekre egyre nagyobb igény van, de mintha azt mondanád hogy a felsorolt dolgok nélkül nem is lehetsz fejlesztő, devops mérnök, infrás vagy egy rakat egyéb.
Illetve én nem rangsorolnám úgy, hogy a data scientist valami magasabb kaszt lenne a "normál" fejlesztőkhöz képest :) Ismerek olyat is, aki simán összeránt neked egy neurális hálót és megdöbbentő dolgokat művel vele, de egy klasszikus 3tier üzleti alkalmazásra, egy adabázisra meg egy közepesen bonyolult integrációra rá se tudna szagolni. Inkább specialisták leszünk idővel, és nem superhero -k (persze itt is van kivétel).
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene
Nem is azt mondom, hogy az kuka. Azt mondom, hogy a Silicon Valley-ben elindult egy trend, miszerint csomó dologba belerakják az AI-t és társait. Ezek mellett ugyanúgy van mezei kóder, üzleti IT...stb., csak kezdenek lejebb csúszni a táplálékláncban. Kb ugyanez ment az üzemeltetésben. Régen a kkv-s rendszergarázda, aki újra tudta telepíteni a windows-t már császár volt, ma meg minimálbéren van. Viszont üzemeltetésben is maradt olyan rész amit nagyon is megfizetnek, de érezzük, hogy oda kicsit több tudás kell. Ez a folyamat fog lejátszódni a fejlesztésben is.
Ezek igazak persze, de arról van szó, hogy lelkes átképzettek kapnak-e enni a piacon - és szerintem kapnak, csak akarni és dolgozni kell érte. És teljesen mindegy hogy milyen papírja van. Én a BSc -met 7 év szakmában aktívan eltöltött év után szereztem meg végül, mert fékezett habzáson foglalkoztam vele, inkább váltottam az egyre jobb munkahelyekre, érdekesebb feladatokra, és több pénzre :)
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene
Igen, csak a nem igaz, hogy a targoncásból átképzett jópofa becsengette a bootcamp árát és onnan övé a világ. Hanem egy ugródeszka, amikor a meló mellett képezni kell magadat, valószínűleg BSc, és késöbb akár MSc szintig. Viszont akkor arra már lesz fedezeted.
Csupán annyit akartam közölni, hogy azt a szintet ami most a reklámokban van, azt jóval több tudásért adják.
Hát nagyon nem. Több jó beosztásokban lévő kolléga hullott ki a bsc első félévében. Egyszerűen felbaszta az agyukat az a szint amire nincs szükség a gyakorlatban, de minden autodidakta kóderből hiányzik. Nekem is nagyokat kellett nyelnem alap algoritmusok magolásakor. Nameg ott volt még a matek, ami sokakat kivégzett.
Én a közeljövőröl beszélek, nem a közelmúltról, vagy a multról.
Kb 10 ével ezelőtt majdnem teljesen valid volt, hogy nem kell a matek. Mára már kezd megváltozni a helyzet.
Nagyon nem kétlem, hogy a kollegák kaptak egy szemléletet, majd megtanultak mondjuk C-ben kódolni és arany életük van, nem is hiányzik nekik semmi. Tökéletesen valid az állítés.
Én azt az állítást challangelem, hogy a fiatalságnak ez már nem egy jó stratégia
Utoljára tegnap kellett gráfokkal molyolnom...
Persze, ML meg Quantum... előbb egy rendes sql selectet próbáljon megírni, ami nem fut két napig, és nem hozza le két adattábla teljes Descartes-szorzatát :-)
+1
Az a baj ezzel a szakmával hogy egy kicsit mindenhez érteni kell, kevés dologhoz meg nagyon :)
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene
A legtobben, akik C#-ot hasznalnak, valoszinuleg nem tudnanak egy C# JIT-et irni. A C programozok nagy resze nem tudna C forditot irni, a Wordot hasznalo titkarnokrol mar nem is beszelve. A Windowsos/Linuxos programfejlesztok nagy resze nem tudna megirni az adott rendszer kernelet.
Aki Tersorflow-t/Scikit-et meg hasonlokat fejleszt, azoknak sok matek kell. Ahogy a 3D engine fejlesztoknek is. Akik csak hasznaljak, mar joval alacsonyabban van a kuszob. Ha egy ceg nem AI engine fejlesztesbol el, akkor fel fog venni egy csomo embert, aki hasznalja, esetleg pluszban nehanyat, aki fejleszti a belso AI rendszeruket. De az elobbieknek kevesebb matek kell. Persze fel lehet venni takaritasra is PhD-s embereket, nem lesz koltseghatekony, plusz utalni fogjak a takaritast, es lelepnek. Favagasra favagot.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
a C, vagy C# fejlesztőknek is érteni kell az algoritmust amit kódolnak, van is belőle elég sokszor nagy baj, amikor nem. Ahoz, hogy hatékonyan haszáld a Tensorflow-t, vagy éppen egy másik implementációt ahhoz értened kell, hogy mi miért történik. Nem kezdesz el komplett AI lib-et fejleszteni, mert már megcsinálták helyetted, sok szemszögből megközelítve, valószínű jobban. De értened kell az AI működését, hogy kiválaszd melyik kell, estleg milyen paraméterek miér vannak, stb. Nem beszélve arról, ha bele kell nyúlni. Erre vannak a dedikált emberek, PhD-val, vagy MSc diplomával akik elteszik a nagy lóvét. Ettől még a mezei programozóra is szükség van. Nem vagy egyik van, vagy a másik van kérdésköre van, van mindkettő, sőt azok között még sok sok réteg. Csupán annyit állítok, hogy a PhD-s réteg keresi majd a nagy pénzeket, a junior meg a minimálbéres lesz. A skála két vége látszik.
"Ahoz, hogy hatékonyan haszáld a Tensorflow-t, vagy éppen egy másik implementációt ahhoz értened kell, hogy mi miért történik."
Attól, hogy érted, hogy mi miért történik, nem valószínű, hogy tudnál Tensorflowt hatékonyan implementálni.
Mint ahogy hiába jó az ember lineáris optimalizálásban, igazán hatékony simplex solver implementációt írni akkora szopás és akkora tudást igényel, hogy hiába vagy matekból penge, nem fog menni - nem is csinálják sokan. Pedig a simplex a legegyszerűbb eset.
Az, hogy érted az AI működését, még nem jelenti azt, hogy hatékonyan meg is tudnád csinálni. Sok algoritmuszsenit láttam már, aki amúgy programozni nem tudott, pláne nem hatékony, tiszta, karbantartaható kódot írni. Ettől még az ő tudásukra szükség van, csak ők épp nem szoftverfejlesztő mérnökök, mert az egy másik szakma.
Akkor is meg tudom mondani egy kódról, hogy gány, ha éppen nem értem, hogy mit csinál.
Kevered a dolgokat nagyon. Attól, hogy valaki penge bizonyos területén az IT-nak, még nem jelenti azt, hogy mindenhol penge ő és csak rá van szükség, mert a tudása nélkülözhetetlen.
Értheted te, hogy hogyan működik a lineáris regresszió, sokan meg is teszik, de kevesek azok a szoftverfejlesztők, akik a mögöttes matekhoz hozzá tudnának tenni. Lehet, hogy értik, lehet, hogy tanulják, de új tudományos eredményt nem tőlük kell várni.
Mint ahogy egy mechatronikai mérnök is teljesen tisztában van a newtoni fizika módszereivel, a vektorszámításokkal, analízissel, mégsem fog újat mondani a fizikában - és nem is ezért fizetik. És ha fizikusokat alkalmaznának ezeken a helyeken, ők nem tudnának megtervezni egy épületet úgy, mint egy mérnök.
Múltkor KFKI-s fizikusok részecskeszimulációs kódját refaktoráltam, mert használhatatlan volt, szoftvermérnökileg meg egy nagy nulla (a szoftver módosításának és adaptálásnak az alapvető eszköze a copypaste volt modularitás helyett például). És még hatékony se volt, mint utólag kiderült. Pedig PhD-s arcok írták. Csak éppen nem jelent semmit a tudományos fokozat, amikor nem tudományról, hanem mérnökségről van szó.
Beletelt egy kis időbe, mire a publikációk alapján rájöttünk, hogy mit is csinálnak - majd megterveztük, és szoftvermérnöki szakma alapelvei szerint meg is csináltuk. Olyan 20-30%-kal lett gyorsabb az egész, és persze rendesen moduláris meg újrafelhasználható. Mert minőségi szoftvert írni, meg az algoritmust, amit a szoftver implementál, érteni két totál külön szakma.
Csakhogy én nem azt állítottam.
Azokról akik a tensorflow-t és társait reszelik arról nem szóltam, az egy külön story.
Azokat mondtam, akik softwaremérnökök és mint framework felhasználói a tensorflow-nak és társainak, a junior-ból lett senior-okról. Simán lehet, hogy az arc a youtube-on tanult először kódolni, elmegy "nagyon junior"-nak, közben megcsinálja estin a BSc-t, majd az MSc-t.
A PhD-sok eddig nem is voltak a képben, nemrégtől kezdték el őket alkalmazni, mivel nagyon drágák, most ért el oda a helyzet, hogy megéri őket is bevonni.
A részecskefizikusok szimulációja nem volt rendes software, hmm. talán mert fizikusok, nem azt tanulták. Viszont eltartott nektek jódarabig, amíg megértettétek, gondol el, hogy ő azt ki is találta :D
A tudományos fokozat nagyon sok esetben jelent előnyt. De gondol el, egy gépészmérnök elvileg meg tudja szerelni az autót, de egy autószerelő sokkal jobban és sokkal gyorsabban megcsinálja azt a feladatot. Viszont amikor az van, hogy egy új alkatrészt kellene tervezni az autóba, akkor érdekes módon az a gépészmérnök feladata. Ezen analógia alapján miért az autószerelői feladatot kéred számon a mérnöktől?
> Viszont eltartott nektek jódarabig, amíg megértettétek, gondol el, hogy ő azt ki is találta :
Az is kurva sokaig tart mire kitalalom, hogy mire gondolt a PO, vagy egy random bug report, szoval ez igy nem jelent sokat...
"Csupán annyit állítok, hogy a PhD-s réteg keresi majd a nagy pénzeket"
Akik igazán nagy pénzeket keres, az nem a PhD-s lesz, hanem a PhD-s főnöke. Aki általában egy juniorból lett seniorból lett manager. Az igazán nagy pénzek megkereséséhez nem tudósnak kell lenni, hanem soft skillekben, meg emberek kezelésében jónak lenni.
> soft skillekben, meg emberek kezelésében jónak lenni
Eleg rossz hir ha igy van.
____________________
echo crash > /dev/kmem
Lepjunk eggyel hatrebb, mi dolga van egy people managernek?
Rossz peldanak mondjuk kivalo az atlag people manager :)
Azon kivul hogy nelkule cincognak az egerek, meg nincs aki ranyomjon a szabidra, nem sok hasznukat latom. Ne ertsd felre, nincs veluk bajom, nem sajnalom toluk a fizetesuket se. Csak tul vannak ertekelve (szerintem).
____________________
echo crash > /dev/kmem
A másik oldalról. Kell egy "diktátor", különben nem készül el semmi. A probléma akkor van, amikor a "diktátor" nem szakmabeli, hülyeségeket
beszél, de legalább hallgatni is kell rá. De a viccet félretéve, nézzük, hogy mi lenne a feladata:
- Biztosítja, hogy a fejlesztők ne mondjanak fel. Ezt folyamatos one-on-one interjúkkal, a fejlesztők problémáink meghallgatásával, és ezekre adott
hatékony válaszokkal történik. Biztosítja a jó hangulatot.
- Figyelemmel kiséri a fejlesztők teljesítményét, értékeli, és fejlődési lehetőséget biztosít számukra
- Biztosítja, hogy a fejlesztők se túl, se alul terhelve ne legyenek
- Részt vesz a felvételiztetés folyamatában
- Amennyiben elakadás van, segít ezt feloldani
- Amennyiben valamiben nincs megegyezés, akkor döntéseket hoz, amiért vállalja is a felelősséget
- Folyamatosan fejleszti a céges folyamatokat, hogy a lehető leghatékonyabban tudjanak dolgozni a munkatársak
- Reportál a felsőbb szintek felé
- Irtja a pletykát ahol tudja
- Tárgyal az ügyféllel úgy, hogy közben a csapat és a cég érdekeit érvényesíteni tudja,
- Képviseli a céget, arcot ad neki,
- Folyamatosan dolgozik a belső folyamatok optimalizálásán,
- Csendesen tűri, ha egy álláshirdetés alatt kifejtik, hogy a munkahelye, az maga az ördög, világellensége :)
A people manager-nek vannak people skill-jei? :-D
https://youtu.be/hNuu9CpdjIo
"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."
Ember, ezek többnyire mezei javascript fejlesztők.
Ember, mi egyről beszélünk :D
Az volt az állításom, hogy megfelelő előképzetslg nélkül nem mindent tudsz megtanulni és megragadsz egy szinten. Például a javascript fejlesztőin.
Miért, az előképzettséget nem lehet megtanulni? :D
De elvileg lehetséges. :D
Gyakorlatban, hát tudod mit szenvednek az egyetemen a hallgatók vele, pedig segítséget is kapnak hozzá.
Aha, segítséget. Belekóstoltam BME-be, ha épp nem volt szivatási kvóta, akkor szimplán csak a Bourbaki-féle agyrém módszerrel ledarálták az anyagot, és good luck. Annál ma már neten is ezerszer jobb anyagok vannak, nem véletlen szenvednek vele egyetemen a hallgatók.
Nekem nem a BME-vel van tapasztalatom, de ha jól tudom ez a BME-n már erőteljesen változik.
De szerintem esélyesebb,hogy a BME változzon. A magánszám produkció így néz ki leül, megnézi yt-on az MIT-s órát, majd csinál hozzá értő módon, összekapcsolva az elméletet a példával kb mindenre vagy 50-100 feladatot. Erre így magánszorgalomból, minden kényszerítés nélkül rádobjon egy évet. És akkor az alpok alapja van meg, akkor jöhetnek a bonyolultabb koncepciók és azok alkalmazáésa a kiválasztott területnek megfelelően. Persze elvileg mindenhez is van anyag, csak "motiváltság" kérdése. Aki ezt átlátja, hogy kell annak tényleg nincs szüksége az egyetemre, de az is igaz, ha ezt otthon magátol meg tudja csinálni, akkor az egyetemet is símán megcsinálja. Mondjuk akkor keresnék külföldön valami jobb egyetemet aminek a diplomája nem csak itthon ad "rangot", hanem a világon mindenhol.
A ketteshez ennél SOKKAL kevesebb is elég. És akkor elégedetten csettintesz interjún, mert van diplomája.
És az aki kettessel átevickél és lesz diplomája, abból lesz a legmenőbb programozó?
Pont azt mondom, hogy a tudás kell, nem a papír. Az hogy van papírod attól még nem biztos, hogy megvan a tudásod. Fordítva azokon a területeken viszont tuti nincsen, sok álláshirdetésben van az, hogy minimum Mester. De ezek AI, Data Science...stb pozíciók és nem itthon. Az még nálunk csak a jövő. Lesz is belőle éppen elég fejvakarás.
Azért nem eszik ezt olyan forrón. Minden új területre eleinte nagyon a belépési feltételek, majd idővel csökken. Másrészt a data science, ml kapcsán a hypevonat már robog ezerrel, de ezek a projectek sokszor még majd csak jó lesz valamire alapon indulnak el, és vért izzadnak a salesesek, hogy rátukmálják valahogy az ügyfelekre.
> Minden új területre eleinte nagyon a belépési feltételek, majd idővel csökken.
Es ezzel egyutt csokken a penz, lehetosegek, stb. is. :)
Azt mondod kevesebbet keres egy programozó mint 10-15 éve, amikor még néhol ránéztek a diplomára is?
Nem, nem mondtam ilyesmit.
Olyat viszont igen, hogy egy uj teruleten az elejen vannak az izgalmas projektek, nagy zseton, stb. Amikor mar csak konzervmegoldasokat kell egymashoz celluxozni, ott mar nincs. Lasd machine learning algoritmusok fejlesztese vs Azure Cognitive Services API hivogatasa.
Az én időmben a BME tanulmányi és vizsgaszabályzatában a kettes pontosan azt jelentette, hogy a tananyagból MINDENT tudsz. ;)
A jobb jegyekhez ezen kívül még alkalmazni, kiválóan alkalmazni, sőt a tananyagot meghaladóan kell alkalmazni a megszerzett tudást.
Tán ezért is hívják a kettest műszaki jelesnek.
A tananyagot meghaladó alkalmazás és ismeretek elég jók a pályakezdéshez. Ha valakinek már van gyakorlata, az azért többé-kevésbé felülbírálhatja a kettes értékét.
Pl. szakirányú gyakorlat hozzátesz, drogdílerkedés levon - viszont akkor meg több pénzed lehet. ;)
Ez az én időmben is benne volt a TVSZ-ben, de már akkor sem volt igaz :)
Igaz, veterán vagy, én meg 20 évvel korábban jártam oda. ;)
Amikor én oda jártam akkor még szabad volt netet használni a BME-n is :)
--
Gábriel Ákos
Várjál, legutóbb még az sch miatt érte meg oda járni, mert ott tanultál meg mindent, nem az egyetemen.
Ja, persze az Sch-ban is volt net. Hol látsz ellentmondást?
--
Gábriel Ákos
Volt szerencsem dolgozni ML project len egy rovid ideig, illetve most is kapcsolatban vagyok a kollegakkal.
Szerintem hype-olt cucc. egy tensorflow-s data scientist arc eleg egy csapatban, ha van mellette nehany jo tradicionalis programozo.
A kihivas itt az infrastruktura: szerverek tanulasra, adatbazisok rendszerezese, stb... ha ez megvan, akkor kivalasztani egy jo nn architekturat mar egyszeru....
Illetve kitalalni, higy a celhardveren milyen architectura tud elfutni...
A mai ai sokkal inkabb szoftverfejlesztes, mint barmi elotte. A tensorflow-s matekos resze nem annyira igenyel jo programozot, mint kepzett data scientist-et, es az a kisebb resze a munkanak, szvsz
Idéznék ebből remélem nem csuknak le érte. Jó könyv egyébként, PACKT napi Free is volt párszor. :)
Chapter 1: Before You Begin...
However, before somebody can even start on the path of becoming a better software developer, one thing has to be true:
Inorder to be come an exellent programmer, you must first want to become an excellent programmer. No amount of training will turn somebody who does not want to be excellent into an excellent programmer.
Chapter 2: The Engineer Attitude
The attitude that every engineer should have, in every field of engineering, is:
I can solve this problem the right way.
Whatever the problem is, there's always a right way to solve it. The right way can be known, and it can be implemented. The only valid reason ever to not implement something the right way is lack of resources. However, you should always consider that the right way does exist, you are able to solve the problem the right way, and that given enough resources, you would solve the problem the right way.
There are lots of invalid reasons for not solving a problem the right way:
- I don't know the right way.
- The group cannot agree on what the right way would be.
- I am too lazy/tired/hungry/discombobulated to do this the right way, right now.
Chapter 3: The Singular Secret of the Rockstar Programmer
The better you understand what you are doing, the better you will do it.
"Rockstar" programmers understand what they are doing far, far better than average or mediocre programmers. And that is it.
All you have to do in order to become an excellent programmer is fully understand what you are doing.
A rockstar meg a ninja azon szavak koze tartoznak szakmai olvasmanyok eseteben, amikor azonnal abbahagyom az olvasast.
devops/java/stb-trendy-technologia magus, brrr.
____________________
echo crash > /dev/kmem
guru.
Itt éppen arról ír, hogy "Rockstar" mint olyan nincs. Csak olyan van, hogy valaki pontosan tudja és érti hogy mit csinál meg vannak a futottak még.
Innentől már "csak" évek kérdése, és elég nehéz az alapokat is megtanulni, amit 1-2 Udemy tanfolyamból nem lehet.
"Attila azóta több mint száz munkahelyre küldte el az önéletrajzát, tehát április óta ennyi munkahelyet célzott meg junior programozóként. Nem fejlesztőnek, hanem projektmenedzsernek jelentkezett, ami a régi szakmájával is korrelál."
Azért ehhez is kell önbizalom, hogy valaki kezdőnél is kezdőbbként zéró tapasztalattal projekt menedzsernek jelentkezzen. Még ha a korábbi szakmájával korrelál is.
Szerk. még egy gyöngyszem a cikkből: "az, hogy van babzsák meg kávégép, 2019-ben, ez az IT-szektorban alap."
Babzsák. Alap. :-)
Egyébként szomorú a történet, mindenkitől elnézést kérek, hogy viccelődök rajta, de hát vicces is, na.
Egyáltalán nem hülyeség. A managerek jellemzően nem fejlesztők. Nem értenek semmit a programozáshoz. Csak keleten divat, hogy fejlesztőkből csinálnak managereket, mert aki jól kódol és sokat látott már, az biztos jó lesz vezetőnek, szervezőnek. Hááát nem. :D
Ellenben olyan managerrel dolgozni, akinek van némi fejlesztői ismerete és képes megérteni azt, amiről a beosztottjai beszélnek, az nagyban segítheti a megfelelő döntéseket, irányítást.
Mondjuk nem derül ki, hogy a srác milyen mérnöki területről ment át és miért korrelál projektmanagerség a korábbi szakmájával. Némileg az is zavaros, hogy most akkor miért programozóként jelentkezik managernek... mertha projekt manager feladatra jelentkezik, akkor miért programozói tapasztalatot kérnek... bár lehet a hres sem tudta mit akarnak.
"Csak keleten divat, hogy fejlesztőkből csinálnak managereket, mert aki jól kódol és sokat látott már, az biztos jó lesz vezetőnek, szervezőnek. Hááát nem. :D"
Hát nálunk nyugaton is előfordul, hogy fejlesztőből lesz manager, de persze csak akkor, ha kiderül, hogy őt ez is érdekli, és jól csinálja. A végeredmény teljesen jó, ilyen ember tud legjobban a különböző "szintek között" közvetíteni.
+1, ezt hívják engineering managernek. Erős engineering alapok után elindul a management felé.
+rohadtsok
Egy jó Engineering Manager az volt engineer mielőtt manager lett.
"Ellenben olyan managerrel dolgozni, akinek van némi fejlesztői ismerete és képes megérteni azt, amiről a beosztottjai beszélnek, az nagyban segítheti a megfelelő döntéseket, irányítást."
Ha a manager nem érti amit a csapata csinál, akkor bizony a leghangosabbra fog hallgatni, és egy kis pechhel bizony rossz utakra téved. A költségek nőnek, termék meg sehol. Szerintem aki a menedzserséget olyanra bízza, aki nem érti a szakmát, az óriásit kockáztat. Én nem csinálnám az tuti. Legalábbis saját pénzből nem, LOL.
Nyilván vezetői képesség is kell hozzá, azért annyira ritka a jó menedzser.
> Ha a manager nem érti amit a csapata csinál, akkor bizony a leghangosabbra fog hallgatni
Akkor nem csak a programozashoz, de a managementhez sem ert. :)
Azért néhány megjegyzést elejtettek a cikkben, ami szerintem ismerős dologra utal, amelyet máskor is felhoztak sokan a több ezer üres pozíció vs munkakeresés témában:
- egyszeri alkalommal 2 pozíciót vállat a máv
- egy junior a cibhez
- pár százezres jutalékfizetési kötelezettség miatt inkább nem veszik fel
...
Ebből nekem az jön le, hogy az a 100 pozíció, amire a 60-90 partnerrel megállapodtak, az betelt. A cégek pedig lehet, hogy örülnének több munkaerőnek, csakhogy megfizetni nem tudják őket. Ilyenkor jön a szokásos történet, hogy a portás béréért felvennének fejlesztőnek valakit és panaszkodnak, hogy találnak embert a pozíciókra.
Gondolom közben valami opensource fejlesztést vagy hozzájárulást is csináltak, ami mutatható egy önéletrajzban. Esetleg a netről továbbképezték magukat, vagy specializálódtak.
Ja, nem.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Mondjuk én is erre gondoltam, hogy ha csak a munkatapasztalat hiánya a gond, azon bármikor lehet segíteni, persze benne van a pakliban, hogy ingyen kell dolgozni egy ideig. De úgy tudom, hogy pl. az ügyvédek is elég sok ideig ingyen/semmi pénzért dolgoznak az elején, mire kapnak egy komoly ügyet.
De reálisabb lenne úgy hirdetni ezeket a képzéseket, hogy sok hónapnyi ingyen munka lehet szükséges az álláskeresés előtt.
Jogi és némelyik mérnöki területen jogszabályi kötelezettség bizonyos évnyi gyakorlati idő teljesítése, hogy utána önállóan is dolgozhassanak.
Ezzel persze vissza is élnek sok helyen. Érdekes volt egyetemi koleszban a leendő jogászokat hallgatni arról (10+ éve), hogy nem ingyen dolgoznak, hanem a papíron kifizetett fizetésük járulék tartalmát is be kellett fizetni az ügyvéd úr zsebébe... ahová a fizetésük is vándorolt. Talán nem véletlenül olyanok a bíróságok és a magyar jogi szakma, amilyen... ha csicskáztatás és adócsalás a beugró.
Miert, milyen a magyar jogi szakma? Mennyivel masabb, mint [insert tetszoleges nyugati orszag]?
> De reálisabb lenne úgy hirdetni ezeket a képzéseket, hogy sok hónapnyi ingyen munka lehet szükséges az álláskeresés előtt.
Ez nem kepzes-specifikus, egyetemet vegezve sem nagyon rugsz labdaba, ha csak a diplodat csinaltad meg 3-5(-10) ev alatt.
Eközben a valóság, hogy a BME-n harmadévben kb. mindenki dolgozik, és nem a mekiben.
Nincs itt ellentmondas szerintem.
> egyetemet vegezve sem nagyon rugsz labdaba, ha csak a diplodat csinaltad meg 3-5(-10) ev alatt
Aki dolgozott mellette, annak konnyebb lesz frissdiplomaskent. (Az internshipet ne nagyon keverjuk szerintem a frissdiplomas fulltime munkavegzessel, elegge mas a ketto, nemcsak munkaido szempontjabol.)
Hat pedig dehogynem... "Voltak ... nehezebb időszakok, mint például amikor egy egész hétvégét végig kellett tanulnia".
Egy egesz hetveget vegigtanulni szerinted nem eleg? /s
"az alábbi történetek főszereplői nem a valódi nevükön nyilatkoznak, és a történet lényegét nem befolyásoló módon egy-két helyen megváltoztattuk az adatokat, hogy felismerhetetlenek maradjanak."
ja persze, az index az pont olyan, hogy a történet lényegét nem befolyásoló módon változtat meg dolgokat :)
Nem álompálya, nem fenékig tejfel.
Döbbenet.
Korrekt cikk. A végén a "területre rálátó szakértő" meglátásaival maximálisan egyet tudok érteni, én is ezt látom. Az elmúlt évtized pénzbőségének vége, a világgazdaság kezd kiszikkadni. A fingósapp gyártó startupok korának leáldozott, már nem találnak befektetőket, a nagy multik is már inkább a féket nyomják, mint a gázpedált. És ez még csak előszele a válságnak.
Azért nem kell az IT-t temetni persze, még mindig rengeteg a projekt, senior/expert szinten annyira nem fog ez érződni, olyan elképesztő a hiány. De azok a tömegek, akik most ugranak fejest a szakmába rendes végzettség nélkül, végső elkeseredettségükben a fizetett hirdetéseket olvasva, azok bizony pofára fognak esni.
Szerintem csak símán kezdi éreztetni a hatását az ami külföldön kezdődött el és az átalakulás még mindig tart, miszerint a mester diploma és a matek eléggé szükséges de persze nem elégséges feltétele az új munkatársnak. :)
Persze ez nem az írjunk egy weboldalt magasságán van, hanem a Machine Learning, Data Science, Robotika vonalon jött be. Mivel ezek a területek a mai fejlesztésekben egyre több hangsúlyt kapnak, ezért a bootcampben végzett juniorokra egyre kevesebb szükség lesz.
>Persze ez nem az írjunk egy weboldalt magasságán van, hanem a Machine Learning, Data Science, Robotika vonalon jött be. Mivel ezek a területek a mai fejlesztésekben egyre több hangsúlyt kapnak, ezért a bootcampben végzett juniorokra egyre kevesebb szükség lesz.
Az érveléseddel az a gond elsősorban, hogy ezek új területek, amik a "hagyományos" területekkel max annyira vannak kapcsolatban, hogy elszipkázzák a képzettebb munkaerőt.
A ML, meg a többi buzzword nem csökkentette a web/mobilapp fejlesztők számát, sőt, a sok új projektnek/startupnak köszönhetően extra felület igények keletkeztek.
Szóval ezek alapján a bootcampes kódpüfölőkre pont, hogy növekedett az igény. :)
Fejlesztésben pedig az AI szerepe még nagyon sokáig inkább support jellegű (pl. kódkiegészítés okosítása) marad, mintsem hogy "e'vennék a munkát".
Viccesen fogalmazva, az a technológia amiben nincsen AI és blcokchain, abban már nem is hiszünk.
Én sem azt mondom, hogy és holnaptól az összes webprogramozó lehúzhatja magát. Ne ennyire végletesen gondolkozzál. Az van, hogy egyre növekszik a felhasználása. Egyre több olyan emberre kell majd.
A bootcampes juniorral az a baj, hogy vagy megvan a matematikai előképzetsége, vagy nincs. Ebből inkább a nincs a jellemző. Ha megvan, akkor könnyen tanítod meg neki az új bonyolult dolgokat is, és akár arra a területre is behozhatod, valamilyen szintig. De a legtöbbje minden elméleti háttér nélkül van, ahol még egy új framework tanulása is nehéz.
Valamint a valamire való seniorokat képzik majd ML és társai irányba, meg úgyis kevés van belőle. Egyszerüen már ma sincsen elég senior a juniorok ápolgatására, nem beszélve a nagyon "hátrányos" kezdetűekről.
AI szerintem, hogy a programozói melót elvegye kicsit odébb van, support jellegű valószínű lesz egész jó, nemsokára. Inkább az fordulhat elő, hogy a programozóknak kell egyre több AI-t készíteni, egyre bonyolultabbakat, amihez kell a képzetség.
Bocs, de nálad beakadt a lemez? Mintha el se olvastad volna amit írtam. :/
Még egyszer: attól, hogy tök új területek jelennek meg, ha a régi területeket ezek nem érintik közvetlenül, akkor a munkaerő igényt se fogják csökkenteni, sőt, inkább növelik.
Arról meg senki se beszélt, hogy 10-20 év múlva mi lesz, itt most a jelenleg zajló folyamatok, közeljövő volt a téma. Nem is látom sok értelmét a távoli jövőről okoskodni őszintén. A mostani buzzword foglalkozások nagy része lehet megy a lecsóba, lehet kiderül, hogy mégse kell annyi neurális háló turkász, vagy bigdata búvár, mert a területek kiforrottá válásával a polcról levehető megoldások megfelelőek lesznek az átlag felhasználási módhoz, amit kívülről tud használni akár egy manager is, miután az OKJ-s kódverő Józsika feltelepítette nextnextfinish a modult.
Lásd pl. szabályozástechnika, az is nagy buzzword volt, persze értelmes és nagyon fontos dolog, de azért nem kellenek szakértőkből tömegek az átlag fejlesztési feladatokhoz.
Kb azt lehet tudni, hogy ami ma a Silicon Valley-ban megy a tech cégeknél, az kb 5éven belül itt van. Nah ez a folyamat amit írtam 2018 óta van kint, még pár év és itt is érezteti a hatását.
Kb az, amiről a meetup-ok meg megszaporodnak a világon, az a technológia lesz a következő 2 éven belül itt. Ez pedig a quantum computing, amihez megint eléggé felkészültnek kell lenni.
Ettől még szükség lesz mezi kóderekre is. OKJ lehet kevés lesz, lehet elég, ezt nem tudod megmondani. Egyenlőre szerintem elég lesz.
Szabályozástechnika pont rossz példa. A lineáris szabályzókból, rendszerint PID, kihozták amit ki lehettett. Most megy a fejvakarás és kezdődik a nemlineári szabályzók kora, ahhoz viszont kicsit durvább felkészültség kell majd.
Az is probléma, hogy nem csak egyre bonyolultabb lesz a technológia, egyre több felkészültséget igényel, hanem az is, hogy irtó gyorsan változik. Olyan munkavállaló kell, aki gyorsan tudja tanulni. Meg kellenek olyanok, akik gyorsan tudják írni ezeket. 2018-ban az USA-ban több PhD-st vettek fel, mint MSc-st. Pont emiatt. Símán megérte már a dupla bér az MSc-shez képest. Szerintem ez egyébként megint túljátszása a dolgoknak, mert a sok junior mellé kellenek a seniorok, azokat leggyorsabban, meg MSc-sből csinálsz. Szóval szerintem itt még várható ingadozás. De ez nem 10-20 távlata, talán még 5 se.
Mégegyszer hangsúlyoznám, ez nem azt jelenti, hogy egyszerű programozóra nem kellene, mert csak a hatvanyolc diplomás harminckét PhD-s nagyon doktoroknak fog állni a zászló, hanem azt mondom, hogy megjelenik egy új réteg, és ez csökkenteni fogja az egyszerűbb helyeken dolgozók bérét.
Nem hinném, hogy csökkentené - nem ugyanazon a piacon versenyez egy kutató-fejlesztő szakmmérnök, meg egy webshopprogramozó technikus. Totál más cégek alkalmazzák őkat, totáls más feladatokra.
Mint ahogy nem ugyanazon a piacon versenyez a mesterszakács meg a kifőzdei alkalmazott sem.
A fizetése meg annak fog nőni, akire nagyobb igény van. Simán eljöhet olyan időszak, amikor az "érjünk utol magunkat" mentén pont a baromi drága fejlesztőmérnöknek mondják meg, hogy köszi, de nincs rád szükség, mert amivel dolgoznál, abból csak 10 év múlva látunk pénzt, és most válság van, erre nincs finanszírozás.
>Szabályozástechnika pont rossz példa. A lineáris szabályzókból, rendszerint PID, kihozták amit ki lehettett.
Akkor miért is rossz példa? Oké, hogy lehet lesz reneszánsza a területnek, de ahhoz képest, hogy nyomták anno, messze nem lett annyira alapszükséglet a szakterületi tudás.
>2018-ban az USA-ban több PhD-st vettek fel, mint MSc-st. Pont emiatt. Símán megérte már a dupla bér az MSc-shez képest.
Forrást tudsz adni erre? Elég hihetetlenül hangzik.
>hanem azt mondom, hogy megjelenik egy új réteg, és ez csökkenteni fogja az egyszerűbb helyeken dolgozók bérét.
Miért csökkentené? A bérek piaci alapon működnek. A fentebbi KKV-s kis rendszergazdás példád is nagyon sánta. Ott sem azért estek a béka segge alá a bérek, mert megjelentek/elterjedtek más üzemeltetési területek. Hanem a könnyű belépési küszöb miatt részben borzasztóan telített lett a piac, közben pedig a felhősödés, egyéb IT folyamatok csökkentették a munkalehetőségek számát.
Igazad van abban, hogy folyamatosan egyre komplexebbé válik a világ, így a betöltendő pozíciók is, de ezen túl össze-vissza ok okozati kapcsolatot kötsz olyan folyamatok közé, amiknek semmi köze egymáshoz.
Azért nem, mert csak bizonyos cégek specializálódtak erre. Nem mindenki akar önvezető autót csinálni, vagy egy sima motorvezérlést. Vagy akár ipari robotot, erre megvannak a főbb cégek, meg pár Tech nagyágyú mint pl a Google, de pl kkv világ ebből kimaradt.
Viszont most kezd el pörögni az automatizálás üzleti/céges folyamatokra (RPA). Még szerintem gyerekcipőben van az a terület, de ott kezdik pedzegetni, hogy AI, szabályzástechnika vonalról kellene behúzni ötleteket, Nah az a rész az, ahol a PID tuti semmit nem fog érni. De szerintem annak kell jópár év amíg kifutja magát.
Azt a konkrét cikket nem találtam meg, ahol olvastam, de egy nagyon hasonló cikket találtam a nature-ben, hogy miért is poén a cégnek a PhD, még akkor is, ha jóval drágább.
https://www.nature.com/articles/d41586-019-00097-x
A belépési küszöb nem igazán lett sokkal könyebb. Régen is elég volt egy vastag könyvet elolvasni és 2x megcsinálni, meg ma is, persze azért vannak különbségek, de nem olyan egetrengetőek. A belépő tudás értéke ami változott. Mivel többek számára lett elérhető.
Ugyanez vár a fejlesztőkre is. Mondjuk a mostani UX designertől elvárják, hogy le is programozza a felületet, ne csak egy PSD-t adjon le. Mivel mostmár a teljes "felhasználói élményt" neki kell megcsinálni, jelentsen ez bármit is. :) Lényeg, hogy alap javascript, swift, java tudásának lennie kell. Ha már mindenki tudja akkor csökken az értéke, mert könnyebben találok az egyik arc helyére egy másikat.
A sok matekato igénylő területekből értelemszerűen meg kevesebb arc van, aki ért hozzá. Ha a terület jelentősége nő, akkor nő a kereslet, de kevés ember van, nyílik az olló. Szerintem az szépen látszik, hogy mi lesz alul, az is, hogy mi lesz felül. Arra viszont nem vállalkoznék, hogy megmondjam mi lesz a kettő között.
Ez nem alul meg felül lévő dolog. Vannak niche területek, amivel mondjuk 10 cég foglalkozik a világon, meg van olyan,a mivel 10 cég foglalkozik egy adott utcában.
Nem versenytársai egymásnak, hogy alul meg felül legyenek.
Jó, hatékony (mérések által bizonyítottan hatékony), használható, akadálymentes, ergonomikus gördülékeny UI-t csinálni pontosan ugyanannyi tanulást igényel, mint az, hogy Tensorflowval betaníttatsz egy modellt. Ami vagy sikerül, vagy nem. Mint a UI is.
Engem az erdekelne hogy honnan dudod mi van a Silicon Valleyben. Nem bantasibol csak erdekelodesbol kerdezem. Nagyon erdekel a tema hogy hogyan tudok naprakesz lenni. Ne legyek outdated 3 ev mulva
Nature elofizetes?
futurism.com?
Mi a jo source?
Eddigi hozzaszolasai alapjan nekem az jott le, hogy a CEU genderszakan PhD hallgato. De persze lehet valami random kanadai/sved egyetem is.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Most aztán nagyon nagy arc vagy.... Csak gratulálni tudok.
(egyébként nem)
Igazabol ennek orulok, mert szakmai temaban erdekes eszreveteleid szoktak lenni. Ha nem vagy genderszakos, idovel a SJW agymosast is kinovod.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Ha még nem esett le, akkor kicsit segítek. Olyan munkám van, ahol minden emberre nyitottnak kell lennem. Lenne is nagy felhördülés, ha ilyet tennék.
Igen, zavar a nyilt antiszemitizmus, zavar ha bármilyen hovatartozása, miatt, akár politikai is kirekesztenek bárkit. Milyen közösség az, ahol azért mert a másik piros cipőt hord narancssárga ruhával, azért nem beszélnek vele. Ha ezeket itt megengedjük, akkor a hup nem egy közösség lesz, hanem egy szétdarabolódott akármi.
Olyan munkám van, ahol minden emberre nyitottnak kell lennem vs. zavar a nyilt antiszemitizmus
Lehet h az a munkakör akkor nem igazán neked való! Legalábbis elég frusztrálónak tűnik, h olyan nyitottságot gyakorolsz munkaköri kötelességként, ami ellenkezik a meggyőződéseddel! Jó, persze lehetnek kifacsartak élethelyzetek, amikor azt a munkát is el kell vállalni, ami nem éppen van ínyére az embernek.
Ez már a végleges verzió ?
Nem, most akartam rátérni erre:
> bármilyen hovatartozása, miatt, akár politikai is kirekesztenek bárkit
Akkor nem lehet érteni, h antiszemita nézeteket magad miért rekeszted ki?
Ez amolyan liberális önellentmondás! :)
Nem ez ilyen polgári jobboldali önellentmondés. Tudod mi konzervatívok már csak ilyen maradiak vagyunk nem érthetjük az ilyen szabad szellemet mint te.
Ááá új szó konzervatív. Az eddigiek tükrében meg lennék lepve ha értenéd, mit takar!
Meg lennék lepve, ha ezt egy nemzeti szocialista el tudná dönteni....
Meg lennék lepve, ha létezne egy téma ami nem ide fakad ki.
-
Álláshirdetések, meetup kiírások. Nyilván nem tűpontos, de azért nagyjából lehet látni
> Mi a jo source?
Bar nem engem kerdeztel, de en peldaul podcastekbol tajekozodok.
Tipikusan a podcast keszitok elkottyantanak ezt azt a maganeletukrol.
A valsagot meg pl. egy Elon Musk earnings callbol tudom, hogy lesz:).
Amikor a millio kocsi/ev csak ugy fog osszejonni, hogyha a modell Y-t is hozzaveszik, mert a 3-ra a valsag miatt nem lehet tovabbi keresletbovulesre szamitani(500k/evnel tetozik).
A silicon valley legkort pl. egy machine learning podcastbol tudom, ahol nehany interviewjarol meselt a keszitoje.
Pl. tudtatok hogy az auto kotelezo biztositasa Californiaban tipikusan 180usd/*honap* ?;)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Amikor szembesül vele, hogy az elmélet alapján egy kódot/algoritmust megírni szép feladat... de hogy abból production (értsd: pénz) legyen, az már más kérdés.
Engem ez a része érdekel:
"általános szoftverfejlesztőket képeznek, amire egyre kevesebb szükség van, és már látható, hogy ezen a területen évek múlva jelentős lesz a robotizáció, az automatizálódás."
Ki mit lát/vizionál 5 év múlva sw dev robotizáció és automatizálódás témakörben? Vagy ez csak annyit jelent, hogy a minden szoftverben közös részek (kb. 80%) egyre inkább felhőből jönnek majd összekattogtatós felületről (pl. firebase, oauth, stb., stb.) és csak az effektív core lesz fejlesztve/szoftver, semmi más?
Amikor megjelent az elso kattintsd ossze a kododat GUI-n az android whatever szoftverben akkor is temettek a programozast. Ez talan 2010 korul volt :D
Fiatal vagy te kistigrincs :D Ezt már 90-es években eljátszották az első GUI builderekkel. Volt ami egyébként meglepően jól sikerült, a Delphi ilyen szempontból egy sikerplatform lett.
Bar ugy lenne. Igen minden platformon eljatszak ezt 5-10 evente. Az androidos is egy pelda volt.
Szerintem arra gondolhat, hogy egyre távolabb kerül a kóder a tényleges dolgoktól, mert leginkább kész dolgok használatából lesz építve minden.
Én is erre tippelnék hogy a "LEGO" irányba megy el a dolog.
Én azt mondom, hogy olyan lesz mint az üzemeltetés. A kistudású kóder minimálbér közeli rabszolga. Valamint elsznek a nagyon sok matematikai és egyébb ismerettel rendelkező és ezt algoritmizálni, felhasználni valós problémára tudó nagyon jól megfizetettek kasztja.
A kistudású kóder minimálbér közeli rabszolga.Ez a UNIX előtt is így volt, pont emiatt akkoriban még a nők uralták a szakmát. Visszatérünk ugyanoda. :)
Csak a teljes Apollo program kódját nők írták.
pl az Apollo 11 kódja kint van github-on:
https://github.com/chrislgarry/Apollo-11
https://www.youtube.com/watch?v=B7CnVGtd1_Y
Szóval inkább gondolkozz mielőtt bunkóságokat irogatsz.
Tudok róla. https://progmasters.hu/2017/08/16/noi-programozok-szerepe/
Pont mostanában láttam a Hidden Figures c. filmet ami bemutatja a női "computer"-ek munkáját is: https://www.imdb.com/title/tt4846340
Az egy nagyon jó film.
Igen. Arra is volt benne példa amiről ebben a topikban is szó esik: ha olyasmivel foglalkozol, amire már nincs igény, akkor hiába vagy / voltál benne profi, muszáj megtanulnod új dolgokat, különben könnyen munka nélkül találhatod magadat. Lásd a csapatnyi nőt akik titokban átképezték magukat Fortran fejlesztőnek amikor kezdett rezegni a léc az IBM számítógép megérkezése után.
DEhogy nők írták. Nők IS írták. Margaret Hamilton volt például a recovery meg priority control felelőse.
A fő hardver architekt Eldon C. Hall volt, az AGC operációs rendszerének (az Executive meg a Waitlist) a fő architektje Hal Laning volt.
Fontos szerepe volt még Ramon Alonsonak, Hugh Blair-Smithnek, meg sokan másoknak is. Margaret Hamiltonnak is.
Az egész AGC egy érdekes dolog volt, mind hardveresen (az első IC-s embedded gép, aszinkron logikával 3-bemenetű NOR kapukkal megcsinálva, ahol az ALU semmi mást nem tudott, mint összeadni, és mikrokódos gép volt), és szoftveresen is.
Érdemes elolvasni az AGC Digital Development Memo, meg AGC Information Series, Luminary Memos, Colossus Memos sorozatot, ha tényleg érdekel. Ezek eredeti MIT IL, illetve NASA belső feljegyzések voltak a fejlesztés során, sok fennmaradt, de sok sajnos elveszett.
http://www.ibiblio.org/apollo/links.html#agcis
Szoftvert fejleszteni annyi, mint megérteni azt, hogy a gép GIGO módon működik. És mindig pontosan azt csinálja, amit mondunk neki. És mindig azt kell neki mondani, amit csinálnia kéne. Kattintgathatsz te firebase-t, vagy oauthot, ha éppen nem arra van szükség, akkor cska nézegetsz, ha tényleg azt gondolja az ember, hogy összekattingatós, legómunka a szoftverfejlesztés.
A fejlesztés legnagyobb része a megértés. A problématér megértése, az elérendő cél megértése. Hogy kitaláljuk, mi a legjobb megoldás az adott problémára, vagy probléma-elemre: dobozos szoftver, más által írt szoftver egyediesítése, vagy saját szoftver. És ha saját, akkor mit kell tudnia, mit miért kell tudnia, mit hogyan kell tudnia.
Ezt a tudást nem lehet összekattingatni.
Az, hogy Firebase van, OAuth van, azok csak eszközök, "kalapácsok". De a házak nem "kalapácsokból" épülnek.
Ez egy nagy +
Amit még hozzászoktam tenni: a folyamatok időbeli rendezettsége az egyik kulcs. Ha fejben összerendezed, hogy mikor mi történjen, gyakorlatilag megoldod a problémát, attól kezdve favágás. És ez nem programkód, hanem a kockáspapír, ceruza, radír szintje.
A témához szólva: a kiadott programozói jogosultságok - bármilyen szintűek is legyenek azok - nem fogják megváltoztatni a populáció genetikai állományát. Azzal kell gazdálkodni, ami rendelkezésre áll és ami rendelkezésre áll az annyit ér a piacon, amennyit adnak érte.
> Sol omnibus lucet.
"És mindig pontosan azt csinálja, amit mondunk neki." A legszebb, amikor nem és ki kell találni, hogy akkor most a compiler csinált valami baromságot, vagy a hardver kuka.
Én kerek semmit nem látok abból hogy a kódolást automatizáljuk, valaki elmagyarázná hogy miről megy a vaker? :)
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene
15 éve még írtál magadnak ORM-et, most már nem.
15 éve még írtál magadnak WYSIWYG editort, most már nem.
15 éve még soaptál a kliens-szerver kommunikációval, azóta nyugi (rest) van. :)
Szerintem erre.
Csak ezt egy junior nem tudja. Egy juniornak el kell magyarázni, hogy miért jó a api kulcsos autentikáció, egy juniornak el kell magyarázni, hogy ne találja fel a spanyolviaszt.
Ezek mind-mind interfészelések csak egy-egy "külvilág" felé, legyen az egy másik service, perzisztens tár, vagy épp a felhasználó.
Az üzleti logika, a megértés, a lényeg, viszont nem itt van.
Pont az ilyen interfészeléseket kell elabsztrahálni, eltávolítani a szoftver lényegi részétől. Ezek az interfészelések nem a lényegi részek.
Az igaz, csak amikor rájön a kiscsávó, hogy a fantasztikus ORM-je elhazudja neki,hogy nem kell az SQL-hez értenie, közben meg igen,
és az egész rendszer teljesítménye a béka segge alatt van, akkor jön a pislogás.
A SOAP jó volt :D De azóta van RAML/Swagger, amiből ugyanúgy generál kódot, mint amikor a WSDL-ből tette.
Ebben egyrészt tök igazad van. Másrészt ez (ORM tuning/SQL) nem a junior szint.
Ne tegyünk úgy mintha spring-el nem szívtunk volna be valami hasonlót anno... :)
--
Gábriel Ákos
Isten ments', hogy a junior kezdjen el érteni az sql-hez, jó lesz neki az orm is, hidd el. :)
aztan nehanapjan megnezed mi fut le es dobsz egy hatast :D. marmint elsonek a SYSDBA, te csak utana :)
Láttam én 3 percig futó SQL lekérdezést, amit az ORM generált ki, mert "jó volt az a juniornak"...
.
Háát, ezt én így nem jelenteném ki. A JPA például tipikus példa arra, hogy hogyan ne írjunk ORM-et. Akkor már inkább valamilyen minimál wrapper SQL felett. Egy jó példa erre a JDBI: http://jdbi.org/
Ugyan miért? Az egyszerűbb lekérdezést azért egy normális juniornak illene tudnia megírnia SQL-ben is, a tényleg összetettet meg egyszerűen nem kell rálőcsölni, mert azt szarul fogja az ORM kínálta lehetőségekkel is.
Az ORM-el az a fő baj, hogy egy elég komoly architekturális döntés a használata, onnantól, hogy használ egy frameworkot az ember, illik minden kérést azon átzavarni - már ha nem akarod a cachinget pl. kikapcsolni, tovább rontva a teljesítményt. Elég alaposan "becsomagolja" az adatbázist fejlesztői oldalról nézve.
Ez egyszerű fütytfürütty alkalmazásoknál lehet nem gond, de komplexebb enterspájz környezetben ordasakat lehet vele azért szopni, láttam olyat ahol több szívás volt vele végül, mintha a seniorok írták volna valami vékony SQL kód generáló libbel (jOOQ, QueryDSL) maguk meg az összes lekérdezést...
Hát peeersze. Aztán lesznek a hulladék adatbázisok, mert fogalma sincs arról, hogy a relációs adatbázis egy tök jó koncepció, és lesz használhatatlanabbnál használhatatlanabb adatbázis, mert se normális táblaszerkezet, se semmi.
Programozóként könnyű hozzászokni az absztrakciókhoz és az ORM szerintem egy nagyon hazug absztrakció, mert ugyan megoldja azt a problémát, hogy valahogy belegyömöszöljék az objektumokat egy adattáblába, csak épp nem biztos, hogy az a praktikus tárolási módja neki.
Másik, hogy erősíti azt a hozzáállást, hogy "jaj, az adatbázis, ahhoz nem nyúlok". Könnyen ahhoz vezet, hogy egy mágikus feketedobozként tekintsenek rá, annak tulajdonságait ignorálva viselkedését nem értve.
A másik meg, amikor napokat szenved valaki mert az ORM rétege nem nyújt valami SQL-es featurera megoldást és implementál egy komplexebb összesítás-szűrést-rendezést, amikor igazából lenne rá query. Arról nem beszélve, hogy közben mennyi adatot mozgat meg ORM-en keresztül ahelyett, hogy csak a tömör összesített végeredményt kérdezné le.
Szvsz. ORM-ezni az ORM-ezzen, aki érti is, hogy mi történik a felszín alatt, mert nagyon észnél kell lenni a határokkal.
> Szvsz. ORM-ezni az ORM-ezzen, aki érti is, hogy mi történik a felszín alatt, mert nagyon észnél kell lenni a határokkal.
+1
Ezek interfészek meg framework -ök, amik tényleg sokat fejlődtek, de ettől még ugyanolyan sokat kódolunk, csak jobban tudunk az üzleti logikára fókuszálni.
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead
Azért az üzleti logikára fókuszálásnál is előfordulhatnak érdekes balesetek. Kb 20 éve a százalékszámítás volt a legbonyolultabb művelet. Azért mostmár egy-egy solvert ráengednek a problémára. A jövőben azért lehet számítani arra, hogy kicsit megnő az igényük. Mint ahogy a kémikusok jártak, hogy mivel már senki nem értette, hogy mit csinálnak, kénytelenek voltak megtanulni kódolni, hogy megírják a saját kis megoldásaikat.
Amúgy érdekes amiket írsz, de eközben a Földön azt látni, hogy a legtöbb ember azt sem tudja, hogy van problémája. Egy kevés tudja (vagy csak érzi), de nem tudja mi az ő problémája. Még kevesebben tudják mi a problémájuk, de fogalmuk sincs hogyan oldják meg.
Amúgy azt látom, hogy az adatbázisoknál* kb megtörtént már az ami a programozásra várhat, de eközben kialakult egy (több) új szakma, ami az adatbázisokra épül vagy támaszkodik.
*Kezdetben volt az adat és pár algoritmus ami valamit művelt velük. Aki gépet használt és adatokat annak valamennyit ehhez is kellett értenie. Majd az adatbázis hozott egy nagy megújulást, de attól még nem lehetett valaki full hülye, hogy elboldoguljon a témában. Sőt!
Ezt amit írtam, szerintem a következő 5 de inkább 10 év kihívás, ez még nagyon alakulni fog, mint minden.
Remélem azért nem látjuk annyir rosszúl mint a kapcsolódó viccben, miszerint:
A 60-as években repülő autókat, meg Marsi vakációt ígértek nekünk. Erre kaptunk 160 karaktert.
Bár aztán ki tudja. :D
Amit te mondasz azt én is látom, hogy a jelenleg kis létszámú akadémiai tudású emberek száma megnő, mert az iparnak is szüksége lesz a magas szintű természettudományi tudásra. Mindeközben a többség butul és már csak csökkentett tudású felhasználóként van jelen. Alapvetően a cégemet is így vezetem, hogy minél kisebb tudással minél magasabb színvonalú munkát tudjak elvégeztetni az emberekkel, ehhez jó rendszer kell. Nagyon fontosnak tartom, hogy gyors legyen a betanulás és ne számítson az, hogy kivégzi a munkát. Ne kelljenek jó emberek, mert van jó rendszer.
Igazából PhD-s embernek sok előnye van, csak nem mindig van ezekre az előnyökre szükség. Pl Gyorsan önnáló tanulási képesség, innovációs, kutatói képességek, jó vitakézség, normális előadó készség, valaimnt csapat irányításáról is van fogalmuk. Természetesen ez alól is van kivétel, de alapvetően ezek a softskillekkel rendelkeznek a PhD-sok. Egyszerre képes one man showt csinálni, mikor meg kell tudni, hogy eldöntsék, hogy megelelő irányba menjenek, ezt nagyon szépen meetingen meg tudja védeni az álláspontját, majd oda lehet adni neki a teamet pár dörzsölt senior-ral, akik biztosítják, hogy akkor az minőségileg is jó legyen.
> normális előadó készség, valaimnt csapat irányításáról is van fogalmuk
Hat, en arra tippelnek, hogy itt nincs eros korrelacio a PhD es a fentiek kozott. :D
Pedig de. Mondjuk sok függ attól, hogy hol tanult az ember. Ha olyan profok között volt ahol az volt a menő, hogy mindenki megértse, akkor ott kifejlődött ez a képesség. Vagy a mai korban, azt látták, hogy mennyire cool a Gilbert Strang (https://en.wikipedia.org/wiki/Gilbert_Strang), vagy a Leonar Susskind (https://en.wikipedia.org/wiki/Leonard_Susskind), azok rendesen megtanultak előadni. Ha abba szocializálódott bele, hogy "szivassuk meg a kis mocskokat", akkor nem. Viszont már itthon is az a kissebség.
Utolsó mondatodban nagyon szépen leírtad a fontoskodás definícióját! :)
Nagyon nem. Mert pl az oktatóanyag nem csak úgy keletkezik. Kevés MSc-s van aki csont nélkül tud gyorsan tanulni tudományos cikkekből. Egy jól megírt oktatóanyagból símán. Sokkal lassabban dönti el, hogy mi és hogyan legyen jó, mivel sokkal lassabban érti meg a dolgokat. Nyilván ez egyénfüggő is, de most a nagy átlagról beszéltem.
Volt egy phd-s kollégám 1,5 év két helyen összeszedett munkatapasztalattal, aki kijelentette, hogy "szar az egész", majd elvonult duzzogni, hogy addig se kelljen dolgozni. Nem olyan egyértelmű ez.
Szóval azért mert láttál valakit aki szerinted nem ütötte meg a szintet, azért az összesre lehet levonni következtetést?
Szóval azért mert láttam egy rossz üzemeltetőt, azért az össze használhatatlan lusta, és ugyanez fejlesztőre? Természetesen nem.
Ha szerinted ezt írtam, akkor hisztizz csak nyugodtan.
Szóval te voltál az. :)
Természetesen nem, csak próbálom felhívni a figyelmet arra, hogy a PhD-s nem feltétlenül pl egy jobb programozó. Sok esetben PhD-st leülteted fejéeszteni, az olyan mintha az üzemeltetőt vagy a managert ültetnéd le. Annyi különbséggel, hogy viszonylag gyorsan beletanul egy szintig és akár tűnhet is úgy, hogy ő fejlesztő, csak ritka béna. Ez természetesen nem zárja ki, hogy valaki pl fejlesztő és abból is jobb, valamint PhD-s is. :)
Szóval ne a most hagyományos munkakörökben ítéljétek meg. MIvel amikor azok kialakultak még nem is volt az iparban sok PhD-s. Ez most valami új rendszer. Természetesen ebben a saját szerepkörükben lehet valaki jó is meg rossz is, teljesen úgy mint ahogyan van jó és rossz fejlesztő, vagy üzemeltető, manager....stb.
Az, hogy minek nevezzük, talán mindegy is, de arra próbáltam sután célozni, hogy egyre magasabb szintű absztrakciót vezetünk be a programjainkba és a végén már tényleg csak a "kreatív alkotás" lesz a feladat. Ahhoz meg bizonyos szinten nincs szükség nagy programozásra, például egy felhasználói felületet sem osztályokból építesz fel, hanem a wysiwyg tervező generálja le neked a kódot... Péládul.
.
Bullshit. A marketinges, a dizájner és a manager még megfogalmazni sem tudja, hogy mit szeretne. Maguktól arra sem jönnek rá, hogy az általuk megálmodott, megrajzolt dolog nem csak úgy a semmiben működik, hanem valaminek fel kell dolgoznia és tárolnia kell az adatokat.
Ha összekattintgatós programozás lesz, akkor ahhoz értő programozó kell, aki tudja milyen pontokat mivel kell összekötni. De ami még fontosabb, ki kell húzni a feladatot megálmodó kollégákból, hogy valójában mit is szeretnének megvalósíttatni.
És akkor még nem is beszéltünk arról, hogy adott varázs rendszerben mi megvalósítható és mi nem. Melyik komponensnek mit enged meg a licensze és mit nem. Mert a jogi osztály persze nem érti a technikai szöveget.
A felsorolt technológiákat ma is licenszelik, előfizetik, pláne, ha hosszabb távon skálázódás is szükséges, mert nagyon a tervek.
Végtére is minen szoftvernek van 3 közös része:
1. valahonann adatokat kér
2. valahogy feldolgozza
3. valakova kiköpi
Amúgy meg a Linux kernel is ilyen összekattogtatós dolog (na jó azért oda kell figyelni sokmindenre), ha ezt a menüs konfigurálós módszert tovább vinnék egy egész disztribúción, már meg is lenne egy összerakhatós oprendszer.
./configure paraméterekkel is sokmindent lehet le lehet tiltani, vagy engedélyezni egy felhasználói peogramban is... már csak annyi kéne, hogy szabványosítani ezeket a paraméterezéseket, meg írni hozzá egy grafikus menüt, és akár komplett oprendszerek is összerakhatóak lennének. ... akár "felhőből" is.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
Hagyjuk már. Az egész egy újabb get-rich-quick scam.
Az IT-ben munkaerőhiány van, ez tény. Az IT-sek jól is keresnek az átlaghoz képest, ez is tény.
Majd jön pár fejvadász, akinek az az ötlete támad, hogy na, kopasszuk meg a hülyéket: a fenti két dolgot összekötve hitessük el az emberekkel, hogy 6 hónap és 1 millió forint befizetése után olyan állást kapnak tőlünk, akik menő fejvadászok vagyunk, hogy most akkor hirtelen jólkereső IT mérnök lesz mindenkiből.
És ezt sokan, nagyon sokan beszopják, mert Magyarországon minden get-rich-quick átverést sokan beszopnak.
Nincs itt semmi látnivaló, csak most épp az IT területe lett az átverések alapja, és nem az autóreklám, a vásárlói csoport, a unit linked biztosítási ügynökség, meg más hasonló dolgok.
Azért ezek régebben eléggé jól mentek az USA-ban. Csakhogy kezd megváltozni a piac, itt pont rosszkor vezették be.
+1
bár ez nem csak magyar sajátosság, de szegényebb országokban valóban fogékonyabbak erre.
Nincs munkaerohiany.
30-40 sot ++ jelentkezes van egy lehetosegre.
Strukturalisan van gond, uzemeltetessel, onemanshowbol, mindenbol kicsit de semmibol nem eleget tipus rengeteg van.
Specialista, vagy melyebb ismeretekkel rendelkezo az keves, vagy nincs.
Masik oldal meg nem fogadja a 80% pass embert, mert a tokeletesre varnak.
Sot, megvolt a 101% ember , megis vartak es varattak mert hat lehet jon jobb. ???
3 honap utan akartak ajanlatot adni, ertelemszeruen akkor mar regen mashol volt, egy olyan helyen amire csak 60 legfeljebb 80% pass, de akarata volt es csinalni bizonyitani kivant, ezt ertekeltek es 3 nap utan megvolt a deal.
Sok baj van mindenhol a fejekben...
Communication error. -
Mit mondjak arra, amikor team lead pozicióba jelentkezés után 1 HÓNAPPAL hívnak vissza, hogy köszi, vettük a jelentkezést, mikor jönnél? Ezt így hogy?
Én is a mindenből egy kicsit vagyok. Ez amiatt alakult ki, hogy rákényszerültem erre. Ha arra kényszerültem volna rá, hogy egy dologhoz, de nagyon, akkor úgy alakulok. Vélelmezem ezzel többen így vannak. Azt is vélelmezem, hogy aki erre képes volt az nem rest tanulni emiatt befaragható (ha kedve is van hozzá) bármely speciális fogaskerék helyére. Nekem amúgy nincs kedvem hozzá. A fullstack jó érzéssel tölt, hiszen egy termékhez nem kell más csak egy gép és én.
A lenyeg, nem, hogy reszelni nem akarnak, hanem meg a legtobb esetben a perfect jeloltet is varatjak, n+1 alkalommal ujrahivjak. Aztan megy a csodalkozas, ha beint. Teteje meg az, amikor a huszoneves nagyonhrpuncibrigad ugy valogat, hogy "Ez cuki, ezt hivjuk be!" - True story
Csodalkozo voltam, hogy mennyire imbecil fogalmatlan jeloltek vannak csak, atmentem szetcsaptam a tyukok kozott es megneztem a palyazatokat. Termeszetesen a valamire valok, mer reg odavoltak, lett egy faragvany jelolt.
Szerintem rengeteg helyen van ez igy meg.
ezt nyugtass meg hogy most csak kitaláltad. könyörgöm...
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
hat ha nincs aki a HR-t értékelje :D akkor így járnak.
olyan mint a pénzügy ami magának megfelelően alakítja a céget mert nem kontrollálja őket senki..
"olyan mint a pénzügy ami magának megfelelően alakítja a céget mert nem kontrollálja őket senki.."
Kivéve pár hatóság pl NAV na meg kompletten az egész gazdaság és a tulajdonosok.
csak azt mondom, hogy van olyan cég ahol az excel-tologatók szavára többet adnak mint a mérnökökére :)
> excel-tologatók
Manapság csak óvatosan ezzel itt :)
(hidden subs.)
____________________
echo crash > /dev/kmem
Siman elhiszem. Tolem is kerdeztek mar meg, hogy mikor szulettem, es erdekelte az is, hogy honap eleje vagy vege, mert az masik csillagkep..
A masik az volt, amikor ketten kerdezgettek, egy HR-es csaj, meg egy fejleszto srac (webfejleszto pozi, eleg regen). Egyik (kapcsolodo) kerdesre a valaszom vegen mondtam, hogy nem dolgoztam sysadminkent, de azert a fejlesztoi kornyezet osszeallitasara kepes vagyok, es sztem elvarhato egy fejlesztotol (persze mas beallitasokkal, mint ami prodban lenne). A srac bologat, latszik, hogy egyetertunk ebben. Csaj kerdese: dolgoztam-e mar sysadminkent. Nezek ra, at a sarcra, vissza ra, ujra a fejlesztore, mire o ranez a csajra:
-De hat az elobb epp erre valaszolt!
-Ja..
Neha nagyon nincsenek kepben.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Neha :D
> Magyarországon minden get-rich-quick átverést sokan beszopnak
Mesz te a francba a magyarozasoddal.
Gyulolkodes / magyar utalat nelkul nem lehet?!
jó hogy mondod... ne felejtsük ki a listából az arcoskodást és a felsőbbrendűség képzetet sem :D
Bezzeg londonba. Az az egzisztencia ha tuzfalra nezel a babzsakbol. En speciel buszke vagyok hogy nem a vilag szemetevel kell egyutt elnem..
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
"Az az egzisztencia ha tuzfalra nezel a babzsakbol."
Felvisítottam! :D
--
trey @ gépház
Szerintem itt technikailag nem felsőbbrendűségi képzet történt, hanem az alsóbbrendűség sugallmazása ellen szólalt fel. Persze ettől függetlenül nevetséges, ha valakit ennyi politikai inkorrektséggel már triggerelni lehet.
Bevallom, hogy miota multkor gyakorlatilag le lett retardaltozva a magyar ember, azota picit jobban ugrok az ilyenekre.
(btw regen se birtam a "magyar mentalitasozokat")
Pedig a tobbseget elnezve (ezalatt korbenezve az utcant ertem elosorban, nem politikai alapon!) pont ezzel a kommenttel objektiven nehezen tudnek vitatkozni.
Az, hogy a te szubjektiv, hasrautesszeru iteleted milyen kapcsolatban van a valosaggal, az meg egy masik kerdes.
Legy oly jo, hogy mutatsz egy hivatalos, hiteles statisztikat a valosagrol, ha mar..Raadadul Bp-rol beszelek, ami iszonyatos mertekben pusztul le, ami az embereket illet, messzebb nem is merem elkepzelni mi lehet.
link
Amikor egy olyan statisztika szerint magasabb Magyarorszagon az atlag IQ, mint Norvegiaban, ami PISA teszten alapul..akkor nem merul fel benned a ketely, hogy faszsag az egesz?
PISA eredmenyek:
http://factsmaps.com/pisa-worldwide-ranking-average-score-of-math-scien…
Ezt ugye te sem gondolod komolyan? :D Tassadar kollega mar jelezte, hogy mi a fo oka.
+1
Én flash akartam tanulni
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Anno jo volt. Meg manapsag is azt mondom, hogy jobb mint a HTMLJSCSS web fejlesztes taknyolas.
azt a felhasználói igények tették takonnyá. Villogjon, csússzon, forogjon, aztán 2 megás JS toolpakkokat kell linkelgetni a html-be.
a flash egy gyalázat volt. a legnagyobb baj, hogy csináltál egy komplett tartalmat benne, (weboldal) és nem lehetett belelinkelni. A flash mutatta meg a felhasználóknak hogy lehet csillogó-villogó-bugyuta is a web.
A példaképem:
http://bettermotherfuckingwebsite.com/
Szerintem nem ez a legelszomorítóbb, hanem az, hogy az egyetemről is jönnek ki olyan diákok, akik hasonló vagy akár még rosszabb szintet képviselnek, mint aki egy ilyen gyorstalpalót elvégez.
Szerintem a papír semmit sem ér, ha nincs meg az akarat és a fejlődési vágy valakiben, no és persze a tudás.
Magamból kiindulva: nem fejeztem be az egyetemet, 6 évig rendszergazdaként dolgoztam és saját erőmből eveztem át Java fejlesztőnek, amit már lassan 4 éve csinálok(kiscégnél kezdtem, aztán bekerültem egy nagy céghez, jelenleg külföldön dolgozom). Soha sehol nem ütköztem falakba a diploma hiánya miatt, ha valaki rendelkezik a kellő tudással, akarattal és fejlődési vággyal(az önkritika is nagyon fontos, mert elég sok ember becsapja magát, aztán koppan), akkor bármit elérhet szerintem.
Eddig hat hasonló előképzettségű juniort kellett mentorálmon (4 greenfox, 2 egyéb gyorstalpaló).
Nyilván felvétel előtt meg lettek szanálva, de a hadrafoghatóságuk nem volt szignifikánsan rosszabb mint az egyetemről frissen kikerülteké (ez kicsit elgondolkodtat az egyetemi oktatással kapcsolatban...), sőt, volt pár kiemelkedő is köztük.
Az hozzáállás és elhivatottság szerintem sokkal fontosabb, ebben látok némi problémát az interjú alanynál. A másik probléma - részben a sales miatt - hogy túlzott elvárásokat támasztottak a közeli jövőjükkel kapcsolatban, mert igen, lehet nagyon jól keresni az IT-ban, de az nem ez első pár hónapban fog eljönni.
<3 openSUSE, Ubuntu, KDE <3
Mondjuk tegyük hozzá, hogy a greenfox is jól ment és voltak partnerek, amíg az állam „támogatni” nem kezdett egy másik céget, nincs tandíj stb.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
A GreenFox most is jól megy - bemeneti oldalon. A kimenet a probléma.
Mondanék két dolgot ehhez én is.
Magyarország cégei tele vannak sok éve írt, számtalanszor toldott-foldott szoftverekkel. Ne a kisvállalkozás webáruházára gondolj, ami mögött van egy számlázó meg egy raktárkészletező, hanem 10-20, különböző platformokon futó, különböző programnyelven kódolt szoftverre, amik ráadásul össze-vissza vannak egymásba integrálva. Ehhez nem vesznek fel junior programozót, hanem olyat keresnek, aki kapásból képes legalább a teljes szarkupacnak legalabb a tizedét átlátni.
Az agilis módszertan kezd betörni a nagy cégekhez, ha kell, ha nem. Buzzword a managementnek, akik bár szót sem értenek belőle, csodafegyverként tekintenek rá. Ez leszivárog az egységsugarú HR-es agyába is, aki innentől kezdve nem project managert keres majd, hanem scrum mastert meg stakeholdert, mert ez volt a főnök múlt heti prezentációjában. Röhej, de így van...
De persze csak odalentre szeretnenek agile-t, fenn a magasban minden mukodik ugyanugy tovabb, aztan megy a csodalkozas, hogy nem jott el a kanaan.
Ez a cikk nem az ilyen jellegű képzés haláláról szól, és nem is arról, hogy nem kell a kezdő programozó a piacon. Itt inkább az a baj, hogy az oktatás segítő szakma és a profitmaximalizálás idegen tőle. Ami itt ránézésre megy, azaz hogy, hamis képet festünk, hogy mennél többen befizessék a tandíjat, hogy a piaci igényekhez nem igazodó képzést tartunk, illetve, hogy a profit érdekében megdrágítjuk a pályakezdőink elhelyezkedését. Tipikus kisstílű viselkedés.
Igazán sajnálatos, mert rengeteg olyan szoftveres munka van, amit mérnöki szintű tanulmányok illetve tudás nélkül is prímán el lehet végezni. Sajnos az ilyen kontár és profit hajhász szereplők miatt végül veszít. A cégeknek nem találnak munkaerőt, a váltani kényszerülök/szándékozók ráfáznak, az oktatás szintvonala pedig tovább esik. Szomorú.
Szerintem az esemény is kicsit túlárazott.
Az a baj, hogy valódi juniorokat nem is igazán keresnek, vagy ha igen akkor nem tudom hol. Egy juniornál is elvárás a több év tapasztalat és ha szóba állnak vele akkor is idétlen bugos oldalakon kell feladatokat megoldani amit gép értékel ki és sztem a forráskódra rá sem néznek. Pl az egyik multinál az "akadémiára" jelentkezésnél is elvárás a 3+ év multinál eltöltött gyakorlat. Szóval ha valaki elszúrja az egyetemi gyakornoki helyét akkor esélytelen normális helyre bekerülni nulla tapasztalattal.
Nem marad más, mint nem normális helyre menni. Attól függ persze, hogy mi a normális nálad. A multicég jelenti a szintet?
Nem rólam van szó, de közeli családtag. Egyébként igen egy multi de legalább egy olyan hely ahol fejlődhetne az ember. Félreértés ne essék talált "munkát" ,de nem igazán kapkodnak érte mások. Pedig okos és a nyelvek sem jelentenek számára problémát. Szóval a 20k IT-s hiányzik az lehet, hogy igaz, de nem a kezdő programozókra. Viszont ha nem kell a kezdő akkor honnan lesz senior ?
Kapcsolódó korábbi téma:
https://hup.hu/node/159820
"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."
[Feliratkozás]
"Gyorstalpaló programozóképzés" Hogy mik vannak! Berosálok. A szívem meg szakadjon meg a lusta, semmihez sem értő kis fiszfasz jóskákért, akik a gyors meggazdagodás reményében beiratkoztak az egyik ilyen marhaságra. Indexünk meg lehozza a cikket, hogy jaj de nagy a baj. Hogy venné már meg azt is a Mészáros Lőrinc...
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-
de az, hogy van babzsák meg kávégép, 2019-ben, ez az IT-szektorban alap.
Azért vannak elvárások egy 4 hónapos képzés után. Ilyen hozzáállással és kevés tudással lehet magam sem venném fel a srácot.
Miert? Babzsak csak PhD utan jar? :D
-1
a babzsak* hidegen hagy, de a kave miert akkora elvaras? A hocipo tele van az olyan helyekkel, ahol azt a napi ~100 forint fogyasztast akarja a ceg behajtani rajtam, raadasul ugy, hogy minel bonyolultabb legyen az eletem (tartsak magamnal aprot, rendeljunk kapszulat a kollegakkal kozosen, stb.)
* kiveve, ha a babzsak egy olyan hely metaforaja, ahova felre lehet vonulni par percre az open office husdaralobol, mert akkor igen, legyen babzsak is!
Nálunk ingyen van a kávé. Az átlag dolgozó 3-5 kávészünetet tart egy átlagos napon. A költség nem csak a kávé ára, hanem a kiesett munkaidőé is.
Amugyis kell szunetet tartania, orankent 10-15 percet. Torvenyi eloiras. Akkor is ha nem kavezik, nem cigizik, nem eszik, nem iszik.
Óránként 15 perc szünet? Wtf?
--
ne terelj
Most hirtelen ezt talaltam:http://kamaraonline.hu/cikk/orankent-10-perc-szunet-jar-a-monitor-elott…
Asszem benne volt a munkavedelmi oktatas anyagaban is.
Ugyanebbol a cikkbol:
"Ez azonban hangsúlyozottan nem munkaközi szünet, vagyis nem a munkavégzés megszakítását vagy felfüggesztését jelenti, hanem azt, hogy ebben a ”szünetben” a dolgozó olyan feladatot végez, amihez nem kell a képernyőt néznie, hogy pihenjen a szeme. Például elvégezheti a papír alapú feladatokat, vagy a munkájával összefüggő telefonhívásokat, vagy részt vehet egy megbeszélésen, egyeztetésen a munkatársakkal."
+1
Épp ugyanezt akartam idézni a cikkből.
--
ne terelj
Viszont az operátoroknak nincsen papírmunkájuk, ezért kötelező a széküket elhagyva szünetet tartani. Így aztán a munkaidejük is csökken.
A szoftveres meg nyilvánvalóan folyamatábrát rajzol a papírra a szünetben. ;)
Nem reális, hogy egy it céghez pár percen belül érkezzen be az összes munkavállaló, szóval ha az egység sugarú főnök jól meg akarja akadályozni, hogy a szemét programozója lógjon, akkor mehet egész napos nonstop meeting vetésforgóban, ami rohadt kontraproduktív lesz, persze papíron jól mutat.
Es?
Te tudsz orankent 10 percet meetingelni v kollegakkal egyeztetni ugy, hogy nem nezel monitorra?
Kékgalléros, gyártószalag?
> A költség nem csak a kávé ára, hanem a kiesett munkaidőé is.
Igen, de azt azert nem szamolnam bele, mert a kaveszunet megtartasahoz nem kell kave. :)
Illetve talan az ingyenes kavenal van a legkevesebb kiesett ido - ha mar megy a szorakozas az apropenzzel, vagy ne adj' Isten manualis kavefozessel, akkor meg tobb logas lesz.
szerk: Raadasul ez foleg szalagmunka-jellegu feladatoknal erdekes, en pl. marha sok idot toltok hupon, de ez foleg context switching kozben tortenik, amibol eleg sok van errefele, illetve ha este jut eszembe valami megoldasa, akkor nem varom ki a reggelt, hogy megcsinaljam.
Nagyon sok irodai melónál annyi munka sincs, mint amilyen hosszú a munkaidő. Gyakran nem is lógnak ilyenkor a "lusta köcsögök" a meló elől, csak megpróbálják valahogy eltölteni a kötelező munkaidőt.
Ugye nem az lesz ez után, hogy ezt én mondtam? ("lusta köcsögök")
Értem én, hogy gondod van a világgal, az életeddel és a főnököddel, de hidd el semmi közöm hozzá! Nem ártottam neked.
en csak azt nem ertem, hogy miert kell kocsogoznotok..
:)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Hát, ha aközött kellene választanom, hogy masszív 8 órát végigprogramozzak*, vagy ezt a nyolc órát végigfavágjam egy fejszével... Szerintem a favágást választanám. És nem csak azért, mert segghülye vagyok a programozáshoz, hanem mert kevésbe fárasztó :)
*Tehát úgy tolod megállás nélkül, mint a gép.
--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."
ez az átka a programozósdinak: termelő munkaerő, aki mindig tud még még és még többet termelni amit még még és mégtöbb pénzért el lehet adni.
Ezzel szemben a titkárnő nem tud még még és mégtöbb repjegyet foglalni, a recepciós nem fog tudni még még és még több beténfergőt üdvözölni.
A programozófurgát meg lehet facsarni hogy még még és még több embert eltartson.
Persze ez igy nem teljesen igaz, de mégis.
A kávézás max. akkor kiesett munkaidő, ha valami soron dolgozó munkásokat foglalkoztatsz. Nyilván van egy olyan szintje, amikor sok, de arra normál esetben idő nincs, meeting, jön valaki, skype etc.
Nekem KV+cigi szunetben szoktak jonni a legjobb otleteim, akkor az is kiesett munkaido?
Altalaban vagy valamin gondolkodok, vagy valakit elrangatok egy kis otletelesre, vagy csak a cloud szolgaltato baromsagai miatt felment pulzusomat probalom visszacsokkenteni.
Mindig van jó ötleted eközben vagy csak volt már olyan?
Mérni kellene, hogy ebből következtetést lehessen levonni. Amúgy ha "a" munkát félreteszed és "b"-vel folytatod, akkor is lehet jó ötleted "a"-hoz.
Erre született egy frappáns válasz, még a GMK időkban, amikor a pénz elosztásáról beszéltünk.
A műszerészünk elmondta, hogy ő pontosan meg tudja mondani hány áramkört szerelt meg. Tehát egyértelműen mérhető a teljesítménye.
Ravasz osztályvezetők meg csak ennyit szólt: Einstein egy sajtcetlin vezette le a relativitáselméletet. :-D
Az egyik korábbi főnökömmel volt hasonló vitám. Megkérdeztem, hogy vajon melyik ér többet?
1. Egy nap alatt 1000 kódsor (aminek jelentős része mondjuk az IDE által generált kód)
VAGY
2. Egy nap alatt 10 kódsornyi változtatás, amivel az SQL lekérdezések jelentősen gyorsultak?
Ezután elvetette, hogy kódmennyiség alapján jutalmazzon. :-)
Mondjuk ez eléggé almát a körtével való összehasonlítás. Van, hogy az 1000 kódsor ér többet, mert egy olyan feature, amit el lehet adni - még akkor is, ha nagy része generált boilerplate, de kell, mert nem maszatoljuk össze a rétegeket, stb. És van, hogy a 10 sornyi változtatás, mert a használhatatlan sebességről a használhatóra gyorsítja a rendszert.
+1
Abszolút helyesnek tartom a produktum üzleti szempontok szerint történő megítélését.
Így aztán
- Aki csak 1000 sorban képes megfogalmazni a feladat megoldását, az azonnal repül, mint a papírsárkány.
- A nagyobb kód általában több bugot tartalmaz.
- A nagyobb kód hoszabb ideig fut.
- A fentiek alapján sokkal költségesebb is lesz, mert
-- a későbbiekben nehezebben karbantartható,
-- ha másnak kell belenyúlni, akkor az elvárt munka többszörösét kell belefektetni.
Szóval a 10 sor változtatásra sem lesz szükség a gyorsításhoz, mert a lassú kód el sem fog készülni. ;)
"- A nagyobb kód hoszabb ideig fut."
Ez hülyeség. Egy quicksort például jóval gyorsabb, mint egy bubblesort, mégis több sor megfogalmazni. A futásidőnek sok köze nincs ahhoz, hogy hány utasításból áll egy kód önmagában - a ciklusok meg a rekurzió miatt.
+1
Bár a quicksortnál lényegesen nagyobb feladatra gondoltam.
Vagy sokkal kisebbre.
Ha már találkoztál ilyennel, no meg igazi fatökű programozóval, akkor gondolkozz el rajta!
A quicksort megfogalmazása egyébkét lényegesen rövidebb: qsort()
Bár a rosseb se használja mert q(sort) lassú. ;)
Hát nem tudom. Ha mondjuk választani kellene egy gazdag funkcionalitású, de lassú rendszer VAGY egy kevesebb funkcionalitású, de lényegesen gyorsabb (10-20x) rendszer között, akkor inkább az utóbbi mellett tenném le a voksomat.
Szóval hiába tudod eladni az 1000 soros feature-t, ha az része lesz egy keretrendszernek, ahova kellene az a 10 soros gyorsítás.
Szerintem ez meg egy hülye és alaptalan általánosítás, hogy 1000 sor rossz, 10 sor jó. Mi az az 1000 sor és mi az a 10 sor? Mitől lenne valami gyorsabb attól, hogy valami 1000 sor vagy 10 sor? Főleg, honnan jön a 10-20x-os különbség?
Dobálóztok itt LOC-kal a levegőbe bármiféle alap nélkül.
Ha a saleseseknek egy 1000 soros, összehányt lassú php script-sql query kupac kell, ami 10 perc alatt felnyalja az adatbázis felét és kiköp belőle egy Excel táblát, ami megspórol nekik négy órányi kattintgatást, ERP-ben való lekérdezkedést, excel bűvészkedést rendezkedést, formázgatást, stb, akkor az éves szinten 800 munkaóra spórolás 8 óra időbefektetéssel. Ha ugyanezen az 1000 soron te 8 óra időbefektetéssel 10 sor módosítással azt éred el, hogy nem 10, hanem 1 perc alatt generálja le, az lehet, hogy technikailag szép húzás, csak üzleti szempontból nem feltétlen ad további értéket hozzá, hiszen a generálás történhet óránként háttérben. Ergo, van 8 óra kidobott mérnökórád, aminek üzleti haszna 0.
Igen, sebesség, erőforrások okos használata érték. De ha a vevőnek pont egy feature hiányzik, mert üzletileg az ad neki értéket, akkor az a prioritás. Előző munkahelyemről rengeteg olyan dolgot tudnék mondani, ami "good enough"-ra lett csak megírva. Lehetett volna gyorsítani rajta, mondjuk 2-5x-ös időbefektetéssel, karbantarthatóság drasztikus romlásával. Csak épp igény nem volt rá, mert úgy is elég gyors volt, cserébe jobban hiányzott az, hogy legyen még X meg Y meg Z funkció, ami pénzt hozott.
Azokat a gazdaságtan nevű dolgokat nem viccből tanítják egyetemen mérnökszakon.
+100
Ain`t nobody got time for that :D
Pont ez a szemlélet hiányzik a legtöbb fejlesztőből, főleg az egyetemről frissen kiesettekből. Programozásból beléjük verik, hogy hogyan optimalizáljanak, talán még a jegyük is attól függ, közgázt végig amóbázzák, és dedikált tárgy hiányában esélyük sincs maguktól rájönni ezekre az összefüggésekre.
Meg azt nem tanítják, hogy a szar kód karbantartása drágább, mint egyszer jól megírni.
Mert Mancika 3 nappal korábban kapja meg az excel táblás baromságát, utána az összes frissítést 3-5 nappal később, rosszabb minőségben, legvégül meg úgyis elölről újraírják az egészet.
A Nokia ebbe bukott ugye bele, mindenáron a Symbiant tolták. Miközben Android alatt 10 nap megírni valamit, Symbian alatt ugyanezt 50. Nem lehet versenyezni szar termékekkel, ha a szomszéd 1000 Ft-ért termeli az almát, én meg 5000-ért, meg fogok bukni. Közgazdaságtan.
Ez az első, amit meg kell tanulni, hogy karbantartható kódot kell írni, közgazdaságilag az kifizetődő.
És miből gondolod, hogy mindig a több kód a szar? :) Spagetti kódból sokszor kevesebből is megvan egy feature, mint a rendesen rétegezett kódból, patternek betartásával, stb.
Nem mindig rosszabb a nagyobb kód. Kétféle idiotizmus van:
- olvashatatlan szuperoptimális kódot írni: *(***ptr++)=(*(double **)ptr + 9), de láttam már java osztályt dinamikusan generálni teljesen feleslegesen, mert generics-sel is működött volna. Kicsit elszállt a szerzője a kódnak.
- vagy ismételten feltalálni a kereket (láttam a shift operátort exp+log függvényekből újraírni, indiai kód), nem hittük el, hogy 1 soros programot 100 sorból írtak meg
Az érthető kód csak azt tartalmazza, ami szükséges, ha pedig valami baromságnak tűnő dolgot csinál, azt megmagyarázza. Néha kell kretén dolgokat csinálni, hogy kompatibilis maradj másik kretén rendszerrel. Ilyenkor jó a komment, hogy miért csinálod a logikátlan vadbaromságot.
Nem mindig, de copy-paste-tel exponencialisan novekszik a code base, igy a tobb kod egy smell szokott lenni.
Kérdés ugye, hogy ki a vevő? :-)
Mert lehet, hogy egy cégvezetőnek csili-vili feature mondjuk egy 3D-s UI, miközben ugyanazon cég dolgozói szívnak a gyakran használt, ám de lassú lekéréssekkel, kimutatásokkal.
Éppen ezért cégen belül valamivel könnyebb "eladni" egy ilyen gyorsításos dolgot, mint egy külső ügyfélnek.
Valamennyire a témába vág: Is it worth the time?
Rohadt kenyelmetlen babzsakban dolgozni.
Babzsakon is kenyelmetlen de babzsakban az mar szerintem szivatas :D
Félreérted. Ez a kukoricára térdepeltetés IT-s megfelelője.
Ha menő a cég, akkor kiönti térdeplés előtt.
A szegényebb cégek meg spórolnak a babbal, ezért kell a zsákban tartózkodni.
Nem kukorica, inkább Java fejlesztésnek tűnik ;-)
Innováció is van azèrt, mert haladni kell a korral.
Ma már legóra kell térdepelni...
- - - - - - - - - - -
"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol
+1
--
"Sose a gép a hülye."
83 vagy 84-ben vette fater a C64-et otthonra. Kemény 3-4 éves voltam. Onnantól kezdve eldőlt, hogy ilyennel fogok foglalkozni, gyakorlatilag a mindennapjaimba beivíódott a gép, gépezés már 10 éves korom előtt. 4 hónapos progrmaozóképzés? Istenem borogass.
10 évesen az első C64 programomat a kézikönyvből pötyögtem be karácsonykor, miután megkaptam a C64-et, de nem írtam be hogy RUN- mert azt az előző lapon írták a könyven, hogy kell (és én első megközelítésben nem sorrendben olvastam a könyvet) :). Várakozás - várakozás - gép újraindít.
Kb 1 napra rá rájöttem, hogy működik az IF és a FOR, és megállapítottam, hogy mindent meg tudok már csinálni, tudok programozni :) Mennyire nem így volt. Majd iszonyat mennyiségű gép nyüstölés, Peter Norton Assembly könyv, meg utána még egy csomó könyv, Watcom C, stb... utility-k programok, játékok írása, vírusok debugolása (mennyire más volt az), stb... 18 évesen teljesen más jellegű tudásom volt, mint a kollégáimnak, ahova mentem dolgozni, nem tudtam jól SQL-ezni, zöldfülű voltam a legtöbb dologban, 0 hálózati ismeretek, de pl sokkal több alap megvolt mint jópár embernek. Ez marad ki a 4 hónapos tanfolyam alatt. + talán az, hogy az ember egyedül hogyan keressen meg, dolgozzon fel információkat, anélkül, hogy valaki elmagyarázná a témát, és az orra elé nyomná, hogy ezt kell megtanulni..
Alapvetően amiben azok az emberek előrébb vannak, akik gyerekként kezdték, az az, hogy jobban állnak a problémához hozzá, nem futamodnak meg előle...
Teljesen más világ volt a Commodore világ. Nem arról szólt az IT tudás, hogy letöltöd a SUPERGAME.EXE-t, megnyomod a Next, Next, Next-et, utána lefuttatod a CRACKIT.EXE-t és már játszol is. Nagyon sokan "számítógépes szakértőnek" gondolják magukat a fenti tudással.
A Commodore újságnak volt egy színvonala, ami a Next, Next, Next-en túlmutatott (akkortájt LOAD + RUN).
Manapság mintha nem lenne erre igény. Pedig nem muszáj programozni, lehetne például SVG vektorgrafikus rajzolásról cikkezni, 3D felületrajzolás, CAD programok használata, weblap készítés, de még az Arduino-zás is beleférne. Ezer érdekes dolog van a világban.
Chip magazint utoljára 20 éve vettem. Annyira visszataszító az egész kialakítása, hogy hanyagolom. Gagyi sok pénzért.
Akit érdekel a retro téma, javaslom Stöki és Grath Checkpoint podcastját. Nemrég volt több adás, amikor a Guru történetén mentek végig, és ott pl. volt szó érintőlegesen a Chipről és a többi Vogeles lapról is.
Vagy ha kicsit össze szeretnéd piszkolni a kezedet, ajánlom Ben Eater legújabb sorozatát, ami 6502 egy modern változatára épül. Lehet kit-et is rendelni és otthon tovább hackelni. Meg persze a többi videója is nagyon jó, példáúl a hogyan működik egy vga kártya (prof of concept-et rak össze), vagy egy 8-bites gépet a 0-ról.
https://www.youtube.com/watch?v=LnzuMJLZRdU
Wow! 2004-ben újragyártották kicsit modernebbül, 970 kHz helyett 14 MHz-ig húzható órajellel?
http://datasheets.chipdb.org/Western%20Design/W65C02S.pdf
Azért nosztalgia részeként mindig megmosolygom az eredeti proci 2..7 órajel/8 bites utasítás "hatékonyságát".
offtopic*
Hahh.. Nosztalgia. Nem kevés éjszakám ment rá arra hogy a Commodore újságokból, vagy a Mikro*-ból kódokat gépeljek be :)
+ az már megint meredek, hogy az MTV-n ugye akkor volt egy ilyen "IT" műsor, ahol sugároztak programkódot, amit ha felvettél a magnón, akkor megjött a progi tádám :)
http://www.sinclair.hu/szoftver_programsugarzas.php <- egy kis nosztalgia :) Bár lehet megkoptak az emlékek, de mintha ez ment volna TV műsorok után is.
*offtopic :)
Nem fejlesztokent dolgozom, de azert szkriptelni mindenhol kell. Neha megdobbent, hogy hanyan vannak olyanok IT-ben, es akiknek a ciklus, valtozo, esetleg a parancssor fogalma homalyosan sincs meg.
Mint peldad is mutatja, egesz mas a hozzaallasa az embernek, aki google/stackexchange nelkul, kodokat kezzel bepotyogve kiserletezett evekig, sajat erobol.
Az en C64 palyafutasomnak a csucsa az volt, amikor megjelent a programom a Commodore ujsagban. A kodot kinyomtatni nem tudtam (nyomtatorol csak konyvekben olvastam, kozelrol nem lattam egyet se), szoval a kodot ugy kuldtem be, hogy egy szazeves mechanikus irogepen beirtam. Nullaknal backspacszel vissza, majd perjellel athuzva, ahogy kell.
Commodore ujsag a hoskor. Azert az vagany lehetett, oda bekerulni :) Respect.
A scripteles szukseget is osztom (/me uzemeltet), csillio dolgot es favago munkat lehet vele automatizalni.
____________________
echo crash > /dev/kmem
Szerintem egy második, harmadik nyelvnek, sok is az a 4 hónap. :-D
Esetleg lehet arról szó, h ez a Greenfox "elfelejtette" leadni a védelmi pénzt az Indexnek?
Ne adjatok fel!
Mikor 20 éve gyerekként elkezdtem tanulni programozni, csak a saját szórakoztatásomra csináltam. Akkor még nem tudtam hogy ezért fizetnek is. :-O
+1
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-
Én már anno kétkedve fogadtam a mindenkiből programozó képzéseket. Kevés olyan ember van, aki más szakmában dolgozik és mégis van érzéke a programozáshoz. Ahogy rohan manapság az IT, nincs a cégeknek ideje mentorálni a nagyon juniorokat.
Az meg, hogy hamarosan nem lesz szükség a programozókra, röhej.
-----------
Akkor beszélsz igazán jól angolul, ha egy angol viccen őszintén tudsz nevetni
Csak hogy tisztán lássunk: Semmilyen szakmát nem lehet megtanulni 4-6 hónap alatt. IT-t meg főleg nem. Akik ilyenekre jelentkeznek, buták, tudatlanok és naívak.
--
"Sose a gép a hülye."
És/vagy át vannak b****a.
Főleg ez
Szerintem vannak páran akik jól járnak ezzel. Még a programozó tápláléklánc alján is jobban járhatnak, mint ahonnan jöttek. Lehet, hogy ők tehetségesek, vagy volt előismeretük, de akkor is vannak. Csak hát a többiek meg nem...
a probléma az arányokkal van: ezek nélkül a lehúzó helyek nélkül is megoldották az átképzést akik akarták-tudtak. Cserébe most van egy csomó ember akik bevállalták a jobb jövő reményében ezt, simán lehet, hogy nem is tetszik nekik stb, cserébe helyzetbe hozták & lekötötték magukat: végeredményben rosszabb helyzetben vannak mint amiből indultak és még időt&pénzt is elégettek valamire...
Ebben te biztos vagy?
Ott voltak vannak az OKJ-s képzések. Azok jobbak?
Nem az a változás, hogy megnőtt a választék. Elvileg ezek a lehúzós helyek, komolyabb előszűrést alkalmaznak azaz nem vesznek fel bárkit?
Aki alkalmatlan az elvileg kisebb eséllyel kerül be, bár ugye hazudni és csalni nem csak Oktatási hely tud hanem a jelölt is.
"Ott voltak vannak az OKJ-s képzések. Azok jobbak?"
Iskolája és tanárja válogatja, de amit én látok, általában igen.
--
"Sose a gép a hülye."
+1
Hogyan nevezzük azokat, akik a jót ingyen helyett, a drágán szart választják?
felsővezető
Aki az ingyenes és jó OKJ, helyett a drága szart?
Nem ez volt a kérdés :)
Hanem amire válaszoltam.
a saját "képzés"-üket felértékelik egy adott összegre amit a diák miután végzett valamilyen formában visszafizet nekik. Ennek a módja már teljesen mindegy a lényeg, hogy le van kötve feléjük:
- akár randomcégen keresztüli munkával ami révén ugyanolyan helyzet alakul ki mint bármelyik fejvadász cégnél, csak itt az "üf". nem mondhatja, hogy elmegy a konkurenciához, mert csak azokhoz mehetne akiket ők kijelölnek
- fizesse ki $ -ben stb.
a lényeg akkor is az, hogy keletkezik egy tartozása aminek a mértéke annyi amennyit a "képzés"-t szervező cég megálmodik..
pl egy OKJ ezzel szemben -minőségétől függetlenül- bizonyos feltételek mellett -eddig- /akár/ ingyen volt.
Engem személy szerint az is zavar, hogy emberek ilyen sanyarú helyzetbe kerülnek, de az sokkal inkább, hogy ezek olyanok nagyrészt akik változtatni szeretnének az életükön, tenni is készek érte csak épp a végeredmény lesz problémás.
Sokkal jobban járnak, ha egy cég belső képzési programjába bekerülnek, ott legalább van esélyük olyasmit tanulni amit -legalább- azon az 1 db helyen használni is tudnak..
"Elvileg ezek a lehúzós helyek, komolyabb előszűrést alkalmaznak azaz nem vesznek fel bárkit?"
Miért is tennének ilyesmit? Ők minél több embert akarnak minél rövidebb idő alatt átpörgetni, ezzel maximalizálva a profitot.
Szűrni?? maximum azt, hogy ért-e már valamihez mert akkor esetleg "képző"-t faragnak belőle :) ; beveszik a buliba.
Persze akik kellően jól csinálják még azt is elhitetik az embereikkel, hogy segítenek másokon.. (ami az esetek nagyon pici részében még igaz is lehetne..)
Igen senki nem kényszerítette a tanulókat erre. Önként vállalták. Mindig olvasd el az apró betűtűs részeket. Lekötés nem hiszem, hogy baj lenne, ha valóban azt tennék amit "ígérnek", a piaci igényre képeznének. (kiszervezett belső képzés, ez esetben a munkaadó fizetné)
OKJ ellenben kb felvesznek bárkit. "/akár/ ingyen volt" az állam ha jól tudom 2db OKJ papírt áll, az sincs ingyen, mi fizetjük.
Igazi mutató az, hogy OKJ után mennyien maradnak a "szakmában", és ezek után a képzések után mennyien.
Elején még a reklám arról szol előszűrnek (pl. elvárták a jó angol tudást), fogalmam sincs valóban szűrnek e. Angolul az OKJ képzésen se hiszem, hogy megtanul bárki, összehasonlítási alap az esti OKJ.
Cég belső képzési programjában jellemzően a cég alkalmazottai vesznek részt. Ígéret arról szolt, tulajdonképpen kiszervezett belső képzéseket valósítanak meg. Ők rugalmasak a keresletre képeznek. Hogy ebből mennyi az igaz, az egy jó kérdés.
Legfontosabb miért volt/van könnyű dolguk, az állami szakmai képzések híre nem a legjobb (villanyszerelő, autószerelő). Inkább ezen kellene változtatni. Akkor ezek a cégek maguktól eltűnnének.
"a lényeg akkor is az, hogy keletkezik egy tartozása aminek a mértéke annyi amennyit a "képzés"-t szervező cég megálmodik.."
Ezt nem hinném, utólag elég gáz lenne változtatni.
"Engem személy szerint az is zavar, hogy emberek ilyen sanyarú helyzetbe kerülnek, de az sokkal inkább, hogy ezek olyanok nagyrészt akik változtatni szeretnének az életükön, tenni is készek érte csak épp a végeredmény lesz problémás."
Ez engem is zavar. Itt pl. állami feladatott látnék, ellenőrizze a cégeket, szedesse le a hamis ígéreteket, csak azokat a cégeket sorolhassa fel amelyekkel valós napi kapcsolata van. (mintha azzal is szívatnák a népet, hogy nem csak a valós napi partnereket sorolják fel)
"Miért is tennének ilyesmit?" Mert a piacra képeznek analfabéta szíjgyártó nyergesből nem tud "programozót" képezni.
Ezzel különböztetvén meg magukat az OKJ rendszertől, csak azokat vesszük fel akiknek van esélye, és nem mindenkit aki beesik az utcáról.
Ez az index-es cikk elég rossz reklám volt nekik.
Kapcsolódó index cikk "Próbált mostanában Magyarországon programozót találni?"
"4.5 hónap alatt képzünk akár targoncakezelőből olyan programozót aki régebbi stílusú játékprogramokat meg tud írni" LOL
Amikor normális állami egyetemen tanultam programozni, ahova csak érettségivel lehet beesni - ez ugye targoncavezetéshez nem kötelező - és inkább a jobb tanulók próbáltak arrafelé szerencsét, második év végére kellett ilyen játékot írnunk. Addig az elég keményen nyomatott matek és prog tárgyak kiirtották a társaság úgy 70%-át. Valószínűleg nem azonos szintű, tudású programozók kerülnek ki egy nagybetűs Egyetemről mint az ilyen zöld rókás tanfolyamokról.
Mostanra a multik is rájöttek, hogy nem ugyanazt a programozót kapják egy foxi-maxi műintézménytől mint mondjuk a BME-től?!
Micsoda brékingnyúz!
Naná, hogy szenzációhajház index cikket kell írni erről.
Engem is kiirtottak anno egyetemrol matekkal. Most itt ulok Kaliforniaban a Szilicium volgyben egy nagy IT ceg fohadiszallasan mint senior/lead devops. Es kurva sok ilyen ismerosom van akiket kiirtottak hasonlokeppen es most nagyon jo pozicioban levo nagyon komoly IT-s arcok. Azthiszem ez sokat elarul a magyar egyetemek ertekerol, meg arrol hogy onnan aki kikerul attol nagyon nem kell hasra esni, siman lehet hozni a tudast es az eredmenyt a nagybetus egyetem papirja nelkul is, ha megfelelo a hozzaallasa valakinek.
En biztos nem az alapjan itelnek meg valakit hogy BME-rol jott vagy foxi-maxi-tol. Aki igy tesz azt meg nagy ivben el kell kerulni mert valoszinuleg papirfetisiszta aki lenezi azokat akiknek nincsen. Halistennek mostanra nem a munkaadok diktalnak a piacon, ugyhogy valoszinuleg nem problema normalis helyet talalni. A hulye HR-es mancikakat akik csak a papirt nezi meg le kell szarni :)
Helyesbítelek: a MAGYAR felsőoktatásból.
A rohadt sok matek nem a magyar felsőoktatás különleges jellemzője.
de a szarul oktatása igen :(
Ezt miből szűrted le?
Szinte mindenhol heti szintű gyakorlat van, rendes feladat megoldással, külföldön ez nem alapértelmezett, simán létezik csak előadás kurzus is. Konkrétan nekünk első évben villanyon fél tankörös bontásban volt (ma is úgy van), 15 fős csoportokban. Ettől jobbat mit vársz el?
Rossz módszerrel adják le az elméletet, majd tisztelet a kivételnek, doktoranduszok megúszós gyakorlatot tartanak gépies feladatmegoldással. Ez az írás egész jól elmagyarázza a problémát: https://www.uni-muenster.de/Physik.TP/~munsteg/arnold.html
Jártam BME műinfóra és ELTE fizikára is. Előbbin vért hugyoztam a matekból, utóbbin úgy adták le a matekot, hogy újra gimiben éreztem magam. Nem azért, mert könnyebb volt (sőt), hanem mert egyből megértettem órán, hogy miről beszél a tanár.
+sok sok
Életemben csak programozással foglalkoztam, és a két legjobb programozó, akivel találkoztam, diploma nélküli srác volt.
Sz.rtak bele, hogy megcsinálják az egyetemet, nagyon sokat gyakoroltak, maguktól oldottak meg sok-sok éles programozási feladatot, interneten utánaolvastak stb
Ahol most dolgozom, nyüzsögnek a PhD-sok (matek, fizika, közgazdaságtan).
A fejlesztők már fogják a fejüket, amikor azt mondják nekik, hogy "itt van ez a kész program, amit egy PhD-s kollega írt, de nem szép, nem karbantartható és g.ci lassú. Valódi programot kéne belőle csinálni."
Ilyenkor 99%ban a teljes eldobás és újraírás a jó megoldás, mert vállalhatatlan nulla, amit letettek az asztalra.
Szóval a papír, vagy akárcsak az IQ semmit sem mond valakinek a programozói képességeiről.
Igazából ez készségszakma.
Ugyanúgy, mint egy szakmáját nem szerető asztalos is "elboldogul" az életében, de amit csinál, az nem lesz igazából jó, csak a kötelező minimumot hozza.
Jól értem, hogy ti PhD-st használtok kódernek? Nah az tuti epic fail, arról az apróságról nem is beszélve, hogy az a világ legnagyobb pazarlása. Bár az is tény, hogy valószínű hamarabb lesznek képesek normális prod. kódot csinálni. Csak az a probléma, hogy ők nem erre valók. Ők meg tudnak oldani olyan problémát, amit a kóder nem és maximum egy prototípust érdemes tőlük várni korrekt leírással. Aztán abból megírják a rendes prod. kódot a kóderek akik erre vannak kiképezve. Ez kb olyan mint mondjuk egy autótervező mérnököt odaállítasz, hogy javítsa meg az autót. Kicsit több idő ráfordítással nem teljesen résmentesen képes megcsinálni, de azért azt érezzük, hogy erre a feladatra inkább egy autószerelőt kérsz meg. Míg az autószerelő sosem tudná megtervezni az autót. Mindenkit arra kell használni, amire való.
Nem egészen értek egyet.
Bonyolultabb problémánál igenis elvárás, hogy egy deszkamodellt, prototípust a PhD-s kollega rakjon össze, pl azért, mert több módszert, képletet, algoritmust kell összeépítenie, hogy az elvárt eredményt kapja.
Nem célszerű, ha azt iteráljuk sokszor, hogy 1) research ad egy képletet 2) fejlesztő lefejleszti 3) research ellenőrzni, nem elég jó, ad egy újabb képletet
De ha már megvan a jó képlet, akkor miért kellene újat adni? Pont arra van a research, hogy keresse meg a lehetőségekhez mérten a legjobbat. Ha már a sok prototípus közül megvan a jó, akkor már elég abból az egyből terméket építeni.
Azért kell, hogy a PhD-s is elkészítse a prototípúst, szimulációt...stb. Mert azon már előzetesen ki lehet próbálni dolgokat. Az elcseszés akkor van, amikor ezt Java-ban kell mondjuk írnia, nem valami olyan nyelven amit megszokott és pont az ő gondolkodását segíti, ami jobban passzol az absztrakt problémához. Ne kelljen neki lemenni odaáig, hogy még Java-ban és szép legyen a kód, és igazából az a pár ember meg is csinálta a projektet. Az majd a fejlesztő urak problémája lesz, rendelkezésükre fog állni a prototípus, szimuláció, dokumentáció, meg mindig kérdezhetnek, de a fejlesztők azok akik a termék elkészítésében jók.
Ugyanarról beszélünk. Én ezzel az állítással vitatkoztam: "3) research ellenőrzni, nem elég jó, ad egy újabb képletet".
Hát ez bizony kőkeményen előfordul pl pénzügyi területen, hogy próbálgatni kell, szimulálni, iterálni, hogy kiderüljön, az elképzelt modell működik-e a valóságban.
A papír, ceruza manapság alkalmazott kutatásban nem elég, prototípus kell.
Az viszont nem szoftvertermék, az másik szakma.
Ahogy mondod, a papír ceruza kombó csak a folyamat első lépése, ami mára már kevés, az alapján a protótípust is meg kell alkotni.
Ezt akartam mondani. A PhD-s kollega adjon egy prototipust, amit lehessen tesztelni. Én azt gondolom, hogy viszont ezt el kell választani a majdani kész terméktől. Itt láttam már olyan gyakorlatot, hogy vanalmi másik nyelven írja meg, ami jobban támogatja az ő matematikai gondolkozását, itt a nagy kedvencemet megemlíthetem a Juliat, de a scientific python is ilyen, meg van még pár. Ezeknek az a jellemzője, hogy sokkal produktívabban lehet benne megoldani problémákat, valamint általában eléggé könnyű tiszta kódot írni. Valamint a tőbbiek oldaláról sem úgy csapódik le a dolog, hogy újra kell melóznom, miért nem csinálta meg, mert másik nyelven van eleve megírva.
+1. Nálunk is ez van. Vannak matekosok, akik foglalkoznak a rendszerben a mindenféle solverrel, meg vannak a szoftverfejlesztők, devopsok, stb., akik köréjük rakják a minden egyebet. Volt egy kolléga is, aki nem is kifejezetten azért volt, hogy productionba fejlesszen, hanem K+F jelleggel oldjon meg problémákat. Aztán vagy lett belőle olyan kód, ami fel lett használva, vagy kiderült, hogy az adott feladat úgy nem megoldható, vagy valakinek utána abból kellett készítenie egy terméket.
Még mindig jobban megérte egy gyorsan összerántott PoC alapján elkészíteni egy rendes production szintű kódot, mint azzal traktálni a matematikust, hogy unit és integrációs teszteket faragjon, cserébe kevesebb dolgot tudjon megvizsgálni.
Mondjuk ez management szempontból is érdekes kérdés, mert ez a PhD-s megjelenik a fejlesztésben létezett régebben is, de mostanában kezd el széleskörűvé válni. Ennek az integrálása a workflow-ba felvet pár eléggé érdekes kérdést, hogy senki ne kapjon idegbajt. :). Én úgy gondolom, hogy a senior fejlesztők is két csoportba fognak oszlani. Az egyik csoport az amelyik érti a matekot és nagyon jól együtt tud majd dolgozni a PhD-sal és a project azon részét tudja kezelni, míg lesznek azok akik nem értik, jellemzően a selfmade coderek, azok meg a project többi részét fogják vinni. Egyik sem előrébbvaló a másiknál. Majd kiváncsi leszek az új buzzword-ökre ezzel kapcsolatban :D
Nem lesz buzzword, egyszeruen inflalodik a papir. Bizonyos multiknal, ahol tuljelentkezes van, manapsag siman beirjak a rank & file koder allashirdetesbe, hogy compsci MSc required, PhD preferred. Hogy minek, azt ok sem tudjak, mar azt leszamitva, hogy igy ezer CV helyett csak szazat kell atnezniuk.
IT területén nem jellemző a túljelentkezés.
Olyasmi fordulhat elő, hogy idáig vagonokat lapátolt, de megvilágosodik, hogy IT szakember lesz, ezért jelentkezik erre a pozícióra. A HR kiszűri automatikusan, hogy ne kelljen az interjúztatókat feleslegesen megterhelni.
El sem jut az önéletrajza az érintett osztályra.
Nah azokkat még nem láttam. Olyat már igen, hogy olyan pozihoz, ahol kellett a matek, ott beirták, hogy: minimum Master, PhD preferred, de hogy ezt sima kódernél beírják az furcsa. Én olyat tudnék elképzelni, hogy required Master és strong mathematical skills, mint kóder a ki PhD-sokkal együtt dolgozik. De persze láttunk már cifra dolgokat, pl 3 éves tapasztalat Swift-ben és a programozási nyelv még csak fél éves, szóval persze teljesen símán lehetnek ilyenek is. :D
Milliókat kereshetnek Berlinben magyar programozók: ez az abszolút csúcs
Almodni sok mindenrol lehet, a realitas viszont meg mindig az, hogy 5 honap alatt senkibo nem lesz programozo, plane nem millios fizetessel.
Jó hát ezt egy programozóiskola írta, fenntartásokkal kell kezelni. Inkább arra jó, hogy megmutassa a magyar vs. külföldi fizetések közti szakadékot.
Erre inkabb ezt a ket oldalt ajanlanam [1], [2]. Az elson megnezed mennyit keresnel kint, a masodikon megnezed mennyit er kint a penzed. Persze ezeket is fenntartasokkal kell kezelni, de egy reklamnal azert jobb kepet ad.
1. https://www.glassdoor.com/Salaries/index.htm?countryRedirect=true
2. https://www.numbeo.com/cost-of-living/comparison.jsp
Ma interjúztattam valakit, hát sajnos 6 év alatt se. :(
Örök junior? Találkoztam olyannal, akinek 20 év sem volt elég...
uh
Egyik ismerősöm elvégzett egy ilyen gyorstalpaló programozó tanfolyamot. Előtte üzemeltetőként dolgozott, de programozói tudása nem volt. Szinte azonnal kapott is munkát a tanfolyam elvégzése után, Budapesten PHP programozóként nettó 240.000 Ft / hó bérért.
Innentől kezdve már van egy papírja, hogy elvégzett egy tanfolyamot, továbbá meg tudja szerezni a szakmai tapasztalatot, ezután már csak rajta múlik, hogy önképzéssel hová jut el.
Szerintem ennél többet nem is lehet várni egy ilyen gyorstalpaló tanfolyamtól: alapokat megadja, elhelyezkedést biztosít egy cégnél, utána már a diákon múlik a többi.
Par ev es meglesz a 20 eves targoncas fiu fizuja. Hajra.
echo crash > /dev/kmem
Nem itt akar maradni hosszú távon, és nem is PHP-t akar programozni, hanem keresettebb nyelven, legelső pozíciónak szerintem jó. Nulla szakmai tapasztalattal adott szakterületen még nem lehet válogatni. Meg ugye vegyük figyelembe, hogy a cégnek ki kell csengetnie a jutalékot az iskola felé, mert az iskola által helyezkedett el, ez csökkenti a fizetést.
Csakhogy tegyük hozzá, hogy többség inkább tapasztalt embert keres, ha vált, akkor könnyen besorolják ismét a junior kategóriába és ugyanott lesz.
Vagy ugyanott se, mert megszokta, hogy senior PHP-skent minden nap steakezik es televasarolt egy 3 szobas lakast amibol ket szoba mar raktar.
Aztan az ilyen ember nem megy el feleannyiert masik nyelv juniorjanak. Meg akkor se, ha azota mar utalja a PHP-t.
Jaja, az ember konnyen megtalalja a legrovidebb utat a kiegeshez. :)
Szerintem ez probléma.
Egy senior fejlesztő nem a nullára fog indulni ha egy másik nyelve vált. Hacsak nem valami nagy ugrást csinálsz (webfejlesztés -> hardverprogramozás), de még ott is a már megszerzett tapasztalat és tudás egy része tud hasznosulni. Ha pedig átmész PHP-ről Node-t fejleszteni, akkor ez az egy rész elég nagy, amit illene méltányolni, és nem ugyanoda kategorizálni, mint aki frissen jött az egyetemről.
Ennyire jól keresnek a targoncások? Egyébként az nem lehet, hogy nem is akart targoncázni, és nem mindegy neki mit dolgozik, esetleg szeret programozni? 240 az nem rossz kezdés pályakezdőként, abban a szakmában ahol van azért lehetőség előre lépni.
Ha nem válaszolnék kommentben, hát küldj privátot!
Ez a targoncavezető dolog már többször előjött ebben a topikban, lehet átképzem magam targoncásnak :)
az út másik oldalán van a gyakorlati képzés meg a vizsga. Mindig pittyegenk ha emelnek vagy tolatnak - tököm tudja - nyáron nyitott ablaknál megőrülök tőlük.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Ha nem pittyegne akkor meg azon menne a sírás, hogy miért csapott el.
Kb. két hétig tart a képzés, utána hivatalos papírokkal mehetnek is munkát vállalni. Viszont több műszakos munkarendben kell dolgozni, nagyon monoton a munka és a pakolandó árukon túl vigyázni kell a jómunkásemberekre is.
„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”
"Az Antikrisztus ledarálja Mészáros Lőrincet."
Plázában bolti eladó nettó bére kb. 200 nettó. Szerintem nem kéne, hogy kezdő programozó nettó 300-350 alatt keressen.
szerintem egy kezdő programozó kevesebbet tud nyújtani a szakmájában, mint egy pláza alkalmazott az első 6 hónapban. Utána nyílván a plázaeladóból max csopvez lesz, a programozó meg egész életében fejlődhet tovább ÈS magasabb szinten tudja támogatni a cégét több pénzért.
"Szerintem nem kéne, hogy kezdő programozó nettó 300-350 alatt keressen."
Sztem meg annyit fog keresni, amennyit ajánlanak neki és vagy elfogadja vagy nem.
Nincs a piacon bértábla - egy kezdő programozó egy majd évig még a jobbak is NEM termeli ki a fizetésüket..
WOKEBUSTERS
https://www.cpachungary.com/wokebusters
A bolti eladoi melo sokkal nehezebb, mint segget mereszteni egy irodaban.
Ha a munka nehézsége lenne a mérvadó, akkor nem a vezetők keresnék a milliókat, hanem a talicskázó szakmunkások.
Igen, eég jól keresnek a targoncások. Igazán jót nettó 400 alatt nem találsz.
Ha azt nézzük, hogy 12 éve kezdtem 1200/ó nettóért (~201e teljes hónapra bár részmunkaidőben voltam.), ami ma inflációval számolva olyan 280-300e nettó, akkor de, elég rossz.
De még a cégnek ki kellett fizetnie a jutalékot is a képző iskola felé, azért az sokat le tud vonni a fizetésből.
Ott is volt a diákmunkás cég felé jutalék.
https://www.origo.hu/gazdasag/20200204-lidl-idei-beremeles.html
Hu, de sok hozzaszolas, vegig se olvastam, de az feljott, hogy egyreszt vannak ezek a szar gyorstalpalok, masreszt meg vannak az egyetemek, ahol halal elavult tudast tanitanak, meg papiron programozast, es igazabol egyik se alkalmas lofaszra se, ha az egyenben nincs meg a belso motor, ami hajtsa? (Es ha megvan benne, akkor meg tokmindegy, hogy honnan jott, mert ugyis felveszi a kulonbseget?)
Amugy a legnagyobb ostobasag barmilyen ceg reszerol az alapjan venni fel barkit is, hogy mihez ert, aki hosszutavra tervez, az az alapjan keressen, hogy mire van meg a jeloltben a potencial, es nevelje ki.
"aki hosszutavra tervez, az az alapjan keressen, hogy mire van meg a jeloltben a potencial, es nevelje ki"
Mert az alkalmazottak azok aztan ugy szeretnek hosszu tavra tervezni. Nagy fluktuacio koraban sokszor luxus a "kineveles". Par hetes tanitas belefer a legtobb ceg profitabilis terveibe, de minden mas penzkidobas legtobbszor.
Nagyon ritka az az ember tipus, akirol mar felvetelkor lehet tudni, hogy a "sokaig tervezek itt" nem ures igeret lesz.
Egy nalam rosszindulatubb kommentelo megjegyezhetne, hogyvisszanyalt a fagyi. :)Haverom 4-5 evet huzott le egy cegnel ugy, hogy 0 forint fizetesemelest kapott ezalatt, viszont acafeteria nettoja csokkent par szazalekot. Nem ertette a foni, hogy miert valt 5 ev utan. Szerintem maig sem erti. :D
Mondjuk olyat is láttam, hogy valakinek kellett valami munka pár hónapig, ameddig nem talál egy "normálisabbat".
Gondolom nem kell mondanom, hogy mekkora károkat tud okozni az ilyen ember, ha kellőképpen beképzelt és masszívan szarokbele hozzáállással fossa telibe mindazt, ami már ott kialakult.
A probaido oda-vissza letezik, es a ceg is vizsgazik. Ha nem sikerult megfogni az alkalmazottat valami miatt, akkor valtani fog. (ahogy a ceg is lecsereli, ha nem jott be)
A strange game. The only winning move is not to play. How about a nice game of chess?
Próbaidőn túl maradt. Ha jól emlékszem 1 hónap volt, kb. 3-4 hónapot volt.
Meg a legbizalmibb backend, big data es devops poziciokban sem ciki 2 ev utan valtani. Ahol masfel ev alatt nem kerult szoba a fizetesemeles gondolata sem, ott nem erzik az alkalmazottat potolhatatlannak, akkor sem, ha amugy az. Onnan menni kell.
En azokrol beszelek, akik 5 honap utan lelepnek. Bizalmi allasra jelentkezve az hatrany, frontendesnek, designernek konnyebben elnezheto.
Pont ez a nehéz a dologban: meglátni 1-2 interjú alapján hogy valaki tipikus alkalmazott vagy sem (és érdemes beletenni az energiát).
Erre jó lehet a személyes ismeretség/referencia.
Gábriel Ákos
nem véltelenül olyan elterjedtek a továbbajánlásos rendszerek itthon is :).
Nem mindig jó ez szerintem, éppen arra való a felvételi, ha tényleg jó a felvételiztető, hogy eldöntse mennyire alkalmas a pozícióra, mennyire fog beletenni anyai apait. Ha felveszik és elmegy fél év múlva az szerintem az interjúztató sara.
Más részről anno emlékszem amikor állást kerestem mondjuk az több mint 10 éve volt, azért nem vettek fel rengeteg helyre mivel nincsen tapasztalatom. Az az érdekes ahol most dolgozom oda először valami mondvacsinálta indokkal nem vettek fel, majd egy alcéghez felvettek ami fuzionált a jelenlegi céggel és én vagyok az egyik legjobb dolgozó a statisztikák szerint.....
Ez egy eleg erdekes hozzaallas, mert nekem pl. egy cegben ha elszegodok, ez egy akkora red flag, hogy sanszosan meg se varnam a probaido veget.
A nagy fluktuacio altalaban azert van ssc-knel, mert rossz a menedzsment, rossz az engineering, es mindenki csak a 'getting shit done' mentalitast tolja, ami nyilvan nem okoz oromet, es jutalmazast senkinek.
En pl. az az ember vagyok, aki szivfajdalom nelkul felallok barhonnan 5-6 honap alatt, ha olyan a ceg, hogy csak egy eldobhato eszkozkent kezel, es boldogan maradok evekig, ha a cegnek van annyi esze, hogy engedjen dolgozni a legjobb kepessegem szerint.
Ha valakit felveteliztetek, akkor ugyanezt az embert keresem, mert ilyenekkel lehet megcsinalni dolgokat.
(Szerintem)
Ha van a CV-dben 1, vagy 5+ ev tapasztalat eseten 2 olyan ceg, ahol ott maradtal evekre, akkor oke felallni probaidoben.
De backendeskent es devops-kent nem szep, ha ugy tunik, hogy commitment issue-id vannak. Felallni szar cegtol nem commitment issue, ha fel tudsz mutatni jot is a history-dban.
(Frontendeskent es designerkent mindegy, mert az nem bizalmi allas)
Mondjuk ez igaz. Nekem ilyen minimum 3 de inkabb 5 eves munkahelyeim vannak, es nehany olyan, ahonnan felalltam par honap utan.
Az teljesen jo. Volt, ami megfelelt neked es te is megfeleltel nekik, es ez a legfontosabb. Innentol senkinek nem tartozol magyarazattal, hogy miert alltal fel a tobbitol. Vegkepp nem erdekel senkit egy hianyszakmaban.
Hogy akarsz jó frontendet csinálni, ha nem érted az üzleti folyamatot, ahova UI-t kell neked varázsolni?
Teljesen jogos amit írsz. A munkahelyed se fogja megvárni a próbaidő végét, ha neki valami nem tetszik. Szerencsések vagyunk, hogy a szakmában van akkora mozgási lehetőség, hogy ha szükséges az ember tud új helyet keresni, és nem kell a megélhetésedet féltve bejárni valahova dolgozni, ahol nem érzed jól magad.
A ló másik oldala viszont az, hogy egyeseknek semmi se jó, és az első probléma, nehézség után lécelnek le, mert úgyis van jobb. Csak hát a kerítés sehol sincs kolbászból, és erre majd biztos rájönnek, csak közben pár cég és munkatárs idejét rabolják feleslegesen vele...
lazán kapcsolódik: Lambda School’s Misleading Promises
tl;dr: az usákoknál sem nagyon működik a dolog és mennek a ferdítések.
Kapcsolódó: Egy halom pénzt toltak a Logiscoolba