-
Fototrend
Új hozzászólás Aktív témák
-
spammer
veterán
Ja már értem, a dupla klikkes dolgot javítandó.
Ez addig jó, amíg programkódból áll a hozzászólás, de ha utána akarunk írni még valamit, akkor már nem biztos, hogy kényelmes monospace betűkkel megírni. Illetve bármilyen más szövegrésznél is zavaró lehet, mert nem lehet menet közben kikapcsolni monospace megjelenítést. Szerintem praktikusabb egy toggle megoldás (button, checkbox, akármi).
„A feketébe öltözött ember a sivatagon át menekült, a harcos pedig követte."
-
Des1gnR
őstag
Sziasztok!
Tudtok ajánlani (ha egyáltalán létezik) egy olyan virtuális soros port emulátort aminek megadhatok válasz értékeket? Így tudnám szimulálni, hogy ez nem csak egy port, de azon egy eszköz is. Egyébként az Eltima által készített emulátort feltettem és szépen végzi a dolgát, szóval ha csak egy eszköz emulátort tudtok ajánlani ami tudja a fentieket, az szuper lenne.
Dell G3 3779 || Samsung S23+ || Samsung Watch 5 Pro || Oculus Quest 2 || Creality Ender 3 V2
-
cattus
őstag
Hi!
Hirtelen nem tudok jobb topikot, így itt kérdezem meg: Visual Studio-ban létre lehet hozni UI preseteket? Pl. hogy bizonyos ablakokat kitegyen külön, meg hogy mit hova dokkoljon. Pl. gondolok itt arra, hogy ha megnyitok az UWP projektet, akkor jó lenne egy kattintással beállítani, hogy melyik ablak hol legyen.
Do the thing!
-
Zola007
veterán
Adott az alábbi ASCII kód:
bináris: 0110 0001
('a' betű)A kiemelt/aláhúzott bit az hanyadik bitnek számít, 5. vagy 6.?
[ Szerkesztve ]
Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
cattus
őstag
-
Zola007
veterán
Wikipedian írják, hogy az 5. bitben térnek el a kis és nagybetűk
de szerintem is az a 6.Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
Zola007
veterán
válasz bambano #9859 üzenetére
akkor ez a 6. bit, mert az utolsó a 8. a paritásbit ami mindig 0
ezért utálok netről tanulni, sose tudja az kezdő, hogy mennyi hibát tartalmaz az anyagMʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
akrobet
tag
Sziasztok!
Tanácsot szeretnék kérni egy üzleti szabálymotor (business rule engine) megtervezésével kapcsolatban.
Angol leírás: [link] - szerintem sokkal érthetőbb annak aki tud angolul mint az én alábbi fordításom
A szabálymotor egy rendelés feldolgozó rendszer része lenne, ehhez hasonló funkciókkal:
- ha egy rendelés érkezik egy fizikai termékért, generáljon egy csomagolási szelvényt (packaging slip) a küldéshez
- ha egy rendelésérkezik egy könyvért, hozzon létre egy másolatot a csomagolási szelvényről a jogdíj osztály részére
- ha egy rendelés érkezik egy tagságért, aktiválja a tagságot
- ha egy rendelés érkezik egy tagság előléptetéséért (upgrade) , érvényesítse az előléptetést (apply the upgrade)
- ha egy rendelés érkezik a "Síelni tanulunk" nevű filmért, addjon hozzá egy "Elsősegély" nevű videót a csomagolási szelvényhez.
...
A rendszernek ehhez hasonló szabályok százait kell hogy tudja feldolgozni, és a szabályok folyamatosan bővülnek és változnak a rendszer élettartama alatt.
Tehát a feladat egy olyen rendszer megtervezése ami elég flexibilis hogy kezelni tudja a bonyolult szabályokat, úgy hogy minél kevesebb karbantartást igényeljen a rendszerfejlesztőtől.
A feladatban előírják, hogy az egyszerűséget előnynek tekintik az rendszer architekturában. Tehát bonyolult design patternek használata nélkül, ha nincs létjogosultsága.
A kódnak teszelhetőnek és könnyen olvashatónak kell lenni.
Nah, ez lenne a feladat leírása (fordítása).
Két megoldás között vacilálok, mivel a feladatban (gondolom direkt) nem utaltak rá, hogy pontosan milyen gyakran változnak ezek a szabályok és hogy a rendszer felhasználói (webshop tulaj) tudjanak-e maguk változtatni / hozzáadni új szabályokat.
1. megoldás - lényegében hardcodeolni a szabályokat termék típus szerint
előnyök: nem igényel bonyolult programozási "trükköket" mint reflection, expression trees, stb..
hátrányok: minden szabályvátloztatás programozót igényel és egy új rendszer verzió beüzemelését (deploy)2. megoldás - a szabályok dinamikusan létrehozhatók a felhasználók által, pl definiálva a termék típusát (class name) és paramétereit (property) és a szabályokat adatbázisba menteni, és vizsgálásnál kiolvasni, majd reflectionnel megvizsgálni hogy az adott megrendelés, stb. megfelel-e a szabályoknak és aszerint végrehajtani az utasítást.
előnyök: rugalmas rendszer, a szabályok létrehozása nem igényel programozót
hátrányok: bonyolultabb implementáció, nem túl elegáns kód (reflectionnel), ha megváltozik egy utasítás neve a kódban, az adatbázisban tárolt szabályok nem működnek többéÉn személy szerint a második megoldás felé hajlanék, mert szabályok százainak karbantartása szerintem túl költséges lenne. A problémám csak az hogy sokan írják a reflectionről pl. stackoverflow-n, hogy lassú és nem alkalmazható olyan helyeken ahol utasítások millióit kell végrehajtani.
Valakinek esetleg lenne ötlete/tapasztalata ilyen rendszer fejlesztésével esetleg a két megoldás közül melyik lenne helytállóbb?
Programozási nyelv: C#
Bocsi a hosszú postért, de szerintem szükséges a feladat megérteséhez. Ha furcsa magyar megfogalmazást használok az azért van mert csak angolul tanultam programozást és nem tudom a magyar kifejezéseket.
[ Szerkesztve ]
-
dabadab
titán
válasz akrobet #9862 üzenetére
A feladatot jól megoldani nyilvánvalóan lehetetlen, csak hogy ez tiszta legyen
Nekem úgy tűnik, hogy így elsőre nagyon összekeverednek benned a rétegek, az alapvető rendszerarchitektúránál szinte nem isszámít az, hogy milyen nyelven csinálod az meg, hogy használsz-e reflectiont, az tényleg n+1. implementációs részlet.
Amit én hasonló témakörben láttam és nagyjából működik, az az, hogy az ember egyrészt az objektumoknál valami nagyon rugalmas adatmodellt használ (pl. gyengén típusos kulcs-adat párokat) és a döntéshozó részt kirakja scriptbe (mert az jóval rugalmasabb, mint amit adatbázisban tárolt szabályokkal meg lehet valósítani), így a "rendes" kódhoz csak akkor kell nyúlni, ha új funkcionalitás kell.
"Ha furcsa magyar megfogalmazást használok az azért van mert csak angolul tanultam programozást és nem tudom a magyar kifejezéseket."
Szerintem vagyunk így ezzel még páran
DRM is theft
-
akrobet
tag
válasz dabadab #9863 üzenetére
Hogy lehetetlen jól megoldani, gondolom arra érted, hogy nincs elég információ a rendszer felhasználási mintájáról, adatforgalomról, fejlesztésre rendelkezésre álló időről stb...
Ja, amúgy azt is írják a feladatban, hogy ha a designnak az implementálása túl sok programozást igényelne (több mint 2 óra), akkor elég ha elmagyarázom ami nincs implementálva. -- haha, 2 óra, viccesek mi. És ez unit testtel, működöképesen, bezippelve
A gond ott van, hogy a rendszer achitektúrájáról nem tudok semmit, viszont már adott: "The module will be used within an existing system".
Úgyhogy nekem csak az order-processing module részre, azon belül is a business rules-ra kellene koncentrálnom. Ez ugye elég nehéz a rendszer többi részét nem ismerve. De gondolom ez is a teszt része, hogy ki milyen megoldást választ..
Tudnád ezt a scriptelt döntéshozó részt jobban elmagyarázni? Mi lenne konkrétan a scriptben? Valami expression tree szerű megoldás serializálva..?
Én egy BusinessRule objektumra gondoltam ami valahogy így nézne ki:
public BusinessRuleEvaluationResult Apply(EntityBase entity)
{
var evaluationResult = new BusinessRuleEvaluationResult();
var actualValue = RelationPropertyValueResolver.GetPropValue(entity, PropertyPath);
//both null -> match
if (RulePropertyValue == null && actualValue == null)
evaluationResult.IsMatch = true;
//one of them null -> no match
else if (RulePropertyValue == null || actualValue == null)
evaluationResult.IsMatch = false;
//check actual values
evaluationResult.IsMatch = RulePropertyValue.Equals(actualValue);
//exectue action
if (evaluationResult.IsMatch)
{
var actionTarget = RelationPropertyValueResolver.GetPropValue(entity, ActionEntityPath);
var actionTargetType = actionTarget.GetType();
var method = actionTargetType.GetMethod(ActionToExecute);
object actionResult = method.Invoke(actionTarget, null);
evaluationResult.ActionResult = actionResult;
}
return evaluationResult;
}var productBusinessRule = new BusinessRule()
{
PropertyPath = "Order.Product.Title",
RulePropertyValue = "Egri Csillagok",
ActionEntityPath = "Order",
ActionToExecute = "GeneratePackageSlip"
};Ez lenne egy rule, amit adatbázisban tárolnék.
[ Szerkesztve ]
-
Zola007
veterán
válasz bambano #9861 üzenetére
8 bites sima ASCII kódban hogy lehet a 9. biten a paritásbit?
nem azért tud a paritásbites ASCII csak 128 karaktert kódolni mert 7 biten kell elférnie és a 8. a paritásbit?magyarázd már el kérlek, mert ezek szerint nekem itt van egy kis zavar a Mátrixban
[ Szerkesztve ]
Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
dabadab
titán
válasz akrobet #9864 üzenetére
"Hogy lehetetlen jól megoldani, gondolom arra érted, hogy nincs elég információ a rendszer felhasználási mintájáról, adatforgalomról, fejlesztésre rendelkezésre álló időről stb..."
Nem, ezt arra értem, hogy egy olyan feladatot, ahol nem lehet érvényes modellt készíteni, mert bármit csinálsz, a következő változtatással felrúghatják valamelyik alapfelvetését, ott nem lehet olyan megoldást találni, ahol a változások követéséhez nem kell programozói munka.
"Mi lenne konkrétan a scriptben?"
Leírva az, amit akarnak, ilyenek:
if ( stuff.physical == true || stuff.type == "book" )
generate_comission"Én egy BusinessRule objektumra gondoltam ami valahogy így nézne ki:"
Ami rögtön meg is hal már abban az egyszerű esetben is, ha pl. két tulajdonságot kell egyszerre nézni.
[ Szerkesztve ]
DRM is theft
-
dabadab
titán
válasz Zola007 #9865 üzenetére
"8 bites sima ASCII kódban hogy lehet a 9. biten a paritásbit?"
Sehogy, az ASCII kódban nincs paritásbit. Amiről szó lehet, az valószínűleg soros átvitel, ott meg alapból bitstream van - neked már semmit sem mond az, hogy 8N1? (Mondjuk abban pont nincs paritásbit, de a 7E1 is elég jellemző konfiguráció)
DRM is theft
-
Zola007
veterán
válasz dabadab #9867 üzenetére
Nekem nem mond semmit, biológus vagyok, most tanulom az egész programozás témát az elejétől
Ezt írják: [link]
"The committee considered an eight-bit code, since eight bits (octets) would allow two four-bit patterns to efficiently encode two digits with binary-coded decimal.
However, it would require all data transmission to send eight bits when seven could suffice. The committee voted to use a seven-bit code to minimize costs associated with data transmission. Since perforated tape at the time could record eight bits in one position, it also allowed for a parity bit for error checking if desired. Eight-bit machines (with octets as the native data type) that did not use parity checking typically set the eighth bit to 0"[ Szerkesztve ]
Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
akrobet
tag
válasz dabadab #9866 üzenetére
Több rulet össze lehetne vonni egy BusinessRuleSet -be
IEnumerable<BusinessRule> Rules
bool MatchAllif (Rules.Any()) {...}
vagy
if (Rules.All()) {...}
A scriptnek mi lenne az előnye hardcode-dal szemben azon kívül hogy nem kell a változtatásához egy release? Mert azt csak programozók tudnák úgy is megírni.
-
dabadab
titán
válasz akrobet #9869 üzenetére
"A scriptnek mi lenne az előnye hardcode-dal szemben azon kívül hogy nem kell a változtatásához egy release? Mert azt csak programozók tudnák úgy is megírni."
1. Egy helyen van a business logic. A hardcodedban szükségszerűen keveredik a business logic meg a mindenféle implementációs részlet, itt nem.
2. A fentiből adódóan sokkal egyszerűbb a kód.
3. Az ügyfélnél akár egy tehetségesebb IT-s is karban tudja tartani.
"Több rulet össze lehetne vonni egy BusinessRuleSet -be"
Ezzel megoldottál EGY problémát és máris megdupláztad az adatbázistábláid számát De ha pl. ciklusra lenne szükséged, akkor megint nem tudsz azzal mit csinálni - és folyamatosan lehet találni ilyeneket addig, amíg vagy feladod, vagy Turing-kompletté válik a szabálykészleted és már meg is érkeztél a scripteléshez
DRM is theft
-
bambano
titán
válasz akrobet #9862 üzenetére
szerintem itt két választási lehetőséged van:
1. ha igazi c# programozó vagy, mindent objektumnak nézel. ha ezt az elvet követed, nekifoghatsz, bele is fogsz fulladni és soha nem lesz kész.
2. fogsz valami, erre a feladatra normálisabb programozási nyelvet és adatbáziskezelőt, és megírod abban.nyilvánvalóan a második utat érdemes járni, mivel az első járhatatlan. a jó megoldás, hogy tervezni kell valami relatíve egyszerű nyelvet, esetleg véges automatát, ami boldogul a problémával, és annak az értelmezőjét leprogramozni. esetleg az adatbáziskezelő saját programozási nyelvében, akkor még relatíve gyors is lesz. szerintem ha jól eltalálod, hogy mit kell tudjon a nyelv, akkor 3-5 nap alatt meg lehet csinálni rendesen magát a szabályrendszert. a gui az más tészta
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz Zola007 #9865 üzenetére
8 bites ascii kódban sehogy.
a memóriában van paritásbit, amit 8 bitesnek látsz, de 9 bitnyi tároló áramkör van benne, meg egy paritásképző/ellenőrző áramkör.ráadásul a decimális számok kódolási rendszerét nem szabadna keverni az ascii-vel, a kettőnek nem sok köze van egymáshoz.
ugyanígy, ahogy a későbbi hsz-ben írtad: nem 8 bites paritásos ascii-ről van szó, hanem 7 bites sima ascii-ről, ami mellé a hardver betehet egy paritásbitet, ha 8 csatornás lyukszalag lyukasztóval nyomtatod. az esélye, hogy ilyet találj, úgy érzem, alacsony. tehát ugorhatsz a következő fejezetre
szerk: ha én még tároltam az első programjaimat lyukszalagon, akkor vén trotty vagyok?
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
akrobet
tag
válasz dabadab #9870 üzenetére
Értem, csak egy kicsit bizonytalan vagyok a scripttel kapcsolatban, hogy hogy működne az a praxisban, mivel még soha nem csináltam ilyet.
Valahogy dinamikusan betölteni text file-ból a c# kódot?
Továbbá, ha változik a method definició (név, paraméterek..) akkor a scripteket elég manuális lenne "utánnaigazítani", míg ha a kettő egy solution-ban van, egy sima refactor elég, és ugye typesafe az egész.
A business logicot és az implementációs részleteket azért szerintem el lehetne különíteni egymástól, ha azt vesszük ami a scriptben van is implementációs részlet, mert ugye C# és nem egy DSL.
-
dabadab
titán
válasz Zola007 #9868 üzenetére
"Nekem nem mond semmit, biológus vagyok"
Értem, akkor képzeld el úgy, hogy van nyolc prokariótád...
Szóval pont az van, amit írnak:
Amikor azon töprengtek, hogy az ASCII-ban hány bit legyen egy karakter, akkor a nyolc bit csábítónak tűnt, mert abba pont belefér kér (decimális) számjegy (mivel egy számjegyhez négy bit kell (négy biten persze nem csak tízféle karaktert lehetne ábrázolni, hanem tizenhatfélét is, szóval itt van egy kis pazarlás, de a praktikum simán megérhetett nekik ennyit)).
Viszont ellenben a végén arra jutottak, hogy nem kell nekik igazán 256-féle karakter, elég lesz 128-féle is, ami az átvinni szükséges bitek számában 12,5% megtakarítást jelent (de a hat bit 64 karaktere meg már mindenképpen kevés lett volna) és ez lett a meghatározó érv. (A "hány bit egy byte" kérdésnek erre a döntésre még olyan sok hatása nem volt, mivel akkoriban a számítógépek messze nem voltak annyira elterjedve, mint manapság, az ASCII-t egy csomó másféle masinára is szánták)
Megint viszont ellenben de az akkoriban használatos lyukszalagok nyolc lyuk szélesek voltak, így az "üresen" maradó nyolcadik bitet felhasználhatták paritásbitnek, ami az akkori input/output eszközök megbízhatósága mellett egyáltalán nem volt rossz ötlet.
Aztán jöttek a számítógépek, ott meg ugye nyolc bit volt egy byte (legalábbis egy idő után ez fixen kialakult, mert kezdetben voltak 36 bites gépek is), ott meg a memóriában a legfelső, a szabvány által nem definiált bitet fixen nullára állították ASCII használatakor.DRM is theft
-
bambano
titán
válasz akrobet #9873 üzenetére
"Valahogy dinamikusan betölteni text file-ból a c# kódot?": szerintem c# forráskódot nem fogsz szövegből betölteni, de pl. lua interpretert nem olyan nagy durranás belevarrni egy java vagy c# programba. és a lua programot betöltheted adatbázisból is.
de szerintem nem jó ötlet egy teljesen általános programnyelvet használni erre a specifikus feladatra.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
akrobet
tag
válasz bambano #9871 üzenetére
Bár látom a fantáziát abban amit mondasz "igazi" C# programozó vagyok, és a feladatban is bennevan:
"Where possible you should provide a working solution written in c# i.e. it should compile without needing to add dependencies manually."
Továbbá a kiindulási helyzet is az, hogy már adott a rendszer többi része, tehát valószínűleg késő lenne egy új programozási nyelvet "feltalálni" és az adatbáziskezelőt lecserélni.
"bele is fogsz fulladni és soha nem lesz kész" - szerintem bármilyen megoldást is választ az ember, soha nem lesz kész, mivel a feladatban is benne van, hogy a szabályok folyamatosan változnak.
Namármost, ha én olyan szinten lennék (de nem vagyok) hogy írjak egy új nyelvet, amiben ezeket a szabályokat kellene írni, attól még nem szűnne meg a szükség a maintenance-re és nem hiszem hogy egy felhasználóra lehetne hárítani a feladatot. Az elég rizikós vállalkozás lenne.
-
dabadab
titán
válasz akrobet #9873 üzenetére
"Valahogy dinamikusan betölteni text file-ból a c# kódot?"
A C# nem scriptnyelv - meg bár létezik némileg módosított, scriptelős változata is, de nem vagyok biztos abban, hogy bölcs lenne egy ennyire túldizájnolt nyelvet használni ilyen viszonylag egyszerű feladatra.
Ez úgy működik, hogy fogsz egy scriptengine-t (mondjuk Pythont vagy Luát), belerakod a kódodba, a konkrét scriptengine-től függő módon összekötöd a scriptet a fordított kódoddal és készen is vagy
DRM is theft
-
bambano
titán
válasz akrobet #9878 üzenetére
rendben, akkor találj ki egy programozási nyelvet, aminek az értelmezőjét c#-ban írod meg. én phpban írnám, mert igazán nagyon durvát szerintem abban lehet kavarni, de ha neked c# kell, nem gond.
ha az értelmezőt c#-ban írod, akkor le fog fordulni és működni fog további függőség nélkül."Továbbá a kiindulási helyzet is az, hogy már adott a rendszer többi része, tehát valószínűleg késő lenne egy új programozási nyelvet "feltalálni" és az adatbáziskezelőt lecserélni.": az adatbáziskezelő lehet jó vagy rossz korlátozó tényező, de ha csak adatbázison keresztül kommunikálna a rendszer, akkor nem lenne gond, hogy más nyelvű modulokat faragj mellé.
"Namármost, ha én olyan szinten lennék (de nem vagyok) hogy írjak egy új nyelvet, amiben ezeket a szabályokat kellene írni, attól még nem szűnne meg a szükség a maintenance-re": ha az értelmezőt nem kell módosítani, akkor a kódot emiatt nem kell karbantartani, így az a fajta karbantartás nincs, ami akkor lenne, ha kódba vésnéd a logikát. a szabályrendszer karbantartását meg, szerintem, meg lehetne egyszerűen oldani, ha jól megmakrózod az egészet.
nem olyan nagy durranás, régi ibm gépeket assemblyben programozták, mert a makro assemblere mocskos jól volt megfaragva.
hasonlót, kicsit kisebb léptékben, csináltam magamnak nemrég, megvolt egy nem alvós hétvége alatt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
martonx
veterán
válasz bambano #9871 üzenetére
Egyetértek, ez a probléma tipikusan SQL mélységben kezelendő, már csak az elvárt dinamikus, könnyű paraméterezhetőség, könnyű változtathatóság miatt is. Lehet, hogy a legjobb valami NoSql-szerű laza struktúrájú tábla lenne, amiben a szabályok el lennének tárolva. Én talán pár micro-service-el oldanám meg az egész feladatot, ahol az egyik service lenne a rule engine (alatta NoSQL-el), lenne egy másik micro-service ami a webshop-ért felelne (hagyományos SQL-el + redis), és lenne egy harmadik ami az admin felületért felelne (saját adatbázis nélkül). Így a webshop könnyen load-balanceolható is lenne.
Aztán, hogy a DB layer felett milyen nyelven valósul meg a kódbázis, az szerintem már teljesen mindegy (én C#-ra szavaznék).Én kérek elnézést!
-
martonx
veterán
válasz akrobet #9878 üzenetére
Szerintem a többiek ezt a C# ellenességet túllihegik, pontosabban félreértik, mivel a feladatot sokkal inkább SQL oldalon kell szerintem megoldani, mintsem C# oldalon. Ha adatbázisban jó, rugalmas és gyors modellt tudsz felépíteni, akkor azt kezelni már teljesen mindegy, hogy milyen nyelvben fogod.
És ugyanez igaz fordítva is. Ha db szinten elcseszed, na akkor egy szuper rugalmas PHP se ment meg attól, hogy le ne fosd a bokádat nap, mint nap a szabályok átdrótozásakor.
Én ugyan NoSQL-el állnék neki, de hiszem, hogy hagyományos SQL-el is jól megfogható a probléma, pl. raktam már össze repülőjegy árazó engine-t, aminek kellemesen bonyolult sok dimenziós mátrixokból kellett dolgoznia, és szépen megoldható volt sima SQL-el, 3-4 táblával, meg némi C#-al a DB felett.Én kérek elnézést!
-
bambano
titán
válasz martonx #9881 üzenetére
no, ilyen, amikor nagyvállalati rendszerszervező és manager kezdi kialakítani az architektúrát
ezt ezer sor alatt meg lehet írni php-ben és postgresben. ha valaki jól át tudja faragni a php-t c#-ra, akkor nem lesz nagyon sokkal több sor c#-ban se. mondjuk az kérdés, hogy amit a php-ben lehet kuplerájt csinálni változókezelés terén, és ebben a probléma megoldásban hasznos is lehet, azt hogy írja meg valaki c#-ban, de bizonyára erre is lehet választ adni.ha viszont elkezdenek objektumokat meg gettersettereket faragni rá, meg ilyen-olyan szervizeket, akkor elszáll az egész a holdba.
számomra csak egy kérdés van, milyen előnnyel járna átfaragni a php kódot valamelyik postgreses natív nyelvre.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
akrobet
tag
@martonx: ahol most dolgozunk (egy bonyolult logisztikai rendszer) bármilyen business logic SQL-ben való megírása teljes no-go, mert szinte lehetetlen karbantartani, tesztelni, stb.
amikor netán valami elcseszett adatotra kell SQL-ben scriptet írnom, az egy kész kínzás .NET kódhoz képest ahol kb. az 1/50-e idő alatt megírom azt amit akarok, linq-el, entity framework-kel."pl. raktam már össze repülőjegy árazó engine-t, aminek kellemesen bonyolult sok dimenziós mátrixokból kellett dolgoznia" - és mi a helyzet a kód olvashatóságával, netán ha valaki másnak kellene átvennie és folytatnia a munkát?
Számomra az is fura olvasni olyan érvelést, hogy valamit milyen kevés sor kódból lehet megírni..
Megintcsak, szerintem sokkal fontosabb, hogy a kód gyorsan olvasható és értelmezhető legyen ahelyett, hogy össze legyen tömörítve 5 sorba és kb 1 órába teljen valakinek aki először látja, hogy megértse. -
amargo
addikt
válasz akrobet #9878 üzenetére
en xml be kezelnem le a problemat es abbol expression segitsegevel generalnam a kodot szerver oldalon. egyszeruen azert xml, mert xml-ul barki tud es kelloen rugalmas a szabalyok leirasara.
viszont lassabb lesz barmilyen nativ megoldasnal. de gyors es rugalmas is egyszerre nem tudom, hogy lehetne. nyilvan egy erre kulon letrehozott feldolgozoval, amit mar tobben is javasoltak meglehet oldani. de szerintem itt nem ez az elvaras.“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
bambano
titán
válasz akrobet #9885 üzenetére
"Számomra az is fura olvasni olyan érvelést, hogy valamit milyen kevés sor kódból lehet megírni..": az érvelésem lényege, hogy ha lényegesen több sorból hozod össze, akkor valamit túlbonyolítottál, tehát nem fog sikerülni.
"entity framework-kel": itt szoktak elbonyolódni a dolgok, mikor bejön a framework framework hátán ne hidd, hogy egy tömör, sima kódot nehezebb olvasni, mint egy agyonframework-özött kódot. php-ben behúzol egy táblát két sorban, ugyanez egy perzisztencia réteggel külön osztályhegyeket igényel.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
martonx
veterán
válasz akrobet #9885 üzenetére
"bármilyen business logic SQL-ben való megírása teljes no-go, mert szinte lehetetlen karbantartani, tesztelni, stb.
amikor netán valami elcseszett adatotra kell SQL-ben scriptet írnom, az egy kész kínzás .NET kódhoz képest ahol kb. az 1/50-e idő alatt megírom azt amit akarok, linq-el, entity framework-kel"Hopp, na akkor itt valóban a szó legrosszabb értelmében vett igazi C# fejlesztővel állunk szembe. Be kell lássam bambanonek, tökéletesen igaza volt.
Gondoltam rákérdezek, hogy miért lehetetlen SQL-ben megírva bármit is karbantartani, pláne tesztelni? Jó, nyilván nem olyan triviális, mint szimplán C# kódot tesztelni, de ezt így kijelenteni, hogy lehetetlen?
Hidd el egy idő után az a leglényegtelenebb, hogy C#-ban 1/50-ed idő alatt írsz-e meg valamit, ha elkezditek a többedik SQL clustert alátolni a szarul megírt kódnak, ahelyett, hogy némi logika SQL oldalon is lenne."C# fejlesztőként" biztos nehéz elképzelni, de attól még, hogy üzleti logika van SQL-ben, a kód olvashatóság semmit nem romlik, no persze az nem árt, ha valaki konyít az SQL-hez. Ez ugyanolyan, mint ha azt a hülyeséget mondanám, hogy attól romlik a kód olvashatóság, hogy webfejlesztéshez nem átallok javascriptet, sőt css-t is használni, nem pedig tisztán C#-ban /PHP-ban írok meg mindent.
Én kérek elnézést!
-
Bizonyos részét az üzleti logikának érdemes tárolt eljárásokkal, triggerekkel implementálni. Legtöbbször így érhető el a legjobb teljesítmény, illetve SQL szinten így jóval egyszerűbben és biztosabban fenntartható az adatok konzisztenciája.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
akrobet
tag
válasz martonx #9888 üzenetére
Akkor let's agree to disagree Értem én hogy sql-ben érdemes olyan részeit az alkalmazásnak átírni ami a legtöbbet használt és EF nem képes rá megfelelően gyorsan futó query-ket generálni.
De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?
Nem lehetetlen SQL-ben megírt kódot tesztelni, karbantartani, csak nagyon hamar el fog menni tőle a kedved, ha egy olyan business model-ed van, ami kb 300 egyedi entitásból áll 15+ level mélységű relationokkel...
[ Szerkesztve ]
-
MODERÁTOR
Nem tudom, nem értek még mindig vele egyet (bár lehet ez a saját tudatlanságom), de tudnál olyan konkrét példát ismertetni ahol a konzisztencia megtörne? Meg a trigger-re is?
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
válasz akrobet #9893 üzenetére
Én sose értettem, hogy miért jó az "univerzális" adatbázis nagyobb rendszerek esetén. Ha képlékeny még, hogy milyen DB kell, akkor még talán megértem, de ennyi erővel meg lehet, hogy a C#-ot kell dobni. A SQL -> noSQL váltási kényszer belekalkulálását meg aztán végképp baromságnak tartom, nagyon másra való a kettő. Egy esetleges DB migrációra fel lehet ugyan valamennyire készülni (ha előre tudod, hogy lesz), de az egy worst-case scenario, emiatt eltoszni a kódot butaság.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
Pl itt ha egy júzer ír / töröl egy hsz-t, akkor a téma és fórum hozzászólásszáma és az utolsó hsz dátumpecsétje frissül, illetve a júzer lehet rangot léphet, stb. Ezt php-ból megírni elég retek meló lenne, és a bonyodalomból adódóan könnyebben előfordulhatnak bugok, viszlát konzisztencia. S ez csak egy egyszerű példa.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
akrobet
tag
Egy teljes 180 fokos fordulat SQL-ről No-Sql-re tényleg nem valószínű, de egy hibrid megoldás sokkat inkább, pl. egy gráf alapú adatbázis mint a Neo4J az applikáció azon részére, ahol az SQL join már nem járható út (és nem szeretnéd agyon-normalizálni a tábláidat és duplikálni az adatot). És akkor szerintem jobban fogok örülni, hogy a bonyolult model struktúra és logic amit le akarok cserélni nem SQL-ben van, hanem CSharpban.
De lehet, hogy ez csak egy egyedi eset nálunk és senki másnál ilyen nem fordult még elő
[ Szerkesztve ]
-
válasz akrobet #9898 üzenetére
De ez akkor a fejlesztés része, ez megint más, ideiglenesen kb abban írod amiben akarod, a kész szoftvernél meg már fix DB lesz, az ami a legjobb a feladatra. Ám lehet inkább alaposan körül kéne járni és megtervezni a DB kérdést, nem pedig rögtön elkezdeni írni ész nélkül, amikor még azt se tudod hogyan lesz.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- AirPods Max - Silver (Hibátlan és tökéletes állapot, tulajdonképpen új, pár napot volt használva)
- LEGJOBB ÁR! GAMER PC - RTX 3070 - Ryzen 5500 - 16GB DDR4 - 500GB Nvme SSD
- ÚJ Playstation 5 CFW képes (feltörhető), lemezes
- ÚJ Dell Vostro 3520 - 15.6" IPS 120Hz / i5-1235U / 8-16Gb DDR4 / 512Gb / HUN backlit / 3 ÉV GAR.
- Nikon D7000, Tamron 18-270mm, Sigma 150-500mm
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest