Hirdetés
- Lenovo Legion és IdeaPad Y széria
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
- Azonnali VGA-s kérdések órája
- Azonnali alaplapos kérdések órája
- LG LCD és LED TV-k
- Kormányok / autós szimulátorok topikja
- AMD Navi Radeon™ RX 9xxx sorozat
- Házimozi belépő szinten
- SSD kibeszélő
- Milyen TV-t vegyek?
-
PROHARDVER!
Új hozzászólás Aktív témák
-
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.
-
#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.
-
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.
-
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.
-
inf3rno
nagyúr
Szerintetek melyik az optimálisabb MariaDB-nél sebesség, memória, cpu szempontjából? Van batchenként mondjuk 100 értékem, amiről nem tudom, hogy változott e, benne van e egyáltalán a táblában, stb. 1.) Küldök be egy 100-as INSERT SELECT ON DUPLICATE KEY UPDATE-et, ahol kiválasztom, hogy melyik értékek változtak, és csak azokat frissítem be egy kérésben. Itt a CTE-be mondjuk JSON-ként teszem be az értékeket, vagy SELECT UNION-al, édesmindegy nekem. 2.) Tranzakcióba teszek egyesével 100 INSERT ON DUPLICATE KEY UPDATE-et. 3.) Csinálok egy SELECT-et, hogy mi változott, aztán tranzakcióban beküldöm a 2-eshez hasonlóan csak azt. Ez jobb hibakezelés szempontjából, ha valamilyen SQL elszáll, de kevésbé gyors lehet, mint az INSERT SELECT.
-
inf3rno
nagyúr
válasz
martonx
#20886
üzenetére
Egyáltalán nem ragaszkodom az SQL-hez. Teljesen jó nekem a Neptune erre a projektre. A cyper lekérdezőnyelvvel már játszottam régebben neo4j-vel, úgy nézem, hogy ez is támogatja. Ami kérdéses inkább a fejlesztői környezet, de elvileg localstack-el vagy serverless-el megoldható lambda fejlesztés, adatbázisnak meg tök jó a neo4j. Fellövöm valamelyik héten ezt az egyveleget AWS-en, aztán rákötöm valamelyik domainemre. Kíváncsi vagyok rá.
-
inf3rno
nagyúr
Mondok egy példát. Van egy pizza recept, amihez paradicsomszósz kell. A paradicsomszósz megvehető, de elő is állítható paradicsom sűrítményből vagy egész paradicsomból receptek alapján. Szóval igazából amikor egy receptet kérdezel le összetevőkkel, akkor valójában egy teljes gráf szeletet kérdezel le egy csomó alapanyagok előállításához való recepttel együtt. Ha versenyezni akarsz mondjuk egy nosaltyval, akkor kellenek az ilyen többlet szolgáltatások, hogy mondjuk ha van 2kg paradicsom otthon, akkor felajánlja, hogy főzzél belőle szószt ahelyett, hogy elküld a boltba kész szószért. Mondjuk nem biztos, hogy erre mindenkinek van igénye, én csak magamból indulok ki, hogy nem mindig van minden itthon és fogalmam sincs, hogy mit főzzek.
-
inf3rno
nagyúr
Ahogy nézem with recursive lekérdezéssel megoldható még abban is. Igazából én nem szeretném SQL adatbázisban megoldani, mert azok nem erre valóak meg leginkább azért, mert gyakorolni akarom a felhő alapú technológiákat. Akarok egy itthoni AWS és talán egy Azure accountot is gyakorolni.
-
inf3rno
nagyúr
válasz
martonx
#20878
üzenetére
Én most gondolkodok egy hobbi receptgyűjteményes projekten, hogy megnézzem melyik környezetben mik a lehetőségek. Az egész kb. 10-15 SQL tábla lenne. A neheze, hogy gráfban kell lekérdezni kb. 5-10 kapcsolat mélységig, hogy bármi hasznosat megtudjak. Szóval erre talán gráf adatbázis lenne jobb. Úgy nézem, hogy Azure környezetben van a Cosmos, AWS-ben meg a Neptune, ami ilyet tud, és mindkettő egész olcsó, ha valami nagyon minimumra veszem a használatot.
-
inf3rno
nagyúr
válasz
martonx
#20874
üzenetére
Ja most nézem, tényleg el van szállva az ára a Redisnek és az RDS-nek is minimum 100 USD. AWS környezetben olcsósítva akkor maradhat az, hogy Lambda + S3(JSON/CSV) + Athena. Amennyire értem, hogy mit akar, gyakorlatilag elég neki annyi, hogy előállítja az adatot, bizonyos időközönként a játék szerver adatai alapján, aztán kiolvassa a legrégebbit, esetleg Athena-val még keresni is tud benne. Azure-al tisztában van valaki, hogy ott mik elérhetőek olcsón? Szeretnék abban is valamennyi tapasztalatot szerezni.
-
#20873
inf3rno
nagyúr
MasterDeeJay
#20872
inf3rno
nagyúr
válasz
MasterDeeJay
#20872
üzenetére
AWS Lambda kell, és ElastiCache-be betenni egy időzített folyamattal mondjuk percenként az adatot, aztán onnan kiszívhatja a lambda, és nem zavarja a játékszerveredet sem, ha szétDDOSolják a Lambdát. Már ha AWS a környezet. Amúgy ahogy írták DDoS-ra meg jó a CloudFlare.
-
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.
-
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. -
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.
-
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.
-
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?
-
#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.
ez kész...
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Lenovo Legion és IdeaPad Y széria
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Hardcore café
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
- Azonnali VGA-s kérdések órája
- Filmvilág
- Jövedelem
- Autós topik
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Poco F6 5G - Turbó Rudi
- További aktív témák...
- Újszerű Sony PS4 500GB, 1db DUALSHOCK 4 kontrollerrel
- Új, felbontott Kingston FURY 24GB (1 modul) Renegade DDR5 8000MHz CL38 KF580C38RW-24 - 24 hó gari
- Honor 90 512GB,Újszerű,Dobozaval,12 hónap garanciával
- Motorola Moto G72 128GB,Újszerű,Dobozaval,12 hónap garanciával
- Xiaomi 13T 256GB,Átlagos,Dobozaval,12 hónap garanciával
- Apple iPhone XR 64GB,Átlagos,Dobozaval,12 hónap garanciával
- BESZÁMÍTÁS! SAPPHIRE B650M R7 8700F 32GB DDR5 512GB SSD RX 6800 16GB Zalman S2 TG GIGABYTE 750W
- GYÖNYÖRŰ iPhone 12 mini 64GB Kék -12 hónap JÓTÁLLÁS - Kártya független, 100% gyári Akkumulátor
- Eladó igazi ritkaság! LG G7 Thinq 4/64GB / 12 hónap jótállással!
- BESZÁMÍTÁS! SAPPHIRE B650M R7 8700F 16GB DDR5 512GB SSD RTX 4060Ti 8GB Zalman S2 TG ADATA 600W
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest