- D1Rect: Nagy "hülyétkapokazapróktól" topik
- btz: Internet fejlesztés országosan!
- antikomcsi: Celebtanya - Farm VIP V.
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- Bevezetés a wokok világába
- sziku69: Fűzzük össze a szavakat :)
- weiss: Pant* rant
- Mr Dini: Mindent a StreamSharkról!
- sh4d0w: Palpatine - A Terv
-
LOGOUT
Új hozzászólás Aktív témák
-
dabadab
titán
válasz
bandi0000
#17398
üzenetére
Angularban pont ilyesmire találták ki a service classokat (nem tudom, hogy milyen nyelven csinálod, ahol duck-typing van, ott egyszerűbben megy, szigorúan típusos nyelveknél egy kicsit macerásabb, de nem sokkal).
Amikor létrehozod a dialogot, akkor a konstruktorban átadsz neki egy osztályt, aminek egyelten publikus metódusa van, egy getListElements() és a dialógod ezt a metódust meghívva kap adatot, innen kezdve nem kell azzal foglalkoznia, hogy honann és hogyan jönnek az adatok, ő csak egyszerűen megkapja őket (ez unit testnél is hasznos, mert akkor meg csinálsz vmi mock service osztályt, ami a tesztadatokat köpi ki magából, nem kell mögé webservice-t rakni).
A service osztályt meg egyszer megírod, aztán az endpoint címét meg megkapja konstruktorparaméterkent, illetve ha vmi enum is más az egyes osztályoknál, azt meg templatespecializációval megcsinálod.
-
bandi0000
nagyúr
Habár inkább Amdroid specifikus, de az alap gond talàn több tagot érintett már.
Szóval kellene csinálnom egy dialogot, ahol listàt jelenítek meg, illetve esetleg rajta egy kereső mezővel, a végén peddig választani lehet 1 elemet.
A probléma az, hogy több listàt kellene kezelni, persze nem egyszerre, így valami univerzàlis/generikus dolgon gondolkodok.
Ami eddig eszembe jutott, csökkenő "jó ötlet" sorrendben
1. Ahol megjelenítem, ott lekérdezem a listàt, és mejelenítéskor átadom a dialognak ezt, valami univerzális típusban.
2.Mivel a lista api ból jön, így a dialognak csak egy típus enumot adok át, és a dialogba szintén egy univerzális típust hozok létre csak egy case-when dologgal, enumtól függően hívom meg az api end pointokat.
3. Generikus dialog, az egyes típusok örökölnek tőle, így a megjelnítés/szűrés stb nem kell megírni, viszont attól még lista fajta X 3 osztály +- a generáltak lesznek.
Van valakinek valami jó ötlete? Talán az első 2 megoldás lehet a jó, főleg a 2. felé orientálódnék, mert akkor a hîvó osztályban, nem kellene mindenképp lekérdezni a listàt, mert lehet nem is nyitják meg ezt a dialogot
-
martonx
veterán
-
Ryan_Sanchez
tag
válasz
Ryan_Sanchez
#17388
üzenetére
Közben sikerült megoldani Json-nal, egyszerűbb volt mint gondolnám. Mondjunk nem teljesen értem, hogy működhet így, de szívesen fogadnám ha valaki elmagyarázza
Controllerbe létrehoztam, átküldtem viewdatán keresztül,
Viewbe megkapja a Json objectet,
Javascriptnek odaadom razor syntaxal,
Szépen megkapja az integer tömböt ahogy kell.
Nekem csak az a fura, hogy nincs szükség deserialize-ra (json.parse()), gondolom ez is JS feature.
-
coco2
őstag
Más, Net, EntityFramework kérdés. Még csak első körben ismerkedek vele, és főleg koncepcionális a problémám.
Szóval vannak entity-k, mondjuk E1, E2, E3 - és még amennyi, amik mindegyikének vannak saját mezőik, de egyúttal referencáik is egymásra egész listányi. Az adatmodel olyan, hogy listányi körbehivatkozásokkal végül minden hivatkozik mindenre, és egész DB kell hozzá "lezárni" a hivatkozásvégeket. Például E1 hivatkozik listányi E2-re, E2 hivatkozik listányi E3-ra, E3 hivatkozik listányi E1-re, és végső soron csak annyi az egész DB. Aztán lekérdezek egyetlen kulcsnyi E1-et.
A kérdés. Fenti példában az EF képes lesz memóriába rántani azonnal az egész DB-t csak azért, hogy a referenciákat végig ki tudja tölteni? Vagy van bármi okosság kitalálva adatmélységet szabályozni?
-
#17387
martonx
veterán
Ryan_Sanchez
#17386
martonx
veterán
válasz
Ryan_Sanchez
#17386
üzenetére
Kicsit konkrétabban? Jsonról hallottál-e? Js oldalon mit csinálsz?
-
#17386
Ryan_Sanchez
tag
Ryan_Sanchez
tag
Sziasztok!
Asp.net core MVC:
Chartot szeretnék megjeleníteni az oldalon, ehhez találtam is megfelelő js libraryt Chart.js néven.
https://www.chartjs.org/docs/latest/
Az itt található kód királyúl működik, csak a kódban található data kézzel van megadva.
Ezt a data tömböt szeretném megadni code behindból. Próbáltam a kukacos (@) razor syntaxal, de sehogy sem lett jó. Hogyan tudnék neki adatot adni tömbformájában backendből? -
>szatelit rendszerekkel, amelyeknek vagy nincs normális dokumentációja, vagy elavult
A mai világban tessék leszokni az általánosításról. Esélyesen közbeékelődött valaki, aki borítékot akart a zsebébe. Tőled, akkor, és ott nem kapta meg. Szóval neked, akkor, és ott nem volt dokumentáció.wtf
-
coco2
őstag
válasz
Vision
#17369
üzenetére
>szatelit rendszerekkel, amelyeknek vagy nincs normális dokumentációja, vagy elavult
A mai világban tessék leszokni az általánosításról. Esélyesen közbeékelődött valaki, aki borítékot akart a zsebébe. Tőled, akkor, és ott nem kapta meg. Szóval neked, akkor, és ott nem volt dokumentáció.
Hogy egy pályára állított műholdnak ne legyen még az utolsó csavarjáról is 3x ellenőrzött dokumentáció, az nonszensz.
-
Talán segíti a megértést ez a kiegészítés: sokszor ugyan fix a szkóp, de bonyolult ökoszisztémák esetén nagyon nehéz eljutni oda, hogy ez feltöltődjön üzleti tartalommal. Például szeretnél csinálni egy új netbankot. Hiába készíted el a legmodernebb UI-t, azt ki kell szolgálni adattal, össze kell kötni core és szatelit rendszerekkel, amelyeknek vagy nincs normális dokumentációja, vagy elavult. Ez mind idő. Gyakran sokkal jobb elindulni agilisan egy szűkített szkóppal, lépésről-lépésre feltérképezni az integrációkat, és folyamatosan szállítani az új funkciókat. Ezt waterfallban megvalósítani szinte lehetetlen, legalábbis belátható időn belül.
Szóval az agilis értékekből nem csak az ügynökségek/szállítók profitálhatnak, hanem a nagy megrendelők is. Persze a valóság kijózanító.
-
coco2
őstag
válasz
Regirck
#17364
üzenetére
Ha csak kell egy linux, win10 alatt mostanra van linux subsystem, vagy vmplayer alatt felhúzhatsz magadnak egy ubuntut desktopostul, és még vps sem kell. Vps arra kell, ha bárhova odamész, és meg akarod mutatni ott hogy mit alkottál weben. Mondjuk ahhoz egy domain regiszter is kelleni fog. A domaint illetően évente +5k huf körüli összegre számíthatsz. Vannak "ingyenes" domain-ek, de mostanra már annyi ge*iség van abban a játékban, hogy azokra most linkeket nem adok. A magam részéről inkább fizetem azt az évi pár k huf-ot.
-
Regirck
senior tag
Mindenkinek köszönöm a segítséget!
Hobbi és önfejlesztés a cél. Valamint egy jó hobbi projekt jobban mutat így, mint egy github/lab link egy CV-ben (véleményem szerint). Szerintem kevesen klónozzák le onnan a projektet, hogy kipróbálják, megnézzék működés közben.
Valamint egy ideig linuxon fejlesztettem, így azok az ismeretek is felelevenülnének/megmaradnának.
Bár most jó fejlesztői állásom van, de a felkészültség nem árthat.
Valamint ha egyszer a hobbi projekt kinőné magát (kevés esélyt látok rá, de sose tudni), akkor majd ismét kikérem a véleményetek a bővülésről.
-
coco2
őstag
válasz
martonx
#17361
üzenetére
Az indító post nem írta le egyértelműen, milyen mélységgel szeretne barkácsolni. Például előkerülhet-e C alapon írt bináris, amit cron-on futtatna egy webszerver mellett. Ha igen, a logikai szintű szolgáltatások már elégtelenek.
Azt sem írta, hogy elég lenne on spot alapon neki a külső szerver. A barkácsolósdi azt sejteti, kelleni fog neki a 7/24 rendelkezésre állás külső szerveren folyamatosan futtatni valamit.
A fentieket összeadva minimum folyamatos vps szolgáltatás kell neki. És pontosan arra kapott költséghatékony tippeket.
Aztán ha mindezekhez még hozzá jön a teljesítmény igény, következőre már dedikált szervereket fogunk neki linkelni, nem vps-t. Vps havi 5 eur, de ha sokkal több cpu / ram / előreszámítható io sebesség kell, afásan 45 eur körül kezdődnek a szerverek egészben.
A serverless nem az indítóban felsorolt igényekre van méretezve.
-
válasz
martonx
#17361
üzenetére
> Ha önképzés a cél, akkor a felhőben futtatási lehetőségekkel kellene ismerkedni, nem linux szervert konfigurálgatni.
Nem tudom, hogy ez miert van igy. Attol fugg, hogy miben szeretned kepezni magad. Lehet persze Heroku/Fly.io/Vercel/stb. iranyba is indulni, de olyat meg nem lattam, hogy artott volna, ha valaki takolt volna sajat szervert, vagy akar sajat maga rakott volna fel k8s-t.
A serverless meg total mas teszta, mas elonyokkel/hatranyokkal.> No persze felhőben (ok, számomra a felhő az AWS, Azure, Google Cloud) is lehet komplett szerver instance-t keríteni, ha valaki mindenáron ehhez ragaszkodik.
Lehet, de elonye nincs, csak hatranya (dragabb). Sima VM-ekert en tuti nem mennek a nagy felhokhoz, tenyleg remisztoen dragak tudnak lenni.
-
martonx
veterán
Ilyen filozófiai mélységekbe ne menjünk bele, hogy mi számít felhőnek, és mi nem.
Arra gondolok, hogy ezekhez nem igazán kell szerver. Garázs cégeknél szerver bérlés meg pláne zsákutca. Ha önképzés a cél, akkor a felhőben futtatási lehetőségekkel kellene ismerkedni, nem linux szervert konfigurálgatni. No persze felhőben (ok, számomra a felhő az AWS, Azure, Google Cloud) is lehet komplett szerver instance-t keríteni, ha valaki mindenáron ehhez ragaszkodik. -
dabadab
titán
válasz
Regirck
#17355
üzenetére
Nekem a Tilaanál (ők hollandok) vannak VPS-eim, jó áraik vannak, elég szabadon konfigurálható (és később bővíthető) VPS-ek, a sávszélesség, uptime meg ilyenek meg teljesen rendben vannak.
Ha valami nagyon low-costot akarsz, akkor amúgy az is megoldás, hogy egy Raspberry Pi-t ráraksz az otthoni routerre.
Manage-elésre meg ssh-nál jobbat nem tudok mondani.
-
Regirck
senior tag
Sziasztok!
VPS servert szeretnék bérelni, ahol a futó (hobbi) projektjeim ki tudom tenni.
(dotnet, mssql, angular meg ami még idővel jön hozzá. Linux alapú servert szeretnék).
Mely szolgáltatót ajánlanátok? Örülnék ha Magyar cég lenne, de nem feltétel. Első körben a RackHost ami felkeltette a figyelmem.Valamint milyen programot ajánlotok amivel lehet kapcsolódni? Vagy a jó öreg terminál az igazi?
-
#17353
coco2
őstag
racskobalazs
#17352
coco2
őstag
válasz
racskobalazs
#17352
üzenetére
Lehetségesnek lehetséges. Itt egy link a nearby search api doksira, de van útvonal tervezés és mindenféle. Az érem másik oldala, hogy token kell hozzá, amit regisztrációval kapsz meg, amiért fizetsz. Kirakod a céged nevében public-ra, rázuhan a nép ezerrel kotorászni, azt mind a cég fogja fizetni. Ugyan mostanra már nem eszelősen vannak elszállva az árak, és van minimum limit, de egy nem is túl népes website azt túl tudja lépni, és pluszba lecsörgethet másik 60k huf-ot havonta. Ha a rokonod ésszel akar valamit csinálni, akkor érdemes neki esni, de ha csak hipszterkedés, az megbánással szokott végződni.
-
#17352
racskobalazs
senior tag
racskobalazs
senior tag
Sziasztok!
Rokonom keresne olyan megoldás, mellyel FB-re lehet a cégéhez egy szűrhető térképet rakni, ami ha kell útvonalat is tervez a legközelebbi bolthoz. Ilyesmit mivel lehetne csinálni? Google Maps API? Egyáltalán lehetséges?
Előre is köszönöm!
-
coco2
őstag
Na mindazokat magyarázd azoknak a főnököknek akiknek ha olyat mondasz, nem tudod előre felmérni és garantálni, hogy mennyi idő lesz az, amit el sem tudnak neked mondani, mert annyira kiforratlan és ködös az alapgondolat, azonnal látod rajtuk, hogy a következő pillanatban üvölteni kezdenének. És persze faképnél lehet őket hagyni, de hát pénzt locsolnak az informatikába, és szerintem cserébe jár nekik az idő, hogy tanuljanak, amennyire a cérnájuk bírja, bármennyi is legyen az.
-
coco2
őstag
>vagy alkalmatlan vagy rá (no offense..
None taken. Minden játéknak több oldala van. Ha valaki nyerni akar az egyiken, valaki másnak veszítenie kell hozzá a másikon. Én elég gyakran a vesztesek oldalán vagyok. Én legalább megbírom. Amilyen harmatos népek érkeznek ma az informatikába, ők valószínűleg alkalmatlanok lennének rá. -
A burokracia tultolasa az agilis fejlesztes felreertese.
Az agilis fejlesztesnek annyi a lenyege, hogy beismerjuk, hogy nem tudjuk pontosan felmerni a vegleges kovetelmenyeket, tehat elindulunk valamerre, es kozben folyamatosan csekkoljuk, hogy jo iranyba haladunk-e.
Az agilis fejlesztes eleve nem fer ossze a fix hataridokkel. Eleve a fix hatarido es a fix szkop nem fer ossze (vagy az egyik, vagy a masik). Tehat agilis fejlesztesnel nem tudunk elore megegyezni abban, hogy mikorra lesz kesz az egesz, hiszen pont azt ismerjuk be, hogy nem tudjuk meg, hogy mit fog tartalmazni a vegleges termek.
-
Te még vagy nem dolgoztál agilisan vagy alkalmatlan vagy rá (no offense, de sokan vannak így). Az agilitás lényege, hogy a piac igényeire tudj gyorsan reagálni, és ne 5 év múlva kerüljön elő egy olyan feature ami most trendi. Amit felsoroltál problémát az agilitástól függetlenül is az lenne.
-
coco2
őstag
Egy korlátos emberi erőforrás környezetben a többlet adminisztrációs teher fejlesztési időt von el. És még csak nem is dokumentálásra, hanem bürokráciára. De igazad van, a sebesség egy teljesen mellékes kérdés, elvégre nem is az alapból képtelen határidők mindig a baj. Szóval a szakmai oldalt nyugodtan félretehetjük - elvégre ki a fenét érdekel az - és lássuk az üzleti oldalát.
Az üzleti oldalon szakmailag hozzá nem értő emberek eggyeznek meg valami képtelenségben, amit a "körülmények összessége folytán realizálható objektivitás"-nak neveznek, miközben a buksija mélyén mindegyik azt gondolja, hogy majd pont a másikon fog csattanni az ostor az egyezményesen elkövetett hazugságok miatt. Ugyan mi is tudhat lehetségesen félresikerülni, ugye?
-
coco2
őstag
válasz
martonx
#17339
üzenetére
Elolvastam a blogot, a linket köszönöm, sajnos nem sokat segít jelen helyzetben.
Szóval az entity-kben nullable-re raktam mindent, a bemeneti parser már nem sír. Megoldás gyanánt a bemeneti mezőkben a körkörös hivatkozást előidéző mezőket simán nem rakom bele. A funkció lefut, adatbázisban van a végeredmény, és akkor jön a meglepetés. Ez a sor crash-el:
return Ok(result);
A "result"-ban egy DbSet<Entity> van. A legfelső szinten ott vannak a tábla saját adatai, de az Entity-nek része a másik táblára hivatkozás, amiből tovább van hivatkozás, és úgy tovább - na azt az ASP kimeneti json parsere nem tudja lekezelni.
Valami olyasmi kellene, hogy megmondhassam a DbSet<Entity>-nek, hogy recursive depth: 0. Ami osztály, azt hagyja null-on.
Átmenetileg megfixeltem: kézileg explicite null-ra állítom az összes referenciát a kimenetben. A result json-ban ott rondálkodik egy null. Így legalább nem száll el. De szépnek éppen nem szép. Egyáltalán nem kellene feltüntetni osztályokat a kimenetben.
Lévén az ASP web controllerének beépített kódjáról van szó, nem vagyok benne biztos, hogy abba én belenyúlhatok kézileg
Bármi bölcsesség?
-
coco2
őstag
válasz
martonx
#17339
üzenetére
A migrations azt csinálja, hogy ilyenkor gyárt egy harmadik táblát kapcsoló táblának, kb ilyesmit:
EgyikMasik {
public int EgyikId;
public int MasikId; }és abba a táblába vési fel a rekordokat, hogy milyen összerendelések léteznek. A migrations kimenetet megnéztem, a köztes tábla létezik. És sajnos nem hiszem, hogy a sok-sok tábla kapcsolatot el lehetne kerülni. Alapvető igény egy adatbázisban.
A linket köszönöm, elkezdem majd olvasgatni.
Addig annyit tettem, hogy átállítottam nullable-re az összes változót, így a parser nem siránkozik. A db felírásokat is megcsinálja, csak sajnos a rekordok felírása után elszáll körkörös hivatkozással. Pislogok, hogy mi van. Megcsinálta, ott vannak a rekordok, miért kell kilépés helyett crashelnie?
-
martonx
veterán
Öööö ez a két tábla közötti kapcsolat így biztos jó???
Jól látod, a hibaüzenetet azért kapod, mert ezzel az elrontott tábla kapcsolattal seperc alatt körkörös referenciát érsz el
Feltételezem latest .Net 6-ot használsz, feltételezem default System.Text.Json-nal szerializálsz. Ez esetben itt van némi olvasnivaló, benne talán megoldással is a problémádra: System.Text.Json features in .NET 6 (okyrylchuk.dev)
-
coco2
őstag
C# + Asp + EF core, kérdés tábla kapcsolatok kezelésére (a webapi miatt van probléma):
Vannak olyan tábláim mint:
Egyik {
public int Id;
public List<Masik> Masikk; }Masik {
public int Id;
public List<Egyik> Egyikk; }Aztán kész a kontroller, app indít, swagger, post add, és kapok vissza egy ilyesmi hibaüzenetet:
"The JSON value could not be converted to api.Entities.Egyik. Path: $.Masikk[0].Egyikk[0] | LineNumber: ** | BytePositionInLine: **."
Amivel kicsit vakarom a buksit, hogy leírtam EF-nek sok-sok kapcsolatokat, oda-vissza kapcsolgatnék, és amikor weben adat létrehozásnál le kell írni ilyesmit, akkor a sok-sok kapcsolat miatt vagy körbeérősen végtelen lett a szitu, vagy azt mondja a webapi, hogy bocsi, nem tudok validálni.
Valami olyasmi kellene, hogy a tábla referenciákra ha kap értéket, parsingolja be, ami jelen van, de ne legyen megkövetelve semmi. Vagy bármi könnyen kezelhető megoldás - javaslatoknak örülnék.
Van rá valami kitalált okosság?
-
sisi22
aktív tag
elég kiküldeni egy tonna emialt, az egyik hülye úgy is rákattint a linkre, vagy megadja a jelszavát.
Minek emiallal (sic
) szorakozni, amikor "hulyek" tomkelege a bongeszoben tarolja az osszes jelszavat, 'oszt csodalkozik, amikor a virtualis coinjaik egyszerre csak atutalasra kerultek mashova, es attol kezdve eselye sincs panaszkodni se sehol? -
válasz
pmonitor
#17333
üzenetére
> Egyébként a ti "közösségetek" mit tart értékne
A kozossegrol nem tudok nyilatkozni, de nekem pl. ertek az, ha masoknak (vasarlo, ugyfel, munkaltato, vagy akarcsak egy kozosseg vagy szemely) valamifele erteket tudok adni. Ennek egyebkent az egyik fo indikatora (for-profit kornyezetben), ha fizetnek erte.
-
pmonitor
aktív tag
válasz
sztanozs
#17330
üzenetére
A (nem csak itt) fórumozó arcokról, és főleg a fórum(ok) szerepéről úgy általában más a véleményünk.
Arról, hogy ez nem C topik, az engem nem zavar. itt van pl . egy Vb.Net-es és 1 C# kódom is. Mivel nem törölték, ezért gondolom, hogy nyugodtan elférnek egymás mellett a C, Vb6, Vba, Vb.Net, C# meg mit'tomén milyen kódok is. De a C(vagy egyéb) topikokban sem látok túl sok kódot). Másrészt (főleg algoritmusos, de egyéb probléma esetén is) szóba jöhet(ne) a pszeudo kód is. Szóval a nyelv nem akadály!Egyébként a ti "közösségetek" mit tart értéknek? Mik a prioritásai? Mi a (szakmai) fórumról alkotott egységes véleménye? Mert az én véleményem ismerhetitek egyrészt innen, másrészt a webhelyemről - de szívesen összesítem itt is, ha kérnétek. A ti álláspontotokkal azonban nem vagyok tisztában. Így kívülről úgy látszik, hogy a fő irányvonalatok csak a rizsa(de meg lehet cáfolni, ha tudjátok).
-
fatal`
titán
válasz
pmonitor
#17325
üzenetére
De sajnos a ti "közösségetek"(is) kódolási impotenciában szenved. Nemhogy új produktumot tudna létrehozni(nem 120-ad rangú témában).
Az itteni közösség nagyrésze hetente (de lehet, hogy kevesebb idő alatt) több produktumot tesz le, mint te 1 hónap alatt, ugyanis ezért kapja a fizetését.Te valami álomvilágban élsz.
-
sztanozs
veterán
válasz
pmonitor
#17325
üzenetére
Ne haragudj, nem hiszem, hogy a fejlesztőként dolgozó, itt fórumozó arcok kódolási impotenciában szenvednének, hiszen valószínűleg (legalább is részben) ezért kapják a fizetésüket. Persze nem mindenki él meg ebből itt, de úgy vélem többen vannak, mint azt gondolod. Másrészt ez nem a C topik, hogy itt mindenki C programot optimalizáljon, ez egy általános programozási fórum, ahol gyakorlatilag megtalálsz mindenkit a C-től a VB6 programozóig; ráadásul a programok nagy része nem a nagy nyilvánosságnak készül, hogy valami honlapon (vagy a github publikus repójában fent legyen) - ezek hiányából ne vonj le túl mély következtetést.
-
válasz
pmonitor
#17325
üzenetére
Azért ha kérhetem ne magyarázzuk félre a dolgokat. Az első implementációval is jöttél, hogy mekkora ász vagy és kiderült, hogy korántsem működik úgy ahogy a régi, az általad lassúnak titulált implementáció.
Ezt most valahogy kifelejtetted a mondanivalódból és teljesen más kontextust teremtettél, de a lényeg megmaradt, hogy azt állítottam, hogy nem sikerül de te csakazértismegcsináltad.
-
coco2
őstag
válasz
fatal`
#17324
üzenetére
Igen, ef core, és attribútum lenne jobb (ebben az alkalmazásfejlesztési stílusban áttekinthetőbb, ha helyileg ott van, ahol az osztályt leírom). Primary key automatán van az "Id" név miatt. Amellé raktam még +1 kompozit indexet. Constraints nincs mellé. Talán kicsit biztonságosabb lenne azzal együtt.
-
pmonitor
aktív tag
Nem kellene, hogy minden programozó reggeltől estig az atoi-t(itoa-t) optimalizálja. De pl. az alap STL függvények optimalizálására eddig is több évtized állt rendelkezésre. Én mindenesetre büszke vagyok, hogy sikerült optimalizálnom, annak ellenére, hogy tisztában vagyok azzal, hogy ezzel nem váltottam meg a világot. De nagyon könnyű lebecsülni a szerepét. Főleg utólag. Nézzük, hogy mobal(tudomásom szerint az egyetlen, aki felvállalta magát, valamint több régi projektjét is megosztotta a nyilvánossággal) itt ezt írta:
>Vergődhetünk még itt de az atoi implementációnál 99%, hogy nem csinálsz jobbat
Nos, az 1% jött be. Én sem tudtam biztosan, hogy meg tudom csinálni, de nem adtam fel. És kovisoft konstruktív kritikáinak a segítségével végül is sikerült. De ezzel rámutattam arra is, hogy az STL függvények nem kőbe vésett, szent és sérthetetlenek. Legalábbis nem lenne szabad, hogy így tekintsünk rájuk. Jobb lenne, ha az STL függvényeit nem lehetne 90% futásidő alá optimalizálni. De ez az optimalizálás sem jelentené azt, hogy nem készülnének szoftverek. Mert az STL optimalizálásával csak pár (rendszer) programozót kötne le. A programozók több mint 99%-a nem ezzel foglalkozik/foglalkozna.
Egyébként én jobban örülnék, ha ez a "közösség"(ahogy sztanozs nevez titeket) több ilyen diskurzus eredményeképpen létrehozna új dolgokat. Olyanokat, ami szerintetek nem 120-ad rangú téma. Mert a kovisoft-al való diskurzusunk következtében létrejött 1 új dolog(produktum). És az általatok létrehozott(fontosabb témában alkotott) új produktumokat tudná alkalmazni más olvasó is. De sajnos a ti "közösségetek"(is) kódolási impotenciában szenved. Nemhogy új produktumot tudna létrehozni(nem 120-ad rangú témában).
Egy másik aspektusa a dolognak meg az, hogy ugyan szívesen emlegetitek az én atoi optimalizálásomat lekicsinylően, de pl. a Cutter programomat nem reklámozzátok így(a többi produktumomról nem is beszélve). Szóval jó lenne, ha ez az állítolagos "közösség" megmutatná, hogy nem csak rizsázni tud, hanem képes lenne vmi. új megalkotására. Ha ezt látnám, akkor hidd el, hogy nem hátráltatnám a "közösség" munkáját. -
fatal`
titán
de nincs annotation support (én nem találtam) kompozit key-t felvenni a primary key mellé, míg index-re van annotation support - szóval index-ként lett kategorizálva
Már az EF6 is tudott kompozit kulcsot attribútumon keresztül, úgyhogy kétlem, hogy ez igaz lenne.
Order property (EF6).
Ha jól látom, akkor EF Core alatt pedig a classra kell rakni az attribútumot, ebből szerintem lehet többet is:
[link]De ugyanígy fluent apival a modelbuilderen keresztül is lehet, nem muszáj attribútumot/annotációt használni.
Ahogy a kapcsolótáblákat is lehet a modelbuilderen keresztül indexelni és akkor kompozit primary key lesz rajta.
-
coco2
őstag
válasz
martonx
#17316
üzenetére
Az a tábla jelenleg 3 másik (a létszámuk később bővülni fog) tábla 1-1 sorához ad többlet információt azon a 3 dimenzión együttesen, és annak okán abban a táblában arra a 3 másik táblára foreign key van (a primary key / ID van bejegyezve). A szitu a sima indexekkel annyi, hogy azokat az EF automatán gyártotta, mert azt mondja, szerinte jók lesznek még valamire. Leszámítva a nagyon barkácsolást, fogalmam sincs, hogyan mondjam meg a migrations-nek, hogy ugyan ne gyártsa már le azokat az indexeket. Szóval ráhagytam. Ami a gyakorlatban tényleg jó lesz valamire, az a kompozit index, mert amikor abban a táblában keresni akarok, mind a 3 értéket tudni fogom. Apropó az az index igazából kompozit key, de nincs annotation support (én nem találtam) kompozit key-t felvenni a primary key mellé, míg index-re van annotation support - szóval index-ként lett kategorizálva. Hát, egy kicsit még szoknom kell a migrations rigolyáit. Lenne egy jó öreg lamp + phpmyadmin-om, nem lennének vele ilyen gondjaim, de most rám olvasták, hogy ezt kell szeretnem. Ennyi az összes nagy titok, nincs itt semmi misztérium, és végleg nem szakmai precizitáshoz van bármi köze a történetnek.
-
sztanozs
veterán
válasz
pmonitor
#17309
üzenetére
Vagy EÜ. szakrendelésen sorszám kérésnél a hölgyek azt mondják, hogy lassú a rendszer, és erre várunk. Vagy a patikában...
Ezek mondjuk nem webes gépek, de tény, hogy a hálózati kommunikációt nem volna nagy truváj rendesen összedobni, de általában ez sem sikerül (konkurencia kezelés).De csak biztonságosabb, és nem biztonságos. Nagy különbség! Valamint lásd, amit fentebb a tinik esetéről írtam. Az iráni uránfinomítókat is megtörték, pedig azok konkrétan semmilyen külső hálózatra nem voltak kötve. Az ember a leggyengébb lántszem legtöbbször, nem a gép, ez be kell látni. A 16 éves hackerek sem a gépet törték fel, ahnem a felhasználót (password reuse és phishing)...
Persze tény az is, hogy a hanyag programozó mindegy mit programoz, lokális kódot, vagy webes kódot, az eredmény így is úgy is sz@r lesz. -
Nem értem most miről írsz. Ezt írtad: "vagy mit matat a filesystemben". Hát ha dockerből futtatod akkor pontosan azt amit megengedsz neki.
Ha pedig dockerből futtatod akkor általában egy tűzfal mögött van. Akkor meg pontosan annyira kontrollált a környezet amennyire Te akarod.
Vagy most mit forgatunk ki a mondandómból?
-
pmonitor
aktív tag
Csak ezekben az esetekben azok, akiket lehülyézel, ők a Samsung-nál, Nvidia-nál stb... jelszóval rendelkező emberkék. Szóval akkor vagy mégsem olyan kvalifikáltak, vagy nem tudom... Meg a tiniknek amúgy is tudni kellene, hogy kiknek kell email-t küldeni, ráadásul még a munkahelyüket is...
-
fatal`
titán
válasz
martonx
#17316
üzenetére
Szerintem a lekérdezés módjától (vagy módjaitól) és gyakoriságától függ, hogy hogyan érdemes indexelni. Ha ugyarra a 3 oszlopra szűrsz mindig, akkor kompozit, mert egy selecten belül, egy táblán csak egy indexet fog használni.
Nyílván a saját use caseben ő tudja kimérni (esetleg query plannerrel).
Mondjuk én nem nagyon értem, hogy miért kell az indexeket is EF-fel generálni/generáltatni. Lehet írni hozzá custom migrációt is és akkor létrehozod kézzel.
-
martonx
veterán
Én már rég nem lepődök meg semmin, ilyet meg se akarok tippelni. Az biztos, hogy az egy szál kompozit index folyton buzerálva lesz, bármelyik oszlopban is változzon bármi, azaz íráskor vélhetően az 1 nagy kompozit index rosszabb lesz (aztán lehet, hogy ez is hibahatáron belül mérhetetlen eltérés csak). A külön külön index-ek meg lehet, hogy olvasáskor teljesítenek valamivel rosszabbul, de erre se vennék mérget. Ezért is kérdeztem a kollégát, hogy ha már ennyire szenved, hogy mindenáron egy nagy kompozit indexet akar, valóban kimérte, és drasztikusan jobb teljesítményt ad a kompozit index?
Szóval belőlem pusztán a szakmai kíváncsiság beszélt, mivel ott van a DB-je, remélhetőleg több millió adatsorokkal, könnyedén ki tudja mérni a különbséget a kétféle indexelési stratégia között. -
Ispy
nagyúr
válasz
pmonitor
#17309
üzenetére
A leggyengébb láncszem mindig is a humán tényező lesz, lehet akármilyen csilivili biztonság, manapság nem úgy törik a rendszereket, hogy fogják a kalapácsot, azt hajrá, elég kiküldeni egy tonna emialt, az egyik hülye úgy is rákattint a linkre, vagy megadja a jelszavát.
-
martonx
veterán
"A jelek szerint indexeket virtuálisan leírni, és később azokra hivatkozni az EF még nem tud" -
azóta is ezen gondolkozok: tényleg számít ez? Van 3 meződ, és mindegyiken van 1-1 index. Vagy van ugyanez a 3 meződ, és 1 komplex index van a három felett? Komolyan kérdezem, benchmarkot is megnéznék, hogy a valóságban mi a különbség a két megoldás között.
Mert én azt tippelem, hogy szinte semmi, bár lehet, hogy sok milliárd adatsornál már a szinte semmikre is van értelme optimalizálni, bár ott meg már úgysem ORM-ezik senki. -
coco2
őstag
válasz
pmonitor
#17309
üzenetére
Kifejlesztik az asp csodát az azúrra, és alá raknak egyetlen cpu magot a napi 135ezer felhasználónak, mert a többi pénzt valaki zsebre rakta. Nem lassabb az, mint amit a HW indokolttá tesz
Én is törtem fel 16-17 éves tiniként hálót. Akkor még "Novell Network"-nek hívták (a 3.11-es működött akkoriban a suliban), szóval szerintem van arra rálátásom, hogyan megy. Temérdek sok időm volt a meglévő doksikat olvasni, és kiszemeltem a leggyengébb pontot, amit emberi hiszékenység + tévedés + egy nagyon szégyentelen hazugsággal keresztül lehet törni. És elkövettem. Nem azért, hogy büszke legyek rá, hanem az izgalomért
Hogy egy egész évnyi erőfeszítésem ment rá egyetlen akcióra, az meg olyasmi, hogy időmilliomos voltam valódi kihívás nélkül, suli halál unalom, csajok frigidek, szóval a suli hálózatának biztonsága lett játékszer. Azóta a technológia fejlődött, de a társadalom nem. A suli még mindig halál unalom, a csajok még mindig frigidek, a fiatalok még mindig időmilliomosok valós kihívások nélkül. Én azt mondanám, a helyzet azóta is változatlan.@martonx:
Azóta megnéztem pár oktató videót, és mindenütt belepakoltak explicite extra mezőket, amikre az indexet rárakták. A jelek szerint indexeket virtuálisan leírni, és később azokra hivatkozni az EF még nem tud. Beletörődtem. -
pmonitor
aktív tag
Egyetértek Veled, és köszönöm a pontosítást.
#17305 sztanozs:
Tényleg nem olvastam utána. De ez az én feladatom lenne, vagy a Samsung Nvidia stb... fejlesztőinek(biztonsági szakembereinek) feladata lenne? Biztos vagyok benne, hogy az utóbbiaknak kellene/kellett volna... Másrészt meg a 16-17 éves tinik(!) törik fel azokat a rendszereket, amiket állítolag magasan kvalifikált, felnőtt "szakemberek" alkottak. Úgy látszik, hogy a tinik jobban utánaolvastak náluk(vagy többet/jobban használták a szürkeállományukat).
1.: Ahhoz képest lassú, mint amit a HW indokoltá tesz.
2.: Igen, van úgy. De nem 1 példát tudnék hozni a rendszer lassúságára. Pl. amikor a boltban kb. 1 percig(!) "gondolkodik" kártyaolvasás után, majd a végén kiköp valamit(van úgy, hogy végül is elfogadja a tranzakciót, de van úgy, hogy nem). Vagy EÜ. szakrendelésen sorszám kérésnél a hölgyek azt mondják, hogy lassú a rendszer, és erre várunk. Vagy a patikában... stb... stb... stb...
3.: "Minél távolabb van az üzleti logika a felhasználótól (minél több rétegen keresztül elérhető), annál biztonságosabb." -> De csak biztonságosabb, és nem biztonságos. Nagy különbség! Valamint lásd, amit fentebb a tinik esetéről írtam.De végül is coco2 jól összefoglalta a dolgot.
-
coco2
őstag
EF, migrations, indexelés. Google példák alapján nem találtam rá megoldást.
Vannak táblákat reprezentáló osztályaim, közöttük egy-egy relációk, az osztályokban 3-4 ilyesmi:
public TablaEgyik TablaEgyik { get; set; } = new TablaEgyik();
public TablaMasik TablaMasik { get; set; } = new TablaMasik();
public TablaHarmadik TablaHarmadik { get; set; } = new TablaHarmadik();(TablaEgyik, TablaMasik és TablaHarmadik mind létező osztályok.)
Az id-k összekapcsolása automatikusan megvan (ellenőriztem a kimenetben), de az indexelés csak egyesével van meg. Például van TablaEgyik, TablaMasik, TablaHarmadik táblám hozzákötve az EntityEgyik-hez. Az EntityEgyik-nek lesz külön oszlopa, ami a TablaEgyik kulcsához tárol értéket, meg lesz rá indexelés az EntityEgyik-ben, ami 3 külön kapcsolat esetén 3 külön index. Ilyesmi extra oszlopokat hoz létre: TablaEgyikId, TablaMasikId, TablaHarmadikId, és egyesével indexeket készít rájuk. De az jellegében Index1, és Index2, és Index3, és nem Index1 + Index2 + Index3. Kellene nekem összesített index is. Amikor megpróbálok valami ilyesmit:
modelBuilder.Entity<EntityEgyik>()
.HasKey(c => new { c.TablaEgyik, c.TablaMasik, c.TablaHarmadik });akkor azt kapom, hogy a TablaEgyik, TablaMasik, TablaHarmadik a db motor által nem támogatott típusok. A migrations-nek nem tudom megmondani, hogy a TablaEgyik, TablaMasik és TablaHarmadik mögött automatikusan beillesztett változókra ( TablaEgyikId, TablaMasikId, TablaHarmadikId ) készítsen kompozitot.
Létezik bármi trükk rá? Vagy fel kell adnom a kényelmet + fejlesztési szabadságfokot, explicite gyártanom le nekem azokat a kulcs mezőket, plusz utána "kézileg" kell megadnom a kapcsolatokat?
Nem lenne rossz, ha az explicit megadásokat megúszhatnám, mert azzal együtt minden kényelem is odavan, ami miatt egyáltalán a migrations-t (és az EF-et) érdemes használni.
Bármilyen ötletnek, olvasni való blognak / linknek örülnék.
(És bocsi a szerkesztés hiányáért. A régi szerkesztő egy kekec bughalmaz, az új szerkesztő meg egy trágya, nem tudom kiemelni a kódrészleteket kényelmesen.)
-
coco2
őstag
válasz
pmonitor
#17304
üzenetére
Egyik sem a web hibája, amiket írsz. A mai világban jellemzően soha semmire nincs se idő, se pénz, se hozzáértés, egy lerágott csontot akarnak még tovább rágni, és hús már nincs rajta, szóval a csont törik el. Kb az a szoftverfejlesztés jelene. Minden, amit fejlesztenek, biztonságtechnikában lukacsosabb, mint az ementáli sajtok. De az nem a web hibája. A bináris alkalmazások ugyan úgy hulladékok.
-
sztanozs
veterán
válasz
pmonitor
#17304
üzenetére
Szerintem csak nem olvastál ennek eléggé utána.
1. Mihez képest lassú - egy elosztott hálózat sokkal gyorsabb tud lenni, mint egy gép
2. Van hogy a gép sem működik. Több gép nagyobb valószínűséggel működik, mint egy. Természetesen be lehet építeni egyéb redundanciákat is (pl. több különálló hálózati kapcsolat). Az elmúlt 10-15 év tapasztalata alapján többet volt elérhetetlen az otthoni gépem frissítés vagy hardver hiba miatt, mint a működő internet hiánya miatt.
3. Alkalmazásfejlesztésnél alap a többrétegű architektúra, ami nem csökkenti, hanem növeli a biztonságot. Minél távolabb van az üzleti logika a felhasználótól (minél több rétegen keresztül elérhető), annál biztonságosabb. Ráadásul a fizikailag kompromittált gépek hálózat nélkül is elérhetők, és azokból később adat kinyerhető (vannak nagyon izgalmas side-channel technikák). -
pmonitor
aktív tag
A web-el kapcsolatban én(mint általában user) csak 1 előnyt tudok "felsorolni". Mégpedig azt, hogy hasznos funkciók vannak benne. Az összes többi csak hátrány:
1.: Lassú
2.: Van, hogy nem működik
3.: Nem biztonságos. Ha 1 gép rá csatlakozik a hálózatra, onnantól kezdve feltörhető(legalábbis, ha hasznos funkciója van). Arról nem is beszélve, hogy mindig akadnak okosabbak, mint a webfejlesztők(lásd pl. itt. Gyakorlatilag csak azt nem törik fel egyesek, amit nem akarnak. Az más kérdés, hogy ezt nyom nélkül nem tudják megtenni(mindennek nyoma van). Csak van, hogy nagyon sokáig tartana a "nyomozás". -
sztanozs
veterán
UAT alatt nagy vonalakban értettem a tesztelést. Amúgy ha nincs security vagy eovs miatt update akkor általában ezek nem is változnak funkcióváltozás nélkül.
Ha meg változik a funkció (és a fejlesztő frissíti a komponenseket), akkor ez nálunk is csak
- először fejlesztői, majd tesztkörnyezeten történhet (és csak sikeres tesztelés után mehet élesbe)
- teszt és éles környezetbe csak auditált repóból jöhet a dependencia -
-
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
) szorakozni, amikor "hulyek" tomkelege a bongeszoben tarolja az osszes jelszavat, 'oszt csodalkozik, amikor a virtualis coinjaik egyszerre csak atutalasra kerultek mashova, es attol kezdve eselye sincs panaszkodni se sehol?
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Amazon Kindle
- Napelem
- Renault, Dacia topik
- Méretes QD-OLED monitor jött az ASUS ROG-os portfóliójába
- WoW avagy World of Warcraft -=MMORPG=-
- Milyen routert?
- Samsung Galaxy Watch7 - kötelező kör
- Iszonyatos mennyiségű hulladékkal járhat a Windows 10 terméktámogatásának vége
- Hálózati / IP kamera
- Cyberpunk 2077
- További aktív témák...
- Szép Dell Precision 5560 Slim Tervező Vágó Laptop -70% 15,6" Xeon W-11955M 32/1TB RTX A2000 4GB FHD+
- UHH! Dell Precision 7560 Tervező Vágó Laptop -70% 15,6" i7-11850H 64/1TB NVIDIA A3000 6GB FHD
- Apple Watch Series 9 Celluláros
- Samsung Galaxy S25 Ultra 12/512GB, Titanium silver
- Nvidia RTX 4070 Gainward ghost Video Kártya
- AKCIÓ! HP USB C G5 Essential (5TW10AA) dokkoló hibátlan működéssel garanciával
- Epson Expression 12000 XL Nagyformátumú A3 szkenner
- DELL, HP gyári töltők, sok db. 7,4x5mm - 4,5x3mm + USB-C/Type-C 65W
- HPE Aruba PoE+ L3 switch raktárról azonnal elérhető!
- Új! Számla + 1-3ÉV Gari! Áfás! Gamer PC - Számítógép! I5 14400F / RTX 5070 / 32GB DDR5 / 1TB SSD M.2
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest