mod_cband, mod_bw

A bandwidth throttling kiválló eszköz arra, hogy már a fejlesztőkörnzezetedben átélhesd a felhasználóid fájdalmát az alkalmazás nyomorult válaszidejével kapcsolatban. Hébe-hóba még egy-két bugot is segíthet megérteni. Amikor a localhostról jön a válasz, akkor irreálisan gyors válaszidőket kapsz, éles üzemben ilyen soha nem lesz és amikor párhuzamosan egymással több AJAX interakció is történik, akkor lehet, hogy valamit ráépítessz a válaszok sorrendjére. Pedig tök összevissza az egész. Szóval ajánlom figyelmetekbe a  mod_bw és a mod_cband apache modulokat, ők segítenek olyan tré minőséget produkálni, mint amilyet az éles szerverek :-) Az egyik konfigurációban még két vmware-s virtualális szerverre épített clustert is bedobtam mögé, hogy az is igazán ótvar legyen.

process != progress

A fejlesztők arra koncentrálnak, hogy minnél több és minnél frankóbb dolgot belepakoljanak a programjukba és sajnos néha ez buktatókkal jár. Úgy hívják a dolgot, hogy bug, defekt. Üzemzavarok, leállások, biztonsági hibák, kiskapuk, átgondolatlan UI, hiányos manuál, tákombákom, satöbbi. Ez ebből a fajta melóból kicsit adódik, de persze lehet koncentrálni a stabilításra, bugok persze akkor is lesznek amíg ember írja a kódot (meg szerintem utánna is, csak azt már senki se fogja átlátni)

Néhány súlyosabb probléma után aktiválódik a management és mindenféle metodikákat kezd bevezetni a probléma kezelésére. Kezdetben bár kisebb-nagyobb áldozatok árán de úgy tűnik sikerül megoldani a problémát (legalábbis lehet róla statisztikát hamisítani), de mivel egy-két csapat talál kiskaput, ezek a metodikák tovább nőnek és lassan kiterjednek a munka minden területére. Azon kapod magad, hogy a reggel vagy az egész délelött rámegy a standupra, esténként hosszú unalmas telefonkonferenciákon veszel részt, esetenként pedig beugrik egy-egy rendkívüli esemény is, "all hands meeting", satöbbi. Az iterációkat szinte lehetetlen összefogni, mert bár megvan a release, a deployment eltart hónapokig, ami szerintem ijesztő, de hát tényleg ez van. Mire valami kijut élesbe, már rég kész lennél a következő verzióval.

A folyamatnak ezen a végén megintcsak elkezdenek problémák jelentkezni, amik a process-ből adódnak. Páran (néha a többség) félreértették a processzt, nem igazodtak ki az eszközökön. Vannak tipikus problémák, például számítógépektől jogosan várjuk el, hogy nagyon sokáig emlékezzenek egy dologra és ha a feladat végrehajtásának két lépése között eltellik 2-3 hét, akkor is mintha az elöbb történt volna, tudják folytatni. Embereknél ez egészen viccesen nem működik, 2-3 hét alatt teljesen elfelejtik, hogy hol tartottak és amire ennyit kell várni, az egyszerűen ennél a lépésnél megakad és az emberünk totál elveszti a fonalat. Ez a dolog kellene a munkájához, szóval mit csináljon két hétig? Minden alkalommal menjen el nyaralni, amikor belefut egy ilyenbe? Egész életét havajon töltené.
Programozók ilyenkor szoktak jönni azzal, hogy "az én gépemen futott", a managerek pedig azzal védekeznek, hogy "nekem sikerült". Például a munkaadómnál a legrövidebb általam ismert SLA 10 munkanap, azaz két hét.

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.

Google Ads vs Chrome Malware deffense

Azon ritka pillanatok egyike volt, amikor érdekesnek találtam a gmailben oldalt a reklámozott terméket (az esetek messze túlnyomó részében észre se veszem) és rákattintottam, a chrome "Mailware Detected!" oldala ugrott be és figyelmeztetett, hogy valami nagyon csúnya dolgot akar csinálni a weboldal.

Közben Wax Tailortól a "There is Danger" cimű szám szólt :-) Ha már itt tartunk, holnapig biztosan nem találom fel a világmegváltó bitet és kisebb dologért miért is írnék ide, szóval legközelebb jövőre és addig is érezzétek jól magatokat és Boldog Buékot!

És bocs ezért a totálisan OFF postért! :)

web és videó séta

Az utóbbi pár év körülbelül a webes videó forradalmaként írható le, annak ellenére, hogy szabványosítás igen kevés történt a téren. Nyílt szabványok pedig szinte semmi. A két világ teljesen két különböző irányból indult, a képfelvétel 100-éves történetre tekinthet vissza, hatalmas üzlet épült rá és kicsi tudományágak fejlődtek körülötte már akkor is, amikor az internetről meg a számítógépek a legelszálltabb fantáziákban se voltak. Körülbelül ennek a 100 évnek az áporodott, ügyvédszagú hangulata lengi körbe a videószabványokat is. Egy magamfajta webjunike-nak igazi fény az éjszakában egy-egy olyan formátum, mint az ogg video, pár olyan szoftver, mint az mplayer/mencoder és az ffmpeg. Ne legyenek illúzióitok velük kapcsolatban: házi technológiának teljesen oké, de amikor be akarod vetni a céges környezetben, akkor ismét ügyvédelésre kerül majd a sor elöbb vagy utóbb. (az "utóbb"-ot nem merném megkockáztatni) Én még arra se tudtam rájönni, hogy kinek a patentjeit kell megvenni, van rá ugyanis több jelentkező és csak egy dologban egyeznek: arany árban mérik a patent díjat. A patent díj természetesen nem a kód, ami működni fog, hanem az engedély arra, hogy megpróbálj működő kódot írni vagy megvegyél egy implementációt. Legalábbis ahogy ők képzelik. Jó mi? :-)

Flash Video

Jelenleg a felhasználók messze túlnyomó része a flash pluginon keresztül részesül a web vizuális élményeiből. Lehet utálni a flash-et (és én utálom is), de rendesen egy évtizeddel megelőzte a html-t ezen a téren. Persze az egész flash világ nem igazán nyílt, bár próbálkozott az Adobe de szerintem későn, keveset és úgy tűnik hamar feladták. A flash maga egy szőrös jeti, a linuxos webkamera támogatás talán már évek óta törött de 64-bites windows 7-en se sikerül bebuherálni, IPhone-on nincs és nem is tudom lesz-e, a nem nagyon mainstream felhasználókról valahogy mindig megfeledkeznek.
Szóval a flash videó felfelé RTMP protokolon csorog. Ez a protokol egy bináris horror, félig nyilt specifikációval. Azaz az RTMP specifikácó (vagy 20 oldal a licenszinfó nélkül) ami leírja a csomagformátumot elérhető publikusan, ez alapján viszont még nem tudsz összeütni egy streaming szolgáltatást.
Nyilván ez a marketing-hajtómű az Adobe Flash Media Streaming Server terméke mögött. Ingyen van a plugin, most már a fejlesztő SDK is ingyért van (söt open source), viszont a tényleg csili vili dolgok mögé muszáj szervert arany árban mérik, per proci licensz, satöbbi. Ez persze b...ta pár ember csőrét és megírták a Red 5-ot.

Red 5

Had kapjon egy kis külön bejegyzést, mert a Red5 egyszerre rajongásom és utálatom tárgya. Igazi ambivalens kapcsolatunk van (emlékeztek még ilyen kifejezésekre irodalom órákról). Nemcsakhogy -valószinűleg- a Flash Media Server vagy a flash reverse engineeringjéből nyert ihletést, de hozzá hasonlóan nem egy szimpla szottyadt jar file, hanem a Red5 maga az alkalmazás szerver, tulajdonképpen egy haxolt tomcat. Tomcated van? Geronimod van? Glassfish, Webklotyi, Web's Fear, egyéb ganaly? Dobhatod ki :-) A Red5 ezen kívül integrál pár ismertebb frameworköt: spring, hibernate, slf4j, groovy, jython. Szóval a Red5 platform, nem pedig library. Ezzel a következő a probléma: platformunk már van. Van logging cuccunk, van webszerverünk, van mindenféle (szvsz hajmeresztő) procedúra ennek a működtetésére, egyszerűen csak nem kell még egy platform.
A dokumentáció jelenlegi állapota soha nem volt jobb, ilyen jó és összeszedett Red5 doksit még nem látott a világ. Viszont az infrastruktóra többi része még mindig egészen félelmetesen szétszórt. A legjellegzetesebb eredmény a Red5 keresések közben a 404-es oldal. A Red5 egy buhera.
A platform vs library dologgal nem vagyok egyedül és találtam is jópár embeddable verziót, de mindet régen elhagyták 1 kiadott verzió után. Kis kalapálásba került a red5-ot lefeszegetni a tomcatről, minimálisan függetleníteni a saját spring megoldásaitól, maven artifactot építeni belőle és beágyazni egy webappba. Fáj, de járható, jónéhány kódmódosítás is kell hozzá.
És ha végigjártad, a Red5 szerethető, mert a fene se tudja miért és hogyan, de megcsinálja neked azt, amit semmi más: flash media streaming a java szerveredben, ingyen.

Még 2 dolog az RTMP-ről:

1. Az RTMP nem HTTP-n át utazik, szóval nézd meg a firewallt és a load ballancert hogy tudnak-e majd kezdeni vele valamit.
2. A RTMPT (http-wrappelt rtmp) lényegesen lassabb az RTMP-nél, de legalább átmegy proxy-n, firewallon, load ballanceren, satöbbin. (Vajon egy sticky bit érdemes oda?)

Html 5

Egy távli galaxisban. A HTML 5 két dolgot hoz majd egyszer a videó streaming világába:

• video tag, aminek felsorolod az elérhető codeceket és a browser okosan kiválasztja az egyik érthetőt. Példul köztük lesz a theora codec is, ami nekem a reménysugár, mert gyűlölök licensz- és patentproblémákkal foglalkozni, azt hiszem jelenleg a firefox támogatja. Nyilván h264 a jelenleg legelterjedtebb ingyenesen használható (legalábbis kliens oldalon még kitudja hány évig) codec ami állítólag de facto standard lesz (rossz hír) bizonyos érdekelt felek nyomására.
  A video tag mostanra kb minden browserben működik, a youtube-nak van is html5 teszt oldala.
• device tag, és itt lesz a webkamera és a mikrofon. Hát erről kevesebbet sikerült összeszedni, mert egészen új még, működő példát sehol nem találtam, a browser támogatottsága talán még mindig 0.

Szóval ez az egész még (mindig) a holdban van, ha azt vesszük hogy csoda történik és a internet exploiter 10-ben már benne lesz, akkor már csak 2-3 év és valamennyire elterjed a neten.

Addig marad nekünk flash és egyéb pluginok, attól tartok. Titeket nem bosszant ez a tempó?

Egy szoftver három halálos ellensége

Utálom azokat a postokat, amiknek a címében szám van, de egyszer voltam egy mocsokdrága NLP (ez kb olyan és talán pont ugyanaz mint a scientológia, annyi különbséggel, hogy ufókról nem esett szó) fejtágítón, ahol többek közt ezt tanultam:

• Mindent ossz
• fel hármas
• csoportokra

Ez következik most. Szóval gondolkodtam rajta, hogy mi okozhatja egy szoftverfejlesztési project halálát, és az eddigi szoftverfejlesztéssel töltött kb 10 év után három dolog jutott eszembe különösebb fejtörés nélkül. Jöjjön hát a teljesen szubjektív listám:

1. Az ügyfél. Tipikusan halálos veszély a projectre nézve egy olyan ügyfél, akinek vagy nincsenek elképzelései a célról, vagy nagyon konkrét és hibás elképzelései vannak. Szerintem a legjobb a kicsit bizonytalan de nagyon együttműködő ügyfél. Na igen, on-site ügyfél.
   Az ügyfél anyagi állapota valahogy soha nem volt összefüggésben a project sikerével vagy kudarcával, nyilván én már csak olyanokkal találkozok, akiknek van elég pénzük a projectre.
   Kicsit pontosítanom kéne ezt a dolgot azzal kapcsoltaban, hogy az ügyfél egyenlő-e a felhasználóval és személy-e vagy szervezet :)
2. A management. A management ezer féle halálos veszélyt jelenthet egy szoftver projectre nézve. Nekem tipikusan az jut eszembe, hogy proxy-ként próbál játszani a szoftverfejlesztők és az ügyfél között. Kicsit felesleges szerepnek tűnik, de lehet jól is játszani. Ettől függetlenül az esetek többségében fontos információk elvesztek a fordítás során. A súlyosabb esetekben a management átviteli sebessége lezuhan 0-ra és elvesztessz minden kapcsolatot a project környezetét jelentő ügyféllel. Ez egyáltalán nem ritka eset. Ettől még lehet a fejlesztés sikeres a végén, ha magadtól is kitalálod a helyes utat, illetve ha akármelyik út helyes csak legyen valami.
   A másik tipikus hiba a túl beszédes projectmanagement, ebben az esetben annyi meeting-re kell járnia a fejlesztőknek, hogy munkára nem marad idejük. Ez mondjuk a ritkább, de nem elég ritka :-)
   Az is nagyon tipikus, hogy a fejlesztőcsapat több része között próbálnak proxy-t játszani. Na, olyat még nem láttam, hogy ez bárkinek is jól menjen. Bár ezen a szinten inkáb a szervezet fejlesztés a priorítás - úgy tűnik így hívják a végülis teljesen öncélú karrierépítést.
3. A fejlesztők is nagyon veszélyesek, konkrétan a kóderek is lehetnek lámák, de azok a projectek amiket eddig láttam, nem a fejlesztők kezén lettek végleg elcsűrve, hanem általában sokkal elöbb, az architekt kezében. A legsúlyosabb döntések ott születnek. Milyen adatbázist használsz, hogyan történik a kommunikáció a felhasználó (böngésző) és a szerver oldali komponensek között, hogyan lehet ezt az egészet fejleszteni, akár ilyenek is, hogy módosítás és teszt között mennyit kell várni az újratöltésre és mennyit kell kézzel kurblizni rajta... Tipikusan itt következnek be azok a hibák, amikról az előző postban írtam.
   Komolyan, egy szoftverfejlesztő csinálhat bugokat, hülyeségeket, láthatsz a képernyőn stack traceket és törött html templateket, segmentation fault-ot, hibás eredményeket, ezek általában pár perc vagy maximum pár nap alatt javítható evidens problémák, amik általában el is múlnak a következő release-ben. Azok a problémák, amik nem múlnak esetleg az egész szoftver életciklus során sem, azok általában mélyebben gyökerező architektúra hibák.

A zárójeles negyedik a UI designer, aki megnehezítheti vagy megkönnyítheti a felhasználó életét HA a project eljut egyáltalán odáig. HA viszont eljut odáig, csodálatos módon a felhasználók a UI design alapján fogják leginkább megitélni a szoftvert. Három okból nem kapott a UI designer külön pontot:

1. Ritkán okoz tényleges project halált egy hülye UI terv, csak a nagyon nagy közönséget kiszolgáló top weboldalakra, operációs rendszerekre, stb jellemző. Persze attól még nem ritka.
2. Még nem is láttam olyat, hogy hülye UI ellenére ne vették volna használatba a rendszert egy cégen belül. Szét is lehet nézni a céges rendszerek között, kezdjük mondjuk az SAP-vel. Azokon a projecteken, amiket kapok, sajnos a UI a legkisebb fubar.
3. Nem fért volna bele 3 pontba