-
IT café
Új hozzászólás Aktív témák
-
mckay
aktív tag
Sziasztok!
Én nem vagyok programozó, "csak" rendszergazda, de most segítenem kéne a főnökömnek egy döntést meghozni.
Méghozzá sürgősen.
- A cégemnek van egy programja, amit a partnerek számára fejlesztettek ki, méghozzá .Net alapokon. Ezzel tudják igénybe venni a cégünk szolgáltatásait. Szóval adott egy vastagkliens. És csak Windows-ra.
- Most sok új dolgot kéne belefejleszteni, és elgondolkodott, hogy talán inkább egy böngészőben futó vadonatúj alapon kéne elindulni a felhőben. Tehát egy vékonykliens. Amihez egyébként adott az Azure, mert bőven van ilyen előfizetése a cégünknek.
Az egészet nem én találtam ki, magam is csak pár hónapja dolgozom a cégnél, de jó ötletnek tűnik.Én eddig azt hittem, hogy olvasott ezt-azt, és ezt a jónak tűnő megközelítést magáévá tette. Most viszont kitalálta, hogy holnapig győzzem meg őt erről, hogy ennek van értelme. Merthogy drága. És hogy aki nagyon akarja a cégünk szolgáltatásait, úgyis kerít egy Windows gépet.
Huhh, segítenétek nekem gyorsan, hogy erre mit lehet válaszolni? Ismétlem, nem vagyok programozó. És IT gazdasági szakember sem. De azért elég sokat olvasni itt ezekről a dolgokról, hogy sejtsem, nem jó stratégia 2018-ban egy Windows-os vastagkliensre alapozni az árbevételt.
Bármilyen szakcikk, elemzés, trend, ábra, grakikon jól jönne, hogy belinkeljem neki!!
Köszönöm!!!
-
mckay
aktív tag
válasz bambano #11938 üzenetére
:-)
Igen, a software as service valóban jobb modell, például ha új szolgáltatásunk van, vagy javítani kell valamit a szoftveren.
De hogy egy .net alapokon megírt üzleti logikát hogy lehetne átültetni Azure-ba, az tényleg új nekem...
:-)A lényeg hogy az a véleményetek, hogy nem olyan egyértelműek a böngészőben futó szoftverek előnyei?
Azt gondolnám, hogy azzal stratégiailag messzebbre lehet jutni, mert maholnap elhajtják az embert a potenciális ügyfelek, ha azt mondjuk, hogy hozzánk belépő feltétel a Windows vastagkliens telepítése.. -
mckay
aktív tag
válasz sztanozs #11946 üzenetére
Köszönöm szépen!
Nagyon alapos válaszok jöttek, nem is gondoltam volna, hogy ennyire belendültök!
;-)Szóval akkor mégsem olyan egszerű a döntés, hogy ha drága a felhő és az előlről programozás, akkor mégis maradjon a kliens. Sejtettem.
Arról bárkinek van jó grafikája a tarsolyában, hogy egy .Net alap várhatóan mikor teszi majd igen korlátossá a program használatát? Hogy pl. a megvásárolható gépek meddig lesznek kompatibilisek, mikortól fog az UAC egy átlag gépen is elreszelni egy aláíratlan progit, mikor jön el az .exe progik alkonya (vs.: js, java, metro, bármi), sőt, már ma is mennyi cég nem használ Windows-t
Ilyesmi muníciója van valakinek készen?
-
mckay
aktív tag
válasz sztanozs #11946 üzenetére
srácok,
szerintem annyira alapos hozzászólásaitok voltak, hogy tisztelettel megérdemeltek néhány további részletet:
- a cégem nagyvállalat, nem gond a beruházás, ha az amúgy értelmes
- az sem gond, ha sokára lesz kész
- valóban szenvedünk azzal, hogy a partnereink nem telepítik a legfrissebb változatot
- valóban sok üzleti logika van kint a vastagkliensben, de email kliens módjára csatolt fájlokkal kommunikál felénk (smtp használattal)
azt hiszem, hogy a hozzászólások összességében a felhő alapú megoldás felé tolnak engem, én meg majd a döntéshozókat, ha tudom
:-)de továbbra sem találok semmi frankó grafikát, számadatot, hogy a mai magyar rögvalóságban vajon mekkora hátrány, ha az ember .Net (tehát Windows vastag) klienssel nyomul a cégek irányába
honnan lehetne valami statisztikát szerezni?másképp fogalmazva: értem, a webes technológia mégicsak király, de vajon eljött-e az ideje már egy több ezer példányos szoftver leváltására?
[ Szerkesztve ]
-
mckay
aktív tag
válasz Jim Tonic #11957 üzenetére
a szóban forgó szoftvernek nincs igazán kapcsolata a szerverrel, és ott nem is tud elérni semmilyen adatbázist
adatok csak a kliensben vannak, és oda sem mi pakolunk, hanem az ügyfél, aki rendeltetésszerűen használja a szoftverünket - azt gondolnám, hogy az általa a mi szoftverünkben tárolt adatokért ő kell, hogy feleljen
nézzétek, úgy tudnám jellemezni, mint egy spéci pizzarendelő szoftvert:
- üzleti logika van a kliensben, például hogy milyen pizzafeltétek mivel párosíthatók (például a tejfölös alap a paradicsomos alappal nem párosítható), összekattintgatja az ügyfelünk, és generálódik belőle egy email, amit a saját smtp szerverén keresztül (mert első használatkor bepötyögte a saját smtp autentikációját) csatolt fájlként elküld hozzánk, és mi várjuk, és teljesítjük az abban szereplő "pizzarendelést"
- adatok abból a célból vannak benne, hogy jellemzően nem magához rendeli a pizzát, hanem máshoz: évek alatt felépíti a saját vendégkörének adatbázisát, és amikor egy vendég kéri a pizzáját, pár kattintással tudja is neki küldeni a "szokásost"
ennyitermészetesen nem pizzarendelésről van szó, de azt hiszem így lenne jó bemutatni
és a dilemma most vezetői szinten, hogy
- jó-e így ez a vastagkliens architektúra helyi adatbázisokkal és helyi programmal
- vagy eljött az idő (egyszer tutira el fog!), hogy böngészőben fusson a mutatványehhez keresek adatokat, hogy mi a magyar rögvalóság a PC-k terén
vagyis baj-e, baj lesz-e, hogy .Net alapú vastagkliensünk van -
-
mckay
aktív tag
válasz sztanozs #11963 üzenetére
nem, ez sehogy sem ideális architektúra
:-)
az ügyfél gépéhez az ügyfél alkalmazottja fér hozzá, aki amúgy bármikor excelbe exportálhat minden adatot, nincs többszintű jogosultság, szóval nem kell kalózkodni, nyitott
de a logika szerint az nem is a mi adatunk, hanem az övé
hozzánk emailben (!) csatolt fájlként jön be az a megrendelés, amit ő a programjában összemókolt az az ő ügyfelének
mondanom sem kell, titkosítatlan csatolt fájlként jön emailben.
na azért az már nem GDPR barát szerintem, de nem feszegetném... -
mckay
aktív tag
Sziasztok!
Szeretném felmelegíteni ezt a kérdésemet, amire most is nagyon szépen köszönöm a válaszokat.
De most azzal kapcsolatban, amit néhány említettetek: adatvédelmi szempontból.
Emlékeztetőül: arró faggattalak titeket, hogy milyen prezentációt tegyünk le a főnökség felé egy olyan kérdésben, hogy mivel lehetne kiváltani egy olyan, mára korszerűtlennek tűnő programot, ami
- helyi gépen fut több ezer ügyfelünknél, mi fejlesztettük, alapvetően offline működik, helyi adatokkal
- SQLite adatbázisa, sima titkosítatlan .dat fájllal
- az a funkciója, hogy megrendeléseket állít össze benne a partnerünk, hogy az ő partnereinek mi milyen szolgáltatást végezzünk el, majd emailben elküldi nekünk ezt a összeállítást, és mi szolgáltatunk.
A mostani kérdésem viszont nem az lenne, hogy mi legyen helyette. Ugyanis bármit is indítanak el a főnökeink, hogy kiváltsák, attól még ez az applikáció évekig használatban lesz. Sok évig.
Hanem azt szeretném megtudni, hogyan lehetne egyértelműen beazonosítani, hogy az adatvédelmi szabályok szerint mi most adatkezelők vagy adatfeldolgozók vagyunk?
Mondjuk amit beküldenek hozzánk, és mi a saját rendszerünkben tárolunk, hogy kinek milyen szolgáltatást nyújtottunk, ott biztosan adatkezelők vagyunk.
De nem csak nálunk vannak infók, hanem a programunkban is, a partnereinknél, akik az ő partnereikről gyűjtik visszamenőleg az adatokat.
Ugye jól sejtem, hogy a partnereink gépén tárolt adatok tekintetében mi nem vagyunk adatkezelők? Még akkor sem, hogy ők a gépeiken csak és kizárólag azért tárolják ezeket az adatokat, mert a mi szolgáltatásunkat igénybe akarták venni az ő partnereik számára? És még akkor sem mi vagyunk az adatkezelők, ha mi éppenséggel úgy írtuk meg a kiadott programot, hogy tárolja ezeket az adatokat, akár örökre?
Nézzétek, nem véletlenül kérdezem. A mai, első GDPR-os napon (05.25.) egy aktivista azt jelentette be, hogy kéri, hogy mi töröljük az egyik partnerünk gépén az arra vonatkozó adatokat, hogy az ő számára a partnerünk bármit is megrendelt tőlünk.
Jó mi?
Hogy tudnánk egyáltalán ezt, akárcsak kérni is tőle, ha nem építettünk ilyen funkciót a programunkba 6 évvel ezelőtt? Kötelezzük, hogy akár a teljes adatbázisa törlésével, vagy bárhogy, de töröljön? Vagy ne kötelezzünk, mert nincs közünk hozzá, és irányítsuk a partnerünkhöz az igénylőt?
Nem rossz kis dilemma, ugye?
Bocsi, ha rossz topicban írtam meg a kérdéseket. Nyugodtan javasoljatok másik topicot, ha az jobban klappolna. Köszi. -
mckay
aktív tag
válasz bambano #12000 üzenetére
oksa, keresek neki valami topicot
azért köszi
:-)no persze, igazatok van, én is úgy gondolom, hogy ez meló, spéci pénzért, tanultaknak
de azért az adatvédelem nem tegnap kezdődött, és azt hittem, hogy esetleg itt is van valaki, aki vágja fejből, hogy ki mikor kezelője egy adatnak
én ugyanis nem vagyok programozó, de tényleg azt hittem, hogy bizonyos szakokon ez is része a tematikának
belátom, ez határterület, kopogtatok jogászoknál(ott viszont, már előre látom, azt fogják hajtogatni, hogy ők meg nem programozók, és hogy ők meg olyan szimpla kérdésekhez vannak szokva, hogy xy webshop gyűjti az email címeket a marketingkampányaihoz, és ahhoz képest egy ilyen sztori már nagyon bonyi, mikor ugyanaz a webshop mondjuk már nem kizárólag magának, hanem a velünk kapcsolattartáshoz és ráadásul a mi programunkban gyűjti az adatokat)
-
mckay
aktív tag
válasz bambano #12004 üzenetére
oks, köszi mindkettőtöknek
tényleg kell egy megalapozott szakvélemény
és tényleg biztosan nem jó a szoftverünk, mert ha
- mi vagyunk az adatkezelők, akkor gond, hogy nem férünk hozzá
- ha pedig a partnerünk (aki a programunkat használja) az adatkezelő, akkor őt meg nem értesítettük, hogy a program alapból minden előzményt elment, és úgy vigyázzon a saját programjára, vagy esetleg ne is használja ezt a fícsört, ha nem akar adatkezelni -
mckay
aktív tag
válasz bambano #12006 üzenetére
háát, abban egyetértünk, hogy a GDPR önmagában nem hoz újdonságot, csak segít, hogy most leessen a tantusz
de a progi sem tökéletes: ha egyszerűen nem létezik benne törlés gomb, és akár 10 évre visszamenően is benne van minden előzmény, az úgy mai szemmel már nem túl döfi
persze mondhatjuk az ügyfeleinknek, hogy adattörlési igény esetén uninstallálják a proginkat, és aztán installáljanak egy tiszta újat, de hát az nem túl elegáns, ezzel kell valamit kezdeni, nem vitás
a kérdés inkább az, hogy a soron következő javításig (amikor bekerülne a törlés gomb) addig is kinek a terhe, hogy megrendelőszoftverünkben ott figyel valami, amire kérés van, hogy legyen kitörölve...
-
mckay
aktív tag
válasz martonx #12011 üzenetére
Igen, igen, igazatok van, nem most indult az adatvédelem.
De egyébként itt nem smucigság van, hanem egyszerűen nem is gondolt rá a cégnél senki. Ugyanis nagyon sokat figyeltek/költöttek az elmúlt időszakban is ilyenekre, a mi szerveroldalunkon ez meg is van csinálva, bármilyen igénylésre tudunk törléssel reagálni, és amúgy is törlődik a törvényben írt időszak után a személyes adat.
Csak ez az egy apróság, hogy nekünk van egy olyan vastagkliens szoftverünk (aminek az alapötlete szerintem meghaladott), hogy a számunkra rendelést feladó cégek a saját számítógépükön a rendelésfeladó programjaikban is gyűjtik az előzményeket, no ez nem esett le senkinek. Ezt a progit hat éve csináltuk, és kiemelem: részünkről offline!, nem férünk hozzá, nem is tudjuk mi történt vele a partner gépén. Csak úgy ott van, és persze mind a mai napig használják, és küldik be vele a megrendeléseket. De mi nem tartjuk karban náluk!
És most, hogy valaki kérte az őt érintő adatok törlését, és mi ezt ügyesen meg is tettük szerveroldalon, na most esik csak le a tantusz, hogy az idegen kft számítógépéről, amelyik beküldte a rendelést, vajon ki fogja törölni? Egyáltalán, megvan még az a számítógép, vagy múl héten kidobták? Vagy pl. újratelepítették rajta a rendelőprogramunkat, és most nincsenek is benne a előzményadatok? -
mckay
aktív tag
válasz bambano #11951 üzenetére
hát igen, beletenyerelt Sztanozs, és valószínűleg te is nagyon jól mondod: új architektúra mellett szól minden, még a GDPR büntik mértéke is
köszi a szempontokat!
és ha már az architektúra szóba került: ha az adatok a kliens program és a mi cégünk között email és csatolt fájl formában közlekednek, önmagában már ez is gond most?
- Sztanozs tényleg beletenyerelt: a kliens progi vastagklienses, saját titkosítatlan adatbázissal, logikákkal.
- a kommunikáció egy titkosítatlan .xml fájl küldése csatolt fájlként
- igen, az .xml igen gyakran személyes adat van, hiszen mi nem csak üzleteknek, hanem természetes személyeknek is visszük, amit tőlünk rendelnek a partnereink
- és igen, ez azt jelenti, hogy a programunknak szüksége van a partnerünk smtp adataira, autentikációjára, ezt a beállításokhoz pötyögik be
- itt a beállítás menüben nem tilos a programunkban SSL nélküli smtp-t megadni, gondolom sok partnerünk használja is a 25-ös/587-es portotönmagukban ezek az ismérvek is olyanok, amit tiltana a korszerű adatvédelem?
ha kikényszerítjük, hogy csak titkosított csatornát használjanak, akkor végülis architektúrálisan meg van oldva, nemde?jah, a lényeget nem mondtam: igen, eldőlt, lesz új programunk, ami böngészőben fut majd, de állítólag csak két év múlva készül el, addig betart a tervezés/kódolás
no addig kell ezt a fenti architektúrát mégis életben tartani valahogy!köszi mégegyszer minden segítséget az eligazodáshoz!
[ Szerkesztve ]
-
mckay
aktív tag
válasz bambano #12025 üzenetére
jó ötlet, le kéne papírozni, hogy mire figyeljenek oda a programot felhasználó partnereink
és akkor alapvetően maradhat a maradék két évre
köszi a tippet!ezt a verziót is fogom javasolni a céges jogászoknak, programozóknak, vezetőknek, akik kalákában foglalkoznak a gdpr-megfeleléssel
köszi mégegyszer!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Androidos fejegységek
- Skoda, VW, Audi, Seat topik
- A fociról könnyedén, egy baráti társaságban
- WoW avagy World of Warcraft -=MMORPG=-
- Bivalyerős lett a Poco F6 és F6 Pro
- TCL LCD és LED TV-k
- Azonnali fotós kérdések órája
- Kínai, és egyéb olcsó órák topikja
- 3D nyomtatás
- Azonnali fáradt gőzös kérdések órája
- További aktív témák...
- LG OLED55C37LA GYÁRI GARANCIA 3 ÉV
- APPLE Mac Studio M1 Max 10C CPU, 24C GPU, 32G RAM, 512GB SSD
- Kingston A400 960GB (SA400S37/960G)
- Ohh! HP EliteBook 840 G6 Fémházas Laptop 14" -70% i5-8365U 4Mag 16GB 512GB SSD FHD IPS + Táska!
- Szép! HP EliteBook 840 G6 Fémházas Laptop 14" -70% i5-8365U 4Mag 8GB 512GB SSD FHD IPS + Táska!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen