- Apple Watch
- Európa exkluzív Edge 60 Fusion színe a Mocha Mousse
- Okosóra és okoskiegészítő topik
- Samsung Galaxy Watch7 - kötelező kör
- Honor Magic V5 - méret a kamera mögött
- Google Pixel topik
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- iPhone topik
- Xiaomi 15 - kicsi telefon nagy energiával
Hirdetés
Új hozzászólás Aktív témák
-
martonx
veterán
Szia!
Én most egy ilyen példa .bat file-t csináltam:
kiszolgalokezelo.bat:
echostart %systemroot%\system32\services.msc
Ezt a Bv.Net-es programodból meghívva simán működik. Gyakorlatilag annyit tettem, hogy a start után kihagytam a /d-t, ami fingom sincs, hogy mit csinálna.
-
martonx
veterán
A kódod nem szép, a változónevekről nem is beszélve, de a célnak megfelel. Ha a többi file-al jól működik, csak ezzel a 3-mail nem, akkor kizárásos alapon valami nagyon alapvető problémának kell a háttérben lennie, mint pl. tényleg nincs ott a file / nincs jogosultságod.
Kódból nem fogsz tudni magadnak magasabb jogosultságot adni, egyszerűen eleve a megfelelő jogosultságokkal belépve a Windowsba, kell elindítani a programod, és akkor lesz jogosultága (vagy jobb gomb és Run as administrator). -
-
#8313
martonx
veterán
DrojDtroll
#8312
martonx
veterán
válasz
DrojDtroll
#8312
üzenetére
Lehet, hogy paraszt vagyok, de ha megdebuggolod, akkor biztosan látni fogod, hogy mi történik.
-
#8284
martonx
veterán
DrojDtroll
#8283
martonx
veterán
válasz
DrojDtroll
#8283
üzenetére
Simán jó lehet.
-
martonx
veterán
válasz
MineFox54
#8260
üzenetére
Eleve nem jó gyakorlat C# mellé MySql-t használni
Csak poénkodok, persze használhatsz bármit mellé, csak ha már jó gyakorlat volt a kérdés, akkor C# mellé MS SQL vagy valamilyen Azure-os adatbázis (na jó én perverz vagyok, mert AWS DynamoDB-t is C#-al használok) dukál. -
-
martonx
veterán
válasz
Zalanius
#8225
üzenetére
Igen, az EF Core esetleg visszatarthatott néhányakat. Ettől kezdve a megszokáson kívül tényleg nem lehet érvet találni egy új projekt .Net Frameworkkel indítására. Sőt kijött 2.0-ás verzióban a Microsoft.Windows.Compatibility package is, azaz ettől kezdve (windowson maradva 100%-ban elérte a .Net Core a .Net Framework kompatibilitást.
-
martonx
veterán
Múltkori .Net Core vs .Net FrameWork témához: tegnap éjszaka megjött a .Net Core 2.1
Egészen elképesztő, amit a Build time csökkentésével elértek. Pár projektes webes solution esetében a hideg build is drasztikusan gyorsult, a meleg build viszont gyakorlatilag észrevehetetlenül rövid időre csökkent. második F5-re, gyakorlatilag rögtön nyílik a böngésző, és indul az app
Döbbenetes, mintha PHP-val dolgoznék -
-
martonx
veterán
válasz
Froclee
#8194
üzenetére
Még két dolgot tennék hozzá: sokkal gyorsabb buildelés, gyorsabb runtime, kevesebb memória használat. Én IIS-en és AWS Lambdában is használom, ami a legjobb benne az valóban a cross-platform nyitottsága.
Gyakorlatilag nem az a kérdés, hogy a Full Framework megromlott-e, mert nyilván nem, egyszerűen hülyeség csak pusztán megszokásból Full Frameworkkel kezdeni új projektet, mikor a .Net Core-nak egy csomó érezhető előnye van. -
martonx
veterán
válasz
petyus_
#8160
üzenetére
Mi asp.net mvc után az asp.net core-al pont ugyanúgy indultunk el, mint az mvc-vel. Viewk, modellek, controllerek. Semmi extra tudás nem kell hozzá, alapvetően minden ugyanúgy működik mint eddig, kivéve a konfigurációs részét, illetve a controllerek modell bindingja változott, bár ez se ismeretlen, csak itt a web api-s megoldást húzták rá mindenhova, amit mv-hez képest, ha valakinek nem volt web api-s tapasztalata, akkor szokni kell egy picit.
Extra tudás akkor kell csak, amikor el kell kezdened saját middleware-t írnod mint például nekünk egy multi-tenant rendszerhez. De összességében elmondható már az 1.0 óta, hogy borzalmasan kézreáll, amiket utáltál az mvc-ben, azok mind megszűntek, és amit kívántál az mvc-ben, hogy bárcsak így lenne normálisan megírva, az pont úgy van megírva.
Egy fellélegzés volt már az asp.net core 1.0 is az mvc-hez képest
Ha használsz alatta EF Core-t is, akkor az viszont egy picit más tészta, ott egy fokkal hamarabb bele lehet futni utána olvasásba pl. pont a feljebb említett lazy-loading hiánya miatt. -
martonx
veterán
válasz
Zalanius
#8158
üzenetére
Lazy hiánnyal szvsz simán együtt lehet élni, kézzel be kell includeolni azt a pár (néha nem is annyira pár) táblát ennyivel fapadosabb, de azért ez nem az a hiányosság, ami miatt azt mondanám, hogy ez nem production ready.
A transactionscope már jobban fájhat, bár szerintem többnyire ez is kivédhető architekturális megoldásokkal, vagy EF Core helyett más ORM használatával pl. Dapper is .Net Core kompatibilis, és kezeli a transactionscope-ot. Ahol meg igazán fájhat (megkövült enterprise világ), ott meg szerintem még csak nem is hallottak a .Net Core-ról de ha véletlenül hallottak is, se kezdik újraírni 20 év előző kódjait .Net Core-ra. Szerintem. Mindenesetre igazad van, elég erős képzelőerővel én is el tudok képzelni olyan esetet, ahol ez blokkolja a használatát.
Az ORA-ról nem tudok nyilatkozni.
És igen, mi sok fős teamként (igaz felhős világban élünk, nem a régi megkövült enterprise dbadminos világban - hehe még DB adminunk sincs a több TB-os milliárd rekordokat tartalmazó tábláinkhoz), simán beleugrottunk nagy projektbe az 1.0-val (igaz azoknál Dapper-t használtunk EF Core helyett, de nem a transactionscope miatt). -
#8157
martonx
veterán
lord.lakli
#8153
martonx
veterán
válasz
lord.lakli
#8153
üzenetére
Asp.Net Core 1.0 óta abban (is) fejlesztünk. Amikor kijött a 2.0 rászántuk azt az 1 napot és simán átálltunk rá. Igaziból maga a .Net Core már az 1.0-val is simán használható volt, akár productionben is (per pillanat is vannak microserviceink, amik 1.0-n maradtak), a 2.0-val simán elérte a Full Framework tudását (mínusz signalr), sőt egy csomó dologban már az 1.0 is nagyságrendekkel jobb volt, mint a régi MVC (mondjuk DI, meg middleware-ek).
EF Core-t is használjuk 1.0 óta, na mondjuk ennek a funkcionalitása az 1.0-val elég fapados volt, a 2.0-val már simán jó, 2.1 pedig már itt van a küszöbön, ami funkció paritásba kerül a sima EF-el, amellett, hogy annál már a 2.0 is nagyságrendekkel hatékonyabb volt (kivéve Group by, ami megítélés kérdése, hogy ténylegesen mekkora hátrány volt az eddigi nem létezése). -
martonx
veterán
válasz
Goose-T
#8145
üzenetére
Jaj tényleg erre akartam válaszolni. Ez örök dilemma, hogy az állásinterjú mennyire legyen elmélet vagy gyakorlat orientált. Szvsz senior szintnél inkább a gyakorlat a lényeg. Mert mi van, ha pöccre meg tudja mondani, hogy mi a különbség az érték és referencia változó típusok között, meg mi az a boxing, unboxing, de közben egy értelmes sornyi kódot se tud leírni?
Ha egy senior-t mindenképpen kérdezgetni kell, akkor én szakmailag inkább arra lennék kíváncsi, hogy mennyire naprakész, mennyire követi az aktualitásokat. Ez számomra nagyságrendekkel többet elárul a jelöltről, mint a száraz elmélet felmondatása. Nagyvállalatoknál dolgozó "senior" kollégáktól előre is elnézést kérek, de ha az idestova több, mint egy éve megjelent .Net Core-al nulla tapasztalata van egy jelentkezőnek, még csak egy hobbi / side projektben se próbálta ki soha, akkor az a fejlesztő rögtön nem senior, csak sok gyakorlattal rendelkező iparos.Ha meg gyakorlat, akkor adjatok neki valami egyszerű feladatot, ahol nem a feladat bonyolultsága a lényeg, hanem hogy mennyire lazán, mennyire szépen, mennyire olvasható kóddal, jó nevezéktannal oldja meg. És indoklást kérni, hogy miért, hogy. Nálunk meglepően sokan véreznek el a legegyszerűbb feladatokon is
Máris nagyságrendekkel értelmesebben eltöltöttétek az időt, és sokkal többet megtudtál a jelöltről, mint ha végigmész egy debil állásinterjús C# kérdéslistán. -
martonx
veterán
Szia, offba rakom a válaszom, de a kezdeményezés nagyon hasznos, és éppen ezért szoktam rendre javasolni az AspHOSTpage-et, mint hoszting szolgáltató alternatíva, mert korrektek és nyitottak vagytok, noha a véleményemet továbbra is fenntartom, hogy én személy szerint inkább Azure-t választanék. Tudva, hogy te érdekelt vagy a hagyományos hosztingban, én meg nem vagyok érdekelt az Azure-ban, nyilván a végén neked lesz igazad, de azért hátha sokaknak lesz gondolatébresztő amit leírok.
Az Azure-nak, ahogy fentebb is írtam nem az ár az előnye, pontosabban az a vicc, hogy ha ért hozzá az ember, akkor tényleg bagóért lehet Azure-on hosztolni.
Hogy a példádra válaszoljak, és megmutassam micsoda lehetőségek rejlenek a felhőben két példán keresztül válaszolok:1. buta fejlesztő fogja az Azure App Service-t, havi nettó 8 EUR-ért, plusz hozzácsap egy MySQL-t havi nettó 25 EUR-ért, és egy üzleti Outlook (vagy Office 365 vagy nem is tudom mik ennek a nevei, Gmail is van üzleti, fogalmam sincs a díjszabásaikról, ezért ezt most ki is hagynám az összehasonlításból) és máris megoldotta a kérdéses infrastrukturális feladatot. Számol és rájön, hogy nahát ehhez képest AspHOSTpage-nél már havi 1800Ft-ért kijön ugyanez (Azure 9900Ft vs 1800Ft).
2. okos fejlesztő átgondolja, utánanéz és kitalálja, hogy erre neki tökéletes az Azure Functions ingyen, ehhez hozzácsap 10Gb blob storage-et havi 0,26EUR-ért és egy Azure SQL-t havi 4,13 EUR-ért. Feladat teljesítve Azure havi 1350Ft vs 1800Ft De simán lehet, hogy elég neki erre egy Azure Table storage ez esetben az Azure havi díja kemény 0,6 EUR per hónap lesz, ami azért már igazán baráti, nem?
De valójában nem is az árak miatt mondom, hogy semmi értelme manapság garázscégeknél hosztolni (legalábbis az én szemszögemből nézve). Hiszem, hogy aki Asp.Net-et használ, az jellemzően nem móricka projektekben utazik, és nem havi 4-5 wordpress-re (ok, ennek asp.net es bármelyik megfelelőjére) alapuló portet tol ki magából, hanem komoly üzleti alkalmazásokat épít. Ekkor a leglényegtelenebb, hogy sikerül-e havi 2K-ból vagy netán havi 50K-ból kihozni a hoszting költséget, mert egy több milliós projektnél régen rossz ha ezen múlik a döntés, és a nyereségesség
Nálam amikor szabadúszó munkát vállalok el, pont az egyik fokmérője a megrendelő komolyságának, hogy az érdekli-e, hogy mennyibe fog kerülni a havi hoszting, vagy az, hogy mennyire lesz jól skálázható, profi a végeredmény a várható nagy terhelésre, speciális felhasználásra való tekintettel.
És ilyenkor minden pénzt megér, hogy bármikor indíthatok plusz teszt adatbázisokat, plusz teszt szervereket, csinálok egy cdn-t, a db backupokat ide-oda csatolhatom, szerver imageket mozgathatom, duplikálhatomm beröccenthetek egy distributed cachet mondjuk redis alapokon, és mindezt azure-on belül pár kattintással (a megrendelő számlájára persze).
Ugyanezen okból használjuk a főállásomban AWS-t, ahol terheléstől függően 10 és 300 szerver között ingadozik a terhelésünk, és minden ki van szervezve distributed megoldásokba. -
martonx
veterán
Persze, hogy lehet, a kolléga például az aspHOSTpage-en tervezi hosztolni, az őskorban még én is hosztoltam náluk több oldalt is, elég korrektek, csak épp az Azure óta (jelzem AWS-ben is lehet, sőt ott is van ingyenes opció, bár ott egy fokkal macerásabb, mint Azure-ban), semmi értelme nincs az ilyen hoszting cégeknél hosztolni. Na jó, a dedikált hoszting cégek valamivel olcsóbbak tudnak lenni, mint az Azure.
Kismillió hosting cég van, ahol pont ugyanúgy tudsz asp.net-et is hosztolni, mint php-t (mint pl. godaddy, hogy csak egy ismertebbet mondjak). -
martonx
veterán
válasz
petyus_
#8119
üzenetére
Oké, én nem ismertem a projekt létrejöttének a körülményeit, sima MVC-t én már akkor se választottam volna (Asp.Net Core éppen egy éve stabil, használható, tavaly ősz óta már 2.0 is van belőle).
A klasszikus aspHOSTpage-es hostolást pedig mindenképpen kiváltanám Azure-al, a DB-t meg Azure Table Storage-al (olcsóbb nem lesz az biztos, de sokkal előre mutatóbb, és legalább kicsit bele fogsz látni az infrastruktúra szintbe is).
Azt neked kell tudnod, hogy backend vagy frontend vonz-e jobban, ártani biztos nem árt, ha egy kicsit jobban utána nézel a frontendnek is. -
martonx
veterán
válasz
petyus_
#8117
üzenetére
Előre is bocsánatot kérek, elég szókimondó, de pozitívnak szánt kritika következik:
Én erre egy Facebook csoportot csináltam volna, de nem vagyunk egyformákAzért, hogy konstruktív is legyek:
1. ha már Asp.Net (ami egyébként alapvetően jó választás volt, és gondolom némi önképzési vágy is lehetett ebben, hogy nem Facebook-on csináltál ehhez egy csoportot), akkor már miért nem szavaztál az igazi önképzésre, és csináltad Asp.Net Core-al, ellentétben a legacy MVC-vel?
2. kettő darab DB entitásod van, ehhez miért kell egyáltalán adatbázis EF-el, mindennel? Én simán egy csv-be, vagy xml-be letettem volna, azt' kész a Service-ekbe meg elfér az a plusz 20 sor, ami a fizikai adattárolásért felel.
3. A Contracts projekt teljesen felesleges kiszervezése mindannak, aminek szerves helye lenne a Services-ben.
4. De ha már Services, akkor könyörgöm a Service-eket ne hívjuk már Manager-nek
5. Autmapper a két darab, egyébként 4-5 property-s modelhez. WTF? Automapper vagy sem, ezen hitvitákat lehetne folytatni, hogy itt biztosan nem kell, az halál biztos.
6. Javascript része pedig a nocomment kategória.
7. DI: Autofac fasza, és nagy kedvenc, de ide minek?Elmondom a helyedben mit csináltam volna, ha már önképzés, meg végre egy projekt, meg lelkes fiatal lennék, meg stb...
1. Asp.Net Core-al oldottam volna meg, erőltetve hogy mindent az Asp.Net Core out-of-the box megoldásaival oldjak meg (pl. beépített DI), hogy lássam mi, mit tud, minek hol a határa.
2. Azure-ban hostolnám (App Service, vagy még menőbb, ha Azure Functions), hogy újat tanuljak, használnék valami Azure-os NoSQL DB-t, mondjuk ehhez simán elég egy Azure Table Storage
3. Beleállnék a JavaScript, CSS részébe, és vanilla js-el oldanám meg, CSS vonalon bootstrap helyett használnék flexbox-ot, megcsinálnám azt a minimális dizájnt a saját kezemmel, és máris többet tudnék ezekről a dolgokról is.
4. Neadj Isten pusztán önképzésként beüzemelnék a projekt keretein belül egy npm-et, browserify-t, vagy webpack-et, és még a melóhelyen is menő lennék, hogy én tudom mik azok a buzzwordök, amik a menő közösségekben már évek óta alap tudásnak számítanak.Ehelyett amit csináltál, csak simán ugyanaz, amit a melóhelyeden csinálsz nap, mint nap (legacy technológiákon alapuló favágás), semmivel nem vitt előrébb semmihez, az idődet pazaroltad, ahelyett, hogy tíz perc alatt összeraktál volna egy FB csoportot, vagy (figyelem szintén önképzés) indítottatok volna SurveyGizmo-n egy ingyenes survey-t, amin a vendégek pont ugyanezeket az adatokat megadhatják, és ugyanúgy ad admin oldalt, ahol a megadott adatok megtekinthetőek.
-
martonx
veterán
válasz
kw3v865
#8055
üzenetére
A böngészőben futtatsz egy url-t, ahhoz csapd hozzá query string paraméterekként a C#-os változóidat. A query string paramétereket meg ki tudod olvasni JavaScripttel.A többiekhez csatlakozva, ha már olyan fontos ez a térkép, akkor itt lenne az ideje dobni a winforms-os legacy szart, és megírni tisztán Asp.Net Core-osra az egészet.
-
#8038
martonx
veterán
BTminishop
#8036
martonx
veterán
válasz
BTminishop
#8036
üzenetére
Winforms a múlt, WPF a jelen / közelmúlt, UWP a jelen / jövő. Aztán persze, ahogy MS váltogatja a technológiáit, ki tudja, hogy az UWP-vel mi lesz hosszabb távon.
-
martonx
veterán
Az megvan, hogy mi a különbség szerver oldal és kliens oldal között? Érted az egyik kód a szerveren fut, a másik a böngészőben
Azaz így direktben sehogy nem tudod megoldani, amit akarsz. Aztán persze miért ne küldhetnéd el a szervernek js-ből ajax-al azt, amit majd szeretnél, hogy a szerver belerendereljen a model propertybe. -
martonx
veterán
Jobbra váltani mindig könnyű, azaz Java -> C# váltás laza. Igaziból a C# -> Java váltás se fáj annyira, de a Java sokkal butább szintaktikailag (minél jobban benne voltál a C#-ban annál jobban fáj, hogy mennyire fapados a Java).
Ami tényleg fájni tud, az a tipikus menedzselt nyelvek (C# - Java)-ról váltás bármi másra, vagy bármi másról ezekre. -
martonx
veterán
Hú, te valamit nagyon fordítva akarsz csinálni.
Ez így alapjaiban nem jó, azt akartad kérdezni, hogy hogyan készíts saját custom HtmlHelpert nem pedig, hogy a saját próbálkozásodon mit tákolj. Vagy hogyan overrideold a meglévő EditorFor implementációt. Szerintem.
Egyébként meg a gugli segít, ha már tudod mit akarsz kérdezni (javasolt keresőszavak: extend, override, custom editor template) -
martonx
veterán
válasz
bandi0000
#7797
üzenetére
Az általában nem baj, ha egy kód nagy. Az a baj, ha nincs jól szervezve, nem olvasható, nem átlátható. Szóval neked most nem azon kellene törnöd a fejed, hogy szar megoldásokkal hogy nyerjek pár sort, hanem hogy szervezd normális olvasható, átlátható formába. Pl. Bevezetni repository patternt, funkciókat más classokba kiszervezni stb...
-
martonx
veterán
Pont ez a lényeg. Ha valami async, akkor az adjon vissza Task-ot. Viszont bármikor odabiggyeszteheted a .Result-ot az async metódusod meghívásának a végére, és máris normál változót fogsz visszakapni, mert látom ez a mániád.
Azaz pl. MyMethodAsync()-et kétféleképpen tudod használni:
1. szép async módon:
var a = await MyMethodAsync();2. csúnyán direktben syncesítve vállalva az esetleg háttérbeli async problémákat, ha egyébként minden más metódusod async fut:
var a = MyMethodAsync().Result;Azaz ha mindenképpen "szép" változó típust akarsz visszakapni a .Result-al bárhol rövidre tudod zárni az asyncosítást.
-
-
martonx
veterán
Nem tartom jó jelnek, hogy a static metódusodban mindig újból csinálsz egy webclient-et. Ez lehet, hogy egy szálon nem okoz gondot, több szálon viszont simán lehet, hogy összeakad valami valahol..
A helyedben a webclient-et egy példányban hoznám létre, és azt használnám újra és újra.Másrészt webről fileok letöltésénél a szűk keresztmetszet úgyis a sávszélesség, nem pedig a processzor kihasználtság, szóval szerintem ez az a tipikus helyzet, ahol felesleges párhuzamosítással felesleges komplexitást hozol be a rendszerbe, nulla hozzáadott értékkel.
Majd amikor a fileokat parsolni akarod, vagy mittudomén, ott lesz értelme a párhuzamosításnak, de itt most éppen nincs értelme. -
#7741
martonx
veterán
lord.lakli
#7740
martonx
veterán
válasz
lord.lakli
#7740
üzenetére
Teljesen más okból, de igen, ez így van
-
martonx
veterán
-
#7609
martonx
veterán
lord.lakli
#7608
martonx
veterán
válasz
lord.lakli
#7608
üzenetére
Ha meg előre annyira nem ismert, akkor mehet nosql-el, bár az ismeretlen adat struktúrát nemcsak letarolni nehéz, de visszaolvasni is.
-
martonx
veterán
Ezt egyrészt web app-al is meg lehet csinálni HTML5 Notification API-ra keress rá.
Másrészt ehhez az UWP tökéletes (már ha win10-ről beszélünk), annak is van értesítő funkciója.
A WPF se volt rossz választás részedről ehhez, csak mint látod ezeknek a klasszikus telepítgetős appoknak pont ez a nagy hátránya, hogy ki tudja hol fognak futni és hol nem.
Ahol van UWP, ott az tutira futni fog. Ahol van egy modern böngésző, ott a HTML5 tutira futni fog. -
-
#7513
martonx
veterán
Chesterfield
#7512
martonx
veterán
válasz
Chesterfield
#7512
üzenetére
Pluralsight, Udemy, asp.net honlap, gugli...
-
#7504
martonx
veterán
Chesterfield
#7497
martonx
veterán
válasz
Chesterfield
#7497
üzenetére
Hogy a kérdésedre is válaszoljak, gyakornoknak vettek fel, nem kell pattogni, legelső napokban úgyis kiderül minden szépen sorban, és bőven lesz időd elsajátítani a helynek megfelelő cuccokat.
-
martonx
veterán
Az UWP architekturálisan teljesen más, sokkal modernebb. Ugyanakkor eléggé felülről nézve az is yaml + c# alapú (leszámítva a js képességet és a DX12 + C++ képességet).
Két fő különbség van egyébként (ahogy én látom, aztán persze hosszasan lehetne még sorolni az apróságokat): 1. UWP csak store-ból telepíthető, 2. UWP minden esetben sandboxban fut, abból sehogy nem tud kilépni, nem adható neki admin mód.
Ja, és UWP tud .Net Native-ra fordulni, míg WFP nem, már ha ez fontos (teljesítmény szempontból). -
#7485
martonx
veterán
Chesterfield
#7483
martonx
veterán
válasz
Chesterfield
#7483
üzenetére
Klasszikus desktop alkalmazásnak nincs. UWP az új desktop, illetve speciális esetekben WPF még játszhat, de az is inkább már csak megszokásból.
-
martonx
veterán
Miért ne lenne a C# jó irány? Persze ha csak a pénz a lényeg, akkor a legjobb valami extrém nyelven istenkirály programozónak lenni, pl. bank szektorban COBOL programozók 1,5-2 misit simán meg lehet keresni. Más kérdés, hogy a munka is pont ennyire szar
Aztán ott vannak a big data nyelvek (Scala és társai) ezekkel is jól lehet keresni. Igaziból bármilyen nyelvvel jól lehet keresni, ha igazán jó leszel abban, amit csinálsz. A nyelvenkénti fizetés eltérések hiszem, hogy 10-20%-on belül mozognak.
-
-
martonx
veterán
válasz
Froclee
#7111
üzenetére
"Én úgy érzem a Java picit elhúzott."
Bocs, de ezen felröhögtem. A Java-nak van majdnem 10 év előnye a .Net-hez képest (na jó Java 95-ben indult, .Net 2001-ben), miközben a Java eleve mulitplatform nyelvnek indult a .Net pedig windows only-nak.
Ha így nézed, akkor ha a Java nem lenne akkora szar, amekkora mindig is volt, akkor a .Net labdába se tudott volna rúgni a 2001-es indulása óta. De nem ezt látjuk, a .Net szépen fejlődik, mostanra nagyon komoly ökoszisztémája van, a C# fejlesztők majdnem ugyanolyan keresettek, mint a Java-sok.
Noha az a 6 év, és run everywhere tagadhatatlanul a mai napig is Java túlsúlyt okoz, mindez azonban nem így történt volna, ha. (hatásszünet)Megkockáztatom, a Java mostanra sehol nem lenne, ha a Gugli nem a Java-t választotta volna az Android programozási nyelvének valamikor 2008 végén. Már rég a retyón húzták volna le magukat a Java fejlesztők (értsd átképezték volna magukat más nyelvekre), mára a nyelv valahol a Visual Basic elterjedtségi szintjén tanyázna.
Az Android jött, látott, győzött, a Java nyelv megmenekült, a Microsoft pedig előre menekült és az OS dominanciájának elvesztésével párhuzamosan azt tette, amit tennie kellett, elindult az open-source világba, az erősségeire koncentrált, köztük a .Net-re és az ASP.Net-re, s a fejlesztőkön keresztül próbál életet lehelni a nem túl rózsásan álló windows ökoszisztémájába.
Ezért vásárolta fel a Xamarint is ("VS ingyenes lett..." elárulom már több mint egy éve - ha nem kettő - ingyenes) és ami igazán a lényeg, hogy a Xamarint is ingyenessé tette, ami nagy dolog, mert előtte több száz dolláros havi díja volt.
Így MS most abban reménykedik, hogy ha már fejlesztői ökoszisztémában ilyen erős, akkor a fejlesztők elkezdenek .Net-el, Xamarinnal dolgozni, márpedig ha ez történik, akkor mivel multiplatform fejlesztésekről lévén szó, az appok automatikusan Windows-on is megjelennének. Így ismét életre tudna kelni az MS által mostanra talán visszafordíthatlanul elbaltázott win10, win10 mobile vonalak.
Sőt havi 40 EUR-t is ingyen ad MS az Azure-jában, ezzel is próbálja a fejlesztőket az ő ökoszisztémájába csalogatni.
szóval ha akarnám se tudnám kipróbálni.
Vagy legalábbis a klasszikus ASP vbscriptjét emlékszek, hogy debugoltam VS 2005-tel (hű, az se ma volt...)
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Samsung QE55QN85D 55" Neo QLED, Mini LED, 4K, 120 Hz, HDR10+
- Lenovo Thinkpad X270, 12,5" FHD IPS Touch, I5-7300U, 8GB DDR4, 256GB SSD, W11, Számla, 1 év garancia
- Dell Ltitude 7480, 14" FHD IPS Touch, I5-6300U, 8GB DDR4, 256GB SSD, W11, Számla, 1 év garancia
- Dell Ltitude 7480, 14" FHD IPS, I5-6300U, 8GB DDR4, 256GB SSD, W11, Számla, 1 év garancia ( olvasd v
- IdeaPad S145-14IWL 14" HD i5-8265U GeForce MX110 12GB 512GB NVMe gar
- Telefon felvásárlás!! Apple Watch Series 6/Apple Watch Series 7/Apple Watch Series 8
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Asus TUF Gaming F16 (2024) FX607JV Grey - 16" - és Lenovo Legion Slim 5 RYZEN 7 8845HS
- Samsung Galaxy S23 Ultra / 8RAM 256GB / Gyárifüggetlen / 12 Hó Garancia
- Samsung Galaxy A12 64GB Kártyafüggetlen 1 év Garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest