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 

Cowboy Coding Manifesto - chapter two

A komplexítás nekem nem haverom. Mindenfajta komplexításnak ára van és ha nem ad értéket, akkor kifejezetten rühellem. De még ha értéket ad is, sokkal jobban szeretném azt az akármilyen értéket a lehető legkisebb komplexitással.

Viszont a kód komplexítása szép a teremtője szemében, vagy akinek a nagyságát kifejezi. Konkrétan erre gondolok: Steve Talbott írta a Devices of the soul című könyvében egy olyan délamerikai törzsről, amelyik az 1950-es évekig a világ többi részétől elszigetelten élt. Kicsit agresszív nép, az első néhány évben senki nem élte túl a kapcsolatfelvételt velük, aztán sikerült velük békés kapcsolatot nyitni és "civilizálni" őket. Ez persze hatalmas változásokat hozott a népcsoport életében, például a köpőcsőről átszoktak a puska használatára. A szerző kiemeli, hogy mennyire rossz választás volt ez, ugyanis a puska ezen az éghajlaton hamar rozsdásodik, nehéz és költséges a lőszer beszerzése, a zajával elijeszt minden esetleges zsákmányt és az esőerdőben egyébként se lehet messzebb látni, mint amennyire a köpőcső elvisz. A benszülöttek azzal magyarázták a választásukat, hogy a puskának "olyan szép a hangja".

További ajánlott olvasmány Sean Hastings God Wants You Dead című irása - egyik kedvenc olvasmányom, ajánlom mindenki figyelmébe. Tulajdonképpen memetikáról szól egész bőven, API dokumentáció az emberi agy operációs rendszeréhez. Legálisan is le lehet torrentezni :-) Érdemelne egy magyar fordítást....

Nagyon gyakran fordul elő az, hogy nem a cél lebeg a fejlesztő/architekt szeme elött, hanem az eszköz: egy böszmenagy tankkal akar odamenni. Tökmindegy, hogy hova, de tankkal, egyszerű önkifejezés céljából. Ezt hívják úgy is, hogy a tisztelt engineeringnek elszállt az agya.

Annotation hell

Gyorsan még az is eszembe jutott, hogy elmagyarázzam, miért gondolom azt, hogy az annotációkkal átestünk a ló túloldalára. Úgyis mindjárt reggel van, már jár a villamos.

A nagy XML konfigurációk helyett csodálatos dolog annotációt használni, amikor úgyis csak az az egy konfiguráció lett volna értelmes. Például JPA és más ORM annotációk. Még soha olyat nem láttam, hogy meggondolod magad és nem jó az a név annak a táblának. Kutyát nem érdekelnek a táblák nevei. Persze konkrétan a JPA lehetőséget ad arra, hogy felülbíráld XML konfigurációval az annotációkat.
Hasonlóan lelkesedek azokért az egyszerűsítésekért, amiket a JSR-181 REST annotációk, a JAXB annotációk ésatöbbi hoztak. Az így felannotált osztályokat és interfaceket az ember tipikusan egy pacakge-be dobálja. Igen, helyenként kicsit cifrán néznek ki az osztály-, metódus- és paraméterannotációk. Sebaj, az XML se lett volna kevesebb.

A másik esetben pont a szétszórtsággal van a probléma. Például a non intrusive IoC-nek pont az volt az előnye, hogy nem összeintegrált komponenseket gyártsunk, elég ha POJO, ennek megfelelően tradícionálisan szét lettek szórva a service osztályok, és nincs is nagyon remény a rendszerezésükre. Szóval ezért nem szeretem az annotált IoC-t, beleértve a spring annotációkat is, és tartok tőle hamarosan a servlet 3.0 annotációival is lesz problémám. Képzeld el így a problémát: átveszel valakitől egy spring annotált projektet, nem a dokumnetációtól működik a szoftver tehát dokumentáció nincs, a fejlesztőtől se várhatsz segítséget. Melyik projectet látod át hamarabb? Szerintem az XML-hell egy-két helyen jobb abból a szempontból ott legalább minden egy helyen van. Nyilván ettől lett hosszú. Attól, hogy szétkentük az XML file tartalmát csillió osztályba, attól nem lett se kevesebb, se átláthatóbb, csak az XML lett rövidebb. Sovány vígasz.

Log

Ismétlés a tudásnak azannnya. Péntek délután az Egér Miklós Vasművekben beszámolót tartottam a websüketes túrkálásaimról és a servlet 3.0-ról. Nem sok új ahhoz képest amit már egyébként itt is leírtam pár postban és ott is elmondtam:

1. A Servlet 3.0 zseniális lépés a java szerver oldali technológiában. Na jó ez kicsit túlzás, de végre egy nagyon lényeges újdonság, ami komolyan növeli a java szerverek teherbírását azáltal, hogy egy hosszú és esetleg nem igazán CPU igényes kiszolgálásnak nem kell feltétlenül külön szálat fentartani. Adatbázis műveletek, JMS üzenetre várakozás, de például akár várakozás más erőforrásokra is, pl gondolom nem igazán szeretnél szerver oldalon párhuzamosan 10 db jóminőségű hubble űrteleszkóp képet feldolgozni kicsi heap memóriával. Ugye...
2. A Servlet 3.0 kifejezetten olyan dolgokra nagyon alkalmas, mint a long poll. Amit ugyebár a szerver push-kén használunk.
3. A Websocket API, ami már ott van a firefox 4-ben, chrome 7, IE 9 (jajj hát ki legyen mindig a legutolsó) satöbbi, szóval ez az API lehetővé teszi, hogy TCP socket-szerű tartós kapcsolatot építsünk fel a kliens és a http szerver között.
4. A Websocket API ha egyszer elterjed, komoly átalakítsok vállnak kézenfekvővé a szoftverfejlesztésben. Szerintem a legtöbb esetben maradnak a régi ajax hívások is, de jópár esetben a websocket le fogja helyettesíteni. A long poll biztos hogy menni fog.
5. Ennél vlószinűleg lényegesebb kihívásokkal kell az üzemeltetés terén szembenézni. A Websocket ugyebár HTTP 101 "Switching Protocol" státusszal kezdődik és innentől az egész kommunikáció nagyon más, mint egy szokásos HTTP kapcsolat során. Kell számítani nehézségekre a proxykon, load ballancereken, stb. Azóta kipróbáltam, hogy apache mod_proxy korrekten kezeli-e ezt a protokolt, de nem ment vele. Aztán lehet az apacs mágusok életre tudják kelteni, de nekem nem ment. Még ki kell próbálnom mod_ajp-vel is, valamiért én inkáb azt használom ha muszáj, nekem az egyszerűbb.
   Viszont a másik kérdés: akarunk apacsot az egész elé? Amikor az kapcsolatonként 1 processzt de legalábbis egy szálat visz, míg a java szerver oldalon már nincs erre szükségünk? Lehet a httpd bottleneck lesz az architektúrában? Illetve most még nem az?
6. Még mindig kérdés, hogy szükség lesz-e a websocket témogatásához valami külön servlet engine kiegészítéshez, vagy belefér-e a sima servlet API-ba. Szerintem kifejezetten jobb lenne, ha a servlet API fürgén előjönne valami támogatással, én mindenesetre a jetty saját apiját használom. Ebből következőleg a kód nem fut pl tomcaten.
7. Ilyen módon mire tényleg használatba vesszük a Servlet 3.0 API-t, talán már nem is lesz rá szükségünk sokáig. Ugyanakkor az, hogy nem tartunk külön szálat minden kliens kapcsolatnak, még inkáb fontos lesz ha majd egyszer Websocket klienseket szolgálunk ki.
8. Ezzel kapcsolatban kicsit szorgoskodtam és dolgozok még mindig egy olyan prototipuson, ami a kliens elől eltakarja hogy long-pollt vagy websocket-et használ. Ennek egy működőképes változata itten-e van. Próbáljátok ki: svn co után mvn jetty:run. Ez a prototipus egyébként egy kicsit elvetemültebb koncepció és télleg csak kisérleti jellegű. Ha egyszer megnő, akkor meg fog érdemelni egy magyarázatot itt, addig még kalapálom és dumálunk róla.

Szóval mindez még nagyon messze van az éles bevetéstől.

Sonar eclipse plugin (FYI)

András hívta fel a figyelmem erre a pluginra, igazi frankó cucc :-) Amúgy nem szeretem pluginekkel telezsúfolni az eclipse-t, stabilabb biztosan nem lesz tőle, de ez egy értelmes ötlet: ahol hegesztek, ott nézhetem a hegesztés minőségét is és javíthatok rajta.

Király lenne az open source projectjeimhez egy sonar valahol, otthon is jó lenne bevetni. Az anzix.net-en ment egy, de eltünt.

Valamint még azt akartam kérni, hogy aki ott van a JUM-on, az légyszi írjon már beszámolót, lehetőleg minnél többen. Én még mindig melóban. Köszi...