- Garmin Venu X1 - vékony, virtuóz, váltságíjas
- Mindenki Z Fold7-et akar
- Telekom mobilszolgáltatások
- Redmi Note 10S - egy a sok közül
- One mobilszolgáltatások
- Huawei Mate 10 Pro - mestersége az intelligencia
- Magisk
- 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
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
-
inf3rno
nagyúr
Amit adott válaszokat a kérdéseimre azokkal én teljesen jól meg vagyok, sokkal többet segített, mint bármelyik keresőmotor vagy ember, akivel eddig találkoztam, és elég speciális a témakör. Nem hiszem, hogy sokszor publikálták ezeket az információkat, fogalmam sincs honnan szedi őket, de kb. kincsestár ebben a témakörben, a többi kereső, wikipedia meg teljesen használhatatlan.
-
inf3rno
nagyúr
Ezzel vitatkoznék, nekem olyan ritka témakörben is sikerült adatot kihúzni belőle, amire a google, duckduckgo semmi találatot nem adott, a bing is csak mérsékelten hasznosat. Pont az volt a várakozásom, hogy kevesebbet tud a kereső motoroknál, mert nem létezik, hogy ennyi adatot normálisan beindexelnek, de mégis.
-
#20819
inf3rno
nagyúr
aprokaroka87
#20815
inf3rno
nagyúr
válasz
aprokaroka87
#20815
üzenetére
Attól függ, hogy minek a kódját.
-
inf3rno
nagyúr
válasz
dabadab
#20765
üzenetére
Ha sikerül pontozni a jóságát egy-egy felállásnak, akkor lehet olyan algoritmust tervezni, ami a nagyobb jóság felé viszi fokozatosan az adott megoldást. Elvileg a gépi tanulás is így működik. Nem muszáj full randomnak lennie, az nagyon fapados.
A fenti problémánál azt is el tudom képzelni, hogy van valami egyszerűbb algoritmus, amivel jó eredmények érhetőek el és ami könnyen automatizálható. De annyira most nincs időm belefolyni.
-
inf3rno
nagyúr
Ritkán vannak, napi 1 deadlock volt mostanában. Ez is új fejlesztés eredménye. Most beleírtam a kódba, hogy legyen retry ilyenkor, aztán rendben van. Nem tudom még mit lehet kezdeni az ilyen deadlockokkal. Jó lenne, ha nem tábla szinten lenne a lock, de ránézésre a key-ek is rendben, úgyhogy nem tudom még mit lehetne tenni.
Még arra gondoltam, hogy újra lehetne tervezni az egészet és bekötni a sorba azt is, ami a deadlockot okozza. Végülis nem sürgős műveletről van szó, úgyhogy megvárhatja a többit.
-
inf3rno
nagyúr
Az van, hogy 100-asával szórjuk be tranzakcióba az egymástól nagyjából független SQL-eket, aztán így kötegelve küldjük be az adatbázisba, mert így nem ül le tőle az adatbázis szemben azzal, ha egyesével küldjük be őket. Aztán ha valamilyen SQL hibára fut, akkor elnyeljük a hibát, hogy ne veszélyeztesse a teljes tranzakciót. Ha mondjuk out of range okozza a hibát, akkor rendben bekerülnek a változtatások commitnál egyedül azt hagyja ki, aminél a hibát dobta. Azoknál a kivételeknél, mint pl. deadlock, ahol elszáll a teljes tranzakció, ott muszáj újrapróbálni az egészet, hogy ne legyen adatvesztés. Aztán ezért kellett különbséget tennem a két hibatípus között. De közben találtam egy drupal kódrészletet, ami alapján megírtam a saját ellenőrzőt hozzá, úgyhogy rendben van. Most várom az out of range hibákat, mert enélkül a fejlesztés nélkül esélytelen volt debuggolni őket. A deadlockra már nagyjából rájöttem, hogy mi okozhatja, de nem javítható, teljesen újra kellene tervezni az egész rendszert hozzá. Úgyhogy ma sem unatkozom.
-
inf3rno
nagyúr
Van egy CRON-om, ami batch-ekben 100-asával küldi tranzakcióban az SQL-eket. Ezek egymástól nagyjából függetlenek, szóval ha elakad az egyik, akkor a többinek van értelme továbbmennie. Elvileg így tehermentesítjük írás szempontjából a szervert, legalábbis exkolléga szerint ezt így kell. Most belefutottam egy olyanba, hogy egyszer out of range errorral száll el a CRON, másszor meg deadlockal. Az első esetben nincs értelme újrapróbálni, csak naplózni az SQL-t, és mehet commit a tranzakcióra, a második esetben viszont jó, ha elszáll az egész, mert akkor később újrapróbálja a CRON. Ezeket a scenariokat szeretném szétválasztani, de ha már itt tartunk, akkor jó lenne a kapcsolat megszakadásakor is ugyanúgy újrapróbálni, és még nem tudom milyen esetek vannak, amikor van értelme. Láttatok már ilyen kódot, ami szétválasztja az olyan PDOException-öket, ahol van értelme újrapróbálni, és ahol nincsen? Így fapados megoldásnak az tűnik, ha ellenőrzöm az error code-ot vagy az sqlstate kódot, és az alapján a dokumentációból megcsinálom az if-elset, de ha már van készen valakinél ilyen, akkor feleslegesen nem csesznék el rá egy napot... SO-n próbáltam már keresni, semmi eredmény, feltettem kérdésnek is, de a sok hülye lehurrogott, hogy így szar úgy szar, amit csinálunk.
-
-
inf3rno
nagyúr
Van egy listád, annak van id-je. Vannak rajta elemek, azoknak is van id-jük. Amikor törölsz egy elemet, akkor removed(listID, itemID) esemény generálódik. A másik rendszer nem ismeri ezt az eseményt, ott csak listCreatedOrUpdated(listID) esemény van, amivel ezt tudjuk emulálni. Szóval pl. removed(1, 10) -> listCreatedOrUpdated(1), removed(1, 11) -> listCreatedOrUpdated(1) és máris ott a duplikáció, amit szeretnék elkerülni. Ezek az események pár percig ott ülnek a soron, mert nem annyira gyors a feldolgozó és nem cél, hogy realtime menjen minden. Szóval simán előfordul, hogy valaki töröl pár elemet a listáról, és bekerül mondjuk egy tucat ilyen duplikáció, aminek hatására a teljes 1-es listát át kell küldeni egy tucatszor. Eddigre már végbement az összes törlés a listán, tehát ugyanaz az adat fog átmenni feleslegesen egy tucatszor egyetlen átküldés helyett. Ezt ha lehet szeretnénk elkerülni, mert valószínűleg jóval drágább kiskálázni, mint deduplikálni nem beszélve arról, hogy üzenet küldési korlátok vannak a két rendszer között.
-
inf3rno
nagyúr
válasz
sztanozs
#20652
üzenetére
Két rendszer van. A soron az egyik rendszerből jövő események vannak, a feldolgozó feldolgozza, és átfordítja a másik rendszer eseményeire, aztán úgy akartam megoldani, hogy felteszi vagy ugyanarra a sorra vagy egy másikra a deduplikáció miatt mielőtt feldolgozná a másik rendszer az eseményeket. A duplikáció a fordításnál keletkezik. Az egyik rendszerben added, removed, changed, listCreated van, a másik rendszerben csak addedOrChanged és listCreatedOrUpdated. Ha egy added és egy changed megy a lista egy elemére egymás után, akkor addedOrChanged keletkezik duplán. Ha két removed megy ugyanarra a listára, akkor listCreatedOrUpdated keletkezik duplán. És így tovább. Lehet még csavarni ezen is, mert ha ráül a felhasználó a gombra az egyik rendszerben és nagyon sok esemény jön gyors egymásutánban ugyanarra a listára vonatkozóan, akkor érdemes összefogni ezeket és egy listCreatedOrUpdated-el a teljes listát befrissíteni.
-
inf3rno
nagyúr
válasz
sztanozs
#20649
üzenetére
Gondolom annyi az egész, hogy az új eseményeket szerializálom, csinálok hasht és megnézem, hogy szerepelnek e a nosql-ben. Ha nem, akkor mehetnek a sorra. Aztán amikor leveszem őket, akkor törlöm az nosqlből. Van redis, sort is tudok csinálni, feldolgozó is van. Gondolom úgy gondoltad a dupla sort, hogy nem én irányítom az esemény felrakását a sorra, ezért mennie kell még egy kört, de azt a kódot is én írom. Ja tényleg nem egy nagy szám.
-
inf3rno
nagyúr
Sziasztok! Küzdök egy kicsit az SQS deduplication-el. Azt szerettem volna, hogy felküldök egy eseményt a sorra és ha már rajta van a soron egy ugyanolyan, akkor ne menjen fel. Az Amazon egy kicsit túllőtt a célon, mert mint kiderült még 5 percig nem lehet feltenni ugyanolyan eseményt miután már leszedtem. Ez teljesen kinyírja az elvet, ami miatt használtam volna, így kénytelen vagyok SQS deduplication nélkül menni. Az érdekel, hogy olyan formában, ahogy eredetileg gondoltam mennyire nehéz megvalósítani az ilyesmit? Csinált már ilyet valamelyikőtök? Igazából lehet kicsit premature optimalizáció, de spórolunk a költségekkel és az esemény feldolgozása viszonylag költséges.
-
inf3rno
nagyúr
Jó hát mondjuk egy voltdb vagy egy nuodb 1000 000 TPS-t tud clusterbe szétszórva kb 20 gépre, egy postgres meg 10 000 TPS-t egyedül és a cluster elég nehezen megy neki, nagyjából ennyi a különbség ezek között. Amúgy nem vagyok egy nagy db expert, csak olvasgattam kicsit a témában. Nekem az a benyomásom, hogy az említett projektre a postgres bőven elég lesz. Az is előny nála, hogy elmegy egy gyengébb szerveren is, szemben ezekkel a nagyobb jószágokkal, szóval ha indulásnál esetleg mégsem lenne millió sor, akkor fokozatosan lehetne fejleszteni a szervert is, ahogy nő a terhelés.
-
inf3rno
nagyúr
válasz
Bambula5
#9245
üzenetére
A NuoDB newSQL, nem noSQL. Van egy csomó új fajta SQL adatbázis , amik sokkal gyorsabbak a régebbieknél, és lazán eljátszadoznak több millió sorral. [link] Ruby-val a látottak alapján talán jobban jársz, ha maradsz a régieknél, esetleg kipróbálsz olyan adatbázist, aminek van REST API-ja (általában szokott lenni), így kikerülheted azt a problémát, hogy nincs csatoló. Gondolom HTTP-t csak tud a ruby valami cURL-el vagy hasonlóval.
-
inf3rno
nagyúr
válasz
Bambula5
#9221
üzenetére
Elvileg a postgresql, amit írtál elég lehet. Ha túl lassú lenne, akkor váltanod kell noSQL-re vagy newSQL-re. Az utóbbiból nézegettem ruby-s gem-eket, NuoDB-hez volt valami tűrhető, de már azt is 2 éve nem fejlesztik, lehet, hogy fel se tudnád telepíteni, build failing-et ír a travis. [link] Nem egy jó nyelv ilyen szempontból a ruby, meg amúgy sem, legalábbis sokan nem szeretik. Én inkább távol tartom magam tőle.
-
-
#9177
inf3rno
nagyúr
Sk8erPeter
#9176
inf3rno
nagyúr
válasz
Sk8erPeter
#9176
üzenetére
"mert nem tudom, mit veszítek vele"
Megmondom én, rengeteg értelmetlenül eltöltött időt meg egy csomó fejfájást...Hát nálam a webstorm 300MB-ot eszik, meg 5-10% CPU-t. Ha ezt valaki nem tudja megengedni magának, az jobb, ha nem fejleszt. Még a tabletemen is simán elmegy gond nélkül, talán még a mobilom is bírná. Előtte netbeans volt, meg talán eclipse egy nagyon rövid ideig, mindkettő zabálja az erőforrásokat 1GB RAM alatt el sem nagyon indulnak, nem is szerettem őket annyira.
Kétlem, hogy VIM hozná azt a kényelmet, mint egy normális IDE, vagy ugyanúgy elkezdené enni az erőforrásokat, akkor meg ugyanott vagyunk, mintha egy IDE-t raktam volna fel, csak elcsesztem vele pár hónapot, mire személyre szabtam pluginekkel, amiket ki tudja ki fejleszt, milyen rá a support, és mennyi bug van bennük...
-
#9174
inf3rno
nagyúr
Sk8erPeter
#9173
inf3rno
nagyúr
válasz
Sk8erPeter
#9173
üzenetére
+1, nálam a :qw volt eddig a csúcs felhasználói felületek terén. Még mindig nem hiszem el, hogy ezt valaki komolyan gondolta.
Teljesen kezdőknek a syntax ellenőrzés, autocomplete, reformat, refactor miatt szerintem mindenképp jobb egy IDE-vel indítani, meg egy rövid cikkel, ami elmagyarázza, hogy léteznek ezek az eszközök.
-
#9161
inf3rno
nagyúr
Oppenheimer
#9152
inf3rno
nagyúr
válasz
Oppenheimer
#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?
-
#9159
inf3rno
nagyúr
Oppenheimer
#9146
inf3rno
nagyúr
válasz
Oppenheimer
#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. -
#9144
inf3rno
nagyúr
Oppenheimer
#9143
inf3rno
nagyúr
válasz
Oppenheimer
#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.
-
#9142
inf3rno
nagyúr
Oppenheimer
#9136
inf3rno
nagyúr
válasz
Oppenheimer
#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.
-
inf3rno
nagyúr
-
inf3rno
nagyúr
válasz
mrhitoshi
#9087
üzenetére
Miért csinálnád 2d-ben? A 3d nem olyan hihetetlenül nehéz, és legalább tanulnál valami újat is közben, mint pl. az OpenGL használatát. A Naprendszer szerintem is jó projekt. Szimulációt nyilván tudnál csinálni az n test problémát meg nem te fogod megoldani. Később a bolygókon kivül beleszórhatsz üstököseket is esetleg másik rendszereket, és így tovább. A lényeg, hogy az eredmény tartalmazzon űrcsatát jó sok lövedékkel.
-
inf3rno
nagyúr
válasz
Zola007
#9070
üzenetére
Sima konstans léptékű véges sorozatok összeadásához nem kell ciklus:
1..n összege egyesével léptetve: s(n) = n*(1+n)/2 ezt fel lehet használni az összes hasonló sorozathoz, pl 2..m páros (kettesével léptetve) s(m/2)*2A div-ről nekem csak a divergencia ugrik be, de gondolom itt nem arra gondolnak. :-)
-
#9029
inf3rno
nagyúr
Atomantiii
#9028
inf3rno
nagyúr
válasz
Atomantiii
#9028
üzenetére
keygen-nek hívják vagymi
ez kész... -
inf3rno
nagyúr
Találtam egy érdekes projektet: [link] itt google meg sun stílusokról írnak az egyik menüpontban, a cuccal meg tudod ellenőrizni, hogy megfelel e a kódod nekik. Magyart ha lehet hanyagold, a többiben nem én vagyok a hiteles forrás, alig fél évet jáváztam.
szerk:
Valszeg a legtöbb IDE-ben is van beépített megoldás ugyanerre. -
inf3rno
nagyúr
Így hirtelen ennyit találtam: [link] egy próbát megér, hátha megjavítja. Szvsz. ilyenkor inkább a support-nak érdemes írni, hogy mi a gond. Én nem tapasztaltam semmi ilyesmit amúgy, de 2 éve nem nyúltam a phpstorm-hoz, és nem is fogok többet php-zni, szóval csak a régebbi verziókkal vannak tapasztalataim. Talán az még fontos lehet, hogy PHPUnit-hoz, doctrine-hez, symfony-hoz, ilyesmikhez elég jó a támogatása ennek az IDE-nek.
-
inf3rno
nagyúr
Ha már szóba került, node-hoz tudtok olcsó itthoni hosting-ot?
@hemaka:
Node egész más világ, php-nél az aszinkron dolgokat elintézi a webszerver, szóval a kód általában szinkron marad, a node meg inkább daemonok írásáról szól, és tele van aszinkron kóddal. Ha ez nem a te világod, akkor lehet, hogy elsőre egy kukkot sem fogsz érteni belőle. A js script nyelv egyébként ugyanúgy a maga gyengeségeivel, de én szeretem.
-
-
inf3rno
nagyúr
PhpStorm jött be nekem, amikor még php-ztem. Azt hiszem 30 napig kipróbálható. 200eur+áfát írnak, szóval olyan 80k huf körüli összegbe kerül. Kb egy éve bekeményítettek a fejlesztők, már nem lehet reinstallal újrakezdeni a 30 napot, meg az árat is megduplázták. Gondolom rájöttek, hogy már mindenkit lenyomtak a piacon, vagy szimplán több pénzt akartak kivenni a projektből, passz. Én még tavaly vettem webstormot 50eur+áfáért, és az is most dupla annyiba fáj. Ingyenes alternatíva van egy csomó, azokat már évek óta nem követem, hogy milyenek. Netbeans volt még talán használható, a php-t úgy emlékszem azzal kezdtem.
-
#8976
inf3rno
nagyúr
Sk8erPeter
#8975
inf3rno
nagyúr
válasz
Sk8erPeter
#8975
üzenetére
Kihagytad azt a részt, hogy jelenleg egy email küldő formot rakott össze számunkra ismeretlen módon, valszeg netről copy-paste-elve valamelyik tutorial-ból, legalábbis nekem ez jött le. Ilyen kontextusban azért elég gyakori, hogy pl php mail függvényt meg hasonló retteneteket használnak bármilyen ellenőrzés nélkül.
A mondandóddal egyébként egyetértek. Azért használunk CMS-t és web framework-öket, mert leveszik ezeket a terheket a vállunkról, és a feladatra tudunk összpontosítani. Annyit azért hozzátennék, hogy egyik ilyen rendszer sem tökéletes, és érdemes figyelni a security update-eket.
-
inf3rno
nagyúr
Ha most csak ennyi ment, akkor közöld, hogy erre vagy képes, többre most nem. Nézz utána, hogy az adott nyelven mi a divatos CMS vagy webalkalmazás keretrendszer, aztán kezdd el azt tanulgatni. Ezen kívül az épp divatos adatbázisnál is érdemes néhány SQL lekérdezést összeszórni, hogy képben legyél. Szóval kell rá egy pár hónap, mire valamit le tudsz tenni az asztalra, addig meg nincs értelme húzni a projektet meg tologatni a határidőt. Szerintem.
Email-nél mindenképp nézz utána, hogy header injection-t, ilyesmit ne tudjanak beletenni, szóval ellenőrizd és kezeld a tartalmat, amit a felhasználótól kapsz. Adatbázisnál SQL injectionre érdemes védeni, HTML-nél, js-nél XSS-re. És így tovább.
-
inf3rno
nagyúr
válasz
peterszky
#8947
üzenetére
Nem hiszem, hogy ez lehetséges, ha ekkora számokról van szó, és random a dolog. Max közelítőleg lehet megtalálni, hogy mi a jó db szám.
Algoritmust nem tudok javasolni, mert ahhoz nem értek. Talán sorba kellene rendezni, és az összeg és az irányszám különbségénél kisebb elemek összeadásával próbálkozni. Jelen esetben ez 591511, szóval mind a 27 elem részt vesz a játékban. Én sem hiszem, hogy erre ne lenne elég a brute force, nem százezer elemes dolgokról van szó. Még excel is 1-2 sec alatt kiszámolta nekem a megoldójával, mondjuk az ránézésre monte carlo-val megy, mert könnyen beragad egy értékre, ami nem is a legoptimálisabb. Esetleg nyálazz át egy algoritmusos könyvet, ha az optimális megoldás kellene.
-
#8916
inf3rno
nagyúr
Oppenheimer
#8912
inf3rno
nagyúr
válasz
Oppenheimer
#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.
-
#8904
inf3rno
nagyúr
Oppenheimer
#8895
inf3rno
nagyúr
válasz
Oppenheimer
#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?
-
#8903
inf3rno
nagyúr
Sk8erPeter
#8894
inf3rno
nagyúr
válasz
Sk8erPeter
#8894
üzenetére
Nem tudom, valami félrecsúszott. Valaki C#-os anyagot keresett, neki akartam.
-
inf3rno
nagyúr
Igen, én is úgy tudom, hogy programmal rakják össze a modellt ilyen oculus rift-el, meg 3d egérrel valamilyen formatervezős programmal meg lehet rajzolni. Ezek után kihajtják 2d-re, és úgy illesztik rá a textúrát, utána meg a modelt, a textúrát és a textúra kötésehez tartozó térképet valahogy beimportálják a játékokba. Tehát nem kézzel kell összerakni, bár gondolom az is lehetséges, csak jóval körülményesebb lehet. Ezek után mennek rá a shader-ek, amik pozíciionálják a pályán, ráteszik a textúrát, effekteket, stb. Ennél többet én sem tudok a témáról (és ez is elég ingatag), viszont rengeteg anyag elérhető vele kapcsolatban, szóval csak kitartás meg évek kérdése, ha valaki ilyesmivel akar foglalkozni. Szép szakma, tetszik is a végeredmény, de nincs meg a rajz tudásom hozzá, gyakorolni meg lusta vagyok, más dolgok érdekelnek. A logikai részét talán le tudnám fejleszteni egy játéknak.
-
#8890
inf3rno
nagyúr
Sk8erPeter
#8886
inf3rno
nagyúr
válasz
Sk8erPeter
#8886
üzenetére
Próbáld meg a Reiter féle könyvet, hátha megvilágosodsz. [link] Én személy szerint nem olvastam, de jókat ír a srác a blogjában, szóval lehet, hogy a könyv is jó.
-
inf3rno
nagyúr
A 3d játékok egész más téma, azoknál shaderek vannak: [link] amiket elsőre elég nehéz felfogni. Ez ugyanúgy egy programozási nyelv független technológia, mint sok más, amivel illik megismerkedni. Amit a programozási nyelvekkel csinálsz, hogy ezeket az algoritmusokat becsomagolod egy jól karbantartható formába, hogyha később hozzá kell nyúlni, akkor gyorsan el tudd végezni a módosításokat.
-
inf3rno
nagyúr
válasz
bucsupeti
#8873
üzenetére
Szerintem érdemesebb struktúráltan elkezdeni oktatni, és ha az már megy, akkor megmutatni, hogy mik a korlátai, és az oo hol egészíti ki, hol add többet nála karbantarthatóság terén, hol meg kevesebbet. [link] Én mondjuk alacsony szinten nem vagyok annyira otthon, js-el kezdtem még 18 éve olvashatatlan spagetti kóddal, az oo elméletet meg hozzáolvastam könyvekből.
-
inf3rno
nagyúr
Szvsz, ha oot akarsz tanulni, akkor az élméletet kéne valamennyire elsajátítani, oo alapjai, solid elvek, ddd, rest, soap, tdd, bdd, orm, stb... Ha ezek mennek, akkor már elég könnyen kiigazodsz bármelyik nyelven. Nincsenek olyan hatalmas különbségek közöttük. Én problémának tartom, hogy sokan először a gyakorlatnak futnak neki elméleti tudás nélkül, és feltalálják a spanyol viaszt. Nyilván ez is beletartozik a fejlődésébe valakinek, de éveket el lehet így tölteni anélkül, hogy látványosan fejlődne valaki, a kód minősége, amit produkál meg ugyanúgy alacsony szinten marad.
-
inf3rno
nagyúr
válasz
sunnysys
#8846
üzenetére
Én is úgy látom, hogy nincs értelme 40 éves korodra rendesen beletanulnál, de más ilyenkorra már régen középvezető vagy magasabb pozícióban van. Persze próba szerencse, java programozókból meg hiány van úgyhogy még akár össze is jöhet. Papír nem muszáj hozzá. Valami olyasmit kellene keresned, ahol nulláról megtanítanak programozni.
-
inf3rno
nagyúr
válasz
bucsupeti
#8795
üzenetére
Most, hogy így mondod, online IDE-t már néztem egyet azt hiszem tavaly, de nekem nem volt szimpi a dolog, valahogy zsigerből idegenkedek tőle. Ilyen irányba esetleg el lehetne menni, hogy egy ehhez tartozó szervert felszórni a céges gépre, aztán otthonról kódolni rá online (már ha erre van lehetőség). [link]
-
inf3rno
nagyúr
Végül nem sikerült összehozni. Maga az injektor működik többé kevésbé, de a chrome pluginban lévő html és js fájlok, amiket a weboldalba injektál úgy néz ki, hogy nem kompatibilisek firefox-al. Debuggolni nem tudom, mert $.html-t használ, ami eval-al szúrja be a scripteket, úgyhogy esélytelen az egész. Elküldtem a kódot a plugin eredeti fejlesztőjének, hátha többre megy vele, mint én. Eltelt kb 20 év, és még mindig ott tartunk, hogy a böngészők közötti különbségek miatt nem lehet normálisan fejleszteni, nem véletlenül utáltam meg a frontendezést.
-
#8779
inf3rno
nagyúr
Sk8erPeter
#8778
inf3rno
nagyúr
válasz
Sk8erPeter
#8778
üzenetére
Ez van, nekem se tetszik, de csak pár sorról van szó, úgyhogy elviselem. Közben megtaláltam a hiányzó részeket is a dokumentációban, meg van valami tesztelős plugin, amivel egyszerűbb a fejlesztés, mert nem kell minden módosítás után újratelepíteni, szóval annyira nem kétségbeejtő, legalábbis ennél a projektnél. Amúgy biztosan nem fejlesztenék én sem plugint. Lehet átpörgetem gyorsan egy nap alatt a dokumentációt, csak hogy lássam mik a lehetőségek.
Néhány hasznos link, ha valaki esetleg megpróbálkozna firefox plugin fejlesztéssel:
https://github.com/mozilla/jpm
https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Getting_Started_%28jpm%29
https://addons.mozilla.org/en-US/firefox/addon/autoinstaller/ -
inf3rno
nagyúr
Közben találtam a getURL-re is megoldást:
function getURL(relative) {
var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"].
getService(Components.interfaces.nsIWindowMediator);
var recentWindow = wm.getMostRecentWindow("navigator:browser");
var base = recentWindow ? recentWindow.content.document.location : null;
return base + "/" + relative;
}Ez sem egy kellemes valami. Hihetetlen pocsék a firefox API a chrome-hoz képest.
Azt sem értem, hogyha elvileg commonjs alapon megy a dolog, ahogy írják, akkor miért van még egy Components.classes.x.getService(Components.interfaces.y). Egy sima require("nsIWindowMediator") teljesen okés lenne. Eddig úgy látszik nem jutottak el, hát hiába egy normális API tervezésére is rá kell szánni az időt.
-
inf3rno
nagyúr
Fejlesztett már valaki közületek firefox plugint? Van egy chrome extension, amiből 3 függvényt szeretnék firefox-ra átírni meg persze a manifest.json-t package.json-ra. Elvileg a maradék kód rendben van. Próbáltam keresgélni, de nehéz copy-paste kódot találni, többszáz oldal dokumentációt meg ezért elolvasni, hát nem éri meg.
Ilyesmik kellenének:
chrome.extension.getURL("relative/path");
chrome.browserAction.onClicked.addListener(function() {
window.open("http://domain.com/", "_new")
});
chrome.webRequest.onBeforeRequest.addListener(function() {
return {
cancel: true
}
}, {
urls: ["*://domain.com/main.js*"]
}, ["blocking"]);A getURL() elsősorban a frontend részéhez kell, hogy be tudjon injektálni egy html meg egy js fájlt xhr-el meg script tag-el.
Az onClicked-nél a toolbar gombra kattintást nézi, annyit csinál, hogy megnyitja az url-t új ablakba, az onBeforeRequest meg letiltja az eredeti oldal betöltését. Ezek mellett a manifest.json-ban van egy match a domain-re, ami beteszi az onClicked-et és az onBeforeRequest-et a background-ba szóval azok a böngésző indításakor futnak, a getURL-es részt meg csak ha stimmel a domain, akkor indítja.
Egyedül a harmadikra sikerült megoldást találnom, de az is vicc kategóriás, hogy mennyire el van bonyolítva:
const Ci = Components.interfaces;
const Cu = Components.utils;
Cu.import("resource://gre/modules/Services.jsm");
Cu.import("resource://gre/modules/XPCOMUtils.jsm");
var observer = {
QueryInterface: XPCOMUtils.generateQI([
Ci.nsIObserver,
Ci.nsISupportsWeakReference
]),
observe: function(subject, topic, data)
{
if (topic == "http-on-modify-request" &&
subject instanceof Ci.nsIHttpChannel)
{
var uri = subject.URI;
if (uri.host == "domain.com" && /main\.js/.test(uri.path))
subject.cancel();
}
}
};
Services.obs.addObserver(observer, "http-on-modify-request", true);Bármi ötlet a másik kettőre meg a package.json-ra?
-
inf3rno
nagyúr
válasz
McSzaby
#8750
üzenetére
Nem tartom magam valami nagy programozónak, de én úgy oldanám meg, hogy megnézném a file modification time-ot, hogy módosították e, ill. minden felolvasás után lementeném, hogy hányadik karakternél/sorban hagytam abba az előzőt. (Feltéve hogy a fájl mérete csak nőhet, és nem törlődik az eleje.)
szerk: Na ebből látszik, hogy tényleg nem vagyok olyan nagy programozó.
-
inf3rno
nagyúr
válasz
olivera88
#8746
üzenetére
Gondolom ezt hiányolja: https://software.ecmwf.int/wiki/display/MAGP/Python+interfaces Pythonhoz nem értek, de a többit szerintem ki tudod találni. Elvileg innen lehet lerántani: https://packages.debian.org/wheezy/amd64/python-magics++ Az amd64 alapján gyanús, hogy intel processzorral ez a változat nem fog menni, de azért egy próbát megér.
-
#8709
inf3rno
nagyúr
cech19960320
#8708
inf3rno
nagyúr
válasz
cech19960320
#8708
üzenetére
Nagy valószínűséggel nem. Általában csak a gépi kódra átfordított változat van nálad, ami csak a gépnek jó, fejlesztéshez használhatatlan. Talán ha nagyon rövid, és valaki nagyon ért alacsony szintű dolgokhoz, akkor ki lehet nyerni belőle, hogy mit csinál, de nem hiszem, hogy bárki vállalkozna ilyesmire. Egyébként te magad is meg tudod nézni, hogy használható e, egyszerűen megnyitod szövegszerkesztővel a fájlokat, ha csak krix-krax van, nem (többé-kevésbé) értelmes szöveg, akkor nem jó semmire.
Szvsz. meg kellene találnod az eredeti program fejlesztőjét, és vele konzultálni ezügyben, hátha van kedve tovább csinálni. Ha nem, akkor esetleg elkérheted tőle a forráskódot, vagy megkérheted, hogy tegye ki github-ra, ahonnan lehet forkolni.
-
inf3rno
nagyúr
válasz
Mr Dini
#8702
üzenetére
Nem akarok hülyeséget mondani, de nekem az jött le abban a 2 percben, amíg utánanéztem, hogy a c fájlt kell módosítani, aztán a compile után lesz belőle pifm fájl. Hogy ehhez milyen compiler kell, hogy elmenjen rpi-n, azt ne tőlem kérdezd, biztos megvannak az eszközök hozzá.
-
#8703
inf3rno
nagyúr
cech19960320
#8701
inf3rno
nagyúr
válasz
cech19960320
#8701
üzenetére
Még mindig nem írtad, hogy milyen programozási nyelven írták a programot, amit tovább kéne fejleszteni.
-
#8700
inf3rno
nagyúr
cech19960320
#8696
inf3rno
nagyúr
válasz
cech19960320
#8696
üzenetére
Ez szerintem erősen függ attól, hogy milyen nyelven írták a programot.
(Ha esetleg nem bináris, hanem szövegfájl, akkor notepad++-al meg tudod nyitni, ellenkező esetben meg tényleg szükséged van külön programra.)
-
#8697
inf3rno
nagyúr
Sk8erPeter
#8691
inf3rno
nagyúr
válasz
Sk8erPeter
#8691
üzenetére
Én loggolni szoktam az értékeket a megfelelő helyeken, aztán úgy nézem meg. Tudom, hogy van ennél jobb megoldás is, pl breakpoint-ot, hasonlókat be lehet tenni, de őszintén szólva nem sűrűn van rá szükségem. TDD-vel fejlesztek legtöbbször, ott meg az esetek döntő többségében azonnal tudni, hogy hol a hiba. Az integrációval szoktak gondok lenne, de annak meg jobb úgy nekifutni, hogy integrációs teszteket ír az ember ahelyett, hogy elkezdene dokumentáció alapján kódolni.
A session-nél a flash típusú letárolásokat szokta kitörölni, mert pl chrome minden kérésnél keresi a favicon-t, ha nincs bent neki cache-ben.
Nekem egyelőre egyáltalán nem világos, hogy mi a hiba, csak annyi, hogy valami nem működik, és nem hajlandó debuggolni, inkább csak találgat. Ennyi alapján szerintem nem lehet semmit kijelenteni.
Szvsz, a wordpress-t procedurálishoz képest nagyon szépen megcsinálták (már amit láttam belőle), minden kapott külön függvényt beszélő névvel, szóval ki lehet igazodni rajta. A dokumentációja is jó. Egyébként azért nem oo, mert még php4-en kezdték fejleszteni. Manapság már vannak symfony-ra meg laravel-re épülő cms-ek, azok valszeg egy fokkal összeszedettebbek. Annyira nem követem php-t, a symfony2 kódja az tetszett.
-
#8690
inf3rno
nagyúr
Sk8erPeter
#8686
inf3rno
nagyúr
válasz
Sk8erPeter
#8686
üzenetére
XDebug-al hogyan fogja megtalálni a hibát? Nekem eddig még sosem sikerült használható infot kifacsarnom belőle, csak egy rohadt nagy log fájlt csinál, amit ha megnyitsz, akkor kiírja, hogy az echot ezerszer hívta, stb. Én már nem PHP-zek, de gondolom neki biztosan segítene ez az info.
-
inf3rno
nagyúr
válasz
creation
#8685
üzenetére
Ha esetleg később megismerkednél az ojjektum orientált fejlesztéssel, akkor érdemes ezt elolvasni: http://www.libri.hu/konyv/tiszta-kod.html és talán nem lesz olyan a kód utána, mint a falra hányt borsó.
Ami még elgondolkodtató, hogy BDD-t vagy TDD-t lehet e procedurálisan használni. Ha igen, akkor jobb lenne áttérnetek arra, mert a debuggal sokkal több idő elmegy. A gond most az, hogy még csak procedurálisnak sem igen lehet nevezni a kódot, mert függvények sincsenek. Spagetti, ahogy más is mondta. Így viszont max e2e tesztelhető legalább minimálisan.
-
inf3rno
nagyúr
válasz
creation
#8683
üzenetére
Próbálj meg betenni egy favicon.ico fájlt, chrome általában azt keresi. De ez session-el kapcsolatos hibákat szokott csak eredményezni, amikor session-be mentesz adatot egy átirányítás erejéig. Ami különbség lehet még az a default doctype, ha nem adsz meg ilyet, illetve, hogy a nem szabványos HTML-t hogyan dolgozzák fel és hogy a karakterkódolás ütközésekre hogyan reagálnak, pl ha meta-ban mást adsz meg, mint header-ben, meg még van egy pár dolog...
Maga az ldap szerintem csak tünet, a probléma a kóddal van. Teszteletlen és átláthatatlan, valszeg hemzseg a hibáktól. Ha nem kenyered az oop, akkor is lehet elfogadható kódot írni procedurálisan. Azt hiszem a wordpress-nek ilyen a kódja.
-
inf3rno
nagyúr
válasz
creation
#8672
üzenetére
Ha localhost-on teszteled, akkor itt van egy hasonló topic: http://forum.wampserver.com/read.php?2,91207,page=1 Azt mondják, hogy az intranet beállítások rosszak MSIE-n, illetve az Apache 2.4 cseréje 2.2-re megoldja. Hát... Én mondjuk inkább IIS-t (ha már windows) vagy nginx-et használnék, ha amúgy is szerver csere kell, sosem bíztam az Apache-ban. Valahogy az a benyomásom, hogy a verzió váltásaik több új bugot tesznek be, mint amennyit javítanak.
-
inf3rno
nagyúr
válasz
creation
#8660
üzenetére
Még érdekes lehet az is, hogy PHP milyen módban fut, mi van a htaccess fájlokban, milyen verziójú böngészőkkel próbáltad, és mi az, amivel nem megy, illetve, hogy van e kliens oldali script, vagy egy sima HTML echo betöltése nem megy. A doctype és a content-type header is közrejátszhat extrém esetben. Egyébként nekem nem logikus, hogy IE specifikus dolog legyen. Ez így tényleg fura. Össze kellene szedni minél több adatot, aztán rákeresni, hátha dob valamit google. Legrosszabb esetben meg írni egy bug report-ot vagy a HTTP szerver gyártójának vagy microsoftnak (utóbbinak azt mondják nem érdemes, mert nem nagyon foglalkoznak vele).
-
inf3rno
nagyúr
válasz
bambano
#8663
üzenetére
Szvsz event sourcing-al lenne a legtöbb értelme, abból később olyan read database-eket csinál, amilyeneket akar. Az immediate consistency meg itt egyáltalán nem szempont, szóval tökéletes lenne ilyen célra. Egy apróbb domain model kell, aminek van egy felülete, ahhoz lehetne szenzoronként eltérő adaptereket írni.
-
inf3rno
nagyúr
válasz
creation
#8657
üzenetére
Nem tudom, ilyen nehéz debuggolni? Vagy az LDAP a hibás vagy valami a HTTP szerverrel van. Próbáld ki LDAP nélkül mondjuk sima PHP array-es példa adattal kimockolva a perzisztenciát (úgy mondjuk elég nehéz, ha nem decoupled az implementációja). Ha úgy megy, akkor valszeg az LDAP lockolja a fájlt, és azért teker a többi. Hogy ennek mi köze az IE-hez, azt ne kérdezd. Persze a bugoknál lehet még sok olyan dolog, amire nem is gondolna az ember, de legalább jó lenne beazonosítani, hogy a szoftver melyik részén bukik el a dolog. LDAP-al és MSIE-vel kapcsolatban nem találtam semmi összefüggést egy gyors kereséssel, úgyhogy valszeg máshol lesz a hiba a rendszeredben.
Egyébként javaslom valamelyik HTTP keretrendszer, pl symfony vagy laravel használatát.
-
inf3rno
nagyúr
válasz
Doctor46
#8654
üzenetére
Hát nekem ez így elég tág határok között mozog, gondolom azt akarják visszahallani, amit leadtak órán. A gyakorlatban nagyon sok dolog ízlés kérdése, pl hogy milyen dokumentumokat szórsz össze azt szerződésben lehet rögzíteni, de sokszor a megrendelő egyáltalán nem is foglalkozik vele, csak működjön az alkalmazás. Az adatbázis is elég esetleges, tudni kéne, hogy milyenekről tanultatok, SQL/newSQL, ill. noSQL szerepelt az anyagban? Elképzelhető, hogy egy noSQL adatbázis erre a feladatra sokkal jobb lenne, mint egy SQL. Na szóval szerintem még mindig kevés az info, hogy érdemben lehessen válaszolni.
-
inf3rno
nagyúr
Hát én úgy tudom, hogy csak párhuzamosított dolgoknál concurrency megakadályozására jobb többé-kevésbé a funkcionális programozás. Jól jöhet, ha többszálú kódot akarsz írni mondjuk java-ban. De ilyen téren tényleg nincs sok tapasztalatom, js világból jövök event loopból, elkényeztettek, nem nekem való az osztott memória, és hasonló nyalánkságok. :-) Java-s ismerősöm szerint magával a lisp-el nem sokat érsz, kis nyelv, a nagyobb nyelvekre írt adaptációi (ha ez a megfelelő szó), pl a clojure viszont annál piacképesebb. (Többet példát nem is tudok felsorolni, hehe.
) -
#8625
inf3rno
nagyúr
Sk8erPeter
#8624
inf3rno
nagyúr
válasz
Sk8erPeter
#8624
üzenetére
Szvsz. olyasmikre, amikor parancssorból kell behaxolni egy csomó dolgot, hogy működjön, amit akarsz. Néha belefutok én is ilyesmibe nagy ritkán. Általában viszont nagyon jól megvagyok az alap funkciókkal, azok szerintem sincsenek elbonyolítva.
Csak egy példa, így kell lekérni a repo útvonalát:
$(git rev-parse --show-toplevel)
Szvsz, ez egy elég jó példa arra, hogy hogyan nem szabad APIt tervezni. Semmi szükség arra, hogy ismerjem a rev-parse-t ahhoz, hogy egy ilyen szimpla adatot le tudjak kérni. Első ránézésre lövésem sincs, hogy mit jelent:
"git rev-parse is an ancillary plumbing command primarily used for manipulation."
Nekem a show top level is csak közepesen beszélő, inkább valami repo root path, vagy hasonló, ami megszokottabb szóhasználat lenne...
Mindenesetre ez az egész a clean code-tól elég messze van. Én jobb szeretem az IDE-be épített pluginnel használni a git-et, azt hiszem nem véletlen.
ez kész...
Akkor mégsem drágultak.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Háztartási gépek
- pr1mzejEE: Viszlát CoD2, CoD4, CS:GO!
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Need for Speed: Rivals
- Kettő együtt: Radeon RX 9070 és 9070 XT tesztje
- exHWSW - Értünk mindenhez IS
- Milyen NAS-t vegyek?
- Windows 10
- Magga: PLEX: multimédia az egész lakásban
- Milyen videókártyát?
- További aktív témák...
- BESZÁMÍTÁS! Microsoft XBOX Series X 1TB SSD fekete játékkonzol garanciával hibátlan működéssel
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- Dell Optiplex MT/SFF 3040, 3050, 3060, 3070, 5070, 7060/ Hp ProDesk /SZÁMLA- GARANCIA
- HP EliteBook 820 G2 i5-8300U 8GB 256GB SSD 12.5" 1 év garancia
- HP EliteBook 830 G8 i5-1135G7 16GB 256GB 1 év garancia
Állásajánlatok
Cég: FOTC
Város: Budapest