Keresés

Ú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!!
    :R

    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 bambano #11951 üzenetére

    igen, hallom-látom, hogy a GDPR okán most nagy divatja van ezeknek az (amúgy tényleg fontos) kritériumoknak - de azt nem látom, hogy az architektúra kiválasztása miért függ a GDPR-től
    ebben is, abban is meg kell felelni...

  • 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"
    ennyi

    termé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ány

    ehhez 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 #11960 üzenetére

    mondjuk a mi esetünkben szinte semmi zártság nincs
    a felhasználó használja a saját adataival
    nekünk úgymond semmi közünk hozzá, csak a rendelést várjuk
    :-)
    természetesen nem ezt gondolom, de tény, nincs titkosítva az adatbázisa

  • mckay

    aktív tag

    válasz Ispy #11959 üzenetére

    Értem, valószínűleg ez a helyes javaslat.
    Ha van rá pénz, fenn kell tartani még jónéhány évig a hagyományos vastagkliens megoldást is, mert még sokakat elriaszt egy tisztán felhő alapú megoldás.
    Köszi, ez lesz a válaszom!
    :-)

    És köszi mindenkinek!
    :R

  • 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

    válasz opr #11965 üzenetére

    köszi, egyetértünk
    csak a titkosítatlanul bejövő email miatt aggódtam kicsit
    :-)

  • mckay

    aktív tag

    válasz opr #11965 üzenetére

    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.
    :P
    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?
    :F
    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?
    :U
    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?
    :Y
    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?
    :Y
    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
    :R

  • 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 #12007 üzenetére

    ehh, ha már ketten mondjátok, hogy valszeg mi vagyunk az adatkezelők...
    nem örülök a véleményeteknek...
    :DDD

  • 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.
    :C
    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!
    :W
    É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?
    :P

  • 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!
    :R

    [ 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