Legfrissebb anyagok

IT café témák

PROHARDVER! témák

Mobilarena témák

GAMEPOD.hu témák

LOGOUT.hu témák

Keresés

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

#21 buherton őstag maga1 #20

Új Válasz 2023-12-02 17:53:27 #21
Ú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 maga1 #20 üzenetére

Egy moduláris nagysebességű mikrohullámú hálózati eszközről van szó. És ez még nem is a teljes SW volt, mert a radiot külön kezelték akkor.
Nem emlékszem már pontosan, de ha az emlékeim nem csalnak, akkor a modul, amiért feleltem az több, mint 10.000 soros volt.
Szerintem egy 20.000 soros kód nem sok. A fentebbi terméken több modult is elég jól ismertem, amik nagyobbak voltak az enyémnél.

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... !!!
#19 buherton őstag UnA #17

Új Válasz 2023-12-02 15:30:01 #19
Ú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 UnA #17 üzenetére

Ismerd meg a go-t . A go végtelenül egyszerűvé tette a build és az a körüli dolgokat. Egy kis dolgokra abszolút rendben van, de amikor új és nagy terméket indítanak pythonban, azt maximum csak úgy tudom megérteni, ha ML-es projektről van szó, vagy az ott dolgozó emberek python only világképűek.
Egyetértek, a vim szerintem is az ördög műve . Emacs rlz.

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... !!!
#15 buherton őstag Mr Dini #13

Új Válasz 2023-12-01 13:09:51 #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... !!!
#12 buherton őstag buherton #11

Új Válasz 2023-12-01 09:10:40 #12
Ú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 buherton #11 üzenetére

Jah, igen és a vscode. Nagyon-nagyon jó IDE, de a fenéért kell felzabálnia a gép erőforrásait?! Erősen javaslom a váltást emacs-ra vagy vim-re. Ezek a kávédarálón is elfutnak és nagyon jó feature paritást lehet elérni.

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... !!!
#11 buherton őstag

Új Válasz 2023-12-01 09:00:34 #11
Ú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

Olyan nézőpontból állsz a problémákhoz, amire nagyon kevesen képesek. Nagyon-nagyon kevesen. Az pedig a ráadás, hogy olyan hozzáállásod van a feladathoz, ami szintén keveseknek van. Ha magadévá tudnád tenni a harmadik területet is, hogy hogyan menedzseld magad, akkor évi 100k+ EUR-s helyekre pályázhatnál. És tipikusan, akik az első kettőben jók, ők a harmadikban nem szoktak azok lenni.
10+ éve vagyok a programozói szakmában, mint villamosmérnök (nem is tartom magam programozónak). Sok interjún vagyok túl és sok embert interjúztattam már, illetve sok kollegám is volt már. Úgy gondolom, hogy jó emberismerő vagyok és ki tudom szúrni a tehetségeket, akikkel öröm együtt dolgozni. És itt nem arra gondolok, hogy majd ő megcsinál mindent más helyett, hanem arra, hogy valakivel együtt lehet előre menni.
Egyébként pedig abszolút áttudom érezni, amin keresztül mentél. Voltam a középiskolában szervezett Németországról szóló versenyen, ahol 4 fős csapatok indultak, én pedig egyedül. Második lettem. Egyetem alatt a menedzsment c. tárgyra készült beadandóra 4 fős csapatok álltak össze, egyedül csináltam meg. A munkahelyeken is jellemzően egyedül maradtam a problémákra. Az egyik munkahelyemen beneveztek a Software Architect képzésre, ahol csapatban kellett a munkánk mellett egy saját projekten dolgozni. Gyakorlatilag ott is egyedül maradtam . Oké, azt nem én találtam ki, hanem egy srác a csapatból, hogy a pythonos game engine-t használjuk és bár az elméleti alkalmazást sem tudtam, amikor elmagyarázta, akkor csak én dolgoztam rajta és az jól működött. Amikor a pathfindigos részt olvastam, nekem rögtön a Dijkstra jutott az eszembe. Volt egy jó időszak, amikor összekerültem egy igazi programozóval, aki nagyon penge volt és ketten kiegészítettük egymást. Amit akkor csináltunk közösen az baromi jó volt.
Továbbra is tartom magam a korábbi kijelentésemhez: [link]
------------
Személy szerint, nagyon-nagyon nem szeretem a python-t, de úgy általában az interpretált nyelveket sem. A szükséges minimumra törekszem a munkám során. Értem, hogy miért lehet jó a python, de engem sokkal inkább aggaszt az, hogy túl sokat kellene tanulni ahhoz, hogy valamennyire biztonságos kódot írhassak. Ez a gondolatom jellemzően igaz a többi nyelvre is. A C++-ra is kifejezetten haragszom. A C++20 standard kiadás előtt itt volt Magyarországon Bjarne és elmondta, hogy mi lesz a standardben. Nekem igazából csak egy kérdés volt a végén, amit nem mertem megkérdezni, hogy "maradt még olyan speciális karakter a billentyűzeten, amit nem használ már a nyelv?". Egyébként kb 10 évig C-ztem és utána váltottam go-ra. Nekem nagyon tetszik a go, valószínűleg azért, mert a Google-nél mérnökök dolgoznak és csináltak maguknak egy olyan nyelvet, amit mérnöki szemlélettel dolgoztak ki.
hogy pl több szálon akarnék egy map-be egyszerre írni
[sync.Map] ha nem akarod wrappelni a sima map-t, mert mondjuk nincs idő ilyenekkel foglalkozni.
a kész bináris simán lehet 10+ MB, mivel semmi optimalizációt nem csinál a fordító
Igen, a go binárisok nagyok, de nem a fordító miatt, hanem azért ahogy a go oldotta meg a library kezelést. A go bináris csak annyi shared libraryre dependál, ami a minimum ahhoz, hogy futni tudjon. Linux az ldd mutatja be ezt jól. E helyett minden statikus lib, amit a linker fog egy binárisba szerkeszteni. Emiatt nagyok a binárisok, illetve amiatt is, mert a linkerek nem nyúlnak bele a fordított kódba (a linker igazából nem más mint egy symbol matcher) és így ha csak egy symbol is használva van a statikus libből, akkor húzza az egészet. Ezzel a szemlélettel a go teljesen szembe megy a C/C++-os világgal, ahol a shared library-s megoldás a preferált. Viszont így lehet az is, hogy a Linuxra fordított bináris standalone az összes disztrón fut.
Az alábbi kód maximum a szerencsének köszönhetően menti el a fájlt. Ez egy wait groupért kiált, de szerintem nem érdemes goroutinesítani a mentést.
func main() { ... go SaveImage(response.MapImagePng) }

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... !!!