-
Fototrend
Új hozzászólás Aktív témák
-
addikt
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...
-
addikt
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.
-
addikt
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.
-
addikt
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.[ Szerkesztve ]
-
addikt
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.
[ Szerkesztve ]
-
addikt
Ü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.
[ Szerkesztve ]
-
addikt
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ő.
-
addikt
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.[ Szerkesztve ]
-
addikt
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.[ Szerkesztve ]
-
addikt
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.[ Szerkesztve ]
-
addikt
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.
[ Szerkesztve ]
-
addikt
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.
[ Szerkesztve ]
-
addikt
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.[ Szerkesztve ]
-
addikt
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.
-
addikt
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ó.
-
addikt
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?
-
addikt
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.
-
addikt
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.
-
addikt
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.
-
addikt
válasz K1nG HuNp #17878 üzenetére
Az, ami a krétánál történt védhetetlen. Eleve hogy lehet hozzáférése a fejlesztő cégnek produktív rendszerhez? Hogy lehet teljes hozzáférése egy szaros PM-nek produktív rendszerhez? Hogy lehet az, hogy meg tud nyitni fertőzött URL-t? Megannyi kérdés, és sehol egy válasz.
Ez a legdurvább adatvédelmi incidens az ország történetében, és megy a nagy maszatolás. Mert a NER-es haveré a cég. Őrület.
A pentestet meg kell rendelni. Ezt nyilván nem tette meg a kréta fejlesztője, mert akkor régesrég kiderültek volna ezek a problémák. Mégis hogyan derült volna fény ezekre a sebezhetőségekre törvényes módon? Ettől még azok a srácok, akik megcsinálták bűncselekményt követtek el.
-
addikt
A programozásnak pont a lényege komplex kódok alkotása...
Kis szőrözés, és lehet, hogy amúgy erre gondoltál, de szerintem a programozás lényege a legegyszerűbb működő megoldás szállítása az adott - jellemzően üzleti, de nem feltétlenül - problémára. Amennyire látom, a fejlődés pont abba az irányba megy, hogy minél kevésbé legyen komplex a kód. Ugye a magas szintű nyelvek éppen erről szólnak. De cáfoljatok meg, én már csak a pálya széléről ugatok.
Persze most nem a pmonitor által elképzeld dolgokról beszélek, hanem a ténylegesen leszállított kódok 99,99%-áról.
[ Szerkesztve ]
-
addikt
Uhh, nem akartam én ennyire mélyen belemenni. Tömören próbáltam megfogalmazni alapvető trendeket, amiket látok. Nyilván nem a gányolásra gondoltam az egyszerűség alatt, hanem arra, hogy az üzleti igényre nem a pmonitor által folyamatosan pedzegetett elv a válasz, hanem a peremfeltételek mellett (fenntarthatóság, stabilitás, fejleszthetőség, biztonság, stb.) az egyszerű és gyors implementáció. Egy AI leletező szoftver kódbázisa nyilván komplexebb lesz, mint egy random Java weboldalé. De amúgy nincs köztünk vita semmiben.
-
addikt
De mondjuk egy bonyolult sql lekérdezést van, hogy nem tudsz megoldani 1000 sor alatt, ha meggörbülsz sem.
Abban egészen biztos vagyok, hogy ez nem jó. Ilyen esetben át kell variálni a DB-t, kiforgatni, köztes absztakciós réteget beiktatni, bármit. 1000 soros, de akár 100 soros SQL is kerülendő.
Nem attól lesz egy kód rossz, hogy hosszú, hanem ha spagetti, felesleges köröket tartalmazz.
Semmi konkrétumot nem mondtam a kódminőségről . Sőt, igazándiból gyakran a hosszabb kód az egyszerűbb. És persze, emvy leírta, hogy az egyszerű fogalom milyen nehezen megfogható. -
addikt
...enélkül a fejlesztők nem fognak közös nyelvet beszélni.
Ez amúgy minden szakterületen fontos. Ha nem ismered a szakzsargont, akkor hülyének fognak nézni, hiába vagy amúgy tök jó képességű. Lehet erre azt mondani, hogy felszínesség, de egy munkahelyen nem nagyon van arra idő, hogy körmondatokban fogalmazz.
Mondjuk ezek át tudnak menni egészen abszurdba. Vannak kifejezések, amik elterjednek, és aztán mindenki elkezdi használni őket 2-pofára. Az egyik helyemen ilyen volt a "perzisztens" szó, ami egy tök jó kifejezés, de gyakorlatilag felesleges használni a fejlesztési feladatok nagy részében. Mégis minden meetingen repkedett a perzisztens, én meg nem értettem, hogy minek kell ezt állandóan mondogatni, hát mindenki tudja, hogy mi ez.
[ Szerkesztve ]
-
addikt
....persze más skillek kellenek hozzá
Azért na! Ez most olyan, mintha azt mondanád, hogy az árokásó cigány munkája == egy atomfizikus munkájával. Hiszen csak más skillek kellenek hozzá.Szóval de, bonyolultabb programozónak menni, mint lakatosnak, vagy burkolónak. Előbbi jó esetben egyetemi végzettséggel jár együtt, utóbbiakhoz még érettségi sem kell.
És akkor most ne menjünk bele a kell a programozónak diploma/nem kell utcába!
-
addikt
...ne lehetne egy villanyszerelő is profi abban, amit csinál, és egy programozó ne lehetne középszerű, vagy csak szimplán szar.
Ez nem cáfolja azt, amit írtam. Simán csak arról van szó, hogy a villanyszerelőség csúcsához messze gyengébb skillek kellenek, mint a programozóság csúcsához. Én végeztem hobbiból szakmunkás képzéseket, ott számtalanszor elhangzott, hogy a szaki NEM tervez semmit, hanem kivitelezi azt, amit a mérnök megtervezett. A kivitelezés nem kreatív szakma, szabványokat kell betartani, és kész. Persze ott is fontos az önképzés, de közel sem olyan szinten, mint az IT-ban.
egy sql lekérdezést megcsinálásában
Az SQL-tákolás nem programozás by definition. Ettől függetlenül ez is igényel szaktudást, főleg komolyabb riportok esetén.
Pont ugyanolyan nehéz, mint megtervezni egy ház elektromos hálózatát és bekábelezni.
A ház elektromos hálózatát nem a villanyszerelő tervezi, hanem villamosmérnök a gépészeti kiviteli terv részeként. És de, sokkal egyszerűbb jól bekábelezni egy épületet, mint megírni jól egy webáruházat. Mindkettőt csináltam már nem is egyszer. Nem véletlen, hogy a melósok nagy része ostoba jobbágy. Azért a programozók többségéről ez nem mondható el!
És akkor most a morális kérdésekbe bele se menjünk (a szakik nagy része úgy hazudozik össze-vissza, mint a vízfolyás)!
[ Szerkesztve ]
-
addikt
emberek jo resze igazabol lofaszhoz se ert
A most már kvázi CTO - aki btw a legjobb fejlesztő, akivel valaha dolgoztam - haverommal szoktunk azon keseregni, hogy a fejlesztők nagy része objektív hülye és/vagy nem hajlandó gondolkodni. Agyatlanul lefejleszt valamit, ami le van írva, és még véletlenül sem gondolja végig, hogy van-e értelme.
-
addikt
A hitelesség biztosításához - a technológiából adódóan - nagyságrendekkel több erőforrást éget el, mint egy centralizált rendszer. Valódi előnye pedig nincsen. Nem véletlen, hogy a nagy blockchain láz idején is a csillogó szemű hívőknek semmilyen konkrét érvük nem volt mellette, csak az olyan abszurditások, minthogy: vége az eddig létező pénzrendszernek, kormányok fognak megdőlni, és társai.
-
addikt
Még annyit hozzátennék, hogy a nagyon komplex olvasási műveleteket jellemzően kiszervezik az adattárház rétegbe. Ott meg aztán mindenki úgy buzul az adatokkal, ahogy akar.
Mondjuk arra kíváncsi vagyok, hogy a blockchain olvasási sebessége miért gyorsabb, mint egy centralizált rendszeré. Ugyanis ilyen állítás is elhangzott előbb.
-
addikt
Amikre ráláttam nagy rendszerek (telco, finance, retail), ott szó sem lehetett arról, hogy ne tároljanak le nyers adatokat. Egyrészt azért, mert az adat a legnagyobb kincs (ez már sok-sok éve ki lett mondva mindenhol), másrészt az aggregáció logikája nem stabil soha, ezért sosem szabad a legalsó szintre rakni. A big data módszerek terjedésével ez hatványozottan igaz.
Nincs 100%-os rendelkezésre állás, soha senki sem állította ezt magáról. A tizedesvessző utáni 9-esek számán szokott megmutatkozni a minőség, és persze az ár is.
[ Szerkesztve ]
-
addikt
Persze, tudom. Ezért csaptam oda a retailt is (most pont ilyen helyen dolgozom), ahol megdöbbenek, mennyire szabályozatlan minden, mégis mindent megőriznek.
Egyébként az általános hozzáállás az, hogy az adat tárolása olcsó, szóval inkább őrizzük meg, hátha jó lesz még valamire. A szelekció önmagában egy rakás architect munkaóra lenne. A storage meg filléres tétel már.
[ Szerkesztve ]
-
addikt
válasz sztanozs #18420 üzenetére
Háát, az ilyen szerver log típusú dolgokat nem sorolnám ide. Nem mindig éles a határvonal, de például egy proxy esetében biztosan. Plusz ezeket nem is db-ben szokás tárolni, hanem fájlrendszeren plain textben. És ne gyere most azzal, hogy nálatok esetleg pont nem így van, mert akkor a kardomba dőlök!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!