- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Az NVIDIA ipari AI-felhőt épít a németeknek, együtt az OpenAI és a Google
- Két új Ryzen közül választhatnak a kézikonzolok
-
PROHARDVER!
Új hozzászólás Aktív témák
-
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.
-
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 .-)
-
bambano
titán
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
-
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.
-
rii
nagyúr
-
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
-
#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...
-
#9176
Sk8erPeter
nagyúr
bambano
#9175
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).
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#9175
bambano
titán
Sk8erPeter
#9173
bambano
titán
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
-
#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.
-
#9173
Sk8erPeter
nagyúr
bambano
#9172
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?
-
#9171
amargo
addikt
Oppenheimer
#9169
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.
-
#9170
emvy
félisten
Oppenheimer
#9169
válasz
Oppenheimer
#9169
üzenetére
igazad van.
-
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.
-
#9165
Oppenheimer
nagyúr
Oppenheimer
#9164
Oppenheimer
nagyúr
válasz
Oppenheimer
#9164
üzenetére
Nagyon jó, bevált!
-
#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. -
#9158
bambano
titán
Oppenheimer
#9152
bambano
titá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?
-
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.
-
#9154
emvy
félisten
Oppenheimer
#9152
válasz
Oppenheimer
#9152
üzenetére
> Mongot
gratulalunk
(mongo: losing data on web scale!)
-
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?
-
#9152
Oppenheimer
nagyúr
Karma
#9148
Oppenheimer
nagyúr
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.
-
martonx
veterán
-
-
#9148
Karma
félisten
Oppenheimer
#9146
Karma
félisten
válasz
Oppenheimer
#9146
üzenetére
Én továbbvinném, amit bambano írt, és a fájlrendszert is kihagynám a buliból. Redist, Ehcache-t vagy Memcached-t elő, aztán hadd szóljon. A fájlokkal szórakozni feleslegesen alacsony szintű, és teljesítményben se determinisztikus.
-
#9147
bambano
titán
Oppenheimer
#9146
bambano
titán
válasz
Oppenheimer
#9146
üzenetére
azt, hogy ne akard újra feltalálni a kereket.
az oprendszerben van blokkeszköz cache, ne programozz le ilyet, használd azt.
a fájlrendszer megoldja rendesen a konkurens hozzáférést, azt használd és ne agyalj máson.minden, amit újrafelhasználsz, a te melódat csökkenti.
-
Karma
félisten
-
#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.
-
#9143
Oppenheimer
nagyúr
inf3rno
#9142
Oppenheimer
nagyúr
válasz
inf3rno
#9142
üzenetére
Ez egy stateless web service.
Adatbázis view-val nem érnék sokat, amikor JSON-t akarok tárolni, nem pedig query-k eredményét.
Böngészők nem kommunikálnak a web service-szel, így nem látom értelmét HTTP cachenek.
Valóban nem bonyolult feladat, de már megbeszéltük, hogy érdemes megoldani.
-
#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.
-
#9140
Jim Tonic
nagyúr
Oppenheimer
#9139
válasz
Oppenheimer
#9139
üzenetére
Még azt megteheted pluszban, hogy ramdrive-ot hozol létre. Akkor nagyon gyors lesz az írás-olvasás. Szinte esélytelen olyan ütközés, amiből gond lenne, de az read errort amúgy is kötelező kezelni.
-
#9138
bambano
titán
Oppenheimer
#9136
bambano
titán
válasz
Oppenheimer
#9136
üzenetére
szerintem web szerver adatterületére kell kigenerálni a statisztikákat.
rendes fájlrendszernél nincs probléma abból, hogy az egyik szál kiszolgálja a fájlt, a másik meg letörli vagy újraírja. max. abból lehet gond, hogy újraírás közben kezdi letölteni, mert akkor lehet, a végét nem kapja meg a kliens.ilyenkor szokás temporális fájlba generálni az eredményt és egy move utasítással a helyére tenni.
-
#9137
Jim Tonic
nagyúr
Oppenheimer
#9136
válasz
Oppenheimer
#9136
üzenetére
Szerintem az nem gond. Ha Te szerkesztésre nyitod meg, a többiek akkor is tudják olvasni. Ez akkor így így lenne, ha DB-ben tárolod. Ha exlusive lock kerül rá, a többiek nem látják, shared lock esetén meg előfordulhat, hogy éppen módosítod.
-
#9136
Oppenheimer
nagyúr
Jim Tonic
#9135
Oppenheimer
nagyúr
válasz
Jim Tonic
#9135
üzenetére
A kliens program egy mobil app, és feltehetjük, hogy használják mondjuk 1000-en egyszerre. Ezek HTTP-n kommunikálnak a szerverrel, és időnként kérik a statisztikát.
Sima fájlba mentéssel az a gond, hogyha letelt az adott idő, és újrakalkulálta a szerver a statisztikákat, akkor nem írhatja csak úgy felül a fájlt, mert lehet, hogy épp egy másik szál olvassa. Ennek kezelésére meg megint állapot kerülne a szerverbe. Ez nem kerülhető el?
-
#9135
Jim Tonic
nagyúr
Oppenheimer
#9132
válasz
Oppenheimer
#9132
üzenetére
Miért nem tolod ki simán XML-be vagy JSON-ba? Utána olvassák azt a kliens programok.
-
#9134
Oppenheimer
nagyúr
martonx
#9133
Oppenheimer
nagyúr
válasz
martonx
#9133
üzenetére
Azt elírtam, 512MB RAM van.
Viszont adat az nincs sok, max pár megabájt lenne. Elfér a memóriában is, de kerülhetne diszkre is, sokat nem számít. Lényeg az, hogy ne kelljen mindig végigolvasni a teljes adatbázist, amikor egy kliens kéri ezeket az adatokat. Simán csinálhatnék egy statikus komplex Java (Kotlin) objektumot, ami ezt tárolja, de akkor elveszne a szerver app stateless-sége.
Nem is gondoltam volna, de memcached-et nem lehet használni Windowson, ami a fejlesztői platformom, szóval az már nem is opció.
-
#9133
martonx
veterán
Oppenheimer
#9132
martonx
veterán
válasz
Oppenheimer
#9132
üzenetére
Az 1Gb ram miatt én bármilyen fapados is, de a lementett statisztikát simán file-ban tárolnám. Ha jól értem ez nem más mint egy nagy Json adat.
Ha bőven lenne ram a gépben, akkor javasolnám a redis, memcache- meg ilyesmik használatát. Bár azt sem tudjuk, hogy mekkora adatról van szó, mert ha pár száz Kbyte, akkor vélhetően simán elfér a memóriában is. -
#9132
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Sziasztok!
Belinkelném ide az SO kérdésem, hátha valaki tud rá itt válaszolni. Sejtésem szerint fogtok tudni.
-
rii
nagyúr
válasz
dabadab
#9130
üzenetére
elékérem akkor a főnöktől (émn csak 3 hónapig vagyok itt beigró ember ha minden jól megy tovább nem kell maradnom) a rendszergazda számát, és elmondom az általatok felvázolt lehetőségeket.
(#9129) Karma:
jó tipp .... megkérdezem, ... én sem tudom ... bevallom, eddig csak véletlenül indítottam le .. mert sose kellett a munkámhoz ... de jó volna mert pont kéznél van -
dabadab
titán
"vagy ha az indexelést le is írtad már, akkor végülis akkor "csak" arra kell egy kis program, ami a grep-pel megadott találatot jeleníti meg?"
Igen, nagyjából. Nem ismerem az OSX-et, de erős a gyanúm, hogy ilyen minimálguit valami kis scripttel is pillanatok alatt össze lehetne dobni.
-
rii
nagyúr
válasz
dabadab
#9126
üzenetére
nekem ez amegodlás nagyon tetszik ...
.... csak az a baj, hogy akkor lenne jó, ha egy finder ablakot dobna fel, amiből be lehet húzni a képet az InDesign-ra (4-5-6 operátor munkájánál lenne fontos, hogy mukodjon a keresés)vagy ha az indexelést le is írtad már, akkor végülis akkor "csak" arra kell egy kis program, ami a grep-pel megadott találatot jeleníti meg?
-
rii
nagyúr
válasz
Jim Tonic
#9125
üzenetére
akkor beszélnem kellene azzal aki leprogramozta a képtátat (abban minden kép fent van)
hogy tud-e még egy "mező"-t hozzáadni, ami tartalmazná az elérési útvonalat, és hogy drag'and'drop-pal be lehet-e húzni InDesign-ba?könyvtárfigyelés:
próbálkoztam már vele OSX alatt ... az a baj, hogy ha van egy könvtár
"kepek"
és abban van egy alkönytvar, és az alkönytárba írok, akkor hiába figyeli a "kepek" foldert, hiszen annak egy subdirectorí-jaba történik a mozgás ... és elég gyarkra létre kell hozni ilyen subdirectorikat, 200 képenként ....meg szabad kérdeznem, bővítményen alatt mit kell érteni?
Nem értek hozzá ... -
Az adatbázis, az adatbázis.
Legnagyobb előny lenne, hogy nem kellene az indexeléssel foglalkoznod, megcsinálja a motor. Ha automatikus tárolást akarsz, akkor csak egy pici program kell, ami figyel egy könyvtárat, ahová mentesz a böngészőből, és letárolja neked. Eset lehet próbálkozni bővítmény készítéssel. De az is lehet, hogy létezik már ilyen. -
rii
nagyúr
válasz
Jim Tonic
#9123
üzenetére
mennyire nem lenne gyors?
egy hétvége csak elég lenne neki, nem?
de egy este jó lenne ... 10-kor elindul, 9-re végez ...kb. 200.000 átlag 5 MB-os képek
meg 100.000 70-200 MB-os fotókaz adatbázist úgy érted, hogy böngészőből elérhető pld. képtár?
most hogy mondod, és remélem jól értettem az "adatbázis"-t, olyan van, csak az a baj, hogy legjobb lenne finderből berántanivagy ha esetleg a böngészőből lehetne egy kis ablakkal ezt megoldani ... minimal funkciók (mert a képtár eléggé bonyolult asziszem . nem is láttam még az ittenit működés közben)
hogy csak control c control v, enter, kiadja a találatot, és ezt egyből rá kellenne tudni hőzni az indesign egy képboxára, mert finderből csak ennyi lépésbből állnanem tudom, tud-e olyan "path"-t mutatni a web browser a program felé, mint a finder file-kezelő
-
Így keresés nem lenne nehéz, sőt, nagyon gyors lenne, viszont az indexelés így sem lenne gyors. Nem tudom, mit tároltok, de nem lenne érdemes az egészet egy adatbázisba tenni? Mert akkor két legyet ütnél egycsapásra, és minden gyors lenne. Ha ez mondjuk egy DMS-szerű valami, akkor meg eleve adatbázisban a helye.
-
rii
nagyúr
köszönöm a segítséget!
(#9120) dabadab: ahogy emvy is írta, igen .. szeritzem az index file lenne 15 mega ... még a régi 286-osomra is felférne ,-D
(#9117) Karma: szerintem lehetne egy "index frissítés" gomb .. arra valaki este mikor elmegy rányom ... (ez lehetne egy kis laptop is) és azon a gépen akkor a program végignyálazza az este alatt a 8-10 terát, reggelre csak végez.
tartalomra nem ... csak a file nevekben szeretnénk keresni ...
néha jól jönne h mondjuk tudnék keresni a egy sra, arra kiad 200 talatot mondjuk, majd eztz lehetne szűkíteni .. ez a Find Any File-ban láttam, de ez már csak hab lenne a tortán ...(#9118) Jim Tonic: a technikai héttár szewrintem rendben van .... csak ez a keresés hiányziok de nagyon .-((((
(#9119) emvy: nem tudom még potnosan mennyi file ... mekkora adatmennyiség (végól is csak a file db-szám fontos ... kb. 120.000 file, amik képszámosak .... 35.000-125.000, meg van többezer még aminek neve van ... szerintem max. 200.000-300.000 db file lehet .... nem tudom mikorra mondja meg a "Get info" ... calculating van ..... szerintem estig ,-D
-
-
Ez nagyon minimalis adatmennyiseg -- igazabol itt a feladat nem az, hogy gyors legyen (mert szinte muveszet lenne lassura megirni), hanem az, hogy vegigolvasgasd a fajlokat idonkent. OSX alatt sajnos nem fejlesztek, egyebkent eleg egyszerunek tunik (vszeg Elasticsearch-ot raknek ala, de valoszinuleg az se kell).
(Osszehasonlitaskepp: licencfeltetelek miatt egyetlen CPU core-on futo adatbazist hasznaltam egy regebbi melonal, napi 50-100 millio uj sort inzertaltunk, az egyszerubb intraday lekerdezesek siman vegeztek masodperc kornyeken, de idonkent 1-2 eves adatmennyiseget kellett analizalgatni, es az se volt kivitelezhetetlen).
-
Karma
félisten
És ki fogja előállítani, neadjisten frissíteni ezt a fájlt? Az a része a necces, nem az indexfájlodban kotorászás. Bár igazából mivel nem specifikáltad túl a feladatot, lehet tényleg overkill a Solr.
Fájlnevekre akarsz keresni, vagy tartalomra is (utóbbira jó igazán a Solr + a Tika, meg gondolom más keresőrendszerek)? Pontos egyezést akarsz, töredékes keresést vagy vagy fuzzy keresést is?
-
rii
nagyúr
nem gondoltam volna, hogy egy 300.000 tételből álló file-ban való keresés megakaszthat egy mai gépet.
.-(
hogyha a 300.000 téleg áátlag 50 karakterből áll, (a fele inkébb csak max 40 ből)
akkor is 50 karakterrel számolva 15.000.000 karakter ... ami a memóriába is lazán fellőhető ....de persze szimpatikusabb is, amit Te írtál.
próbáltam utánanézni ... de nem is igfazán értem mi-micsodamilyen költségekkel lehetne ez esetben számolni?
-
Karma
félisten
-
rii
nagyúr
sziasztok
OSX alá valaki le tudná programozni az alábbiakat? (egy file kereső program a serveren)
- saját index file-t csinál beállítható időpontokban, saját gépre, vagy hálózatra (ha hálózatra, akkor a többi gép is tudja használni, és csak egy gépnek kell erőlködnie az index-file elkészülésével
- találati listában a találatokat Drag'n'Drop-pal be lehet húzni egy msáik programba
- találti listában a találatokon jobb gombra legyen "Reveal in finder"ha valalki ezt meg tudná csinálni, akkor e-mailcímmel írjon kérem privátot, és eljuttatom a cégvezetéshez.
a program lényege: egy több terás háttértáron lehessen keresni .... beírja az ember, hogy 75966, és kiadja 2 mp alatt ... ami szerintem index file-t használva nem lehetetlen, mivel csak az index file-t kell átnyálaznia a programnak ....
most .... mivel valszeg windows-os a szerver, ezért a finder-spotlight nem keres rajta ...
-
brd
nagyúr
Sziasztok, nem találtam konkrét .NET-es topicot, így itt kérdezem: van egy .NET-es ClickOnce alkalmazás, itt a legalsó. A setup lényegében létrehoz egy parancsikont, ami JoystickCurves.appref-ms néven fut, és ez a tartalma:
http://www.xedocproject.com/joystickcurves/JoystickCurves.application#JoystickCurves.application, Culture=neutral, PublicKeyToken=582c649bb763629a, processorArchitecture=x86
Így letöltődik a legfrissebb (gondolom legalábbis, hogy valami ilyesmi ezen faramuci megoldás létezése) program, és elindul. A letöltődő programot természetesen megtaláltam, de Internetelérés nélkül nem igazán akar elindulni, ez részben azért baj, mert szeretném offline is futtatni. Lehet ezt, ill. hogyan?
-
válasz
dabadab
#9107
üzenetére
Ez egy tökéletes példa. A program viszonylag könnyen összezavarható, ha aközött ugrálsz, hogy nyerni vagy veszíteni akarsz. A program ugyanis azt feltételezi, hogy nyerni akarok, és eszerint tippel. Mindjárt kiegyenlített marad az eredmény. Vagy csak mázlim volt, de nem hiszem, mert veteránon nagy adatbázisból dolgozik. Persze ez nem bizonyít semmit, de szerintem kijátszható.
-
#9107
dabadab
titán
Oppenheimer
#9105
dabadab
titán
válasz
Oppenheimer
#9105
üzenetére
Van számítógépes kő-papír-olló bajnokság, ha ráklikkelsz a botoknál Human VS Computer gombra, akkor te is szerencsét próbálhatsz: [link]
-
bambano
titán
válasz
mrhitoshi
#9087
üzenetére
másik ötlet: egy cikk szerint lehet olyan kő-papír-olló játékot írni, ami ember ellen játszva statisztikusan nyer. agyturkászok vizsgálták, hogy az ember milyen pszichés folyamatok alapján játszik. erre alapozva szerintem írható olyan kő-papír-olló program, ami folyamatosan tanul, és elég játék után szignifikánsan többször nyer, mint veszít.
ez is egy jó feladat, 2^9-en sorba pont megfelel.
-
#9101
bambano
titán
Oppenheimer
#9093
bambano
titán
válasz
Oppenheimer
#9093
üzenetére
csak amikor Dabadab kiteszi a szmájlit, akkor ő naprendszer alatt nem egy napot plusz kilenc bolygót ért, hanem egy napot, kilenc bolygót, azok holdjait, az aszteroida övezetet, a Kuiper övet meg egy csomó kósza üstököst érti
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- ÚJ Lenovo Legion Pro 5 16IRX9 - 16" WQXGA 165Hz - i5 14500HX - 32GB - 1TB - RTX 4060 - 3 év garancia
- T14s Gen4 14" FHD+ IPS i7-1365U 16GB 512GB NVMe magyar bill IR kam gar
- Gopro hero 7 black
- ThinkBook 16p Gen3 16" QHD+ IPS Ryzen 5 6600H RTX 3060 16GB 512GB NVMe ujjlolv gar
- ThinkBook 16p Gen3 16" QHD+ IPS Ryzen 5 6600H RTX 3060 16GB 512GB NVMe ujjlolv gar
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged