-
IT café
Új hozzászólás Aktív témák
-
martonx
veterán
Ne felejtsük el, hogy esetében kemény 512Mb a ram, amiben minden benne kell, hogy legyen. Emellett a DigitalOcean-os szerverek SSD-sek (mondjuk ettől még lehet azért lassú az IO). Szóval én ezért szavaznék a file rendszerre, valami normális cache rendszer helyett.
Én kérek elnézést!
-
veterán
Redishez nincs erőforrás a felhős gépben.
Memcached csak Linuxra van, a fejlesztői gépem windowsos. Lehetne külön Linuxon futtatni a Memcachedet, de az teljesítményben hátrányos lenne, mert az app (még) monolitikus felépítésű, minden 1 gépen kell hogy fusson.
Ehcachet is nézegettem, az szimpi is volt. De ennyi erővel megtarthatnám a Kotlin objektumot egy pl StatService osztályon belül, ahelyett, hogy kiszerializálom JSON-né. Aztán ez az osztály felelne az időnkénti frissítéséért az objektumnak, és szolgálná ki a kéréseket. Nem?
Ehcachet használva annyi lenne más, hogy a StatServiceben nem közvetlenül van benne az objektum, hanem azon keresztül az Ehcachenek a cache-ében JSON-ként.Konzulensem amúgy Mongot és Redist ajánlott, ezekhez ugye nincs erőforrás. Jövőhéten jön ki az új MySQL, amiben lesz JSON type, azt is lehetne használni, mivel az az RDBMS-em, bár ennek kérdéses, hogy milyen Java API-ja lesz. Ha szar, de ez lenne a jó irány, akkor meg le lehetne cserélni postgresre is.
[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
Karma
félisten
válasz martonx #9151 üzenetére
Na, én ezt teljesen elfelejtettem. Vegyétek úgy, hogy nem jöttem ide beleokoskodni.
Egyébként nekem nagy szerelmem a Redis, nem is mint cache, hanem mint adatbázis - a beépített adattípusaival sokféle problémát le lehet írni, és azokat elég jó komplexitással és in-memory lévén durva futási teljesítménnyel meg is oldja.
--
De mégis visszatérve az on-topic kérdésre: a DO-s szerver mellé nem lehet hozzácsapni egy RedisToGo-t vagy más, ingyenes modellben is futtatható szolgáltatást?
[ Szerkesztve ]
“All nothings are not equal.”
-
nagyúr
válasz Oppenheimer #9152 üzenetére
> Mongot
gratulalunk
(mongo: losing data on web scale!)
while (!sleep) sheep++;
-
martonx
veterán
Igen, a redis brutál jó!
Illetve azt én is fel akartam vetni, hogy a mezitlábas megoldások helyett, mi lenne ha nem havi 5, hanem 10 dollárt szánnánk a szerverre, ezzel rögtön megduplázva a rendelkezésre álló memóriát? Ha meg olyan komoly a projekt, a havi 20 dollárt sem érzem istenkáromlásnak 2 mag, 2gb ramért.
Én kérek elnézést!
-
veterán
-
válasz Oppenheimer #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?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.Buliban hasznos! =]
-
veterán
válasz bambano #9158 üzenetére
Eddig nem volt szükség JSON-re, nem is gondoltam, hogy lesz. Pont akkor jött a hír, hogy jön MySQL-be, amikor nekem szükségem lett rá.
VPS-en Ubuntu lesz, szóval crossplatform technológiákkal dolgozok.
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
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?
[ Szerkesztve ]
Buliban hasznos! =]
-
veterán
-
veterán
-
veterán
válasz Oppenheimer #9164 üzenetére
Nagyon jó, bevált!
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
vimes
senior tag
Sziasztok,
Windows-os C fordítóprogrammal kapcsolatos kérdésem lenne. Alapvetően valamelyik Visual Studio kiadás érdekelne (ingyenes a DreamSpark-ból). Tegnap előtt letöltöttem a VS 2013-at, de ott alig lehetett testreszabni a telepíthető komponenseket, egy csomó olyan dolog települ, amire nincs is szükségem ( Visual F#, stb.). Régebben használtam a VS 2010 Professionalt, és ott azt hiszem, hogy ki lehetett választani, hogy mely nyelvek könyvtárait akarom telepíteni, meg egy csomó minden mást, de ebben már nem vagyok biztos kísérletezgetésből meg ennyi elég is volt. C-ben tanulunk programozni, nincs arra szükségem (még), hogy más nyelvekhez tartozó komponenseket telepítsek (feleslegesen foglalná a helyet). Tud valaki segíteni, hogy milyen c fordítót válasszak? köszi.
Szerk: a VS-t eddig csak C#-hoz használtam még régebben (kb. két éve utoljára), úgyhogy ha vmi hülyeséget írtam volna vele kapcsolatban, sry.
[ Szerkesztve ]
"Ole, ole, ole, ola, der FCK ist wieder da! Ole ole, ole ola, die roten Teufel sind ganz wunderbar." Let's go Bezte!
-
veterán
mondjuk aki alap vezérlési szerkezeteket tanul, annak lehet, hogy nem érdekes az Idea refaktorálási képessége, vagy a VS akármilyen tulajdonsága. amit írtál az persze igaz, de a kezdőket szerintem nem érinti.
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
nagyúr
-
amargo
addikt
válasz Oppenheimer #9169 üzenetére
Ez teljesen igaz, viszont később, ha elkezd dolgozni, akkor vélhetően normális IDE lesz előtte, na akkor nagy előny tud lenni, hogy ismeri már.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
-
Sk8erPeter
nagyúr
válasz bambano #9172 üzenetére
Tényleg azt javasolnád egy kezdőnek, hogy k×rjon el rengeteg időt azzal, hogy megismerjen egy ahhoz nem szokott felhasználó számára elképesztően kényelmetlen eszközt, és majd csak azután kezdjen el programozni, hogy legalább megtanulta, hogyan lehet egy árva sort bepötyörészni benne, majd elmenteni a fájlt?
Sk8erPeter
-
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.
Buliban hasznos! =]
-
válasz Sk8erPeter #9173 üzenetére
végülis javasolhatom azt egy kezdőnek, hogy addig meg se mozduljon, amíg fel nem rakott egy jáva vm-et, a hozzá való ide-vel, jdbc driverrel meg egyéb cuccokkal ami egy kisebb vidéki isp-nél akár 2-3 nap alatt lehussan a hálózaton
vagy tanuljon meg egy olyan editort, ami minden unixon ott van, értő kezekben borzalmasan hatékony és gyors, akár mobil internetes vonalon keresztül is.
szerk: egyébként is az élet nem habostorta az it-n
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Sk8erPeter
nagyúr
válasz bambano #9175 üzenetére
Első bekezdésre: igen, nyugodtan javasolhatod, a next-next módszerű telepítőjükkel ezerszer egyszerűbbek ezek a folyamatok így is, mint egy vi(m) megtanulása, ami nemhogy órákat, inkább napokat (heteket?) vesz el az ember idejéből, egy kezdő szempontjából feleslegesen, amikor az ember a saját arcának levakarása helyett inkább foglalkozhatna azzal is egyből, amivel tényleg szeretett volna (hány egyszerű grafikus alapú szerkesztő létezik). A vidéki ISP-ket meg hagyjuk már, gondolom ezt most Te sem gondoltad komolyan, hogy valós érv. Aki programozni tanul, mindenképpen súlyosan rá van szorulva a nethasználatra, de inkább nem is kezelem komoly érvként ezt a szempontodat.
(#9174) inf3rno: Igen, de a kedvencem az, hogy sokszor visszajelzést sem kapok arról, hogy most mit is csinálok, csak amikor már mondjuk sikerült elcsesznem valamit, vagy csak a közelében járok a megoldásnak. Na ezt nem, tényleg úgy voltam vele, hogy szopassa magát az, akinek jólesik (imádom a hotkey-ket és a billentyűzet segítségével gyorsan elérhető funkciókat, de ez már gáz). Én elfogadom, hogy nagyon kéz alá tud dolgozni, de egyrészt milyen áron, másrészt egy IDE-ről is ugyanez elmondható (ha az jó), és igen, tény, hogy az viszont jóval komolyabb erőforrás-igénybevétel mellett teszi ezt (cserébe esetleg tud olyat is, amit a vi és társai közel sem, vagy csak további mágikus hotkey-k megtanulása árán). Azért már pár éve programozás közelében vagyok, és sosem éreztem hiányát, hogy nem voltam hajlandó megtanulni egy ilyen komoly szenvedések árán később talán megtérülő eszköz használatát, mint a vi és társai - erre mondjuk az ellenérv nyilván az egy fan részéről, hogy csak azért gondolom így, mert nem tudom, mit veszítek vele (de én abból tényleg nem kérek).
[ Szerkesztve ]
Sk8erPeter
-
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...
Buliban hasznos! =]
-
vimes
senior tag
Köszönöm az eddigi javaslatokat feltettem a a Dev-C++-t, nem egész jó volt, de a fordítóval nem voltam megelégedve. Megnézettem, h van-e a forráskódban hiba, nem talált semmit, futtattás, majd kapom a hibaüzenetet, hogy *.exe működése leállt, a Windows megoldást keres a problémára... hibaüzenet semmi. Lefordítom ugyanazt gcc-vel Linux alatt a Terminálban, azonnal jön a hibaüzenet, látszik is azonnal, hogy elhagytam az fsanf() egyik argumentumánál az & jelet. Fogalmam sincs, hogy egy ilyen alap hibát hogy nem vett észre... ezt a Code:: Blocks-ot mindenféleképp kipróbálom.
A környezethez, amiben programozunk, annyit, hogy Linux + gedit + terminál (gcc) a legjobb barátunk a szemeszter kezdete óta, zh-kon is ezt kell használni, semmi sallang. Semmi kényelmi funkció, emlékszem mikor C#-ot tanultam VS alatt kb. sose írtam ki pl. hogy Console.WriteLine, stb. kb. csak az Enter-t nyomogattam végig, de annyira elszoktam ezektől, hogy pl. amikor a Dev-C++-nál automatikusan kirakja a kapcsos, kerek, ill. szögletes zárójelek másk felét, inkább zavart, mint hasznos volt, most "szoktam vissza a jóhoz", de mondom sajnos gyakorlatom meg zh-n nincs ilyen kényelem
[ Szerkesztve ]
"Ole, ole, ole, ola, der FCK ist wieder da! Ole ole, ole ola, die roten Teufel sind ganz wunderbar." Let's go Bezte!
-
vimes
senior tag
Mondom, ha Linux alatt Terminálban fordítottam gcc-vel a kódot, kaptam hibaüzenetet arra a sorra, utan meg csak rá kellett pillantani és azonnal látszott, hogy hiányzik a & az argumentum elől.
"Ole, ole, ole, ola, der FCK ist wieder da! Ole ole, ole ola, die roten Teufel sind ganz wunderbar." Let's go Bezte!
-
rii
nagyúr
sziasztok
van még eljárás orientált (az oopl nem megy .... ) nyelv amit használnak manapság, vagy ha nem is használnak, de lehet benne programokat írni?
előre is köszönöm!
piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
rii
nagyúr
Borland C van még?
vagy már csak Borland C++
vagy az csak win 3.11 -ig volt? .-)piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
rii
nagyúr
válasz dabadab #9186 üzenetére
akkor nem fogok tudni eljárásorinteált nyelvet találni amivel lehet X, OSX, vagy win alá írni bármit is?
..... megpróbálom megértem az OOPL-t ....
.-/csak 2002-ben totál nem jött be a C#, azt kellett volna tanulni ...
Linux alatt milyen OOPL nyelvet tudnék elkezdeni?
piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
dabadab
titán
"akkor nem fogok tudni eljárásorinteált nyelvet találni amivel lehet X, OSX, vagy win alá írni bármit is?"
Ahogy az ősi bölcsesség tartja: minden nyelven lehet FORTRAN-ban programozni
Egyébként meg vannak bindingek C-hez is (a GTK pl. egyenesen C-ben íródott), csak éppen pont ez a téma, ahol nagyon adja magát az OO (amit egyébként túlmisztifikálni, tulajdonképpen bármilyen kellőképpen bonyolult, procedurális nyelvben normális megírt programnál előjön az OO, mert adott komplexitásnál egyszerűen az a természetes, hogy az ember nem kilométeres paraméterlistát használ, hanem egy struct-ot ad át a függvényeinek, aztán amikor az ember elgondolkodik azon, hogy van X darab függvénye, amik paraméterként megkapnak egy Y structot meg esetleg még néhány egyéb dologt, akkor tulajdonképpen sikeresen írt egy osztályt procedurális nyelven.
"Linux alatt milyen OOPL nyelvet tudnék elkezdeni?"
Tulajdonképpen bármit, a kérdés inkább az, hogy mit szeretnél? Ha csak gyorsan csinálni valamit, ami aztán fut mindenhol (mert a kérdéseidből úgy tűnik, hogy ilyesmiről lehet szó), akkor Python.
DRM is theft
-
ha nehezen megy az oop, akkor rakj fel linuxra egy régi netbeanst, meg visualwebpack-ot, és azzal kezdj el programozni. a visualwebpackben olyan kódgenerátor van, ami az oop kód vázát megcsinálja, neked csak a procedurális részt kell kitölteni.
előfordulhat, hogy ezzel olyan példákat kapsz, ami segít megérteni az oop-t.
egy baj van a tanáccsal: régen nem fejlesztik már ezt, úgyhogy kőkori minden. ha jól emlékszem, a 6.7-es netbeansben volt utoljára vwp, én az 5.5.1-est használtam sokáig. és ha úgy érzed, hogy ezzel sikerült megfelelően előrelépni, akkor az egész múzeumot hajítsd ki a francba
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
rii
nagyúr
válasz dabadab #9188 üzenetére
megnézem a Python-t
és ha esetleg az oopl-be el szeretnék méllyedni?
akkor merrefele lehetne még nézelődni? .-)(egy régebbi linux alatt láttam, hogy van az emacs ... az prog, nyelvekhez kitalált editáló program?
(#9189) bambano:
jobb szeretném akkor már magam megtanulni amit csak lehet .-)
elég ha a html oldalakat dreamweaver-ben csinálnom, oszt van benne jócskán mindenféle dolog, amin csak pillogok ...volt egy ilyen könyvem: BRIAN W. KERNIGHAN – DENNIS M. RITCHIE – ANSI C .... inkább még az 50 oldalas bevezetőt is elolvasom, csak értsem is amit csinálok .-)
[ Szerkesztve ]
piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
-
-
Jim Tonic
nagyúr
Múltkor volt itt Karnaugh-tábla, azért nem jött már meg elsőre fejből.
Egyébként szerintem sok nyelven meg lehet kerülni bizonyos határig az OO-t, ha az ember Forms-okkal dolgozik, és csak az eseménykezelőket írja meg. Ha onnan elkezd utána leásni, hogyan is áll össze egy ablak, akkor meg tudja érteni hátulról az OO-t. Főleg, hogy a legtöbb komponenst csak fel kell rámolni, szinte mindenre van kész megoldás.
Alcohol & calculus don't mix. Never drink & derive.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Dell 5820: Intel Xeon W-2135, 64GB DDR4, 256GB NVMe SSD, Nvidia Quadro P600, USB 3.1 C/A, ÁFÁs
- Eladó alig használt benq Zowie xl 2411P kihasználatlanság miatt karcmentes, tökéletes állapotban
- Honor X6a 128GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy S23 Ultra 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- iPhone 15 Pro Max 256GB