backend fail

Mintha nálam tipushiba lenne a gubancos backend, amit integrálni kell a rendszerhez. Az egyik SOAP-os backend pl NPE-t vág az arcomba kiszámíthatóan minden alkalommal, amikor egy bizonyos metódust meghívok rajta teljesen tökmindegy milyen paraméterekkel. Állítja a szakember, hogy rosszul van telepítve és én hiszek is neki, csak akkor kérném hogy telepítsék fel jól, mert én akármit csinálok, mindig NPE lesz belőle.
A másik backend egy sima XML+http és a szerver oldalon mysql+php, de valami trükköt mégis csinálhattak rajta, a continuous integration szerver ugyanis egymás után kétszer is hibát jelzett a tesztben. Egyből éreztem kis motivációt utánnanézni és ez derült ki: két rekordot küldök át neki, a másodikban benne van az első ID-je, amit nyilván csak akkor kapok meg, ha az első sikeres volt. Általában működik is, de néha nem, néha azt van képe állítani, hogy az előző rekord nem létezik. Tipikus cluster hibának tünt elsőre, hátha aszinkron replikáció van adatbázisok közt, hogy az is "elég jó" és akkor kicsit várni kell, hogy szétreplikálódjon az első rekord, mielött becsapódik a második. Savanyú arccal a kettő közé tettem egy obj.wait(fubar)-t és lefuttattam újra a tesztet és ocsmány pofáraesés... megint elhalt. Úgyhogy kijött szépen az obj.wait és a helyére bement egy catch és retry. Most gondolj egy szóra... nekem is csúnya szó jutott eszembe.
Régebben meg volt a paypal történet, amit ha nem velem történik, nem hinném el senkinek és volt egy egész csinos rakás kis buhera a többi gubancos backendek kezelésére, azt gebaszos backendek egész hada idézte elő, az akkori projectem 9 backenddel tartott kapcsolatot. Mára azok szerencsére elmúltak de a helyükre újak jöttek.

A gubancos backendek megfigyelésére a múlt héten összeütöttem egy kis webappot és ez életem egyik leggyorsabban megtérülő befektetése lett :-) másnap reggel máris hibát jelzett és még a helyszinen elkaptam a merénylőt, aki buherálta az adott backendet.

Szóval a backendek az eddigi tapasztalatok szerint kulcsfontosságúak a szoftverhibák megvalósíŧásában. Ha csak egy mód van rá, használj inkáb beágyazható megoldást, legyen pár failover opciód, hogy ne menjen dőljön be az egész project, ha egy szolgáltató kifekszik.
A felhasználóidat ugyanis nem fogja érdekelni, hogy hol és miért volt gubanc, nekik áldozat kell majd és te vagy a legközelebb.

ERR_TEMPORARILY_THROTTLED

ERR_TEMPORARILY_THROTTLED

A Chrome 9 bétájában van a fenti feature, ami egy kicsit halva született gyerek. Szóval ez azt csinálja, hogy ha 500-at, 404-et dob  a webappod, akkor az érintett URLt nem kérei újra CTRL-R-re de még CTRL-SHIFT-R-re sem, hanem töröttként jeleníti meg, egészen újraindításig.

Gondolom az volt az ötlet, hogy a Chrome megpróbál nagyon jófiuként viselkedni a weben és nem piszkál olyan dolgokat, amik nem működnek. Viszont sajnos a web fejlesztés oltári szívás így, mert egy hiba után újra kell indítanod a böngésződet, hogy megint megpróbálhasd elérni az adott URL-t. Hát remélem ez elmúlik, mire lekerül a béta cimke, de nekem elég volt ahhoz, hogy fejvesztve visszameneküljek a stabli verzióra és firefoxra.