Fórumok
Ma reggel vettem észre, hogy a hajnalban még használt MobilBank app szó szerint eltűnt a telefonomról, nem elérhető a beállítások között sem, a futó alkalmazások között pedig nem nyílik meg. Újraindítás után sem találtam meg. Csak frissíteni lehet a George-ra, ami sajnos még szerverhiba miatt nem működik.
Más is találkozott ezzel? Eddig csak úgy tudtam, "veszélyes" alkalmazásokat töröl távolról a Google, ilyen jellegű frissítés kikényszerítéssel még nem találkoztam.
Hozzászólások
https://hup.hu/node/172598
Egy ideje minden alakalommal mikor beléptem írta, hogy február 8 án ez lesz.
A régi már nem, az új még nem működik :D Ez van.
Bár nekem most megy, bár kicsit lassan. Kell 1-2 nap mire összeáll szerintem.
Fedora 38, Thinkpad x280
Works for me. Egyelőre frissítés nélkül simán beléptetett és működik. Nem lassabban, mint korábban...
Szerintem ehhez nem kell a Google, az Erste ha akarja, akkor kitol neked egy frissítést, ami kvázi törli a régit.
marmint indirekt. egy android app nem tudja magat modositani, csak android-on keresztul, az meg rakerdez a user-nel, meg amugy is jog kell hozza.
azt lehet, hogy az app-ben van egy remote kill switch, kvazi, mintha kihuztak volna a remote API -bol a dugaszt.
de eltuntetni nem lehet.
Ezen felul persze az app store auto update-t ertelmes ember kikapcsolja, pont ezert. nincs orvul, segged alatt update-elt app.
Olyan nincs, hogy ez a Google Play szerint ugyanaz az app, mint a Mobilbank, csak más neve és ikonja lett?
A fura az volt, hogy a telefon alkalmazáslistában nem szerepelt, de frissítésként felajánlotta a Google Play, de megnyitni nem engedte.
De igen, pontosan ez a helyzet. A csomagnév maradt pegasus.project.ebh.mobile.android.bundle.mobilebank, az aláíró kulcs is ugyanaz az f5bd861b33e5bf77d47a3ebee44f30d1. A név változott MobilBank-ról George-ra, illetve a launcherben megjelenő aktivitás a korábbi pegasus.project.erstebank.mobile.android.bundle.mobilebank.ui.splash.SplashActivity helyett at.beeone.george.SplashScreenActivity. Nem minden launcher kezeli jól, ha menet közben változnak az indító aktivitások, ilyenkor előfordulhat, hogy a régi ikon még látszik, de nem működik, az új pedig még nem jelenik meg. A launcher (vagy a telefon) újraindítása megoldja ezt a problémát.
Újraindítottam, illetve az auto update is ki van kapcsolva.
Nalam az update lecserelte a regi mobilbankos appot a George-ra, egyuttal a kitett ikonja is eltunk. Az utobbit ujra kitettem, es jo lett.
A strange game. The only winning move is not to play. How about a nice game of chess?
Ki van kapcsolva az auto update, ezért lepődtem meg, hogy szó szerint eltűnt a régi.
Szerintem kapcsold vissza.
Bár érdekelne egy érvelés emellett a bad practice mellett.
Nem tudom, hogy a posztolónak pontosan mi volt a tapasztalata, de az in-app update feature-rel le lehet blokkolni egy alkalmazást szinte teljesen:
https://developer.android.com/guide/playcore/in-app-updates
Annyi kell hozzá, hogy az alkalmazás észlelje, hogy egy kritikus frissítés érhető el a play store-ból, és tetiltja magát.
Banki alkalmazasnal nem is hogy bocsanatos dolog, hanem egyenesen elvarhato ez a mukodes.
Error: nmcli terminated by signal Félbeszakítás (2)
Köszi az infót, ezt nem tudtam. Érdekes módja ez az app staged rolloutnak...
Nade akkor sem tunik el az app, csak feldob egy dialog-ot indulaskor.
Nem tudom, mit gondol az Erste a mobil applikációkól, de nekem az első benyomásom negatív az új George (WTF George?) appról... A régi mobilbank nem volt egy vizuális orgia (szerencsére), viszont hamar meg lehetett benne mindent találni. Az új csak kibasz két widgetet a nyitóképernyőre, az egyik ráadásul valami reklámbanner-szerűség, ami az Erste mindenféle okosságát reklámozza. Aztán lehet lapozgatni, görgetni jobbra-balra, hogy valami infót megtalálj. Legalább a számomra fontosabb funkciókat ki lehetne tenni az elejére - de nem lehet, vagy legalábbis nem triviális, hogyan lehetne.
Amikor végre sikerül eljutni a tételes tranzakciókhoz, akkor ugyan ki tudja tenni a Spar meg a Lidl színes logóját (ami tényleg létszükséglet), cserébe a magyar ékezetek egy részével hadilábon áll. Gáz.
Megnéztem. Az enyém egy dashboarddal indul, ami kiteszi egymás alá a számláimat és a hitelkártyámat.
Áttekinthető, sallagmentes. Egy bajom van, hogy nem lehet az engem érdeklő számlákat felülre tenni, így pl. a hitelkártyához scrollozni kell.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
A Profil/Termékeid menüpontban át lehet rendezni a számlák sorrendjét, majd jobb fent Mentés gomb.
Nálam ez működött.
Köszi, ez hasznos.
Mondjuk nem túl intuitív, de legalább van rá lehetőség.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Velem egy regresszió már szembe jött: csak 24 órára lehet átállítani a kártyalimitet, többr vagy épp kevesebbre nem (oké, a rövidebb idő megoldható úgy, hogy amikor nem kell, visszaállítom mondjuk 2 Ft-ra, és 24 óra múlva visszarakja 1Ft-ra - Visa Virtuális kártya)
A kezdőképernyőre kirakott ikon nálam szürke lett az új verzió telepítése után, de az alkalmazások között ott volt az új verzió, és megy is.
Ha én MNB lennék, minden banki appnak ki kellene tudni renderelni az összes számla egyedi nevét és aktuális egyenlegét az ikonra kattintás utáni 1 másodpercen (leszámítva, amíg a kódot beírod, vagy Face ID, stb) belül.
És milyen hálózati infrastruktúrát alárakva?
Olyat, ami a banki tobb 10-100 mrd -s eredmenyekbe is belefer?
Error: nmcli terminated by signal Félbeszakítás (2)
Nem a banki oldalt kérdeztem. Mérni, illetve határok közé szorítani szeretnél egy időtartamot, amire kifejezetten jelentős hatással van az ügyféloldali eszköz milyensége is, és az üf - bank közötti egy vagy több harmadik fél szolgáltatása is.
Erre azért vannak egészen objektív mérési módszerek, nyilvánvalóan nem a másfél soros hup kommentemet gondoltam volna Ctrl-C Ctrl-V törvénybe iktatni. :)
Rengeteg olyan projektet láttam, ahol az SLA-ban ilyen kitételek voltak, és mindenhol sikerült közös nevezőre jutni, hogy milyen feltételek között kell garantálni az elérési időt. Annál sokkal nagyobb és sokkal kisebb cégeknél is, mint egy Erste Hungary. Ez gondolom megint ilyen ungarische kereskedelmi banki gyakorlat, hogy nem lehet, jó az úgy. :P
Tipikusan ~realtime mukodo dolog pl a websocket. Nagy talalmany.
Error: nmcli terminated by signal Félbeszakítás (2)
Egy random mobbilos kliensen, aminek a garantált hálózati sávszélessége 0kbit/s. Oké, hogy L7-ben van "azonnali" megoldás, de mire L7-ből L1 lesz, majd átmegy az adat, és L1-ből ismét visszamászik L7-re, annak az ideje kifejezetten nem garantálható, hogy mennyi. Nem, websocket-en sem.
Más iparágakban hogy oldják meg, hogy közel realtime látod ennél komolyabb hálózati forgalom eredményét is? Egy másodperces késleltetéssel már többszereplős videokonferenciát is lehet csinálni, publikus felhővel, gombokért. Hogy van az, hogy egy random magyarországi bank képtelen 10 másodpercen belül kirajzolni egy statikus számot, ami az én esetemben pl. havi max 5 alkalommal változik? :)
Egyébként senki nem beszélt 100%-os SLA-ról. Ha tízből kilencszer sikerül, az már egy baromi nagy előrelépés UX-ben. Valaminek a válaszidejét megmérni sem rakétatudomány, rengeteg projektben van olyan követelmény, hogy X időn belül response-t kell adni, és hidd el, meg lehet csinálni. Mérésekkel, SLA-val, minden bizbasszal. Senki nem mondott olyat, hogy az MNB-nek a puszta közepén kéne mérni az elérési időt, ahol térerő sincs. :)
A "megoldják" és a "kötelezően renderelje a kliens 1s-en belül az aktuális számlaegyenleget" között azért van néhány árnyalatnyi különbség. (mert az eredti felvetés ez volt: 1s-en belül a kliens a felhazsnálói felületen jelenítse meg az egyenleget)
Lehet mérni, tudom - dynatrace jó dolog (ha nem nézed meg, hogyan is működik/épül fel...), szép dolog, de ettől még kötelezően előírt 1s-es időlimitet adni olyanra, aminél a sebességre hatással lévő komponensek egy igen nagy szeletére nincs hatása a banknak, nos... Bár láttunk már a törvényalkotótól fasságot máskor is, ez igaz :-P
Akkor máshogy fogalmazom. Meg lehet mérni valamit úgy is, hogy nem stopperrel méred, ahogy a mobilodat nyomkodod. Akár úgy is, hogy a komponenseket külön méred. Értelemszerűen az 1 sec limit arra vonatkozna, amire a banknak van ráhatása. Ha nem jön össze az 1s, mert basztad kifizetni a telekomnak a mobilnetet, és ezért belassított, azt nem számolnám bele. Ha az óceán közepén vagy, és húszezer forintonként pörgeted a megabájtokat maritime APN-en keresztül, azt sem számítanám bele. Tényleg nem érted, vagy csak próbálod úgy csavarni a dolgot, hogy lehetetlennek tűnjön egy olyan dolog, amit a bankvilágon kívül már kb. mindenki megoldott?
Ne próbáld már bemagyarázni plz, hogy azért tart 10+ másodpercig megjeleníteni az egyenlegem, mert lassú a wifi otthon, vagy szar a mobilom, vagy mittudomén, de a banknak biztosan nincs semmi ráhatása. Légyszi, ezt az egyet azért ne. :)
Ismétlem (utoljára, utána elengedtem a témát, mert úgy érzem, nem fogok tudni újat mondani): a javaslatom nem arról szólt, hogy a földön mindenhol, minden eszközzel 1s legyen kattintástól kattintásig, hanem hogy a tetves banki API ne 10 másodpercig keresgélje az egyenlegem. Úgy gondolom 2021-ben, amikor már önvezető autók vannak az utakon, géppel műtenek betegeken neten keresztül, tízezer ember hallgat egy előadást pár másodperc késéssel, ez nem egy lehetetlen gondolat.
szerk: és most nem olyan problémákról beszélünk, hogy a 24 óránként futó batch 25 órán keresztül fut az AS400-on, hanem hogy egy HTTP GET kérés 1 másodpercen belül visszaadjon egy <1 KB-s json-t.
Láttam olyat, aki hallott olyanról, akinek voltak kifejezetten end-to-end mérési adatai (dynatrace), és bizony a lassulásokban mobilos végpontok esetében döntően a mobilhálózat, illetve az üf.-nél lévő mobilos böngésző volt a ludas.
" a javaslatom nem arról szólt, hogy a földön mindenhol, minden eszközzel 1s legyen kattintástól kattintásig, hanem hogy a tetves banki API ne 10 másodpercig keresgélje az egyenlegem. "
A javaslatod egészen pontosan ez volt:
"Ha én MNB lennék, minden banki appnak ki kellene tudni renderelni az összes számla egyedi nevét és aktuális egyenlegét az ikonra kattintás utáni 1 másodpercen (leszámítva, amíg a kódot beírod, vagy Face ID, stb) belül"
Ha a banki API pártíz ms-en belül válaszol, és visszaadja az adatot, de a telefonod rottyon van, és nem igazán gyors, elelnben lassú procival van megverve, akkor mi van? És mi van akkor, ha van mondjuk 5 vagy 10 számlád? Akkor van 100-200ms/darabnyi idő adatot lekérdezni, a visszakapott adatokat átpasszolni a megjelenítő rétegnek, és a képernyőre kirakni azokat. (5 számla pillantok alatt összejön: folyószámla, moratórium számla, hitelkártya, gyerekek számlája (rendelkezési jog van rajta, ezért látom), megtakarítások, és máris sokasodnak a megjelenítendő adatok (az "egyenleg" mellé oda köll tenni a zárolásokat is...)
Ne már. Akkor hogy van az, hogy a brokercégem appja login után kb 1-2 másodperccel már realtime portfólió adatokat mutat, de a 2-3 magyar kereskedelmi banki app meg teker vagy 5-15 másodpercig, mire kijön 1 db statikus szám?
Akkor azt nem mérjük. Direkt leírtam, hogy nem Ctrl-C Ctrl-V kellene jogszabályba illeszteni a kommentemet, hanem végiggondolni, hogy mit és hogyan lehet szabályozni. Ne haragudj, de az, hogy ez lehetetlen feladat lenne, az bullshit. Ezt onnan tudom, hogy van több (külföldi) bankkal, brokerrel, stb. kapcsolatom, akiknek sikerült.
Ha szőrszálakat hasogatunk, akkor legyen 1+(0.5*$countSzámlák) másodperc a limit, de baromira nem ez a lényeg. :)
A gond továbbra is azzal van, hogy ennél jóval komplexebb problémákat más iparágban simán megoldanak, de még ebben is, ha elindulsz nyugat felé.
Az, hogy ezt mérhetően, számonkérhetően meg lehessen csinálni, na az a bullshit. És ez nem banki app, hanem brámi esetében igaz.
Azt, hogy mérhetően, számonkérhetően meg lehessen csinálni kontrollált körülmények között, azt nemhogy nem lehetetlen megcsinálni, hanem meg is kellett már csinálnom. :)
Csak épp a való életben nem kontrolláltak a körülmények.
Ennek megfelelően a számonkérés sem egy random kisorsolt user dzsunkatelefonján történne a mekis wifin, hanem a szabályozásban (~= SLA) meghatározott mérési módszertannal. :)
A telefonom tetszőleges (gyors) weblapot másodpercek alatt megjelenít. Bizonyos sport stream app 2-3 másodpercen belül betölt, rányomok a meccre, 5 másodpercen belül a stream-et nézem. Youtube app másodpercek alatt elindul, egy videóra nyomva kb. instant kezdi lejátszani (tizedmásodperc nagyságrend lehet a delay). Ezt tudják az otthoni neten, a céges neten, haverok/család/stb. helyeken, illetve mobilneten is, legalábbis 100-ból 95 esetben simán megy.
Az erste korábbi netbankjánál, illetve ennél a dzsordzs nevű csodánál többször is előfordult az, hogy indításkor az ujjlenyomat beolvasása után annyit homokórázott, hogy a 30 másodpercre beállított screenlock előbb bekapcsolt, mint hogy ez a csoda behozza a kezdőképernyőt az oda tartozó adatokkal. Most mértem egyet ezzel a retekkel, 3 másodperc kellett neki, hogy bekérje az ujjlenyomatomat. Majd miután ez sikerült, mindössze 16 másodperc után már meg is mutatta a 2 (kettő) darab számlámat, az egyenleggel és az elérhető összeggel.
3-5s az elindulás és a biometrikus azonosítás, utána 13-16s alatt dobja fel négy számla egyenlegét. Lehetne gyorsabb, ez igaz (másik mobilbanki app az utolsó tranzakciók listájával együtt bármikor 10s-on belül felhozza az egy szál számlám egyenlegét - igaz, ott nincs cloud, nincs PFM, meg egyéb kényelmi "ingyombingyom" - és garantáltan magyarországi vasakon fut csak), de ez pont az a válaszidő, amit még el lehet fogadni.
Ezek közül melyik kell az egyenleg megjelenítéséhez? Nem lehet a háttérben tökölni PFM-mel?
10 másodperc az borzasztóan sok, pláne mobilon.
A legfeljebb 10s ott az app indulása, biometrikus azonosítás és kezdőoldal betöltés egyben akkor, ha épp sz@r a mobilnet :)
Nekem Erste esetében az a gyanúm, hogy "messze van" a mobilbanki frontend a számlavezető rendszertől, és az egyenleg lekérdezés sok olyan lépésből áll, amit bőven ki lehetne, illetve ki kellene optimalizálni a rendszerből. De ez csak egy tipp, semmi több.
Generikus hibának tűnik, egy szimpla háttérszín-váltás is hosszú másodpercekig tekeri a UI-t.
KH cucc is 10-15sec alatt jut el onnét, hogy rányomok, hogy belépek addig, hogy megjeleníti a számlák adatait, igaz utána már gyors (ebbe benen van a facetime azonosítás is).
Domain, tárhely és webes megoldások: aWh
Ott van a lenyeg. Engem nem zavar, hogy a kapcsolatfelepites, authentikacio, tokenmokolas, stb. sok ideig tart, de utana porogjon...
Error: nmcli terminated by signal Félbeszakítás (2)
El lehet fogadni, persze. Azért, mert olyan sok választásod van ám. Ha nem fogadod el, akkor mégis mit csinálsz? Másik netbank appot használsz? xD Az egyedüli lehetőség az, hogy bankot váltasz, én ezután a dzsordzos faszkodás után ezen komolyabban el is fogok gondolkodni, pedig csak huszonéve vagyok náluk.
Nagy szar ez az egész, 16 másodperc, come on, egy perc negyede elmegy a semmire. Mert nem képesek normális rendszert összetákolni, hanem jó ez _szerintük_ nekem. Mert én annyira ráérek, ugye.
Egy utalásnak országon belül _5_ másodpercen belül _kell_ teljesülnie, azt hiszem ezzel nem mondok nagy újdonságot. Mindezt úgy, hogy a saját számlaegyenleg ellenőrzése után egy másik bankkal kell kommunikálni, ahol nyilván megtörténik a számla létezésének az ellenőrzése és a pénz jóváírása, illetve a hatósági levonások és hasonlók ellenőrzése is, meg még egy csomó dolog, amire nyilván nem is gondolok. Aztán meg a visszajelzés, hogy a tranzakció sikeres-e, vagy nem.
Na ehhez képest a _saját_ számláim és azok egyenlegének a megjelenítésére az elfogadható szintidő 1 másodperc, annál semmiképp se több.
"Nagy szar ez az egész, 16 másodperc, come on, egy perc negyede elmegy a semmire. Mert nem képesek normális rendszert összetákolni," - szerintem jelentkezz chief architect pozícióra, és mutasd meg, hogy kell...
Az IG3 működését kifejezetten leegyzserűsítetted, ez az egyik. A másik, hogy ott azért a résztvevők (mind a hárman) kifejezetten magas rendelkezésre állású, dedikált eszközöket és hálózati útvonalakat használnak az adatcserére.
"Na ehhez képest a _saját_ számláim és azok egyenlegének a megjelenítésére az elfogadható szintidő 1 másodperc, annál semmiképp se több." - Ismét a kérdés: hány számla esetén? mert nekem per pillanat négy számlát jelenít meg, melyek között van folyószámla, hitelkártya (másik rendszer), moratórium számla (nullás, de azt is meg kell mutatni) - és még lesz mellé pár termék, ha úgy alakul.
Tudod mit? Legyünk nagyvonalúak! Legyen számlánként 1+1*$countSzamla másodperc a limit, négy számlánál még az is a "pont elfogadható" 10 másodperc fele. :)
Úgy gondolom, hogy értelmesen is hozzá lehet állni a feladathoz, pl. limitálni az instant kiírandó számlák darabszámát, mint ahogy azt néhány másik bank csinálja. Ha a nullás technikai számla ugyanúgy 10-30 másodperc marad, az kit nérdekel, azzal együtt lehet élni.
Egyébként a legelborultabb lakossági ügyfélnél is nagyon maximum átlagban napi tízszer ha megváltozik az egyenleg, de szerintem sokat mondtam. Minek ehhez elmenni a számlavezető rendszerhez?
"Egyébként a legelborultabb lakossági ügyfélnél is nagyon maximum átlagban napi tízszer ha megváltozik az egyenleg, de szerintem sokat mondtam. Minek ehhez elmenni a számlavezető rendszerhez?" - mert mondjuk nem a reggeli/1 órával/x perccel ezelőtti egyenleget _kell_ megmutatni?
Bár lenne valami megoldás arra, hogy egy ritkán változó, statikus adatot eltároljunk valami gyors elérésű helyre, hogy ne kelljen mindig a core rendszerben kapálózni érte, és ha mondjuk megváltozna, akkor felül lehetne írni az új értékkel. :)
Nomostan az "egyenleg" az lehet könyvelt egyenleg, meg elérhető egyenleg, azaz rögtön minimum két értéket kell legalább két helyen kis késleltetéssel szinkronban tartani. Ezt vagy úgy csinálják, hogy egy helyen tárolják, és aminek/akinek kell, az "odamegy" érte (net/mobilbank esetén nem biztos, hogy jó ötlet), vagy a netbank/mobilbank is tárolja az értékeket, amit vagy akkor frissít be, amikor az üf. explicit rákérdez, hogy "mennyi" (bejelentkezik az alkalmazásba/netbankba), vagy pedig a számlavezető rendszer "push"-olja felé a változást, miután a változást generáló tranzakció megfelelő állapotát beállította (pl. bejött egy kártyás vásárlásról egy zárolás, akkor az elérhető egyenleg csökken, a könyvelt majd csak akkor, ha a zárolt összeg terhelése is megtörténik.)
Az átlag usert elsősorban az érdekli, hogy hány forintja van még, amit elkölthet, mielőtt jönne a következő fizu. Szerintem szinte senki nem foglalkozik vele, hogy a hitelkártya tranzakciók mikor könyvelődnek le, de ha mégis, az majd kivárja szépen a 10-30 másodpercet a részletes nézet betöltésekor. :)
Hááát... ha valaki azt nézi, hogy egy hitelkártyával mennyit tud még elkölteni ahelyett, hogy mennyit költött el eddig, az szeret veszélyesen élni.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
OK, akkor hitelkártyánál 2*32 bitet kell cache-elni, de miért érdekes ez? :) Ettől még a mindennapokban, az átlagos usernek nem érdekes infó, hogy egy hitelkártya-tranzakció zárolt, vagy könyvelt - emiatt én nem bonyolítanám a splash screenen megjelenített egyenlegeket, ha az a cél, hogy gyorsan hozzáférhető legyen.
Nomégegyszer... Mikori, mennyivel korábbi adatot cache-eljen a netbank/mobilbank? És mi triggerelje az eltárolt adat frissítését? Van oylan, ahol a számlavezető rendszer "push"-olja a netbank/mobilbank felé az összes, ott megjelenítendő változást, és van, ahol meg a netbank/mobilbank küld egy kérést a számlavezető rsz. felé, hogy mondja meg, mennyi a könyvelt/zárolt/satöbbi összeg az adott ügyfél adott számlájánál. Aztán amikor jön válasz, akkor tudja megjeleníteni. Totál mindegy, hogy az adat mennyi, a kérés/válasz ideje, illetve időpontja/trigger, ami kiváltja azt az a releváns.
"az átlagos usernek nem érdekes infó, hogy egy hitelkártya-tranzakció zárolt, vagy könyvelt" - nagyon nem mindegy a kettő, és tippre az MNB keményen ráharapna, ha csak az egyiket, illetve "valami korábbi állapot"-ot jeneítene meg a felület.
A push elég megbízhatatlan mobilon, én nem a mobilappra támaszkodnék, mint cache.
Én ezt piszkálnám inkább meg. Az egyenleg gyors rendereléséhez mi szükség van egy ilyen felbontásra? Az ID+egyenleg párost kell kivezetni valami gyorsan elérhető API endpointra, az emögött álló adatbázist pedig etetném a számlavezető rendszerből. A "mennyi a zárolt összeg" ráér, ezeket a háttérben be lehet húzni, nem kell hozzá a UI-t blokkolni. Ha a user erre kíváncsi, akkor úgyis ki fogja várni. Nézd meg mondjuk, hogy működik a Revolut app user szemszögből.
Nem véletlenül írtam úgy, hogy "push"-olja. A számlavezetőben történik egy esemény, és a számlavezető rendszer "szól ki" a net/mobilbanknak (jellemzően queue-n keresztül), hogy az x számla kapcsán y változás történt.
"Az egyenleg gyors rendereléséhez mi szükség van egy ilyen felbontásra?" - Melyik egyenleg? (elérhető? könyvelt?) - ez az egyik. A másik, ami szintén megfontolandó, hogy egy kéréssel mit és mennyi információt (és mennyi idő alatt) kap meg a kliens. Sokszor célszerűbb egy kérés-válasz párossal több információt is odatolni a kliensre, nem minden értékre külön "megfutni a köröket".
"Az ID+egyenleg párost kell kivezetni valami gyorsan elérhető API endpointra, az emögött álló adatbázist pedig etetném a számlavezető rendszerből. " - igen, ez a másik lehetőség, amikor a számlavezető rendszerből a netbank/mobilbank számára fontos adatokat az előbbi mondjuk egy queue-n keresztül vagy máshogy tolja ki a netbank/mobilbank alá, és a klienseket kiszolgáló webes alkalmazásszerver onnan szedi öassze, ami kell.
Szerinted a "mennyi a zárolt összeg" ráér - mint írtam, az MNB szerint meg nem biztos - a revolut ilyen szempontból irreleváns, egyelőre maradjunk a hazai szabályozásnak való megfelelés területén.
Továbbra is az elérhető :)
Na, álljunk meg egy picit, én nem azt mondtam, hogy a többit ne írjuk ki. Azt mondtam, hogy az egyenleg renderelhető gyorsan, és utána, a háttérben (már splash screen nélkül) be lehet húzni a többi infót. Egyébként ez biztosan MNB-compliant, az OTP app még login előtt is meg tudja mutatni az elérhető egyenleget. Ha az nem elég, akkor login, még több várakozás, és ott a többi.
"Na, álljunk meg egy picit, én nem azt mondtam, hogy a többit ne írjuk ki. Azt mondtam, hogy az egyenleg renderelhető gyorsan" - Azt is le kell húzni a netbank/mobilbank mögötti valamelyik DB-ből, és ha már bemegy egy kérés, akkor lehetőleg minél több információt toljunk ki egyszerre a kliensre. (Ha csak egy elérhető egyenleget húzna le a kliens (melyik számla?), a többit meg "majd a háttérben", akkro rögtön minimum duplázódna a kérések száma a kliens és a mobilbanki kiszolgál között. És ne felejtsd el, hogy nem egy PoC néhány useres demóról, hanem jelentős ügyfélkört kiszolgáló rendszerről van szó, ahol még pár %-nyi megspórolt erőforrás költsége is szép summa.
Akkor ezert tettek ala egy 2-es Raspberry Pi-t. Legalabbis erzesre annak tunik.
A strange game. The only winning move is not to play. How about a nice game of chess?
Hmm. Revolut fórumok tanúsága szerint vannak időszakok - nem is ritkán - amikor a Revolut app esik/kel. Ha "tetszőleges" bank így viselkedne és ilyen sűrűn, akkor szerintem már az MNB-t ostromolnák a dühös ügyfelek (nem csak a mobilapp, de kártyás tranzakciók is elhalnak ilyenkor). De persze 'legalább ingyen van'... Mellesleg egyre kevésb van ingyen, most is bejelentettek némi plusz korlátozást.
Nem a Revolutot dicsérem úgy általában, hanem azt, hogy képesek olyan csúcstechnológiai bravúrokra, mint egy statikus integer lekérdezése API-n, gyorsan. :) Értem amúgy az issue-kat, én sem vagyok különösebben rajongójuk.
Nem muszáj amúgy a Revoluton lovagolni, az IBKR app a FaceID azonosítás után 1-2 másodperccel mutatja az egyenleget (amiben FX váltás is van), a legnagyobb pozícióimat realtime árfolyamokkal, és a watchlist-em papírjait realtime árfolyamokkal. Ehhez képest a magyar bankoknál egy HUF folyószámla egyenleg kijelzése 10-20-másodperc.
No, akkor fussunk neki... Van a mobil appod, az elindul, biometriával előkotorja a bejelentkezési adatokat, elmegy a mobilbank/netbank kiszolgálását végző webszerverhez, az redirect oda-vissza egy IDM-hez, majd amikor ez megvan ("visszajött" az IDm-tő, megfelelő sütikkel, credential-lal, egyebekkel, akkor ez alapján a netbank/mobilbank elmegy queue-n keresztül, vagy épp a saját DB-hez, összeszedi, milyen számlái vannak az adott üf.-nek, összeszedi mindenek a tranzakciós listáját, egyenlegét, az üf.-nek szóló üzenetek számát, miegyebet, és visszaadja a kliensnek, amit az ezt követően elkezd renderelni. A "miért mindent is egyben" oka egyszerű: egy kérés/válasz elég, nem 10-20 vagy több kérés/válasz párossal operál a motyó. Hogy miért? Nem mindegy, hogy x vagy 10*x kérés kiszolgálására kell méretezni a szervereket.
A KH továbbra is tudja a faceID után 7-10 másodpercen belül produkálni ezeket az adatokat (több számláét ráadásul, nem egyét). Ez ugye egy magyar bank, a magyar szabályozásnak megfelelően.
Domain, tárhely és webes megoldások: aWh
Más is tudja gyorsabban adni, mint George. És? A cloud-os George magyarországi premierje után vagyunk nem sokkal - azt tippelem, hogy lesz még performance tuning.
A cloud az kb. annyit jelent, hogy más valakinek a számítógépe. Nagyjából senkit se érdekel, hogy klód, hosting, self hosted, vagy valami egzotikusabb módon van a kompútör gyuri alatt.
Már többedszerre javasoltam, hogy nem mindent egyesével kell lekérdezni, hanem kell két bucket
Az 1-es bucket egy kérés, a 2-es bucket még egy kérés, a háttérben. Ezzel az egyetlen változtatással (a komplexebb query-k nem blokkolják a UI-t) az app máris sokkal reszponzívebbnek tűnik, és a user kevésbé fog anyázni.
Milyen távolról láttál banki it-rendszereket? Az "egy változtatás" ötletedről nekem ez jut eszembe: https://derrickesharry.blog.hu/2017/03/26/a_csak_egy_mezot
Elég közelről. Retail és IB vonalon is. Még a regulatory oldal sem teljesen ismeretlen. Ha azt szeretnéd hallani, hogy rengeteg banknál az IT tele van TD-vel, és ezért baromi nehéz fejleszteni bármi értelmeset, akkor igazad van, szerintem sok banki rendszernek lenne a szemétdombon a helye.
Mert? Ennél jóval bonyolultabb problémákat is láttam már megoldódni elfogadható idő és költségek mellett. Továbbra is arról beszélünk, hogy 1-3 db integert ki kell írni egy mobilalkalmazásban, UI blocking nélkül. Borzasztóan nehéz feladatnak tűnik :P
"szerintem sok banki rendszernek lenne a szemétdombon a helye." - ebben egyetértünk - sajnos példákat nem mondhatok, de elég csak arra gondolni, hogy hány meg hány alkalmazás működik vastagklienssel...
A "ki kell írni"-hez: Mikori (milyen régi) adat az elfogadható, az hol legyen tárolva, hogyan frissüljön - illetve hogy pontosan mit értünk "kiírandó egyenleg" alatt? Van, akinek a felhasználható a lényeges, van akinek a könyvelt - oké, akkor számlánként két értéket kell kvázi folyamatosan (legfeljebb a "milyen régi felel meg" időközönként) frissen tartani (gyakorlatilag valamennyi tranzakciót követően a net/mobilbanki "árnyék" rendszerben is frissíteni) Miközben ha az user elkattint majd vissza, akkor már az aktuálisat kell mutatni, ami lehet, hogy eltér - amiből jön az üf.panasz, hogy "login után 123 petákos egyenleget írt ki, de a részletesben már 115-öt - ha nem tudják mennyi pénzem van, akkor megyek innen" - és üf. szemmel jogosan küldi el az egész bankot melegebb éghajlatra, hiszen a mobilos app két nézete inkonzisztens adatokat mutat.
Van, ahol úgy csinálják, hogy minden tranzakció után a netbank/mobilbank által nyilvántartott egyenleg is frissül, és van, ahol meg nem, hanem a login triggerel egy adatfrissítést, és a friss adatokat jeleníti meg, vagy épp direktben benyúl valamilyen köztes rétegen át a számlavezető rendszerekbe, és előkotorja az üf. egyenlegeit, mondjuk úgy, hogy röptében. Hogy ez a "röptében" egy töröt szárnyú betonbagoly vagy épp egy vándorsólyom, az más kérdés.
Miért futjuk ugyanazokat a köröket újra és újra? :)
Szerinted az emberek hány százaléka tudja, hogy mi a különbség? Tízből kilenc retail ügyfelet szerintem az érdekel, hogy mennyi pénze van, amit el tud elkölteni, de tartok tőle, hogy keveset mondtam. Ha érdekli, hogy ebből mennyi a zárolt, és mennyi a könyvelt, akkor majd kivárja a 10+ másodpercet, ahogy eddig. Rosszabb nem lett neki. A 90+ százaléknak viszont jobb lett a UX.
Van olyan app itt a telefonomon, ami meg tudja ezt csinálni. Nem kell túlmisztifikálni a feladatot, valahol már megoldották, és működik.
Nekem is van olyan moboilbanki app a telefonomon, ami jóval gyorsabb, mint Gyuri, igaz, funkcionalitását tekintve - nem utolsó sorban a bank által kínált pénzügyi termékek jóval szűkebb köre miatt - jóval egyszerűbb, és mivel nem az az elsődleges számlám, így a PFM funkcionalitást nem hiányolom belőle.
Lehet, neked nem tűnt fel, de zeller hajlandó végletekig ismételgetni a mondanivalóját, ha szükségesnek látja. Nem tűrheti, hogy mások butaságot írjanak, szorgalmas juhászkutyaként próbálja terelgetni az ostoba barmokat. :D
:)
És ha elégedetlen vagyok a közbiztonsággal, akkor jelentkezzek rendőrkapitánynak, ha meg a kormánnyal, akkor pedig miniszterelnöknek, nem? Szerintem nem kicsit szánalmas ez a reakció.
azért javasoltam, mert nagyon az látszik, hogy szerinted te mindenkinél jobban tudod, hogymi kell, és hogy azt hogyan lehet megvalósítani, minden körülményt, szabályt, előírást figyelembe véve.
Nyilván nem előírás az, hogy picsalassú legyen, szóval hagyjuk már a szabályokat és előírásokat. A többi meg bullshit, már ne haragudj. Azt tudom, hogy ez szar. Nem tudom, hogy azért szar-e, mert karcsú alatta a vas, vagy azért, mert szarul van megírva, esetleg a kettő együtt. És ez nyilván nem azt jelenti, hogy én jobban meg tudnám csinálni, de az azért sokat mond, hogy 1 nap alatt sikerült 1,6 pontra lemennie a store-ban 2,1 pontról. Szóval nem volt magasan a léc, de legalább azt se sikerült megugrani. Azóta amúgy már 1,7 pont, gondolom kiadták a dolgozóknak hogy fel kell pontozni...
"hagyjuk már a szabályokat és előírásokat." - Ne, ne hagyjuk. Van egy meglévő környezet, számlavezető rendszerrel, IG3-mal, meg 1024 egyéb k1f...ommal, amire nem is gondolsz - ebbe kell beledrótozni egy felhős mobilbankos alkalmazásszerver-halmazt úgy, hogy az alapvető funkciók ne sérüljenek, és az MNB se köthessen bele semmilyen szempontból - ugyanis igencsak szeretik drágán mérni a "belekötéseket".
"gondolom kiadták a dolgozóknak hogy fel kell pontozni" - Tipikus magyarosch rosszindulat - nem vagyok Erste-s dolgozó, csak ügyfél, és bizony én is toltam rá a régi mobilbank értékeléséhez képest egy jobb "jegyet" - ugyanis többet tud, _nekem_ nagyjából az első 2-3 használat után legalább annyira kényelmes, mint az előző volt - a plusz tudás miatt meg pláne megérdemli a jobb minősítést (sebességre a régi sem volt gyorsabb egyébként...)
Revolut: 4 sec
George: 20 sec
Ennek egyik oka, hogy a Revolut fülekre bontja az elérhető termékeket, így az app indításánál csak a folyószámla egyenlegét tölti be, míg az Erste az összes elérhető számlát.
Kriptodeviza esetén ennél is cselesebb: az utolsó letárolt értékkel azonnal indul, majd a frissítés után átpörgeti a számokat.
Ha ez igy lenne ahogy mondod, akkor minden magyar bank appjanak bun lassunak kene lennie. De mivel van bank ahol ezt meg tudtak oldani, ezert nem a szabalyozasra kell kenni a dolgokat. El van baszva valami, nem masra kell mutogatni, hogy azert, mert...
Domain, tárhely és webes megoldások: aWh
Nyugi, láttam már közelről netbank/mobilbankot - a "másik oldalról" is :-) Nem azt írtam, hogy nem lehetne gyorsabb, hanem azt, hogy a meglévő infrastruktúrához és folyamatokhoz kellett igazítani, és az bizony hordozhat magában korlátokat, problémákat - amiket vélhetőleg ki fognak kalapálni - bár a korábbi válaszideje sem volt sokkal kevesebb - sőt. Csak ott beraktak egy képernyőt ("mindjárt készen vagyunk, de tényleg", vagy mi a szösz), ami picit (hangyabokányival) jobb, mint a "nem történik semmi".
Azt tartom problémásnak, hogy itt 10-ből 9 (és fél) megszólaló csak a frontendet nézi, és totálisan ignorálja azt, hogy ennek egy igen összetett konglomerátum részeként kell működni, amiben való igaz, vannak legacy sz@rkupacok, meg olyan módszerek/folyamatok, amiket már sok évvel ezelőtt sem így kellett volna csinálni. Viszonz banki/pénzintézeti környezetről van szó, ahol nagyon igaz az, hogy "ami működik, és nem b...ogat érte az MNB, aut nem piszkáljuk".
En ezt mint ugyfel magasrol leszarom. Mas meg tudja oldani? Igen. Akkor oldjak meg itt is.
Domain, tárhely és webes megoldások: aWh
Nem problémás, csak épp a 10-ből 9,5 elégedetlen ügyfél megszünteti a számláját és máshová viszi a pénzét. Azokhoz a másik bankokhoz, amik gyors és intuitív felületet adnak nekik.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Tegye :-) Tudok george-nál gyorsabb, divatosan mondva reszponzívabb mobilbanki felületet mutatni - és a számlavezetés díját is meghatározhatja a t. ügyfél :-)
Ugye ez csak vicc volt és valójában tudod, hogy a reszponzív az nem a sebességgel van összefüggésben?
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Koznapi ertelemben de: quick to respond or react appropriately or sympathetically
A strange game. The only winning move is not to play. How about a nice game of chess?
persze, de itt egy appról volt szó :-)
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
A számlavezető rendszert pár éve cserélték, volt is emiatt egy komolyabb leállás, ekkor ment a levesbe a régi, jól használható netbankjuk is. Szóval elvileg szép, új, csodás rendszerük van. És értem én, hogy bonyolult meg minden, de ha pár másodperc alatt _lezajlik_ egy átutalási vagy egy kártyás fizetési tranzakció (ami egyrészt tartalmaz számlaegyenleg lekérdezést is, másrészt pedig sokkal több is annál), akkor ne kelljen már 20 másodpercet várni egy mobilbank app kezdőképernyőjének a betöltésére.
Tipikus magyarosch hozzáállás az, hogy ha valami sz*rt csináltunk, akkor kiadjuk a dolgozóknak, hogy pontozzák fel, hogy legalább ne látszon az, hogy annyira sz*r.
Ez azért komolyan érdekelne, hogy mivel tud többet, mint a korábbi.
"ekkor ment a levesbe a régi, jól használható netbankjuk is" - csak a felület lett lecserélve, ha jól tudom.
Az IG3 meg a kártyás tranzakciókra kifejezetten kötött időlimitek vannak, ez az egyik, a másik, hogy ezek a tranzakciók "direktben" a rendszer mélyebb "rétegeibe" esnek be, amikhez a net/mobilban csak több lépcsőn/queue-n/egyeben keresztül férhet hozzá. Bónuszként az IG3 vagy épp a kátyás tranzakciónál a tranzakciós adatok mozognak, egy mobilbanki kliens és a kiszolgáló között meg a felületet leíró tartalom egy része is.
"mivel tud többet, mint a korábbi." - Vizuálisan nekem átláthatóbb/szebb, de ez kifejezetten szubjektív, tudom. Amiben mindenképp többet tud, az például a PFM funkcionalitás (amiből tippre még messze nincs minden bekapcsolva), vagy épp a "termékek" oldal, ahol példul a befektetéseket lehet elérni/csatolni a meglévő számlák mellé. Szerintem ide több banki/pénzügyi/biztosítási termék illetve szolgáltatás is be fog kerülni majd idóvel.
Hát tudja a fene. Az új netbank csodái:
- lassabb
- a tranzakciókat a könyvelés dátuma szerint rendezi
- a korábbi 15 perc helyett 3 percig használható új lap/fukció/akármi töltése nélkül. (Ezt 5 percnek hazudja, de 3 perc múlva felugrik egy ablakocska amin ha azt nyomod, h szeretnél belépve maradni, akkor _újratölti_ az épp aktuális oldalt.)
Mindenféle fórumokon morognak az emberek, hogy timeout, lassú, hiba... egyszerre ennyi embernek lassult be a netje meg a telefonja. Aha. Ne védjük már a védhetetlent.
A "lassú" relatív fogalom. Az előző verzió "mindjárt készen vagyunk - de tényleg" bullshit-jéhez képest nem lett lassabb. És attól, hogy n ember panaszkodik, attól még x-n nem. A kérdés az, hogy az n az az x-nek hány %-a?
panaszkodók + elégedettek < teljes ügyfélkör
Az emberek nagy része csak csendben anyázik egyet. Amúgy a 10-30 másodperces banki loading screenekre eddig csak banki alkalmazott mondta az ismerősi körömben, hogy jól van az úgy, szóval ez a százalék lehet elég magas is. :)
Nyelvtanilag lehet, de a UX egy elég jól mérhető és számszerűsíthető tudományág. Vannak itt a hupon is érdekes sztorik, érdemes olvasgatni.
Lassú: loading screeneket látok, miközben nem super PI-t számolok végtelenig. Tessék megírni úgy hogy <0.1s legyen a válaszidő bármilyen requestre. Sajnálom. Nem érdekelnek a kifogások, meg hogy minden bonyolult. Tárolják megfelelően az adatokat és ne 21313 mikroszervizből kelljen Thread.sleep-ekkel teletömött legacy rendszerekből összegereblyézni.
Mondom ezt úgy, hogy 10 éve banki kakit túrok.
"Mondom ezt úgy, hogy 10 éve banki kakit túrok." - Gondolom, nálatok ez akkor meg van oldva, qrvagyors a netbankotok/mobilbankotok, és mindenben megfelel az MNB előírásainak is - szerintem jelentkezz az Erste fejlesztői csapatába atyaistenszakértőnek, hogy megmutasd, hogyan kell - ha már a sok hülye nem tudja...
Sajnos nincs annyi belőlem, hogy minden bank mobilappját rendbe tudjam szedni :)
De gyorsabb se, az a baj. Illetve van némi funkcióvesztés is, pl. tudok 24 órára kártyalimitet állítani, mert valaki úgy gondolota, hogy ennyi választás elég lesz nekem. A régivel lehetett 1, 12, 24 és 48 órára állítani, a netbank pedig tud 24 és 48 órát. Bravó.
Most a belépés ujjlenyomat után 7 sec volt, de beléptem az egyik számla zárolásai közé, mejd nyomtam egy vissza gombot (a könyvelt tételekhez), azóta homokórázik. Csak 3x kapcsolt be azóta a fél percre állított screenlock, most volt a 4. Szóval 2 perce nem tud visszalépni arra az oldalra, amit egy "kattintással" korábban mutatott. Azóta megvolt az 5. is, szóval kilőttem az appot, elindítottam, autentikáltam, akkor meg bejött.
"A régivel lehetett 1, 12, 24 és 48 órára állítani, a netbank pedig tud 24 és 48 órát. Bravó" - halkan jelzem, hogy a legjobb tudomásom szerint ennek a javítása "benne van a csőben".
Halkan jelzem, hogy dzsordzs élesítésének napján kaptam egy emailt (du. 3 körül, de ez mindegy is) az erste-től, amiben ezt írták: "A kártyalimit-módosítás egyszerűbb: 24 órára tudsz összeget módosítani, aztán visszaállítom az eredetire."
Szóval legyen igazad, de én ebből azt veszem le, hogy ez nem bug, hanem feature...
Lehet - csak tippeltem. Minthogy elég alaposan vizslatják, hogy melyik funkciót/beállítást mennyire használták/használják, így az is lehet, hogy a 24 óra volt kimagaslóan a legtöbb, a többi beállítás meg csak egyszámjegyű százalékban - ekkor érthető, hogy a felület és a belső működés egyszerűsítése okán csak ez az opció maradt.
""A kártyalimit-módosítás egyszerűbb: 24 órára tudsz összeget módosítani, aztán visszaállítom az eredetire." - ezt úgy is lehet olvasni, hogy egyszerűen limitmódosítás - mennyi legyen, és kész, az időt nem kell beállítani - egy lépéssel/paraméterrel kevesebb, egyszerűbb a felület/folyamat.
Megmagyarázni én is meg tudom, de ez akkor is fasság.
A régi rendszerrel működött pár intervallum, asszem 4, de nem is ez a lényeg. Ha tippelnem kell, akkor ez kb. úgy működik, hogy bejegyzi valahova, hogy X kártyával Y típusú tranzakcióból Z összeg és n db. engedélyezett, és ide van még csapva az ideiglenes tranzakció lejárati ideje is. Mégis mennyit egyszerűsít az, hogy fix 24h időt jegyez be? Kispóroltak a dzsordzsiból 4 nyomorult gombot, mert a többi része már nyilván kész van. Hát bravó, tényleg
Amúgy minek egyszerűsíteni? Simán indokolt lehetne a korábbiaktól (1-48h) ezektől akár rövidebb, akár hosszabb intervallum is. Pláne úgy hogy ennek leginkább a netes kártyánál van értelme, amit ugye "veszélyes" helyeken használok, azaz nem POS/ATM. Még az 1 óra is túl sok egy ebay vásárlásra, a 24 meg aztán főleg.
"Még az 1 óra is túl sok egy ebay vásárlásra, a 24 meg aztán főleg." - Megkaptam a választ, mondjuk úgy, hogy "nem vagyok elégedett" vele - idézem: "Tájékoztatjuk, hogy a korábbiaktól eltérően a George App keretein belül, időtartam limit, valamint tranzakció db szám maximalizálás beállítása nem megoldható, a kártyához kapcoslódóan csak időzáras (24 órás), és összeg alapú limit beállítására van lehetőség, melyre vonatkozóan szíves megértését kérjük." - Hát b+ Ödön, vagy Gyuri, vagy hogy a pékbe' hívnak, nem értem meg! (Meg is kapták a választ, illendően kulturált formában...)
Őszintén reméltem, hogy igazad van, de sajnos nekem lett. Ezt tényleg fícsörnek tartják.
Egyik haverom szerint ezt az appot szellemi fogyatékos transzvesztitáknak fejlesztették, hát nehéz vele vitatkoznom...
Valahogy vissza lehet varázsolni a régi appot?
"Valahogy vissza lehet varázsolni a régi appot?" Visszavarázsolni talán (ha valaki lementette az apk-t), de működésre bírni szitne biztos, hogy nem (más a "túloldal").
dehát biztos megkutatták, hogy ez így jó, mert a userek így használják, rétegigényeid vannak.
Igen, ebben biztos vagyok, hogy megnézték, hogy a beállítások döntően a default 24 órára szólnak - de az is lehet, hogy ott, ahol Gyurikát megalkották, ott alapból nem is volt más, és azt implementálták a mobilbanki alkalmazásban is...
Azt ne mondd, hogy egy API-hoz, ami semmi mást nem csinál, minthogy egy párszázezer soros táblából visszaad 1..3 db guid+decimal párost, akkora elvetemült méretű infra kéne, ami jelentősen meglátszódna egy bank költségvetésében. :)
Nem a banki oldal a lényeges, ott jellemzően ott van az up-to-date egyenleg a netbankban, az user oldali eszköz és a banki infra közötti kapcsolat is "bele lesz mérve" a felvetett 1s-os limitbe, miközben ezekre, ezeknek a teljesítményére, sebességére nincs a banknak ráhatása.
Röhögni fogsz, de az MNB még a használandó containerization eszközt és CI / CD környezetet is megszabja.
Tényleg...? Erre tudsz valamilyen publik előírást mutatni - csak hogy ne maradjunk tudatlanok...
Semmilyen publikus dokumentumot nem találok, de én is kíváncsi lennék rá.
Interjú közben mesélték egy hazai banknál, hogy az agilis átállást kísérő fejlesztési igények jelentős része ilyen mélységű MNB-s regulációk miatt szükséges.
Talán van közöttünk hazai banki IT-ban dolgozó, aki részleteiben is ismeri.
Az, hogy CI/CD "kell", az tiszta sor, elfogadom, az viszont nehezen hihető, hogy azt is megszabná az MNB, hogy tételesen mely eszközöket kell használni - én legalábbis ilyet nem találtam az általam olvasgatott MNB-s anyagokban.
Egy másodperc? Hahhhha-hahha-hahaha! George a belépés után e pillanatban éppen homokórázik, majd 15-20 másodperc múlva közli, hogy hiba történt. Újratöltés után dettó. Így megy ez vagy 10 perce...
És? Nem érsz rá? :D
OK, hát ez eléggé rozoga.
Tegnap beléptem ujjlenyomattal.
Ma be akartam lépni, hogy zsver kolléga tanácsát követve átrendezzem a számláimat.
Ujjlenyomat: nem sikerült, add meg az mPIN-t.
mPIN: nem sikerült (azt hiszem, azt írta, hogy rossz a kód)
más módszerek - biometrikus azonosítás: ó, hát még nem állítottál be biometrikus azonosítást, nosza, most megteheted.
biometrikus azonosítás bekapcsolása: OK, add meg az mPIN-t.
mPIN: OK, biometrikus bekapcsolva.
ujjlenyomat: OK
Nice one
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Működik a George. Tegnap használtam.
Pontosabban: tegnap működött. Ma meg a nap nagyobb részében nem.
Most epp mintha mukodne.
Help az nincs, de tooltip, amin disznek van a bezaras ikon, na az van...
Sub, mert engem is érdekel a téma, de kicsit OFF is, hátha valaki jobban képben van. A kérdésem, miért Bitcoin? Azon kívül, hogy az a "legnépszerűbb". Az én megértésem szerint, a Bitcoin már "lejátszott" menet, azaz pl. https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html alapján az a userek vagy walletek 2,36%-nak van 1-nél több bitcoinja, tehát ezeknél a walleteknél összpontosul az egész Bitcoin "vagyon" majdnem 95%-a. Nincsenek pontos adataim, de valahogy a "valós" pénznél is így van, nem? Kevés gazdag kezében van sok pénz.
A másik kérdés pedig, pontosan mi határozza meg, hogy fel- vagy lefelé megy az árfolyam? Ugye most Elon bevásárolt egy picit, és ettől felfelé ment, de ezt szimplán a hype generálta? Meg ugye új BTC csak nagyon kevés lesz naponta, így a meglévők cserélnek gazdát ha jól értem. Tehát akkor most miért 40x ezer dollár, míg korábban jóval "olcsóbb" volt, tehát "kevesebbet ért". Ha már itt tartunk, ha BTC-t veszel, kitől veszel? Aki éppen elad? Mi van ha senki nem ad el épp?
És végül, lehet hogy teljesen rosszul értelmezem, és most nem is a kriptopiac hasznosságára fókuszálok, de aki ebbe fektet, az tulajdonképpen attól várja a meggazdagodást, de legalábbis valamennyi nyereséget, hogy új belépők jönnek a hype következtében és így a berakott pénze többet fog érni, tehát minél később szállsz be, annál "rosszabb" (ami igazából neked jó is lehet, mert igaz, hogy 45 ezren szállsz be a BTC-be, de 1 hónap múlva lehet hogy 55 ezer lesz)? Mert ez nekem egy az egyben MLM/Piramisjáték/Tulipánláz szagú, és ezzel nem azt mondom, hogy rossz, és nem lehet vele keresni, sőt. Csak a magasztos érveléseket nem értem egyelőre, hogy köcsög bankok, meg hurrá decentralizáltság, stb., amikor az én szememben ez simán spekuláció. Nem értek hozzá, sorry, viszont pár tízezerrel szívesen beszállnék én is :)
Ez nem kicsit off, hanem teljesen. Menj máshova erről beszélgetni, ez a topic nem erről szól.
Jaja, valszeg a MC-s threadbe akarta. Shit happens, nem a világvége.
De.
Leegyszerűsítve: van egy rakás ember aki vesz, és egy csomó, aki elad. Van eladó BTC: 10, 11, 12 forintért, és van vételi ajánlat 8, 9, 10 forintért. A kettő találkozik, akkor 10 forintot ér a BTC. Te nagyon szeretnél BTC-t venni, ezért azt mondod, hogy 11 forintot is megadnál érte, hogy te kapd. Mivel van eladó BTC 11-ért, ezért azt megkapod, és az új árfolyam 11 forint. Jön valaki, aki szerint durranni fog a lufi, ezért kiszórja a BTC-jeit 8-ért, ezután hülye lenne bárki megvenni 10-ért, megy az árfolyam 8-ra.
Dióhályban arra megy az árfolyam, amelyik irányba tolják a fentiek alapján.
Semmi, akkor nem tudsz venni, de ennek nagyon kicsi az esélye.
Valaki igen. Mások azért, mert úgy gondoljáűk, hogy releváns szereplő lesz a piacon - most kell venni, amíg "'olcsó". Megint mások szabadságharcosok, köcsögbankok, anarchia, mittudomén. Vannak olyanok, akik a privacy miatt. Stb.
Az úgy van hogy az app beszélget a háttérrendszerrel. Ehhez nem kell google sem és play store sem.
Ha az app megkérdezi a háttérrendszertől hogy még jó vagyok-e, és nem a válasz, akkor lehet a definiált viselkedés az hogy makacsul kilép, nem indul el.
Frissitened kell arra, amit az Erste támogat.
Az oké, hogyha az app azt kapja a backendtől, hogy már nem oké, akkor indulás után kilép. De a nyitókérdésben az volt, hogy mindenesetül eltűnt a telefonról. A kérdés inkább az, hogy pl. egy app tudja-e törölni magát?
Létezik olyan, hogy a google play-ről visszavonnak, letiltanak appot, és azt bizony törli a telefon.
Specifikus verziót? Az ID ugyanaz maradt, csak a verziószám ugrott egy nagyot 3.7.0-ról 20.47.14-re.
Amennyiben ez igaz, akkor is érdekes módja a rolloutnak.
Érik a bankváltás ...szák meg, mert a gyurira csrélik május 10-től a netbankot is... A mobilapp tapasztalatai alapján az is egy rakás f0s...
De miért nem próbálod ki a webes változatot? Miért a mobil app alapján ítéled meg?
Kipróbáltad? A webes dettófos... A bemutató slide-ok vegyesen német, angol meg magyar felirattal, az utolsónál "setup.dashboardBtn" feliratú gombbal... Hitel nem látszik (a moratórium számla igen, mert az folyószámla jellegű "termék"), kártyalimit dettó 24 24 órás (se több, se kevesebb, és ezt a gyagyagyurika nem is tudja máshogy).
Gyakorlatilag a webes alkalmazás a mobilos "csempéket" rakja fel egy oldalra, kiegészítve néhány másik csempével.
Ahogy most kinéz, amilyen állapotban most van, úgy értelmes helyen talán a fejlesztői teszten sem ment volna át, de hogy ügyfélnek odaadni, hogy élesben nyomkodja, azt biztos, hogy nem...
Korábban mintha több lett volna az optimizmus.
:)
Igen, több volt, mert abban bíztam, hogy a hiányzó funkciók idővel élesedni fognak a mobilos felületen is. Arra gondolni sem mertem, hogy a mobilalkalmazásban "elkövetett" visszalépéseket a webes felület is megörökli/megkapja, azaz abból is kiesik néhány olyan funkció/beállítás, ami eddig volt, és előnyként jelent meg az Erste mellett. Ezen előnyök kezdenek elfogyni, a PFM funkció nem ellensúlyozza a hiányukat (Egy 24-48 órás intervallumban beeső rendszeres terhelés a virtuális kártyára eddig egy, esetleg két limitállítást igényelt, most ez gyakorlatilag 3-5 alkalomra nő, miután a gyagyagyuri lesz a webes felület. A hitelem adatait meg nem tudom, hol fogom tudni megnézni - lehet, hogy hetente 1-2 alkalommal majd fogom hívni a telebankot, hogy nézzenek rá, olvassák be a pontos adatokat...? :-) Csak hogy "érezzék a törődést", minden alkalommal elmondva, hogy ez a funkció a netbankból hiányzik, azért telebankolok miatta.
De van még egy rakat egyéb "bammeg" dolog benne, ami miatt nem tetszik gyagyagyuri, amellett, hogy egy hazai fejlesztés lett kikukázva, és lett helyette ez a -ha jól tudom- osztrák bagázs által összelapátolt valami...
A PFM szerint 200 millió forintot költöttem az elmúlt hónapban, idk, szerintem nem ellensúlyoz az semmit. :D
Te jó Isten, minek? :D
",,majd fogom hívni a telebankot'' Te jó Isten, minek? :D" - hogy megkérdezzem hogy érzik magukat gyagyagyurika szülei :-) Nem, nem azért, hanem azért, hogy a gyagyagyuri webes felületen nem található információt (hitel állapota) megkérdezzem. Csak mert alkalmanként arra is rá szoktam nézni netbankon belül. Ha nem tudom megnézni, akkor sajnos a telebankos ügyintézők idejét fogom "rabolni"...
Jó, hát alkalmanként én is megnéztem, de kéthetente? :)
Amikor a netbankban ránéznék, akkor helyette a telebankban nézetnék rá, mi ebben a furcsa...? :-D Fene az ízlésemet, tudom, hogy havonta többször is rénéznék... :-D
Amikor hitelem volt, havonta volt egy törlesztés. A törlesztési időpontok közt nem volt változás. Minek kéthetente ránézni? Nyilván létezhet rövidebb törlesztési periódus, de főleg a Provident szintjén.
Van egy információ, amit a régi netbankban elértem, akár naponta többször is, az új gyagyagyuriban meg nincs ott, mint funkció/információ, ez a gond.
Ebben a szálban arról volt szó, hogy minek kéthetente ránézni a hiteledre. Az, hogy van információ, vagy nem, egy másik ág. Az engem hidegen hagy. Szóval minek kéthetente vagy gyakrabban ránézni egy olyan információra, ami általában havonta változik?
Akármikor ránézhettem eddig, a gyagyagyurival meg semmikor sem nézhetem meg - mert gyagyagyuri annyira gyagya, hogy ezt nem (ezt sem...) tudja...
Ezt már írtad. A kérdés az volt, hogy minek olyan sűrűn megnézni. Erre viszont nem válaszoltál.
(nem azt írtam, hogy ez így jó vagy nem jó, ezzel hiába jössz, ez nem érv)
Nomostanm sokadszor: Oké, havonta egyszer (vagy fordulónapő időszak előtt meg után kétszer) rá lehet nézni most, a gyagyagyuriban meg nullaszor - ugyanis nem tud ilyet. És nem, nem káptalan a fejem, nem tartom észben, hogy adott hitelen mekkora a tartozás, és szeretném _bármikor_ megnézni. Akár annyiszor, ahányszor benézek a netbankba. Ami nem havi 1-2 alkalom.
Én is ezen törpölök...
A gond az, hogy nagyon kevés banknál van virtuális kártya, és erre szükségem lenne. Bár ha jobban belegondolok, ha a kártyalimitet le lehet vinni kellően alacsonyra (összeg meg tranzakciószám), akkor egy "sima" kártya is használható igy, mert normál használatra van másik, úgyhogy mégsem annyira gáz a helyzet...
Az én bankomnál külön limit van a CNP tranzakcióra, és az e-bankban pillanatok alatt át lehet állítani, internetes vásárláskor átállítom, fizetés után pedig vissza. Nem bonyolultabb, mint vásárlás előtt egy virtuális kártyát feltölteni.
Viszont a kártyád klónjával bármikor, bármennyit... Na ezt (klóngyártás) "nem nyert" a virtuális kártyával. Egyelőre kivárok, és gondolkodom, hogy mi legyen - egyelőre annyi van, hogy amikor szolgáltató terhel (kb. 2 napos időszakban valamikor), akkor reggel-este mobilbank, és megtomom 24 órával a kártyalimit érvényességét, és megnézem, hogy bejött-e már a terhelés.
Ez nagyjából hatszor annyi belépés/tranzakció, mint a korábbi volt, ennyiszer több DB-bejegyzés, log, illetve kapcsolódó csingilingi...
Nekem az APKMirror-ról letöltött Google Pay szokott időnként letörlődni.
Személyes weboldalam
'Everybody loves LEDs'