- Xiaomi 14T Pro - teljes a család?
- Poco F7
- Milyen okostelefont vegyek?
- Google Pixel topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Apple Watch
- Android alkalmazások - szoftver kibeszélő topik
- A Pixel 10 minden színben és oldalról
- Poco X6 Pro - ötös alá
- Stílussal és friss szenzorokkal futott be a Huawei Watch GT 5
Hirdetés
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
pigster
#6892
üzenetére
Jelzem egyébként kismillió fillérekbe kerülő program létezik erre, mint amire le akarod fejleszteni az ezeregyediket.
Ráadásul igazad van: a telepítés, kód hordozhatóság fájdalmas. Ezért is koptak ki mostanra a vastag kliensek, és az ilyen programok böngészőből futnak, így abszolút nem probléma az adatbázis telepítése
-
martonx
veterán
-
#6774
martonx
veterán
lord.lakli
#6773
martonx
veterán
válasz
lord.lakli
#6773
üzenetére
A nyitó hsz-re való reagálás egy ilyen gyöngyszem hozzászólásban már csak hab a tortán
![;]](//cdn.rios.hu/dl/s/v1.gif)
Másrészt értékeljük a segítő készséget, respect -
martonx
veterán
Most hülyéskedsz? Debugold már végig azt a pár sort, és nézd meg, hogy hol kapsz null-t, és képzeld ott lesz a hiba.
Abszolút nem biztos, hogy a kóddal van baj, jó eséllyel valami környezeti változó / registry bejegyzés, telepítési útvonal nem lesz jó, ami nem a kód hibája. -
-
martonx
veterán
Jópofa dolog ez az universalApp, csak a hülye MS annyiszor nyírta ki, változtatta meg drasztikusan az utóbbi években az eddigi fő platform fejlesztési irányát, hogy szvsz kb. egyedül vagy azzal, hogy universalApp-ot fejlesztesz. Nem akarok a többiek nevében beszélni, de igyekszek annyira távol maradni a Microsoft újabb platformjaitól, amennyire csak lehet (és mondom ezt C# fejlesztőként), mert tragédia amit az utóbbi 5 évben az MS művelt.
Aztán meg megy az értetlenül nézés részükről, hogy miért nem fejleszt senki Silverlightban/winRT alkalmazásban/universalApp-ban (mikor éppen melyik volt a sláger)? Mikor alapvetően egy egyszerű HTML5-ös alkalmazás is natív élményt hoz windows-on, és portolni is jóval könnyebb utána más platformokra, vagy sokan eleve Xamarinnal futnak neki, mert akkor kapásból célozni tudják a többi platformot is.
Most meg, hogy már IOS-ről, Android-ról is lehet portolni appokat universalApp-á, végképp ki lesz az a hülye, aki nekiáll nulláról universalApp-ot készíteni? -
martonx
veterán
Ugyan ezt az SQL topikban kellett volna kérdezned, de tessék itt az én módszerem, ami a belinkelt google-os módszernél biztosan jobb, és hatékonyabb (meg rövidebb is, de az ugye kit érdekel):
-- disable all constraints
EXEC sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all"
-- delete data in all tables
EXEC sp_MSForEachTable "DELETE FROM ?"
-- enable all constraints
exec sp_msforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"Mondjuk ezt eddig csak MSSQL 2012-vel próbáltam, de elvileg az Azure SQL már 2014-el is kompatibilis, szóval mennie kellene.
-
martonx
veterán
válasz
zsolti_20
#6400
üzenetére
"Ha nem ez lenne a megfelelő topik ezzel kapcsolatban kérlek irányítsatok át"
Ez a C# topik, szóval elvileg jó helyen jársz. Gyakorlatilag meg csinálni kellene egy hülye kérdések topikot, mert az lehet, hogy megfelelőbb lenne számodra
Viccet félretéve, nem lehetne értelmesebben, netán példa kódokkal megfogalmaznod, hogy mit is akarsz?
-
martonx
veterán
"aztán valami olyat kapsz, amitől eldobod az agyad, de azt már megfejettük, hogy azét mondanak mindenre igent, mert nemet mondani tiszteletlenség.."
Sokat dolgozok orosz/ukrán/fehér orosz (innen nézve egykutya - és valóban mennyire igaz) fejlesztőkkel is közösen. Na, ők is elég furák. Ők azok, akiknek kiadod a parancsot, és mint egy vadászkopó gondolkodás nélkül végrehajtják. Komolyan, ha azt mondod, hogy menjünk jobbra, tök mindegy, hogy négy falat kell puszta kézzel lerombolni, ők akkor is jobbra mennek, és nem mondják azt, hogy de mi lenne, ha kettőt megkerülnénk, egyet meg kihagynánk mert tök felesleges, és ténylegesen csak egyet kellene áttörnünk.
Mióta személyesen ismerem az orosz mentalitást, meg tudom érteni a németek elkeseredettségét, döbbentét, amikor szembe találták magukat a szovjet néphadsereggel a második világháborúban, és a szovjetek minden józan gondolkodást nélkülözve képesek voltak dacolni mindennel, és elmenni a legvégsőkig.
Annak mindig van egy pikáns bája, amikor az orosz (fehérorosz/ukrán egykutya) fejlesztőkhöz szokott projekt vezető kiadja az ukázt a magyar fejlesztőknek, azok meg küldenek neki egy csomó kérdést, hogy biztos így vagy úgy, vagy nem-e lenne sokkal jobb amúgy? És nem érti, hogy mik ezek a kérdések, mikor ő világosan megmondta, hogy jobbra kell menni, és leszarja, hogy jobbra menni kb. lehetetlen mert puszta kézzel kell 4 beton falat áttörni.
-
martonx
veterán
válasz
Froclee
#6304
üzenetére
Semmi köze, mert borítékolom, hogy egy sornyi C# kód se fog elhangozni a végén, mint megoldás.
Itt az ideje némi logolást tenned a programodba, hogy lásd, mi a hiba
Lehet, hogy csak valami mysql-es izét fel kell telepíteni a másik gépre is.
Pont az ilyen szarakodások miatt halt ki mostanra a klasszikus vastag kliens-es ügyviteli rendszerek fejlesztése, és váltotta fel a webes fejlesztés. -
-
#6264
martonx
veterán
haromegesz14
#6263
martonx
veterán
válasz
haromegesz14
#6263
üzenetére
Viszont a VS2013 Community Edition ingyenes, és a VS2013 Pro komplett funkcionalitásával rendelkezik, szóval semmi se gátolhat meg abban, hogy ne azt használd.
-
#6262
martonx
veterán
haromegesz14
#6261
martonx
veterán
válasz
haromegesz14
#6261
üzenetére
simán nem kompatibilisek
-
martonx
veterán
Mondjuk biztos nem a leghatékonyabb, de én fognám és mindkét számból mondjuk listát csinálnék, majd LINQ-val distinctelném a két listát, és képezném az uniójukat. Ha az unio két elemű, akkor mehet az összeadás. Bár jobban belegondolva a megoldásom azokra a speciális esetekre nem lenne jó, amikor mindkét szám ugyanaz, és mindkét szám kizárólag ugyanabból az egy számjegyből áll pl. 111 vs 111
De ezt a speciális esetet akár egy szimpla if is el tudja dönteniAz biztos, hogy futásidőben ez lesz a legrosszabb megoldás, de összesen 6 darab számjegyről beszélünk, és egy egy soros megoldásról.
-
martonx
veterán
válasz
sztanozs
#5997
üzenetére
Meg win8.1 Home-nál nálam. Vicces, hogy MS közvetve szinte könyörög azért, hogy ugyan fejlesszenek már a népek wp-re is, miközben a szoftveres (intel esetében még a hardveres) requirement-ek megléte sem triviális a tömegeknél.
Sőt az is érdekes, hogy céges gépen viszont megvan a win8.1 Prof, ott meg az Intel i7-esnél valahogy a hyper-v-n vérzik el a dolog. Nyilván csak valamit be kellene valahol kapcsolni, de a francnak van kedve ezért biost, meg ki tudja mi mindent bogarászni.
Idióták. -
martonx
veterán
válasz
sztanozs
#5994
üzenetére
Gyakorlatilag a Professional-t ideadják ingyen kb. bárkinek. Ami az 1-2 kötelező pluginnel kiegészítve brutálisan hatékony fejlesztést tud eredményezni. Ráadásul egyre szélesebb platformra.
Már csak azt kellene elérni, hogy a mobil emulátorok ne hyper-v-n fussanak, mert így viszont még mindig kell alá a win8.1 Professional, ami még mindig tömegeket tart vissza pont mondjuk a windows phone fejlesztéstől. -
martonx
veterán
Most lusta vagyok a dokumentációját helyetted átnyálazni, de érzésre ez ugyanúgy működik mint az amazon-os megfelelője, azaz:
X időig tartja magában az eventeket, utána azok mennek a lecsóba
Az X idő alatt csak olvasni tudod őket, viszont azt meg tudod mondani, hogy honnantól akarod kezdeni az olvasást. Azaz csinálsz egy service-t, ami szépen olvasgatja az eventeket, és magadnak kell jegyezned, hogy a service hol is tartott az olvasásban. -
martonx
veterán
válasz
Goose-T
#5865
üzenetére
Illetve ehhez tenném még hozzá, hogy rengetegen képtelenek az EF-et optimálisan használni. Mondok pár példát, nem neked címezve, de a te hsz-edhez kiegészítve:
1. db.savechanges-t foreach-en belül rengetegszer látom, miközben a foreach végén egy kötegben kiadott db.savechanges pont ugyanúgy mind az X ezer insert-et elvégezné, csak éppen jóval hatékonyabban, mint tízezerszer szólni az SQL-nek, hogy insertálj egy sort. Ez pláne távoli felhős SQL-ek esetében pár nagyságrendet tud rajtunk gyorsítani.
2. pont a nagy tranzakciószámokhoz lett kitalálva a Configuration.ValidateOnSaveEnabled = false kapcsoló, amivel a csomó EF-es belső validációt ki lehet iktatni töredékére csökkentve ezzel az EF-es overhead-et.
3. Configuration.AutoDetectChangesEnabled = false is egy hasznos kapcsoló külső adatok db importja esetén. Minél több az importálandó adat, annál hasznosabb.Persze a legjobb a Bulk Insert, csak van amikor ez betegesen le van korlátozva, illetve egyszerűen a fenti pontok ismeretében az EF-es insertelgetést is lehet ésszel csinálni.
-
#5787
martonx
veterán
leximester
#5786
martonx
veterán
válasz
leximester
#5786
üzenetére
Egyrészt Azure lehet a megoldás, másrészt bármilyen hoszting cég, ahol foglalkoznak ASP.NET-tel. Erre egy magyar példa, ahol segítőkészek is: https://asphostpage.com/
-
#5785
martonx
veterán
leximester
#5784
martonx
veterán
válasz
leximester
#5784
üzenetére
Hogy jobb-e? Erre találták ki, erre való. A WCF meg egy böszme nagy nehéz(kes) SOAP kliens (na jó, ennél azért sokkal többet tud, nem csak SOAP-ot).
Ha most ismerkedsz ezzel az egésszel, akkor gyorsan felejtsd el kb. azt is, hogy a WCF létezik, és nagyon hirtelen állj át az ASP.NET WEB API-s irányra.
-
#5783
martonx
veterán
leximester
#5782
martonx
veterán
válasz
leximester
#5782
üzenetére
Tudom, ez nem segít rajtad, de ha javasolhatom, kukázd az egész WCF vonalat, és csináld meg ugyanazt ASP.NET Web API-val.
-
martonx
veterán
-
martonx
veterán
válasz
MATEO6600
#5400
üzenetére
Nekem volt szerencsém korrepetálni középiskolás szerencsétleneket.
Szvsz ezt az egész programozós érettségizős dolgot a tömegeknek nem kellene erőltetni. Sokan kitalálják, hogy ha már úgyis egész nam fb-znek a mobiljukon, meg tök jól eljátszanak a tabletjeiken, akkor ők máris programozók lesznek. Aztán az első tömb bejerásnál for ciklusnál megáll a tudomány, és a delikvensek jelentős százaléka (a kis merítésű mintavételem alapján ez olyan 80%) erről a szintről soha a büdős életben nem fog tudni feljebb jutni.Azaz én az arra alkalmatlanokat (80%) kapásból kiszórnám az első felév végén. A többiekkel meg hagy haladjunk négyszer olyan tempóban, hagy oldjunk meg érdekes feladatokat, ne az unalmas sorbarendezésekkel töltsünk el egy félévet.
Persze ez amit mondtam a komplett közoktatásunkra igaz, ha egyszer valaki discalculusban szenved (ez eleve mekkora kamu már, buták mindig is voltak és lesznek), azért még nem kötelező neki matekból érettségiznie, és mindenféle felmentést kapnia (matek, fizika, kémia). Egyáltalán mostanra sikerült az érettségit a vicc szintjére süllyeszteni.
-
martonx
veterán
Ez esetben sok lehetőséged van. Van egyszer a beagle bord - szerver közötti adatút. És van a szerver - kliens közötti adatút.
Ezeket akár külön is bonthatod, hogy mondjuk a beagle Web API-n keresztül küldi az infót (C++-ból ez tűnik a legkézenfekvőbbnek), majd a szerver duplex WCF-en keresztül továbblöki a kliens felé (ez a része ha jól sejtem kész is van). A szerveren meg a Web API fogja meghívni a WCF-et (itt már C#-on belül vagyunk, ez egy triviális művelet).
Vagy mindent egyben kezelsz, és a szerveren egy szál Web API - SignalR kombó intézi az egészet akár egy szál konzol alkalmazásból / windows service-ből futtatva.
Az utóbbi megoldás sokkal szebb, az előbbi megoldáshoz meg sok komponensed már készen van, neked kell dönteni. És persze még biztos van kismillió megoldási lehetőség, én ez a kettő között ingadoznék.
-
martonx
veterán
Kettő dolog.
1. megint csak arról írtál, hogy eljutnak az adatok a szerverig, és ennek értelmében nem kell duplex kommunikációs, se signalr. Ez így igaz? A szerveren megállnak az adatok, és mindenki happy, vagy a server elkezdi a bejött adatokat "szórni" valamerre?
2. "egy biztos SignalR kizárva, mert NEM böngészőbe kell, hogy fusson" - félre ne érts, nekem teljesen mindegy mivel oldjátok meg, csak nem szeretném, hogy butaság hangozzon el a topikban, és esetleg ez másokat félrevezessen. A SignalR abszolút nincs böngészőhöz kötve! Mondhatni semmi köze hozzá, maximum annyi, hogy mára a legjellemzőbb, hogy minden böngészőben fut, ergo ott használják leggyakrabban. Illetve http web socket-tel kommunikál, de ez ne tévesszen meg.
-
martonx
veterán
Igen, az elején úgy indította ubid, hogy ez kell neki.
Aztán most leírva a végső megvalósítást, abból nekem úgy tűnik, hogy minek ide duplex működés?
És ha mégis, akkor SignalR + web API párossal szvsz egyszerűbben együtt tud működni egy C++ kliens, mint WSDL-ekkel nyűglődni.
Mivel a konkrét problémát még mindig csak több vázlatos hsz-ből ismerjük, én csak találgatok. A linuxos C++ vonal miatt az biztos, hogy kerülném a WCF-et, mint ördög a tömjén füstöt. -
-
-
martonx
veterán
Igen, sokfelé el lehet indulni C++-al is, csak amennyire felületesen ránéztem, akár csak egy gSOAP-ot beindítani (majd buzgón reménykedni, hogy kompatilis lesz a WCF WSDL-jével), egy nagyságrenddel nagyobb melónak tűnt, mint akár csak sima C-ben elküldeni egy http hívást a megfelelő json-nal.
Ha meg már C#-al dobták össze a WCF-et és C++-ból kellene használni, akkor jó eséllyel lehet, hogy kevesebb erőforrás a WCF-et átírni ASP.NET Web API-ra, mint C++-ból elkezdeni SOAP-ozni.De lehet, hogy csak én utálom túlságosan a SOAP-ot (mindig csak szívni tudtam vele, kivéve a C# - C# felállást, de ez most nem az). ubid hsz-éből meg az jött le, hogy azért lett WCF, mert csak (a másodpercenkénti 60 request feldolgozását nem értékelem érvnek, a szűk keresztmetszet úgyis az adatbázis lesz), meg eddig C# - C# esetben csak bedobott egy referenciát egy varázslóba, és már használta is. Na, ez most nem így lesz.
-
-
martonx
veterán
válasz
moseras
#5307
üzenetére
Nem feltétlenül hiba ez. Az await ctx.SaveChangesAsync(); és az await Task.Delay(4000) simán eltérhet viselkedésben ennyire egymástól, az async await közel sem csak annyit csinál, hogy egy Task-ba burkolva hívja meg a kért függvényt.
Illetve az await pont azt mondja meg a kódnak, hogy várja be az adott aszinkron futó kódrésznek az eredményét, és emiatt működjön úgy mintha az egy szinkron hívás lett volna.
-
#5282
martonx
veterán
trisztan94
#5281
martonx
veterán
válasz
trisztan94
#5281
üzenetére
Figyi, ezt szépen nem lehet megoldani. A szervertől adat lekérésnek kellene olyannak lennie, hogy egy nagyobb json struktúrában küldje le az adatokat, ráadásul ne kelljen 12 queryt-t futtatni ehhez. Adj ide mindent, és kész. Maximum pár szűrő feltételt küldesz. Ez így végtelenül szarul lett megoldva.
Onnan kezdve, hogy a szerver oldal nem így működik, te már csak szarból tudsz várat építeni, és az sehogy sem lesz szép, és jó. -
#5279
martonx
veterán
trisztan94
#5276
martonx
veterán
válasz
trisztan94
#5276
üzenetére
A kedvedért kipróbáltam. Nem teljesen jól írtam. Szóval a pontos process:
1. Fogod ezt a példa json-t, vágólapra teszed:
{
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}2. Majd fogsz egy bármilyen .cs file-t, mondjuk model.cs és Paste Special-lal beilleszted Json as Class-t választva.
3. VoliáAz ismertetett módszer egyébként XML-lel is működik.
-
#5275
martonx
veterán
trisztan94
#5274
martonx
veterán
válasz
trisztan94
#5274
üzenetére
Ez a DeserializeObject<dynamic> felejtős. Fix struktúrájú Json-t .Net-tel az alábbi módon illik parseolni:
1. létrehozol egy model-t a Json-nak. Ilyet a VS2013 már tud out of the box. Bemásolod valahova a Json-t, kijelölöd az egészt, jobb gomb, majd franc se tudja melyik menü melyik pontja, és már meg is kaptad a Json-nak megfelelő class-t.
2. Ezután használod a DeserializeObject<generáltobjektum> és örülsz. -
#5265
martonx
veterán
trisztan94
#5263
martonx
veterán
válasz
trisztan94
#5263
üzenetére
Az egyik ismert táblán futtatsz egy select top 1 * from ize-t. Ez mondjuk nem szép megoldás.
MSSQL-lel lehet csekkelni az egyes SQL elemek meglétét, nem tudom, hogy ilyen ellenőrzéseket tud-e az SQLite, a helyedben megnézném a dokumentációját.
-
#5264
martonx
veterán
trisztan94
#5262
martonx
veterán
válasz
trisztan94
#5262
üzenetére
ok, csak akkor az egyszerű embereknek ne olyan szavakkal vagdalkozz, hogy REST API, mert attól falnak mennek. Csak annyit mondj nekik, hogy a szerver oldalt nem ártana normálisra megcsinálni. Na persze ha ez eddig jó volt droidhoz, meg ios-hez, akkor most nem a te kedvedért fognak ezen változtatni.
-
martonx
veterán
Persze az nyilván beteg, hogy a POST paraméter egy komplett SQL query-t kell küldeni.
Csak azt jeleztem, hogy önmagában nem attól lesz jó egy megoldás, hogy egy komplett RESTful API-t kerítünk. Egy normálisan megoldott PHP /akármi fogadó a POST oldalon is teljesen jó tud lenni.
Azaz én az elvre mondtam, hogy azzal elvi szinten nincs gond. Sőt ha ezt vesszük RESTful API-t is meg lehet szarul oldani. -
#5258
martonx
veterán
trisztan94
#5257
martonx
veterán
válasz
trisztan94
#5257
üzenetére
Csöndben jegyzem meg, szerinted egy RESTful API mit csinál? Valami csodát? Mert az is a kapott megfelelően felparaméterezett POST, GET, PUT, DELETE http hívások alapján Json-nal (xml-lel, odata-val, whatever) kommunikál a külvilággal.
És miért ne tudna már WP is pont így kommunikálni a szerver oldallal?
-
-
martonx
veterán
Én így 2014-ben akkor már inkább egy asp.net web api-t javasolnék. Ennek a meghívásához aztán biztos nem fog kelleni semmilyen extra class library.
"Nekem pedig az kéne, hogy a WCF küldje folyamatosan az adatokat." - ezt kicsit részletezhetnéd. Oké, hogy nincs gombnyomás, de valami azért csak indukálná az adat küldéseket nem? Egy esemény, egy adat megváltozása valahol... Ha már Web API, akkor mondjuk SignalR-rel elég szépen le lehet kezelni ezeket az értesítéseket.
-
martonx
veterán
válasz
zsolt13
#5149
üzenetére
Pedig a neten vannak ezekhez teljesen jó leírások. Joker DI-ra már javasolt is pár megoldást (Unity, NInject, Autofac ...). Bármelyiket beüzemelni nem nagy ügy.
Viszont előbb a DB repository-dat csináld meg, és majd azt használd DI-al. Ehhez semmi extra nem kell, pusztán kód szervezés kérdése. Csinálsz egy plusz réteget a DB réteg fölé. Ehhez is rengeteg magyarázó anyag van a neten. -
martonx
veterán
Hát most erre mit mondjunk? Valószínűleg nem lesz gond, de bármi előfordulhat. Na, ki lettél segítve?
Egyébként rémlik, hogy a VS2013 már tud olyat, hogy nem akarja automatikusan új verzióra migrálni az adott solution-t, pont az esetleges kompatibilitási problémák megelőzés érdekében.
Azaz ELMÉLETILEG semmi problémát nem kellene tapasztalnod. -
martonx
veterán
Akkor pár gyors kérdés:
Az megvan, hogy ez egy C# topik, és hogy mi az a C#, illetve ugye nem téveszted össze C-vel, C++-al?
Ennek megfelelően gondolom Visual Studio valamelyik új verzióját ugye telepítetted már?
Azért valamilyen könyvet biztos csak olvastál már C# témában, ugye?
Konkrétan addig eljutottál-e már, hogy legalább megpróbáltad megoldani a problémát?Bocsánat, ezek nem hülyének nézős kérdések, csak semmi nem derült ki a hsz-edből, és gondoltam a kötelező köröket tudjuk le gyorsan
Ha bármelyik kérdésre NEM a válaszod, akkor javaslom előbb tájékozódni, és csak utána kérdezni.Egy példakódot jó lenne látni tőled, hogy mégis meddig jutottál, hol akadtál meg. Mondjuk ide tedd be, amit eddig csináltál: http://csharpfiddle.com/
-
#4933
martonx
veterán
trisztan94
#4932
martonx
veterán
válasz
trisztan94
#4932
üzenetére
Plusz, ha jól rémlik az ingyenes Express VS változatokhoz nem lehet MySQL-t telepíteni. Legalábbis régen, VS 2010 környékén még így volt. Azóta meg nem próbáltam.
-
martonx
veterán
A Notepad++-os linkelt bővítmény C# scriptekhez való, nem pedig komplett C# alkalmazásokhoz (beleértve a konzol alkalmazást is). A gyerek tényleg el lehet varázsolva, ha szeptember óta C#-oznak, és azt nem sikerült felfognia, hogy milyen programot használnak az órán
Több ingyenes C# alternatíva is létezik, a Visual Studio Express-ek is ingyenesek, gyáriak, de van még MonoDevelop (ez fut linuxon, OSX-en is), SharpDevelop (ez csak windows-os, viszont minimális erőforrásigényű, bár a tudása is kb. ehhez mért).
-
#4833
martonx
veterán
trisztan94
#4831
martonx
veterán
válasz
trisztan94
#4831
üzenetére
Olvasd el a 4822-es hsz-t.
-
martonx
veterán
válasz
MrSealRD
#4828
üzenetére
Elvileg akárhány gépről debugolhatod, ha mindegyiknél sikeresen bejelentkeztél Azure-ba, feltetted az SDK-t. Viszont egyszerre (egy időben) csak 1 gép kapcsolódhat a debuggerhez.
Azt se felejtsd el, hogy a Remote debugging csak 48 óráig él, lehet időközben lejárt ez az időszak? -
#4601
martonx
veterán
trisztan94
#4600
martonx
veterán
válasz
trisztan94
#4600
üzenetére
MS bénázik rendesen.
-
martonx
veterán
válasz
Taoharcos
#4569
üzenetére
Nem tudom, nekem a Reiter István könyv teljesen elégnek tűnt. Akkor meg minek olvassam el angolul is ugyanazt?
Nyilván lehetne egyébként a Reiter könyvnél komolyabbakat is találni, de javaslom először nézd át azt, aztán ha hiány érzeted marad, esetleg már achitekt szinten, a mikro optimalizációkra fekszel rá, illetve a minél absztraktabb desing patternek a kedveinceid, akkor majd utána nézel guglin, vagy keresel mélyebb merítésű könyvet. -
martonx
veterán
válasz
Taoharcos
#4566
üzenetére
A két nyelv szintaktikája, filozófiája hasonló szvsz a C#-é letisztultabb (de ezek szubjektív szempontok voltak). A C# ugyan fiatalabb, mint a Java, mégis mostanra jóval fejlettebb.
Ez már csak saját tapasztalat, és bőven lehet vele vitázni, de a C# erőforrás kímélőbb is, kevesebb memória használatával, alacsonyabb proci teljesítménnyel oldja meg ugyanazt a feladatot.
A Visual Studio (még az ingyenes Express is) pedig szerintem az egyik, ha nem a legfejlettedd IDE. Legalábbis Netbeans, Eclipse-el összevetve olyan mintha egy Opelből átülnél egy Mercedesbe. A komolyabb fizetős Java IDE-kről nincs tapasztalatom, lehet azok is hozzák a VS szintjét?
Mostanra a Mono révén a C# ráadásul egyre cross-platformosodik, Linux-on és OSX-en is lehet fejleszteni, futtatni. Sőt Android-on és IOS-en is, bár az ezekhez való külön licenszek a MonoTouch esetében szvsz erősen túlárazottak, viszont simán el tudom képzelni, hogy komolyabb projektnél megérik az árukat.
Összegezve viszont ezek nem akkora előnyök, hogy mondjuk csak ezek miatt az ember nyelvet, fejlesztői platformot váltson. Másrészt, ha eleged van az open-source instant út keresésekből, Linux-os szopásokból, folyamatos kísérletezésekből álló fejlesztésből, és sosem tudsz szívből örülni annak, hogy kijött az új java/tomcat/akármi, mert fog-e vele az eddigi kódom működni, akkor mindenképpen javaslom a .Net-es világot.Nem csak VS-el lehet C#-ot fejleszteni, de miért szivatnád magad mással, hacsak nem Linux-on vagy OSX-en akarsz C#-ozni. VS-nek van ingyenes változata, kezdetnek teljesen megfelel, de ne lepődj meg azon, ha belefutsz a korlátaiba (pl. Oracle DB-t nem fogsz tudni vele használni, ami Java-s világból érkezvén gondot jelenthet).
VS alternatíva a SharpDevelop (ez is csak Windows-on fut), illetve a MonoDevelop (ez windows-on, Linux-on és OSX-en is telepíthető).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
használj Azure-t.
, de azért jóval kevesebb a buktató, mint vastag klienseknél.
Ú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!
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Így VERNEK ÁT a KAMU webshopok!
- AMD Navi Radeon™ RX 9xxx sorozat
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Xiaomi 14T Pro - teljes a család?
- Sweet.tv - internetes TV
- Luck Dragon: Asszociációs játék. :)
- Plazma TV topic
- Könyvajánló
- Star Trek
- További aktív témák...
- Apple iPhone 14 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÚJ Asus TUF Gaming F17 FX707 - 17.3"FHD IPS 144Hz - i7-13620H - 16GB - 1TB - RTX 4060 -3 év garancia
- LG K61 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 13 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3056, 94% Akkumulátor
- Xiaomi Redmi Note 11 Pro+ 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest