- Milyen RAM-ot vegyek?
- Az előírások megszegése miatt éghet le egyes alaplapokon a Socket AM5 foglalat
- Gaming notebook topik
- OLED TV topic
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen házat vegyek?
- Jól felszerelt, csúcskategóriás külső videokártya jött a Gigabyte zászlaja alatt
- Külső 3,5'' mobil rack-ek topikja
-
PROHARDVER!
Új hozzászólás Aktív témák
-
-
repvez
addikt
válasz
#39560925
#9337
üzenetére
oké a pyton,de ha egy komplett windowsos progit akarok majd később csinálni akkor szinte a nulláról kezdhetem el a C++ példáil,mert a kódszavak nem ugyan azok avgy nem ugyan azt a funkciót csinálják.
Pytonnal eddig még csak scriptekként találkoztam a 3d modellező progiknál.
-
inf3rno
nagyúr
válasz
#39560925
#9152
üzenetére
Nem vágom ezt a kotlin dolgot meg a java-t. Szerintem azért gondold át, hogy a kliensnek JSON kell. Szóval ha objektumban tárolod, és minden kérésnél JSON szerializálod, akkor az lassít. Az objektum gráfot akkor éri meg a JSON meg az adatbázis közé tenni, ha az egyes részeit eltérő időben frissíted az adatbázisból, vagy ha a kliensek csak egy-egy részét kérik le. Ilyenkor is érdemes JSON formában eltárolni a gyakori kliens kérésekhez küldött válaszokat, ha van rá elég memória, meg ha túl nagy a terhelés a szerializálás miatt. Mérni kellene.
Ohh most olvasom, hogy eleve JSON-t tárolsz le. Akkor minek futni még egy kört a parsolással és újra szerializálással?
-
inf3rno
nagyúr
válasz
#39560925
#9146
üzenetére
Szerintem mindenképp előnyösebb a memória. Fájlba csak akkor van értelme menteni, ha túl nagy vagy ha history-t akarsz több fájlból.
A stateless-nél arra kell figyelni, hogy a client state-et ne tárold a service-ben, akkor is menjen két egymás utáni kérés, ha közöttük újraindítod a szervert, vagy éppen eltérő instance kezeli a két kérést.
Az authentikációt, authorizációt ugyanígy érdemes memóriába kesselni, hogy ne kelljen minden kérésnél az adatbázisból kiolvasni a felhasználó vagy a kliens jogait a felh név és jelszó vagy éppen az access token alapján.
A HTTP cache-t akkor tudod használni, ha több service van egymásra rétegezve aka. layered system. Ilyenkor az aktuális kliens mindig az eggyel alatta lévő réteg service-eit hívja, és tudja kesselni a válaszukat. Így az alsóbb rétegek, amik az adatbázisokhoz közelebb vannak, kevesebb terhelést kapnak. Ha nálad a kliens 3rd party, akkor nem tudod kiharcolni, hogy az is kesseljen, szóval lényegtelen. Ha te írod a klienseket is, akkor viszont érdemes beleépíteni.
Igazából ezek a REST constraint-ek csak akkor működnek, ha tényleg komoly terhelést kap (vagy fog kapni) az alkalmazás. -
bambano
titán
válasz
#39560925
#9152
üzenetére
a vps-re gondolom nem windowst akarsz rakni, hogy szanaszéjjel törjék?
ha ilyen memcached meg hasonló csodákat raksz az architektúrába, akkor annak a kódja is visz el a ramból, azt a programot is ütemezni kell, stb. tehát ha kevés a lóerő, akkor érdemes kidobálni a ballasztot.
ja, és miért vársz a mysql json-ra, mikor a postgres ezer éve tudja?
-
-
bambano
titán
-
inf3rno
nagyúr
válasz
#39560925
#9143
üzenetére
A HTTP cache nem böngészőfüggő dolog, bármilyen klienshez hozzá lehet csapni.
View-okkal gyorsabban menne a JSON előállítása, cserébe valamivel lassabb lenne az írás.
Eléggé képben vagyok a stateless constraint-el kapcsolatban, a memória kérések kesselésére történő használata semmiben nem mond ellent neki.
-
inf3rno
nagyúr
válasz
#39560925
#9136
üzenetére
Ezt az állapot kerül a szerverbe témát kifejthetnéd, hogy miért probléma. Hozz létre timestamp alapján fájlt, aztán akkor nem kell izgulni, hogy mi van, ha felülírod az előzőt. Gondolom pár json fájlba nem szakad bele a szerver, meg be tudsz lőni egy cache gc-t, ami törli őket bizonyos időközönként. Adatbázisban is meg lehet oldani view-okkal, ha csak néhány query-ről van szó, illetve gondolom létezik olyan, hogy query cache vagy ilyesmi. Annyi extra, hogy talán nagyobb lesz a latency, ha az adatbázis más gépen van. Egy HTTP cache-t mindenképp tegyél be mellé, ami modified-since headert nézi. Nem tűnik bonyolult feladatnak ez az egész.
-
bambano
titán
válasz
#39560925
#9136
üzenetére
szerintem web szerver adatterületére kell kigenerálni a statisztikákat.
rendes fájlrendszernél nincs probléma abból, hogy az egyik szál kiszolgálja a fájlt, a másik meg letörli vagy újraírja. max. abból lehet gond, hogy újraírás közben kezdi letölteni, mert akkor lehet, a végét nem kapja meg a kliens.ilyenkor szokás temporális fájlba generálni az eredményt és egy move utasítással a helyére tenni.
-
-
martonx
veterán
válasz
#39560925
#9132
üzenetére
Az 1Gb ram miatt én bármilyen fapados is, de a lementett statisztikát simán file-ban tárolnám. Ha jól értem ez nem más mint egy nagy Json adat.
Ha bőven lenne ram a gépben, akkor javasolnám a redis, memcache- meg ilyesmik használatát. Bár azt sem tudjuk, hogy mekkora adatról van szó, mert ha pár száz Kbyte, akkor vélhetően simán elfér a memóriában is. -
-
inf3rno
nagyúr
válasz
#39560925
#8912
üzenetére
Szvsz ebből a saját translator ami húzós. Ahogy nézem OCR-el dunát lehet rekeszteni. Legózásban azért OCR-nél is jó lehet, ha van egy nyelv felismerő, ami a rosszul olvasható szavakat meg tudja tippelni a kontextus alapján. Olyan fordítót meg bonyolult írni, ami felismeri a kontextust. Párszor már nekifutottam, hogy hogyan lehetne modellezni a problémát, de nem sokra jutottam. Lehet, hogy tényleg jobban jártok, ha a translator API-t használjátok, bár sokszor az is szemetet dobál ki magából.
-
inf3rno
nagyúr
válasz
#39560925
#8895
üzenetére
Nem csak noSQL létezik, van newSQL is, ami ugyanúgy SQL, csak nulláról írt adatbázis motorokkal, és azt mondják sebességben felveszi a versenyt a noSQL adatbázisokkal. Rengeteg van egyébként, olvastam egy könyvet polyglot persistence témában régebben, amiben felsoroltak legalább 10 divatosat, mint mongodb, neo4j, riak, stb... Mindegyiknél megvan az a feladat, amiben nagyon jó, meg persze az is, amiben nagyon rossz. Szóval lekérdezés alapján érdemes adatbázist választani. Kis alkalmazásoknál persze választasz egyet azt kalap. Nagy alkalmazásoknál meg jobb helyeken váltanak monolitról microservice-re egy méret felett, és minden microservice-nek egy vagy több adatbázist adnak, amelyek eltérő típusúak (is lehetnek). A típus attól függ, hogy az adott lekérdezés csomagra melyik adatbázis alkalmasabb a legjobban. Ezeket úgy frissítik, hogy csinálnak egy központi event storage-et, ami a teljes rendszer állapotát tárolja, aztán az abba bekerülő domain event-eket figyelik, és ha új event érkezik, akkor annak megfelelően frissítik a microservice-hez tartozó adatbázist. Nem kell multiphase commit, hogy szinkronban legyenek az adatbázisok, mert elég ha az event storage letárolja az event-et, a kis adatbázisok ha valami rosszul megy, akkor maximum eldobják a jelenlegi táblát, és nulláról újra lekérik az összes event-et, és végrehajtják magukon. Ez nagyon rugalmas rendszer így, mert egyedül az event storage lecserélése, ami problémás. A microservice-ekhez tartozó query database-eket bármikor tetszés szerint lehet cserélni, vagy akár még több különbözőt is lehet párhuzamosan futtatni, és A/B teszteket csinálni, és loggolni, hogy a kliens mennyi idő alatt kapott választ a lekérdezésre. A hátrány annyi, hogy legalább 2 helyen meglesz ugyanaz az adat, illetve, hogy visszamenőleg nehéz módosítani domain event-eket, mert akkor vagy belenyúlsz az event storage-be és módosítod a már letárolt event-ek adatait, hogy pl új tulajdonságok is kapjanak értéket, vagy mondjuk bevezetsz egy MyDomainEventV2 osztályt, ami már tartalmazza az új tulajdonságokat. Egyik sem tűnik valami jónak. Na asszem már túl sokat bloggoltam, mi is volt a kérdés?
-
-
válasz
#39560925
#8895
üzenetére
"Ennek tudtában azt csinálnám (csinálom a mostani verzióban is), hogy minden userhez tartozik egy max 1.000.000 millió méretű terület a táblában, tehát például az n-edik usernek [n x 1.000.000] és [(n-1) x 1.000.000] közé esnének az Exceptionjeinek az ID-jai."
Ejha, miert tennel ilyesmit? Arra spekulalsz, hogy ilyen modon gyorsabban tudsz majd lekerdezni? Ugy, hogy azt se tudod, hogy valojaban ez bottleneck lesz-e, ill. azt sem, hogy hany exception instance lesz userenkent?
Siman legyen autoincrementalt ID-je az exceptionoknek, es ha ugy latod, hogy tul sok a felhasznalo, akkor majd skalazol. Arra gondolj, hogy egy ilyen sor kb. 20 bajt, tehat ha van egymilliard exception, akkor az meg siman elfer a memoriaban (!) egy komolyabb szerveren.
Abszolut tulgondolod szerintem, ill. informacio nelkul hozol technologiai donteseket.
"Beszúrás már más kérdés, szerintem ha Java kódból EntityManageren keresztül nyomok egy persist-et, semmiképp se fogom tudni elkerülni, hogy lockolja az egész táblát, és a többi tranzakció ami közben olvasna belőle, ne blokkolódjon."
Ize, miert kene lockolni az egesz tablat, ha inzertalsz? Olvass utana az MVCC-nek
Szar lenne az elet, ha az egesz tablat zarolnank egy inserthez -
olivera88
veterán
válasz
#39560925
#8735
üzenetére
-DCMAKE_INSTALL_PREFIX=/usr/local Így gondoltad ugye?
Köszi. Bár lehet próbáltam már nem tudom.
Hogy lehet újra installálni h ne keljen lefordítani még egyszer?
Evvel indul ugye a fordítás és itt van meghatározva a telepités helye. cmake /home/oliver/build/Magics-2.24.7 -DCMAKE_INSTALL_PREFIX=usr/local
Lefordítja a fájlokat és aztán kell installálni.
-
repvez
addikt
válasz
#39560925
#8641
üzenetére
Azokból kiderül, hogy esetleg több fájl is egymásra hatással van? TEhát, hogy az egyik fájl számitásánál egy másikból hiv be adatot vagy oda továbbit és ezt már a modositás kor is meg kéne nyitni, hogy a forditás során ne okozzon hibát?
Azért érdekelne, hogy megoldható lenne e egy külső ingyenes fizikai motor beleintegrálása külön modulként, mint a phisyx vagy a JSBSim
-
-
-
válasz
#39560925
#8479
üzenetére
Total mas, mint az ML-alapu nyelvek. A Scala nem erolteti tul a funkcionalis hozzaallast. Hibrid nyelvkent szerintem a F# egy jobb konstrukcio, de masik okoszisztema, szal mindegy is. Az ipari alkalmazasai elsosorban a penzugyi teruleten jelentosek; bar egy jo baratom dolgozik HPC kornyezetben is Scalaval.
En sokkal erdekesebbnek tartom pl. a Clojure-t, ott vannak extrem eloremutato dolgok, mint pl. teljes lockmentes konkurens programozas STM-mel, meg ilyesmik.
-
válasz
#39560925
#8476
üzenetére
Szerintem eleg sok haszna van, de ha elsosorban latoteret szeretnel tagitani, akkor en nem Scala-t tanulnek, hanem valami erosebben funkcionalis nyelvet. JVM-en pl. Clojure, vagy esetleg valami ML-varians, F# mondjuk. Ha jo vagy OCAML-ben, akkor tudok mondani egy allast, ami juniorkent 80k fontot fizet evente, aztan ez mondjuk megduplazodik
A Scala az kicsit olyan, mint a C++, amiben tizenotfeleke paradigma lehet programozni.
-
modder
aktív tag
válasz
#39560925
#8165
üzenetére
Én hallgattam a Java EE-s kurzust pár éve, nincsen benne EJB 2.1, szerintem JSP-t is alig említik, gyakorlat inkább JSF+EJB. Gyakorlaton Netbeansben van a fejlesztés, ami legenerálja a CRUD EJB-ket meg ilyenek.
Amit fontos tudni, hogy rettentő sok az anyag, nem is csoda, mert hihetetlen nagy állat az egész Java EE framework, érdemes jó sok pontot szerezni a házin, mert olyan sok az anyag, hogy vizsgára nehéz mindent rendesen megtanulni.
A másik dolog, hogy akkor a gyakorlatok Netbeansben voltak, ami sok kódot, egész projektet legenerált, nagyon megkönnyítve ezzel a dolgunkat, de nekem akkor nem is állt össze pontosan, hogy mire jó, hogyan működik az EJB, JPA. Csak később, amikor munkahelyen láttam egy életnagyságú Java EE projektet, ahol minden réteg (megjelenítés, üzleti, adat model) külön Ant (vagy Maven) projekt volt, akkor esett le az egész. Ezzel annyit akartam mondani, hogy hasznos, de magadtól is érdemes letölteni pár Java EE sample projektet githubról, ami valami konvencionális build toolt használ (maven, ant, gradle), hogy lásd, a valóságban milyen egy projekt, mert a való életben nem Netbeans-szel generálják a kódot.
Ja, és ha már Java vagy .NET... én szeretem a Javát, nem is feltétlenül a nyelvet, hanem azt a sokszínű platformot, amit a JVM nyújt. Nagyon sok nyelvet támogat, és mind futtatható a JVM-en együttműködve: Scala, Clojure, JavaScript, Groovy. Sokféle Webes keretrendszer. Ha akarod hackelheted a javac fordítót, hogy fordítás közben generálj kódot (pl. Project Lombok). IntelliJ Idea-t istenítik, ami fizetős, de a legújabb Eclipse is már elég fasza támogatást nyújt webfejlesztés terén.
Ami viszont tény, hogy körülményesebb tud lenni, mint a .NET: neked kell kitalálnod google segítségével, hogy esetlegesen melyik osztály milyen Jarban lehet benne, ha hiányzik valami függőség a projektedben és csak egy ClassNotFound exception-t kapsz. Nehézkes a főggőség menedzsment. Egy nagyobb projektnél nehéz lehet konfigurálni az Antot vagy Mavent, ezekbe mind bele kell tanulni. Sokszor ki kell előre választani, hogy milyen szervlet vagy Java EE konténeren akarod futtatni az alkalmazásodat, mert habár standard a Servlet api, meg az összes Java EE szolgáltatás, mindig előjönnek konténer specifikus konfigurációk. Míg .NET-nél elvileg mindig IIS-en futtatod, jól össze van integrálva VS-val, és minden librarynak egyetlen, a hivatalos Microsoft implementációja van, nem neked kell kiválasztani.
-
Karma
félisten
válasz
#39560925
#8148
üzenetére
Halkan azért hozzátenném, hogy egyik választható tárgy se annyira mély vagy hasznos, hogy csak erre alapozd a karrieredet. Az újgen.NET még a frissebb adatlap szerint is eléggé elavultnak tűnik - amit linkeltél meg talán pont ugyanaz, mint amit anno én is hallgattam.
A J2EE-be belelépés se feltétlen adja vissza azt, ami a való életben kelleni fog.
Ha választani kell, én azt mondanám, hogy hallgasd mindkettőt
-
martonx
veterán
A zárójelezést (nagyon) könnyű elrontani.
Az async/await meg vegkepp sok lenne mar az absztrakciobol 
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Háztartási gépek
- Futás, futópályák
- Milyen RAM-ot vegyek?
- Geri Bátyó: Agglegénykonyha – bevezető - igényfelmérés
- Xbox tulajok OFF topicja
- Apple Watch Sport - ez is csak egy okosóra
- A legnagyobb számok a Honor kagylójában vannak
- Az előírások megszegése miatt éghet le egyes alaplapokon a Socket AM5 foglalat
- Gaming notebook topik
- További aktív témák...
- Razer Viper Mini
- EK-Quantum Velocity RGB - Full Nickel - LGA1700-hoz is!
- Újszerű Creality K1 MAX + CFS garanciális, nyomtatótér: 300 x 300 x 300 mm 160 óra üzemidő
- Extrém teljesítményű gamer PC (AMD Ryzen 7 5700X, Radeon RX 7900 XTX) LEGJOBB ÁR/ÉRTÉK ARÁNY!
- Garanciális Gamer Számítógép, PC (RTX 3060Ti, I5-10400, 16GB Ram, SSD) Beszámítás! Posta ok! (37)
- Telefon felvásárlás!! Samsung Galaxy A20e/Samsung Galaxy A40/Samsung Galaxy A04s/Samsung Galaxy A03s
- Gamer PC-Számítógép! Csere-Beszámítás! R5 3600 / RTX 2060 6GB / 16GB DDR4 / 512GB SSD
- BESZÁMÍTÁS! MSI B450 R5 5500 16GB DDR4 512GB SSD 1TB HDD GTX 1060 6GB Zalman N5 MF ADATA 600W
- iPhone 13 mini 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3086, 94% Akkumulátor
- Xiaomi Redmi Note 14 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest