Van arany középút? Autodidakta tanulás.

Van arany középút? Autodidakta tanulás.
2021-10-04T21:45:23+02:00
2021-10-08T15:44:41+02:00
2022-10-17T07:41:56+02:00
  • Ez pl azert problematikus, mert akkor nekunk az o design-ja szerint meg van hatarozva, hogy milyen technologiat hasznaljunk es nem tudjuk kicserelni a Hazelcast-ot egyeb distributed cache-re.

    Csak úgy zárójelben :) Én megéltem pár ilyen cserét egy korábbi projectben. GemFire -> Infinispan -> Hazelcast. Nem a terv implementálása, de éles rendszerben tapasztaltak miatt. Bár mindhárom distributed cache (is), vannak azért eltérések közöttük. Az IS -> HZ váltás akkor konkrétan egy prod issue miatt történt, ahol az IS egy split healing után szépen az új állapotot dobta el, és a régit használta merge után. És ebbe nem is volt beleszólásod kódból, míg a HZ már akkor is támogatta az entry szintű custom merge policyt a gyáriak mellett, amivel ezt ki tudtuk volna védeni. Aznap nem volt jó napja az operátoroknak és az on-call embereknek :) És ezután az eset után nem is merték tovább HA-ban futtatni az adott komponenst, csak cold backupként tudták felhúzni a másik lábat adatbázisból (mi programból garantáltuk az adatbázis és a cache konzisztenciáját, amennyiben a perzisztens réteg előtti queue szépen le lett drainelve). Szóval valóban, egy architekturális pattern/építőkocka konkrét implementációját azon a szinten érdemes kikötni, ahol az PoC-olva lett, nem feljebb.
    Mutasd a teljes hozzászólást!
  • Igen, úgy látom, te még abban a fázisban vagy, hogy "ki akarod tanulni" a szakmát oly' módon, hogy minden, ami létezik a szakmában, arról tudj elég sokat, hogy az önbizalmad meglegyen. De ez nem fog menni. Alapok kellenek, jó erősek. Az adja meg a megfelelő önbizalmat. Vannak olyan cégek, ahol ez alapján szűrnek, nem pedig azzal, hogy milyen mennyiségű lexikális tudásod van mondjuk React-ből.
    Mutasd a teljes hozzászólást!
  • Számomra ezek inkább a parasztvakítás kategória... boccs... arra szolgálnak, hogy a cégek hízelegjenek a munkatársaknak, esetleg a fizu papíron is legyen különbség valami miatt

    Szerintem van olyan hely ahol, ahol tenyleg ezek szerint zajlik a kifizetes. 
    De szervezetfuggo a dolog. Pl nalunk van olyan architect akitol ugymond a 'megrendeles' jon, egy affele high level design ha ugy tetszik. O nem kozvetlenul dolgozik a csapatunkban es nem diktalhatja, hogy milyen technologiat hasznalunk.
    Itt mar sok politika van. Pl egyszer veletlenul elkottyintottam, hogy Hazelcast-ban miket csinalunk, es legkozelebb bekerult az o design dokumentaciojaba, hogy mi mit fogunk Hazelcast-ban tarolni. Ez pl azert problematikus, mert akkor nekunk az o design-ja szerint meg van hatarozva, hogy milyen technologiat hasznaljunk es nem tudjuk kicserelni a Hazelcast-ot egyeb distributed cache-re. Ha pedig lecserelem es kiderul es hiba van, akkor biztosan ez okozza...ugyhogy hetekig ment itt is a vita, hogy vegye ki a design-jabol, hogy mit-miben tarolunk.
    Tehat az o szintjen max annyi jelenhet meg, hogy pl 2 rendszer kozt milyen protokol lesz hasznalva, milyen adatok lesznek atkuldve, de hogy mi mindezt javaban implementaljuk es azon belul is melyik http klienst hasznaljuk, es kozben hogyan lokogetjuk ide-oda az adatokat, edes mindegy kellene, hogy legyen.
    Aztan van a csapatnak sajat architect-je, o is dobozokat huzgal, de ez mar low level, itt mar megjelennek technologiak, hogyan map-elunk, transzformalunk, hibakezelunk, logolas hogyan lesz, redelivery, stb. Vele egyutt dontjuk el, hogy milyen technologiai megoldasokat fogunk hasznalni. O csak akkor kodol ha kell, ertsd, alapbol nem kodol, de tud kodolni is, ha pl lebetegszik hirtelen 5 ember. De o megy 'vitazni' az egyeb architect-ekkel, miutan megegyeztek es ertheto a feladat, o akkor kezd dolgozni. 
    Aztan pl en sokszor POC-ken szoktam dolgozni a csapat architectjenek design-ja alapjan es ha mukodik, akkor az alapjan szoktam csinalni egy alap framework-ot, a fejlesztok pedig ebbe tetszik be a modulokat. Itt is felmerulhet a kerdes, hogy erre miert van szukseg: pl azert, hogy a fejlesztok ugy tudjanak fejleszteni, hogy ha veletlenul valtoztatnank egy technologian, akkor ugy lehessen kicserelni, hogy a fejlesztoknek fel se tunjon, hogy CXF helyett valami mas hivja meg a web service-eket. 
    Aztan felmerulhet a kerdes, hogy erre miert van szukseg, egyertelmu, hogy igy fejlesztunk, nem? Sajnos nem minden fejlesztonek, sokan csak osszedobalnak mindent 'es mehet', legalabbis nalunk, igy erre is szukseg van
    Mutasd a teljes hozzászólást!
  • Nekem is inkább az a tapasztalat, hogy a senior az inkább egyféle technikai mindentudó, mintsem hozzáállás, meg egyéb szakmai profizmus lenne. Ha mondjuk valaki eddig C++ DirectX, meg némi Qt app fejlesztésben járatos és hozzávágnak egy .NET microservice feladatot, hogy akkor ezt holnap reggelre meg kéne oldani, akkor a senior valószínűleg azt mondja, hogy oké, érdekes a feladat, de jelenlegi tudással ez nem lesz meg holnapra kéne még pár nap felkészülni, mert van pár technikai részlet, fogalom, ami hiányzik. Erre a munkáltató nem azt fogja válaszolni, hogy végre egy profi, aki nem kezd el vakon gányolni, inkább megmondja a tényeket, hanem akkor a jelenkező nem is senior, mert annak mindent is tudnia kéne.
    Mutasd a teljes hozzászólást!
  • biztos, hogy nem szeretnék nálatok dolgozni

    Nem véletlen mondanak fel nálunk a kollégák egymás után...
    Mutasd a teljes hozzászólást!
  • Igen világos számomra is, hogy élő élményeket írtál és sajnálom, mert a többi részletet amit megosztottál biztos, hogy nem szeretnék nálatok dolgozni .
    Ettől még lehet jó ugró deszka, mert neves cég a szakmában, tényleg kurrens dolgokat, kellő mélységben tanulhatsz. De, ezt magadnak kell látni, mikor jön el az idő, hogy pl. ne csak technológiát akarj tanulni / látni, hanem módszertant - esetleg teljesen más iparágat, más problémákat. Ne adj Isten más kultúrkör cégét... gondolok itt pl. arra, hogy nagyon másképp működik egy német cég egy angolhoz vagy amerikaihoz képest... a skandináv meg egy megint más világ. A tapasztalat szerzés - szeniorodás - ezt is kell jelentse. Pl. hányféle emberrel kell dolgozzak együtt, melyikkel, hogy kell hangot találni. De fontos, pl. hogy akár napi szinten használj kommunikációra angolt/németet/... 
    Tied a világ, jó szakmád van hozzá!
    Mutasd a teljes hozzászólást!
  • Számomra ezek inkább a parasztvakítás kategória

    Egyetértek, de sajnos ez létező dolog, és nagyon sok cég él is ezzel a rendszerrel, és meg is lépik a lefokozást (alacsonyabb fizetést), ha nincs készre szerelt tudásod, hiába van tapasztalatod azon a területen. Csak ezért említettem meg, illetve azért, mert én a munkahelyemen ilyen rendszer van.
    Mutasd a teljes hozzászólást!
  • Boccs Lilla, nekem már keveredik az elmúlt napok két topikja... így lehet a másikban került elő... nem is ekézésből írom.
    Egyrészt 5 év az már pont az amikor egész jó rálátásod van a szakmára, de még nem is mondható, hogy beleragadtál volna egy skatulyába... mint pl a backend.
    Tök igazad van abban, hogy sem nem lehet érteni mindenhez és minden ágat egyformán jól ismerni. Persze később rájöhetsz, hogy a legtöbb ág összefügg és akárhány nyelv + keretrendszer, nincs új a nap alatt, sémák vannak amiket itt másképp neveznek mint amott. Ezért pl. egy gyakorlott .NET-es sokkal hamarabb tud átnyergelni Java + spring-re, mivel ott is ugyazokat a problémákat oldják meg. De még azt sem lehet mondani, hogy az egyik vagy másik kifejezettebben jobban való lenne pl. backend fejlesztésre.
    Sőt egy JS tipusú rendszerben is hamarabb boldogulnál mint aki most kezdi a szakmát, pont a berögzült sémák miatt. (Mondjuk pont javasolnám, hogy ne tekintsd black-box-nak a keretrendszert, az a jó tovább fejlődési irány ha nem elhiszed amit igér, hanem tudod mit csinál belül).
    Az is igaz lehet, ha hazabeszélhetek, hogy .net-ből/java-ból mondjuk egy c/c++ világ jóval nehezebb mint fordítva, viszont pont az alapok azok, ti. így működik a számítógép fontosak bármilyen környezetben is fejleszt az ember, egyszerűen könnyebben átlátja a működését.

    Viszon amiben kötözködnék, ahogy már megtettem máshol is, ezek a titulusok!!!???
    Junior dev, senior dev, Junior architect, senior solution architect??? Mik ezek?
    Számomra ezek inkább a parasztvakítás kategória... boccs... arra szolgálnak, hogy a cégek hízelegjenek a munkatársaknak, esetleg a fizu papíron is legyen különbség valami miatt. De szerintem nem attól senior xyz architect valaki, mert mondjuk .NET-ben össze tud rakni egy microservice-t megfelelő security setuppal és CI/CD-t mögé tud rakni. Sokkal inkább az a tapasztalat ami segít neki, hogy adaptáljon megoldási sémákat problémákra, adott nyelven vagy nyelv/környezet függetlenül, de tudja, hogy egy problémára milyen környezet, milyen séma ad olcsóbb és hosszabb távon fenntartható megoldást. Ez persze más megközelítés, de pont az ellentetje annak a mondásnak, hogy akinek kalapácsa van mindent szögnek néz. 
    Sajnos olyan is van aki bár a titulust birtokolja, mégsincs se annyi ismerete, se előérzete, hogy pl adott technológiának milyen hátrányai fognak előjönni adott probléma megoldásakor... csak megy a divattal. Ilyenkor jót mosolygok, mikor kipattannak a semmiből pl serverless architecture, meg minden cloud-ba és microservice-be kell költözzön... anélkül, hogy megvizsgálta volna a megoldandó problémát. 
    És aki senior is, attól is az, hogy a saját korlátait is ismeri, és nem próbál csakazért is okosnak lenni ha tudja, hogy adott témához fogalmatlan... ahelyett, hogy esetleg nekiáll tanulni arra felé is...
    Mutasd a teljes hozzászólást!
  • Én nem tudok okosat mondani a témában, csak azt tudom megosztani veletek, hogy én hogyan gondolkodom a saját szakmai fejlődésemről.

    Végső soron a programozás is egy szakma, amit azért tanulunk, mert szeretjük csinálni, és mert pénzt akarunk keresni vele. Utóbbin van első sorban a hangsúly, amiből véleményem szerint következik az is, hogy mindenkinél van egy szint, ahol azt mondhatja, hogy "nekem az a szint, amit eddig elértem, az elég", és nem szeretne mélyebben belefolyni a dolgok működésébe. Tehát ha te a saját megélhetésedet és életszínvonaladat biztosítani tudod azzal, hogy össze tudsz rakni egy weblapot a megrendelőnek PHP-ban, akkor elég, ha ennek az iránynak a változásait figyelemmel tartod, hogy ne ess ki a versenyből.

    Mivel az informatika egy nagyon-nagyon hatalmas szakma rengeteg ággal, amelynek a programozás bár csak egy kis szelete, de még az is nagyon nagy ága, gyakorlatilag képtelenség mindenhez mélyen érteni. Csak hogy egy párat megemlítsek, lehetsz:
    - desktop alkalmazásfejlesztő
    - mobil fejlesztő
    - web frontend fejlesztő
    - backend fejlesztő
    - fejleszthetsz AI technológiákat
    - IoT eszközökre és mikrokontrollerekre írhatsz vezérlést
    meg sok mást csinálhatsz, ami most nem jut eszembe.

    Minden területnek persze megvannak a saját módszerei és technológiái. Én a backend fejlesztés csínját-bínját kezdtem el megismerni, .NET környezetben. Ma már nem tartom magammal szemben jogos elvárásnak azt, hogy olyan mélyrehatóan ismerjem például a mai modern .NET MAUI-s cross-platform fejlesztés módszereit, mint amilyen "mélyrehatóan" a backend fejlesztés módszereit ismerem. Egyrészt azért, mert a munkahelyemen nem elvárás mindennapi szinten, a szabadidőmben pedig már nincs annyi motivációm fejleszteni magam, mint ahogy általános/középiskolás diákként, egyetemistaként volt. A backenden kívül sok más területen vannak szétszórt ismereteim, de ha megkeresnének egy ReactJS frontend állásajánlattal, valószínűleg újra junior lennék, tapasztalat és ismeret híján. Sőt, fel sem vennének.

    És az, hogy mélyebben ismerem a backend fejlesztési területet, nem jelenti azt, hogy ott is agyon tudnék optimalizálni bármit, vagy hogy ne tekintenék black boxként a framework-re. De legyünk már egy kicsit reálisak, még csak most lesz 5 éve, hogy főállásban dolgozom programozóként, vagy most már junior architectként. Nincs mögöttem annyi év tapasztalata, mint azon kollégáimnak van, akik évtizedek óta a szakmában dolgoznak, és mondjuk senior solutions architect szerepkört töltenek be.

    Óh, és a tech stack csodái... Hiába ismerem a backend fejlesztést úgy-ahogy, illetve hiába tudom azt, hogy milyen problémákat oldanak meg, illetve mire számíthatok egy MVC, ORM, serialization, message queue stb. framework-öktől, hogyha eddig .NET-es voltam és a következő munkahelyemen mondjuk Java-t és Spring-et fogunk használni. Lehet, hogy az interjún átmegyek valamilyen csoda folytán anélkül, hogy a javás tech stacket ismerném, de mivel nincs készre szerelt tudásom, már a béralkudozásban is alulról fogok indulni annak ellenére, hogy 5 éve vagyok backend dev.

    Röviden azt gondolom, hogy a kulcs a specializáció egy adott szakterületen. Persze feltételezem azt, hogy olyan munkahelyen dolgozol, ahol a minőség fontosabb a mennyiségnél, és a munkahely megköveteli tőled azt, hogy minél jobb legyél, és ehhez van is olyan kollégád, akitől lehet tanulni. A többihez pedig van elég anyag a neten, hogyha alkalomadtán szükséged van rá, gyorsan össze tudj rakni valamit.
    Mutasd a teljes hozzászólást!
  • A programozók mai helyzete sokkal jobb, mint az 1980-as években felnövőké volt. Ma már elég egy olcsó, használt számítógép, egy Linux CD, valamint internetkapcsolat, és máris mindened megvan a munkához és ahhoz, hogy magas szintre fejleszd programozói tudásodat.
    Mutasd a teljes hozzászólást!
  • Javaslom, hogy törekedj a lehető leghatékonyabb módszerre.

    1. Ha sok matekot kívánó dolgokat fejlesztesz, akkor jóformán lehetetlen otthonról felszedni a szükséges tudást. Nem mintha nem lehetne az MIT OCW oldalon akár egy teljesen computer science szakot elvégezni, vagy bármilyen matematikai szakkönyvet beszerezni a netről -- de otthon egyszerűen nem fogod megtanulni. Annyira összetett / bonyolult, hogy elveszíted a motivációdat. Így ilyen esetben marad az egyetem. (Pl. data science: most még sok az önképzett kókler a piacon, de ezek hamarosan ki fognak kopni, amikor a munkaerőpiac felzárkózik képzett munkaerővel az igényekhez.)

    2. Matematikát nem igénylő, "sima" szoftverfejlesztéshez felesleges újabb egyetemre járni, ahogyan az előttem szóló írta: YouTube, Udemy + könyvek. Van pár klasszikus könyv a kód rendszerezésről, ezekből pár magyarul is megjelent (Martin Fowler: Refactoring, Robert C. Martin: Clean Code stb.). A többihez pedig választasz egy technológiát, befizeted magad pár ötcsillagos Udemy kurzusra amikor éppen $10-os diszkont van, a témákhoz letöltesz pár jobb könyvet és ezeket végigrágod. A többi meg otthoni és munkahelyi gyakorlás.
    Mutasd a teljes hozzászólást!
  • Udemy! Azt akartam írni természetesen. Bocs.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy van arany középút, csak mindenkinek magának kell megkeresnie és végigjárnia.
    Az, hogy hol kezdődik és merre kanyarog, pár dologtól függ.
    A képességektől és a lehetőségektől, na meg a szerencsétől is.
    Azt gondolom van pár legfontosabb dolog amire szüksége van közben az embernek.
    Úgy mint; gondolkodásmód (elemzési, tervezési, logikai és alkalmazási képességek), tanulás + kitartás, affinitás mindezekhe és a fejlesztéshez, pénz + szerencse.
    No meg, kitartó gyakorlás. Felsőoktatásban sok mindent megtanítanak és sok mindent nem. Persze intézménye/tanára válogatja melyik tananyag melyik kategóriába fog esni. Nem lehet hagyatkozni csak az iskolában tanult dolgokra. Szükség van önképzésre is és ezen keresztül tapasztalatszerzésre.
    Nem biztos, hogy van értelme tovább fejtegetni. Nem tudom ki mennyire ért egyet azzal amit írtam.
    Ezek csak az én tapasztalataim, gondolataim. Az utolsó mondataimból talán látszik, hogy az önmagunkban való kételkedésrre is szükség lehet. Persze másokban lehet, sőt kell kételkedni.
    Ez amolyan szkeptikus irányvonal, arra viszont nagyon jó, hogy aa kételkedés miatt az adott dolgokat az ember megpróbálja átgondolni és kideríteni, vajon lehet-e valamit jobban megcsinálni. Nem biztos, hogy lehet, viszont cserébe kapott az ember egy jól kielemzett látképet arról amivel foglalkozik. Ez a fejlesztőknél időnként piszok jól jön.
    Mutasd a teljes hozzászólást!
  • De, hogy legyen válasz az eredeti kérdésre is.
    Szerintem megéri bele vágnod ha tényleg érdekel és úgy érzed van hozzá érzéked.
    Ne a cég kedvéért persze, de tekintsd egy jó terepnek ahol kipróbálhatod a tanultakat, kb ingyen motiváció viszonylagos felelősség nélkül. Ha meg már jól megy akkor simán lépj tovább, komolyabb helyre ahol ez már elvárás is. Akár juniornak persze.

    Nem is kell több milliós suli. Kezd az newman ...max pár 10euro -os anyagokat told végig...kezdésnek .net-c# vonalon.
    Mutasd a teljes hozzászólást!
  • Szerintem ugyanazt akarjuk mondani.

    Persze, hogy baj ez, persze, hogy az oktatás hiánya. 

    De ez azért tudott kialakulni mert nincs kényszer. SW és HW oldal is kompenzálni tudja a szakmai hiányosságokat. A fejleszteok (nagyrésze) meg azt hiszi, az a programozás, hogy megtanul egy ide-t, keretrendszert, lib gyüjteményt használni.
    Mutasd a teljes hozzászólást!
  • Nem tudok evvel egyetérteni. Szerintem a szemlélet helyére nyugodtan helyettesíts oktatást. Ha ott el van nagyolva (pl. egy 4 hónapos gyorstalpalón) akkor ez szemléletté alakul és igen ezek a "szakemberek" nem is tudják, hogy lehetne másképpen is.
    Ez a betanított munka szinonimája nálam, ezúton is elnézést kérve azoktól akiket sért, de tények makacs dolgok. Ettől még láthatóan kellenek az ilyen tipusú tudással rendelkezők a szakmába, keresik, sőt megfizetik őket is. A gond ott kezdődik, hogy tovább képzés és tapasztalat nélkül lépnek feljebb...
    Mutasd a teljes hozzászólást!
  • Nézd nem gondolom ez elavult szemlélet. Az idő az idő akkor is ha pár perc a veszteség akkor is ha ember évnyi fejlesztési költség lesz a vége. 
    Én is dolgoztam 128k-s mikro kontrollerre, ott sem mindegy, hogy akár egy rendszerszintű architekturális döntés hogyan befolyásolja a megvalósíthatóságot alacsony szinten.
    De volt olyan is amikor csak 1 mp volt a túl hosszú idő a felhasználó szempontjából, egy kép nagyítás volt elrontva, hál Istennek 1 sor cseréjével 10x lett a gyorsulás, mivel a korábbi szerző felcserélte a sorokat az oszlopokkal feldolgozás közben. Ehhet persze kellenek némi alapismeretek, de még nem atomfizika azért.

    Úgyhogy az ár mindig magas, max nem látszik tisztán, mivel senki nem jár utána.
    Mutasd a teljes hozzászólást!
  • "ez a szemlélet, a megoldja a vas és a framework"

    Ez nem szemlélet, hanem kialkúlt helyzet.
    Nem így állnak neki, csak mivel senki nem mondja nekik, hogy egy  1000 ember adatának nem kell 4GB, azt gondolják, hogy ez így normális. 

    Szóval amit akartam, hogy nem ök gondolják, hogy megoldja a vas, hanem mivel a megrendelonek sem drága ezért nem reklamál. Es ezert kb minden szoftver rosszabb mint régen.

    Hozzászoktunk a sz4rhoz.
    Mutasd a teljes hozzászólást!
  • valós példa mikor az apache poi-val generált xls 15.000 sornál megevett 2GB RAM-ot... sebaj lenyomjuk 8-ra

    Bizony, én is erről beszélek. Az alapszakmám elektronikai műszerész. Egyszer egy végtelenül egyszerű készüléket terveztem és építettem. Mikrokontroller volt a lelke. Ott nem beszélhetünk memória és CPU bőségről. A vezérlőprogramot megírtam először uBasicben, működött. Aztán megírtam assemblyben is. Ugyanúgy működött, viszont a mérete töredéke volt a uBasicből fordított programénak. Tehát amikor ma a keretrendszerek mindenhatóságáról hallok, azért ez eszembe jut. A gyorsaságnak és egyszerűségnek is ára van. Csak ez az ár ma nem annyira magas.
    Mutasd a teljes hozzászólást!
  • Mert megoldja a keret rendszer, a fejlett programozási nyelvek, az órajel és a memória mérhetetlensége.

    És ezek szerinted maguktól nőnek ki a földből, ha kellően gondozzák őket? Tévedsz!

    Egy szakmailag képzett programozó, akinek ez a napi munkája, aki ebből él, az ismeri az algoritmusokat, ismeri a hozzá tartozó matematikát, és képes olyan absztrakciós tudásra, amellyel mindezt egy programozási nyelv segítségével képes számítógépen modellezni, megírni. Nyilván az, hogy ki milyen területeken dolgozik, olyan algoritmusokra van szüksége, azokat ismeri, de a matematikai képzettség elengedhetetlen. Ez az a tudás, amit egy felsőoktatási intézmény adni tud, és amin el lehet indulni.
    Azok, akik manapság teljesen autodidakta módon tanultak meg programozni, nem jártak ilyen irányú közép- / felsőoktatási intézménybe, ennek ellenére fejlesztésből élnek, azok főleg többségében a webes / desktop alkalmazások világában dolgoznak, ügyviteli szoftverek valamilyen területén. Itt a hétköznapokban valóban nem szükség az erős matematikai - algoritmizálás tudás, néha kell, de nem általános, így az ilyen területen van létjogosultsága a matematikai alapok nélküli szoftverfejlesztés aspektusának. De azért nyilván, nem csak ebből áll a szakma.
    Ebből a szemszögből vizsgálva a kérdést, a keretrendszereket megírják a "komoly" programozók, a többiek pedig ezt csak használják, és elfogadják. De számukra a keretrendszer egy fekete doboz, nem is érdekli az, hogy hogyan működik, csak alkalmazkodnak hozzá, elfogadják a kereteket, az előnyöket, és a hátrányokat. Ez is egy megoldás, de szerintem a többség számára nem járható út.
    Mutasd a teljes hozzászólást!
  • Hát erre is van válasz... mégpedig a nagyok nem engedik a közelébe a kicsiket. Egyszerű piac, a nagyok elszívják a kicsik elöl a levegőt. Őket arra tartják, hogy max a nagyok beszállítói legyenek, ha már nagyon muszáj. Így működnek a nagyobb body lease cégek is, hiába tudnál te referenciával megtámogatott ajánlatot adni, ők már előre lezsírozták a beszállítói csatornákat. Ebbe belesimulsz és lenyeled, hogy kb munka és valódi felelősség nélkül lefölözzék a haszon egy részét. Na de nincs új a nap alatt...
    Mutasd a teljes hozzászólást!
  • Jajj... boccs, én elég régi módi vagyok ezek szerint, de ilyenek hallatán sikítófrászt kapok.
    Sajnos - ez a szemlélet, a megoldja a vas és a framework. És hány projekt bukik meg vagy lesz egy kupac ... mert nem volt értelem a probléma feltárására és ment a tákolás.
    Persze a time-to-market nagy úr, de mindenki nézzen magába hány olyan projektet látott amit fele-harmad annyi valódi szaki röhögve elvitt volna sokkal messzebbre mint a fel stuffolt ész nélkül összerakott csapatok. 
    Igen a csapatot építeni kell, megfelelően összeválogatni az embereket, felépíteni, kinevelni a juniorokat. De amikor a csapból is az informatikus hiány folyik... bármit is jelentsen ez a valóságban, hiányszakma művelőjeként tekintenek az emberre és inkább felvesznek szinte bárkit... sok multinál megy ez sajnos (és persze van ahol nem, de oda bekerülni is elég nehéz már).

    De én ahol lehet küzdök ez ellen a szemlélet ellen, hogy valós példa mikor az apache poi-val generált xls 15.000 sornál megevett 2GB RAM-ot... sebaj lenyomjuk 8-ra ...
    És mikor megkérdeztem, mégis mi  franc eszik 150kB-t rekordonként csak vonogatták a java-sok a válukat. Gondoltam megkérdezem azt is, hogy ha az adott instance-n a jvm-t felnyomjuk 8GB-re, mit fog csinálni a többi process (klasszik monolit alkalmazás volt btw). 

    Itt viszont nagyon könnyen szétszakad majd a szakma... vagy már szét is szakadt és áthidalhatatlan szakadék lesz a kb betanított munkás szintjén dolgozó fejlesztők közt és a ...nevezzük... mérnök fejlesztők közt akik értik mi is történik ha egy adott kódsort végrehajt a gép. 
    Jó ez, nem tudom... de pár hónapja volt egy riogatós cikk itt miszerint az AI majd elveszi a fejlesztők munkáját... ja csak nem mindegy ki munkáját.
    Mutasd a teljes hozzászólást!
  • Mert megoldja a keret rendszer, a fejlett programozási nyelvek, az órajel és a memória mérhetetlensége, és a github

    Na de a bőség zavara az, ami teljes káoszhoz vezet. Egyetértek azzal, hogy szilárd alapok kellenek, hogy meg tudd ítélni, helyes-e az amit ott írnak.
    Ezzel a "megoldja a keretrendszer" dologgal egyébként szintén ráfáztam. Lásd a DB2-ről szóló írásomat. A code-first elv oda vezetett, hogy a finomhangolás elmaradása hatalmas kárt okozott majdnem.
    A vitaindító WPF témakörben (is) egyébként sokszor egymásnak ellentmondó megoldásokat lehet látni. Az egyik youtuber így, a másik úgy. Van aki esküszik a WYSIWYG megközelítésre, van aki inkább írja a kódot. Hozzám az utóbbi áll közelebb. Persze ez a nehezebb út.

    Saját tapasztalat: az egyik alkalmazásom használatba vétele után érzékeltük, hogy bizonyos esetben rettentően fogy a memória. Na de mit számít? Van elég. Azért csak bosszantott. Átírtam. Felületileg semmi változás. Mégis sokkal kevesebb erőforrással megy, közelebb van a nagykönyvhöz. Mert megértettem a probléma okát, így tudtam, hova nyúljak.
    Mutasd a teljes hozzászólást!
  • HIdd el tökéletesen értem. Látom én is a saját korlátaimat, pont bizonyos felsőbb matematikai alapok hiányában. Tehát egy AI szakértői munka, komolyabb grafikai implementáció amikhez jócskán kéne tanulni... és igen csak hobbiból elég nehéz időt szánni rá. Nekem is legtöbbször kell valami projekt vagy cél ami miatt nekiállok. Nyílván régebben ez könnyebben ment... akár munka időben, családosan pedig nehezebb. De nem adtam fel, hogy újra beiratkozok valamilyen képzésre pl. Ebben az egy! dologban volt igaza Leninnek .
    Mutasd a teljes hozzászólást!
  • Lehet, mint említettem,  rég elhagytam a pályát, nem látom,  ma mi megy élesben.
    Azt tudom, hogy hiába ismerek egy nyelvet (pl python), webes keretrendszert (flask), az említett hiányosságok miatt egészen primitív dolgokat  sem tudok tisztességesen elkészíteni, mert nem tudom megtervezni.
    És amikor felhagytam a programozással, akkor is ez volt a bajom. Kódolni tudtam, de egy feladatból rendszerzervet készíteni, megtervezni, hogy mit, hogyan... hát az nem ment már akkor sem.
    Mutasd a teljes hozzászólást!
  • A legjobb, ha valakiben van kis kurázsi, hogy olyat vállal amire még nem képes... és kénytelen megtanulni, a saját bőrén, nyomás alatt.

    Ebben volt részem, egyetértek.

    A profikkal kapcsolatban - több projekt esetében is - azt tapasztaltam, hogy a nagy, átfogó rendszereket dobozos programok szabás-varrásával hangolják a szervezetre. Néha nagyon megerőszakolva. Több milliós licenszek és több milliós mérnökóra-díjak mennek el arra, hogy gyári alkalmazásokat alakítsanak egymáshoz inkább kisebb, mint nagyobb sikerrel. És ez EU ügynökségeknél is megy. Szóval nem magyar specifikum.
    Vajon hol vannak a "zöldmezős" fejlesztők? A régi időkből emlékszem remekül működő nyilvántartó programokra, raktárkezelő, bérszámfejtő stb. alkalmazásokra. Nagy gyártók logói nélkül. Ilyen cégtől nem is érkezett ajánlat. Pedig nem akarjuk a csillagot az égről.
    Mutasd a teljes hozzászólást!
  • "Algoritmusok, matematikai alapok nélkül"

    Szerintem fordítva van.

    Ezek most már nem kellenek.

    Mert megoldja a keret rendszer, a fejlett programozási nyelvek, az órajel és a memória mérhetetlensége, és a github

    Sokkal könnyebb most fejleszteni. Látszólag több mindenhez kell érteni, valójában nem, és azokhoz is elég  csak felületesen.
    Mutasd a teljes hozzászólást!
  • Próbálom érthetőbben: alapok kellenek, szilárd alapok.
    Én végigjártam a középiskolát, ahol "programozókat" képeztek, aztán úgy gondoltam, hogy ebből én meg tudok élni.
    Hát ja... akkoriban ment is. Csak ugye ami akkor elég volt, az manapság nagyon kevés. Algoritmusok, matematikai alapok nélkül ma már nem nagyon lehet túlélni a szakmában, max. kóklerkedni lehet. És ezeket az unalmas, de lényeges dolgokat nem nagyon tanulja meg senki, ha csak hobbiból tanul, nincs "motiváció" (=vizsgák, bukás lehetősége stb.)
    Szerintem.
    Mutasd a teljes hozzászólást!
  • Hát ez így nagyon általánosító vélemény. Az én tapasztalatom kicsit más. Egyrészt ebben a szakmában (nyílván sok másban is) önképzés nélkül az iskola csak papír... egy váltó/biztosíték arra, hogy az illető tud tanulni viszonylagos hatékonysággal.

    De én is érzem hiányát pl. bizonyos egyetemi szintű elméleti tárgyaknak amit "szabad időben" felszedni sokkal nehezebb.

    De! Aki akar az fog tanulni, seniorabb kollégáktól, learn-by-doing kényszer alatt, könyvekből és az elmúlt 5-10 évben már rengeteg előadás elérhető a neten vagy be is lehet akár csak kurzusokra iratkozni, tényleg mindent IS meg lehet tanulni "auto didakta módon".
    A legjobb, ha valakiben van kis kurázsi, hogy olyat vállal amire még nem képes... és kénytelen megtanulni, a saját bőrén, nyomás alatt.

    A cégeknél szerintem többet ér, jobban számít ez a képesség, mint a papír megléte.

    ... az lehet, hogy neked ez nem jön be, lehet egyszerűen nem is neked való ez a szakma, mert nem köt le annyira, hogy ezen járjon az agyad ha kell-ha nem. Szerintem fontos, hogy az ember örömöt találjon abban amit amúgy is csinálnia kell.
    Mutasd a teljes hozzászólást!
  • A 90-es évek elején még úgy tűnt, van jövője az iskola nélküli önfejlesztésnek. Kb tíz, programozóként töltött év eleg volt ahhoz, hogy megállapítsam, biztosan van akinek így is megy, nekem nem. Akkor váltottam üzemeltetésre, aztán újabb tizensok év után azt is feladtam.
    Konklúzió: hobbi programozóknak jó az autodidakta, élesben jobb ha mással foglalkozikaz ember.
    Abban még lehet fantázia, amit régebben "code monkey"-ként emlegettek, de algoritmizálni, komplett rendszereket átlátni, megtervezni stb... azt (szerintem!) iskola vagy legalább megfelelő oktatók nélkül esélytelen elérni.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd