- Meggyi001: Hasznos helyek és tippek Párizsban, amiket jó eséllyel keresni is fogsz...
- Luck Dragon: Asszociációs játék. :)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- GoodSpeed: 24 éves a Windows XP! Nézzen ki úgy a Windows 11 mint az XP?
- GoodSpeed: Kell-e manapság egérpad vagy sem?
-
Fototrend
Ú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
DanielXXXV
#4841
válasz
DanielXXXV
#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!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- Androidos fejegységek
- AMD GPU-k jövője - amit tudni vélünk
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Elemlámpa, zseblámpa
- Képernyős trükkök növelik a notebookok üzemidejét
- Jogsik - tanuljunk vezetni
- AliExpress tapasztalatok
- További aktív témák...
- Lenovo Tab P12 tablet és Pes Plus alig használt még 3 hónap garanciával
- Bomba ár! HP ProBook 650 G5 - i5-8265U I 8GB I 256GB SSD I 15,6" FHD I Cam I W11 I Garancia!
- Bomba ár! Dell Latitude E7440 - i5-4GEN I 8GB I 256SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- Bomba ár! Lenovo ThinkPad Yoga X390 - i7-8565U I 8GB I 256SSD I 13,3" FHD Touch I Cam I W11 I Gari!
- Bomba ár! Dell Latitude E5450 - i5-5GEN I 4GB I 320GB I 14" HD I HDMI I Cam I W10 I Gari!
- Azonnali készpénzes Sony Playstation 5 lemezes és digitális felvásárlás személyesen/csomagküldéssel
- Samsung Galaxy S21 Ultra / 12/256GB / Kártyafüggetlen / 12Hó Garancia
- ÁRGARANCIA! Épített KomPhone Ultra 9 285K 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- 121 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 - 4 év garancia
- Lenovo ThinkPad T14s Gen 2 i5-1135G7 16GB 512GB 1 év garancia
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest