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.