-
IT café
Új hozzászólás Aktív témák
-
martonx
veterán
Hidd el, hogy amit te látsz, az nem a normális webes javascript fejlesztés.
Tudom hihetetlen lesz, de egy immár több, mint egy éves, egészen komoly nagy több emberes frontendes projektnek nálunk pl. így néznek ki a node-modules függőségei (Vuejs 3.2.X miatt még mindig sok benne a beta, alpha csomag, de ezek stabilak, csak épp nem rég lettek a 2.X-ről forkolva):"dependencies": {
"vue": "3.2.31",
"vue-grid-responsive": "next",
"vue-i18n": "9.2.0-beta.28",
"vue-meta": "3.0.0-alpha.10",
"vue-router": "4.0.14",
"vue-tiny-validate": "0.2.4",
"vue-good-table-next": "^0.1.0"
},
"devDependencies": {
"@intlify/vite-plugin-vue-i18n": "3.3.1",
"@vitejs/plugin-vue": "2.2.4",
"eslint": "8.11.0",
"eslint-config-prettier": "8.5.0",
"eslint-plugin-prettier": "4.0.0",
"sass": "1.49.9",
"vite": "2.8.6"
}Én kérek elnézést!
-
martonx
veterán
Azta 100mb méret a node_modules, és maguk alá 134 alfüggőséget húznak be? Úúúú de dúrva
Az app egyébként valóban nem a legkomplexebb, viszont nem is egyszerű, még ha a dependency-k alapján annak is tűnhet. Csak mi nem rohanunk mindenért külön lib-et behúzni, hanem igyekszünk sok mindent házon belül tartani, megoldani. Lehet, hogy ezzel van amikor plusz pár nap munkát okozunk magunknak, viszont a végeredmény sokkal jobban menedzselhető lesz, és a kismillió függőségnek se vagyunk úgy kitéve, amivel meg végeredményben munkát tudunk spórolni, és a végeredményünk is személyre szabottabb, kisebb bundle méretű tud lenni.Én kérek elnézést!
-
martonx
veterán
Amit írsz node.js-hez (de hehe Python-t, sőt PHP-t is láttam már emiatt kártyavárként dőlni) teljesen igaz. Webes frontend dolgokra mérsékelten igaz. Egyébként meg, ahogy mondtam nem kell, agyatlanul mindenre libeket behuzigálni, és akkor elég könnyen lehet minimalizálni ezt a problémát.
Én kérek elnézést!
-
martonx
veterán
Én a helyedben a hivatalos doksival kezdeném: Indexes - EF Core | Microsoft Docs
Szívesen!Én kérek elnézést!
-
martonx
veterán
"A jelek szerint indexeket virtuálisan leírni, és később azokra hivatkozni az EF még nem tud" -
azóta is ezen gondolkozok: tényleg számít ez? Van 3 meződ, és mindegyiken van 1-1 index. Vagy van ugyanez a 3 meződ, és 1 komplex index van a három felett? Komolyan kérdezem, benchmarkot is megnéznék, hogy a valóságban mi a különbség a két megoldás között.
Mert én azt tippelem, hogy szinte semmi, bár lehet, hogy sok milliárd adatsornál már a szinte semmikre is van értelme optimalizálni, bár ott meg már úgysem ORM-ezik senki.Én kérek elnézést!
-
martonx
veterán
Én már rég nem lepődök meg semmin, ilyet meg se akarok tippelni. Az biztos, hogy az egy szál kompozit index folyton buzerálva lesz, bármelyik oszlopban is változzon bármi, azaz íráskor vélhetően az 1 nagy kompozit index rosszabb lesz (aztán lehet, hogy ez is hibahatáron belül mérhetetlen eltérés csak). A külön külön index-ek meg lehet, hogy olvasáskor teljesítenek valamivel rosszabbul, de erre se vennék mérget. Ezért is kérdeztem a kollégát, hogy ha már ennyire szenved, hogy mindenáron egy nagy kompozit indexet akar, valóban kimérte, és drasztikusan jobb teljesítményt ad a kompozit index?
Szóval belőlem pusztán a szakmai kíváncsiság beszélt, mivel ott van a DB-je, remélhetőleg több millió adatsorokkal, könnyedén ki tudja mérni a különbséget a kétféle indexelési stratégia között.Én kérek elnézést!
-
martonx
veterán
Öööö ez a két tábla közötti kapcsolat így biztos jó???
Jól látod, a hibaüzenetet azért kapod, mert ezzel az elrontott tábla kapcsolattal seperc alatt körkörös referenciát érsz el
Feltételezem latest .Net 6-ot használsz, feltételezem default System.Text.Json-nal szerializálsz. Ez esetben itt van némi olvasnivaló, benne talán megoldással is a problémádra: System.Text.Json features in .NET 6 (okyrylchuk.dev)
Én kérek elnézést!
-
martonx
veterán
Ilyen filozófiai mélységekbe ne menjünk bele, hogy mi számít felhőnek, és mi nem.
Arra gondolok, hogy ezekhez nem igazán kell szerver. Garázs cégeknél szerver bérlés meg pláne zsákutca. Ha önképzés a cél, akkor a felhőben futtatási lehetőségekkel kellene ismerkedni, nem linux szervert konfigurálgatni. 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.Én kérek elnézést!
-
martonx
veterán
válasz Ryan_Sanchez #17386 üzenetére
Kicsit konkrétabban? Jsonról hallottál-e? Js oldalon mit csinálsz?
Én kérek elnézést!
-
martonx
veterán
"A kérdés. Fenti példában az EF képes lesz memóriába rántani azonnal az egész DB-t csak azért, hogy a referenciákat végig ki tudja tölteni? Vagy van bármi okosság kitalálva adatmélységet szabályozni?"
Képes lesz, és igen szabályozni is tudod. Lazy load a kulcsszó.
Én kérek elnézést!
-
martonx
veterán
Kismillió bevitt adat alapján jóslást jelent az AI, ha nagyon le akarjuk egyszerűsíteni. Mondok egy szuper leegyszerűsített példát. Rúzsokat árulsz, egy éve rögzíted a boltba betérők nemét, és hogy vásárolt-e.
Ezeket az adatokat betolod valami felhős ML ízébe (nálam műveltebbek ezt hívják betanításnak). Ez alapján pedig, amikor legközelebb bejön valaki a boltba az AI meg fogja tudni egész pontosan mondani, hogy vásárolni fog-e.
Ha ez alapján úgy érzed, hogy ilyen tudomány régen is volt, csak akkor ezt másképp hívták, akkor nem állsz távol a valóságtól.
Azért a fenti Móricka példa ne vezessen félre, minél több adatot vesz az AI figyelembe a jósláshoz, annál izgibb tud lenni a dolog.Én kérek elnézést!
-
-
martonx
veterán
Az általánosítás valahol nem statisztikai fogalom? :D
Értem én, hogy volt fejlődés a statisztikában (manapság trendibb data-sciencenek hívni) az elmúlt 50 évben, és ez pont a számítógépeknek volt köszönhető. 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. Igen, a számítógépeknek köszönhetően új szintre emelkedett.Én kérek elnézést!
-
martonx
veterán
Azt állítom, hogy ha a sok maszlagot (amiben természetesen rohadt sok fejlődés volt mind hardveres, mind elméleti vonalon) félretesszük, és eléggé felülről nézzük, mert egy laikusnak kell elmagyarázni, hogy mi az az AI és ML, akkor a statisztikával nem lövünk mellé. Végtelenül leegyszerűsítve a koncepciót, beküldünk rohadt sok (féle) adatot, és ezek alapján kapunk egy valószínűséget (ami bármi lehet, akár egy kép is, egy érzelem, bármi, amit az AI a legvalószínűbbnek tart).
Én kérek elnézést!
-
martonx
veterán
Pontosan erre írtam, hogy matematikusok csinálják a hálókat, és mindegyik ilyen kollégának a statisztika a szakterülete, doktorival, mindennel Egyikük sem programozó, csak szín tisztán matematikus, akik kenik vágják a statisztikai számításokat.
Remélem kezd letisztulni a képÉn kérek elnézést!
-
martonx
veterán
Mi az AI-t konkrétan videókon látható arcok érzelemfelismerésére használtuk. Jelenleg pedig kódelemzésre. A lehetőségek végtelenek, csak ügyesen (erőforrásokat nem kímélve, ebbe beleértve a neurális hálót megálmodó matematikusokat is, és a végtelen sok betanítást) kell a neurális hálót megálmodni, betanítani. Előző cégemnél éveket és EUR milliókat öltek ebbe.
Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #17503 üzenetére
Miért lenne hiba, hogy valamit úgy lehet rendelni, hogy nincs készleten? Tudatos üzleti döntés, hogy engedik rendelni, és majd beszerezik gyorsan a nagykerből. Rengeteg cég nem tart nagy készletet. Itt egyetlen egy valaki hibázott: az adminisztrátor.
Én kérek elnézést!
-
-
martonx
veterán
Tudtok-e olyan API-ról, ahonnan lekérhetőek adott évre vonatkozó ünnep, munkaszüneti napok? Első körben Magyarország lenne a lényeg.
[ Szerkesztve ]
Én kérek elnézést!
-
martonx
veterán
válasz dabadab #17552 üzenetére
Egy ilyet találam közben: Public Holiday API Documentation (theapiguy) | RapidAPI
Havi száz hívásig ingyenes.
Google Calendar is jó ötlet, csak hirtelen nem tudom, azt hogy lehetne C#-ba legkönnyebben beemelni, míg egy json-t visszaadó API result beimportálása csukló mozdulattal meg is van.Én kérek elnézést!
-
martonx
veterán
válasz racskobalazs #17583 üzenetére
Keretrendszerrel írd újra nulláról. Ha php akkor Laravel, Yii meg nem tudom még mik a menők manapság. Nyilván bármilyen nyelvet használhatsz. Személy szerint a php-t kicsit butácska script nyelvnek tartom, de az utóbbi időben sokat fejlődött, és a célodnak simán megfelel.
Én kérek elnézést!
-
martonx
veterán
válasz racskobalazs #17585 üzenetére
Írd nulláról, és meglátod, hogy jéé Laravelben lesz eleve user menedzsment (vagy legalábbis tippre viszonylag könnyen hozzá adható, bekonfigurálható).
A meglévő kódrészeket meg ha minden jól megy jó részt fel fogod tudni használni Laravelben is.Én kérek elnézést!
-
martonx
veterán
válasz racskobalazs #17587 üzenetére
Örülök, hogy sikerült téged a helyes irányba állítani :)
Én kérek elnézést!
-
martonx
veterán
Ráadásul ahelyett, hogy igazi programozási problémákkal foglalkoztok, foglalkozhatnátok 2D vágással (azóta se vettem a fáradtságot, hogy utánanézzek mi is ez), és itoa optimalizálással, mint az igazi nem is programozók!
Sok kis csicska programozónak hazudott nick, most mit csináltok, hogy nincs, aki megmutassa, hogy mi is az igazi programozás?
Rögtön kétségbe estetek, mi?Én kérek elnézést!
-
martonx
veterán
A csapatom az én vezetésemmel per pillanat Írországba készít egy új szerencsejáték rendszert (hja, ahol olyan liberalizmus van, hogy gyakorlatilag bárki bármikor beléphet a szerencsejáték piacra, ha van egy ötlete, és sok-sok pénze a megvalósításhoz), de én se vagyok igazi programozó, mert nem atoi-t optimalizálok.
Én kérek elnézést!
-
martonx
veterán
válasz gordonfreemN #17661 üzenetére
Én valami ilyet próbálnék meg használni: GitHub - UglyToad/PdfPig: Read and extract text and other content from PDFs in C# (port of PDFBox)
Nyelvet nem írtál, de gondolom kiindulásnak egy ilyen PDF feldolgozó is jó ötlet lehet, biztos, hogy bármilyen nyelvhez találsz hasonlót. Más kérdés, hogy szvsz még ezzel is elég izgi lehet egy pdf-ben lévő táblázatból kimazsolázni az adatot.
Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #17778 üzenetére
File művelet momentán os szinten korlátos Windows-on (gyanítom más os-en is). Ezen fog segíteni pl. Direct Storage windows vonalon.
A Google keresés pedig nem a te géped, vagy a Google optimalizálatlansága miatt lassú, hanem az irdatlan adatmennyiség miatt.Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #17803 üzenetére
Jaaa, hogy a Google-t pozitív példának írtad? Azért a Google keresés sebességét hasonlítani egy garázs szerveren futó SQL-éhez, szerintem nem korrekt. Ennyi erővel egy vadász repülőt is hasonlíthatsz egy normál autóhoz...
Emellett annyiban igazad van, hogy a garázs SQL-re olyan programozó dolgozik, aki egy év alatt nem keres annyit, mint a Google-nél dolgozó egy év alatt. Google-nél ilyenből van több ezer, a garázs SQL-en meg Pista bácsi egymaga bohóckodik.
Szóval igen, nem vagyunk egyformák, nem egyformák a képességeink.
Rengeteget állás interjúztatok, és nagyon gyakran ledöbbenek, hogy milyen gyenge programozók is vannak (többnyire állami szférából érkezettek a különösen fájdalmasak).Én kérek elnézést!
-
martonx
veterán
válasz pmonitor #17866 üzenetére
Közszférában válogatott debilek dolgoznak, ez ismét megerősítést nyert. Tényleg közben eszembe jutott, hogy tudok neked kódot mutatni.
https://www.nuget.org/packages/BarionClient2
Az első clientben még csak közreműködő voltam. Viszont az elhagyatott lett, valakinek tovább kellett vinnie, így lett belőle 2-es.Én kérek elnézést!
-
martonx
veterán
válasz FeniX- #17889 üzenetére
Ez szimpla ügyfélkezelési probléma, nincs köze ahhoz, hogy az ügyfél magyar-e vagy külföldi.
Az ismerősöd nem tud bánni az ügyfelekkel és/vagy annyira rá van szorulva a pénzre, hogy rögtön ugrik mindenkinek mindenre, ezzel elkapatva az ügyfeleit.
Le kell szarni, hogy mit csinál a megrendelő dacára a szerződésnek, megegyezésnek, hiszen azért van szerződés, megegyezés, mert az a programozót is védi, nem csak a megrendelőt.
Ha le van írva, hogy milyen rendelkezésre állással dolgozik valaki és milyen módon fogadja el a support ügyeket, akkor ez van.
Persze ettől még lehet próbálkozni éjszakai telefonhívásokkal, meg mindenféle fenyegetőzésekkel, de a szerződés/megegyezés kimondja, amit kimond, ahhoz mindkét félnek tartania kell magát.No persze a dolognak lehet olyan olvasata is, hogy ismerősöd annyira szarul dolgozik, és annyira ótvar hibák jönnek elő a kódban, ami a megrendelő részéről elviselhetetlen, és mondjuk egy péntek délután felfedezett (netán előtte 10 percel kiélesített) hiba annyira durva, hogy nem várhat a hétfői javításig, mert addig X milliós bevételtől esik el a megrendelő a programozó hibájából.
Ha rendre ilyenek miatt jönnek a soron kívüli hívások, akkor meg azt tanácsolom az ismerősödnek, hogy ne erőltesse, ami nem megy, ne legyen programozó, menjen el inkább asztalosnak.Én kérek elnézést!
-
martonx
veterán
válasz gygabor88 #17900 üzenetére
Engedjük már el ezt a magyar ügyfél szar dolgot. Nagyobb cégek azért nem dolgoznak magyar piacra, mert a magyar ügyféllel is ugyanannyi gond és baj van, mint egy nyugatival, csak éppen töredék pénze van cserébe. Ergo anyagi okokból fordulnak nyugati ügyfelek felé, nem pedig azért, mert átlag magyar ügyfél hülyébb lenne az átlag nyugati ügyfélnél.
Főállásomban egyszerre dolgozok magyar ügyféllel is, és egy másik projekten külföldi ügyféllel is. Egyik sem problémásabb a másiknál. Csak míg a magyarnak meg kell részletesen magyarázni (jelzem ezzel önmagában nincs baj, hogy megkérdezi, és el is fogadja a választ), hogy miért kerül havi 120-130 EUR nettóba a hostingja, addig a külföldi meg se kérdezi, hogy miért számlázunk ki havi 2000 EUR-t hostingra (miközben alig van terhelés a szerveren, és valójában megoldjuk kevesebből, mint a magyar ügyfél hostingját...). Cserébe a nyugati ügyfélnek kismillió egyéb nyűgje van, mégis mindenki boldog, hogy de jó ügyfél.
Ezzel csak szemléltetni akartam, hogy miért szeretnek a cégek inkább nyugati ügyfélnek dolgozni.
Mellékállásban egyéni vállalkozóként két magyar ügyfélnek dolgozok (az egyik bérel tőlem egy webshop rendszert, a másik pedig az egyik állami múzeum). Semmi baj nincs velük, tök korrekt ügyfelek. Jelzem idáig eljutni azért nem volt könnyű, és tényleg ki kell szórni a "minden kéne tegnapra, de miért nincs ingyen?" megkereséseket.Én kérek elnézést!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy S24 - nos, Exynos
- Fejhallgató erősítő és DAC topik
- Politika
- Steam topic
- Vallás
- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- Amazon Fire TV stick/box
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Dark Souls sorozat
- További aktív témák...
- Több db HP Thunderbolt dock 230W G2 230W -os töltővel MONITORCENTER
- Philips Evnia 42M2N8900 Gamer Oled Monitor!42"/4k/138hz/0,1ms/Freesync-Gsync/HDMI 2.1/TypeC/Ambiglow
- -56% HP EliteBook 840 G8:i7 1165G7,16GB RAM,512GB NMVe SSD,Iris Xe,IR kam.+ujj.olv.,vil.MAGYAR bill.
- Monitortató plexi konzol több elérhető készletről MONITORCENTER
- -50% HP EliteBook 840 G8: i7 1165G7,32GB RAM,1TB NMVe SSD,Iris Xe,IR kam.+ujj.olv.,vil.MAGYAR bill.
- kowa cctv lens lmvz4411 1/1.8" 4.4-11mm/F1.6 Manual C-Mount, Edmund Optics 4mm/F1.8 33300 optika
- REL AirShip Wireless Vezeték nélküli adóvevő REL S szériás Subokhoz, új
- Amazon Fire TV Stick 4K Max (3rd gen)
- Audioquest és Nordost hangszóró kábelek,RCA kábel, Nakamichi banándugó
- IPHONE TELEFONT, KERESEK,VÁSÁROLOK! TÖBB INFÓ A LEIRÁSBAN!