- Kirakatba tette a Google a Pixel 10-eket
- Itt egy pár fotó az iPhone 17 sorozatról
- Profi stratégiára vált a Galaxy S26
- Huawei Mate 9 - Mate evangéliuma
- Samsung Galaxy A56 - megbízható középszerűség
- Kikristályosodik a Razr 60
- Bemutatkozott a Poco X7 és X7 Pro
- Huawei Watch Fit 3 - zöldalma
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Fotók, videók mobillal
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
Drizzt
nagyúr
Elolvasva ezt a kommentedet olyan érzésem van, hogy vagy te olvastál egy másik könyvet, vagy én. De persze nehéz megmondani, mert valójában amikor erről beszél az ember valakivel, akkor nem szimplán a könyvben elhangzó dolgok vannak benne, hanem az azzal összefüggésben máshol olvasottak is. Én az általad leírt dolgok egy részére határozottan nem ebben a formában emlékszem. Én biztosan elég régen olvastam, olyan 7 éve kb. Viszont vannak újabb könyvei is, lehet az azokban leírt pontosítások miatt emlékszem máshogy már a korábbi könyveire is.
Az viszont nagyon gykori, hogy a könyvben leírtakat félreérti, félremagyarázza valaki és ebben a formában erölteti. Az valóban káros tud lenni.
Én például a DRY-nál úgy emlékszem, hogy benne volt a könyvben, hogy olyan esetekben kell csak kiemelni a közös dolgokat, amikor azok nagyon nagy valószínűséggel együtt fognak változni a jövőben is. Valamiért dereng, hogy a dry kapcsán is előjön a yagni, de lehet ezt már megint csak a minden egyéb olvasmányaim miatt hozza elő most az agyam.
Szerintem a clean architecture könyv ami későbbi is nagyon jó, bár azt kell mondjam, hogy clean architecture/hexagonal architecture kapcsán amiket olvastam, a legtöbbször az a gond, hogy nem elég gyakorlatias a dolog. Pedig néhány praktikus megoldás végiggondolása nélkül az elmélet erőltetése elég szarul tud elsülni.
Van egyébként functional programming könyve is, de azt nem olvastam még.
Alapvetően a közepes programozók rossz megoldásai azért vannak, mert eleve nem képesek a kritikus gondolkodásra, meg a kontextusban értelmezésre. Tök mindegy, hogy mit olvasnak, a végeredmény az lesz, hogy közepes programozók maradnak. Biztos vagyok, hogy vannak olyan könyvek amiket elolvasva ettől sokkal nagyobb hülyeségeket is csinálnának.Engem elsősorban a refactoring for the sake of refactoring jellegű akciók zavarnak, de ez megint nem a könyvek hibája, hanem az azokat értelmezni képtelen embereké.
-
Drizzt
nagyúr
válasz
Vision
#20319
üzenetére
"Arról nem beszélve, hogy tipikusan kész komponenseket reciklálnak."
Mintha backenden nem ugyanez lenne.![;]](//cdn.rios.hu/dl/s/v1.gif)
Tok mindegy, van komplex feladat boven UI es Backend oldalon is. Aki viszont barmikor amikor nem muszaj ujrafeltalalja a kereket, az minden teruleten sulyos gond. Kiveve ha eppen tanul, de annak meg nem a munkahely a megfelelo terulete.
Algoritmust irni meg szerintem nagyon ritka mind backend, mint frontend oldalon. Felhasznalni mas altal megirt algoritmusokat: az nagyon gyakori. Bar en valoszinuleg az algoritmus iras alatt foleg az adatstrukturak implementalasat ertem. Az esetek 99.99%-aban a megfelelot kell kivalasztani a problemahoz es azt felhasznalni. Tehat nekem az, hogy egy Map, lista, etc. elemein csinalok valamit, vagy irok egy SQL query-t, az nem algoritmus iras, hanem algoritmus hasznalat. De lehet nem igy kene hasznalnom ezt a kifejezest. -
Drizzt
nagyúr
Ebben a formában ez a kérdés nehezen értelmezhető.
Vannak a queue-ek.
Ezekben tetszőleges időpontokban írnak valakik, nevezzük most őket publishereknek, esetleg producereknek. Ettől teljesen független időközönként akiket érdeklik az üzenetek a queue-kből, azok feliratkoznak és saját tempoban, tetszőleges időnként kiolvassák őket. Nevezzük őket subscribereknek, esetleg consumereknek.
Mind az írók, mind az olvasók lehetnek sokan és nem is tudnak általában egymás létezéséről egyáltalán. -
Drizzt
nagyúr
Nem szokas. Mi tortenik, ha a rabbitmq tobbi feliratkozoja esetleg hamarabb megkapja az uzenetet, mint ahogy az bekerul a db-be(pl. A d-ben csak percekkel kesobb van ott)? Vagy mi tortenik akkor, ha nincs uzenet valamirol, de a db-ben mar ott van? Ezek megvalaszolasa menten lehet kitalalni, hogy mit erdemes csinalni.
-
Drizzt
nagyúr
-
Drizzt
nagyúr
-
Drizzt
nagyúr
Siman megeri akkor is programozast tanulni, ha csak 1-2 evtizedig a jovojet megalapozni akarja az ember. Nem mennek ritkasagszamba azok a sztorik, hogy valaki nyomta 10-15 evig, aztan megcsinalta belole a pekseget, bisztrojat, vallalkozasat, fene se tudja mijet. Persze garancia nincs ra, hogy kesobb nem ter vissza.
-
Drizzt
nagyúr
válasz
Alcsi69
#19313
üzenetére
Igen, tobbe-kevesbe.
A tobbe az az, hogyha konkretan mentoring jelleggel elbeszelgetnek veled, csinalnak epito jellegu code review-t a munkadhoz, stb. De osszessegeben a sajat fejlodesedert mindig te leszel az, aki a legtobbet tud tenni. Barmikor leakaszthatsz egy konyvet a polcrol, vagy egy training videot, amibol mar annyi van, mint csillag az egen.
Azert legalabb annyi tamogatas szokott lenni, hogy fizetos oktato tartalmakhoz hozzaferj ingyen. Es ez nagyon hasznos tud lenni. -
Drizzt
nagyúr
Horizontálisról inkább nem beszélek, mert a gyakorlatban - főleg autoscaling-gel - nem használtam.
Horizontális skálázásról viszont tudok valós tapasztalatból beszélni.
"Azt mondja az elmélet, hogy röptében még node-okat kér az alkalmazás a szolgáltatótól. Tuti, azt megkaphatja. Nem mintha röptében telepíteni egy OS-t, be-config-olni, üzembe állítani két pillanat lenne, de pár perc alatt meg tudhat éppen történni." OS-t nem kell se telepíteni, se konfigolni. Kiindulási állapotban van 1 master és x worker node-od. Ezeken már fut az operációs rendszer. Az alkalmazások OCI szabványú containerek szoktak lenni, tehát igen gyors tud lenni az elindításuk, illetve többféle container runtime is el tudja indítani őket. Amikor definiálsz egy deploymentet, meg tudod adni, hogy mennyi replikát szeretnél futtatni az adott alkalmazáskor. Pl. azt mondod, hogy van egy alkalmazásod, amiből szeretnél 3 példányt futtatni és mindegyik egyenként 1 CPU-t és 1GB memóriát igényel. Ekkor a Kubernetes meg fogja nézni, hogy melyik node-okon van ilyen szabad erőforrás és oda fogja allokálni őket. Onnantól, hogy elindultak ezek a példányok, egy helyben maradnak. Ez a manuális horizontális skálázás. Menet közben megváltoztathatod a replika számot. Ha pl. 3-ról 4-re emeled, akkor elkezdi elindítani a negyedik containert. Amikor az feléled, akkor update-eli a routing-ot, hogy tudjon róla, hogy 4 helyen érhető el éppen az alkalmazás.
Autoskálázás: mindenféle metrikák és threshold-ok alapján megmondhatod, ha több, vagy kevesebb replika tűnik szükségesnek. Gyakorlati tapasztalatom nincsen vele.
"És biztos létezik olyan alkalmazás típus (mondjuk hang vagy video kodek, ahol egy csomag bejön, egy csomag kimegy, és teljesen előzetes történetmentes jellegű az alkalmazás üzemelése), amit lehet dinamikusan bővíteni, de a legtöbb eset nem olyan. Sőt, mondjuk az esetek 99%-a nem olyan. Vagy megfeledkeztem volna valamiről?"
Igen. Az ilyen környezetben futtatható alkalmazásokat olyanra is kell tervezni. Fontos fogalmak: stateless application, cloud native, 12 factor app.
Stateful alkalmazásokat is lehet futtatni, de általában azokat inkább érdemes valamilyen dedikált - nem kubernetes - környezetben futtatni.Szerintem teljesen felesleges technikai leírást nézni, mert nem fogod érteni elsőre. Ezt nem személyeskedésnek szánom, mindenkinek ezt mondanám elsőre.
Sokkal jobb út végigcsinálni a [hivatalos tutorialt]. Eléggé gyorsan el fogsz tudni addig jutni, hogy kipróbál a manuális skálázást a gyakorlatban. Fel kell hozzá rakni egy Rancher desktopot, vagy egy minikube-ot a gépedre(tehát gyakorlatilag egy kubernetes clustert tudsz futtatni a saját gépeden). Egyébként részletes technikai leírásnak is remek kiindulópont a kubernetes.io. -
Drizzt
nagyúr
Jó, hogy előjött a WoW. Kitalálnád melyik nyelven írták a game engine-et? Ha esetleg azt gondolod, hogy abban a nyelvben nem kezdenek már új projekteket, akkor nézd meg esetleg az egy hete elkészült Diablo 4 engine-jét miben írták. Esetleg még a Blizzard karrier oldalát is nézd meg, miféle tapasztalatú fejlesztőket keresnek, még nem leleplezett új projektekre is.
-
Drizzt
nagyúr
Nekem az az erdekem, hogy ertelmes diskurzus legyen itt, aminek resze az, hogy tenyeket irunk, nem sajat prekoncepciokkal dobalozunk.
Az, hogy tenyismeretek nelkul erzelmi alapon nyelveket szidunk, nem segit senkinek.
"C++-ban ma már senki sem kezd el új projectet."
Ilyen pillanatok alatt cafolhato mondatokat semmi ertelme nincs irni. -
Drizzt
nagyúr
Neha tenyleg felmerul bennem, hogy trollokodsz-e ezekkel az irasokkal.
C-t hasznalnak nagyon sokan, akik beagyazott szoftvert fejlesztenek. Ez a default choice ilyen projekteknel. Nyilvan nem az egyetlen lehetoseg, de foleg ehhez letezik a tapasztalat, meg a boseges toolkit. Azt, hogy valami esetleg ezt a korabbi hegemoniat veszelyezteti-e, nem tudom megmondani, mert beagyazott szoftvert lassan 10 eve nem fejlesztettem.
C++ programnyelvbol is folyamatosan jonnek az uj release-ek, nagyon valoszerutlennek tunne, hogy ne hasznalnak uj valtozatos projektekhez. Ugyanakkor magaval a nyelvvel ervelni nem tudok, mert szinten jo 10 eve nem nyultam C++ programhoz. Multkor viszont orommel lattam egy Stroustrup eloadason, hogy ez a nyelv is folyamatosan fejlodik. Olyannyira, hogy az uj nyelvi elemek egy reszet nem is tudtam azonnal megerteni, mert epitett az elmult release-ekben bevezetett valtozasokhoz.
Egyebkent ugyanez az elmenyem a Java-val is megvolt, egyetem utan erdemben majd 10 evig nem hasznaltam, ki is alakult bennem egy eros ellenerzes. Aztan amikor ujra kellett hasznalni, akkor dobbentem ra, hogy milyen brutalis fejlodesen ment at mind a programnyelv, mind az okoszisztema.
Nem a Linux kernelt hoztam fel peldanak, hanem egy szoftvert, amit fejlesztettunk. Bar egy szoftvernek nevezni talan nem tul szerencses, hiszen jopar kulonallo image keletkezett a forraskodbol. Valoszinuleg a kod egy jelentos resze modularizalhato lett volna. Dokumentaltsaga valtozo szinvonalu volt, a nincs-tol a teljesen at terjedo skalan. Volt magaban a kodban operacios rendszer is, de nem valaminek a szemelyre szabasa, hanem celhardverre nullarol irt operacios rendszer C nyelven. De az csak egy elenyeszo resze volt, amit nyilvan erdemes lett volna kulon repo-ba szervezni. Sajnos ez soha nem tortent meg. Amiert megis egy repo maradt az egesz, az az, hogy egy jol iranyzott make-et lefuttatva es par orat varakozva kiesett par image, amit az adott celhardver(ek)re lehetett telepiteni. Lehetett volna ertelmesebben a kodot kisebb repository-kba? Igen. Lett volna ettol fuggetlenul GB meretu a legkisebb kod repo? Talan igen, talan nem. Nagysagrendileg nem lett volna kisebb. -
Drizzt
nagyúr
Es ha ezek az erveid a C++ ellen, akkor a C ellen miert nem? Vagy barmelyik masik nyelv ellen miert nem? En dolgoztam gigabyte feletti C kodon. Eselye nem volt senkinek atlatni az egeszet, bar en meg a legjobbak koze tartoztam. Es tokre elveztem amugy. Persze nyilvan ma mar jobb helyeken nem ugy szervezik a kodot, mint akkor es ott, de peldatlan eros keszsegem lett a tajekozodashoz ismeretlen terepen. Szoval egy picit sem banom es nagyon hasznos tapasztalatnak gondolom.
-
Drizzt
nagyúr
Clean/onion/hexagonal architecture tervezés szempontjából valamiféle tutorial/wlak through video van esetleg valós projekt kapcsán? Valami kifejezetten hosszabb, alaposabb dolog érdekelne. Könyvek tekintetében alaposan ki vagyok művelve, de vannak olyan részek, amiknél jó lenne látni tervezési megfontolásait másnak. Pl. hogyan ússza meg az ember, hogy szivárgó absztrakciókat határozzon meg. Érdemes-e ugyanazokat a domain entity-ket különféle struktúrával reprezentálni különféle use case-ekben, etc.
-
Drizzt
nagyúr
Wireshark, vagy hasonlo tool is azt mondja, hogy biztosan 2 kulon UDP packet received, vagy a kuldo oldalon sent? En is nagyon meglepodnek, ha 2 kulon kuldott csomag egyben erkzene meg. Milyen lib-eket hasznalsz a kuldesre es a fogadasra? Az o dokumentaciojuk mit mond arrol, hogy hogyan kezel buffereket?
-
Drizzt
nagyúr
Mit ertesz egybe ragasztas alatt? Egy kuldo ket kulon UDP csomagot kuld, aminek ket kulonallo header-je van? Es ezt amikor megkapja a vevo, akkor ugy nez ki, mintha egy csomag jott volna be, egy tok uj headerrel, es a kuldott data-k konkatenalasaval? Milyen receiver-rol beszelunk es miert zavar, hogy igy kapja meg? Feltetelezem azert, mert te tole kapod meg az adatot. Biztos, hogy nem maga a kuldo rakta mar ossze egy csomagba elkuldes elott?
-
Drizzt
nagyúr
válasz
ValGerald
#18456
üzenetére
És az miért baj? Amióta van professzionális Java programozás, azóta nem nagyon volt olyan év, amikor ne tartozott volna a 3 legjobban fizetett nyelv közé(, a 2-t is meg merem talán kockáztatni). Mellesleg Java-val dolgozni nagyon jó, a nyelv kötöttségei miatt nagyon könnyű például automatizáltan refaktorálni, nagyon könnyű megbízható kódot írni vele. Az ökoszisztémájával meg nem igazán tud felérni semmi. Végtelen agyonhasznált és bizonyított futtatókörnyezet, library és framework van hozzá és hasonló mértékben fejlődnek is, meg keletkeznek teljesen újak. Közben maga a nyelv is egyre gyorsabban fejlődik, gyakran más nyelvekben kipróbált és bevált újdonságokat beemelve.
De bevallom én is utáltam a Javat amikor egyetemen tanultam, kb. J2SE 1.2-t, ráadásul az akkoriban még igencsak kezdetleges Eclipse-szel. De ugyanezt már egy JDK8 + IntelliJ-re cserélve is kb. mintha űrhajóba raknák az embert. Ami meg azért létezik már szintén majd 1 évtizede. -
Drizzt
nagyúr
"Vagy inkább csak a pancser fejlesztőik. Ahol szenzor adatokat tárolnak, normális design gyárt belőle sorfolytonos adat stream-et valami helyi flash-en, amit távoli állomás időszakosan átolvas, feldolgoz, mindenféle statisztikát gyárt belőle, és már csak a kész statisztikát tolja fel adatbázisba. Az a statisztika egyszer kap felírást, és életciklusa során vagy milliószor olvasást."
Ertem. Egy dolgot mondj akkor meg legyszives! Mit csinalsz abban az esetben, ha kiderul, hogy a statisztika gyarto fuggvenyben van egy bug, ami miatt a fel evvel ezelotti osszes adatot ujra kellene szamolni? A helyi flash meg mar azota 15-szor ujra lett irva uj adatokkal. Honnan lesz meg az adat, amibol kiszamoltad a rossz statisztikat, hogy ujraszamold helyesen?
De mondjunk egy meg egyszerubb forgatokonyvet: kellene uj statisztika az eszkozok altal begyujtheto adatbol, 5 evre visszamenoleg. Mostantol, eddig nem kellett. Viszont ugyanazokbol az adatokbol, amiket eddig is gyujtott az eszkoz.
Mit csinalsz? Tegyuk fel, hogy az adatok nagy frekvenciaval keletkeznek, a flash merete meg korlatos, mondjuk 1-2 napi adat fer el rajta maximum.[Nagyobb google kiesesek]
[Facebook: ez nem volt olyan regen, gyarkolatilag napokig hasznalhatatlan volt a felhasznalok tobbsegenek(bar hivatalosan 6 ora utan helyre lett allitva)] -
Drizzt
nagyúr
válasz
KubanitoS
#18275
üzenetére
"A fentiek nem elhanyagolható szempontok egy valóban kezdőnek. Ha most nekifognék ilyen-olyan ingyenes netes képzéseket (Codeacademy, W3 stb) csinálni, akkor mégis mit írjak az önéletrajzba? Hogy xy weboldalon szépen végigkattintgattam a képzést? Hülyének fognak nézni..."
Ha relevansak a korabbi tanulmanyaid, akkor azokat. Ezen kivul erdemes lenne csinalni referencia projekteket. Azokat githubra, vagy hasonlo helyre rakni, arra hivatkozast berakni az oneletrajzba. Eleve ugy erdemes csinalni ezeket a kepzeseket, hogy ki is probalod kozben, foleg az elejen. A full ingyenes dolgokkal nem tudom meddig lehet eljutni, de par szaz dollarert biztos lehet olyan trainingeket venni, amibol ossze lehet pakolni eleg modern, elterjedt dolgokat.
Ettol fuggetlenul ha van penz, ido, akarat, akkor erdemes lehet menni bootcampre, akiket ismerek, hogy elkezdtek, mindegyikuk programozokent dolgozik azota is. Kiveve egy valakit, aki kibukott, de aztan valahogy security-s lett belole, az meg megy neki.
Bar a napokban lattam cikkeket, hogy erosen felhigult a bootcamp piac. Ilyenkor gondolom vegkepp a bejaratottak kozul lehet erdemes valasztani valamit. -
Drizzt
nagyúr
Elsőre a Redis pubsub channel-nél arra jöttem rá, hogy nekem nem lenne ideális, mert én akkor is szeretném tárolni az üzeneteket, ha valaki offline. De úgy látom a Redis Stream-szel ez is megoldható, bár a last read message ID nincs karbantartva subscriberenként, mint a Kafkanal. De ez nem egy tragédia.
NATSt még ennyire sem ismerem, de utánanézek. -
Drizzt
nagyúr
SSE: Server sent events. Gyakorlatilag a böngésző indít egy kapcsolatot a szerverrel, amin keresztül aztán a szerver tud kezdeményezni küldést. Tehát alapvetően éppen bejelentkezett embernek üzenet küldésére szolgál.
Pl. elkezdesz megnyitni egy számlát. Kapsz egy azonnali visszajelzést, hogy oké, elkedztük a számlád megnyitását. De a számla megnyitása bonyolult folyamat, ami mondjuk két perc átlagban. Ilyenkor SSE-vel tudsz üzenetet küldeni az embernek, ha még éppen online van, hogy hahó, el is készült a számlád.
A másikról nem jól érted. Az a lényeg, hogy szeretnék 100e csatornát. Az egyes csatornákban elég kevés üzenet lenne, gyakran semmi. Ha valaki akar küldeni üzenetet, akkor az tudja a csatorna nevét, oda elküldi az üzenetet. Ha meg valaki olvasni akar üzenetet, akkor a csatorna nevét ismerve feliratkozik. Amikor valaki küld a csatornára üzenetet, akkor a feliratkozó kap értesítést. Feliratkozni a szerver iratkozna fel, amikor egy böngészőn keresztül a user SSE kapcsolatot épít ki nála. Ha kap értesítést a csatornáról, akkor az üzenetet tovább küldené SSE-n. -
Drizzt
nagyúr
Lazán kapcsolódó.
Van-e olyan framework készen, amit lehetne SSE-hez úgy használni, hogy minden embernek csinálni egy topicot, aztán arra subscribe, ha megjön az SSE connection, az üzenetküldők meg publisholnák a cél ember topicjába az üzeneteket? Minden ember 100e-es nagyságrendet értve. Szóval van-e olyan pubsub, ami nem kezd el kétségbeesni 100e topictól? -
Drizzt
nagyúr
Space and time az az asymptotic.
Essentialt meg meg intrinsicnek is szokas szinten nevezni.Btw. en olyan helyen dolgozom, ahol tovabbra sincs code review. Es az elejen majdnem sokkot kaptam ettol az informaciotol, de tovabbra is ugy latszik, hogy megis mukodik. Nagyon ritka a nagy sev/prio bug. Hogy meg furabb legyen a helyzet, van jopar microservice, aminek jelenleg 0 a test coverage. Bar a test coverage eleve nem mond sokat. Ha nagyon merni kell automatizaltan a teszt josagat, akkor mutation testinget lehet csinalni, de az altalaban tul sokat dob a tesztek futasi idejen. Lehet azert mukodik ez nalunk, mert a median tapasztalat 10 ev korul van, 10 fo alatti csapatnal.
Most van ilyen celunk, hogy legyen minden birtokolt modulon legalabb 80% lefedettseg, igy tudom edzeni a Mockito kepessegeimet. :D Kezdek atszokni a unit testekre a Spring integration tesztek helyett. Mar az Application context elidulasanak az idoigenye is zavar. :D De persze vannak dolgok, amiket ertelmesen unit tesztelni "nehez". Pl. Repository-k perverz sql-lel, Controllerek access controllal.
-
Drizzt
nagyúr
válasz
FeniX-
#17889
üzenetére
Egyszeru a helyzet latszolag, megvalositani annal nehezebb, ha nincs az ember hozzaszokva: meg kell tanulni nemet mondani. Talan ott kezdodik az egesz, hogy egyaltalan miert reagal az ilyen jellegu megkeresesekre. Ha beleirja a szerzodesbe, hogy milyen formaban lehet megkeresni, milyen keretek kozott, akkor tartsa magat a dologhoz, ignoralja a telefonhivasokat. Nyilvan ez potencialisan ugyfel veszteseggel jar, de ilyen ugyfelet elveszteni valoszinuleg tobbet er, mint megtartani.
-
Drizzt
nagyúr
válasz
pmonitor
#17785
üzenetére
Tovabbra is:
Ez egy anonim forum. Nem programozot adok-veszek. Ha az lenne a cel, akkor el lehetne varni referenciat. De ez egy egyszeru beszelgetos topic egy anonim forumon belul. Ha az ember publikusan akarja mutogatni magat valamilyen forumon, megteheti. Arra van a Facebook, LinkedIn, Twitter, stb.
Ha valaki egy anonim forumon belul mindenaron emberek nyilvanos adatait probalja kikenyszeriteni, akkor annak elegge rosszindulatu adathalaszat szaga lesz. -
Drizzt
nagyúr
válasz
sztanozs
#17296
üzenetére
A kovetkezo lepcso meg az, hogy van library compliance, illetve a build soran csak a compliant library-kat tartalmazo registry-k erhetok el. Meg library approval process.
De ez az a kategoria, amit mindenki gyulolni szokott.
Foleg akinek meg kell kuzdenie az approval mocsarakkal.
Meg persze build artifact scan tobbfele szempontbol. -
Drizzt
nagyúr
"Szóval jön az ügyfél a kész munka után, és 20ezer számra sorolja, hogy de ezt ő nem így gondolta, meg azt nem úgy mondta, meg hogy de hiszen egyértelmű volt hogyan kellett volna csinálni, és társai. Gyakorlatilag a beleidet kidolgoztad a lehetetlen határidő tartására, elméletben viszont kárt okoztál a cégnek a "hozzá nem értéseddel", mert semmit sem csináltál meg "úgy, ahogyan az ügyfél kérte", csak "elpocsékoltad az időt"."
Nem így kell ezt elképzelni. Ez nem azt jelenti, hogy a határidőkor látja először a business azt, hogy mi készül el, hanem első adandó alkalommal. Pl. egy hónapos határidő esetén már az első héten lehet neki mutatni valamit, s onnantól ki fog derülni, hogy tényleg ezt az irányt kell-e csinálni. Ilyenkor még teljesen más irányba is el lehet menni, bőven van idő. Nyilván ehhez partner kell, hogy legyen a business is. A business meg örül, hogy olyan kérdések merülnek fel minél hamarabb, amik az ő fejében magától meg sem fordultak volna.
Visszatérve a #17116-os kérdésre:
"Csak hogy értsétek, nálunk vannak olyan emberek, akiknek a feladata az lenne, hogy az ügyfél ötleteit átfordítja nekünk, ami alapján tudnánk becslést adni, de amit én kapok abba kb több a kép, mint a normális leírás, szóval pl egy számlázó programanàl annyi lenne leírva, hogy készít egy számlát a számla gomb, de hogy mit ellenőriz, hogy számoljon stb azt nem írják le. Szóval több a kérdés utána mint a válasz. Jó lenne megreformàlni, de nem tudom hogy lenne ez a legjobb."
Erre agile képzéseken azt szokták javasolni, hogy legyen valamilyen definition of ready. Azaz meg kell határozni, hogy milyen feltételek esetén van tényleg olyan állapotban egy task, hogy el lehessen rajta kezdeni a munkát. Ha nem elég jó a kidolgozás ahhoz, hogy becsülni lehessen, akkor meg kell mondani, hogy csak nagy szórással tudsz becsülni rá, vagy még egyenesebb, ha tényleg megmondod, hogy ezen infók alapján nem tudsz rá egyáltalán becsülni. Másik agile-os módszer, hogy egy spike-ot csinál rá az ember, ami arról szól, hogy feltérképezitek, hogy mit is kell csinálni valójában. Ha azt gondolod, hogy valami szerinted nem becsülhető/elkezdhető állapotban van, akkor azzal kell beszélned, aki azt gondolta, hogy abban van. Elmondani, hogy szerinted miért nem elég az infó. -
Drizzt
nagyúr
Na, itt jön egy igazán váratlan pont: nálunk nincsen code review.
Eleinte teljesen kizártnak tartottam, hogy ebből ne süljön ki valami katasztrófa hosszabb távon, de meglepő módon egész jól megy. Persze ennek alapja, hogy elég sok microservice van és ritkaságszámba megy az olyan, amin 3-nál több ember dolgozik összességében. Amin dolgozik 5-6 ember, na ott hiányzik a code review már egyértelműen. Ilyenkor már elkerülhetetlen az architekturális rohadás, indokolatlan kód és funkció duplikáció. De elenyészően kevés az ilyen "mikrolit". A tesztelés még tényleg ott marad így is, mint amihez jó a ticket, az biztos. És tök jól jönne a CR-hez is, amennyiben az lenne.
-
Drizzt
nagyúr
válasz
bandi0000
#17116
üzenetére
Nálunk ez most úgy megy, hogy konkrétan nincsen becslés. Megmondja nagy vonalakban a business, hogy mi kéne neki. Megmondja, hogy mikorra kell neki. Mi meg ezután kitaláljuk, hogy ebből reálisan mit tudunk megcsinálni és elkezdjük kidolgozni, meg PoC-ként implementálni, hogy minél hamarabb rájöjjenek, hogy mennyi mindent kell még tisztázni rajta.
Ha valakinek nagyon kidolgozott requirement kell, hogy valamin elkezdjen dolgozni, az nálam a junior developer definíciója. Nálam ott kezdődik a senioritás, hogy korlátozott mértékű leírás alapján is el tudjon kezdeni valamit az ember csinálni, ha mást nem, akkor pár értelmes kérdéssel, saját ötlettel visszatérni.
Nagyon kényelmes lenne tűéles definícióból dolgozni, de aki írja ezt a dokumentációt, annak gyakran egyszerűbb rögtön Java-ban írnia, mint angolul egy Jira ticketbe. Hamarabb megvan. -
Drizzt
nagyúr
válasz
pmonitor
#16955
üzenetére
"Ők vajon miért is nem titkolják, hogy hol dolgoznak? Sztem. aki olyan helyen dolgozik/dolgozott, azt nyugodtan felvállalhatnák itt a fórumon is. Vagy vaj van a fülük mögött(rossz úton járnak), hogy nem merik megtenni? Vagy, vagy, vagy..."
Ez egy anonim forum, jo reggelt! Es egyebkent az en allasom peldaul rendelkezik arrol eloirasokkal, hogy a munkammal kapcsolatban publikusan milyen szabalyok szerint nyilvanulhatok meg. Beleertve az internetes megjelenest is.
A peldad teljes hulyeseg, nincsen ott az embereknel a PH! nickjuk. Anonym forumokon nem hinnem, hogy reklamoznak kik ok, kulonben mit keresnenek egyaltalan anonim forumon? -
Drizzt
nagyúr
válasz
pmonitor
#16952
üzenetére
"A pénz keresést meg azért hoztam szóba, mert ha vki(k) ebből gazdagodik meg, akkor sztem számon lehet kérni teljesítményt is."
Számon is szokták kérni. És a sikeres projektek jól szoktak teljesíteni. Ahol a jól teljesít nem azt jelenti, hogy nincsen olyan rész, amit ne lehetne gyorsítani rajta. Viszont ezek a gyorsítások nem járnak jelentősen érezhető különbséggel a felhasználó szemszögéből. Ilyetén módon pedig feleslegesek(senki nem akar olyan optimalizálásért fizetni, amiből nem érzékel semmit), pazarlások a megrendelő szemszögéből. -
#16875
Drizzt
nagyúr
Netszemete
#16872
Drizzt
nagyúr
válasz
Netszemete
#16872
üzenetére
De, és a JSON nem kimondottan kis erőforrásigénnyel parse-olható formátum. Ellenben remekül olvasható. Valamint WEB API-knál megintcsak fontosabban az egyéb előnyök, mint az azokhoz elhanyagolható mértékű sebességnövelés. Könnyű olvashatóság, mindenféle architektúra könnyen tudja értelmezni.
Ha pl. MQ-n küldesz adatot és nem akarsz parsingot alkalmazni, akkor mindkét végén a queuenak pontosan ismernie kell az adott adatstruktúrát.
Webes APIknál általában nincsen olyan latency requirement, amiben egy +/- JSON serdes ne férne bele.
#16873: JSON parsingnál a fő problémát az okozza, hogy nem lehet tudni az üzenet végigolvasása nélkül, hogy melyik mező hol kezdődik, így nem elég csinálni egy pár offsetről való közvetlen betöltést, ha egy mező értékét meg akarod tudni, hanem kénytelen vagy végigolvasni az eredeti JSONt(legalább addig, ahol a keresett mező(k) és annak értéke(i) van(nak)). Illetve az, hogy van szöveg, szám, meg boolean önmagában még nem segít semmit, mert a számot mindegyik oldal önkényesen értelmezheti különböző számtípusonként. Szóval általános JSON parsingnál valamiféle objektumba nem lehet megúszni a konverziót a számok esetén. Eleve a JSON sorrendfüggetlen, ugyanaz az objektum lehet a {"a": 1, "b": 2}, mint a {"b": 2, "a": 1}. Tehát nem tudsz olyat monda, hogy az Integer b mindig a 4. offseten keresendő. De még csak azt sem tudod megmondani, hogy a b Integer, Float, Double, BigInteger, BigDecimal. Szabadon értelmezhető.
De ahol a konverzió sebessége szűk keresztmetszet, ott nem is JSONt használnak. -
Drizzt
nagyúr
válasz
Vision
#16826
üzenetére
"És ja, az is lehetne, hogy egy köztes absztrakt rétegbe kiforgatjuk az adatokat egyfajta view-ként, csakhogy az is üzleti igény, hogy az adatok nem napra, hanem percre pontosak legyenek."
A ketto nem zarja ki egymast. Ha a forrasrendszerek a valtozasrol valami MQ-ba is kuldenek uzeneteket, akkor azzal igen low latency-vel fel lehet frissiteni a view-t. Persze ha a tobbfele MQ-t tobb alkalmazas resz dolgozza fel, akkor ilyenkor elengedhetetlen a view update melle az optimistic locking. Meg arra fel kell keszulni, hogy az adott user view-jat teljesen nullarol is megbizhatoan fel lehessen epiteni, de erre a most meglevo query-tek tokeletesen alkalmas kell legyen az alapjan, amit irtal(feltetelezve belole, hogy valamilyen user ID a request input parametere). -
Drizzt
nagyúr
válasz
Vision
#16811
üzenetére
Nem lehetne elore leszedni az osszes adatot az osszes helyrol es aggregaltan, denormalizalva eltarolni valami key-value store-ban? Nyilvan az a tradeoff, hogy nem biztos, hogy teljesen aktualis adat jon, de legalabb jo gyorsan. De lehetne adni a usernek kapcsolot, hogy gyors adat kell-e, vagy pontos. Nekunk peldaul ilyenekre elegge gyakran van olyan megoldasunk, hogy <1 sec a query, a megengedett lemaradasa a kompozit adatnak meg mondjuk 15 perc a "valosagtol".
-
Drizzt
nagyúr
válasz
pmonitor
#16775
üzenetére
Nagyon jol latszik, hogy dolgozni nem dolgoztal proramozokent. Ugyanis ott jellemzoen nem ezek a fontos problemak. Sokkal tobb gondot okoz az allandoan valtozo requirement lekovetese ugy, hogy a meglevo funkcionalitas erintetlen maradjon a bugfixek es uj fejlesztesek kapcsan. Illetve gyakran nagyon fontos, hogy a user minel hamarabb el tudjon kezdeni hasznalni valamit, mert akkor fog tudni rajonni, hogy mit nem gondolt vegig amikor megfogalmazta a korabbi requirementjeit.
Jobbnak gondolt programozok alapelve, hogy "avoid premature optimization". Ennek minden szava fontos. Mert nem arrol van szo, hogy ne optimalizalj, hanem arrol, hogy ne a szerint optimalizalj, hogy mi lesz szerinted gyakran hasznalt es kritikus. Ugyanis sosem tudod elore biztosan kitalalni, hogy a usernek mi lesz a fontos. Altalaban elore o maga sem tudja. Nyilvan van amit muszaj optimalizalni, de jol meg kell valasztani, hogy mit, mert aranytalanul draga.
Ha mondjuk valamit egy csapat szarraoptimalizal 1 ev alatt es amiatt fele annyi hardverkoltseg lesz eves szinten, az a megrendelonek nem igazan deal, mert egy(, nem egy csapat!) programozo eves koltsege legyen mondjuk 250000 dollar, fele akkora vm elofizetese meg mondjuk 300 dollar sporolas/honap, azaz ~4000 dollar/ev.
Sokkal fontosabb az, hogy a programozo meg tudja allapitani, hogy mi az, ami tenyleg lassu(monitoring, profiling) es azt hamar elfogadhatora optimalizalja.
Ami igazan fontos resze a lehetseges teljesitmenynek, az foleg architekturalis kerdes, abba erdemes tobb idot beletenni. Mikrooptimalizalasnak ott van ertelme, ahol az tenyleg bizonyitottan szukseges. -
#16761
Drizzt
nagyúr
Atomantiii
#16759
Drizzt
nagyúr
válasz
Atomantiii
#16759
üzenetére
-
#16694
Drizzt
nagyúr
Netszemete
#16692
Drizzt
nagyúr
válasz
Netszemete
#16692
üzenetére
Nem jársz tévúton, teljesen valid a választott út. Embere válogatja, hogy kinek melyik irány a kényelmesebb ezek közül. Lehet először entity-t írni, aztán abból sémát generálni és fordítva is. Vagy lehet írni mindkettőt kézzel, de annak tényleg nem olyan sok az értelme. Viszont a generált dolgokat érdemes mindig átnézni, mert a generálás valamilyen önkényes választások alapján fog eredményt hozni amikor döntési pont van. Én is egyébként általában előbb a schema DDL-eket írom meg mint az entity-ket.
Tutorialok java része egy irányból szokott csak megmutatni dolgokat és célja a bevezetés, nem a teljes mélységek megmutatása. Sokszor fordul elő olyan az emberrel, hogy már 5 éve csinál valamit valamilyen módon, aztán egyszercsak véletlenül megismer rá egy sokkal egyszerűbb módszert. Ez az élet része. Nincs olyan tutorial/training, amivel ezt el lehetne kerülni.
Pythonban egyébként nem vagyok otthon. -
#16691
Drizzt
nagyúr
Netszemete
#16689
Drizzt
nagyúr
válasz
Netszemete
#16689
üzenetére
Azt konkrétan magadnak kell eldönteni.
Ha kicsi alkalmazás, akkor kb. teljesen mindegy. H
Azt nem teljesen értettem a reflectiont miért hoztad fel. Illetve a programnyelv is segíthetne a döntésben. Én elsősorban JPA-hoz értek, de az Java. Ott nem is lenne olyan lehetőség a nyelv tulajdonságából adódóan, hogy a kód változtatása nélkül az entity class dinamikusan megváltozzon, azt feltételezve, hogy az entity egy class. Míg pl. Javascriptben ugyanez megoldható, mert a classhoz lehet felvenni új mezőket futás közben is. Az már egy másik kérdés, hogy ez miért jó, általában nem az. Persze Javaban is meg lehet oldani hasonlót, de nem sok értelme van, mert onnantól távolról sem lesz OO a kód.
Az egyébként nem baj, hogyha változik a séma akkor sem, ha a kód közben nem változik mindaddig, amíg a séma változás új oszlopok felvételét jelenti csak. Ha meglévő mappelt oszlop lesz átnevezve, vagy esetleg olyan típusúra átalakítva, amivel a régi mapping nem kompatibilis, akkor baj lesz belőle.
Ha meg nagyon változó sémáról van szó, akkor eleve nem biztos, hogy relációs adatbázisban kellene gondolkodni. -
#16688
Drizzt
nagyúr
Netszemete
#16687
Drizzt
nagyúr
válasz
Netszemete
#16687
üzenetére
1. Az ORM nem tudja elrontani a mappinget, míg a user igen. Persze ebben annyi hazugság van, hogy vannak dolgok, amik többféleképpen mappelhetők, tipikusan az ID-k. Ugyanis ha az ID egy foreign key, akkor lehet helyette Objektumként mappelni. Szóval az ORM egyszerűen megcsinálja azt helyetted, amivel dolgoznod kéne.
2. Az ORM megteszi az entity-object mappinget, ami ORM nélkül magadnak kell megtenned. Általában ad valamilyen object oriented query buildert APIt is.
3. ORM egyszerűen bizonyos mértékig elrejti előled, hogy adatbázissal dolgozol, használhatsz simán OO szemléletet.
4. ORM gyakran integrálható tranzakció management-tel, ami megintcsak olyan extra kód, amit magadnak kéne megírni.
5. Az ellenkező irány is lehetséges a fejlesztésnek: megírod az entity-t és az ORM frameworkkel generáltatsz táblákat.
Meg igazából lehetne sorolni bőven.
Nagyobb alkalmazásoknál egyértelműen meg tud térülni az ORM által elnyelt boilerplate kód, amit amúgy meg kéne írni. Viszont azért ORM-ek sem mindenre tökéletesek, update/insert teljesítményre optimalizálni kimondottan nehéz tud lenni. Ezeket sokszor natív SQL-lel egyszerűbb megcsinálni. De semmi nem gátolja meg az embert abban, hogy a kód egy részében ORM-mel bűvészkedjen az entity-jeivel, más részén meg natív SQL-lel módosítsa őket. -
Drizzt
nagyúr
válasz
bmatthun
#16364
üzenetére
Én anno csináltam ilyen scrapert, de a google eléggé gyorsan le is tiltotta az IP címet, ahonnan futtattam. Nem tudtam előre, de a google felhasználói feltételei között ott van, hogy ilyen célokra tilos a használata, s az elkövető tiltásával jár. Mondjuk ez vagy 15 éve volt, nem tudom megengedőbb lett-e a szabályzat. Nem hinném.
Én a html-ből próbáltam 1-2 heurisztika alapján parseolni, néha egész sikeresen, de hasonló mértékben egészen sikertelenül. Az eredményeket valamilyen db-be írtam, aztán kézzel átnéztem őket. -
Drizzt
nagyúr
válasz
btraven
#16229
üzenetére
De.
Maradjunk annyiban, hogy az elbaszhatatlan módosításokat minden további nélkül lehet csinálni(Nálam ebbe a kategóriába az IDE által automatikusan elvégezhető refactor lépések tartoznak(rename, make static, move to other class, extract ez az, amaz, stb...)), de ha nagyobb, mint nulla az esélye bármi elrontásának, akkor csak abban az esetben, ha minden lehetséges lényeges code path le van tesztelve, ahol az átírásra kerülő kód van. Vagy ha még nincs lefedve teszttel, akkor készül hozzá megfelelő teszt, s tényleg egyértelmű, hogy mi az expected behavior. -
Drizzt
nagyúr
1. Masfel millio nem keves penz Magyarorszagon. Inkabb marha sok.
2. Backendeskent is effele van a nem szupermenkent elerheto maximum. Es ugyanugy nem a minden masodik ember a ket szep szemeert es napi ket perc munkajaert kapja meg kategoria.
A magas fizetesert meg kell dolgozni es ez igy is van rendjen. Ha mindenki magas fizetest kapna, akkor az a fizetes onnantol kezdve atlagos lenne es nem magas.
3. Jo frontendes elegge keves van. Ennek egyik oka, hogy sokan nem szeretnek frontendezni. Sokan meg le is nezik valamiert. -
Drizzt
nagyúr
Kimondottan ellejvallott, kiveve ha koddal, vagy valtozonevvel nem lehet valamit kifejezni. En akkor irok kommentet, ha az adott szandekot sehogy nem tudom kifejezni a program nyelvi elemeivel. Pelda: ha mondjuk valamit raneyesre esszerubb lenne 3 sorral lejjebb vinni, de van kozben valami olyan framework hivas, aminek a mellekhatasa miatt nem lehet atsorrendezni, akkor meger egy kommentet. Ha valamit ki tudsz fejezni maskepp elnevezett valtozoval, vagy fuggvennyel, akkor jobb azt tenni, mint kommentet irni. A magyarazat egyszeru: ha a kod valtozik, s emiatt a mellette levo komment is idejetmultta valik, akkor nagyon nagy esely van, hogy a kommentet elfelejtik update-elni. Ennek meg az a vege, hogy par honappal kesobb ha arra a reszre teved az ember, nem tudja, hogy a komment hazudik, vagy a kod arrol, hogy minek kellene tortennie. Masik jo pelda, amit erdemes kommentelni: nyilvanos API, foleg ha abbol konkretan API spec lesz generalva. De ha siman annyi egy komment celja, hogy leirja mit csinal egy fuggveny, akkor jo esellyel a fuggveny neve a rossz. Ha meg a fuggveny neve igy 3 oldal kene, hogy legyen, akkor jo esellyel az a fuggveny tul sok dolgot csinal es erdemesebb feldarabolni. Persze ellenpelda mindenre van, ezek csak ilyen altalanos okoskodasok.
#16027btraven:
Miért nem csinalsz inkább enum-ot?
PL. WATER_FREQUENCY.HIGH = 1, WATER_FREQUENCY.LOW = 2.
Vagy ha nem diszkrét az értékkészlet, akkor inkább nevezném WATER_PROPORTION-nek, s akkor százalékként értelmezett adatot írnék bele. Vagy WATER_RATIO. -
Drizzt
nagyúr
válasz
bambano
#15896
üzenetére
Nem ertelek, engem zavarni egyaltalan nem zavar ez a kikotes. Ha zavart volna, akkor agalok ellene/nem irom ala.
Es ezzel el is jutunk a 3. ponthoz, a mi meg az, hogy igazabol semmi olyan fejlesztes nincs, amit munkaidon kivul csinalnek szivesen. :D Egyedul a covid jarvany elejen jart a fejemben egy magyar adatokbol dolgozo tracker irasa, de mire hozzakezdtem volna, addigra voltak megfelelo minoseguek. -
Drizzt
nagyúr
-
Drizzt
nagyúr
Ez nem lesz jó:
else { jatekter[bekertSor+1, bekertOszlop+1] = jel; }
, mert oda kellene figyelned arra, hogy nehogy a 4. sorba, vagy 4. oszlopba próbáld rakni a jelet.
Legegyszerűbb, ha meghívod újra a egyJeletVeletlenLerak függvényt, rekurzívan. Ezzel azt érnéd el, hogy amikor már foglalt helyet választott ki, akkor megpróbál egy másikat választani helyette.
(Amúgy nem eleve 3 X - 2 O-t, vagy 3 O - 2 X-et kellene lerakni? Ez így eléggé "cinkelt" amőba lesz.) -
Drizzt
nagyúr
Kétféle megoldás kapásból van:
1. Kiindulási állapotban a mátrixot töltsd fel valami olyan jellel, ami azt jelzi, hogy ott nincs még lerakva semmi. PL. legyen az egy 'S' karakter. Akkor amikor egy jelet leraknál egy mezőre, csak akkor teheted meg, ha ott még S van. Ha nem, akkor új pozíciót kell választani. Ezt lehet meg is úszhatod, mert progamnyelvtől függően lehet az adott terület már eleve valamilyen karakterrel végig fel lesz töltve. De jobban jársz, ha explicit feltöltöd valamivel.
2. Egy halmazban - amiben párok vannak - eltárolod, hogy hova raktál eddig jelet, a kisorsolt pozíciót ellenőrzöd, hogy foglalt-e már. -
Drizzt
nagyúr
válasz
Silεncε
#15499
üzenetére
Pedig azt is eleg jol meg lehet nezni egy jol iranyzott git log - - graph - - all - - oneline-nal.
Szerintem erdemesebb command line, mert az ugyis mindig rendelkezesre fog allni. Masfelol sokkal gyorsabban megvan az eredmenye annak, amit meg akarsz nezni. Mondjuk soha semmit nem grafikus feluleten csinalok gittel, de ez talan megint a masik extremitas.
-
Drizzt
nagyúr
válasz
martonx
#15466
üzenetére
Hat ugy kezdted a hozzaszolasod, hogy oskovulet. Nem igy van. Regota letezik, de a fejlodese kimondottan dinamikus. Teny, hogy nem volt ez mindig igy. De peldaul en is nagyon meglepodtem, amikor 5 eve eloszor javaztam, olyan 8 ev kihagyas utan. Mert nekem is hasonlo emlekeim voltak, mint amiket itt felhozol. Aztan amikor ujra javaznom kellett, ott jott a nagy meglepi, hogy ez bizony sok szempontbol kifejezetten jo es elvezetes lett a korabbi java developer elmenyhez kepest. En a c#-pal nem mernem osszehasonlitani, de a tobbi emlitett nyelvvel sem. Szimplan mert azokkal nincsen semmifele on-hands tapasztalatom az elmult 5 evbol. Oke, Js-ben meg volt aktiv programozoi elmenyem, ezerszer kellemetlenebb elmeny js-ben programozni, mint Javaban. Legalabbis nekem. A Java elmenyhez sokat hozzaad szerintem amugy az IntelliJ is. Teljesen osszehasonlithatatlan a regi Eclipse szivassal(, lehet persze, hogy az se olyan mar mint reg).
-
Drizzt
nagyúr
válasz
martonx
#15450
üzenetére
A Javarol amiota dolgozom, allandoan ezek az allitasok kerulnek megfogalmazasra. Ettol fuggetlenul amik meg igazak az elmult 13 evben a Java kapcsan:
- Mindig temettek, megis el es virul allando jelleggel.
- Rendkivul sokat fejlodik, nagyon sok dolgot atemel a konkurrenseitol, de ugy, hogy a megoldas nem tunik nyelvidegennek.
- Gyakorlatilag mindenre van library, tobb is. Nemelyik pont a nyelv hatranyainak kikuszobolesere epul, pl. Lombok.
- Nagyon fasza frameworkok is vannak hozza, eleg a Spring/Spring Bootot felhozni.
- Akarmi volt eppen a legmenobb nyelv, a Javaval elerheto fizetes mindig az elsok kozott volt. Legalabbis itthon ezt tapasztaltam.Egyebkent Java fejlesztokent csak olyan 5 eve dolgozok aktivan. En szeretek Javaban programozni, persze van 1-2 dolog, amit mas nyelven konnyebb, gyorsabb leirni, de nagy hianyerzetem nincs. Ami tenyleg zavaro, ugyis idovel kikupaljak ujabb Java verziokban.
-
Drizzt
nagyúr
válasz
K1nG HuNp
#15274
üzenetére
Ugyan sose hasznaltam go-t, de ez tunik a go szinten elfogadhato megoldasnak. [link] Kb. Az a lenyege, hogy egy channelre figyelsz, s ha abban van olyan uzenet, ami miatt le kell allni, akkor leallsz. Ez nyilvan nem tul jo, ha valami hosszu blokkolo fuggvenyt kell hivnod.
Mas nyelvekben meg inkabb az explicit thread kezelessel lehet ezt megoldani, mert ott lehet kuldeni interruptot, amire a thread leallhat.
De amennyire tudom, a goroutine egyaltalan nem biztos, hogy kulont threadben fut, ez az egyik lenyege.
Emiatt viszont ezen az absztrakcios szinten nehez megallitani aszinkron dolgoknak a futasat. -
Drizzt
nagyúr
válasz
bandi0000
#14927
üzenetére
Hát, ha befér az összes a memóriába, akkor:
1. Csinál egy mapet, amiben a kulcs egy id pár(pId, rPid), az érték meg maga a sor lesz.
2. Menj végig az összes DB soron. Nézd meg, hogy az adott sor (rPid,pId) párosával szerepel-e már elem az 1-es pont map-jében. Ha igen, akkor update-eld meg a hozzá tartozó sort, s valahogy jelöld meg, hogy a db-be is ki kell majd írni(pl. a kulcsát beteszed egy toUpdate Set<pId, rPid> halmazba). Az éppen olvasott sort meg rakd bele egy toDelete Set<pId, rPid>-be. Sőt, még egyszerűbb egy toUpdate Set<id> setet használni inkább.
3. Amikor végigértél az értékeken, akkor már csak annyi a dolgod, hogy a toUpdate elemeire tolsz egy batch update-et, a toDelete értékeivel jelzett sorra meg egy batch delete-et.Viszon ahogy elnézem a db sorodat... Nem kell a cId-t is belevenni a buliba, s hármasokat keresni inkább a párok helyett?
-
#14867
Drizzt
nagyúr
instantwater
#14855
Drizzt
nagyúr
válasz
instantwater
#14855
üzenetére
"Esetleg arról is van infód, hogy nálatok milyen branching strategy vált be, és ha van automatizált telepítés, akkor mi triggereli az egyes környezetek frissítését?"
Nevezzük módosított gitflownak. Azért módosított, mert muszáj egy adott alm, meg rlm rendszert használnunk, amit viszont más csapat birtokol, s nem igazán nyitott a változtatásokra, meg a rugalmasságra.
Automatizált deploy jelenleg nincs. DEV rendszerbe lehetne. UAT/feljebb nem mehet csak kézi kezdeményezésre, megfelelő jogosultságú emberek által, PROD-ra meg emberek még szűkebb csoportja által. Szerintem amúgy nincs ezzel különösebb gond. Minőségi garancia szinte semmi nincs jelenleg(még unit testek is általában a jobokban ki vannak kapcsolva, code review elvétve van; ha valaki önként jelzi, hogy szeretné, ha megnéznék a kódját), mégis meglepően stabilan mennek a dolgok. Ez szerintem csak azért mehet így, mert alapvetően masszív tapasztalatú emberekből áll a csapat(, legkisebb tapasztalatú ember valahol 5 év körül lehet, az átlag 15 körül).
Én amit legfontosabbnak tartok az az, hogy a build során elkészült alkalmazás része legyen mindenképpen valamilyen build metadata. Az sem árt, ha mondjuk induláskor is kiírja az ember a logba, hogy pontosan milyen verzió indult(legfontosabb a git sha-1). De azt is fontos lehet, ha meg tudja oldani az ember, hogy valahol a deployment verzió history is látsszon. De ezt a taget szintén a deployment pipeline is rárakhatja a commitra. Pl. jó ötletlet lehet rárakni a környezetet, meg a deployment timestamp-et. -
#14853
Drizzt
nagyúr
instantwater
#14844
Drizzt
nagyúr
válasz
instantwater
#14844
üzenetére
Egy tanács:
- Nem tudom ugyan, hogy milyen nyelven/frameworkon fejlesztetek, de ha Spring boot, akkor semmiképpen ne fat jarba package-eljetek docker image esetén, hanem a dependency-k, meg az alkalmazás források legyenek külön docker layerben. Ezzel az össz. helyfoglalás jóval kisebb lesz, illetve amíg nem változik a dependency-k összetétele, addig az a layer ott tud csücsülni azon a gépen, ahol a docker már találkozott vele, így nem kell letölteni se újra.
- Még érdekes kérdés, amit tisztázni kell, hogy hol tároljátok az alkalmazáshoz tartozó környezetfüggő konfigurációkat. Különös tekintettel a szenzitív adatokra(db cred, etc.).
- "A deployment jelenleg egy több szerverre kitolt kódbázissal megy ahol a függőségek az összes szerveren helyben újra és újra telepítve vannak ami írtó sávszél pazarló, és fragile, mert boldog-boldogtalan root joggal bír a szervereken, és gyakran elb.rmolják az ownershipeket." Ez nagy baj, de docker használatával kapásból meg tudjátok oldani. -
Drizzt
nagyúr
Egyes subfeature-ekre volt mar ra pelda. Eleg jo volt a helyzet, mert aki csinalta a requirementet, ugy csinalta meg, hogy a teszt szinte copy paste volt belole. Csinalnek ilyet gyakrabban. De azert sajnos elegge gyakori volt anno, hogy a kodot mar irni kellett a requirement rogzitese elott. Ugy meg nehez a tdd. Mostani munkahelyen a hozzaallas pedig test in production. De ettol meg szerencsere az egyes embereknek nincs megtiltva, hogy teszteket irjanak, ha ugy latjak jonak. Elegge veszelyesnek tartom ezt a hozzaallast, megis valahogy mukodik. Jelentos reszben valoszinuleg azert, mert a fejlesztokben belulrol van igeny a kritikus reszek automata tesztelesere. Meg az is igaz, hogy kb. 4 ev a legkisebb tapasztalatu fejleszto, az atlag 15-20 korul mozog. Szoval megiscsak van teszt, de fentrol nem az az uzenet, hogy legyen.
-
Drizzt
nagyúr
Mondjuk szamlak tipusa. Van betet, hitel, meg mittuodmenmilyen. Termeszetesen ez se tokeletes pelda, mert akar kesobb is keletkezhetnek uj tipusok. Es akkor kodhoz kell nyulni, ha konstansba rakta az ember az erteket. Egyebkent ha valaminek a zart ertekkeszletet akarja megadni az ember, mint az en peldam is, akkor meg inkabb enum. Az is egyfajta konstans. Ami a te peldadban van, az tipikusan property-bol konfiguralhato ertek kellene legyen, legalabbis javaban. Viszont pl. az, hogy melyik property-bol kell felolvasni, meg mi a property default erteke, azt mar tipikusan konstanskent szokas eltarolni.
Vagy jo konstans pl. a honapok szama egy evben. Azert az egeszen ritkan valtozik. :D
-
Drizzt
nagyúr
válasz
Con Troll
#12585
üzenetére
Amúgy Java backend(Spring, vagy EE) miért nem merül fel? Amióta én dolgozom, Java fejlesztőt mindig kerestek, s sosem az alja felé volt a fizetési listáknak. Valahogy úgy tűnik, hogy a Java sose fog kihalni. Mindent túlél.
A 8-as verziótól kezdve kifejezetten élvezetesen használhatónak találom. Azóta sokkal szebben meg lehet oldani dolgokat, ami előtte sok töltelék kódot igényelt. -
#12490
Drizzt
nagyúr
Victor Súgó
#12489
Drizzt
nagyúr
válasz
Victor Súgó
#12489
üzenetére
Ez az elasticsearch funkcio talan jol johet neked. Nem tudom pont erre van szukseged, de haigen, akkor angol hint: [link]
-
Drizzt
nagyúr
Megjelent a Refactoring second edition. Bar az eredetit se reg olvastam, de mindjart bevasarolok ebbol is. Imadtam azt a konyvet. Bar magyarul olvastam, ugy az igazi kihivas, megprobalni visszafejteni a pattern neveket angolra, hogy valamit ertsen is belole az ember.
-
#4349
Drizzt
nagyúr
FehérHolló
#4346
Drizzt
nagyúr
válasz
FehérHolló
#4346
üzenetére
Teljesen mindegy jelen esetben.
-
#4345
Drizzt
nagyúr
medvezsolt
#4328
Drizzt
nagyúr
válasz
medvezsolt
#4328
üzenetére
Php topikban kéne kérdezni inkább. Amúgy: a get tömbben nincsen id key. Próbáld meg esetleg $_REQUEST['id']-vel, az a posttal, s gettel adott paramétereket is tartalmazza. Vagy nézz egy isset($_GET['id'])-t, ha igaz, akkor irasd ki, hogy igaz, ha nem, akkor meg azt, hogy nem. Lehet rosszul adod át az url-ben a paramétert, ha kézzel akarod átadni.
-
Drizzt
nagyúr
-
Drizzt
nagyúr
Sziasztok, elég rég nem írtam ide, de most szeretnék nyáron tanulni, programozásban szeretném magamat továbbképezni. Na lássuk miből élek eddig: Kezdtem Pascallal magamtól, meg egy picit C-t is, aztán BME-n C++, C, Java, Prolog, SML volt eddig. Igazából Windows alatti dolgok érdekelnének a közeljövőben főleg. Van egy elég vaskos könyv C# alatti adatbáziskezelés, vagy valami hasonló címmel ''mesteri szinten''. Namost: ez a könyv milyen? Ha C#-ot még soha nem tanultam, akadhat vele valami gondom, vagy az alapokról épít?
Esetleg logikai és funkcionális programozással milyen irányba lehetne keresgélni, hogyha magasabb szinten érdekelne, vagy modern felhasználhatósága(ebből voltam eddig még csak 4-es életemben a Bme-n, minden más 2,3)?
Vagy akármi ötlet? Mondjuk lehet egyszerűbb lenne azokat a dolgokat tanulnom, amiből megbuktam... -
-
Drizzt
nagyúr
Helló. az érdekelne engem C++ban:
- cin-nel ha beolvasok valamit, akkor hogyan ellenőrízhetem, hogy a beolvasás sikeres volt-e?
- file-kezelés hogyan? Valami link esetleg?
- Grafikus képernyő kezelése hogyan?
Fontosak lennének ezek a dolgok, mert kellenének a nagyházimhoz, de sajna a VC++ 6.0-mben nincsen benne a help rész... Help pls... -
#561
Drizzt
nagyúr
TheVeryGuest
#560
Drizzt
nagyúr
válasz
TheVeryGuest
#560
üzenetére
Helló. Már sikerült megoldani a gondot. Köszi, s elnézést, ha valakit megsértettem volna.
-
Drizzt
nagyúr
válasz
VladimirR
#546
üzenetére
Azt hiszem, hogy nem erről van szó. A példaprogramban is van egy dolog, de ott a komplex osztályhoz van túltöltve az operátor, de szintén két argumentummal. Igaz ott a ''!='' operátorról van szó. A fordítóprogram meg a programblokk belsejében sípol, nem a függvény fejénél, s külön-külön panaszkodik a leftoperand, illetve rightoperand-ra.
-
Drizzt
nagyúr
Hellósztok. Aki ért C++hoz, annak szeretném a segítségét kérni. A feladatom a következő:
Van egy vektor osztály, ehhez kell overload-olni a különböző értékadás, összehasonlítás műveleteket. Leírom, hogy mit írtam eddig be(erősen kivonatolva...)
Tehát a lényegi részek(amúgy visualc++-ban dolgozok):
class vektor{
private:
int x,y,z;
public:
friend bool operator <(vektor a, vektor b);
...
};
bool operator <(vektor a, vektor b)
{
return a.norm<b.norm;
}
Erre a fordító hibát ad ki, miszerint a ''<'' operátor operandusaival van valami gondja. Hogy kell ezt megcsinálni helyesen?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Tok mindegy, van komplex feladat boven UI es Backend oldalon is. Aki viszont barmikor amikor nem muszaj ujrafeltalalja a kereket, az minden teruleten sulyos gond. Kiveve ha eppen tanul, de annak meg nem a munkahely a megfelelo terulete.
Foleg akinek meg kell kuzdenie az approval mocsarakkal.
Ha kicsi alkalmazás, akkor kb. teljesen mindegy. H
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Amlogic S905, S912 processzoros készülékek
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Könyvajánló
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Battlefield 6
- Házimozi belépő szinten
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Formula-1
- Kirakatba tette a Google a Pixel 10-eket
- További aktív témák...
- Gigabyte 15 G5 Gamer FHD IPS 144Hz i5-12500H 12mag 4.5Ghz 16GB 512GB Nvidia RTX 3050 Win11 Garancia
- Layer 2 Plus (Layer 3 Lite) Passzív rack switch, 24x1G + 4x10G SFP+ , SFP-kkel FS S3900-24T4S-R
- Eladó/Lenovo X240 Ultrabook/I5-4300U/8GB DDR3/Win 10Pro/12,5"!!!
- LG OLED55C9 prémium TV - 140cm, 4k, 120Hz - apró vizuális hibával
- Erős Gamer / Munka PC i7-14700, RTX 3070 Ti, 32GB RAM, 1TB SSD
- AKCIÓ! Asus ROG Flow Z13 +ROG XG RTX 3070- i9 12900H 16GB DDR5 1TB SSD RTX 3050Ti 4GB + RTX 3070 W11
- 8 GB-os GeForce RTX 2060 SUPER (OEM HP) - garanciával
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- HIBÁTLAN iPhone 11 64GB White -1 ÉV GARANCIA - Kártyafüggetlen, MS3027
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest