Új hozzászólás Aktív témák
-
leslie23
tag
köszönöm a válaszokat urak, jó látni a különböző álláspontokat!
sztanozs: igen, három szintű user matrixot szeretnék.
egyébként nem tudom, hogy van-e erre vonatkozó előírás, gyanítom, hogy nem igazán fejleszt bárki is a saját részlegének. teljesen megértem, hogy IT-s szemmel ez nem túl szimpatikus projekt. de valóban arról van szó, hogy egy 2500+ alkalmazottal rendelkelő cég durván 30 dolgozójának lenne szüksége egy egyéni megoldásra. szinte elképzelhetetlennek tartom, hogy erre időt és pénzt biztosítson a vállalat, így maradnak a saját kis garázsprojektek, az IT-t félig-meddig kihagyva a buliból. nyilván ezzel kapcsolatban senki nem fog a helpdesknek telefonálni. a meglévő intranetes webappok is hemzsegnek a bugoktól, szerintem ilyen minor dolgokra abszolút nincsen kapacitás, sajnos!hogy máshol ez hogyan működik, azt nem tudom, de én csupa negatív tapasztalattal találkoztam eddig az ismerősi körben hasonló kérdések esetén.
-
joysefke
veterán
válasz
martonx #8895 üzenetére
Úgy hogy már mindenki a böngészőből elérhető adatokhoz -kivéve office- szokott, kissé ósdinak tűnik egy weblink helyett egy file store elérést megosztani egy futtathatóhoz, ami nyilván minden alkalommal szépen letöltődik a user gépére hogy azon elinduljon.
Ha ezen túllépünk, akkor most hogy a Core framework új 3. verziójával elérhető lesz a self contained opció illetve jelentősen visszanyesik a self contained package méretét illetve a Core 3 már támogatni fogja a Windows desktop appokat, végül is nem olyan elvetemült opció ez:
Egy pár 10MB-os self contained app aminek nincsen dependenciája a futtató gépre installált .NET környezet felé az kb nem romlik el míg világ a világ, míg a másik oldalon a böngészők is változnak ez pedig elronthatja a felhasználói élményt.
-
Ablakos
őstag
Hogyan lehet megállapítani két consol-os alkalmazás közül melyik .net framework illetve .net core keretben lett fordítva?
-
leslie23
tag
Értem ám amit mondotok, nekem is szimpatikus egyébként a webes megoldás, annál is inkább, hogy frontend terepen szívesen ügyködök, legalább egy ilyen része is lenne akkor a projektnek.
Viszont! Feltételezem, hogy ehhez szervergépre lenne szükségem, amin fut az IIS és itt válik neccessé a dolog. Nagyvállalatnál dolgozom, de max. 25-30 ember használná az alkalmazást, és bizony előny, ha nem kell az IT-vel köröket futni és sírni, hogy biztosítsanak nekünk infrastruktúrát. Nincsenek a helyzet magaslatán és nem is vagyok benne biztos, hogy erre lenne lehetőség. Vannak belső webes megoldások, de azok döntően JSP alapúak.
A napi munkában használt szoftvereink szinte mint .NET-ben lettek írva, mondjuk nem tudom, hogy az egyes verziók közötti kompatibilitás az mennyire megoldott a keretrendszeren beül...
Szóval mindezek figyelembevételével tűnt előnyös megoldásnak a közös meghajtón megtalálható "portable" .exe + db fájl, de persze az is lehet, hogy rosszul gondolom és pikk-pakk el lehetne intézni szerver dolgot... -
martonx
veterán
válasz
leslie23 #8887 üzenetére
Igaziból addig nem érzed a fájó különbséget, amíg többször bele nem futsz abba, hogy a telepített .net egyáltalán nem evidencia (vagy elég ha csak verziók térnek el), vagy ugyanígy kézzel frissítgetni a programodat a gépeken se feltétlenül triviális (egyik kolléga elvitte a notebookját, mire visszajön, meg már ki emlékszik rá) stb...
Nem véletlenül ment el a világ a web / mobil appok irányába a klasszikus telepítgetős programok helyett. -
leslie23
tag
válasz
martonx #8882 üzenetére
Köszönöm a válaszokat!
(#8880) Keem1: rendben, ránézek!
(#8882) martonx: okés, akkor első körben marad a fix struktúra.
A telepítés dologgal kapcsolatban lehet van némi zavar nálam... Ha nem tévedek, akkor a VS-ban készített exe-ket simán tudom futtatni telepítés nélkül is. Maga az app és a db is egy hálózati meghajtón lenne, amit a felhasználók a saját irodai PC-jükön megnyitnának. A .NET valamennyi gépen telepítve van.
Vagy ez nem ilyen egyszerűen megoldható? -
Keem1
veterán
válasz
leslie23 #8872 üzenetére
Az SQLite jó, könnyen kezelhető, könnyen elsajátítható, baromi gyors és könnyen egy akár meglévő programhoz is hozzákapcsolható. Én sokat használom, főleg olyan esetben, amikor sok és/vagy különböző módon elért/lekérdezett és/vagy gyorsan több adatot kezelő applikációról van szó.
Fontos! Az SQLite nem többfelhasználós. 1 app = 1 db (nyilván ez áthidalható, de akkor sem baba)! Ha ez nem hátrány, használd nyugodtan, mert szeretnivaló DBMS. -
leslie23
tag
válasz
martonx #8873 üzenetére
Köszönöm a válaszod!
Az a helyzet, hogy a NoSQL-ről jóformán semmit nem tudok, így egyelőre maradnék RDBMS-vonalon, ha másképp nem érdemes, akkor rögzített táblastruktúrával. Első körben ez megteszi, most egyelőre a C#/.NET tanulás részén szeretném, hogy maradjon a hangsúly.
Windows Forms Application vs. ASP.net szempontból miért lenne nagyobb előrelépés a webes megoldás? Nyilván böngészőben sokkal szebb felületet tudnék összerakni, de úgy sejtem, hogy te nem erre gondolsz... -
Alexios
veterán
válasz
alapz@j #8874 üzenetére
A nyelvet tényleg, de azért általában valamilyen frameworkön belül szokták ezt használni, aminek megvannak a saját tooljai, stb, frameworktől függ mennyire jó a doksija, supportja, akármi, szóval azért nem teljesen lényegtelen.
De amúgy tény, hogy simán lehet váltani, ha az ember szeretne
-
leslie23
tag
Sziasztok, egy félig-meddig elméleti jellegű kérdésem lenne.
Abszolút új vagyok C#-ban, éppen saját, megvalósítandó projektek után kutakodok. Ki is néztem egy lehetőséget, a munkahelyen van egy nyilvántartásra szolgáló Excel, néhány VBA-makróval. Jópár évvel ezelőtt készítették, szerintem már a koncepció is hibás volt, azóta meg rengeteg új igény is felbukkant és általában én kapom azt a hálás feladatot, hogy toldozzam-foldozzam a fájlt és a makrókat.
Arra gondoltam, hogy érdemesebb lenne áttérni egy SQLite, vagy akár Access alapú megoldásra, amihez késztítenék .Net-ben egy szimpla GUI-t.Amire viszont igény lenne, hogy mondjuk egy emelt jogosultsági szintű felhasználó, bejelentkezés után tudjon új mezőket (oszlopokat) bevinni a fő, nyilvántartott egységeket listázó táblába. Természetesen korlátozott számban és lehetőségekkel, én úgy képzelem el, hogy választhatna egy legördülőből, hogy string/int/enum/date legyen a data type, ezzel nagyjából valamennyi későbbi igény fedhető lenne.
Persze az új rekordok bevitelére is lenne egy userform, amin minden egyes mezőhöz tartozna egy control. Ha viszont az admin hozzáad egy Date típusú mezőt a táblához, akkor nekem arra lenne szükségem, hogy az új rekord bevitelére szolgáló userformon dinamikusan generáljak hozzá egy DatePickert, vagy pl. egy Enum típusú oszlopnál egy dropdown-t, a lehetséges értékekkel.
A kérdésem voltaképpen arra vonatkozna, hogy egyáltalán életképes-e egy ilyen koncepció (dinamikusan bővíthető/szűkíthető tábla) és ezt a GUI szintjén meg tudom-e oldani tisztességesen? Vagy az egész elképzelés felejtős és úgy érdemes nekiállni az ilyesminek, hogy egy átgondolt, fix, rögzített adatbázis struktúra legyen a GUI mögött?
Előre is köszönöm a válaszokat!
-
Ablakos
őstag
Az Mesbox string paramétert hogy lehet ToString fv-el konvertálni? Valamilyen zárójeles varázslat
MessageBox.Show(new IntExtension().Half(number));
Csak ez a konvertálási lehetőség érdekel, ha lehetséges.
-
joysefke
veterán
A poén az hogy mégis működik, kipróbáltam.
Lehet hogy a bejegyzés óta eltelt majd két évben meggondolták magukat...
Sőt, egyelőre jobban működik mint a Choose/When -féle megoldás, mert ott a package upgrade csak a csomaghoz tartozó legelső verziószám bejegyzést módosítja, míg a másikban az egyetlen verziószám-bejegyzés szépen módosul.
-
dqdb
nagyúr
válasz
joysefke #8867 üzenetére
Nem érdemes próbálkozni, a linkelt issue alapján nem működik az én megoldásom, csak az általad talált workaround.
Mindig "élmény" olvasni a NuGet fejlesztőcsapat arrogáns hozzáállását a bejelentett problémákra és szívni, amikor valamilyen újításuktól eltörik a build folyamat
-
joysefke
veterán
Köszi a tippet!
Lehet kipróbálom ezt is, de amikor keresgéltem, ráakadtam erre:
https://github.com/NuGet/Home/issues/5895itt meg azt írták, nem fogják megoldani, aztán valahol a hozzászólások között találtam azt a megoldást amit feljebb írtam is!
-
dqdb
nagyúr
válasz
joysefke #8865 üzenetére
<PackageReference Include="YoutubeExplode" Version="4.7.9" Condition=" '$(Configuration)' != 'GooglePlayRelease' and '$(Configuration)' != 'GooglePlayDebug' "/>
Így egyszerűbb, nem kell a
Choose
blokk, elég az eredetiPackageReference
elemet módosítani. Csomagfrissítésnél nézz majd rá a .csproj fájlra, megmaradt-e a feltétel benne. -
joysefke
veterán
válasz
joysefke #8864 üzenetére
Lehet megoldódott
Úgy tűnik, csak le kell írni egy problémát és az jó eséllyel megoldódik, mielőtt jönne az első hsz. Egy csomót próbálkoztam VS-ben az ilyen olyan Android kapcsolókkal (amelyek ki tudja mit csinálnak), ehhez képest a megoldás igen kézzelfekvő:
1,
Minden kód ami a kérdéses komponensben van#if !GOOGLEPLAY
...
#endifközé került. Ezzel a GOOGLEPLAY szimbólumot tartalmazó build konfigok esetében semmilyen aktív kód nincsen ami használná a YoutubeExplode csomagot.
2,
Mivel a YoutubeExplode csomag bizonyos buildek esetében nincsen használatban, ezért el is lehet távolítani a csomag-referenciát, ehhez a .csproj fájlban a Choose/When/Otherwise konstrukciót lehet használni. Alább látszik, hogy a kettő Gplay-es konfigban (GooglePlayRelease és GooglePlayDebug) nincsen referencia a YoutubeExplode NuGet csomagra, a többi nem GPlay-es konfigban viszont lesz..És ez így fordul szépen, és ha ILspy-jal belenéze, tökéletesen semmi nyomát nem látom a YoutubeExplode-nak...
<Choose>
<When Condition=" '$(Configuration)'=='GooglePlayRelease' ">
<ItemGroup>
...
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='GooglePlayDebug' ">
<ItemGroup>
...
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
...
<PackageReference Include="YoutubeExplode" Version="4.7.9" />
</ItemGroup>
</Otherwise>
</Choose> -
joysefke
veterán
Xamarin.Forms - GooglePlay
Help kéne, sok időt beleöltem, nem boldogulok...
-(0)
Van egy Xamarin.Forms(Android) hobbiprojektem. Ez a projekt tartalmaz egy általam írt komponenst "YtExplodeVideoService" néven amely a YoutubeExplode nevű 3rd party NuGet parser libre épít. A YoutubeExplode működése okán nem GPlay policy kompatibilis, ennek megfelelően a "YtExplodeVideoService" komponens sem az.A XF projekt shared része egyetlen projektben, egyetlen assembyben van, ez tartalmazza az általam írt kód 99%-át.
Eddig minden szép és jó és működik is.
Most szeretném, ha fel tudnám rakni az appot a GPlay-re is, anélkül, hogy terminálnának engem, a családomat, a macskámat meg úgy mindenkit akihez közöm van.
Amit eddig csináltam:
-(1)
A "YtExplodeVideoService" mellé készítettem egy azzal interfész-kompatibilis komponenst "VanillaYtVideoService" néven. Ez megfelel a GPlay feltételeinek, ennek a használatáért nem fognak kivágni.-(2)
Készítettem az eddigi (ad hoc) Release solution-konfiguráció mellé egy GooglePlayRelease solution- konfigurációt. Ahol is a shared project konfigja tartalmaz egy compilation változót, ami megjelöli mint GPlay release.A videokomponens példányosításakor ellenőrzöm a változó értékét és annak függvényében választom ki a konkrét implementációt:
#if GOOGLEPLAY
VideoService = new VanillaYtVideoService(Settings, CachedSearchClient);
#else
VideoService = new YtExplodeVideoService(httpClient, Settings, CachedSearchClient);
#endifEz eddig szépen működik. ILSpy-jal belenézve a különböző build konfigurációkkal készített assemblikbe szépen látszik, hogy mindig a megfelelő komponens példányosodik.
A probléma:
Szeretném elérni, hogy
1, az elkészült GPlay-re szánt APK-ban, semmi esetre se legyen benne a YoutubeExplode.dll assembly, jelenleg, ha az APK-t kizippelem, akkor szépen ott van. Nem értem, hogy mit keres egyáltalán ott...2, A shared projektem assemblyjébe ha ILSpy-jal belenézek, akkor a references listában szépen látom a YoutubeExplode nevet. Ezt sem szeretném.
Szeretném, ha az elkészült projekt-assemblyben majd a végső APK-ban semmiféle ráutaló nyom nem lenne a YoutubeExplode-ra. Nem hiszem, hogy ez nagy kérés lenne, hiszen nem is használom a GPLay-re szánt releaseben.
És szeretnék biztosra menni, minél kevesebb mókolással.
3, Hogyan tudom biztosan ellenőrizni azt ami felkerül, hogy mindenben megfelelő?
Amivel eddig próbálkoztam:
1, A Linking opció Sdk Assemblies Only-ra van állítva. Ha egyel erősebbre rakom, akkor runtime hibáim vannak. (Első körben a Newtonsoft.Json-nal ütközik, de ha ezt kiküszöbölném lenne más)
Ha lehetséges nem bántanám ezt a beállítást, mert nem értek a linker konfigurálásához és félek, hogy olyan helyeken hozna be runtime hibákat, ahol nem is számítok rá.
2,
Játszottam a "Code shrinker" beállításokkal, nincs változás.3,
Próbálkoztam az ingyenes "Dotfuscator Community"-vel. Ez átnevezi a függvények paramétereit, de pld az assembliket magukat nem.4, Nekiálltam a YtExplodeVideoService-t kiszervezni egy külön assemblybe, de ezt elvetettem, ha csak egy mód van rá, nem szeretném szétbarmolni "Az Egy Assemblyt". (eleve legalább három felé kéne essen, ahol a harmadik, közös assemblybe mindenféle interfészeket, modelleket ki kéne szerveznem ÉS a hálózatos kódot)
-
joysefke
veterán
A neve "Named arguments" az utóbbi C# verziók folyamatosan csiszolták, a lényege, hogy már fgv-híváskor nem csak a pozíciója, hanem neve alapján lehet egy paramétert azonosítani.
Hasznos, hogy ha sokelemű a paraméterlista, akkor tudod, hogy mi micsoda, a másik pedig az, hogy át tudod rendezni az argumentumok sorrendjét a deklarációhoz képest.
Szerk: és ahogy feljebb írták, default értékkel rendelkező paraméterek esetén is jól jön.
-
vlevi
nagyúr
válasz
Ablakos #8859 üzenetére
Nem csak itt, de bárhol beírhatod a paramétereket név szerint.
Akkor jó, ha egy metódusnak több paramétere van, esetleg némelyik default értéket tartalmaz, és nem kötelező megadni. Ilyenkor, ha nevesíted a paramétereket, akkor te is jobban átláthatod, hogy melyik paraméternek milyen értéket adtál át. -
Ablakos
őstag
VisS-ban mindig van egy ajánlás, hogy használjam pl. egy WriteLine paraméterben a value: szót a valódi paraméter előtt.
Mi ennek a jelentősége? (hogy használom vagy sem a value:-t) -
martonx
veterán
válasz
DrojDtroll #8852 üzenetére
Használd a Watch window-t, ha csak konkrét értékre vagy kíváncsi.
-
válasz
DrojDtroll #8854 üzenetére
Ott konkrétan be tudod gépenlni és szépen egyesével legetteled az értékeket. Jobb ötletem hirtelen nincsen, vagy 5 éve nem használok már VS-t
-
válasz
DrojDtroll #8852 üzenetére
Csak az értékére lennél kíváncsi? Immediate window?
-
coco2
őstag
válasz
Balcsix #8847 üzenetére
Ha a mai világban általános jelleggel állást keresni akarsz vele, szerintem a c# torony magasan teljesít majd lehetőségekben a c/c++-hez képest. Ami nem azt jelenti, hogy végül nem pont olyan helyen kötsz ki, ahol a c felé irányítanak majd, mert dobhat pont olyat a véletlen, de nem az a jellemzőbb.
-
coco2
őstag
válasz
Balcsix #8843 üzenetére
Régi világ kóderei még basic-el kezdtek, aztán jött a turbo pascal / asm őrület, végül a c/c++ is felütötte fejét. A c# azokhoz képest új keletű dolog, a php és társai meg még újabbak. Hogy a régi kóderek a c-t fogják neked preferálni, az mindössze megszokás kérdése, és csak speciális esetekben célszerűség. Ha olyan üzleti területre kerülsz, ahol a költséghatékony üzemeltetés nevében a torkodat is elvágják, jobban járhatsz c-vel (különben az a vicc, hogy nem mindig, de jellemzően). Viszont a c még egy olyan világ része, amikor minden sokkal spártaibb volt. A mai világban például nincsen többé olyan szakma, hogy "folyamat szervező", ismeretlen a dokumentálás fogalma, meg úgy egyáltalán bármiféle tervezés. A c# néha akkor is megállja a helyét, a c/c++ kevésbé, mert vagy 10x annyi idő volt vele fejleszteni, meg komponenseket írogatni előzetesen legalább egy hét / darab, ha bármi normálisat csinálnál. Utólag az nem lesz probléma, de ha most kezded, sikerélmények helyett csak kudarcokra számíts. Ha nem olyan fejlesztői környezetbe kerültél, ahol direkt azért kapod a fizetésedet, a c/c++-t felejtsd is el. Tekints rá úgy, mint a c# egy elődjére, amit túlhaladott a világ, mert a c# is elég hatékony, és a legtöbb helyről kiszorította amazokat.
-
Keem1
veterán
válasz
Balcsix #8841 üzenetére
Az alapok elsajátítása nem nyelvfüggő. Természetesen arra tökéletes a C, hisz a legtöbb mai, még magasabb szintű nyelvek onnan származnak (C++, Java, C#, PHP, csak hogy a legismertebbeket említsem).
Az algoritmusokat, programozás alapjait, objektumorientált szemléletet akár nyelv nélkül, pszeudo nyelven is meg lehet(ne) tanulni. Minél kevésbé fejlett/komplex nyelven sajátítja el valaki az alapokat, annál kevésbé rögzül benne az adott nyelv specifikussága, hülyeségei, annál könnyebben tanul újabbakat. -
Balcsix
senior tag
Sziasztok!
Olyan kérdéssel fordulnék hozzátok, hogy manapság érdemes-e még C-n kezdeni tanulni programozni vagy teljesen felesleges lépés?
Jelentkeztem egyetemre, és külsős információk szerint 3 évig a C-t tolják, aztán utolsó évben van lehetőség szabadon választott nyelv tanulására (esetemben C#). Már középiskolában elkezdtem a C# nyelvet, és úgy döntöttem, hogy ezt a vonalat viszem végig (ASP.NET és a többi...) viszont így ez a "projekt" bukott. Ma még érdemes az alapokat C-ben tanulni, vagy hasznomra fog még válni a C ha a későbbiekben mindenképp a .NET felé kacsingatok?
A másik egyetemről hallottam ahova még jelentkeztem, hogy ott a kezdetektől C#-ban programoznak.
Neveket nem említenék, de ahol C-n tanítanak ott az országban elég kiemelkedő az informatikai oktatás, míg a másik intézmény meg sem közelíti...Ha a ti kezetekben lenne a döntés, akkor hogy választanátok a 2 egyetem/oktatás között?
-
coco2
őstag
Céges projecteknél, amikor a termék már kint van piacon, nyilván másmilyen állapotok vannak. Például egy kezdeti gyenge design döntés miatt - amit hála az égnek ráerőszakolt a projectre valaki önjelölt "zseni" - utólag nem tehetsz mást, mint lapátolod a sza*t, amíg el nem fogy az ügyfél pénze, és akkor a cég is jóllakott, meg új termék sem került piacra, sikerült két legyet ütni egy csapásra. Elvégre minden élő dolognak táplálkoznia kell - szó nincs róla, hogy azzal vitatkozni akarnék.
Viszont aligha spanyolviasz, hogy kispolcos projectnél nincsenek olyan kötöttségek az elején, és nem kötelező design tévedéseket elkövetni.
-
dqdb
nagyúr
így utólag már mezei file-ok és memória blokkok elegendőek az sql szerver helyett, ami bizony egyszerűbbé teszi a dolgokat - akár hiszed, akár nem.
Tudom, hogy egyszerűbbé tudja tenni a fájlokat használó megoldás az életet, rendszeresen használok ilyet a storage interfész mockolására tesztekben. Persze éles környezetben nem, hiszen a redundancia, rendelkezésre állás kifejezések léteznek, és amíg egy clusterezhető middleware elintézi helyettem az adatok node-ok közötti replikálását, addig egy fájlalapú megoldásnál nekem kellene ezt nulláról lefejleszteni. Nem lehetetlen, csak rettenetesen időigényes, és akármennyi erőforrást is elégetek rá, akármennyi tesztet gyártok hozzá, a saját implementáció kevésbé lesz tesztelve éles szituációban, mint az elterjedt 3rd party megoldások. Vannak esetek, amikor érdemes feltalálni a spanyolviaszt, mert megéri, ez szerintem határozottan nem az.Részemről inkább azt a kérdést tartom nehezen megválaszolhatónak, hogy a c# topikban miért c stuffokat preferálnak a népek?
Én sosem a nyelvhez, hanem mindig feladathoz választok middleware-t, az pedig, hogy miben írták, teljesen irreleváns addig, amíg van hozzá .NET vagy REST API. Így aztán az egyik rendszerünk tipikus telepítése használ Javában, Erlangban és Góban készített middleware-eket (másikban akad Ruby is), miközben a rendszerünk forrása egyetlen sornyi Javát, Erlangot és Gót sem tartalmaz. Nem azért, mert a szivárványos össznyelvi összeborulás volt a cél, hanem azért, mert adott részfeladatra az adott komponenst találtuk a legjobbnak. -
coco2
őstag
Kár, hogy a fél világ ezt nem tudja,
Ha el akarnám viccelni, most azt mondanám, hála az égnek a világnak van egy olyan fele is, amelyik nem ért a programozáshoz. Nélkülük nem lenne, aki fizet érte.Hanem a redisből én akkor sem kérek. Az a része húzós volt, mire a 7 sql táblányi szénaboglyát le tudtam cserélni 8 kbyte-os user profileokra, de így utólag már mezei file-ok és memória blokkok elegendőek az sql szerver helyett, ami bizony egyszerűbbé teszi a dolgokat - akár hiszed, akár nem.
Részemről inkább azt a kérdést tartom nehezen megválaszolhatónak, hogy a c# topikban miért c stuffokat preferálnak a népek?
-
dqdb
nagyúr
Az Iodine támogatja, ezt már sztanozs is jelezte. A másik csak egy egyszerű frontend, elé kell tenni egy rendes webszervert TLS proxynak.
A chrome is, meg a firefox is konkrétan blokkolják, ami nem támogat https-t, legyen az akár csak egy webapi kiszolgáló.
Rossz megközelítés: nem azért kell TLS-t használni, mert a Chrome és a Firefox sír a hiánya miatt, hanem azért, hogy védett legyen a kapcsolat, és ettől mellékesen a Chrome és Firefox boldog lesz. Nem tudom másoknál hogyan van, nálunk már sok-sok éve a fejlesztői rendszerekben is TLS-sel védett minden kapcsolat.könnyű megírni egyébként is
Ja, ha ilyen könnyű összedobni egy skálázható-clusterezhető megoldást, akkor nem szóltam. Kár, hogy a fél világ ezt nem tudja, és Redisre épít, ha cache kell neki. -
coco2
őstag
A memory cache résszel nincsen problémám, azt könnyű megírni egyébként is, a linkelt webes kiszolgálók pedig nem támogatnak tls-t, és anélkül kb használhatatlanok. Már minden https, amit csak weben fellelni lehet. A chrome is, meg a firefox is konkrétan blokkolják, ami nem támogat https-t, legyen az akár csak egy webapi kiszolgáló.
-
coco2
őstag
Részint elkezdheted kotorászni a netet webspider feldolgozók után, amit valaki beállított a tippmix oldalára, és amit összepakolt, az még mindig működik (nem változott az oldal jelentősen). Az említett cuccok minden alkalommal be szoktak krepálni, amikor az oldal a gépi szem számára változik (néhány változást a fogaskerekek mélyén emberi szem észre sem vesz, de a gépi agy elemien annyira ostoba meg kötözködő, hogy megzakkanhat akármilyen apróságtól), és aki csiszolta a stuffot, vagy követi a változásokat, és csiszol újat a népnek jófejségből, vagy nem. Ha találsz valami ingyenes stuffot, a problémád megoldódott. Részemről nincs olyanról tudomásom.
A magam részéről írtam a szerencsejáték zrt-nek egy levelet, hogy biztosat tudjak meg róla, van-e támogatás az oldalon lévő tartalom szoftveresen automatizálható eléréséhez (webapi). Ha pozitív választ küldenek, akkor lehet, hogy stabilabb cuccot is találhatsz a neten, mint webspider scriptek, vagy lehet írni viszonylag költséghatékonyan. Dobj rám egy privit, hogy megmaradjon egy link az elérésedhez, és majd megírom, amit válaszoltak.
-
tazkir
csendes tag
Sziasztok,
nagy valószínűséggel nem jó helyre írok előre is elnézést mindenkitől!
Egy olyan programra lenne szükségem, ami le tud tölteni egy listát ami publikus, de nem egyben jön le, hanem 50 soronként és mindig nyomkodni kell a következő oldalt. Konkrétan a szerencsejáték rt oldaláról kellene nekem a tipppmix lista, de mivel több 10 oldal is lehet ezért elég macerás másolni és úgy betenni xls-be. Nem vagyok programozó, úgyhogy ha esetleg valakinek van ilyen már készen v. le lehet tölteni valahonnan kérlek segítsetek.
köszönöm.
-
coco2
őstag
válasz
martonx #8825 üzenetére
Hát ha fordítva kezdtem el, akkor most fordítva lesz
Azt az asp.net példát természetesen megtaláltam. Nem szimpi. És bevallom töredelmesen, lila halvány lövésem sincs, mi a különbség az asp.net és az asp.net core között. Van valami relevanciája?
A projectet meg szeretném tartani olyan formában, hogy az később konkrét összetevőkre darabolható és darabjaiban újrafejleszthető legyen. Ha valami project generátor szeletelhetetlen control és data flow-t sózna a nyakamba, azt nem fogom szeretni.
A szervereken memory cache fog futni. Ami a stuffot illeti egészben, láttad a facebook filmet? Egy olyan alkalmazás framework-öt akarok gyártani. Kotorásztam utána, de nem találtam facebook-ot a facebook-ban. Csinálnék egyet.
-
martonx
veterán
Szerintem valamit fordítva kezdtél el. Nekem még az se biztos, hogy vágod-e mi a különbség az asp.net core és más asp.net-ek között?
Konzolba kiadsz egy dotnet new web parancsot, majd dotnet run, és már futhat is a load teszt, mókolhatod a kódot, hogy mi hogy legyen optimalizáltabb.
-
coco2
őstag
válasz
sztanozs #8822 üzenetére
Köszönöm a linkeket, de egyenlőre - remélhetőleg - nem fogok relatíve olyan extrém szitukba ütközni, mint a blogok szerzői. Nem azzal az alkalmazás verzióval, aminek az építőköveit most csiszolnám.
Egyenlőre [ilyesmik után kotorászok], és olvasgatok (még ennek is csak az elején járok).
-
coco2
őstag
válasz
sztanozs #8817 üzenetére
Válasz mindkettőtöknek @sztanozs @joysefke
A project célja webes kliensek mögé költséghatékony backend szervert gyártani. A facebooknak köszönhetően sajnos kötelezően https lesz a szerverek domain-jén (a szerver back egy facebook-os alkalmazáshoz kellene), különben a chrome piros ablakokat dobál majd minden alkalommal a felhasználóknak - nem elfogadható marketing veszteség egy új alkalmazás számára.
A javascript topicban rámutattak, hogy a kapcsolatépítés az alaposan számításigényes hátulütője a https használatának (amit le kell nyelni), és kaptam útmutatót is, hogy merre érdemes haladnom. Ha mindig bontogatnom kell a kapcsolatot, a kapcsolat építések elég rendesen enni fogják a szervert, mert apró elemi kommunikációk lennének csak, de abból sokezernyi per szerver per másodperc (per felhasználó maximum 1 per másodperc, de nagyon sok lenne a felhasználó). Akárhány másodpercnyire is tudom egy socket életciklusát kinyújtani, az mind szerver költség spórolás, mert mindegyik kliens várhatóan huzamosabb ideig is kommunikálni fog a szerverrel. Teljesen mindegy nekem, hogy 5 vagy 15 másodperc. Ha akár csak 5 másodperc, már 80% erőforrás spórolás arra a műveletre. Valójában az már elég is ahhoz, hogy érdemes legyen megküzdeni a problémával.
A felhasználást illetően ha valaki ismerkedett már a facebook graph api-jával, nem lesz neki semmi meglepetés, pontosan mit is szeretnék. Https get paraméterekkel, json válasz. Független elemi kommunikációk. Emberi számítás szerint kliens oldalon chrome asztali / mobil böngészőben javascript xhr - és ahhoz kellene szerver framework-öt gyártani. Azon ügyködöm.
Ha van még kérdés, nagyon szívesen megválaszolom, és utána én is örülnék válaszoknak.
-
joysefke
veterán
Nekem úgy tűnik, hogy
1,
te sessionöket és ezen keresztül szerver -> kliens irányú nyitott NAT-portokat akarsz fenntartani, hogy push üzeneteket küldhess (szerver-> kliens).2,
A két szervered közül gondolom az egyik az valami frontend a usereknek, a másik pedig a backend. A FE és a backend között (nyilván?) nem lesz NAT, és a backend szerver bármikor elérhető a frontended számára.Szerintem az 1,-hez valami külön real time framework kéne, ami kezeli a push üzeneteket. Kell legyen ilyen ASP-hez is.
A 2,-es feladat teljesen más, azt nem is mosnám össze az 1,-gyel.
-
sztanozs
veterán
HTTP alapjában véve stateless protokoll, tehát bontja a kapcsolatot. A HTTP1.1 kiegészítéssel lehet sztenderd http keepalive-ot kapni. Viszont (főleg resource és biztonsági okból) a TCP perzisztencia viszonylag rövid idejű - 5-15 másodperc. Épp ezért főként arra használható, amire kitalálták (sok elemből álló weblap betöltése), nem pedig, amire te használni szeretnéd: fél-egy percenként némi adatot átküldeni.
Ennyi ideig nyitva tartani egy tcp portot sokkal erőforrás pazarlóbb, mint lezárni és újra megnyitni. Hagyd, hogy a network stack dolgozzon, nem jó ötlet túl sok portot egyszerre nyitva tartani (főleg akkor nem, ha nincs rajtuk forgalom). -
coco2
őstag
Sziasztok!
Fejtágító után kotorászok.
Asp.net-et kellene nagyon kiberhelnem néhány hasznos tulajdonságáért - ha egyáltalán lehet olyat.
Jelenleg küzdök a [System.Net.HttpListener] class-al, és vesztésre állok abban a csatában, hogy normálisan kellene kezelni keep-alive-ot. Eddig nem találtam rá elfogadható megoldást.
Amire kellene egy web framework:
-bejövő kapcsolatok https get request paraméterekkel, custom text kimenet
-Kimenő kapcsolat https get request paraméterekkel, custom text jön vissza
-Kapcsolatok életben tartása, nyílt véggel azonos jellegű kommunikáció socket végpontok közöttAz asp.net példákat néztem weben, nagyon erősen hajaznak tartalom management-re. Weblapok vannak beépített szinkron feldolgozandó részletekkel - hát nekem semmi olyasmi nem kell. Nekem csak a http réteg kell a saját kezembe.
Ha van róla normális könyv, vagy blog, amiben azt a réteget is leírják, vagy példa project valahol olyan témában, minden infót köszönettel veszek.
-
Keem1
veterán
válasz
Hunter2 #8814 üzenetére
Tudsz, de ezt C-ben írták és nem C#-ban
Bár rég volt már, ehhez szükséged van egy C compilerre, visual studioval nem tudod (egykönnyen) használni, mivel nem VS projekt. Szerintem érdemes lenne C-vel (vagy hardverközeli programozással) foglalkozó topikban megkérdezni, mivel a C# elég erősen magasszintű nyelv, nem szoktak vele mikrokontrollert programozni. -
Hunter2
addikt
Sziasztok, mindenek előtt elmondom hogy nem értek a programozáshoz.
Az lenne a kérdésem hogy ebőől hogy tudok windows alól futattható állományt csinálni? [link] -
user112
senior tag
Sziasztok!
Riportok készítéséhez szeretnék segítséget kérni, lokál táblákból.
Community 2017 + W8.1Pro. Ingyenes és szabadon használható kellene.
Az RDLC Report Designer-rel próbálkoztam, de a Reporting Services Project nem települ, csak a Designer
(The current OS Version '6.3.9600.0' is not in the supported version range '[6.2,6.3)').A Crystal Reports-ot találtam még, ami fel is ment, de nem tudom ez jó e.
Melyik az ajánlott report készítő? -
válasz
DrojDtroll #8807 üzenetére
-
lord.lakli
őstag
válasz
Chesterfield #8808 üzenetére
Ekkor ugye nincs a kapcsolótáblának plusz attribútuma, mint ahogy írta DrojDtroll.
@DrojDtroll: Ha kell a kapcsolótáblán is attribútum, akkor nem úszod meg a külön osztályt. Ekkor a TáblaA 1-* Kapcsolótábla *-1 TáblaB struktúrát kell kialakítani.
-
Chesterfield
őstag
válasz
DrojDtroll #8805 üzenetére
-
martonx
veterán
válasz
DrojDtroll #8805 üzenetére
Nyilván nem, de kismillió dokumentáció, tutorial van hozzá, nagyobb szégyen hülyeséget kérdezni, mint szó nélkül utána olvasni.
-
DrojDtroll
veterán
Sziasztok!
Entity framework-öt akarok használni egy feladatomhoz Code-First megközelítésben. Adott két egyed, amelyek között sok sok kapcsolat van. Hogyan érdemes a két objektumot összekapcsolni? A köztük lévő kapcsolat számos attribútumot tartalmaz. Megoldható a kapcsolás új class létrehozása nélkül?
-
martonx
veterán
Nyilvánvalóan nem a válaszra vagy kíváncsi, hanem a véleményünkre. Akkor tessék:
Ember, te most komolyan elmész egy állásinterjúra, miközben arra nem vagy képes, hogy írott szöveget keress guglin és azt értelmezd?
Másrészt ahova ilyen hozzállással felvennének, oda jobb ha nem is mész. -
Orionk
senior tag
Sziasztok,
C#-ban mi a lényeges különbség a const és Readonly módosítók között.
Junior állásinterjún mi lehet az a lényeges dolog, amit meg kellene említeni/elmagyarázni egy ilyen kérdésnél?köszönöm.
Ú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!
- DELL Universal Dock UD22 210-BEYV (DisplayLink)
- REFURBISHED és ÚJ - HP USB-C Dock G5 docking station (5TW10AA) - 3x4K felbontás, 120Hz képfrissítés
- A tökéletes hűtés éjjel-nappal: ARCTI FREEZER 8A! Most csak 7.500 Ft!
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- LG 42C4 - 42" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest