Hirdetés
- MasterDeeJay: Harc a DDR5 árak ellen
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- HUNNIA1920: Kínaiwebáruház, amit jobb elkerülni
- sh4d0w: Árnyékos sarok
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- eBay-es kütyük kis pénzért
- urandom0: Száműztem az AI-t az életemből
- btz: Internet fejlesztés országosan!
-
LOGOUT
Új hozzászólás Aktív témák
-
gergo5991
őstag
ma egy random app ötlet jutott eszembe, és geminivel rákérdeztem van-e ilyen a piacon stb, azt mondta kva jó ötlet, sok benne a fantázia, ilyen a piacon konkrétan nincs.
Nyilván minden igaz amit gemini mondott. Kérdésem az lenne, van itt valaki, akinek sikerült már ötletet pénzé tenni? de olyan szinten, hogy még egy file se lett létre hozva, magát az ötletet eladta. -
inf3rno
nagyúr
Én most spirális fraktál rajzolással küzdök. Nem vagyok annyira toppon a 3d geometriában, de haladok chatgpt segítségével. Néha úgy vagyok vele, hogy jobb lenne utána olvasni, mert túl okos akar lenni a chatgpt, és mindenféle hülyeséget összehord ahelyett, hogy a kérdésre válaszolna.
Fizetési rendszert hegesztek még, az eléggé lefáraszt. Még 2-3 hét van vissza abból a projektből. Remélem azért januárban végzek vele, mert már nagyon unom.
-
#20939
martonx
veterán
VikMorroHun
#20938
martonx
veterán
válasz
VikMorroHun
#20938
üzenetére
Ez tök jó, csak éppen továbbra sem írtál éppen semmi kontextust, hogy vajon milyen programnyelv, milyen keretrendszeréről beszélsz
Azért örülünk, hogy sikerült megoldanod valamit, valamiben, mutatókkal! -
#20938
VikMorroHun
őstag
inf3rno
#20930
VikMorroHun
őstag
válasz
inf3rno
#20930
üzenetére
Fun fact: miután leírtam a múltkoriakat, úgy döntöttem, elhagyom a mutatókat. Összesen 5 objektumról van szó, az kézzel is kezelhető. Szépen átírtam a függvényt switch/case szerkezetre (idejét sem tudom, mikor használtam ilyet utoljára); a 20-30 sorból lett 50+ sor, de működött. Miután
ezzel megvoltam, megértettem, mit is olvastam az egyik fórumon, amikor valakinek ilyen jellegű gondja támadt. A megoldás: mutatót kell használni. Igen, azt használtam, és nem működött. Ja, hogy az egész UI-t azzal kellene kezelni...
Ma este lettem készen vele. (De nem baj, hogy előtte annyit küzdöttem ezzel, mert a félig jó változat rávilágított néhány programhibára (amit ki tudja, mikor vettem volna észre nélküle), amik kijavítása meglehetősen fontos volt). -
válasz
cattus
#20936
üzenetére
Oké, az Angular is csak, csak nem az a useState/setState-es hülyeség, mint amilyen a React (és amilyen a Flutter). Egyszer írtam Flutterben egy egyszerű appot, két hétig volt fenn Play Store-ban, annyira megutáltam, hogy nem volt kedvem tovább fejleszteni. Már a forráskódja sincs meg.
Angular hagyományosan inkább a two way bindinget használja, mint pl. a JavaFX. Bár az igaz, hogy mióta vannak signalok, azóta ugyanott vagyunk, mint Reacttel.
-
cattus
addikt
válasz
urandom0
#20935
üzenetére
Az Angular is egy reactive framework.
Mostanra amúgy eljutottunk oda hogy a legtöbb frontent framework kb. ugyanazt a paradigmát implementálja minimális eltéréssel, pl. a Vue ref(), a React useState, az Angular signal() meg a Svelte $state() kb ugyanúgy működik / néz ki.
-
válasz
martonx
#20934
üzenetére
Azt gondolom, hogy ezeknél az ismertebb frameworkoknél (beleértve a React-et, Vue-t, Svelte-t, Angulart, stb.) tudsz valami jobbat.
A Vue szerintem egyértelműen programozó barátabb, mint a React, mondjuk nem nehéz annak lennie, mert a React a JSX-el együtt egy gány tákolmány (bugos is, lassú is). A Svelte-t nem ismerem, de jókat hallottam róla.
Én, ha most kezdenék frontendes projektbe, az összes ilyen reactive frameworköt kerülnék, és szerintem Angularral állnék neki. -
martonx
veterán
válasz
urandom0
#20932
üzenetére
Előre bocsátom, hogy böngészős és .Net vonalat ismerem. És ez azért erősen szubjektív tud lenni, pláne weben, ahol kismillió megoldás van ugyanarra.
Svelte és Vuejs ha böngészőről beszélünk (tudom, tudom ott a hype a React, előtte - mellette pedig az Angular, amik nem is rosszak, csak épp szerintem vannak náluk sokkal jobb megoldások).
.Net vonalon pedig a .Net Maui lett meglepően jó. -
#20930
inf3rno
nagyúr
VikMorroHun
#20929
inf3rno
nagyúr
válasz
VikMorroHun
#20929
üzenetére
A frontendet (fullstacket) az ilyenek miatt hagytam ott. Programozni nagyon szeretek, UI-t tákolni viszont nagyon utálok.
-
#20929
VikMorroHun
őstag
VikMorroHun
őstag
A programozás szépségei...
Van egy UI "ablak", ahol visszajelzést kap a felhasználó.
Ki akartam bővíteni, hogy belerakok néhány objektum mutatót, azokat meg egy tömbben kezelem.A következő változatokat sikerült összehozni:
- a tömb elemszáma folyamatosan nő (érdekes módon az indexek is, szóval a tényleges elemszám konstans, ahogy lennie kell, persze a ciklus 0-tól indul)
- jó a tömb elemszáma, de ha valami megváltozik, újrarajzolásnál szétesik a UI
- ha kihagyok egy utasítást az objektum mutatók létrehozásakor, amivel hozzáadnám őket a tömbhöz (mert látszólag kicsivel korábban már megtörtént), akkor minden remekül
működik, csak a tömb üres lesz, vagyis nem fogom tudni használni az objektum mutatókat (mert nincsenek). Bár a UI mutatja őket.
- látszólag minden remekül működik, nem esik szét a UI sem, csak ha leáll a program, memóriaszivárgás van.Olyan verziót még nem sikerült készíteni, hogy a fentiek közül egyik hiba se jöjjön elő.
-
-
coco2
őstag
És majd amikor a dap szerverei leállnak, mert "a kellemetlenségekért szíves elnézésüket kérjük" és társai, akkor a szolgáltatás határozatlan ideig elérhetetlen lesz, mert senki sem fog tudni bejelentkezni.
A közelmúltban volt valami kormányzati rendszerek leállásáról, amiről annyit hallottam nyilvánosan, hogy valami szerverben tönkrement egy alkatrész, és nagyon sajnálják. Csak kicsit kiröhögni való szakmai szemmel, hogy kormányzati szinten nem képesek 100.0% üzemstabilitást garantálni.
-
#20920
urandom0
őstag
VikMorroHun
#20916
válasz
VikMorroHun
#20916
üzenetére
Szerintem az ötleted jó, de az már nem a te scope-od, hogy a user megfelelően kezelje az e-mail fiókját. Egy fiók/user, 2FA, ... ezeknek azért elég alapvető dolgoknak kellene lennie manapság.
-
#20917
coco2
őstag
VikMorroHun
#20916
coco2
őstag
válasz
VikMorroHun
#20916
üzenetére
Szerintem nem kellene túl szakbarbárnak lenned.
Azokat a problémákat nem informatikailag, hanem jogilag kezelik. Ha a cég rááll email ellenőrzésre, általában belerakja a felhasználási feltételekbe, hogy a felhasználó elfogadja a teljes jogi és erkölcsi felelősséget annak az email címnek a biztonságban tartásáért, amit a titkos funkciókhoz használ, és ha azt a fiókot feltörik, akkor azért ugyan úgy felel, mintha ő maga szándékosan követte volna el mindazokat a cselekményeket, amiket idegen személy követett el. És ott a pont.
A te gondolkodásodban ott a hiba, hogy a dáp is csak jelszavas. Egy jelszó helyett kettőt kell elkapni, esetleg hármat, esetleg még egy mobil számot is lenyúlni, igen, még több védelem, de végső soron egy patchwork, aminek sehol sincsen vége. Nincsen lezárva a kérdés. Kérdőjel van a sor végén ("mi van ha még azt is.. ?"), és nem pont ("lenyeled."), ami egy cég tevékenységét kiszámíthatatlanabbá teszi a jogi kockázatok miatt (beperelik, hogy a cég volt trehány, mert szoftver hiba és a többi).
Szóval nem. Nincsen igazad
Amit mégis ellenőrizhetsz, hogy a felhasználási feltételek és a jogi felelősség összhangban van-e kezelve az informatikai szerelékkel. Ha az nincsen meg, na azért viszont nyafoghatsz a főnöknek, hogy mégis mi az a trehányság?
-
#20916
VikMorroHun
őstag
VikMorroHun
őstag
Kiberbiztonság Magyarországon 2025-ben:
Cég: létrehoztunk egy portált, ahol az ügyfelek hozzáférhetnek (érzékeny) ügyféladatokhoz, és néhány dolgot meg is változtathatnak. Fontos, hogy megerősített e-mail címük legyen az adatbázisban, mert oda megy az értesítés, a jelszógenerálási utasításokkal együtt.
Én: Mi lenne, ha integrálnánk a DÁP-ot, mint erős ügyfél hitelesítő alkalmazást a rendszerbe?
Cég: Nem, az e-mail cím a tuti.
Az nem derült ki, hogy mi van, ha
- többen használnak egy e-mail postafiókot
- valaki bekap egy adathalász e-mailt, esetleg keyloggert is
- egy szakértőnek kedve szottyan jelszótörést gyakorolni (mindenkinél más, de mégis ismert a kiindulási adat és a jelszógenerálási módszer) -
Lien
aktív tag
Sziasztok, az itteni fórumozók véleményére lennék kíváncsi, akik jártasak a manuális szoftvertesztelésben. Mit láttok, vajon érdemes ebbe tanfolyamok nélkül, videókat, adatokat halászva belemélyednj, esetleg ebbe az irányba átképeznie magát az embernek? Milyen lesz a jövőbeli kilátása ennek a szakmának? Volt lehetôségem egy nagyon kedves ismerősöm napi munkájába belenézni, hogy milyen és még ha monoton is tetszene. Azért egy automata tesztelés nulla programozói tudással nem menne max sokkal később.
-
inf3rno
nagyúr
válasz
inf3rno
#20908
üzenetére
Mértem még közben egy bulk insertet. Az talán 5%-al gyorsabb, mint a JSON-os megoldás, viszont közel sem annyira kényelmes ér rugalmas, mint az INSERT SELECT a JSON-al, úgyhogy komplexebb helyzetekben nincs is igazán értelme foglalkozni vele.
Ami még érdekes itt, hogy egyes dátumokra mentek értékeket. Aztán bizonyos tábláknál összefüggő dátum tartományok alakulhatnak ki, amiknél azonos az érték. Azt találtam, hogyha 5+ dátumot átfog egy átlagos tartomány, akkor már megéri from-to tárolni, mert jóval gyorsabb az írása és az olvasása is. Batchben frissíteni úgy, hogy ne fragmentálódjon közepesen bonyolult, de azért megoldható.
Így bizonyos tábláknál a sima 100-as tranzakciós megoldáshoz képest 50x-es írási sebesség is elérhető. Ez kb. olyan, mintha 1 perc alatt bemenne, ami most 1 órába telik. Azért az nem semmi. A problémásabb tábláknál is 5-10 perc, ami várható 1 óra helyett.
-
inf3rno
nagyúr
válasz
dabadab
#20901
üzenetére
Na benchmarkoltam, egyelőre csak annyit, hogy 10.000 rekord van, és másik 10.000-el írjuk felül INSERT ON DUPLICATE KEY UPDATE-el. A sebességek ilyenek voltak:
- egyesével beküldve: 6.000 record/sec
- tranzakcióban beküldve 100-as kötegekben: 10.000 record/sec
- tranzakcióban beküldve 250-es kötegekben: 10.000 record/sec
- JSON-ban beküldve CTE-vel 100-as kötegekben: 80.000 record/sec
- JSON-ban beküldve CTE-vel 250-es kötegekben: 95.000 record/sec
- JSON-ban beküldve CTE-vel 10.000-es kötegekben: 110.000 record/secNekem ebből az jött le, hogy JSON-ban fogom beküldeni CTE-vel ahelyett, hogy tranzakcióval szarakodnék. A 250-es köteg tűnik optimálisnak. Annyi talán még elveszhet, ha valami nagyon félrecsúszik, nem zabál annyi memóriát és sebességben elég közel van a 10.000-es köteghez.
Még csinálok majd egy 4. változatot, aminél először SELECT FOR UPDATE-el lekérem, hogy mi változott, aztán csak utána tolom rá az INSERT ON DUPLICATE KEY UPDATE-et. Így le tudom naplózni a tényleges változásokat is. De ezt csak akkor lépem meg, ha nem annyira lassú, mondjuk hozza legalább az egyszerűbb JSON-os változat 80%-át sebességben.
-
Sonja
nagyúr
Érdekes programozási nyelvet találtam.
"The only compiled language that lets you code with "sus", "slay", and "vibez" while achieving near-c performance."
-
inf3rno
nagyúr
válasz
dabadab
#20901
üzenetére
Hát benchmarknál arra gondoltam, hogy beviszek 10 millió rekordot, aztán beküldök újabb 10 milliót úgy, hogy abból 50k ami tényleges változtatás. Nagyjából valami ilyesmire lehet készülni, max 25 millióra. Igazából a 100 az ilyen hasraütésre született vagy nem tudom mi volt a megfontolás mögötte, simán lehet, hogy 1000 vagy 10000 lesz helyette, most tervezzük újra a rendszert.
-
inf3rno
nagyúr
Nem akarok itt komplett SQL-t írni. Nagyjából úgy néz ki, hogy a SELECT-be rakok egy JSON-t a 100 értékről, azt beparsolja, aztán INNER JOIN-al illesztem a meglévő táblára az értékeket az ON részében meg lesznek a kulcsok meg az, hogyha az érték eltérő, akkor kerüljön csak kiválasztásra. Az INSERT ON DUPLICATE KEY UPDATE meg erre a kiválasztott halmazra íródik.
A 3-as jó lenne, de tudok nélküle élni.
Igazából csak kíváncsi voltam kinek mi a véleménye, megérzése. Így is úgy is le fogom benchmarkolni legalább az első kettőt.
-
#20903
JoinR
őstag
VikMorroHun
#20902
JoinR
őstag
válasz
VikMorroHun
#20902
üzenetére
Van benne egy kis programminghorror vibe.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#20902
VikMorroHun
őstag
VikMorroHun
őstag
Ha már log:
A programom 8-10 példányban fut egyszerre, de néha egyik-másik meghibásodik valamiért (nem jöttem rá, mitől). Nincs hibaüzenet, nincs összeomlás, egyszerűen csak megáll, és nem csinál semmit. Eléggé véletlenszerű a dolog; tesztelésnél nem jelentkezik, csak élesben, viszont sok pénzbe kerülhet, ha előfordul, úgyhogy csináltam egy kis log filet, amibe folyamatosan irkálják a dolgaikat, és mindegyik tudja ellenőrizni az összes többit. Ha valamelyik azt látja, hogy leállt az egyik, akkor újraindítja. Tök jó, működik (és így az is kiderült, hogy naponta többször is előfordul ez a hiba). Az egyiket én magam állítottam le, mert nincs rá szükség. A naplóban viszont benne maradt, és buzgón "indították is újra" a nem létező programot. Ok, írtam hozzá egy ellenőrző függvényt, hogy ha valami nem létezik, akkor ne akarják újraindítani, akkor se, ha a naplóban van róla adat. Eredmény: csak fél óránként próbálják újraindítani. Néha egy óráig semmi, aztán valamelyiknek megint feltűnik, hogy nini, hiszen ez leállt, akkor újraindítjuk! Ma írtam hozzá egy másik függvényt, ami kiüti a nem létező programhoz tartozó azonosítót a naplóból, hátha így már nem akarják újraindítani. Kíváncsi vagyok, mi lesz a jövő héten. Nyilván, ha törlöm a naplót, akkor nincs adat, ami alapján újraindítanák a nem létező programpéldányt, de azért kíváncsi vagyok, sikerül-e végre rendesen megcsinálni...
-
válasz
inf3rno
#20898
üzenetére
Teljesen tippre az első tűnik a gyorsabbnak, de 100 értéknél tulajdonképpen mindegy is.
Ha viszont tényleg le akarod mérni, hogy a te konkrét adatbázisodnál, a te adataiddal melyik a gyorsabb, akkor meg kapcsold be a slowlogot (egy long_query_time=0 után minden query slow querynek fog számítani) és nézd meg.
ezzel megvoltam, megértettem, mit is olvastam az egyik fórumon, amikor valakinek ilyen jellegű gondja támadt. A megoldás: mutatót kell használni. Igen, azt használtam, és nem működött. Ja, hogy az egész UI-t azzal kellene kezelni...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- High-End AMD Ryzen 9 9950X3D, ASRock X870E Taichi + Dell AlienWare AW2725DF + ajándékok
- 24,5"-os FullHD Dell Alienware gamer monitor újszerű állapotban AW2518HF
- GAMER LAPTOP - ASUS Rog Zephyrus M16 / Intel i7 12700 / RTX 3060 6gb / 24gb DDR5 / 2TB ssd
- Gigabyte GA-H110M-S2PV PC 7. gen i5 proci, 240 GB SSD, Jogtiszta Windows 11
- Gamer PC - Z790 / i5 13600 KF / 32 GB / 2 TB / RTX 3080
- Samsung Galaxy A17 5G / 8/256GB / 12Hó Garancia / Kártyafüggetlen / Akku 100%
- Új, Aktiválatlan, iPhone 15 (128 GB) (rendelhető)
- Xiaomi 14T 256GB, Kártyafüggetlen, 1 Év Garanciaval
- GYÖNYÖRŰ iPhone 13 Mini 128GB Midnight - 1 ÉV GARANCIA -Kártyafüggetlen, MS4195, 94% Akksi
- REFURBISHED és ÚJ - HP USB-C/A Universal Dock G2 (5TW13AA) (DisplayLink)
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest