Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
válasz
bambano
#17720
üzenetére
Ideje lenne megbarátkoznod a dologgal, mert önmagában a konténerizáció rohadt jó dolog, ráadásul pont az üzemeltetőknek igazán frankó. Ezt mutatja az, hogy a Linux rendszergazdánk, aki legalább annyira morgós boomer, mint te konkrétan imádja, és már minden appunkat konténerbe pakolja. Mellesleg nagyon sok pénzt spórol ezzel a cégnek.
-
válasz
sztanozs
#17523
üzenetére
Még ha fizetett is rendesen, simán lehet olyan vállalkozás, amely nem vezet naprakész készletnyilvántartást. Egyszerűen felesleges, mert 100-200 forintos dolgokat árul tonnaszám. Ő nem fogja ezeket tételesen nyilvántartani. Dolgoztam ilyen helyen fejlesztőként, beleraktam a raktárkezelést a rendszerbe, és a főnök mondta, hogy tök felesleges. Mert ha kifogy a raktárból, akkor mi van? Másnapra itt van a cucc a nagykerből úgyis, az ügyfél meg csak megijedne attól, hogy nincs raktáron. Ez egy teljesen tudatos üzleti döntés.
-
Pont itt is volt nemrég hír arról, hogy ML-t használnak leletezésre. Ott írtam, hogy ismerek egy srácot, aki műtéti robotok szoftverét fejleszti. Szintén ML alapon tervezi meg a robot a konkrét műtéti eljárást. Ezt úgy képzeld el, hogy megtervezi a szoftver, hogy hol és mennyit kell mondjuk lecsiszolni a térdedből.
-
Hát, azért ez bonyolultabb. A statisztika ennél azért sokkal szűkebb terület. A leíró statisztikába nyilván nem lehet beleszuszakolni az AI-t, a következtető statisztikából is kilóg számomra, bár közelebb áll hozzá.
Ha AI fejlesztésre gondolsz, akkor az egyértelműen nem statisztikai terület, bár rengeteg statisztikai eszközt (adatot) használ. Ha mondjuk data science-re gondolsz, annak a nagy része statisztikai jellegű munka AI eszközöket felhasználva.
Nem tudom, hogy perpill mi a taxonómiája, de kizártnak tartom, hogy simán a statisztika tudományához sorolnák az AI-t. Valószűleg vagy külön tudományág lesz, vagy az informatikán belül kap valami megnevezést.
Pontosan mit szeretnél tudni? Egy konkrét példát AI fejlesztésre/felhasználásra?
-
Talán segíti a megértést ez a kiegészítés: sokszor ugyan fix a szkóp, de bonyolult ökoszisztémák esetén nagyon nehéz eljutni oda, hogy ez feltöltődjön üzleti tartalommal. Például szeretnél csinálni egy új netbankot. Hiába készíted el a legmodernebb UI-t, azt ki kell szolgálni adattal, össze kell kötni core és szatelit rendszerekkel, amelyeknek vagy nincs normális dokumentációja, vagy elavult. Ez mind idő. Gyakran sokkal jobb elindulni agilisan egy szűkített szkóppal, lépésről-lépésre feltérképezni az integrációkat, és folyamatosan szállítani az új funkciókat. Ezt waterfallban megvalósítani szinte lehetetlen, legalábbis belátható időn belül.
Szóval az agilis értékekből nem csak az ügynökségek/szállítók profitálhatnak, hanem a nagy megrendelők is. Persze a valóság kijózanító.
-
válasz
martonx
#16854
üzenetére
Hja, nehogy személyesre vedd, nem az volt a célom.
Csak megmutatni azt, hogy tényleg mekkora jelentősége van a tervezésnek. És itt rohadtul nem kódminőségről van szó, hanem architektúráról. És tényleg sokan vannak, akik nem láttak ekkora rendszereket, és könnyen mondanak triviálisnak tűnő, de használhatatlan megoldásokat. -
40 éves mainframe-en szerintem ezt nem tudják megcsinálni, szóval ettől én megmenekülök. Az ügyfeleknél már most is ez van, sírnak is miatta.
#16851emvy
Hja, ezt már linkelted korábban, én is magyaráztam a kollégáknak, hogy a VPN egy faszság, csak kényelmetlenséget szül. Persze ezt nem mi fogjuk eldönteni itt a gyarmatokon. -
Bocs, félreérthető. Tehát a havonta változtatást vezették be, az összes többi volt eddig is. A legszebb az, hogy a belső core rendszernél is kitalálták ezt, ami egy mainframe, és körbe van vastagon tűzfalazva meg VPN-ezve. Szóval én is cserélgethetem havonta a jelszavamat. Mondanom sem kell, hogy ugyanaz a jelszó, csak az utolsó szám különbözik.
Hja, ez egy amerikai giga multi, ami szerintem százmilliós nagyságrendben költ IT secre. Dollárban.
-
Más téma. Régen ismert már ez a dolog, de most megint szembe jött velem: [kép]
Most bevezették nálunk azt, hogy havonta kell az ügyfeleknek jelszót változtatniuk, nem egyezhet meg az előző 12-vel, kis-nagybetű-szám legyen benne, minimum 8 karakter. Na de könyörgöm, milyen webapp nem rendelkezik manapság bruteforce preventionnel? Az ügyfelek háborognak, nyilván felírkálják a jelszavukat, kérik állandóan a jelszó emlékeztetőket. Rengeteg panasz jön emiatt a CC-be. Mi értelme ennek a szigornak manapság? Hja, persze van 2-faktoros authentikáció is.
-
válasz
martonx
#16834
üzenetére
Egy végtelenül bonyolult banki ökoszisztémában sajnos ez nem ilyen egyszerű. Mert könnyen rá lehet mondani, hogy 90% mehet kessből, de egyrészt azonosítani kell ezen adatok körét, másrészt azzal is számolni, hogy ez a 90% 10 rendszerből jön össze, amiket fel kell térképezni, töltést kitalálni, embert keríteni hozzá. A végén pedig kijön, hogy mindez 3 évbe, és 1500 embernapba kerül (nyilván nem konkrétan ennyi, de elő szoktak jönni ilyen szituk). Szóval ez azért nem olyan, mint egy zöldmezős webapp, amivel a fejlesztők 90%-a szembesül életében.
Ugye ennek a szolgáltatásnak multifunkciósnak kell lennie, és illeszkednie a bank SL-ébe, hiszen más appok is akarják használni. Szóval nem lehet csak a mi appunkra kihegyezni, hiszen lehet, hogy másnak más adat "változatlan".
Most abba az irányba indulunk el alkalmazás oldalról, hogy szét fogjuk bontani a hívásokat (alapból paraméterezhető, de nekünk teljes adattartalom kell egyébként), kvázi megpróbáljuk többszálasítani a lekérdezést. Cachelés lesz alkalmazás backend oldalon, mert magát a szolgáltatást is többször hívjuk egy cikluson belül, az első hívás tartalmát bekesseljük, és csak akkor kérdezzük le újra, amikor tudjuk, hogy változhatott az adat.
Mint látszik, ez csupán tüneti kezelés, a forrás service ettől nem lesz gyorsabb, csak az ügyfél kevésbé szembesül a hátrányaival.
#16836martonx
Persze, ez annyira tipikus üzlet, mindenből friss adat kell, és ráadásul lassú se lehet
Nézd, az üzlet az ügyfél valid igényeire próbál referálni. Szerintem az teljesen jogos elvárás, hogy egy webes alkalmazásra ne kelljen perceket várni, és az ügyfél a valós szolgáltatásképét lássa. -
A kess logikailag nem jó itt, mert nem tudod elkülöníteni az ügyfelek olyan csoportját, amelyet nagy valószínűséggel fogsz lekérdezni. Innentől pedig az van, hogy az egész DB-t memóriában kéne tartanod. Persze ez sem lehetetlen, de nyilván te is tudod, hogy nem tipikus.
#16832nevemfel
Majd leírom, hogy mire jutottak az architekt urak, én csak a partvonalról szemlélem a dolgokat. -
válasz
nevemfel
#16827
üzenetére
Az adattárház nem forrásrendszer, a benne lévő adatok nem frissek, jellemzően T-1, T-2-ben vannak, vagy még régebbiek. A forrásrendszerek DB-jéből töltődnek oda az adatok számos okból. Friss dolgokra az sajnos nem használható.
A kesselés tök jó dolog, de itt nem ez lesz az út szerintem. Pont a percre készség, a nagy ügyfélállomány, és az ügyfél prioritás hiánya miatt itt komplett DB-ket kéne kessben tartani, és változás esetén azonnal frissíteni. Persze ki lehetne alakítani azt, hogy az ügyféltörzset berakod kessbe, illetve a ritkán változó adatokat, de a lassulást jellemzően amúgy sem ezek okozzák. Meg hát ugye itt már minden le van fejlesztve, szóval valami olyan megoldás kéne, amihez nem kell elölről kezdeni az egészet, kifordítva a teljes architektúrát, mert nagyjából tegnapra kéne minden.Tényleg tegnapra.
#16829Drizzt
Persze, userID, de ezt ne úgy képzeld el, hogy van egy nagy DB, és onnan queryzgetünk dolgokat. Van egy kompozit szolgáltatás, ami hívogat szintén kompozit szolgáltatásokat, amik a mi szemszögünkből blackboxok. Meg Pl/SQL jobokat, meg kis kutya faszát is. Aztán így 20 szekvenciális kérésből összerak neked egy response-t. Szóval ez a köztes absztrakt réteg egyrészt nem létezik architekturálisan (ki kéne alakítani), feltérképezni a hívott szolgáltatások logikáját, aztán vagy bekötni MQ-ba, vagy közvetlenül DB-queryzni. Csak hát így pont adtunk egy pofont annak a törekvésnek, hogy próbáljuk a bank szolgáltatásait egy standard service layerbe szervezni az egyedi kókányolásokkal szemben. -
Maga a service ilyen szempontból paraméterezhető, de sajnos nekünk minden kell egyben. Mármint tényleg minden, mert megy ki egy dashboardra az ügyfélnek azonnal. És persze lehet mondani, hogy nem így kellett volna tervezni a UI-t, de így akkor a gombhoz varrnánk a kabátot. És ja, az is lehetne, hogy egy köztes absztrakt rétegbe kiforgatjuk az adatokat egyfajta view-ként, csakhogy az is üzleti igény, hogy az adatok nem napra, hanem percre pontosak legyenek. Tehát ha az ügyfél igényel egy biztosítást, akkor onnantól fel se dobjuk neki azt ajánlatként. Ezt pedig valós idejű forrásrendszeri kapcsolattal lehet. És itt most több banki core (számlavezető, kártya, hitel, biztosítási, adattárház) rendszerről, számos szatelitről beszélünk vegyes relációban. Nem mondom, hogy nem lehet ezen javítani, a mókusok már dolgoznak rajta, de gyors megoldás biztosan nem lesz. Ők is kapásból úgy közelítették meg, ahogy te, de folyamatosan falakba ütköznek. Itt amúgy nem a vas a probléma szerintem, egyszerűen túl sok az IO, jobban szét kellett volna darabolni, de most már késő.
-
Ügyfél által választható biztosítási termékek, és azok, amelyekkel rendelkezik. Ügyfél által választható bankkártyák, folyószámlák, és azok, amelyekkel már rendelkezik. Megtakarítási termékei, és ajánlatok. Hitelei, és hitel ajánlatai.
Minden ügyfél típus és szegmens szerint paraméterezve.
-
Attól, hogy nem nézem, még kellenek az adatok. Csak olyan kerül lekérdezésre, amire szükség van, illetve csak 1x, szóval a kesselésnek tényleg semmi értelme, mert akkor bekesselhetnéd az egész táblát a DB-ből. Ügyfél adatokról van szó, szóval még azt sem lehet mondani, hogy a leggyakrabban használtakat betolod kessbe, mert nincsenek leggyakrabban használtak a felhasznlás jellegéből adódóan.
-
válasz
Drizzt
#16816
üzenetére
Ilyesmire már nincs idő. Banki core rendszerekről van szó, nagyon sok hívásról. Az architectek már törik a fejüket a dolgon, bár az első fos megoldást is ők találták ki.
Szerencsére nem nekem kell ezt megoldanom, én csak szenvedő alanya vagyok a dolognak.#16815mobal
Hát, bekesseled az egész banki adattárházat? Az a gond, hogy számtalan szolgáltatásra hivatkozik a kompozit service, és elágazások is vannak benne. Hja, PL/SQL jobokat is hív. -
#16811
Vision
veterán
Netszemete
#16797
válasz
Netszemete
#16797
üzenetére
Azt tapasztalom a business alkalmazásoknál, hogy nem a kód a szűk keresztmetszet, hanem az architektúra, illetve a sok DB kapcsolat. Most szenvedünk egy olyan kompozit szolgáltatással, ami 20+ egyéb szolgáltatásból szedi össze az adatokat. A leggyorsabb futásidő 30 másodperc, ezt kéne levinni <1-re.
Amikor megnézték a futási statot, akkor kiderült, hogy az idő felét DB-műveletek viszik el. Kódhibával alig-alig találkozok. -
válasz
Tigerclaw
#13300
üzenetére
Mondjuk erre milliókat kifizetni erősen értelmetlen dolog. Eleve nem mennék olyan helyre képzésre, ahol nincs aktív oktatás. Egyik kollégám járt a Ruanderhez (én is szerettem volna, de nem volt időm). Náluk heti 2 alkalommal 5-től - 9-ig tantermi oktatás van, egészen az alapoktól hónapokon keresztül. Java SE-vel kezdenek, aztán Java EE. Ha jól emlékszem, akkor a 2 együtt fél évig tart, és 350 ezer forint. A végére eljutnak a webservice írásig, Hibernate, talán a springbe is belekóstoltak. Innen szerintem egy Junior pozit már meg lehet csípni egy kis plusz önképzéssel.
-
#4842
Vision
veterán
csucsbicep
#4841
válasz
csucsbicep
#4841
üzenetére
Most komolyan velünk akarod megíratni az egyetemi házidat? Vannak erre bevált emberek az évfolyamon, fizess, és megcsinálják...
Csak megmutatni azt, hogy tényleg mekkora jelentősége van a tervezésnek. És itt rohadtul nem kódminőségről van szó, hanem architektúráról. És tényleg sokan vannak, akik nem láttak ekkora rendszereket, és könnyen mondanak triviálisnak tűnő, de használhatatlan megoldásokat. 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Elektromos autók - motorok
- Miért vezet mindenki úgy, mint egy állat?
- Hamarosan megjön az ASUS házak új zászlóshajója
- Formula-1
- sziku69: Szólánc.
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Redmi Note 14 5G - jól sikerült az alapmodell
- Milyen videókártyát?
- TCL LCD és LED TV-k
- További aktív témák...
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- Akció! Windows 10 pro OEM licenc kulcs 64/32 bit activation key licensz, liszensz,kulcs
- Bomba ár! Lenovo ThinkPad T450s - i5-5GEN I 12GB I 500GB SSD I 14" HD+ I Cam I W10 I Garancia!
- 134 - Lenovo Legion Pro 7 (16IRX8H) - Intel Core i9-13900HX, RTX 4090 - 3 év garancia
- Ritkaság! Hibátlan! Intel Core I9 13900KS Processzor!
Állásajánlatok
Cég: FOTC
Város: Budapest