-
IT café
Új hozzászólás Aktív témák
-
-
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.
Én kérek elnézést!
-
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)"Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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Én kérek elnézést!
-
-
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".Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.Én kérek elnézé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.
Én kérek elnézést!
-
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
Én kérek elnézést!
-
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?
Én kérek elnézést!
-
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...Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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);
[ Szerkesztve ]
Én kérek elnézést!
-
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ágomusing 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);
}
[ Szerkesztve ]
Én kérek elnézést!
-
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.Én kérek elnézést!
-
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?Én kérek elnézést!
-
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?Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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Én kérek elnézést!
-
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.Én kérek elnézést!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- -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.
- 1.250.000 FT helyett 940.000 FT !! MacBook Pro 16" M3 Pro 12CPU / 18GPU / 18GB / 512 SSD
- RTX 2080TI ROG STRIX GAMER PC