- Apple Watch Sport - ez is csak egy okosóra
- Samsung Galaxy S25 - végre van kicsi!
- Mobil flották
- iPhone topik
- Honor 200 Pro - mobilportré
- Leesett a kamionról több millió eurónyi Z Fold7
- Yettel topik
- Samsung Galaxy Watch6 Classic - tekerd!
- Garmin Venu X1 - vékony, virtuóz, váltságíjas
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
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
-
#17585
racskobalazs
senior tag
martonx
#17584
racskobalazs
senior tag
válasz
martonx
#17584
üzenetére
Szia,
Köszönöm a választ, kigondolom a Laraveres verziót (sose használtam
)
S egy kapcsolódó kérdés, akkor ha Laravelben csinálnám az user managementet, akkor ami jelenleg kész van sima PHP 8.1-el az oldalon (file feltöltés, galéria meg még egy két dolog) azokat is írjam át, vagy azt lehetne úgy hagyni ahogy van? Vagy arra írtad, hogy írjam nulláról? -
pmonitor
aktív tag
válasz
martonx
#17531
üzenetére
De ebben az esetben ugyebár egy fontos dolog hiányzik: mégpedig az input. Mert ugye ebben az esetben nem tartod nyilván, hogy miből mennyi van! Így nincs mit le ellenőrizni. Ez a legfontosabb, amit eddig írtam. Az már egy nem olyan fontos, de azért megemlítem, hogy ezt a döntést csak megerőszakolva lehet üzletinek nevezni.
-
pmonitor
aktív tag
válasz
martonx
#17520
üzenetére
>nem látod át az üzleti folyamatokat, döntéseket, és az ezeket támogató rendszerek működését, programozását.
Milyen üzleti folyamat, döntés az, amelyik azt mondja, hogy NE ellenőrizd le a user által megadott inputot? Akkor ne ellenőrizzétek le a nick-neveket, e-mail címeket stb... Ez ám a komoly üzleti folyamat!!!
-
pmonitor
aktív tag
válasz
martonx
#17505
üzenetére
>Miért lenne hiba, hogy valamit úgy lehet rendelni, hogy nincs készleten?
Az önmagában nem hiba akkor, ha ezt jelzik az ügyfél részére. De itt 11 nap múlva jött egy olyan e-mail, ami leírta, hogy "a termek nincs raktaron nem tudjuk szallitani Onnek.". Tehát nem csak hogy nincs raktáron, de még rendelni sem tudnak. Tehát korán sem arról van szó, hogy majd gyorsan beszerzik a nagyklerből.
-
JoinR
őstag
válasz
martonx
#17466
üzenetére
Há hogy kinél kellene a képnek tisztulnia, arról lehetne vitatkozni
bár én sem vagyok szakértő, csak pipeline-okat csináltam ML betanításhoz. Engem nem zavar, hogy valaki azt gondolja, hogy az AI/ML az ~statisztika, de hogy láthatóan a témában laikusoknak ezt miért fontos ekkora elhivatottsággal képviselni egy szakmai topikban, azt nem értem.Egyébként az orvosi diagnsztikában nagyon komoly eredményeket érnek el ezzel a módszerrel: https://www.altexsoft.com/blog/deep-learning-medical-diagnosis/
-
coco2
őstag
válasz
martonx
#17455
üzenetére
Régebben fpga-kban programozható vezetékeken xor kapukat használtak. A mai formájukban nem xor kapuk vannak, hanem Karnaugh-táblák után a "fordító" azt a bitmátrixot tölti memóriába. Logikai művelet helyett memória kiolvasás működik a logika mélyében. Gyanítom, hogy idővel azt nevezték át "neurális háló"-ra, és használják az alap gondolatot cpu-kon is (nagyon sokkal több memóriája tud lenni). Ha abban nem tévedek, az az egy technikai felismerés (nevezetesen, hogy gyorsabb ram-ot használni, mert meg lehet úszni a logikai kapuk zajos vezetékeit, meg cudar mennyiségű nem-előreszámítható áramkajálásukat) növelt annyit a sebességen, hogy azt elnevezték "korszakváltásnak". Annyi realitást meg lehet szavazni a "teljesen új szintre emelte"-hívőknek. A többi fogalmat még nem sikerült azonosítanom. Lehet, hogy mind csak "marketing".
-
emvy
félisten
válasz
martonx
#17455
üzenetére
Nem vagyok ML profi, de ez egyebkent sem jo reakcio, felesleges cinikuskodni.
Akkor konkretan: az LSTM elmeleti resze kb. 2000 korul lett ismert. Az ebbol kinovo terulet az egyik legnagyobb hatasu tudomanyos elorelepes az ML teruleten. Azt allitod, hogy ez vegulis csak sima statisztika, es a hardverek fejlodesevel ezek nelkul az elmeleti elorelepesek nelkul is kb. ugyanitt tartanank?
-
emvy
félisten
válasz
martonx
#17452
üzenetére
A mostani ML-szupersztarok 30 eve egy tokre lenezett terulettel foglalkoztak. A rendszamfelismero backprop halo meg a mostani DL rendszerek _teljesen_ mashogy neznek ki.
Szerintem erdemes lenne abbahagyni a magabiztos kinyilatkoztatasokat egy olyan teruletrol, amirol szerintem semmit nem tudsz.
-
emvy
félisten
válasz
martonx
#17450
üzenetére
> De ne tegyünk úgy ML, AI kapcsán mintha most valaki feltalálta volna a spanyol viaszt, és a semmiből idekerült volna valami tökéletesen új csoda
De, a helyzet az, hogy pl. a Hinton-fele kutatasok emeltek teljesen uj szintre ezt a tudomanyt es iparagat. Abszolut nem arrol van szo, hogy siman csak tobb hardverunk lett, es emiatt jobban mennek a dolgok.
> Igen, a számítógépeknek köszönhetően új szintre emelkedett.
Nem, a szamitogepeket azutan gyurtak ra a temara, miutan megtortentek az elmeleti elorelepesek.
-
JoinR
őstag
válasz
martonx
#17450
üzenetére
Mindenbe bele lehet magyarázni, hogy statisztikai, meg azt is, hogy matematikai vagy fizikai. Sőt, eredetileg minden csak filozófia...de attól még vannak idővel elszeparált tudományok, mint pl. a számítástechnika.
És bár a neurális háló évszázados ismeret, csak az elmúlt 1-2 évtizedben lett olyan a technológia, hogy ezt ki lehet használni és van értelme vele érdemben foglalkozni. -
coco2
őstag
válasz
martonx
#17361
üzenetére
Az indító post nem írta le egyértelműen, milyen mélységgel szeretne barkácsolni. Például előkerülhet-e C alapon írt bináris, amit cron-on futtatna egy webszerver mellett. Ha igen, a logikai szintű szolgáltatások már elégtelenek.
Azt sem írta, hogy elég lenne on spot alapon neki a külső szerver. A barkácsolósdi azt sejteti, kelleni fog neki a 7/24 rendelkezésre állás külső szerveren folyamatosan futtatni valamit.
A fentieket összeadva minimum folyamatos vps szolgáltatás kell neki. És pontosan arra kapott költséghatékony tippeket.
Aztán ha mindezekhez még hozzá jön a teljesítmény igény, következőre már dedikált szervereket fogunk neki linkelni, nem vps-t. Vps havi 5 eur, de ha sokkal több cpu / ram / előreszámítható io sebesség kell, afásan 45 eur körül kezdődnek a szerverek egészben.
A serverless nem az indítóban felsorolt igényekre van méretezve.
-
emvy
félisten
válasz
martonx
#17361
üzenetére
> Ha önképzés a cél, akkor a felhőben futtatási lehetőségekkel kellene ismerkedni, nem linux szervert konfigurálgatni.
Nem tudom, hogy ez miert van igy. Attol fugg, hogy miben szeretned kepezni magad. Lehet persze Heroku/Fly.io/Vercel/stb. iranyba is indulni, de olyat meg nem lattam, hogy artott volna, ha valaki takolt volna sajat szervert, vagy akar sajat maga rakott volna fel k8s-t.
A serverless meg total mas teszta, mas elonyokkel/hatranyokkal.> No persze felhőben (ok, számomra a felhő az AWS, Azure, Google Cloud) is lehet komplett szerver instance-t keríteni, ha valaki mindenáron ehhez ragaszkodik.
Lehet, de elonye nincs, csak hatranya (dragabb). Sima VM-ekert en tuti nem mennek a nagy felhokhoz, tenyleg remisztoen dragak tudnak lenni.
-
coco2
őstag
válasz
martonx
#17339
üzenetére
Elolvastam a blogot, a linket köszönöm, sajnos nem sokat segít jelen helyzetben.
Szóval az entity-kben nullable-re raktam mindent, a bemeneti parser már nem sír. Megoldás gyanánt a bemeneti mezőkben a körkörös hivatkozást előidéző mezőket simán nem rakom bele. A funkció lefut, adatbázisban van a végeredmény, és akkor jön a meglepetés. Ez a sor crash-el:
return Ok(result);
A "result"-ban egy DbSet<Entity> van. A legfelső szinten ott vannak a tábla saját adatai, de az Entity-nek része a másik táblára hivatkozás, amiből tovább van hivatkozás, és úgy tovább - na azt az ASP kimeneti json parsere nem tudja lekezelni.
Valami olyasmi kellene, hogy megmondhassam a DbSet<Entity>-nek, hogy recursive depth: 0. Ami osztály, azt hagyja null-on.
Átmenetileg megfixeltem: kézileg explicite null-ra állítom az összes referenciát a kimenetben. A result json-ban ott rondálkodik egy null. Így legalább nem száll el. De szépnek éppen nem szép. Egyáltalán nem kellene feltüntetni osztályokat a kimenetben.
Lévén az ASP web controllerének beépített kódjáról van szó, nem vagyok benne biztos, hogy abba én belenyúlhatok kézileg
Bármi bölcsesség?
-
coco2
őstag
válasz
martonx
#17339
üzenetére
A migrations azt csinálja, hogy ilyenkor gyárt egy harmadik táblát kapcsoló táblának, kb ilyesmit:
EgyikMasik {
public int EgyikId;
public int MasikId; }és abba a táblába vési fel a rekordokat, hogy milyen összerendelések léteznek. A migrations kimenetet megnéztem, a köztes tábla létezik. És sajnos nem hiszem, hogy a sok-sok tábla kapcsolatot el lehetne kerülni. Alapvető igény egy adatbázisban.
A linket köszönöm, elkezdem majd olvasgatni.
Addig annyit tettem, hogy átállítottam nullable-re az összes változót, így a parser nem siránkozik. A db felírásokat is megcsinálja, csak sajnos a rekordok felírása után elszáll körkörös hivatkozással. Pislogok, hogy mi van. Megcsinálta, ott vannak a rekordok, miért kell kilépés helyett crashelnie?
-
coco2
őstag
válasz
martonx
#17316
üzenetére
Az a tábla jelenleg 3 másik (a létszámuk később bővülni fog) tábla 1-1 sorához ad többlet információt azon a 3 dimenzión együttesen, és annak okán abban a táblában arra a 3 másik táblára foreign key van (a primary key / ID van bejegyezve). A szitu a sima indexekkel annyi, hogy azokat az EF automatán gyártotta, mert azt mondja, szerinte jók lesznek még valamire. Leszámítva a nagyon barkácsolást, fogalmam sincs, hogyan mondjam meg a migrations-nek, hogy ugyan ne gyártsa már le azokat az indexeket. Szóval ráhagytam. Ami a gyakorlatban tényleg jó lesz valamire, az a kompozit index, mert amikor abban a táblában keresni akarok, mind a 3 értéket tudni fogom. Apropó az az index igazából kompozit key, de nincs annotation support (én nem találtam) kompozit key-t felvenni a primary key mellé, míg index-re van annotation support - szóval index-ként lett kategorizálva. Hát, egy kicsit még szoknom kell a migrations rigolyáit. Lenne egy jó öreg lamp + phpmyadmin-om, nem lennének vele ilyen gondjaim, de most rám olvasták, hogy ezt kell szeretnem. Ennyi az összes nagy titok, nincs itt semmi misztérium, és végleg nem szakmai precizitáshoz van bármi köze a történetnek.
-
fatal`
titán
válasz
martonx
#17316
üzenetére
Szerintem a lekérdezés módjától (vagy módjaitól) és gyakoriságától függ, hogy hogyan érdemes indexelni. Ha ugyarra a 3 oszlopra szűrsz mindig, akkor kompozit, mert egy selecten belül, egy táblán csak egy indexet fog használni.
Nyílván a saját use caseben ő tudja kimérni (esetleg query plannerrel).
Mondjuk én nem nagyon értem, hogy miért kell az indexeket is EF-fel generálni/generáltatni. Lehet írni hozzá custom migrációt is és akkor létrehozod kézzel.
-
cucka
addikt
válasz
martonx
#17287
üzenetére
A 134 dependencia nem amiatt riasztó, hogy mennyi helyet foglal a diszken.
A probléma, hogy a 134 dependencia az vagy 100 vendort jelent, mindegyik hozza magával a saját kódolási stílusát, véleményét és bugjait.A tietek egy egyszerű eset, mert tudatosan nem húztok be mindenre egy libraryt. A vadonban az általános inkább az, hogy mindenki nyakló nélkül húzogatja be a dependenciákat, aztán a végeredmény az lesz, hogy az egész rendszert a szentlélek tartja össze, és ha a több száz dependencia közül 1-el bármilyen probléma van, akkor az egész kártyavár összeomlik.
És probléma lehet bőven. Senki se tudja megszámolni, a több száz libraryból hányan változtatgatják a globális típusok prototípusait. Senki sem tudja, ki mit hívogat node-gyp segítségével, vagy mit matat a filesystemben. Még abban sem lehetsz biztos, hogy a több száz dependenciád mind helyesen követi-e a szemantikus verziózást.
Emlékszünk a left-pad.js problémára. Vagy a múlt héten a hülyére, aki a node-ipc package-be malware-t rakott. -
coco2
őstag
válasz
martonx
#17254
üzenetére
Oké, értem, csak hát annyi eszem van, mint egy egysejtűnek, és nem sikerül rájönnöm a weben talált temérdek sok 1-1 kapcsolatot bemutató példa alapján, hogyan tudok 1-sok kapcsolatot lelistázni, amikor a másik tábla példányból nem csak 1-nek kell tartoznia az aktuálishoz, hanem egy egész tömbnyinek. Van esetleg kéznél egy olyan példa link is?
-
coco2
őstag
válasz
martonx
#17197
üzenetére
Én meg nem csak frontendről beszélek, hanem komplett alkalmazás szintű modulokról, amik valamilyen default design-al nagyon kevés sornyi programmal életre kelthető. Például vannak db táblák szerver oldalon. Azokból gyártani egy minor replika ábrázolást kliens oldalra, és a felhasználói akciókat automatán vezetni vissza és érvényesíteni szerver oldalon. Mindehhez valamilyen lap gyártó loop halom sok beépített aszinkron szerver kommunikációval elengedhetetlen. Persze összerakom kézileg mezítlábas környezetben bármilyen csillivillin, nem félek én attól se, csak hát az idő pénz.
-
-
coco2
őstag
válasz
martonx
#17189
üzenetére
Had találjam ki. Az extra libek ha támogatnak high-level komponenseket, mint pld egy adott sql táblára egyben edit form keresés / editálás built-in minden és hasonló finomságokat mindezt 1-2 programsorban leírhatóan, ahhoz szerver oldali modulok tartoznak, amik mind node alá vannak kitalálva. Szólj rám, ha elnéztem volna. A tanácsokért természetesen hálás vagyok.
-
coco2
őstag
válasz
martonx
#17184
üzenetére
Webassembly-t nem pont a sebesség miatt találták ki? És pont az a gyenge pontja
Ejnye, mi történt?Egyébként meg gyakorlatias segítség az lenne, ha valami szerver + kliens oldalas lib segítene olyat csinálni, hogy c# sdk-val definiálok logikai szintű komponensekből összeollózott weblapot, formokat, talán még webes fizetéshez is legyen valami támogatás - egyszóval alkalmazás fejesztéshez sebességet adna. Ha olyat adni nem tud, és ígyis-úgyis mezítlábasan végig kell vakerásznom az apró részleteken mindenestül, akkor minek csesszem tele a tech stack-et semmire kellő kukás vacakokkal?
-
coco2
őstag
válasz
martonx
#17160
üzenetére
Nem elég jó az sem. Bizony állapotgépet kell rakni a sorokra, és karakterenként értelmezni. Néha a \ az escapelés, és \" vagy \, csak sima karakter, nem vezérlő. Néha a duplázott karakter az escape és "" vagy ,, csak karakter. Ahol a , a cella elválasztó, ott "-tól "-ig az burkolva egy cella, ha akárhány , van benne. Például lehet egy sor ilyen:
cella1,"cella2,\"szöveg1\,szöveg2\"",cella3
Az csak 3 cella (egy belső felesleges, de nem szabálysértő escapeléssel).
C++-ban állapotflagekkel kell sorfolytonos karakter értelmezővel egyesével nyalogatni a karaktereket, és lesz vagy 4-500 sornyi a program, mire std vector lesz a szöveges sorból.
@zsolti_20
C# alatt van rá külön osztály Microsoft.VisualBasic.FileIO.TextFieldParser, de az csak dotnet alatt. -
zsolti_20
senior tag
-
pmonitor
aktív tag
válasz
martonx
#16983
üzenetére
Látom tényleg nincs időd Ilyenre, de fórumozásra, arra jut
Te csak használd nyugodtan a var-t majdnem mindenhol, mint rutinos .net programozó. 
De látom a mostani ON témához a "PH! megmondói" közül senki nem tud érdemben hozzászólni. Példakódot meg természetesen ne is várjon az illető, mert beletörne az igazi programozók ujja... -
-
pmonitor
aktív tag
válasz
martonx
#16885
üzenetére
Elég szomorú, hogy az évtizedek alatt senkinek sem jutott eszébe optimalizálni az alapvető függvényeket/metódusokat sem. Mert az alap típusok konvertálásai alapvetőek(legalábbis sztem.). Mondjuk itt valszeg. a sok függvényhívás is közrejátszik pl. a C "relative" lassúságában.
A másik meg az, hogy ez biztos, hogy egy user programozgatónak a dolga lenne? Ha van egy autóm, amiben nekem nem tetszik valami, akkor tervezzem át, küldjem be a gyártónak, és várjak, hogy elfogadják-e, mi?
-------------------------
Ettől függetlenül nem árt, ha valaki megpróbálja megérteni az általa használt függvények/metódusok működését/algoritmusát. Főleg, ha ugyanazt a funkciót gyorsabban is meg tudja valósítani.
-------------------------
Ha most lennék fiatal, és programozó szeretnék lenni, akkor én 2, esetleg 3 programnyelvet sajátítanék el nagyon. Az asm-ot, a C-t, esetleg a "mezei" C++-t(nem a VC++-t). Ezekkel mindent meg lehet csinálni, és eszközt adnak a kezembe az optimalizálásra is. -
pmonitor
aktív tag
válasz
martonx
#16854
üzenetére
>mert nem atoi-t optimalizálok hehehe).
Azért próbáld optimalizálni a C# Convert.Tostring(int value, int tobase) metódusát. Ha megszakadsz sem tudod jelentősen optimalizálni, mert a C#(és mögötte a robosztus .Net) nem ad megfelelő eszközt a kezedbe.
Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt. -
válasz
martonx
#16854
üzenetére
Hja, nehogy személyesre vedd, nem az volt a célom.
Csak megmutatni azt, hogy tényleg mekkora jelentősége van a tervezésnek. És itt rohadtul nem kódminőségről van szó, hanem architektúráról. És tényleg sokan vannak, akik nem láttak ekkora rendszereket, és könnyen mondanak triviálisnak tűnő, de használhatatlan megoldásokat. -
Ispy
nagyúr
válasz
martonx
#16836
üzenetére
a való életben SOHA nem ez az igazi probléma
Szerintem ezt már vagy 100x elmondtuk, egy mai modern pc-nél kliens oldalon tök mindegy, hogy 0.1 mp vagy 1 mp, ezért is felesleges agyonoptimalizáni bármit. Ha az ügyfél pattogósabb programot akar vegyen a gépbe több ramot/erősebb procit/ssd-t (ha nincs).
-
válasz
martonx
#16834
üzenetére
Egy végtelenül bonyolult banki ökoszisztémában sajnos ez nem ilyen egyszerű. Mert könnyen rá lehet mondani, hogy 90% mehet kessből, de egyrészt azonosítani kell ezen adatok körét, másrészt azzal is számolni, hogy ez a 90% 10 rendszerből jön össze, amiket fel kell térképezni, töltést kitalálni, embert keríteni hozzá. A végén pedig kijön, hogy mindez 3 évbe, és 1500 embernapba kerül (nyilván nem konkrétan ennyi, de elő szoktak jönni ilyen szituk). Szóval ez azért nem olyan, mint egy zöldmezős webapp, amivel a fejlesztők 90%-a szembesül életében.
Ugye ennek a szolgáltatásnak multifunkciósnak kell lennie, és illeszkednie a bank SL-ébe, hiszen más appok is akarják használni. Szóval nem lehet csak a mi appunkra kihegyezni, hiszen lehet, hogy másnak más adat "változatlan".
Most abba az irányba indulunk el alkalmazás oldalról, hogy szét fogjuk bontani a hívásokat (alapból paraméterezhető, de nekünk teljes adattartalom kell egyébként), kvázi megpróbáljuk többszálasítani a lekérdezést. Cachelés lesz alkalmazás backend oldalon, mert magát a szolgáltatást is többször hívjuk egy cikluson belül, az első hívás tartalmát bekesseljük, és csak akkor kérdezzük le újra, amikor tudjuk, hogy változhatott az adat.
Mint látszik, ez csupán tüneti kezelés, a forrás service ettől nem lesz gyorsabb, csak az ügyfél kevésbé szembesül a hátrányaival.
#16836martonx
Persze, ez annyira tipikus üzlet, mindenből friss adat kell, és ráadásul lassú se lehet
Nézd, az üzlet az ügyfél valid igényeire próbál referálni. Szerintem az teljesen jogos elvárás, hogy egy webes alkalmazásra ne kelljen perceket várni, és az ügyfél a valós szolgáltatásképét lássa. -
válasz
martonx
#16834
üzenetére
Lehet, hogy nem fog - jellemzően - gyakran változni, de pl kockázatkezelési szempontból nem előnyös, ha egy üzleti döntést nem aktuális adatok alapján számol a rendszer.
Peraze egy ilyen folyamat tipikusan nem kell kis válaszidővel rendelkezzen, szóval nem triviális megtervezni egy ilyen köztes réteget. -
fatal`
titán
válasz
martonx
#16573
üzenetére
Ja hát a microservice persze, hogy gyorsan buildel. Nyiss meg egy régi solution 150 projekttel aztán meglátjuk mennyire gyors.
Mondjuk általában a ram korlát és a rengeteg process a probléma, vélhetően ez a 22-es vs-sel megoldódik (még nem próbáltam). Meg aztán a R# is sokat lassít, bár azt nyilván nem használja mindenki.
-
lenkei83
tag
válasz
martonx
#16472
üzenetére
Ketten is írtátok az alkalmazás szervert, ezzel nem tudok vitatkozni, valóban ez lenne a normális megoldás. De nekem az Atlantis űrsikló helyett jó lesz egy Szputnyik2 is
. Más funkciója nem lenne az alkalmazás szervernek, így fölösleges lenne most időt fektetnem a programozásába.
SQL-job most is fut, ami ellenőrzni a folyamatos SQL kapcsolatot, de őszintén mondom, fogalmam sincs, user ellenőrzés szintjén, hogyan kellene ennek működnie.
Ami most hirtelen a fejemben van: indítok egy time tickert ami letárolja a pillanatnyi időt sql-ben és kódban is, és a következő tick-nél ha a két idő egyzik (nyilván előtte megint megpróbálja beírni a pillanatnyi időt, de nem tudja mert valamiért már nem fut a kód), akkor a user inactive. -
lenkei83
tag
válasz
martonx
#16466
üzenetére
"De malfunction esetén ez akár be is ragadhat, ha pl feladatkezelőn keresztül bezárom a progit." - ez nem így van.
Szerintem így van. Ha figyeltél, nálam még nincs session sem GUID sem semmi egyéb. Login-kor simán beírok True-t egy SQL UserActive mezőbe, ami a program normális bezárásakor False lesz. Ha kivágom feladatkezelőből, az UPDATE nem fog lefutni, vagy sem sem fog elhalni és látszóla aktív marad a felhasználó.
Igen, Using van beállítva adatbázishoz.
Írtam egy kódot ami működik, de szeretném tovább vinni olyan irányba, amit még nem csináltam. Nem tudom hogy jutottál el a rosszul megírt kódból az űrhajóig, de kíváncsi lennék. Minden rosszindulat nélkül. -
Ryan_Sanchez
tag
válasz
martonx
#16103
üzenetére
Nem tudok például egy mappa elérési útvonalat megadni, majd abban akár rekurzív bejárást végrehajtani, hogy a mappából, és azok alkönyvtáraiból kiszedjem az xy kiterjesztésű fájlokat. Ez lett volna az eredeti terv. Ha jól értem akkor egyenként lehetséges csak feltölteni a szükséges fájlokat.
-
pmonitor
aktív tag
válasz
martonx
#15975
üzenetére
Ha azt mondtam, hogy a win api-t a C/C++/Free pascal/Delphi beszéli folyamatosan, akkor erre meg azt mondom, hogy az office alkalmazásokat meg a VBA/Vb.Net beszéli folyamatosan(bár más nyelvben is meg lehet csinálni). Ha szeretnék nyitni 1 Excel munkafüzetet, aminek az első munkalapjának első cellájába akarom írni az "asdfgh" szöveget, akkor aszondom, hogy:
Dim exapp As Object = CreateObject("Excel.Application")
exapp.Visible = True
exapp.Workbooks.Open("d:\MunkaFüzet1.xlsm").WorkSheets(1).Range("A1") = "asdfgh"És ha a "d:\MunkaFüzet1.xlsm" file jelszóvédett, akkor be is kéri a jelszót megnyitáskor(mondjuk itt hibakezelés nincs, tehát ha rossz jelszót ad meg a user, akkor elszáll).
Egy ilyen sor kódtól:
exapp.Workbooks.Open("d:\MunkaFüzet1.xlsm").WorkSheets(1).Range("A1") = "asdfgh"
a C# befonná a szemöldökét![;]](//cdn.rios.hu/dl/s/v1.gif)
-
-
válasz
martonx
#15968
üzenetére
Ez mukodik oda-vissza minden erdemleges office verzioval? Amugy ezt nem ismertem, de ugy latom eleg szepen frissen van tartva, es a known issues is meglepoen rovid (es elegge edge-case mind), ugyhogy akkor visszavontam a fentit, ezek szerint elavult volt a tudasom a temaban.
-
pmonitor
aktív tag
válasz
martonx
#15935
üzenetére
Azért C#-ban nem olyan könnyű "office cuccokat töcögtetni.". Főleg ha verziófüggetlenül szeretnéd birizgálni. Mert ha felveszed a references közé, akkor az verziófüggő(csak arra a verzióra tudod használni, amit felvettél a references közé). Ha Office alkalmazásokat akar programnyelvben birizgálni, akkor én a Vb.Net-et ajánlanám Neki.
-
-
pmonitor
aktív tag
válasz
martonx
#15606
üzenetére
Ezt a C++ kódot szerettem volna elkészíteni C#-ban. Kezdődött azzal, hogy a "DRIVE_LAYOUT_INFORMATION_EX"-et nem vette be a gyomra(ezt a végén sikerült megoldanom). Folytatódott azzal, hogy a "FindFirstVolumeMountPoint/FindNextVolumeMountPoint" nem működött. Ez helyett a "GetVolumePathNamesForVolumeName"-t kellett használnom. Aztán mikor kész lettem, és kipróbáltam 1 olyan gépen, amiben linux meghajtó is van, azt nem listázta ki, míg C++-ban igen. Rákényszerültem a natív .dll használatára, hogy legyen 1 működőképes program. Amikor ki akartam próbálni C#-ban, hogy 1 használaton kívüli pendrive-ról 1 szektort beolvasok, majd változatlanul visszaírom, akkor nem adott hibát, de tönkretette a pendrive-ot úgy, hogy újra kellett formáznom. Ezt is bele kellett tennem a natív .dll-be. Így már tökéletesen működött a pendrive írása is.
Egyik esetben sem tudtam elkerülni a natív .dll használatát, hogy hibátlanul működő binárist kapjak. Régebben írtam, hogy a C# csak játékszer a C/C++-hoz képest. Hát ha ez szó szerint nem is igaz, de azért nem áll messze a valóságtól. Egyetlen nagy előnye van: hogy gyors vele a fejlesztés. Semmi más. Egyszer még a prog.hu-n a társalgóban az egyik nick azt kérdezte, hogy miért ilyen lassú a .Net. Azt válaszoltam neki, hogy "a kényelem ára". Azóta sem változott a véleményem.
-
-
válasz
martonx
#15623
üzenetére
És jönne az a kérdés, hogy fejlesztő csapat az elején miért nem 100+-os felhasználói bázisra írta meg? Mert valószínűleg volt egy árajánlat
- egy 20+ felhasználói csoportra egyszerű kódbázissal, ami X idő alatt lékszül Y forintból és N darab gép kell alá;
- és egy 100+ useres robosztusabb, elosztott változat, ami 1.5X idő alatt készül el, 2Y pénzbe kerül és N+5 darab gép kell alá.
Ebből nagy valószínűséggel az ügyfél az olcsóbb és gyorsabban elkészülő és könnyebben üzemeltethető megoldást választja - amennyiben az számára elegendő - az esetek 99.99%-ban. -
pmonitor
aktív tag
válasz
martonx
#15619
üzenetére
Ismerem a C# működését, hiszen abban kódolok legtöbbet. C-t meg általában akkor, ha valamihez natív dll kell, vagy ha kedvem tartja. Asm-ben meg még ritkábban. Továbbá nem tudnak eladni VB6/VBA/VB.NET-ben, javascriptben php-ben, pascalban sem, bár ezek azért már akadozva mennek.
Hogy sok aspektusa van egy nyelv megítélésének, azt elhiszem. Sajnos a programozók(vagy akik annak állítják be magukat. mert a tény az, hogy 2 nick bizonyitotta be nekem, hogy tud programozni) ezek közül soknak tényleg lényegtelen szempont. Csak a gond ott van, hogy én nem vagyok programozó(és nem is mondom magam annak). Akkor vajon miért is kell a hardvert fejleszteni, ha a sebesség lényegtelen? Valaki írta, hogy a user 2 mp-et vár a gépre vagy 10-et, az nem igazán szempont. Ezzel sem igazán tudok egyetérteni annak ellenére, hogy tudom, hogy nem leszek népszerű. Sztem egy programnak 2 jellemzője van(legalábbis ha pénzt kérnek érte): az egyik, hogy jól működjön. A másik, hogy ezt minél gyorsabban tegye. Amikor a bankban az ügyintéző azt mondja, hogy a gépre várunk, majd kb. fél perc múlva lépünk tovább(addig csak nézzük egymást), annak nem igazán szoktam örülni. De akkor kérdezek egyet. Ha nem igazán szempont a sebesség, akkor miért is az nálatok a mondás, "hogy 5 másodperc alatt kell kiszolgálni egy HTTP requestet" Akkor miért kell egyáltalán bármilyen időkorlátot is felállítani, ha a sebesség nem igazán szempont? Az meg egy másik szempont, hogy aki az 5 sec-t meghatározta, ő sem volt a helyzet magaslatán, ha könnyedén a törtrésze alatt meg lehetett oldani(1 szakinak azért pontosabban be kellene lőnie a teljesíthető időt). Soha nem tudom megérteni a programozókat. Én nem közétek tartozom. Főleg úgy, hogy tudom, hogy nagyon sok mindent gyorsabban meg lehetne oldani. De természetesen itt a fizetős alkalmazásokra gondolok. Bár a free-nek is illene ezeket betartani. Pl. most én tudom, hogy lehet gyorsítani a programom kódján. Ezt meg is teszem majd attól függetlenül, hogy free a programom. Hosszú időn át nem tudom elképzelni, hogy a lassabb változat lenne fent annak tudatában, hogy van gyorsabb kód is. Amikor lesz időm, akkor módosítom. -
pmonitor
aktív tag
válasz
martonx
#15606
üzenetére
Nagyrészt igazakat írsz. De pl. 1 C csapat sem biztos, hogy olyan lassú, mint ahogy azt írod. Ha én csinálnám C-ben, akkor biztos.
De azt is figyelembe kell venni, hogy a C-seknek is van egy csomó előre megírt kódjuk. Hogy mást ne mondjak, itt van kovisoft esete. Ő sem most írta meg a kódját, hanem a tarsolyában volt. Tehát a C-sek sem nulláról írnának meg minden kódot. Szóval lehet, hogy mégsem lenne annyival hosszabb idő a fejlesztés. És szerintetek a webalkalmazás miben íródott/íródik? Ha jól tudom C++-ban. De javítsatok ki, ha tévedek. De mindenképp kap legalább egy réteget fölé. Sztem ez lassítja le ezeket.
Azért egy linux/windows váltás, vagy 32/64 bites áttérés bármelyik nyelvet "megvisel"(pl. a C# mehet a levesbe linux esetén) Bár ha jól tudom, arra is van C#, de az aztán korántsem olyan elterjedt. -
Ispy
nagyúr
válasz
martonx
#15606
üzenetére
Persze lehet írni fosch kódokat, amik nagyon szarok, de azért manapság már inkább a hw az ami a szűk keresztmetszet, de olcsóbb ízomból áttolni a kódokat a vason, mint c-ben nekiállni fejleszteni.
A c ha jól tudom eléggé hw közeli nyelv, szóval szerintem inkább ott használják, ahol az oprendszer alatt kell dolgozni, a többiek meg bedurrantják a keretrendszert, azt majd a többit intézi az operációs rendszer, ami így nyilván lassabb lesz.
Igaz pont most van egy régi ügyfelünk, havi milliárdos bevétellel, aztán amikor a kimutatás 30 percig futott felvetettem, hogy milenne, ha 2021-ben a szerverükön (amin fut a raktártól kezdve minden szar) kicserélnék a HDD-t SSD-re, meg nem futtnának backupk a háttérben meg mittudomén mik, hát nem mert drága. Jó, hát akkor 30 perc.
-
Drizzt
nagyúr
válasz
martonx
#15466
üzenetére
Hat ugy kezdted a hozzaszolasod, hogy oskovulet. Nem igy van. Regota letezik, de a fejlodese kimondottan dinamikus. Teny, hogy nem volt ez mindig igy. De peldaul en is nagyon meglepodtem, amikor 5 eve eloszor javaztam, olyan 8 ev kihagyas utan. Mert nekem is hasonlo emlekeim voltak, mint amiket itt felhozol. Aztan amikor ujra javaznom kellett, ott jott a nagy meglepi, hogy ez bizony sok szempontbol kifejezetten jo es elvezetes lett a korabbi java developer elmenyhez kepest. En a c#-pal nem mernem osszehasonlitani, de a tobbi emlitett nyelvvel sem. Szimplan mert azokkal nincsen semmifele on-hands tapasztalatom az elmult 5 evbol. Oke, Js-ben meg volt aktiv programozoi elmenyem, ezerszer kellemetlenebb elmeny js-ben programozni, mint Javaban. Legalabbis nekem. A Java elmenyhez sokat hozzaad szerintem amugy az IntelliJ is. Teljesen osszehasonlithatatlan a regi Eclipse szivassal(, lehet persze, hogy az se olyan mar mint reg).
-
Drizzt
nagyúr
válasz
martonx
#15450
üzenetére
A Javarol amiota dolgozom, allandoan ezek az allitasok kerulnek megfogalmazasra. Ettol fuggetlenul amik meg igazak az elmult 13 evben a Java kapcsan:
- Mindig temettek, megis el es virul allando jelleggel.
- Rendkivul sokat fejlodik, nagyon sok dolgot atemel a konkurrenseitol, de ugy, hogy a megoldas nem tunik nyelvidegennek.
- Gyakorlatilag mindenre van library, tobb is. Nemelyik pont a nyelv hatranyainak kikuszobolesere epul, pl. Lombok.
- Nagyon fasza frameworkok is vannak hozza, eleg a Spring/Spring Bootot felhozni.
- Akarmi volt eppen a legmenobb nyelv, a Javaval elerheto fizetes mindig az elsok kozott volt. Legalabbis itthon ezt tapasztaltam.Egyebkent Java fejlesztokent csak olyan 5 eve dolgozok aktivan. En szeretek Javaban programozni, persze van 1-2 dolog, amit mas nyelven konnyebb, gyorsabb leirni, de nagy hianyerzetem nincs. Ami tenyleg zavaro, ugyis idovel kikupaljak ujabb Java verziokban.
-
Tigerclaw
nagyúr
válasz
martonx
#15434
üzenetére
Ezekkel mar talalkoztam. Mivel az egesz projekt meg csak gyerekcipoben jar es lehet hogy nem is lesz jovoje, nem foglalkozok azzal hogy kerelmet irjak nekik, hogy noveljek meg a limitet. Csatoljam melle a pre-pre-pre-pre-alpha-just-proof of concept snippet teszt appomat, atvizsgalasra?
Az viszont erdekelne, hogy uzleti alapon mennyibe kerul egy lekerdezes. Nem akarok en ingyen lekerdezni adattokat, csak irjak le valahova hogy mi a tarifaja.
Azt amugy nem ertem, hogy ket kvazi ugyanannyi eroforrast lekoto lekerdezesnel miert kerul 1 egysegbe az egyik, 100-ba a masik.
Most ideiglenesen inditottam egy masik projektet, hogy ma meg tudjak dolgozni, holnap meg a masik quotaja is resetelodik, de inkabb valtok nem csak a youtube apirol, de a youtube-rol is, ami amugy is csak tesztnek lett szanva.
Van ahol azt olvastam, hogy valaki ugy oldotta meg a problemajat, hogy inditott egy halom projektet a youtube dev oldalan es ha visszadobta a lekerdezest a napi limitre hivatkozva, az algoritmus kulcsot valtott es folytatta. Talan 15 projekt a limit, igy 15x annyi lekerdezest tud naponta futtatni. Most kvazi en is ezt hasznalom ki, csak manualis modon. Ebben a fazisban nincs szuksegem sokkal tobb lekerdezesre es at is terveztem a sajat kodot, igy kevesebb lekerdezes is eleg. Kozben meg keresek alternativ mediakiszolgalot.
)
Kérdés: "előző" - mi történt a céggel / veled / az eur milliókkal?
bár én sem vagyok szakértő, csak pipeline-okat csináltam ML betanításhoz. Engem nem zavar, hogy valaki azt gondolja, hogy az AI/ML az ~statisztika, de hogy láthatóan a témában laikusoknak ezt miért fontos ekkora elhivatottsággal képviselni egy szakmai topikban, azt nem értem.
Ejnye, mi történt?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Szerintem épp ellenkezőleg, rendszeresen új vallás születik szinte minden témában.
Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Autós topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Mibe tegyem a megtakarításaimat?
- Xbox Series X|S
- Kerékpárosok, bringások ide!
- Apple Watch Sport - ez is csak egy okosóra
- Új szintre emeli a csalók elleni védelmet a Battlefield 6
- DOOM - The Dark Ages
- VR topik (Oculus Rift, stb.)
- PlayStation 4
- További aktív témák...
- Azonnali készpénzes Sony Playstation 5 lemezes és digitális felvásárlás személyesen/csomagküldéssel
- Lenovo ThinkPad L15 Gen 2 - 15.6" FullHD IPS - i5-1135G7 - 8GB - 256GB SSD - Win11 - MAGYAR
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W10 I Cam I Gari!
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- Gamer PC- Számítógép! Csere-Beszámítás! R9 3900X / RX 6700XT 12GB / 32GB DDR4 / 1TB SSD
Állásajánlatok
Cég: FOTC
Város: Budapest