- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Klaus Duran: Youtube AI szinkron
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- eBay-es kütyük kis pénzért
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
pmonitor
#16942
üzenetére
"Vagy hogy hogy nem tudja 'kend ezt megcsinálni?" - tekintve az általam linkelt kiindulási alapot, nem a tudással van a bajom, hanem az idővel
Te meg látványosan unatkozni látszol, gondoltam feldobok egy feladatot, amivel végre igazán hasznossá teheted a szabadidődet, és végre olyat programozhatsz, amit nem megmosolyognak a többiek, hanem elismerően csettintenek. Mondjuk nem lep meg, hogy inkább passzolod, jogos, csináld meg inkább még négyszer az itoa-t. -
martonx
veterán
válasz
pmonitor
#16939
üzenetére
Ha ennyire ráérsz, és szeretnél egy igazi való világbeli problémában segíteni, akkor írj egy managed (csak C#-os, azon belül is .Net Standard 2.1-es) HTML to Image konvertert (és nyilván annál jobb, minél optimalizáltabb).
Ez jó kiindulási alap: ArthurHub/HTML-Renderer: Cross framework (WinForms/WPF/PDF/Metro/Mono/etc.), Multipurpose (UI Controls / Image generation / PDF generation / etc.), 100% managed (C#), High performance HTML Rendering library. (github.com)
Végre valami hasznosat programozhatsz!
Garantálom, hogy nem csak én, de több ezer másik C# fejlesztő is használni fogja, amit csinálsz, és nagyon hálásak leszünk érte!
-
-
martonx
veterán
válasz
pmonitor
#16886
üzenetére
"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?"
Ez a példa ott megy borzasztóan félre, hogy egy autónál még a garanciát is bukod, ha elkezded buherálni. Ellenben az Open source programnyelvek azért open source-ok, hogy BÁRKI jobbá tehesse, azaz ezeknél szinte elvárás, hogy ha valamit jobban tudsz, akkor már küldöd is a PR-t github-ra. Minden más csak okoskodás.
-
martonx
veterán
válasz
Vision
#16855
üzenetére
Előző, nem banki munkahelyemen, meg rendszeresek voltak a több milliárd soros DB táblák. Ott is észnél kellett lenni, minden egyes SQL lekérdezésnél, és nyilván egy 2 TB-os DB táblát cachelni se lehet
vagy legalábbis észnél kell lenni, hogy mit, mikor, milyen aggregáltsági szinten cachel az ember.
Azaz amikor cachelésről beszélünk, ne arra gondolj, hogy oké lerántom a táblát memóriába, és probléma megoldva. Ennél a valóság az esetek többségében nyilván bonyolultabb (bár kis rendszereknél, ez nyilván egy könnyű járható út). -
martonx
veterán
válasz
Vision
#16837
üzenetére
dolgoztam bankoknak, OTP-nél egy időben még külsős IT tanácsadó is voltam pont ilyen esetekre (mert én is csak egy nick vagyok aki ugatja a szakmát, mert nem atoi-t optimalizálok hehehe).
De mindegy is, semmi értelme egy ilyen fórum keretein belül mélyebbre mennünk. Írtál egy problémát, páran írtunk lehetséges megoldási javaslatokat, aztán ebből mindenki azt hoz ki, amit a lehetőségei, képességei (bankokat ismerve és pár kivételt mélyen tisztelve de a többség inkompetens, kezdve a menedzsmenttől, a programozókig) és a projekt scope-ja engednek.
Számomra az egészből egyedül az volt a lényeg, és amiért nagyon hálás is vagyok neked, hogy @pmonitorral ellentétben hoztál egy valós életbeli programozói problémát, szemléltetve, hogy nem az atoi-val kell szórakozni, hanem olyan robosztus rendszereket írni, tervezni, amik valós ügyfél problémákra reagálnak. -
martonx
veterán
válasz
sztanozs
#16835
üzenetére
Nyilván, de Tapsi ezzel kezdte a probléma felvetést:
"A leggyorsabb futásidő 30 másodperc, ezt kéne levinni <1-re."
Persze, ez annyira tipikus üzlet, mindenből friss adat kell, és ráadásul lassú se lehet
Amúgy meg teljesen jó a probléma felvetés, mert pmonitor nagyon kezdett félre menni a string - int konverziók sebességével, miközben a való életben SOHA nem ez az igazi probléma -
martonx
veterán
válasz
Vision
#16826
üzenetére
Ez alapján amit leírtál, akkor is igaz, hogy ezeknek az adatoknak a jelentős része nem fog percenként változni. Márpedig ami nem fog percenként változni, azt teljesen felesleges realtime lekéregetni. Nyilván a konkrétumok ismerete nélkül én úgy csinálnám, hogy a 90% mehet cache-ből, és elég lenne csak a 10%-ot realtime lekérni.
-
martonx
veterán
válasz
pmonitor
#16775
üzenetére
"A fejlesztők úgyis elkergetnének, hiszen a programozókat nem érdekli a sebesség, és a méret/helypazarlás(lásd az elején belinkelt sztanozs hozzászólást -- is)."
Tessék egy link, hogy a nyelvek fejlesztőit mennyire nem érdekli a teljesítmény: [link]Mondod ezt úgy, hogy soha nem próbáltál meg PR-t beküldeni. Gratulálok
-
#16667
martonx
veterán
böng ész ő
#16665
martonx
veterán
válasz
böng ész ő
#16665
üzenetére
Ez esetben rossz hírem van a számodra.
-
#16651
martonx
veterán
böng ész ő
#16648
martonx
veterán
válasz
böng ész ő
#16648
üzenetére
stackoverflow, google
-
martonx
veterán
válasz
pmonitor
#16616
üzenetére
"De sztem. az elég sokszor előfordul, hogy tömegesen kell számokat szövegre konvertálni." -
Szerinted. A valóságban meg nem legalábbis semmiképpen sem tömegesen. Néha 1-1 logban nyilván szövegesen iratod ki a számokat is, de kb. ennyi (a nyilvánvaló programozói hibákat, helytene adat modellezést leszámítva). -
martonx
veterán
válasz
pmonitor
#16611
üzenetére
Hagy mondjak egy személyes példát.
Megrendelőnek volt egy utazáskereső rendszere, aminek már sok fejlesztő csapat nekifutott, a legjobb aki előttünk volt 2 perces keresés válaszidőket tudott felmutatni, nulla szűrési feltételekkel, hibás listázással stb...
Utána szerződött velünk, és az volt a kikötése, hogy 30 másodperc alatt érkezzenek meg a keresésre a válaszok, működő szűrésekkel, hibátlanul.
Megoldottuk neki C#-al, hogy 40 ms (igen fél perc volt az elvárás, és 40 milisec alatt jönnek a válaszok) alatt érkeznek a válaszok, vicc szerver terheléssel, minden szerződéses határidőt betartottunk. Az ügyfél szuper elégedett volt.
Vajon tényleg ennyire elégedett lett volna, ha tízszer ennyi idő alatt, tízszer ennyi pénzből oldjuk meg a feladatot C-vel / assembly-vel, és cserébe 2 ms alatt jönnek a válaszok?
Nem igazán hinném. -
martonx
veterán
válasz
pmonitor
#16566
üzenetére
Viszonyításképpen nekem Ryzen 7 5800x-en, 1 TB-s X4 m.2-es SSD-n, úgy indul a VS, mint az álom. Hol lassú ez? Szvsz iszonyat gyors. És a build idők is röhejesen alacsonyak. Igaz töbnyire Microservice-ekkel, meg Web API-kkal foglalkozok.
Ja, és a telepítés kevesebb, mint 7 GB-t foglal. -
martonx
veterán
válasz
lenkei83
#16475
üzenetére
User ellenőrzés szintjén úgy működhetne, hogy a user aktivitásakor ezt a táblát, amiben a Ture/False-t váltogatod, updatelnél egy mondjuk LastActivity timestamp mezőt.
Azt SQL job meg azt aki aktív, de a LastActivity-je mondjuk fél óránál régebbi, zokszó nélkül átállítja False-ra. -
martonx
veterán
válasz
lenkei83
#16467
üzenetére
Éppen most kezdesz eljutni a felismerésig, hogy ehhez egy alkalmazás szerver fog kelleni. Pedig te csak egy fapados session kezelést szerettél volna. Hát így jön ide az űrhajó.
Egy kókány módszert azért megléphetsz űrhajó építés előtt. Csinálj egy SQL jobot, amit utemezve tudsz futtatni, és az majd átállítja az inaktív usereket. -
martonx
veterán
válasz
lenkei83
#16465
ü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. Ebben az esetben SQL oldalon is el fog halni elég gyorsan az ide tartozó session. Az adatbázist ugye using-al használod? Azaz automatikusan dispose-oldóik?
És ennek semmi köze Asp.Net hez
Értem én, hogy valamit alapvetően rosszul írtál meg, és most nem ezt akarod kijavítani, hanem űrhajót építeni köré
Hidd el, mindenkinek jobb lesz, ha a kódodat javítod, ahelyett hogy űrhajót építenél.
SQL session-ök lekérdezése és erőltetett bezárása simán megoldható: KILL SPID command in SQL Server (sqlshack.com)De hidd el, neked nem ez kell, hanem egy jól működő programkód, ami nem hagy szemetet maga után.
-
martonx
veterán
Azért ez így erős. A Mac BSD-re épül, ami meg unix-ra, amire a Linux is. Szóval igen, a Mac nagyon nem egy linux, de valahogy nekem is ugyanaz volt az érzésem, mint @opr-nek, hogy de végülis ez egy linux, mert rögtön mindenhez terminalt kellett nyitni, csak épp ügyesebb, mint egy linux, mert annyi mindenhez mégse kell terminal-ban bohóckodni a google legmélyebb bugyraiból előszedve parancsokat.
De ahogy fentebb jeleztem, ez már nagyon flame kategória, szóval én nem mennék bele komolyabban, a többieknek is ezt tanácsolom, hogy hagyjuk a kinek milyen OS-t témát a programozás topikban. -
martonx
veterán
Tudom, hogy egy vélemény nem mérvadó, én személy szerint többször nekifutottam a Mac-nek, sőt Linux-nak is, de valahogy mindig lepattantam róla.
Számomra irónikus Mac-en hallani a just works mondást, miközben bőven bele kell heggeszteni, tutorialokat olvasni, megtanulni együtt élni a hiányosságaival (linuxon ez hatványozottan előjön, Mac-en csak időnként és a feketöves Mac-eseknek fel sem tűnik).
Ellenben Win vonalon, ha eddig is együtt tudtál élni a hiányosságokkal, akkor simán tényleg igaz a just works kitétel (és majd mindjárt jönnek a másik oldal megmondóemberei, akik elmondják, hogy ez nem így van, mert mekkora szopás a 99-ben vett nyomtatót win 10 alá felinstallálni, meg a kínából 1000 Ft-ért rendelt bluetooth adaptert se akaródzott felismerni a rendszernek stb...). Szvsz, talán jobb is lenne nem belemenni egy durva flame háborúba itt a programozás topikban
-
#16105
martonx
veterán
Ryan_Sanchez
#16104
martonx
veterán
válasz
Ryan_Sanchez
#16104
üzenetére
No igen, mivel ez web fejlesztés, azt tudod megcsinálni, amit egy böngésző meg tud csinálni. azt tudod csak te is megcsinálni javascriptből.
-
#16103
martonx
veterán
Ryan_Sanchez
#16102
martonx
veterán
válasz
Ryan_Sanchez
#16102
üzenetére
"Akkor egyértelmű, hogy ez csak fájlonként fog működni"
Hogy mi? -
#16100
martonx
veterán
Ryan_Sanchez
#16096
martonx
veterán
válasz
Ryan_Sanchez
#16096
üzenetére
<input type="file"> szerintem ezt keresed, nem pedig winforms-os dll-t
Webfejlesztés alapjai megvannak? -
martonx
veterán
válasz
pmonitor
#15974
üzenetére
Ahogy nézem, ilyen esetet mintha nem kezelne, mert ez az SDK csak az openxml szabványt jelenti, az, hogy egy konkrét excel file jelszóval lett ellátva, azt már maga az Excel csinálja a file mentésekor, az openxml szabványtól függetlenül, és ha jól olvastam utána ezt feloldani is csak akkor lehet, ha van tényleges Excel telepítve a gépre (vagy más nuget package tud ilyet NuGet Gallery | Spire.XLS 11.4.6
Fura, hogy ennél meg tudták oldani a jelszó kezelést is. -
martonx
veterán
válasz
pmonitor
#15972
üzenetére
Ez OpenXml, azaz az Office 2007-től kezdve default file formátumok (amik nyitott szabványok) kezelésére szolgáló SDK.
Szóval igen, amíg nem cél, hogy a régi Office 2003-as file-okat is kezelni tudja a kód (így 2021-ben, úgy sejtem ez nem egy akkora lemondás ), akkor a megoldásom tök jól működik docx-re, xlsx-re, pptx-re windowson, linuxon, és osx-en is (vagy akár raspberry-n édesmindegy).
Annak idején mi pl. pptx-ek gyártásához használtuk ezt az SDK-t linux szerveren.
Egyébként ezt a pár soromat már csak egy foreach-be kell tenni, és megírni a regexp-et, ami a hivatkozásokat kiszedi, illetve a végén az eredményt excelbe bedobni, és voilá(a foreach-et még hozzáadtam ).
Akkor most már igazi programozó nick-ké avanzsáltam? Pedig a win32 api-kat se vágom using System;using System.IO;using DocumentFormat.OpenXml.Packaging;var targetDirectory = new DirectoryInfo(@"c:\Users\lajos\Downloads\");foreach (var wordFile in targetDirectory.GetFiles("*.docx")){using var document = WordprocessingDocument.Open(wordFile.FullName, false);var body = document.MainDocumentPart.Document.Body.InnerText;Console.Write(body);} -
martonx
veterán
Tech Debt-et?? A hivatalos MS féle OpenXMLSDK-val??? OfficeDev/Open-XML-SDK: Open XML SDK by Microsoft (github.com)
Most kipróbáltam ennyi volt kiolvasni egy word doksi tartalmát:
using System;using DocumentFormat.OpenXml.Packaging;using var document = WordprocessingDocument.Open("c:\myTest.docx", false);var body = document.MainDocumentPart.Document.Body.InnerText;Console.Write(body); -
martonx
veterán
válasz
pmonitor
#15891
üzenetére
Hohó, eszembe jutott, hogy van egy projektemhez kapcsolódó kicsi kódrész, ami publikus.
NuGet Gallery | SimplePaymentSDK 1.0.9No persze még ennek a kicsi kódnak is külön története van, hogy miért lett publikus.
A Simple Payment-et gondolom nem kell bemutatni. OTP cégcsoport, mégis csak és kizárólag PHP-hoz van SDK-juk.
Az egyik nagyobb országos utazási irodának fejlesztett Asp.net rendszerembe kellett beintegrálni a bankkártyás fizetést. Mondtam az ügyfélnek, hogy tudom, hogy nem szokás publikussá tenni kódokat amiért fizetnek, de ez az egy kódrész pont olyan, amit mindenféle rizikó, retorzió, versenytorzítás nélkül lehetne publikussá tenni.
Gyakorlatilag vitatkoztunk, és meg kellett győznöm, hogy mi is mennyi nuget package-et használunk (mint npm csak épp C#-hoz), és itt van ez a több, mint 2 emberéves projekt, aminek ezt a pár hetes részét igazán megnyithatnánk a közösség előtt.
Így lett ez az elkészült SDK publikus, ugyanakkor ha belenéztek látszódik, hogy abba a részébe sosem tettünk energiát, hogy pl. Readme.md-t készítsünk
Ennek ellenére napi 5 letöltésnél jár (ami számok persze mindig csalókák, mert egy ember többször is letölthet egy csomagot).
Szóval szerintem hasznos kis package lett, de hangsúlyozom ne az alapján ítéld meg a programozói munkásságomat, hogy fel tudok egy ilyen kis nyúlfarknyi publikus kódot mutatni (ráadásul ezt is 2 nekem dolgozó kollégával közösen írtuk).
Inkább csak példának szánom, hogy mennyire nem ezen múlik, hogy egy "nick programozónak mondja-e magát".Webfejlesztőként vannak referenciának mondható publikus webes rendszereim, de már máskor is tűntek el hsz-eim, mert reklámnak minősülne, ha belinkelném őket. Ha nagyon érdekel PM-ben elküldhetem őket.
-
martonx
veterán
válasz
Demertin
#15875
üzenetére
Hát ööö nem akarlak kiábrándítani, de a gépészmérnök (pláne a hazai oktatási szintek...) szerintem nem egyenlő a harcászati, repüléstechnikai dolgokkal, a programozás meg végképp. Egyébként fogalmam sincs, hogy harcászatban, repüléstechnikában milyen nyelveket használnak, szerintem ha valami isteni csoda folytán odakerülsz egy ilyen céghez (egyáltlán itthon van ilyen fejlesztő cég?), akkor ráérsz megtanulni C-zni, vagy Assembly-zni, vagy tudom is én mostanában vajon miben fejleszthetnek.
-
#15871
martonx
veterán
MostaPista
#15867
martonx
veterán
válasz
MostaPista
#15867
üzenetére
Ha te autógyártó vagy, és szerinted X millióba kerül egy általad előállított autó. Mi meg odamegyünk, és kifejtjük, hogy de hát ezt lehetne ingyen is, mert milyen jó lenne mindenkinek az ötletünk, hogy legyen ingyen az autó.
És elkezdünk morcizni, mert te mint szemét önző autógyártó nem kezdesz el nekünk ingyen autót gyártani... -
#15846
martonx
veterán
MostaPista
#15840
martonx
veterán
válasz
MostaPista
#15840
üzenetére
De ha havi pár dollárt sajnálsz erre, akkor komolyan el tudod képzelni, hogy találni fogsz olyan programozót, aki ezt ingyen megírja neked?
-
#15838
martonx
veterán
MostaPista
#15836
martonx
veterán
válasz
MostaPista
#15836
üzenetére
Nem tudom eddig miket néztél át, de az Office 365 naptára tud location szerinti keresést
-
martonx
veterán
válasz
sztanozs
#15624
üzenetére
No igen, csak néha már úgy érzem ódákat írok (és talán mintha feleslegesen tenném), és nem akartam minden apró részletbe belemenni. Köszi a kiegészítést!
Plusz, amit egyikünk sem hangsúlyozott ki, az még a HATÁRIDŐ. Attól kezdve, hogy a szerződés megköttetett, egy programozónak határidőre el kell készülnie, nem pedig a kódot hobbiból csiszolgatnia a végletekig, akár a határidő többszörösével megcsúszva, mert így lett tuti a legszebb, leggyorsabb a kód.
-
martonx
veterán
válasz
pmonitor
#15620
üzenetére
Egy dolgot felett siklasz el. Te most a saját szórakozásodra programozol pár jópofa ciklust, és ezzel szórakozol, hogy hogyan lehet hatékonyabbá tenni, akár nyelv váltás árán is. Abba ne hagyd, ez egy nagyon hasznos hobbi!
DE ezzel szemben a rideg valóság az, hogy egyrészt a programmal szembeni követelményeket szinte SOHA nem a programozók határozzák meg. Ha az ügyfél már attól is boldog, ha az eddigi 20 másodperces futásideje 5 másodperc lesz, akkor ezt fogja beleírni a követelményei közé. Mert elképzelni sem tudja (hidd el, sokszor a programozók se látják előre a jövőt ), hogy amit szeretne az 40ms alatt is megoldható.A hardvert pedig azért kell fejleszteni, mert képzeld el a következő szitut (direkt kicsit kisarkítva):
Jón egy ügyfél, hogy kellene neki egy program, amit jelenleg 20 párhuzamos user használ, legyen gyors meg minden. Elkezd a csapat kódolni, menet közben jönnek változtatási igények, előjönnek csúszások, néhol kompromisszumos megoldásokkal kell élni stb...
Végül elkészül a kód, mindenki kipróbálja, zokszó nélkül viszi a 20 párhuzamos usert, szép, gyors, határidőre kész lett, mindenki happy.Igen, ám, de mi van akkor, ha visszajön az ügyfél, hogy nyitott még 4 másik telephelyet, ebből kettő már külföldön van, és hát a rendszer lassulgat igaz, hogy már 100 párhuzamos user van rajta. És ekkor az ügyfél választhat, beletol plusz X processzormagot Y összegért a rendszerbe, vagy elkezdi újra íratni a programját, ekkor már 100 párhuzamos userre méretezve mondjuk 5Y összegért (és ez az újraírás el fog tartani mondjuk 2 évig, miközben Y összegért azért a plusz hw erőforrást is bele kell tolnia, mert a rendszernek addig is mennie kell). Szerinted melyik opciót választja az ügyfél? Elárulom: roppant ritka az az ügyfél, aki a másodikat választja, ő is inkább csak azért, mert hardveresen már közelít a falhoz, ahonnan már nincs tovább.
És ekkor te, mint ügyfél, ott állsz az 300-adik párhuzamos user ügyfelessel szemben, és nem érted, hogy miért lett olyan szarul megírva a program, hogy várnia kell az ügyintézőnek, mire valamire reagál a rendszer. És hogy lehetnek ezek a magukat programozóknak mondó kóklerek ennyire faszok, hogy egy ilyen szart tettek le az asztalra. -
martonx
veterán
válasz
pmonitor
#15613
üzenetére
"És szerintetek a webalkalmazás miben íródott/íródik? Ha jól tudom C++-ban." - nem állítom, hogy pl. a C# egyik komponensének sincs köze a C/C++-hoz, de a C# konkrétan úgy működik, hogy megírod a kódodat C# nyelven, amiből a compiler (na, ez a compiler éppen simán lehet, hogy C/C++, de lehet, hogy Rust vagy tudja isten, lusta vagyok github-on kikeresni a Roslyn forráskódját) készít egy köztes nyelven lévő általános kódot (Intermediate Language), és futásidőben (pontosabban első futáskor) ebből készít a JIT egy arra a hw architektúrára optimalizált assembly kódot.
Bővebben: [link]
A C# nagyon sokáig windows only nyelv volt, de ez 2017 óta már nem így van. Így 2021-ben ideje lenne elfelejteni ezeket a rég berögzült paradigmákat (rakás C# rendszerünk fut Linuxon jelenleg is). Java, Javascript, PHP, Go, Python, stb. nyelvek meg soha nem is voltak windows only-k.
A konkrét példám éppen C#-os volt, ezzel nem egy C# vs. más nyelv flame-et akartam kelteni, hanem az mellett érvelni, hogy mennyi aspektusa van annak, hogy egy nyelvre azt mondjuk, hogy jó vagy csak játékszer, és ezek között a nyelv sebessége csak egy (sokszor tök lényegtelen) szempont a kismillió közül.
De látom, te most éppen a C/C++-ba beleszeretőbe vagy, amivel semmi baj nincs, én meggyőzni se akarlak semmiről. A C/C++ is teljesen jó nyelv bizonyos programozási feladatokra. Sőt minden nyelvben meg lehet oldani minden problémát, más kérdés, hogy egyes problémákat egyes nyelvekkel jóval egyszerűbben, gyorsabban meg lehet oldani, más nyelvekkel meg csak nyögvenyelősen.Ahonnan ez az egész thread elindult, hogy a C-ben lévő kódod vs. a C# kódod között futásidőben mértél némi eltérést (50% semmiképp sem drasztikus, majd ha a C-s kódod tizedannyi idő alatt lefut, akkor arra én is azt mondom, hogy na az már sebességkülönbség - és ezzel meg is válaszoltam egy korábbi kérdésed). És ezen eltérés alapján nagy hévvel kijelentetted, hogy a C# (de ide bármelyik nyelvet érthetnénk a kontextusod alapján) csak egy játékszer a C-hez képest. Miközben ez nem igaz, sőt butaság.
-
martonx
veterán
A probléma nem elsősorban a PHP volt. Nyilván PHP - vél is simán le lehetett volna menni 5s alá, ha nem is 40-80ms-re.
Én mindenféle script nyelvet szeretek. Tök gyorsan össze lehet bennük dobni egyszerűbb cuccokat.
Viszont az az általános tapasztalatom, hogy sok script junkie nem véletlenül marad a script nyelveknél, hanem a képességeik a gyorsan összedobjunk valamit, valami egyszerű nyelven szinten meg is áll.
Ez nem a script nyelvek hibája, és vannak persze kivételek. -
martonx
veterán
válasz
pmonitor
#15603
üzenetére
Nem off topik ez. Csak egyszerűen nem kell butaságokat írni. Annak, hogy egy programnyelv jó-e vagy rossz, egy csomó szempontja lehet, nem csak a futásidőben nyújtott teljesítmény. Hiszen, ha így lenne, akkor nem lenne feljövőben a Python, a PHP már vagy egy évtizede ki kellett volna, hogy haljon, a javascriptről nem is beszélve
Ugyanakkor nyilván azt se lehet kijelenteni, hogy nem számít a futásidejű teljesítmény, mert igenis van sok olyan eset, amikor meg erre kell kihegyezni valamit. De ekkor is több mindent figyelembe kell venni. Pl. van-e értelme natív nyelvben újraírni valamit, csak azért, hogy pár százalék gyorsulást hozzon a konyhára? Vagy inkább egyszerűbb egy szerver alá betolni plusz két processzormagot, és a fejlesztők meg a hónapokig / évekig tartó újraírás (nem is beszélve egy új nyelv megtanulásáról) helyett inkább olyan új feature-ökön dolgozhatnának, amikkel megtöbbszörözik a cég bevételeit?
Vagy említetted, hogy pl. elég csak a teljesítmény kritikus részeket megírni natív kódban, és azokat dll-ként behivatkozni. Ekkor vajon mennyire fog jól működni a közös logolás, monitoring? Mennyire lesz fájdalmas CI/CD rendszert több repository-ból kiindulva felépíteni, és egy sikeres build/deploy/testing fázist végig verni az X féle nyelven készült komponensken? Mekkora szopás van ebben az esetben, ha akár csak egy szerver frissítéskor eltörik valamelyik ilyen "külső" komponens? Netán linuxról windowsra váltanak vagy vissza? Vagy csak 32-ről 64 bitre? És máris cseszhetik a dll komponensüket. Ráadásul mi van, ha az a kolléga már nincs is a cégnél, aki ezt anno készítette?
És még hosszasan lehetne sorolni a kismillió szempontot, amiket fejlesztéskor számításba kell venni. Ahelyett, hogy csak az lebegne a fejlesztők szeme előtt, hogy hú, használjuk pont azt a nyelvet, amivel most éppen 50% teljesítmény növekedést lehetne elérni.Én is dolgoztam olyan projekten, ahol a futásidő kritikus volt. Nálunk C# projektnél az volt a mondás, hogy 5 másodperc alatt kell kiszolgálni egy HTTP requestet (kellemesen bonyolult háttér logikákat futtatva több millió adatsoron), mert az előző PHP-s csapat ezt se tudta felülről még csak megközelíteni se. Nálunk ez végül 40-80ms között szórt. Vajon elégedettebb lett volna-e a megrendelőnk, ha mindezt C-ben oldja meg egy másik csapat mondjuk négyszer ennyi fejlesztési időből, és a végén 30-60ms a requestek válaszideje? Miközben ő csak annyit akart, hogy 5 másodpercen belül menjenek a válaszok.
Szóval a világ korántsem olyan fekete-fehér, mint ahogy te látod.
-
martonx
veterán
válasz
pmonitor
#15587
üzenetére
Hm, most jól értem, hogy ez a C# játékszer, és a C mennyire hasít, ezen bődületes nagy eltérések alapján lett kijelentve?
C# C
n=13 23s 14s
n=15 330s 200sAkkor mondanám, hogy a C#-hoz képest a C hasít, és rohanjunk minél több, mindent C-be átrakni, ha tizedannyi idők alatt végezne.
Egyébként az is kérdéses, hogy a C#-ot mennyire mesterien optimalizáltad, minden struct és span<T>-e benne, meg ilyesmik.
A fentiekkel nem azt akarom bizonygatni, hogy a managed kód nem lassabb, mint egy natív kód, mert az butaság lenne, csak arra akartam rávilágítani, hogy a talán helyes eredményeidből, levont következtetésed helytelen: "C# játékszer a C-hez képest". -
-
martonx
veterán
válasz
Drizzt
#15452
üzenetére
Egyrészt többnyire igazad van, kár, hogy ezek kb. bármelyik nyelvre elmondhatóak, hogy fejlődnek, és van hozzájuk csomó library python, php, c#, go, javascript stb... Semmi értelme ezeket a nagy általánosságokat puffogtatni. Én a két nyelv közötti különbségekre próbáltam rámutatni, egyik nyelvet sem fikázva, objektívan.
Hol írtam, hogy kihalóban van? Pont azt írtam, hogy nem fog kihalni sosem. Olvasd már el, hogy mit írtam -
#15450
martonx
veterán
RudiLicenc
#15449
martonx
veterán
válasz
RudiLicenc
#15449
üzenetére
A java egy őskövület. Az Enterprise fejlesztések évtizedes tehetetlensége tartja életben, illetve anno az Android adott neki egy erős lökést, de mostanra ott már mindenki átállt Kotlinra.
No persze pont az Enterprise beágyazottsága miatt nem fog kihalni sose, munka is mindig lesz benne, lásd per pillanat is keresnek még Cobol fejlesztőket is. Illetve Java vonalon még vannak webes projektek, de ezek egyre ritkulnak.
A C# valamivel újabb nyelv (viszont pár éve drasztikusan megújult, ami folyamat jelenleg is tart), szintén van Enterprise vonalon is, de nem annyira mint Java. Webes vonalon egészen sok helyen bele lehet futni, cross-platform fejlesztéseknél Xamarinnal is jó pár helyen használják.A döntés a tied.
-
#15445
martonx
veterán
BTminishop
#15444
martonx
veterán
válasz
BTminishop
#15444
üzenetére
Hát a GDRP szerint, ha ez az oldalon a user által olvashatóan le van írva, és küldéskor elfogadja a feltételeket, akkor semmi gond.
-
martonx
veterán
válasz
Tigerclaw
#15432
üzenetére
"If you want to make use of more that the general limit of 10k units. (which is essentially limits you to 6 x Remote video uploads), you will need to make a request to youtube with your use case for exceeding the limit at this URL:
https://support.google.com/youtube/contact/yt_api_form?hl=en
Note that its the same as trying to upload an app to the app store, they will vet your request and either accept or deny. (it's anybody's guess if you are eligible, so i'd recommend some lateral thinking when developing your applications)" -
martonx
veterán
válasz
Tigerclaw
#15347
üzenetére
Ismered a mondást: sok légy nem tévedhet
Persze távol álljon tőlem egy vuejs vs react flame kirobbantása. Csak javasltam, hogy ha már ismerkedés, akkor a vuejs-nek is adj esélyt. Simán lehet, hogy neked is sokkal jobban be fog jönni, pláne ha angularos tapasztalatod van. -
-
-
martonx
veterán
Ez szerintem nem ennyire sarkos. Régen is használtunk Github-ot, MS évek óta megvette, azóta inkább lefelé mentek az árai, mint felfelé.
Attól még, hogy github, miért kellene Azure-t használni? Nálunk pl. Bamboo húzza le a kódokat Github-ból, és azok végül AWS-en futnak.
A CodeSpace meg egy Visual Studio Code, amit bárhol tudsz futtatni, ha mégis szabadulni akarsz a Codespace-től.
Ezek egymással tök jól vegyíthető építőkövek, ha valami jó és bevált, akkor nem kell csak azért is mindent egy adott céghez átvinni.
Ha valami komoly vendor lock, akkor az a felhő platform (AWS, Azure). Szerintem. -
#15065
martonx
veterán
instantwater
#15063
martonx
veterán
válasz
instantwater
#15063
üzenetére
Ez nem ide való. Nem tisztem MS-t védeni, meg nem is akarom
Csak jelezni akartam, hogy nem kell mindenből flame-et generálni. Olyan rendszer nincs, aminek nincsenek korlátai, és még olyan frissítés se volt (lásd legutóbbi Apple Big Sur), amivel valahol valakinek ne lett volna bármilyen problémája -
#15062
martonx
veterán
instantwater
#15058
martonx
veterán
válasz
instantwater
#15058
üzenetére
"A GH Actions pontosan ugyanolyan publikus bétateszt mint a win 10" - azért ez erősen troll kijelentés volt, mind a GH-t, mind a win10-et tekintve...
-
martonx
veterán
válasz
Silεncε
#14807
üzenetére
Én mostanában épp ckeditor 5-ös plugineket javítgatok aktívan, így hogy havonta jönnek a breaking change-es új verziók. Én ebben az egészben azt nem értem, hogy ha már valaki vállalja, hogy csinál egy plugint, és kap emailt egy PR érkezéséről, mégis mi a f....ért nem képes belátható időn belül rányomni egy nyomorult merge gombra?
-
-
#14735
martonx
veterán
BProgrammer
#14723
martonx
veterán
válasz
BProgrammer
#14723
üzenetére
Munkához, csakis AMD procis gépet szabad jelenleg választani, abból is az új 4XXX procisokat. 16GB memória kelleni fog, ahogy az 512GB SSD is. Aztán, hogy ezen peremfeltételek mentén pontosan melyik gyártó melyik gépét fogod választani, az szerintem kb. mindegy.
-
martonx
veterán
Egyik régi munkahelyemen esett meg az a klasszikus eset, hogy az egyik ügyfélnél a szerverek megzavarodtak. Egy napig szívtunk vele távolról, mire az ügyfél elküldte nekünk a biztonsági kamera aznap hajnali felvételét, ahol látszódik, hogy a takarítónő a Rack szekrény környékén porszívózik, közben véletlen egy adag kábelt a porszívóval kirántott, majd kis tétovázás után, találomra visszadugdosta a vezetékeket...
Ezóta hiszem el, hogy nem csak urban legend, amikor valakinek a lélegeztető gépét sikerült véletlenül legyilkolnia a takarító nőnek
-
-
-
#14444
martonx
veterán
instantwater
#14438
martonx
veterán
válasz
instantwater
#14438
üzenetére
Az AWS Lambdan egy linux distro fut, amin végeredményben custom runtime-al és némi bűvészkedéssel azt futtatsz, amit akarsz. Ettől még a tényen nem változtat, hogy egy csomó nyelv alapból, hivatalosan támogatott, előtelepített a Lambdan, míg a PHP nem. Ami azért számomra erősen jelzés értékű, hogy a PHP egyre inkább kikopik a fősodorból. Ettől még aranyos nyelv (anno én is PHP-vel kezdtem), és nem kell hanyatt-homlok minden meglévő PHP-s cuccot más nyelvekre migrálni, csak most kezdőként nyelvet tanulni, meg zöld mezős fejlesztésekhez talán már nem a PHP-t kellene választani.
-
martonx
veterán
válasz
K1nG HuNp
#14399
üzenetére
"amazon utan kezdni az ms is nyomatni azureon a serverless jamstacket" - mármint C#-ban jó ideje lehetett Azure-ban serverless dolgozni, a nodejs, meg python mint alternatívák valóban nemrég jöttek be.
És jó is, hogy mondtad a felhőt, meg a Serverless-t. Tegnap szó volt róla, hogy miért mondjuk, hogy a PHP már lefelé tart a lejtőn. Hát pl. az AWS Serverless nem támogatja a PHP-t, ahogy az Azure Functions sem. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions
Jó nyilván nem ebből kell levezetni, hogy a PHP kifutóban van, de azért eléggé jelzés értékű. -
martonx
veterán
Így leírva a WPF jogosnak tűnhet. Én eleve azt nem értem, hogy miért kell 2020-ban windows only desktop appot csinálni? Alapból web app-nak csinálnám, vagy pedig cross platformra pl. Xamarinnal.
A PHP viszont MS-es, .Net-es környezetben totál védhetetlen marhaságnak tűnik a szememben. Ne mondd, hogy szimpla API-kat Asp.Net Core-al nem lehet percek alatt összerakni
legalábbis ezt hallottam.
És ennek semmi köze Asp.Net hez 
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Ingatlanos topic!
- Mobil flották
- Spotify
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Autós topik látogatók beszélgetős, offolós topikja
- Megjött a jubileumi Pixel széria
- Apple asztali gépek
- Samsung Galaxy S25 Edge - a tegnap határán
- Microsoft Excel topic
- További aktív témák...
- Új Acer Predator 16 WQXGA 165Hz G-Sync i9-13900HX 16GB 1TB Nvidia RTX 4070 8GB 140W Win11 Garancia
- Számítógép, ryzen 5 2600, RX 580 8GB, 16gb ddr4, 512gb ssd, 1tb hdd
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 16/512 Iris Xe FHD
- Gigabyte GeForce GTX 1660 Ti OC hibátlan, dobozos, 14 nap személyes garanciával
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD
- Samsung Galaxy S25 128GB Kártyafüggetlen 1 év Garanciával
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Fujitsu LIFEBOOK E449 i5-8130U 12GB 512GB 14" FHD 1 év garancia
- BESZÁMÍTÁS! Gigabyte B450 Aorus R7 5800X 32GB DDR4 512GB SSD RTX 4060Ti 16GB Zalman N5 MF CM 650W
- Fujitsu LIFEBOOK E449 i5-8130U 8GB 256GB 14" FHD 1 év garancia
Állásajánlatok
Cég: FOTC
Város: Budapest