2. Fórumok
  3. LOGOUT reakciók
  4. 24 órán keresztül programoztam
Keresés

Új hozzászólás Aktív témák

  • #22 Arphox tag Mr Dini #1
    Új Válasz #22
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Arphox

    tag

    válasz Mr Dini #1 üzenetére

    Köszönöm a kiváló bejegyzést, és gratulálok az eredményhez!
    Büszke vagyok Rád, és arra, hogy az ismerőseim között tudhatlak. Ha ügyesen menedzseled magad, nagyon messze eljuthatsz karrierben. :) Sok sikert!

    A konfigomat lásd az adatlapomon.

  • #15 buherton őstag Mr Dini #13
    Új Válasz #15
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    buherton

    őstag

    válasz Mr Dini #13 üzenetére

    A Rust eddig teljesen kimaradt az életemből. Azon kívül, hogy gyorsaságban a C-vel veteszik, tudtommal a Linux is nyitott rá és hogy jól kezeli a memory leak veszélyes helyzeteket, nem tudok semmit. Se szintaktika, se principle, semmit se.

    Azt nyugodtan ki lehet jelenti, hogy az OOP elavult lett (a Java-val együtt, csak hogy borzoljam a kedélyeket). Pontosan én is így gondolom: [The Flaws of Inheritance]. A go nem is támogatja az OOP-t.

    Az volt az elvárásom, hogy az fmt egyetlen függvénye miatt bekerül a binárisba az fmt összes szimbóluma. A szemléltetés kedvéért nem strippeltem a kész binárist. Ghidrában megtekintve az eredményt, jól látható, hogy rosszul tudtam:

    Most már erősen a tudásom határán mozgok, de szerintem a Decompile ablak csak annyit mond, hogy az egyes sor milyen symbolt használ. A bal oldali ablak meg "csak" annyit, hogy az fmt-ben milyen symbolok vannak. Az hogy a linker mit fog a binárisba tenni az egy harmadik kérdés. Szerintem egyébként a teljes static libet. Közben megnéztem és a symbolokat a go tool nm-al lehet kilistázni. A binárisban benne van az összes fmt symbol vagyis a teljes static lib bekerül. A lényegen egyébként nem változtat, hogy a go binárisok nagyok.

    Még egy picit a Rust vs Go-nál maradva. Amennyire tudom a Rust a zászlajára tűzte a performanciát és e köré épített fel mindent: a principle, memória menedzsment, build, stb. És ez így van jól, mert sok helyen nem engedhető meg, hogy pl. garbage collector fusson a háttérben. Addig a go más megközelítést alkalmazott: [Miért és mikor érdemes Go-ban programozni? - Szabó Dávid (LeanNet)] abszolút egyetértek a meglátásaival. Ez persze nem jelenti, hogy a go-ban ne figyeltek volna a performanciára, mert a goroutine önmagában megtestesíti ezt. És a garbage collector is elég penge lett: [Go versus Rust fastest performance]. De pl. a bináris mérete már nem erről árulkodik. Egyébként a _teljes_ footprintet nézve ide a rozsdás bökőt, hogy a go még ígyis odaver a Java, C#, Python és társaiknak. Az pedig a non plusz ultra, hogy a dockerimage készítés álom egyszerű a go-val. A cross compiling is egyszerű. A legutóbbi nagy go-s feature az volt, hogy most már a binárisok az utolsó bitig reprodukálhatóak. Szóval egy adott kódra a go 10 év múlva, sok verzió után is bitre ugyanazt a binárist fogja generálni. Most fejezem be a go "dicsőítést", mert itt ragadok még egy darabig. Még annyit (reflektálva a buildre), hogy a rengeteg makefile és CMake (több millió soros C/C++ projektet írtam át Makefileról CMakere, de úgy hogy a projektnek több féle Linux disztrón, többféle CPU archictectúrán (armle/be/64, ppc, x86) kellett futnia. Külön production és unit teszt kód. Kellett binárisokat, shared és static libeket, sima 3pp-ket, framework 3pp-ket, kernel modulokat, illetve magát a kernelt is fordítani) után álom az, hogy a go-ban a build annyi, hogy go build.

    Volt kollégám aki C++ phd hallgató volt és olyan csuda kódot írt, hogy a csapatból senki nem értette, hogyan működik, amit írt. Ez pedig szerintem abszolút a nyelvhibája, hogy ilyet megenged. A csuda kód alatt nem valami alattomosan kesze-kuszán írt kódot kell érteni, hanem olyat, ami kihasználja a nyelv featureit. Talán egy jó példa, hogy a C++ template magicre külön kb 1000 oldalas könyvet írtak. WTF?! Ki az aki ezt elolvassa és végül használja?! És a template magic csak egy a sok C++ featurei közül.

    Humor ON:
    A Rust-ról ennyit tudok: [Interview with Senior Rust Developer in 2023]
    Ez pedig jól mutatja be az emacs-t: [Interview with an Emacs Enthusiast in 2023 [Colorized]] (btw, nagy emacs fan vagyok)

    (#14) Mr Dini: a vscode tényleg jó. Amikor vacilláltam, hogy milyen toolt használjak és akkoriban lett volna vscode, akkor könnyen lehet, hogy ott kötök ki én is.

    Úgy gondolom, hogy a vim és az emacs egy kutya csak más a megközelítést használtak. Teljesen mást: [Editor war].

    Szerintem bold claim a részedről, hogy nem tartod magad programozónak. A megnyilvánulásaid alapján nekem az jön le, hogy mélyebben tisztában vagy a dolgok mikéntjével

    Szerintem ez egy fontos önismeret, hogy valaki tudja magáról, hogy kicsoda. Persze azt fontos leszögezni, hogy ez nem mérvadója a tudásnak, hanem inkább a gondolkodást írja le, hogy hogyan áll hozzá a problémához.

    [ Szerkesztve ]

    tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

  • #10 lajosdani2 csendes tag Mr Dini #8
    Új Válasz #10
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    lajosdani2

    csendes tag

    válasz Mr Dini #8 üzenetére

    Azt hiszem 3 óra volt az első részre, és 3 a másodikra is. Közben volt ebédszünet is - nagyon jól voltunk tartva :)

  • #9 lajosdani2 csendes tag Mr Dini #8
    Új Válasz #9
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    lajosdani2

    csendes tag

    válasz Mr Dini #8 üzenetére

    Ha jól emlékszem - mert ennek már jó 5 éve - az algoritmus annyi volt, hogy figyelje az útpálya színét.
    Ugyanis a pálya egy nagy fehér papír volt, amire rajzoltak egy színes pályát.
    Kék volt a normál út, piros volt az akadály, és sárga körök voltak a pályán két helyen, ezeken a körvonalakon ha végigment a robot, akkor az pluszpontot ért.
    Amíg kék pályát látott maga alatt a színszenzor, addig menjen egyenesen.
    Ha letér jobbra vagy balra, akkor a kék ugye átmegy lassan fehérbe (a pálya alapszíne), ekkor korrigáljon vissza 3 fokot.
    Ha pedig elért a más színekhez, akkor az akadályt kerülje ki egyik oldalról. A sárgán menjen végig, amíg újra kéket nem talál.
    Tehát az egész szabály a színekre épült.
    Volt még távolságszenzor is, mert a pálya szélén volt egy fal emelve. Ha ezt megközelíti, akkor a távszenzor jelez, és visszaküldjük ellenkező irányba - 180 fok fordulás.

    Nagy vonalakban ennyire emlékszem, de tényleg nagyon ötletes és jó kis verseny volt :)
    Azt hiszem az OTP rendezte az EcoSim-mel közösen, és a győztes csapat állásinterjúra is mehetett a bankhoz.

  • #2 sonar addikt Mr Dini #1
    Új Válasz #2
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    sonar

    addikt

    LOGOUT blog

    válasz Mr Dini #1 üzenetére

    :R Good Job!

    A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

Új hozzászólás Aktív témák