-
IT café
Új hozzászólás Aktív témák
-
martonx
veterán
válasz lenkei83 #16465 üzenetére
"De malfunction esetén ez akár be is ragadhat, ha pl feladatkezelőn keresztül bezárom a progit." - ez nem így van. Ebben az esetben SQL oldalon is el fog halni elég gyorsan az ide tartozó session. Az adatbázist ugye using-al használod? Azaz automatikusan dispose-oldóik? És ennek semmi köze Asp.Net hez
Értem én, hogy valamit alapvetően rosszul írtál meg, és most nem ezt akarod kijavítani, hanem űrhajót építeni köré
Hidd el, mindenkinek jobb lesz, ha a kódodat javítod, ahelyett hogy űrhajót építenél.
SQL session-ök lekérdezése és erőltetett bezárása simán megoldható: KILL SPID command in SQL Server (sqlshack.com)De hidd el, neked nem ez kell, hanem egy jól működő programkód, ami nem hagy szemetet maga után.
Én kérek elnézést!
-
martonx
veterán
válasz lenkei83 #16467 üzenetére
Éppen most kezdesz eljutni a felismerésig, hogy ehhez egy alkalmazás szerver fog kelleni. Pedig te csak egy fapados session kezelést szerettél volna. Hát így jön ide az űrhajó.
Egy kókány módszert azért megléphetsz űrhajó építés előtt. Csinálj egy SQL jobot, amit utemezve tudsz futtatni, és az majd átállítja az inaktív usereket.Én kérek elnézést!
-
martonx
veterán
válasz lenkei83 #16475 üzenetére
User ellenőrzés szintjén úgy működhetne, hogy a user aktivitásakor ezt a táblát, amiben a Ture/False-t váltogatod, updatelnél egy mondjuk LastActivity timestamp mezőt.
Azt SQL job meg azt aki aktív, de a LastActivity-je mondjuk fél óránál régebbi, zokszó nélkül átállítja False-ra.Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #16566 üzenetére
Viszonyításképpen nekem Ryzen 7 5800x-en, 1 TB-s X4 m.2-es SSD-n, úgy indul a VS, mint az álom. Hol lassú ez? Szvsz iszonyat gyors. És a build idők is röhejesen alacsonyak. Igaz töbnyire Microservice-ekkel, meg Web API-kkal foglalkozok.
Ja, és a telepítés kevesebb, mint 7 GB-t foglal.Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #16611 üzenetére
Hagy mondjak egy személyes példát.
Megrendelőnek volt egy utazáskereső rendszere, aminek már sok fejlesztő csapat nekifutott, a legjobb aki előttünk volt 2 perces keresés válaszidőket tudott felmutatni, nulla szűrési feltételekkel, hibás listázással stb...
Utána szerződött velünk, és az volt a kikötése, hogy 30 másodperc alatt érkezzenek meg a keresésre a válaszok, működő szűrésekkel, hibátlanul.
Megoldottuk neki C#-al, hogy 40 ms (igen fél perc volt az elvárás, és 40 milisec alatt jönnek a válaszok) alatt érkeznek a válaszok, vicc szerver terheléssel, minden szerződéses határidőt betartottunk. Az ügyfél szuper elégedett volt.
Vajon tényleg ennyire elégedett lett volna, ha tízszer ennyi idő alatt, tízszer ennyi pénzből oldjuk meg a feladatot C-vel / assembly-vel, és cserébe 2 ms alatt jönnek a válaszok?
Nem igazán hinném.Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #16616 üzenetére
"De sztem. az elég sokszor előfordul, hogy tömegesen kell számokat szövegre konvertálni." -
Szerinted. A valóságban meg nem legalábbis semmiképpen sem tömegesen. Néha 1-1 logban nyilván szövegesen iratod ki a számokat is, de kb. ennyi (a nyilvánvaló programozói hibákat, helytene adat modellezést leszámítva).Én kérek elnézést!
-
martonx
veterán
-
martonx
veterán
-
martonx
veterán
válasz pmonitor #16775 üzenetére
"A fejlesztők úgyis elkergetnének, hiszen a programozókat nem érdekli a sebesség, és a méret/helypazarlás(lásd az elején belinkelt sztanozs hozzászólást -- is)."
Tessék egy link, hogy a nyelvek fejlesztőit mennyire nem érdekli a teljesítmény: [link]Mondod ezt úgy, hogy soha nem próbáltál meg PR-t beküldeni. Gratulálok
Én kérek elnézést!
-
martonx
veterán
Ez alapján amit leírtál, akkor is igaz, hogy ezeknek az adatoknak a jelentős része nem fog percenként változni. Márpedig ami nem fog percenként változni, azt teljesen felesleges realtime lekéregetni. Nyilván a konkrétumok ismerete nélkül én úgy csinálnám, hogy a 90% mehet cache-ből, és elég lenne csak a 10%-ot realtime lekérni.
Én kérek elnézést!
-
martonx
veterán
válasz sztanozs #16835 üzenetére
Nyilván, de Tapsi ezzel kezdte a probléma felvetést:
"A leggyorsabb futásidő 30 másodperc, ezt kéne levinni <1-re."
Persze, ez annyira tipikus üzlet, mindenből friss adat kell, és ráadásul lassú se lehet
Amúgy meg teljesen jó a probléma felvetés, mert pmonitor nagyon kezdett félre menni a string - int konverziók sebességével, miközben a való életben SOHA nem ez az igazi problémaÉn kérek elnézést!
-
martonx
veterán
dolgoztam bankoknak, OTP-nél egy időben még külsős IT tanácsadó is voltam pont ilyen esetekre (mert én is csak egy nick vagyok aki ugatja a szakmát, mert nem atoi-t optimalizálok hehehe).
De mindegy is, semmi értelme egy ilyen fórum keretein belül mélyebbre mennünk. Írtál egy problémát, páran írtunk lehetséges megoldási javaslatokat, aztán ebből mindenki azt hoz ki, amit a lehetőségei, képességei (bankokat ismerve és pár kivételt mélyen tisztelve de a többség inkompetens, kezdve a menedzsmenttől, a programozókig) és a projekt scope-ja engednek.
Számomra az egészből egyedül az volt a lényeg, és amiért nagyon hálás is vagyok neked, hogy @pmonitorral ellentétben hoztál egy valós életbeli programozói problémát, szemléltetve, hogy nem az atoi-val kell szórakozni, hanem olyan robosztus rendszereket írni, tervezni, amik valós ügyfél problémákra reagálnak.Én kérek elnézést!
-
martonx
veterán
Előző, nem banki munkahelyemen, meg rendszeresek voltak a több milliárd soros DB táblák. Ott is észnél kellett lenni, minden egyes SQL lekérdezésnél, és nyilván egy 2 TB-os DB táblát cachelni se lehet vagy legalábbis észnél kell lenni, hogy mit, mikor, milyen aggregáltsági szinten cachel az ember.
Azaz amikor cachelésről beszélünk, ne arra gondolj, hogy oké lerántom a táblát memóriába, és probléma megoldva. Ennél a valóság az esetek többségében nyilván bonyolultabb (bár kis rendszereknél, ez nyilván egy könnyű járható út).Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #16886 üzenetére
"Ha van egy autóm, amiben nekem nem tetszik valami, akkor tervezzem át, küldjem be a gyártónak, és várjak, hogy elfogadják-e, mi?"
Ez a példa ott megy borzasztóan félre, hogy egy autónál még a garanciát is bukod, ha elkezded buherálni. Ellenben az Open source programnyelvek azért open source-ok, hogy BÁRKI jobbá tehesse, azaz ezeknél szinte elvárás, hogy ha valamit jobban tudsz, akkor már küldöd is a PR-t github-ra. Minden más csak okoskodás.
Én kérek elnézést!
-
-
martonx
veterán
válasz pmonitor #16939 üzenetére
Ha ennyire ráérsz, és szeretnél egy igazi való világbeli problémában segíteni, akkor írj egy managed (csak C#-os, azon belül is .Net Standard 2.1-es) HTML to Image konvertert (és nyilván annál jobb, minél optimalizáltabb).
Ez jó kiindulási alap: ArthurHub/HTML-Renderer: Cross framework (WinForms/WPF/PDF/Metro/Mono/etc.), Multipurpose (UI Controls / Image generation / PDF generation / etc.), 100% managed (C#), High performance HTML Rendering library. (github.com)
Végre valami hasznosat programozhatsz!
Garantálom, hogy nem csak én, de több ezer másik C# fejlesztő is használni fogja, amit csinálsz, és nagyon hálásak leszünk érte!Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #16942 üzenetére
"Vagy hogy hogy nem tudja 'kend ezt megcsinálni?" - tekintve az általam linkelt kiindulási alapot, nem a tudással van a bajom, hanem az idővel
Te meg látványosan unatkozni látszol, gondoltam feldobok egy feladatot, amivel végre igazán hasznossá teheted a szabadidődet, és végre olyat programozhatsz, amit nem megmosolyognak a többiek, hanem elismerően csettintenek. Mondjuk nem lep meg, hogy inkább passzolod, jogos, csináld meg inkább még négyszer az itoa-t.Én kérek elnézést!
-
-
martonx
veterán
No pont ezért nem akartam belemenni a var vs mindig írjuk ki szépen az akár kilométer hosszú típusokat is témába. Teljesen egyértelmű, hogy melyik a jó megoldás, de hitvitában úgysem lehet meggyőzni észérvekkel a másikat.
Én kérek elnézést!
-
martonx
veterán
Windowshoz kettő ingyenes, és egészen jó (noha nem hibátlan, és nem mindenható) git kliens van szerintem:
Fork - a fast and friendly git client for Mac and Windows (git-fork.com)
Sourcetree | Free Git GUI for Mac and Windows (sourcetreeapp.com)Hogy átszokni mekkora dolog, azt nem tudom, soha (na jó ez nem igaz, mert 15 évvel ezelőtt a karrierem kezdetén 4 évig használtam) nem használtam SVN-t.
Én kérek elnézést!
-
martonx
veterán
válasz Sokimm #17174 üzenetére
Szia!
Én meg a kérdésedet nem értem. Ha Web API-t akarsz, akkor hogy jönnek ehhez css, meg html file-ok?
A web api tisztán szerver oldal. Konzolba beírod:
dotnet new webapi
és voilá, nem kell feltételezni, meg érdeklődni, hanem megnézni, hogy milyen kiinduló kód generálódik
Hogy szerverre kell-e .net "csomag" (amit inkább SDK-nak vagy Runtime-nak illik hívni programozói körökben), az a kód publikálásodon múlik, több lehetőség is van. Van, amikor kell, van amikor a buildelt, deployolt kód magába foglalja a runtime-ot is.
Én mostanában docker image-re szoktam rá, hogy ekként publikálom, így garantáltan bármilyen futtató környezeten elfut (AWS, Azure, Heroku, bármi, ami docker image-et tud futtatni).Én kérek elnézést!
-
martonx
veterán
"core sdk kliens oldali támogatottság"
Web forms nincs, megszűnt, vége hála istennek.Ha azt érted a szokásosan zavaros kérdésed alatt, hogy mennyi támogatást ad az ASP.NET Core a html rendereléshez, akkor a Razor kimondottan hasznos! Viszont manapság erre már nem is a backendet szokták használni, hanem angular, react, vue javascript rendszereket.
Én php-vel semmilyen projektnek nem állnék neki, ha c#-al is lehet. És nem is feltétlenül azért mert gyorsabban lesz kész a projekt (php-s kókányolásnál biztos, hogy nincs gyorsabb), hanem a kód minőség, karbantarthatóság, szerver erőforrás kímélet miatt.
Én kérek elnézést!
-
martonx
veterán
Mondjuk akkor már érdemes lehet kipróbálnod C# vonalon a WebAssembly-t, ami Blazor néven fut. Nem vagyok elájulva tőle, de ha nagyon nem akarsz javascriptelni (meg ha nem fontos a pagespeed, és a Seo), akkor egész érdekes alternatíva tud lenni.
jquery abszolút felejtős.Én kérek elnézést!
-
martonx
veterán
"Webassembly-t nem pont a sebesség miatt találták ki? És pont az a gyenge pontja Ejnye, mi történt?" - az történt, hogy a webassembly tök gyors, meg csili-vili, éppen csak egy dolgot nem tud: DOM-ot manipulálni, ami a böngészőben lássuk be, elég nagy hiányosság.
Így aztán lassú, mint a szar, mihelyst javascript helyett akarod használni, hiszen szerencsétlennek, mindenért a javascript motort kell abajgatni, hogy ugyan rendereld már ki ezt, módosítsd már át azt...
Amellett, hogy a js natívan fut a böngészőkben, a Webassembly-nek még egy pár Mbyte-os futtatót is le kell húznia, ami érthetően nem tesz jót a pageloadnak.
Szóval szar lett, na.
Admin screenekhez, dashboardokhoz azért elég jó tud lenni (már ha a gyerek betegségeket pl. normális hot realod sikerülne kinőni), ahol nem gond, ha plusz 2 másodperc az oldal betöltési ideje, és nem dőlünk a kardunkba, ha nem atom gyors a renderelés, és az ember semmiképpen sem akarja javascripttel (vagy a még fájdalmasabb typescripttel) beszennyezni a kezét."egyszóval alkalmazás fejesztéshez sebességet adna" - pont erre való a vuejs, angular, react és a hozzájuk létező libek.
Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #17199 üzenetére
Nem.
Azt magyarázzuk, hogy probléma függő, hogy számít-e a sebesség. Nagyon sokszor nem számít. Az a fajta sebesség optimalizáció, amin te szoktál lovagolni, még annyiszor se számít. Amúgy meg WebAssembly-ről beszéltem, ahol ha értetted megint nem az itoa volt lassú :D
WebAssembly-t kérdezték leírtam mik a hátrányai, sőt azt is, hogy ezek mikor igazán hátrányok. Nyilván csomó esetben meg nem számítanak.
Azaz webshopos, Seo-ra kihegyezett oldalakat öngyilkosság WebAssembly-vel csinálni, mert Google pagespeed lepontoz a futtató környezet betöltése miatt. Miközben kismillió eset van, amire ettől még tök jó a WebAssembly (webes játékok, 3d-s webes grafika, admin screenek stb...).
Így már érthető?Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #17214 üzenetére
Szövegértés, szövegértés
Én következetesen lekicsinylettem a szerepét, ettől függetlenül, ahogy abban a hsz-emben is elismertem, hogy vannak akik ennek az optimalizálásával foglalkoznak, és azt is elismertem, hogy van hova gyorsítani.
Mutasd meg hol írtam, hogy szerintem ez tényleg probléma, és egyébként tényleg szükség van az optimalizálásáraÉn kérek elnézést!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- APPLE MacBook Air 2020 13" Retina - M1 / 8GB / 256 GB SSD / MAGYAR / 96% akku, 81 ciklus / Garancia
- LG NanoCell 55NANO766QA Halvány píxel csík
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!