Hirdetés
- Parci: Milyen mosógépet vegyek?
- ricsi99: 6. Genes alaplap tündöklése.. kontra MS/Zintel korlátozásai.(Mehetnek a levesbe)
- skoda12: Webshopos átbaszások
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- GoodSpeed: Megint 3 hónap Disney+ akciósan :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
-
LOGOUT
Új hozzászólás Aktív témák
-
-
#20718
cucka
addikt
VikMorroHun
#20717
cucka
addikt
válasz
VikMorroHun
#20717
üzenetére
azt akarom, hogy egymás után állítsa be őket a program.
Akkor írj egymás után 3 if-et. Nem értem, miért vannak az if-ek egymásba ágyazva. -
#20706
cucka
addikt
VikMorroHun
#20705
cucka
addikt
válasz
VikMorroHun
#20705
üzenetére
Az a baj vele, hogy a grafikus IDE-k, az intellisense, és az azonnali statikus type checking egyszerűen elavulttá tette. Azok a problémák, amiket megold, nagyrészt nem léteznek.
A másik, hogy nagyon korlátozott a felhasználhatósága, leginkább C-ben előforduló primitívekre van kitalálva. Ha ennél fejlettebb típusrendszert használsz (ami azért előfordul
) akkor nem jó semmire.A Robert C Martin hivatkozás a wikin pont arról szól, hogy nem javasolja a használatát. Ahogy Linus vagy Stroustrup sem.
-
cucka
addikt
válasz
proci985
#20701
üzenetére
De jó is lenne, ha az egyetemről kikerülők kennék-vágnák a clean code témát. Sajnos a valóság ennél sokkal lelombozóbb.
Velem előfordult már, hogy "senior" programozó sok év tapasztalattal és millió feletti fizetéssel, és én kellett neki elmagyarázzam, hogyan kell megírni egy unit tesztet.
-
cucka
addikt
Mi az alternatívája a Clean Code-nak?
Mi az a könyv, amit oda tudok adni a programozónak, aki szarul programozik, hogy tanuljon belőle?A többi amit írtál - ne haragudj, de nem tudom értelmezni, a szavakat egyesével értem, de koherens gondolatot nem tudok belőle kihámozni.
-
cucka
addikt
A baj ezzel, hogy nem tudod tudományos igényességgel megfogalmazni, hogy mit jelent az, hogy "jó a kód". Ugyanúgy nem tudod megfogalmazni azt sem, hogy mi a "helyes absztrakció".
Van egy csomó metrika, sokszor egymásra ortogonálisak, és ezekből lehet okoskodni.
Az egyetlen amit meg tudsz objektíven fogalmazni, az a kód helyessége. -
cucka
addikt
Szerintem itt félreértés van arról, hogy mire jó a Clean Code.
Ez egy tankönyv kezdőknek. Gondolatokat és szempontokat fogalmaz meg arra, hogy mi számít a szerző szerint jó kódnak, egy adott kontextusban.
Nem receptkönyv. Nem szabály-lista, amit ha vallásos dogmaként kezelsz, akkor automatikusan jó kódot fogsz írni.Tudományos bizonyítékot igazságtalan számonkérni. Arra sincs tudományos bizonyíték, hogy a DDD elveinek betartásával jól fogod modellezni a problémát. Ettől még használjuk, hiszünk benne, hogy működik.
És a DDD szerintem más szintje az absztrakciónak. Arról szól, hogy hogyan lehet az üzleti problémát kódként modellezni. A Clean Code meg arról szól, hogy hogyan írd meg az osztályodat úgy, hogy azt le lehessen tesztelni és más is megértse.
Azzal én sem értek egyet, hogy a Clean Code-ra dogmaként gondoljunk. De hidd el, a programozók többségének bizony jót tenne, ha képes lenne megérteni és alkalmazni azokat az elveket. Példának pont felhoztad, hogy mi van akkor, ha valaki nem érti a DRY elv lényegét. Nem a DRY elvvel van baj ott sem, hanem user error.
Egyébként ha már itt tartunk, szerintem a Clean Architecture egy sokkal jobb könyv.
Illetve Uncle Bob ír blogot is, mostanában funkcionális programozással foglalkozik, és minő meglepetés, a clean code elvek arra is alkalmazhatóak. Mert ezek elvek. Nem receptek, szabályok, előírások. -
cucka
addikt
Igen, teljesen felesleges a komment, ha azt mondja el, ami a kodbol is latszik.
Igen, és fordítva is igaz. Arra kell törekedni, hogy a kód önmagában elég beszédes legyen, ne legyen szükség kommentre. És jól írod, vannak dolgok, amik nem derülhetnek ki önmagában a kódból.Például a nagy klasszikusnál ha a függvény neve az lenne, hogy "fastInverseSquareRoot", akkor az az összes komment, amire szükséged van igazából.
-
cucka
addikt
válasz
btraven
#20683
üzenetére
Robert C Martin nem tiltotta a kommenteket.
Ehelyett az állítás, hogy a jól megírt kód önmagában olvasható, nem szükségesek hozzá kommentek.
Az egész gondolatmenet arra van felfűzve, hogy a programozó idejének jelentős részét mások kódjainak olvasásával tölti. A kód amit te írsz azt a következő embernek írod, aki el fogja olvasni. Ezért ha a kódod önmagában nem olvasható és kommentben kell magyarázni, az gyanús.És igen, vannak kivételek a szabály alól. De ahhoz, hogy tudd, mikor kell megszegni a szabályt, előbb érteni kell, hogy miért jött létre egyáltalán a szabály, milyen problémát akar megoldani.
-
cucka
addikt
-
cucka
addikt
A korábbi hozzászólásokban leírtuk, hogy miért lett nagyon népszerű a java.
2010-ben, amikor az android megjelent, akkor már bőven az egyik legnépszerűbb nyelv/technológia/platform volt. A legtöbb szerveroldali szoftver közép és nagyvállalatoknál akkor már javaban készült.Szóval nem az android hozta el ennek a nyelvnek a népszerűségét. Sőt, igazából pont az ilyen eseményvezérelt mobil alkalmazás az, amire annyira nem testhezálló javat használni, nem véletlenül tért azóta át mindenki kotlinra android vonalon. (Ami amúgy egy tök jó nyelv)
Ja és 2005-ben már bőven volt elérhető árú lakossági fél-1 megabites kábeles meg adsl internet. Akkora burzsuj dolog volt, hogy csóró egyetemistaként ilyenünk volt az albérletben.
Én értem, hogy te akkoriban 10 évvel lemaradva éltél a vax gépeiddel meg a dosos könyvelőprogramokkal, de a világ már bőven túllépett ezeken akkor is. -
cucka
addikt
válasz
petyus_
#20513
üzenetére
Technikailag nincs semmi baj a dotnettel, ez saját egyéni preferencia.
Igazából kb. 10 éve macen fejlesztek, szóval csak júzerként használom a termékeiket, és hát igazán átjön, hogy abban a cégben silók működnek, és a termékek fejlesztésénél az egyetlen szempont, hogy az adott silóban az összes menedzser megkapja az év végi bónuszát. Termék vízió nulla, konzisztencia nulla, ízlés nulla, a felhasználói élmény le van szarva.
Felhasználói szemmel az a folyamatos élményem, hogy ezek rossz minőségű, esetlegesen kitalált és összedobált termékek.
Ha megvan az "enshittification" fogalma, na az 100%-osan igaz erre a cégre és mindenre, amit kiadnak a kezükből.De ismétlem, ez egyéni preferencia, nem műszaki kifogás, nehogy hitvita induljon el ebből
.Hogy pozitívat mondjak, az F# nagyon tetszik, azzal szívesen dolgoznék.
-
cucka
addikt
-
cucka
addikt
válasz
Vision
#20506
üzenetére
Én nem emlékszem ilyen kikötésre. Ezt ne vedd 100% biztosra, de szerintem nem fogják visszadobni a szimulátoros screenshotokat.
Delphi azért kopott ki, mert jött a java, ami letarolta a piacot:
- jvm, krosszplatform, a java applet-ek akkoriban jó iránynak tűntek
- teljesen menedzselt oop nyelv, ez a 90-es években komoly fícsör volt
- java ee meg hasonló enterprise fícsörök
- nem volt akkora brutál vendor lock in, mint a borland rendszerével.Utána meg a kegyelemdöfést a web adta meg, ami eredetileg ugye hypertext alapú médium volt, de szép lassan alkalmazás platformmá nőtte ki magát. Manapság más kb. senki sem fejleszt windows desktop alkalmazásokat, minden a webre költözött.
Manapság meg már halott ügy, minden javascript-java-dotnet, esetleg python, mindent saas meg paas platformok futtatnak, ahova havi pár eurós a bekerülési költség, minden fordító és fejlesztőeszköz ingyenes vagy nagyon olcsó.
Na és erre jön az Embarcadero a 2000 eurós fejlesztőeszközével (ez a basic bitch verzió, frissítések nélkül, az plusz pénz), hát nem hiszem, hogy egymást tapossák érte a vásárlók. -
-
cucka
addikt
Nem fog belekötni, eddig se kötött bele, leszarják.
- az apple developer pénzt így is megkapják
- a 30%-ot így is leveszik minden tranzakcióból
- műszakilag ezek kompromisszumos megoldások, nem tudom, milyen veszélyt jelentenének a platformjukra. Ha first party minőségű app-ot akarsz csinálni, ami támogatja a legújabb fícsöröket, akkor ezek a cross platform cuccok mind felejtősek -
cucka
addikt
válasz
Kutyauto
#20467
üzenetére
Cordova az régóta döglött. Ilyen vonalon a Flutter vagy a React Native az, amit használnak.
Ha most bele kéne kezdenem ebbe, akkor React Native-ot választanék, pusztán azért, mert a js-ts-React tudás könnyen hasznosítható.#20468Imy
Cubix-ot nem ismerem, de ha a célod, hogy munkaerőpiacon értékes tudást szerezz, akkor inkább válassz egy nyelvet/platformot és abban mélyedj el.
Szerintem C# és C++ nem az a két nyelv, ami jól kiegészítené egymást, szóval ritka, hogy mindkettőhöz érteni kell. -
cucka
addikt
válasz
cog777
#20395
üzenetére
A jatekallas azert nem egyszeru mert vannak scene-k azok mas node-okat tartalmazhatnak.
Erre azt tudod csinálni, hogy minden objektumodnak adsz egy egyedi id-t. És akkor a referenciád nem egy objektum lesz, hanem egy objektum id. (ami egy string vagy uuid vagy bármilyen primitív)
Ezzel eléred, hogy az objektum gráfodat kezelheted objektum listaként, könnyű menteni-betölteni.
Annyi a plusz meló vele, hogy betöltés után ezeket a referenciákat kézzel fel kell oldani.Lényegében ez a szegény ember kézműves, lábbal hajtós lazy loadingja.
De lehet van rá jobb megoldás, nyilván, a legjobb megoldás, ha nincsenek körkörös referenciáid
. -
cucka
addikt
válasz
totron
#20326
üzenetére
És akkor mi van? Az összes többi szakma nem ilyen?
Ha valaki elmegy ovónőnek, akkor mikor lesz belőle senior ovónő?
Vagy szerinted egy kezdő junior háziorvosnak az a karrieríve, hogy sokat tanul, majd senior lesz belőle, és végül akkor agyat fog műteni?Nézz ki egy kicsit a fejlesztői buborékból.
Ez is egy olyan szakma, mint a többi. Ahogy minden szakmában, a csúcsra csak a szakemberek minimális része fog eljutni. Tehát a többség "örök junior" lesz. Vagy "örök senior". Ez van. -
cucka
addikt
válasz
Vision
#20319
üzenetére
A UI-UX dizájnerek többsége egy kétpálcás bohóc.
Ahhoz, hogy jó legyen a termék, nem tudod megúszni, hogy kicsit érts ezekhez. Ahogy a SEO-hoz is kell érteni.
És jó hogy vannak előre megírt komponensek, mert boldog-boldogtalan komponenseket ír, de a többségük szar. Tessék-lássék jól működik.
Aztán jön a júzer héberre állított telefonnal, gyengénlátó módban, és szétesik az egész amit csináltál.És a másik a performancia. Webvitals valaki?
Ha a youtube-on a live chat ablak leblokkolja 1 másodpercre a render thread-et akkor az is UX probléma, de mégis csak a fejlesztők baszták el, és nekik kéne megoldani.
Vagy téged is zavar, amikor betöltesz egy oldalt, és össze-vissza ugrál a szöveg, amíg a háttérben betöltődik a kép meg a reklám? UX probléma, de a fejlesztő baszta el.És akkor ne beszéljünk a typescript-ről (ami ugye jó, csak mellette a javascripthez is kell érteni), a packaging-ről, meg az egész ökoszisztémáról, hogy csinálsz egy lángossütőnek egy weboldalt, és 1 giga a node_modules-od, de azért jó lenne, ha gyorsan betöltődne, meg nem akadna meg az animáció.
A frontend egy nagyon mély nyúlüreg. A felszíne egyszerű.
-
cucka
addikt
válasz
Vision
#20312
üzenetére
Ez egy hatalmas tévedés, hogy "bezzeg a backend".
Valójában a frontend fejlesztés a legtöbb esetben sokkal nehezebb.A szoftverek 95%-ában a backend annyit csinál, hogy valami adatot beolvas valahonnan, transzformálja, majd valahova valamilyen formában kiszolgálja.
Ehhez képest jó UI-t készíteni az iszonyat nehéz. Ez egy eseményvezérelt, aszinkron rendszer, aminek gyorsan és helyesen kell működnie. A komplexitás, amivel dolgoznod kell, az jelentős.
És jó UI-ra az egyszerű szoftvereknél is szükség van. Sőt, ott van igazából szükség rá.
#20313galaxy55
Összegezd már, semmi kedvem órákon át hallgatni egy random kezdő programozó életsztoriját meg locsogását a szakmáról, ennél bármit szívesebben hallgatok. -
cucka
addikt
válasz
totron
#20308
üzenetére
Mi ebben a rossz üzenet?
Ez egy tömegszakma. A világon sok millióna foglalkoznak szoftverfejelsztéssel. Nem tudom, miért kell úgy gondolni rá, mint ha valamilyen kiválasztott kaszt tagja tudna csak szoftvert írni.
És mindenki, aki ezzel foglalkozik, az elkezdte valahol. Valahogy meg kelll tenni az első lépéseket.Főleg webfejlesztésnél. Itt tényleg nagyon sok olyan munka van, ami nem igényel mélységet, megalapozottságot, meg semmit, viszont meg kell csinálni.
-
cucka
addikt
-
cucka
addikt
válasz
galaxy55
#20286
üzenetére
az IT is olyan szakterület lett, ahol inkább ölik, mint segítik egymást a dolgozók?
Szerintem ez egyáltalán nem igaz.Annyi történt az utóbbi pár évben, hogy elfogyott a gazdaságban az ingyen pénz.
Szóval nincs már akkora programozó hiány, normalizálódik a piac, mindenki jobban megbecsüli a munkáját.A másik, ami történt, hogy jött az AI, ami nagyon rossz hír a junioroknak, akik most akarnak betörni a szakmába.
-
#20274
cucka
addikt
BUZZLGHTYR
#20267
cucka
addikt
válasz
BUZZLGHTYR
#20267
üzenetére
Szerintem érdemes. Azt érdemes tudni, hogy ez egy szakma, és nem annyira könnyű.
Illetve lehet, hogy van hozzá affinitásod, és élvezed csinálni, és könnyen megy. És az is lehet, hogy nincs hozzá affinitásod, és akkor soha nem fogod tudni ezt rendesen megtanulni. Ez menet közben derül ki.Ha nulláról indulsz, akkor legalább 2-3 év tanulás lesz, amíg elérsz arra a szintre, hogy juniorként esélyed legyen az első munkahelyhez.
Tanfolyam akkor érdemes, ha szükségét érzed, hogy valamilyen oktatási rendszerben, számonkérhetően kezdd el a tanulást.
De azok az idők lejártak, hogy egy 3-6 hónapos gyorstalpaló után nulla szaktudással állást tudj találni. Pár éve még így volt, manapság már ennél magasabb a belépési küszöb.Angolra azért van szükség, mert minden oktatóanyag, dokumentáció angolul található meg. Német tudás pedig nagy előny akkor, ha német cégnél szeretnél dolgozni, amiből azért van pár.
Nincs szükség erős gépre vagy speckó hardverre ahhoz, hogy elkezdd nulláról a programozás tanulását.
-
cucka
addikt
válasz
martonx
#19301
üzenetére
De pont elhiszem, mert volt velük kapcsolatom, és a saját szememnek csak hiszek.
Ők nem egy kamu cég, nem strómanok, nem csak papíron léteznek, hanem tényleg valóban vagy egy csomó szoftverfejlesztőjük akik szoftvert fejlesztenek.Attól mert közbeszerzés és NER közeli, a munkát valakinek el kell végezni. A stadion nem épül fel magától, az út nem lesz ott a semmiből, és a szoftver sem írja meg magát.
És ha te betont szállítasz a teherautóval az építkezésre, akkor neked kb. édes mindegy, hogy a projekt hogyan van finanszírozva, és hogy a haszonélvezőknek milyen politikai kapcsolatai vannak vagy nincsenek.
Persze lehet önérzetesnek lenni, megértem, egyáltalán nem kötelező ilyen helyen dolgozni. De ne feledd, ugyanígy fel lehet hozni erkölcsi érveket amellett, hogy miért ne dolgozz a McKinsey-nek, egy nagy pénzügyi vállalatnak, vagy mondjuk egy fogadóirodának.
Én speciel nem értem, hogy miért problémás az állami szféra erkölcsileg, ugyanakkor teszem azt a blackrock pesti irodája meg nem problémás erkölcsileg. De ez mindenkinek a saját szíve joga eldönteni.
-
cucka
addikt
Az UDP egy connectionless protokoll.
Vagyis minden csomag teljesen különálló. Nem garantált a csomagok sorrendje, nem tudod megmondani, hogy egyáltalán megkapta-e a címzett a csomagokat, és azt sem tudod megmondani, hogy melyik két csomag "tartozik össze".Szóval nem igazán tudom elképzelni, hogyan fogja ezeket összeragasztani bármilyen oprendszer.
Szóval ahogy írod, kényelmes dolog teljes sebességgel döngetni, és fosni a byteokat a hálózatra, abban az esetben, ha nem érdekel, hogy a címzett megkapta-e az összes csomagot, és az sem érdekel, hogy milyen sorrendben.
-
cucka
addikt
De, pont ezért van, leleplezted a nagy IT-ipar összeesküvést!
Viccet félretéve - a devops és az üzemeltetés az ugyanaz.
Csak régen az üzemeltető az volt, aki a hóna alatt becipelte a szervert a szerverterembe. Most meg ugyanez az ember ír egy python scriptet amivel a cloud-ban szervert hoz létre, voilá, devops. -
cucka
addikt
válasz
Vision
#18417
üzenetére
Telco és finance iparágakban jogszabályi előírás, hogy meg kell őrizni a tranzakciókat.
Például egy rendőrségi nyomozás során kikérik a gyanúsított 4 évvel ezelőtt szombat délutáni híváslistáját.
Na akkor nem az a jó válasz, hogy "Nincsenek meg az adatok, mert nálunk nem pancser fejlesztők dolgoznak" -
cucka
addikt
válasz
Drizzt
#18410
üzenetére
Ha a rendszered tranzakciókat dolgoz fel, akkor az a legjellemzőbb, hogy
1. Folyamatos, nagy mennyiségű, írási műveleted van, ahol a fő szempont a gyorsaság.
2. Kevés olvasási művelet, amelyek komplexek, és ezáltal nem is gyorsak.Azt nem tudom, mit jelent a "kiegyensúlyozott alkalmazás", gondolom ezt a faszság tantárgyon tanítják, azokra az órákra nem jártam be.
-
cucka
addikt
De most mi a kérdésed?
Hogy lehet-e más dolgokra használni a blockchaint, amire kitalálták?
Lehet, igen. Mosogatószivaccsal is ki lehet festeni a szobát.Vagy az a kérdésed, hogy miért nem tértek át erre a bankok?
Ugyanazért, amiért a szobafestők sem cserélik le a festékhengert mosogatószivacsra. -
cucka
addikt
Valóban nem ugyanarról beszélünk. Amiről te írsz, az egy elosztott rendszer.
A blockchain első számú fícsöre és problémaforrása, hogy decentralizált.Banki ledger-ek legalább 800 éve léteznek. A lényege, hogy minden érintett fél megbízik a bankban, hogy a tranzakciókat helyesen kezeli, megérkezik az utalás, nem tűnik el a pénz a számláról. A banknak pedig elemi érdeke, hogy ezt a bizalmat fenntartsa.
A blockchain arra a problémára ad megoldást, hogy hogyan tudnánk pénzügyi tranzakciókat elvégezni és validálni abban az esetben, ha nem léteznének megbízhatóan működő banki ledger-ek. Csak hát ugye léteznek, úgy legalább 800 éve.
-
cucka
addikt
válasz
axioma
#18233
üzenetére
Egy vállalkozó elsősorban üzletember, szóval olyan hozzáállás, mindset szükséges hozzá.
Például te tudsz mobil appot fejleszteni, valakinek meg pont egy mobil appra van szüksége. A te dolgod megtalálni őt és eladni neki a tudásodat, lehetőleg úgy, hogy minél több pénzt keress rajta.
-
cucka
addikt
válasz
K1nG HuNp
#18229
üzenetére
nemtudom miert gondoljak emberek hogy a vallalkozashoz nem kell iskolazottsag
Ebben pont személyesen is érintett vagyok.
Egy vállalkozáshoz nem diploma kell, hanem szaktudás. Nem tudsz úgy sikeres szoftveripari vállakozást indítani, ha nem értesz a szoftveriparhoz. Emellett szükségesek egyéb nem szakmai skillek, például jól kell kezeld a stresszes, kockázatos helyzeteket.Természetesen az egyetemi oktatás fontos, és segíthet abban, hogy a szükséges szoftveripari szaktudás egy részét megtanuld.
A fontos, hogy nem fogsz mindent megtanulni az egyetemen, és az is, hogy a tudás az, ami érték.Vannak olyan szakmák, ahol elvárt a diploma, például ügyvéd. De ott meg ez a kérdés irreleváns lesz, a diploma olyan beugró feltétel, mint a kőművesnél az, hogy meg bírjon emelni egy zsák cementet.
Az ügyvédi irodában van ügyvéd, aki minimálbér-közeli pénzért csinálja a favágó munkát, meg van sztárügyvéd sztárügyekkel, sztárfizetéssel. Mindketten ugyanazon az egyetemen ugyanazt a diplomát szerezték meg. -
cucka
addikt
Az, hogy az elosztott rendszerek fejlesztése nehéz, az az én saját személyes tapasztalatom.
Amúgy bármikor tehetsz te is egy próbát, és nekiállhatsz lefejleszteni egy hibatűrő elosztott rendszert, és ezután neked is lesz tapasztalatod arról, hogy mennyire könnyű vagy nehéz ez a témakör.
-
cucka
addikt
Ilyen feladatokra az iparágban key value store-t szoktunk használni. Cloud-ban a natív megoldásokat érdemes használni, saját üzemeltetésben a legtöbbször redis-t láttam. De léteznek distributed actor megoldások is, amivel megvalósítható.
És nem, nincs egymillió megoldás erre, mert ilyen elosztott rendszerek lefejlesztése kurva nehéz feladat.
-
cucka
addikt
Az a fő probléma, hogy az elosztott rendszerek egy nagyon nehéz témakör, a te ismereteid pedig nem elegendőek ahhoz, hogy ezt felismerd.
Ha pozitív akarok lenni - ez egy remek alkalom a fejlődésre, itt egy témakör, amihez egyáltalán nem értesz, viszont érdekes, izgalmas, és megéri elmélyedni benne.
Ha negatív akarok lenni - a magabiztosan előadott gondolataid olvasása közben óhatatlanul a Benny Hill zenéje szól a fejemben.
-
cucka
addikt
Az a szint, ameddig megtanulható a programozás az kevesebb, mint a minimum, ami szükséges ahhoz, hogy ezt a szakmát professzionálisan űzd.
Az absztrakciókban való gondolkodás egy készség, ami fejleszthető, de nem tanulható.Ettől még persze a szoftveripar tele van kóklerekkel.
Ha érdekel a téma, itt van Jeff Atwood nagy hatású blogposztja még régről - [link] . Ez hozta be a köztudatba a FizzBuzz-t.
Ez nem tűnik nagy dolognak, de valójában az. Itt jött rá a teljes szakma, hogy az interjún végzett feladatok célja elsősorban nem az, hogy a jelentkezők felső 5-10%a között rangsorolni tudj, hanem hogy kiszűrd a jelentkezők 50%-át, akik egy alapszintű programozási feladatot sem képes megoldani. -
cucka
addikt
válasz
martonx
#18016
üzenetére
Egy szintig nyilván tanulható a programozás,
Szerintem ez határozottan nem igaz. A programozás olyan szakma, ami megköveteli az absztrakt gondolkozás készségét, ami nem tanulható. Valójában a legjobb indikátora annak, hogy valaki alkalmas-e erre a pályára az az IQ teszt, mert ott ezeket a készségeket mérik.
Ne érts félre, ez nem valami IQ-fasiszta duma. Egy csomó hasonló szakma van.
A profi sportolók az átlagemberhez képest kiemelkedően atletikusak, és ez már gyermekkorban is látszik.
A profi zenészneknek az átlagembernél jobb a zenei hallása.
Az előadóművészetben extrovertáltságra van szükség. Ők azok, akik már óvodás korban is állandóan szerepelni akarnak.
Szociális vagy oktatási pályán előfeltétel az empátia és altruizmus.Mindegyik tanulható, én is el tudok menni kosárlabda edzésre hogy megtanuljak játszani. Azt viszont soha nem tudom megtanulni, hogy legyek 20 centivel magasabb és tízszer atletikusabb.
-
cucka
addikt
válasz
pmonitor
#18007
üzenetére
Ott tévedsz, hogy azt hiszed, az elméleti dolgok nem fontosak a gyakorlati munkavégzés során. Valójában nagyon fontosak, mert enélkül a fejlesztők nem fognak közös nyelvet beszélni.
Tehát ha azt mondom a fejlesztőnek, hogy ide ez a két osztály közé kell egy adapter, erre a három service-re meg csinálj egy facade-et, ami ezt az api-t fogja implementálni, akkor előnyös, ha érti, hogy miről beszélek.#18008Ispy
A Dijkstra féle matematikai modellet "Bevezetés a programozáshoz" néven tanítják, ha jól tudom BSC első félévében. [link] ez az ELTE-s jegyzet.
Most arról nem fogok kisregényt írni, hogy mennyire elképesztően hülye ötlet ezzel tanítani a programozást. -
cucka
addikt
Persze, ilyen gyakran van, erre használjuk az UML diagramokat, esetleg ha van idő+pénz, akkor lehet írni SAD-ot is.
Ami fontos, hogy ezek nem matematikai eszközök. Amikor ilyet mondasz, akkor általában az automatikusan verifikált programokra gondol az ember, meg a Dijkstra-féle matematikai modellre. Tehát nem magyarázó diagramokról van szó, hanem függvényekről, halmazműveletekről, állapotterekről meg invariánsokról, illetve a legfontosabb - matematikai módszerekkel definiálni a program elvárt működését, majd bizonyítani, hogy valóban teljesíti a feltételeket. -
-
cucka
addikt
20 éve vagyok a szakmában, én még olyat nem láttam, hogy matematikai modelleket hozott volna létre bárki a szoftver tervezési szakaszában.
Nyilván, ha űrhajó vezérlő szoftverről beszélünk, ott elvárható.
Átlag üzleti szoftvernél én még nem láttam ilyet, ami szokott lenni, az egy halom uml diagram, jellemzően valamilyen személyes uml-nyelvjárásban, és persze mindegyik outdated mint a szar, meg persze mellé némi szöveges doksi. És ez a jobbik eset. Sokkal jellemzőbb, hogy kapok egy git repót, és akkor glhf. -
cucka
addikt
válasz
pmonitor
#17990
üzenetére
Először is - a komplexitás fogalmát ott érdemes tárgyalni, ahol nagy méretű kódbázisról van szó. Egy tök átlagos, jávában/c#-ban írt céges ügyviteli szoftverben lesz több száz, vagy akár több ezer osztály, amit éveken át írt több csapat, ilyen-olyan tudásszinttel, folyamatosan változó üzleti igényekkel.
Az essential complexity főleg tervezésnél fontos. Tudod, mi tartozik ide, tudod, hogy ideálisan ez stateless van implementálva, tudod, hogy erre akarsz tuti 100% test coverage-et, akár más tesztek kárára is. Ha DDD-t csinálsz, akkor ezt a komplexitást definiálod. Ha BPMN-t akkor szintén. Arra is jó, hogy rájöjj, ha a juniorabb kolléga refaktorálási ötletei valóban hasznosak-e, vagy csak arra jók, hogy a komplexitást átrakd az egyik zsebedből a másikba.
Ciklomatikus komplexitást arra használod, hogy jelzi, melyik részei tesztelhetetlenek a programodnak. Ezek azok a részek, amelyek sürgős refaktorra szorulnak, mielőtt bárki azon gondolkozna, hogy teszt lefedettség.
Kognitív komplexitás metrika szintén a problémás részek azonosítására szolgál.
LOC esetenként lehet hasznos, ugye megmondja, hol vannak hosszú függvények a kódban. De ugye önmagában ha hosszú a kód, az nem jelent gondot. Az jelent gondot, hogy várhatóan ha hosszú a kód, akkor nehéz lesz tesztelni.
Aszimptotikus komplexitást jól mérni nem nagyon lehet, ott jön elő nagyon, amikor nagy mennyiségű adattal dolgozol. Mittomén, minden éjjel ütemezettem riportokat gyártasz. Ha 5 perc egy riport legyártása, az nem gond, ha 3-at kell megcsinálj, de gond, ha 3000-et.
Vannak más szempontok és technikák is, de meghagyom mindenkinek az örömöt, hogy olvassa el magának a Clean Architecture-t.
-
cucka
addikt
válasz
pmonitor
#17982
üzenetére
Nem bántásból, de az a baj, hogy van egy elképzelésed erről a szakmáról, ami köszönő viszonyban sincs a valósággal.
Amiket írtam, azok mind a való életben szembejövő kérdések-problémák. Mindegyik fogalom szembejött már a munkám során ilyen-olyan formában.
Ezzel szemben az NP-teljesség kérdése alapvetően kívül esik a szoftverfejlesztők mindennapi munkáján. Ilyen kérdésekkel a számítástudomány foglalkozik, jellemzően kutatási téma akadémikusoknak, a vizsgálata pedig matematikai módszerekkel történik.
Értékelem az igyekezetet, de ha a mindennapokban, gyakorlatban fontos fogalmakról beszélünk, akkor erre az NP-teljesség a létező legrosszabb példa, amit kitalálhattál.
-
cucka
addikt
válasz
sztanozs
#17986
üzenetére
Szerintem nem annyira rendkívüli, most épp én is keresek 1-2 fejlesztőt, akik láttak már Springet, lehetőleg adnak számlát, és rendelkeznek az "Algoritmusok és adatszerkezetek 1." tantárgy első ZH-ján megkövetelt programozási tudással.
Meglepődnél, az utolsó feltételen hány tapasztalt programozó vérzik el. -
-
cucka
addikt
Na hát akkor a kedvenc interjú-témámon te is elvéreznél
. Szóval a komplexitás nem azt jelenti, hogy te épp mit gondolsz, hanem elég jól definiált fogalomhalmaz - érthető, a nagy komplexitás termelékenység-csökkenést okoz, a fejlesztők pedig nagyon drágák.Szóval mivel épp ráérek, némi támpont, hogy pongyolán megfogalmazva. (nem mindenre tudok magyar kifejezést)
essential complexity - az a komplexitás, ami nélkülözhetetlen. más szóval a megrendelő üzleti igényei. Ha a webshop 16 féle fizetést támogat, akkor az annyi.
accidental complexity - minden, ami nem essential.
ciklomatikus komplexitás - számolt érték, nagyjából a kód futás közben bejárható útvonalainak a száma. Tesztelhetőség szempontjából fontos.
kognitív komplexitás - számolt érték, azt akarja reprezentálni, hogy mennyire nehezen érthető a kód egy ember számára.
loc - ez a függvény sorainak száma, amiről beszéltél. Ha túl magas, az gyanús.
space and time - ez van valahogy magyarul is, de nem ugrik be. ez az amit az iskolában tanítanak, n-es, négyzetes, exponenciális, stb.És ezeken kívül még van a szubjektív komplexitás érzés. Van olyan kód, amit úgy olvasol, mint az újságot, és van olyan, amivel szenvedsz.
Hiába jók a metrikák a Sonárban, ha szembejön egy ProductFactoryProviderManager nevű osztály. Ilyenek még - rossz nevezéktan, inkonzisztens struktúrák, nevek, stb. -
cucka
addikt
válasz
fatal`
#17971
üzenetére
Hogy egy rendszer mennyire rugalmas a jövőbeli igények szempontjából, az alapvetően architekturális kérdés.
Az ideális szituáció, hogy az architektúrád rugalmas, és ott figyelsz arra, hogy mik lesznek a rendszer fix részei, és melyek fognak a jövőben mozogni.Egy ilyen setup-ban a programozók dolga a kódolás, és lényegesen kissebb a hibázási lehetőség is.
-
cucka
addikt
Jókat írsz, pár random gondolat:
- A fejlesztők többsége nem tud különbséget tenni az essential és az accidental complexity fogalmak között, és ez meg is látszik a munkájuk minőségén.
- Nekem a szoftveres komplexitás nagy kedvenc interjú témám, sajnos nagyon ritka az a versenyző, akivel egyáltalán eljutok ide. Tényleg, ti nem vettétek észre, hogy a diplomás, profi, sok év tapasztalattal rendelkező programozók többsége egyszerűen nem tud programozni?- Ez a Datomic nagyon szexi. Igazából eddig is tudtunk hasonló, objektum-history alapú adatstruktúrákat csinálni pucér sql-el, de na, ígéretes.
- A YAGNI elv lényege pont az, hogy ha valamire jövő hónapban lesz szükséged, akkor jövő hónapban írod meg. Falra tudok mászni attól, amikor a fejlesztők előre gondolkoznak és általánosítanak, 10-ből 9 alkalommal az lesz belőle, hogy kiderül, segg hülyék az üzleti igényekhez, és fogalmuk sincs, milyen absztrakciókra lesz szükség a jövőben.
-
cucka
addikt
Az az előnye, hogy számomra, az én napi munkámban komfortos
. - Sok projekt van a gépemen, amelyeken kell tudjak alkalomadtán dolgozni.
- Nem nagyon van köztük olyan, aminek az üzemeltetése konténerizált. Fejlesztőként max. a saját magam örömére írhatnék dockerfileokat, a konténerizáció fő előnyét nem tudnám kihasználni.
- A projektek egy része ilyen webes szutyok, node vagy php vonalon, ahol állandó kényelmetlenség volt, hogy melyik milyen verziójú dependenciákkal hajlandó működni.
- A projektek kis része pedig natív, ahol magunknak fordítunk mindent kézzel.
- Macen dolgozok, és macen a docker kifejezetten szar. Vagy legalábbis szar volt amikor próbáltam, fura bugok, értelmezhetetlen erőforrás-használat, stb.Szóval nem találtam fel a szent grált, egyszerűen csak erre az élethelyzetre kitaláltam egy fapados megoldást, ami eddig nekem bevált.
-
cucka
addikt
válasz
dabadab
#17759
üzenetére
Szerintem nem emiatt akar mindenki konténereket használni,
Nyilván, de túl sokszor láttam már olyat, hogy tök fölöslegesen konténerizáltak valamit.
Ez csak egy példa volt, hogy lehet viszonylag normálisan menedzselni dependenciákat konténerek nélkül is. Tehát létezik köztes megoldás a globális összeakadó dependencia pokol és a mindent dockerbe megközelítés között félúton.nem nagyon látom, hogy az általad javasolt megoldás milyen lényegi ponton különbözne a konténerektől
Hát azért az én megoldásom jóval fapadosabb.
Az egyik fő hátrány, hogy minden a saját userspace-emben fut, tehát valójában nincs semmi izolálva.
A másik fő hátrány, hogy ez devops szempontból lábbal hajtós megoldás. Egy konténert bedobsz az ECS-be, Kubernetesbe, stb.
További szívás, ha van a környezetbenv valami, amit háttérben kell futtatni, konténerizálva teljesen triviális, hogy mondjuk 3 eltérő mysql fut a gépeden daemonként, a fapados megoldásnál kicsit több munka. -
cucka
addikt
Szerintem félreérted, arról van szó, hogy kell-e mindenképp mindent konténerizálni, nem arról, hogy használsz-e 3rd party csomagokat.
Például linuxon létezik olyan, hogy filesystem hierarchy standard, tehát egyáltalán nem muszáj minden dependenciát globálba telepíteni.
A linuxos dependencia pokol abból jön, hogy mindenki globálba telepít mindent, amit amúgy egyáltalán nem muszáj. Lehet minden projektnek saját könyvtára saját környezettel, és akkor nem lesz összeakadás, ha 4 különböző node verzióra meg 3 különböző java verzióra van szükséged különböző projektekhez.
Szóval kb. azzal hogy nem szemetelem tele a /usr-t, kihúztam a dependencia pokol méregfogát, és megoldottam a fő problémát, ami miatt mindenki mindent egyből konténerizálni akar.
-
cucka
addikt
-
cucka
addikt
válasz
pmonitor
#17692
üzenetére
A delegate-eket arra találták ki, hogy ne csak adatot tudj átadni paraméterként, de viselkedést is.
Praktikusan erre találták ki a függvény pointereket, jobb/modernebb nyelvekben meg alapból használhatsz függvény paramétereket. Ahol egyik se volt (pl. régebbi java), ott lett ez a rettenetes gányolás a delegate-ekkel.
-
cucka
addikt
válasz
hellomi
#17535
üzenetére
Annak nincs értelme, hogy "regex parancs".
Olyat tudsz, hogy egy bemeneti szövegből regex pattern alapján gyártasz egy kimeneti szöveget.Például itt a bemenet az, hogy "valami.pdf", a kimenet pedig "valami-5.pdf"
echo "valami.pdf" | sed -E 's/^(.*)\.pdf$/\1-5.pdf/'De olyat nem tudsz, hogy van n darab bemeneted, és akkor a regex pattern tudja magától, hogy épp hanyadik mintát nézi. Arra írhatsz egy for ciklust, pl.#17534hozzászólásban van rá példa, ott egy $i változóban van az aktuális sorszám, azt bele tudod rakni a sed regex pattern-jébe, és akkor azt fogja behelyettesíteni az 5-ös szám helyett.
-
cucka
addikt
Ha rendesen szét van választva az üzleti logika és az alkalmazáslogika, akkor az a megfigyelésem, hogy az üzleti logika szinte mindig stateless, az alkalmazáslogika meg általában nem az.
Szóval a cél nem az, hogy lisp-el büntesd magad meg a kollégáidat, hanem hogy az üzleti logikát mellékhatás-mentes függvényekkel fogalmazd meg. És akkor mindegy miben írod, akár lisp-ben is megteheted, ha tényleg azt szeretnéd, hogy az összes kollégád gyűlöljön.
-
cucka
addikt
Igen, az teljesen életszerű, hogy hálózat nélkül futtatod a javascript alkalmazásodat.
#17296sztanozs
Az ökoszisztémát érintő problémák általában fejlesztés közben jönnek elő, pl. 1 napig turkálod, hogy az npm install most miért dob hibát és korábban miért volt jó. És ezt az 1 napot valaki neked kifizeti, aki ha tudná, nem örülne. A maradék probléma meg leginkább élesben, pl. memory leak-ek.UAT arra van, hogy az ügyfél átvegye és jóváhagyja azt, amit fejlesztettél. Ha itt derülnek ki hibák, akkor valamit rosszul csináltok.
-
cucka
addikt
válasz
martonx
#17287
üzenetére
A 134 dependencia nem amiatt riasztó, hogy mennyi helyet foglal a diszken.
A probléma, hogy a 134 dependencia az vagy 100 vendort jelent, mindegyik hozza magával a saját kódolási stílusát, véleményét és bugjait.A tietek egy egyszerű eset, mert tudatosan nem húztok be mindenre egy libraryt. A vadonban az általános inkább az, hogy mindenki nyakló nélkül húzogatja be a dependenciákat, aztán a végeredmény az lesz, hogy az egész rendszert a szentlélek tartja össze, és ha a több száz dependencia közül 1-el bármilyen probléma van, akkor az egész kártyavár összeomlik.
És probléma lehet bőven. Senki se tudja megszámolni, a több száz libraryból hányan változtatgatják a globális típusok prototípusait. Senki sem tudja, ki mit hívogat node-gyp segítségével, vagy mit matat a filesystemben. Még abban sem lehetsz biztos, hogy a több száz dependenciád mind helyesen követi-e a szemantikus verziózást.
Emlékszünk a left-pad.js problémára. Vagy a múlt héten a hülyére, aki a node-ipc package-be malware-t rakott. -
cucka
addikt
válasz
dabadab
#17277
üzenetére
Hát nem tudom, nekem csak a szívás jut vele.
Az npm és az egész mikro package elképzelés egy határ szar. Az nem normális, hogy egy viszonylag egyszerű szoftvernek 2-300 dependenciája van.
Aztán ha nem megy vele valami, akkor sok sikert. Néha az a hiba, hogy adott package csak globálba telepítve megy. Vagy beszarik a node-gyp. Vagy rossz a node verzió. De türelmesen próbálkozz a 8 magos gépeden, mert ez a szar egy szálon fut.Aztán ott van, hogy itt mindenki preprocesszort meg fordítót akar írni. Typescriptet fordítunk. CSS-t fordítunk. Template-et fordítunk. Aztán az egészet becsomagoljuk. Sőt jönnek a php-s hülyék és ők sem akarnak kimaradni a jóból, ezért a csomagolóra írnak egy saját csomagolót (laravel mix). És az egészre egy futtatót, mert hát az felháborító lenne, hogy írjunk egy build scriptet, hát nem vagyunk mi állatok. De egy futtató nem elég, legyen több, az "industry standard" az ilyen lefordíthatatlan szójáték. És fontos, hogy az egyik package ezen dependáljon, a másik meg azon.
Na és ez a tooling, berakod a projektbe, hoz mindegyik magával 100 dependenciát meg úgy 300 nyitott bugot. Te futottál már be typescript fordító hibába? Mi igen.
Na és ezekkel fogod és elmerülhetsz a frontend fejlesztés mocsarában. Ahol mindenki annyira okos, hogy saját virtuális dom-ot meg event loop-ot ír, mert hát biztos jobban megoldja javascriptben azt, amit a böngésző fejlesztők C++ban megírtak. Sok sikert ahhoz, hogy találd meg, hol leak-el a memória, mert valahol leak-elni fog.
Bocs a rantért, de szerintem az ipar egyik rákfenéje mostanában pont a javascript ökoszisztéma, annak a minősége, és az a tény, hogy kenyérpirítótól desktop appon át szerverig mindenki mindent ebben a szarban akar lefejleszteni.
-
cucka
addikt
válasz
dabadab
#17274
üzenetére
Hát nem tudom, mi javult benne. A böngésző mint platform végül is eléggé kiforrott.
De az egész javascript ökoszisztéma az egy igazi foskazal, nekem lábrángásom van, amikor az a munka, hogy ahhoz hozzányúljak.Régen a php és a ruby on rails köré gyülekeztek a hülyék a szoftveriparból, azóta a javascript utcahosszal átvette a vezetést.
-
-
cucka
addikt
válasz
Silεncε
#15083
üzenetére
Nem arra gondolok. Olyanokra, mint
- stabil-e a szolgáltatás, amiért fizetsz? Jövőre is stabil lesz?
- kivesznek-e belőle fícsöröket 1 év múlva? (lásd Atlassian)
- beetető árazás, majd jelentős áremelés lesz?
- egyoldalú szerződésmódosítás, pár apró betűs rész módosult, aztán jövő hónapban falnak mész a számlától
- ha elég nagy a cég és nem férsz bele az előre megadott csomagokba, faszra húznak-e a sales-eseik, amikor az egyedi árazásról tárgyaltok?Ezek nem vádaskodások, hanem lehetőségek, amiket érdemes szem előtt tartani, amikor egy vendor-al szerződsz és a céged működését hozzájuk kötöd. Szóval semmi Microsoft specifikus, akármelyik SaaS/PaaS/Cloud szolgáltató örömmel kizsebel, ha lehetőségük van rá.
-
cucka
addikt
válasz
K1nG HuNp
#15080
üzenetére
A Microsoft úgy jön ide, hogy övék a Github.
A vendor lock-in meg úgy, hogy ha átállsz a Github Actions + Codespace kombóra, akkor
a Microsoft-nál lesz a forráskód, a CI, a release-ek, az MS fejlesztőkörnyezetében fog mindenki dolgozni és a futtatókörnyezet is valami konténer lesz az Azure-ban.A nehéz kérdés azt mérlegelni, hogy mennyire éri meg ez a kockázat, mennyit spórolsz azon, hogy nem lábbal hajtósan üzemelteted mindezt, mennyire bízol meg a Microsoft-ban, hasonlók.
-
-
cucka
addikt
A Codespaces-t kipróbáltad, benne vagy esetleg a bétában?
Nézegetem és próbálok rájönni, hogy ez mitől jó, de nem megy. Az egyetlen újításnak az tűnik, hogy a szokásos git workflow helyett ad egy saját, egyedi, Microsoft és Github specifikus valamit - ez azért nem tűnik akkora bomba ötletnek.
De lehet csak a bemutatkozó oldaluk szar és nem jött át az ötlet nagyszerűsége. Amiket írnak, hát nekem mindegyik megoldott problémának tűnik. -
cucka
addikt
válasz
szata.68
#11877
üzenetére
Szerintem kár felhúzni magad. A kérdésedre olyan embertől kaptál választ, aki hasonló szoftverek fejlesztéséből él.
Ma Budapesten egy senior fejlesztő bérköltsége a havi másfél milliót karcolja, és erre jönnek rá a járulékos költségek (irodabérlés, adminisztráció stb). Jól látod, hogy a te helyzetedben egyedi szoftvert készíttetni az nem opció. Ezek a félmilliós meg másfél milliós költség becslések, amiket említesz, teljesen nevetségesek.
A másik - a felhős, havi díjas konstrukció igazából neked sem olyan rossz üzlet, mert tervezhető havi költséget kapsz, plusz ingyen backupot, nem kell aggódni, hogy mi lesz ha elromlik a számítógéped. (A fejlesztő cégnek meg tervezhető havi bevételt jelent, ezért nyomatják nagyon ezt a konstrukciót)
Egyébként a legtöbb ilyen felhős szoftver fel van készítve arra, hogy mi történik, ha nincs stabil internet kapcsolat. Ezt a szoftverek gyártóitól kell megkérdezned, hogy mennyire támogatják ezt a fajta helyzetet. Lehet, hogy el se indul a szoftver offline, de az is lehet, hogy elég neki, ha 2-3 naponta szinkronizál a felhővel. Úgy gondolom, neked ez lesz a fontos döntési szempont, kérdezz utána. -
cucka
addikt
válasz
Froclee
#11665
üzenetére
De egyikben sem számítgatsz semmit papíron, meg nem kell megtanulni könyvek tartalmát. Az egyetem erre készít fel.
A munka nagy része mindkettőnél libek meg toolok használata. Aki meg annyira jó matekből, hogy ezeket a libeket, toolokat fejleszti, annak p*csafüst a progmatos vagy mérnökös matek színvonala.
Az átlag programozó képzésre gondolok, ahol a végzősök zöme valamilyen üzleti szoftvert fog fejleszteni. Esetleg hardverközelben lesz és c-ben programozik mikrokontrollert. Egyikhez sem kell különösebb elméleti fizikai vagy matektudás szerintem.Nyilván ha különösen jó vagy matekből, fizikából vagy akár kémiából, akkor érdemes tanulni, mert kamatoztathatod később a tudást, minden piaci résben vannak cégek, akiknek szükségük van programozóra.
-
cucka
addikt
Ha a programozás érdekel, és ebből szeretnél karriert csinálni, akkor két dologra fókuszálj:
- Meg kell tanulni programozni rendesen. Programozási nyelvek, algoritmusok, adatszerkezetek. Csinálj hobbi projekteket és olvass sok szakirodalmat szabadidődben.
- Tanulj meg rendesen angolul, beszélni is. Az összes szakirodalom angolul van és a jobb munkahelyeken szóba sem állnak veled, ha nem tudsz angolul.Az ilyen matekes, fizikás tárgyak fölöslegesek, csak az egyetemeken, iskolákban a tanári gárda ehhez ért, úgyhogy ezzel szórják ki a diákokat.
Van egy olyan kifejezés, hogy domain tudás. Ez nagyon értékes és jól meg is fizetik. Ha pénzügyi projekten dolgozol, akkor ez pénzügyi ismeretek, ha repülőjegy foglalási rendszeren, akkor az ahhoz tartozó specifikus tudás, stb. Vannak ritka projektek, ahol matekes vagy fizikus tudás kell, de azért nem ez a jellemző. -
cucka
addikt
A kommunikációs skill nem azt jelenti, hogy extrovertált vagy, hanem:
- komplex dolgokat kell egyszerű, érthető módon megfogalmazni
- kell valamennyi empátia, a forráskódot nem a gépnek írod, hanem a következő fejlesztőnek. a napi munka során több idő tellik kód olvasással, mint írással
- csapatban dolgozol, napod nagy részét ugyanazon emberek társaságában töltöd, szóval ne legyél fasz -
cucka
addikt
Ez amúgy jó hír és jó irány. Valójában a cégek már versenyeznek, hogy bekerüljenek a jobb egyetemekre, nem úgy van az, hogy mindenkit tárt karokkal várnak, hogy jobb legyen a diákoknak
Amit én tapasztalok, hogy diplomás és nemdiplomás fejlesztők között is vannak jók és bénák. Egy fejlesztőnél soha nem a diplomán múlik, hogy behívják-e interjúra vagy sem.
Láttam már mesterdiplomás senior fejlesztőt aki kínlódott egy olyan feladattal, ami egy programozás 1. zh-n sem számítana nehéznek. -
#11631
cucka
addikt
PumpkinSeed
#11629
cucka
addikt
válasz
PumpkinSeed
#11629
üzenetére
Azt nem tudod mérni, hogy mennyire tud gyorsan tanulni, de az azért kiderül percek alatt, hogy vág-e az esze a jelöltnek vagy sem. Meg az is, hogy tud-e egyáltalán alapszinten programozni vagy sem.
A megoldás pedig az lenne, ha a programozó informatikus egyetemi képzésen a programozói szakmára készítenék fel a diákokat.
Mert jelenleg az van, hogy verik a mellüket az egyetemeken, hogy ők szemléletet meg szakmai alapokat tanítanak. Szerintem a programozói szakma alapja az hogy tudj programozni, tudj csapatban dolgozni, tudj felbontani bonyolult feladatokat egyszerűbb részfeladatokra, hasonlók. A magyar egyetemeken ezekből semmit nem tanítanak. Ott a matekkönyv, tanuld meg fejből, mert a vizsgán visszakérdezzük, hogy kiderítsük, elég jól megtanultad-e fejből. Az ilyen oktatási módszer egyetlen előnye, hogy minimális energia befektetést igényel az oktatóktól. -
#11628
cucka
addikt
PumpkinSeed
#11621
cucka
addikt
válasz
PumpkinSeed
#11621
üzenetére
Én azt tapasztalom, hogy az esetek többségében lóf*szt se számít, hogy van-e egy informatikus bsc diplomád vagy nincs. Kb. a legkevésbé fontos dolog amit az önéletrajzban nézni érdemes (kivéve ha valami menő képzés, egyetem)
Való igaz, hogy az egyetemen nem tanulnak meg rendesen programozni az emberek, de ez elég nagy baj szerintem. A fejlesztői állások többségéhez nem kell matek, ahova meg kell, oda úgyis az okosabbja megy aki meg bírja magától is tanulni.De érted, bejön a frissdiplomás versenyző junior programozó interjúra, akkor mit kérdezzek tőle, a taylor sorbafejtést? vagy számoltassak vele crc-t a whiteboardon?
-
cucka
addikt
válasz
bandi0000
#11622
üzenetére
Egy átlag multi (vagy olyan jellegű) cég azt, hogy
- tudj angolul folyékonyan beszélni
- tudj programozni, úgy általában véve. történt már olyan, hogy a senior fejlesztő tizenöt percet izzadt az interjún amíg megírt két for ciklust
- ismerd alapszinten a technológiát. csinálj egy hobbi projektet, ha nincs más. nyilván előtte találd ki, milyen technológia érdekel
- legyél már képben a szakirodammal. clean code, refactoring, olvass hacker newst, ilyesmi. mivel tudsz angolul, ez nem problémaamúgy egy csomó helyen olyat kérdeznek majd interjún, hogy járj be egy fát meg írj egy rekurziót. esetleg kapsz egy házi feladatot, hogy bizonyíts
-
cucka
addikt
Én két nyelvet tudok javasolni programozás tanulásához: Python és C.
Python azért, mert olyan, mint a pszeudokód, mentes a csomó fölösleges zajtól. Algoritmusokhoz és alapvető programozási ismeretek elsajátításához tök jó, mert nem vonja el a figyelmed a lényegről.
C azért, mert erősen típusos, fordítani kell és a te dolgod a memória kezelése. Ez értékes tapasztalat még akkor is, ha valamilyen magasabb szintű nyelvben fogsz a későbbiekben dolgozni. -
#7087
cucka
addikt
freelanced
#7086
cucka
addikt
válasz
freelanced
#7086
üzenetére
A szemléletmód megértése a lényeg. Annak semmi értelme, hogy bármit megtanulj kívülről, arra ott a doksi, ahol bármikor utánanézhetsz.
-
cucka
addikt
válasz
martonx
#7055
üzenetére
Nem realtime rendszereknél az erőforrásigény nagyjából senkit sem érdekel, annyira olcsó a hardver a programozói fizetésekhez képest. Előző hozzászólásban szóba jött a tízmilliós árú szerver, ugyanez a pénz Amerikában egy nem kezdő programozó 3-4 havi bérét fedezi. Gondolhatod, milyen erőfeszítéseket tehetnek ilyen bérszínvonal mellett, hogy megspóroljanak pár száz-ezer dollárt a szerver bekerülési költségein..
Java hoszting meg pont ugyanazért nincs, amiért .net hoszting sem: túl bonyolult ahhoz képest, hogy milyen vékony a célközönség. Aki nekiáll ezekben a technológiákban fejleszteni, az jellemzően nem egy kétpálcás shared hosting szolgáltatásban gondolkozik, hanem rendes saját szerverben, vagy cloudban.
-
cucka
addikt
Abstract factory helyett szerintem a sima factory is teljesen megfelelő.
A különböző szakköreidet könnyű hierarchiába rendezni, tehát öröklődéssel megoldhatod az egészet, nincs szükség absztrakt osztályokra.A factory-d meg lényegében egy függvény, ami Szakkör objektumokkal tér vissza, hogy pontosan milyen osztályúakkal, azt az ő dolga kitalálni a bemenő paraméterekből.
Esetleg csinálhatsz egy abstract factory-t, ahol a Szakkör osztályban lesz egy statikus függvény, ami saját maga példányaival tér vissza. Ezt megöröklik majd jól a leszármazottak is, tehát bármelyik szakkör osztályod fog tudni példányokat gyártani saját magából.
) akkor nem jó semmire.
.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Tesla topik
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Sorozatok
- Parci: Milyen mosógépet vegyek?
- Trollok komolyan
- Kikapcsolható lesz a PWM az iPhone 17 modelleken
- Kertészet, mezőgazdaság topik
- Kerékpárosok, bringások ide!
- exHWSW - Értünk mindenhez IS
- Nagyon bízik az Instinct MI450-ben az AMD alelnöke
- További aktív témák...
- GYÖNYÖRŰ iPhone 13 256GB Midnight - 1 ÉV GARANCIA - Kártyafüggetlen, MS2227
- Bomba ár! Dell Latitude E6320 - i5-2GEN I 4GB I 250GB I DVD I 13,3" HD I Cam I W10 I Garancia!
- Samsung Galaxy S23 Ultra // 512GB // Számla + Garancia //
- HP Zbook Fury 15 G8 mobil munkaállomás -i7-11800H / 32 GB RAM / RTX A2000
- AKCIÓ!!! Dell Latitude 5320 i3-1125G4 16GB 256GB magyarbill. 1 év garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest