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...

retró

Arra még emlékeztek, hogy valamikor régen CD-n és DVD-n terjesztettek szoftvereket? Pár levitézlett harcost bemutatnék a képről: IBM DB2 és Websphere, Rational, SAP gányolmány nagy mennyiségekben (hogy szerettem a német rövidítéseket az abapban...), Novell féle suse, Sun One appszerver (6 CD!!!) A kupca alján van valahol pár Oracle motyó is, tudom hogy valahol van benne Sybase is. Na meg a hardware-k kidobált windowsos driver CD-i. A microsoft termékek hiányoznak totál szőröstül bőröstül, mert azt itthon nem használok.

Szakmai önéletrajz helyett, mondjuk úgy 5-6 évvel ezelöttig :-)

ws://

A héten kerítettem időt magamnak egy pár prototipus fejlesztésre és kifejezetten érdekelt a html5 (ezzel kapcsolatban szólt ki ugye nemrég a w3c-s csákó, hogy még sehol sem production quality, ezt egyébként tapasztaltam is) websocket. Amit összetúrtam, az tényleg csak a prototipus építés összegzése, ne vegyétek valami szakértői véleménynek :-)
Szóval nézzük mi ez az egész...

A hiper-szuper interaktív szines-szagos weblapok fejlesztésénél a jó öreg request-response megoldás már nem nyerő. A websocket tulajdonképpen egy socket szerű dolog. Küldözgethetsz rajta mindkét irányba üzeneteket, ahogy tetszik. Azt a problémát akarja megoldani, mint az adobe RTMP nevű szőrös gorillája. Konkrétan az is tud utazni http felett, de hát ezt a dolgot jobb nem eröltetni, ugyanis mocskosul lassú.

Nos hogy a rákba fér bele a socket-szerű működés a http protokolba? Nem egyszerűen. Eredetileg úgy volt, hogy a ws protokol nem a 80-as porton fog utazni, hanem 81-es. Aztán ezt az ötletet elvetették, rettegve a firewalloktól és a proxyktól, most ott tart az ötlet - és úgy tűnik ezen már nem változtatnak - hogy ez is a 80-as porton fog utazni. A wikipédia cikk tök jól leírja, hogy fog ez működni. Nem is tudom használták-e valamire idáig a http 101 státusz kódot.

Browser háború

A wikipédia cikk a mainstream broesereket is felsorolja, csak annyit jegyeznék meg ezzel kapcsolatban, hogy jelenleg a chromium az egyetlen browser, ami kint van mainstream elérhető több oprendszerre web socket támogatással. Annak mennyi a piaci részesedése? Nem sok. A Internet exploiter 9 tartalmaz majd websocket támogatást, ez jelenleg testdrive.
Szóval erről az oldaláról a dolog szerintem jelenleg nem bevethető állapotú.

Szerver háború

Aki a szerver oldalt akarja bütykülni, annak se lesz egyszerű dolga még egy jó ideig, a java servlet ugyanis semmi támogatást nem ad az egészhez. Két dolgot találtam a weben, amit fel lehet használni:

• jwebsocket hát vele az a baj, hogy a protokolt implementálja kivállóan, csak nem fér rá a http portra mellé. Szóval muszáj neki alternatív portot meghatározni. Nem tudom mekkora gubanc a firewallok használata ebből a szempontból, pl már dolgoztam olyan helyen, ahol nem engedték ki az ismeretlen protokolokat. Pl ssh-val se lehetett kimenni. Hájli szikjúr... volt, amíg fel nem találták a pendrive-ot.
• A jetty-s srácok csináltak egy nagyon szép kis apit a websocket kezelésére. És még ráadásul működik is, csodaszép és egyszerű. Egy baja van: totál jetty specifikus. Szóval hozzáberhelted az alkalmazásod a jetty containerhez. Amíg ki nem jön valami spec, addig jóban rosszban együt.

Etc háború

Hát az egészet azért bonyolították meg, hogy mehessen a 80-as porton. És megy is, de hogy ez mennyire van tesztelve az infrastruktúra többi részén... ilyenekre gondolok:

1. proxyk kifejezetten
2. http load ballancerek
3. firewall-ok

Szóval hogy ez mind boldog lesz vajon? Annyi már most biztosnak tűnik, hogy a servlet 3.0-nál is jobban át kell majd rendezni az architektúrát.

Kérdések

Ha egyszer ez végre teljesen oké lesz és működik, akkor vajon

1. Volt-e értelme a servlet 3.0-nak? :) Mert akkor csak úgy áttolnánk minden lassú interakciót websocketen, majd szól a szerver ha kész. (mondjuk a servlet 3.0 már itt van, a websocket meg mint kiderült még sehol)
2. Ez az ajax hívások túlnyomó részét át fogja venni? Amit cachelünk, azt gondolom jobb lesz mégis a régi módszerrel küldeni.
3. Nyugdíjba megy az ajax push? Nem fog hiányozni! :-)
4. Például a socketek kiszolgálását hogyan lehet majd loadballancelni? Egész végig 1 ugyanaz a szerver fogja kiszolgálni a socketet?

Hát ennyit túrtam fel, azt hiszem most még kicsit rugdosom de hagyom érni még egy ideig. Azért ennek a technológiának a bevetéséhez igen alaposan át kell majd forgatnunk pár dolgot, egy ideig attól tartok el fog tartani, és még sehol sem tartunk vele.

Az indiánok üldöztetése

Egyik nap apache benchmarkkal méregettem az egyik webappom válaszidejét és terhelhetőségét és hát nem voltam igazán boldog. Gondoltam, hogy már nem sok mindent lehet húzni rajta, sima adatbázis cókmókot pakol bele xml-be oszt jónapot, az egész architektúra a dögunalomig menően szokványos.

A tuningolás egyébként izgalmas téma, ezer dologgal lehet húzni egy ilyen rendszert, adatbázis optimalizálás, cache réteg kidolgozása, a DAO réteg optimalizálása, profile-olás, garbage collector tuningolás, memóriaparaméterezés, jdbc connection pool buhera, threadpool buhera... és mindezen már túl voltam és az egész még mindig nem muzsikált úgy ahogy nekem tetszik. Azért éreztem nyekergésnek az egészet, mert ugyanezen a vason lemértem hogy a default apache installáció statikus html tartalommal mit tud kezdeni. Rendesen odacsűrt a procinak, de 5000 req/sec körül teljesített. Ez nyilván egy unfair összehasonlítás, mert az apacsnak semmi mást nem kellett csinálnia, csak kipumpálnia egy file-t a tcp socketen. Ez adta az ötletet, hogy ha az én rendszeremnek csak ennyit kellene csinálnia, akkor megcsíphetné az apacs tempóját.

És ezt a receptet főztem ki:

1. Végy egy filtert. Nevezd el ResponseCacheFilternek
2. Végy egy JCache (ez az oldal kiválló példája egy halott JCR-nek) implementációt, de ha nincs vagy bizonytalan vagy, jó lesz egy HashMap is, lehetőleg legalább az adatokat Ref-fel csomagold hogy OOM-et azért mégse okozzon
   
3. Fogd meg a HttpServletResponse-t és gondosan tekerd be egy HttpServletResponseWrapper-be. Itt van néhány trükk amit csinálni kell, de a lényeg hogy írj egy olyan ServletOutputStream-et, ami hasonlóan a apache commons io TeeOutputStream-jéhez (esetleg építhetsz is erre az osztályra) másolatot készít a kiírt adatból. Szerintem célszerű egy ByteArrayOutputStream-et használni ha az eredmény nem véresen nagy. Esetleg csinálhatsz köré egy limitált verziót, ami egy limit után már nem ír (mint pl a CountingInputstream)
4. A filtered egyszerűen csak dobja tovább a végrehajtást az adatbázisba matató kódnak, ami majd mégtovább dobja az adatbázisból kiberhelt adatokat kiszerializáló kódnak, satöbbi. A végén valahogy a vezérlés visszakerül a filterhez.
5. No ekkor kapjuk el a HttpServletResponseWrapperünk grabancát és követeljük tőle servlet output stream-re kiírt adatok másolatát, ez egy plain byte tömb ha minden igaz. Egyszerűen csak csináljunk egy kulcsot a request paramétereiből, és az értékként használva a response másolatát dobjuk be a cache-be
6. A következő requestek beérkezésekor a requestből összebütykölt kulccsal megnézheted, hogy van-e cachelt válasz, ha nincs lásd fenti pontok, ha pedig van, akkor boldogság, mert csak egy byte tömböt kell kidobnod.
7. Ezt a filtert applikáld rá a tipikusan csakis olvasást végző műveleteidre. Pl getCustomer, getLatestPosts, stb.
8. Lesz még itt bonyolítás: a módosítást végző kód kell hogy kérni tudja a fenti response cache egyes elemeinek kiürítését. Ide clusteres esetben szerintem egy jms topicon érdemes körbeküldeni egy ID-t vagy hasonlót, ha nincs igény culsterezésre, elég csak direktben törölgetni kulcsokat a cache-ből. (erre is lehet kultúráltnak látszó kódot írni, akármilyen bunkón is hangzik)
9. Kész! Elő a benchmark eszközzel!

Csak ennyivel még nem sikerült megszorongatni az apacsot, bár a teljesítmény igen látványosan megnőtt, de még most jön egy desszert.

A browserek (söt talán már az internet explorer is) képesek tömörített tartalmat kezelni. Az "Accept-Encoding" headerben küldik meg, hogy ők mit fogadnak el. Na ezt ki lehet használni. Általában azt szokták mondani, hogy hülye dolog generált tartalmat is gzippelni, mert sok időt visz. Talán így van, de ha csak egyszer generáljuk a tartalmat, és az eredményt becacheljük, akkor onnantól már nem kell újra és újra gzipelnünk a generált tartalmat. Ez lényegesen csökkenti  a hálózati forgalmat. Egy gzippelt response törtrésze az eredeti tartalomnak. Példaként a jól ismert JQuery minified 76 K gzippelve csak 26 K. Ez most egy rossz példa volt, mert az alig a harmada, de az én teszt kimeneteim harmincadukra estek össze és ez tényleg sokat dobott rajta.

Ez az egész csak akkor hatásos, ha az alkalmazás az olvasások számához képest ritkán módisítja a kimenetet ÉS a pillanatnyi pontos állapot nem fontosabb, mint a jó válaszidő. A legtöbb webapp tipikusan ilyen szerintem. Az internet ilyen. Egy bank esetében atomkatasztrófával érne fel, de speciel egy blogger cikk esetében nem nagyon érdekel senkit sem, hogy publish után még akár fél másodpercig is a régi tartalom jelenik meg másoknak.

Itt most egy kicsit kénytelen vagyok ködösíteni, mert mégiscsak a konkrét alkalmazáson múlik, de a cucc teljesítménye így vetekedhet, söt verheti is az apache statikus oldalak sebességét -ami mégegyszer nagyon unfair összehasonlítás, hiszen az apacsot nem tuningoltuk és esetleg csinál egy rakás egyebet amit a jetty vagy tomcat nem, és fordítva.

A válaszidőkről még annyit, hogy amikor egy-egy kulcs (vagy egyszerre több is) kiesik a cache-ből TTL, GC vagy a fenti kódolt mechanizmus által, újra a régi és lényegesen lassabbnak mért kódunk lép működésbe és ilyenkor amíg a cache-ben meg nem jelenik újra az eredmény esetleg több kérés is a háttérlogika végrehajtásához kezd, ami például tökönrúgja az adatbázist. Egy mérésben ez meg is fog látszani, tipikus bemélyedések szabályos időközönként.

Már erre is volt megoldásom egyébként, csak még nem építettem bele ebbe a response cache megoldásba, nagyjáből annyi, hogy háttérszálon is frissítheted az eredményt, ha nem borzasztó sürgős és kritikus fontosságú mindig pontos eredményt adni, és addig visszaadhatod a régi eredményt. Persze ha a cache-d nem dobja ki a régi eredményt. Szóval ez egy kicsit gubancosabb történet, de végig lehet járni ha valaki ki akarja kalapálni a csorbákat a performace görbéjén.

Na ennyi, remélem valamennyire tanulságos volt. A francba kedd lett közben, akkor jöjjön még egy ilyen a teljesítmény tuningoláshoz:

Egyik nap azt találom ki

Hogy másnap százon én nyerek

És nő hegyek vesznek körül

De én nem szeretek egyet se

Még párszor győzök

De már csak megszokásból

JaSON is EVAL...

Tegnap próbálgattam JQuery 1.4-gyel meghívni egy kézzel hímzett JSON-t gyártó ajax backendet és nagyon furcsa eredményeket kaptam. Egész pontosan a callback metódus nem került meghívásra, és pedig azért, mert nem tudta felparsoloni a json kimenetet. Néztük ketten is, hogy hol lehet a gubanc a kimenetben, és mint kiderült az idézőjelekkel volt a baj. Egyszeres idézőjel nem jó, dupla idézőjel jó.

A dolog egyébként azért volt meglepetés, mert nyilván erre a kézzel hímzett json kimenetre is írtunk validációt és a jávás json parser átengedte simán, mint ahogy a JQuery 1.3 is. Nekem kicsit a régi CORBA idők jutottak eszembe róla. Bár a probléma gyökere más, ami a felszinen van, az mégiscsak rémesen hasonlít :-(

egy üzenet magamnak

Gyónás következik... Kicsit nehéz volt elmagyaráznom az operátoroknak is és végülis szerintem csak félig lett a vége megértés és a másik felében inkább napirendre térés, de mostanában számos JMS queue ütötte fel a fejét, aminek mindkét végén ugynanaz a webapp áll. JMS-t egyébént arra használja az ember, hogy más szolgáltatásokhoz üzeneteket küldjön és nem mellesleg biztos akar abban lenni hogy nem is alkalmatlankodik a kéréssel és egyszer ki is lesz szolgálva. Nos nekem ilyen nem áll rendelkezésre, nekem sima SOAP és egyéb http backendek vannak. Szóval amikor a webappom kiveszi a kérést a JMS-ből, akkor egy SOAP hívást küld tovább. Ha nem sikerült (pl network outage, server crash valahol, konfigurációs gubancok, satöbbi), akkor bátran és nagy magabiztossággal eldobom az exceptiont a message meg mehet a dead letter queue-ba vagy konfigtól függően újra besorolásra, legközelebb hátha több szerencséje lesz.

Szóval ez nekem olyan eccerű megoldásnak tűnik, JMS-SOAP bridge. Nem lesz ez mindig muszáj, már úton van a CXF-ben is a soap-over-jms cucc, más web service stackokban már talán ott is van.

Csak ennyit akartam mondani, köszönöm a figyelmet.

Servlet 3.0 első kör

Nagyon érdekelt a servlet 3.0 és közismerten türelmetlen tipus vagyok, letéptem hát a legfrissebb specifikációt és kipróbáltam rajta pár dolgot. A kipróbált implementációk:

• Jetty 8
• glassfish 3.0
• tomcat 7

Hát eléggé fej-fej mellett voltak, úgy tünt kb mind ugyanaddig jutott el. A kisérletsorozatnak nem sikerült kizökkentenie a jetty-pártiságomból. Továbbra is a jetty volt a fejlesztés során a legkönyebben használható. A 8-as verzióhoz is van maven plugin. Pedig próbálgattam a glassfish 3 embedded pluginjét, igazából pozitív meglepetés volt, de hot deployt nem csinált. Szóval minden eltévedésem után újra kellett startolni és packagelni. A tomcat 7.0 az meg maradt a maga kis bemásolom és újraindítom megoldással. Magad uram ha integrációd nincsen.

Servlet annotációk

Iiiigen... aki velem dolgozik, az tudja mennyire nem komállom azt, hogy mindent annotálunk. Az XML HELL sem volt jó, de most elmentünk egy még rosszabb irányba. XML konfigurációkkal még megvolt az esélye annak, hogy áttekinthető marad. Mindenesetre gyors prototype alkalmazásokat az ember biztosan szivesebben tol össze úgy, hogy csak ráannotál a szervletére. Működött is mindenhol.

Azt soha nem értettem egyébként hogy a servlet ikonja az mi akart lenni. Valami ősi dolog lehet a Delphis és Progress-es időkből.

Opcionális búcsú a web.xml-től

Hát igen, ha nincs benne semmi érdekes, akkor le is törölhetjük és a dolog megy nélküle is. Persze ha már egy adatbázis kapcsolat kellene a la JNDI (ami végülis egy hasznos dolog), akkor vissza is jön egyből. Oké, szóval marad, adatbázisa kb mindenkinek van és az operátorok akarják babrálni. (Vajon miért pont azt az egy resource-ot? Az összes többivel miért nem foglalkoznak?)

Asynchron servlet support

Ez talán a legűberebb dolog mióta gyáva programózó vagyok, de az utóbbi 5 évben biztosan a legfontosabb dolog számomra. Nagyon egyszerő, ez történik: amikor úgy véled, hogy sokáig tartó művelet közeledik (pl vársz egy JMS üzenetre) egyszerűen azt mondod, hogy ez a request innentől asszinkron fog kiszolgálódni. Így:

req.startAsync();

Ezután elkérheted a requesthez tartozó AsyncContext ojjektumot

AsyncContext asyncContext = req.getAsyncContext();

Ezt akár bedobhatod egy másik szál által kezelt listába, ahol a lassú műveletre váró összes többi kliens várakozik. Az az egy szál le fogja tudni kezelni minden requestedet. Például valahogy így

asyncContext.getResponse().getWriter().write("gedappa!\n");

Eddig csúcs :) Na akkor most jön a gubanc. Azt is biztosan szeretnénk tudni, hogy mikor kellene ezt a AsyncContext objektumot kidobnunk a listából. Erre tök jó lett volna az AsyncListener osztály. Ami meg is van, kiválló. Példányosul is szépen az implementáció, még mindig oké, de aztán NoSuchMethodError amikor regisztrálni próbáltam, mind a 3 servlet containerben. Ez vagy valami kis lemaradás a specifikációhoz képest, vagy valami szokásos sünös-orákulumos gányolmány.

Elfelejtettem azzal kezdeni, hogy ennek mi értelme van. Talán már kiderült a fentiekből: megszabadulunk az millió kiszolgáló száltól, maradnak csak simán a TCP kapcsolatok. A NIO után végre a következő lépés.

Pár dolgot biztosan érdemes a async kedvéért átgondolni az üzemeltetésben is: például sokan használnak apache httpd-t a servlet container elött, mert példul még php és perl meg egyéb ingyombingyomokat is ezzel a szerverrel hajtanak. A httpd régebben single process per connection cucc volt, most már lehet külön szálakat is használni, de vicces hogy ott álnak majd a szálak, amig a java VM-ben megoldottuk hogy ne kelljen állniuk. Nekem nagyon gyanús, hogy ilyen esetekben sokkal érdemesebb lesz kihozni a servlet containert a httpd mögül. (és persze van, aki azt kérdezi: mit keresett ott addig, ha csak a java elött állt? kiválló kérdés...)

Hát ennyit akartam elmondani már jórég óta, csak mindig belémfolytották a szót. Egyébként komolyan gondolom, hogy ezt a lépést a java világ legnagyobb előrelépésének tartom az utóbbi 4-5 évre. Mondjuk nem kis lépés, de azért szivesen látnék nagyobb lépéseket is.

nyáriszünet

Igen, nagyon meleg van, körülbelül ennyivel tudom magyarázni az elmúlt pár hónap inaktivítását. Kéktúrán voltam, néha egész hétvégén cuppogott és csámcsogott a cipőm a sárban, néha inkább forró mediterrán hangulatba hajlott, de végigcsináltam. Melóztam is elég sokat sajnos mindenki rámtolt mindenfélét és már nem csak fejlesztő vagyok hanem adminisztrátor is. Nem ideális, nagyon lefárasztanak, néha nem is marad időm haladni a fejlesztéssel. Holnap reggel elhúzok egy kicsit a tesóimmal tölteni az időt. Ők is le fognak fárasztani :)

Szóval ennek megfelelően lassan, de készül a todomap 0.6.0, és egy nagy rakás dolog már most is benne van. A héten akartam kitenni, de így nyaralás elött inkáb mégsem kapkodnék. Szóval ezek jönnek:

• Van szabadszavas keresés. Elég bénácska, még valami szebb dizájn kellene neki :( A kinézettel mindig szívok.
• Van integráció. A polgármesterek jobbára friss listáját használva üti a helyi hatóságokat. Még ki kellene őket listázni szépen a megfelelő oldalon.
• Le lehet zárni a bugokat.
• Pár új apróság, például egy térkép azokkala gebaszokkal, amiket te jelöltél be, saját RSS feedek. Ide még kell, hogy felhasználóknak is használhatóvá tegyem.

Szóval ez jön. Augusztus. A hőmérséklet lassan ismét csökkenni fog, a produktivítás fordított arányban nőni kezd.

Cowboy Coding Manifesto

Annak ellenére hogy már másfél éve egyedül dolgozok (ami elég unalmas) és emiatt a scrum metodikát -vagy legalábbis jó részét- a sutba dobtam, a munkaadóm elküldött egy scrum trainingre. Azért nem volt tejesen haszontalan, nem írnék most róla részletes beszámolót, csak pár dolgot gondoltam vele kapcsolatban:

• Kell-e egy scrum csapatnak dokumentálnia? - Erre nekem az lenne a válaszom, hogy HA a ügyfél kéri és csak azt amit kért. Amit senki sem fog elolvasni az ugyebár "waste". Például az OpenSSO-val hogy hogyan integrálódik a webalkalmazásom, nem hiszem hogy bárki elolvasná amit erről írok, de ha egy fejlesztő belenéz a kódba, szerintem értené (nagyon remélem :) ). Mindenki más állította hogy egy feladat akkor kész, ha dokumentálva van. Én ezt kivenném a kész definíciójából. A user doksin kívül egy ilyen feladathoz nem nagyon kell doko. Architektúra doko? Egy ennyire plain webapphoz?
• Mondjuk azt meg is beszéltük, hogy ha nem adottak a feltételek (mint esetemben) akkor kár is erőltetni a scrumot. Szóval ennyiben maradtunk.
• Egy processz nem hoz tavaszt. Az emberek visszazökkennek a megszokott munkatempójukhoz. Mondjuk ezért kell egy dedikált scrum master, de hát kinek van erre pénze?
• Azért ahhoz bátorság kell, hogy idomítsd a munkaadód magas beosztású képviselőit. Pedig erre szükség van.
• A scrum egy elég szigorú process és a training után már nem tartom annyira minimalistának. Szerintem ez már kicsit ellentétben áll az agile kiáltvány első pontjával.

JUM XV log

Tegnap esti Java felhasználók találkozója. A democamphez hasonlóan viszonylag kevesen voltunk, erre az eseményre viszont sajnálhatja aki nem jött el, nekem nagyon tetszett a két előadás. Mindkét előadást szakmai bloggerek tartották, nekem is itt vannak a google reader végén.

Kovács Richárd: btrace

A btrace egy trace eszköz, olyan mint a dtrace solarison (ez a legtöbb embernek azért nem mond sokat, nem egy mainstream oprendszer még a szervereken sem). Egyszerű kis scripteket lehet rá írni annotációkkal és nagyon kevés kóddal, ami a hotspot vm-hez kapcsolódik és bizonyos esetekben meghívódik. Például csinálhasz egy scriptet, ami a DriverManager.getConnection() metódusra ráakaszkodik. Tipikusan olyan komponensek tuningolásánál jól jöhet, amik nem logolnak és nem mi írtuk. Őszintén szólva tegnap került csak a látőterembe a cucc és most már nem tudom hogy élhettem eddig nélküle :)

Marhefka István: Domain Driven Development

István egy hosszabb előadást tartott a Domain Driven Developmentről, ami egy nagyon elméleti téma de nagyon sok gyakorlati tapasztalat is volt benne. A DTO pattern körül a végén sok kérdés volt, azt hiszem az említett fintorgók tábora nagy számban volt jelen. Én csak akkor szoktam bevetni, ha már nincs más választásom.

Egyébként nem is tudtam hogy van még a munkaadómon kívül teamcity felhasználó itthon. Elég borsos ára van :-)

Ez volt most az időny utolsó jum-ja, szeptemberig szünetelünk és akkor újjult lendülettel :)

Eclipse Democamp 2010 Budapest

Immár szokásosnak mondható éves eclipse democamp a b2international szervezésében. Kis újításként 15 perces előadások vannak, viszont több. Nekem tetszik ez a műfaj. A felratkozott 43 főnél némileg kevesebben lehettünk, szerintem úgy 30 fő lehetett jelen. Mindenki unja az esőt. Szóval annak, aki lemardt...

Nekem kifejezetten tetszett Nagy Gergely Pythonos előadása, aminek csak a kisebb részét szánta a pydev bemutatására, inkáb a python csodálatos képességeit mutatta be, ami perlhez hasonlatos write-only nyelvvé képes tenni.

Aztán Török Zsolt Eclipse Communication Framework-ös demója is érdekes volt. Én jobban szeretem nem teletömni pluginokkal az eclipse-t és csak a szükséges minimummal beérni. Volt régebben egy érdekes demó arról, hogy hogyan lehet egyszerre ketten dolgozni egy editoron ECF segítrségével. Na az konkrétan nagyon jó volt.

Oláh Bence: Developing GWT application using Eclipse IDE. Live demóval fűszerezett prezentáció. Valami forráskód formázáson emélkszem hogy 4-5 percre fentakadtunk. Hát igen, a sok anon inner class nem teszi mindig olvashatóbbá a kódot, főleg ha az anon inner classban van egy anon inner class.

Még az XText-et kiszúrtam, mint lehetséges érdeklődésem tárgyát, de alaposan utánna kell néznem a neten.

ingyen spamblockerek versenye

Összedobtam egy nem túl fair ls tudománytalan tesztet, ami 3 publikus és ingyenes comment-spam szűrő szolgáltatást hasonlít össze a google címemre érkező spam segítségével.

Tessék hát...

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.todomap.spamegg.AkismetSpamFilterTest
[INFO] Total messages:354
[INFO] gmail spam considered ham:230
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 282.074 sec
[INFO] Running org.todomap.spamegg.TypePadFilterTest
[INFO] Total messages:354
[INFO] gmail spam considered ham:213
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 313.741 sec
[INFO] Running org.todomap.spamegg.LinkSleeveSpamFilterTest
[INFO] Total messages:354
[INFO] gmail spam considered ham:0
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 196.878 sec

Szóval röviden összefoglalva az eredményt a linksleeve nemcsak a leggyorsabb, de a leghatékonyabb is. Elég gyanúsan lógott ki a sorból, ezért teszteltem kézzel beírt adatokra is, azokat nem szűrte ki. Szóval furcsa, de tényleg jónak tűnik. Az akismet és a typepad ugyanazt a interface-t használa, lehet hogy valami számukra nagyon fontos adatot nem postolok el, amitől javulna a teljesítményük.

névadási és verziózási hagyományok

Egy érthető névadási és verziózási szabályrendszer szerintem nagyon nagy szerepet játszik egy technológia használhatóságában. Néhány eset...

Az egykori SÜN! Microsystems termékei minden kanyarban más nevet kaptak. Az első javás történet maga a java verziói és nevei. A java 1.2-t elnevezték java 2-nek és átnevezték j2se-nek, de aztán senki sem hívta 2.0-nak és a 1.3-at és 1.4-et kiadták a régi konvencióval, míg a név megmaradt j2se és j2ee, majd a java 5.0 jött és a j2se-bé eltönt végre a "2", de ezt azért zárójelben 1.5-nek hívtuk és ugyanez igaz az 1.6-ra is. Vajon hogy lesz ez a 1.7-tel, az oracle marketingesei mit szeretnének? És vajon mi lesz akkor, ha egyszer tényleg akkora dolgot csinálnak a java nyelven (bár ennek valószinűsége most már igen alacsony) ami nem férne bele az 1.x-be? Pl kompatibilitás törés és szakítás régi paradigmákkal...

A Sun más termékeinek névadási stílisa néha még ennél is cifrább, például a mai Metro web services stack legalább 3 másik néven volt már fejlesztve. A glassfish is valami minden verzió után más nevű termékből származik ha jól emlékszem. Tök jó, hogy most már 3 verzió óta ugyanúgy hívják.

Néha a saját verziózási és névadási konvencióim se túl egyszerűek. Csomagot átnevezni nem szoktam, de néha olyan neveket adok, amit nem hiszem hogy egyszerű lenne kitalálni. Például a todomap.org-ot egy o29 nevű szoftver hajtja. Azt hiszem jár egy sör a helyes megfejtőnek :-) Más csomagok neve kicsit érthetőbb, pl spameggspam nyilván spam szűrő.

Viszont soha egyetlen egyszer nem neveztem egy szoftveremet 1.0-nak. Három decimális verzió, az első a 0.0.1, így van elég helyem :)

Még a verziókról jut eszembe az a munkatárs (aki hála jehovának nem magyar és ezt soha nem fogja elolvasni) aki szerint a maven SNAPSHOT verziói egy gusztustalan gány. Soha nem használ snapshotokat. Ennek következtében a fejlesztési verziói a végleges verziószámmal "floating around the network", és mindben más van. Ezért egyébként a neki dedikált build agenteken egy időben meg kellett osztani a maven filerendszerét a gépek között. Húúúhhh....
Csak magyarázatként ant júzereknek: a maven a snapshot verziókat időnként felfrissíti (lásd maven paraméterek és settings.xml), míg a nem snapshot verziókat ha egyszer leszedte, örökre ott is marad.

Gyanús dolog az is, amikor az első publikus verzió arra enged következtetni, hogy nem ő az első. Például hogy 2.0-ként adják ki. Ez teljesen igaz arra a szoftverre, amit munkában fejlesztek. Eléggé összetákolt dolog, párszor beszakadt, úgyhogy eldöntöttük hogy from scratch újra. Már egy ideje dolgoztam rajta, amikor mondták hogy ez lesz akkor a BLF 2.0. Mondom BLF 2.0 nem lehet, az fut most a live rendszeren. De akkor már késő volt és most ott járunk hogy két ugyanolyan nevű és verzió számú, de totálisan más kinézetű és funkcionalítású rendszert fejlesztünk. Egy csomó extra munka nekem az, hogy a felhasználóknak elmagyarázzam hogy mi micsoda, ezzel például kivállóan lábon lövöm magam.

Szóval összegzésként csak ennyit szeretnék mondani: marketingesek, politikusok, humoristák, el a kezekkel a szoftveripartól!

Todomap 0.5.15

Hali, boldog szerdát!

Sok sok újítással kikerült a szerverre a todomap 0.5.15. Gondolkodtam rajta, hogy ne legyen inkáb 0.6, de lusta voltam. Szóval újdonságok:

• Összehúzott design. A régiben böszme nagy volt minden. Összehúztam az ablakok fejlécét, a tabokat és az accordionokat (akárhogy is hívják őket magyarul) Hogy tetszik?
  
• Immár a negyedik, és remélem az utolsó tooltip megoldás került be. Nem össze vissza mindenfelé jelenik meg, hanem adott helye van. A térképen babrálás közben bosszantó volt. Ez a tooltip megoldás lehetne az ugródeszka a segítséghez, lenne benne pár link bővebb leírásokhoz.
  
• Búcsú a jobbklikktől! Mostantól nem jobbklikkel lehet gubancot felírni, hanem van rá gomb. Ha megnyomod, az egér mutató célkereszt lesz, egész addig amig meg nem határoztad a gubanc helyét.
• Bemutatkozó ablak, csak hogy tudd hogy mi ez és téged miért érdekelhet. Az első látogatásod alkalmával fogod látni, aztán csak ha megkeresed.
• Diagramok: egyelőre csak a beágyazott anon szavazáshoz van, de ha kattintassz, kapod a grafikont. Kattints bátran :)
  
• Egy nagy belső rendrakás a rendszerintegrációhoz. Igen, ezzel le vagyok maradva mint a borravaló, de meglesz és szép lesz, tényleg :)
• Pár belső nagyon technikai dolog: sitemap a robotoknak és ilyesmi

Todomap 0.5.14

Sok tökölés után tessék: todomap 0.5.14 Azért tartott el ennyi ideig, mert letéptem a dizájnt a részletes leírásról és nagyon puritán lett az egész. És hát ég a pofám miatta :-D

No lényegesebb újítások:

• Anon szavazás - külön számolva a rendes felhasználóktól, akik bejelentkeznek...
• Más weboldalakra beágyazható anon szavazódoboz. Így néz ki épp pillanatnyilag (szóval ez nem képernyőlövés, hanem maga a cucc és aki buzz-ban vagy google reader-ben nézi az nem lát belőle semmit):
  
• A részletes információk többé nem feltétlenül új böngésző ablakon jelennek meg (ami idegesítő), hanem belső ablakon. Persze a régi módszer is elérhető, ehhez a kis link ikonra kell kattintani.

JUM_XIV.log

Érdekes JUM volt tegnap este, de sajnos webkamera és hangrögzítés nem volt, így aki nem jött, az be kell érje a prezentációkkal.

Fazekas Imre kedte a Brillien rendszerrel. Érdekes alapötletei vannak és az már most látszik hogy legalább akkora gondolkozásbeli változás kell hozzá, mint a scala-hoz :-) Érdekes, ebbe bele fogok olvasni. Brillien doksi -> ebook reader. (még a scala könyvek is olvasásra várnak sajnos)

Szünet után rövid Todomap. Hááááttt... rá kellett jönnöm, hogy teljesen tökéletesen mindegy mennyit készülök, úgyis teljesen más sorrendben és felépítésben fogom kiszerializálni amikor kell. Nem tudom mennyire volt érthető az alapötlet, vagy hogy hogyan néz ki ez az egész, mi a célja az egész projectnek, de ha szétnéztem nem láttam homlokráncolást.

Tulajdonképpen kicsit új fogalmat építek, ilyen szoftver még nincs, amikor azt mondod hogy email kliens vagy issue tracker, akkor azért mégiscsak vágja az ember, hogy miról van szó. A todomap-re azz mondanám hogy 'social bugtracker', erről nem tudom kinek mi jutna eszébe, talán kevés embernek a térkép.

A második hosszabb előadást Pató Bálint és Tamási Árpád tartotta a SameBug nevű fejlesztésről, ami java exception-ök tárháza és keresője (szintén valami új dolog abban a kategórióban, ahol a stackoverflow is van). A kereső és a felhasználói felülete mocsok jó. Hibákhoz vezető utak gráfon ábrázolva. Egy valami nem szimpatikus benne, és ez a licenszelése. Nem nyílt kódú cucc, hanem szolgáltatásként szeretnék értékesíteni. Vehetnénk úgy is, hogy az tök jó, legalább nem kell installálni ilyen rendszert. A todomap stack traceit szivesen megosztanám (bár elég kevés keletkezik, tényleg), mivel majdnem semmi titkos információt nem tárol. Majdnem, és mi van a maradékkal: e-mail cím, openid azonosító, talán még IP címek is a geoip cuccból. Hogy garantálhatom, hogy nem adok ki ilyen információt? Inkáb manuálisan tömném be egy ilyen szolgáltatásba a logokat, vagy valami adatbázisba tenném, hogy aztán kézzel még átválogassam.

A munkahelyen további nehézségekkel kellene szembenéznem. Hallottatok már a PCI-ról?

Még érdekelne vele az is, hogy a különböző szoftvervetrziókat hogyan tudja tolerálni. Pl hogy hibernate 3.1.x-ben 10 sorral lejjebb keletkezik ugyanaz a hiba, ami hibernate 3.2.x-ben.

todomap - ötletek a felületre

Hali!

Három új ötlettel jönnék elő a todomap felületéhez és a vélményeteket kérném!

1. Anon szavazás. Ugyanazzal a fel és le nyilakkal működne az anonkáknak is, de nekik külön számolnánk (azaz a bejelentkezett szavazók eredményeibe nem számolnánk bele) és csak captcha kitöltés után fogadnánk el. Vagy persze B lehetőségként bejelentkezhet az ember.
2. Részletek oldal áttervezés. Az accordion (hogy hívják ezt magyarul? mind1 legyenek gurulós fülek) elmenne a jófenébe és egy oldalra költözne szépen minden információ.
   (Pedig mennyit szívtam a google maps és az accordion inkompatibilításával, mire sikerült rávenni őket, hogy működjenek együt!)
3. Részletek a térképen. Nem lenne muszáj új böngésző ablakban megnyitni a részletes leírást, feljöhetne egy iframe-ben is, illetve mellette lenne a link a régi módszerre is.

Egyéb hírek a project házatájáról:

• Holnap a JUM-on lesz egy tizperces todomap beszámoló is. Nem túl technikai, inkáb csak pihentető jelleggel két erősen technikai beszámoló között.
• "Kicsit" el voltam havazva mostanában, tipikus tavaszi pörgés. Ennek megfelelően nem sikerült annyi időt spórolnom a projectnek, mint szerettem volna. Elcsúsztam a kb mostanra tervezett külső rendszerintegrációval, de akkor is meglesz :-) Azt szép lenne eléreni, hogy az önkormányzati választások friss nyerteseit már egy napra kész listával láthassuk el arról hogy mit várunk tőlük.

néhány pénzátutalási megoldás

Paypal tranzakció díj: 3.4% + egy kis zs hogy biztosan ne járjon rosszul.

noba.hu tranzakció díj (foundraising projectekhez): 2% - barátibb! :-)

moneybookers tranzakciós díj: 1% - hmmmm... Ezzel kapcsolatban van valakinek tapasztalata, véleménye?

todomap 0.5.12

0.5.12 két apró javítással:

• cimkék láthatóak a gebaszokon, a meglévő gebaszok is cimkézhetőek (140)
• a cimkékből készül keywords meta, hogy értse a google is, hogy miről van szó (141)
  

Törölni egyelőre nem lehet. Kicsit okosabbra csinálom a törlő logikát, ha nem maradt gebasz egy cimkéhez, akkor a cimkét letörli.

todomap 0.5.11

Todomap 0.5.11 frissen a szerveren. Két UI frissítés:

• Cimkézés (139) Miután új gubancot jelöltél be, felugrik egy kisablak, ahol egyből cimkézni is tudod. 2 dolog van rá, válogathatsz a cimke-felhőből, vagy beírhatod magad. Autómatikus kiegészítés felugrik alul és rá lehet kattintani ha ráismertél. Mindig csak a 50 leggyakrabban használt cimke lesz fent a felhóben, ami remélem a trágár kifejezéseket eltakarja, mert erre még nincs filter.
  Ennek akkor lesz jelentősége, amikor a szerver logikának el kell döntenie, hogy kit értesít a problémáról ha eljön az ideje.
• Képek csatolása a térképről. (99)
  

Még nagyon kellene az, hogy lehessen cimkézni a már meglévő gebaszokat is. Ugyanis azokat még nem lehet... de a héten meglesz, söt talán még ma.

File upload tesztelés

Csak egy gyors recept.

Tegnap este a file upload funkciót tuningolgattam* egy munkahelyi projecten és azon gondolkodtam hogy ezt hogyan teszteljem. Gyorsan ezt sütöttem ki: wireshar-kal felvettem, ahogy curl-lal elküldöm a postot, kivágtam belőle a http headereket és lementettem a teszt resources könyvtárba. A teszt kiolvassa, betölti a spring-test (régebben spring-mock) csomagban található MockHttpServletRequest tartalmába, valahogy felépíti a servletet (vagy controller spring esetén és akkor pl már inkáb unitils-szel inicializáltatom), egyszerűen csak meghívom a service metódust rajta és innentől a kód teljesen azt is heheti, hogy tényleg egy appserver-ben fut.

*: igen, úgy tűnik a szokásos fileupload-on van mit tuningolni, egy streaming megoldástól lényegesen jobb futást várok, mint sima tutorial-os cucctól, még ha nehezebb is használni.

todomap 0.5.10

Te szavaztál már? :-)

Szóval, ez a verzió csak kevés újdonságot hoz a kliens oldalon:

• Szavazatösszesítés a TODO kisablakában, így már kicsit egyértelműbb talán, hogy a fel és le nyil nem lapozgatás, hanem értékelés. Még az lenne jó, ha mondjuk a lefelé nyil piros lenne. Vagy nem is nyil talán hanem hüvelykőj fel vagy le.
• Kicseréltem a upload plugint. A különbség az, hogy most ez nem csak firefoxban működik :) Viszont benne hagytam a javascript alertet :( Következő lépésben megcsinálom Dani ötletét és a térképről is lehet majd képet csatolni.
  
• Még egy chrome gubanc javítása: a rich text editor hajlamos volt újra előmászni, miután lelőttem. Most kicsit hatékonyan lövöm le és nem mászik elő újra.

Az integrációs frontról jelentjük:

• Írtam egy kis AOP kódot arra, hogy a szerver oldali adatmódosító hívások (törlés, új adat, módosítás) után elküldje egy sorba (JMS) a módosult adatot. Így aki majd figyel a drót végén, az kapja az arcába az infókat. Nos egyelőre nem figyel ott senki, de arra sem kell sokáig várni, remélem.
• Összetúrkáltam egy külön API-t is a magyarorszag.hu hivatalkeresőjének gépi hasznosítására, ez a kód egy darabja lesz annak a nagyobb rendszernek, ami az imént említett drót végén figyelni fog. Lásd előző bejegyzés...
• És hogy pontosan mi lesz a drót másik végén, arról még nincs pontos elképzelésem. Csak megyek előre, aztán majdcsak lesz valahogy. Tanulgatom az camel frameworkot, servicemix-szel ismerkedek, mindenféle ESB-k után szaglászom, ilyesmi. Ez jön most egy ideig.
• Ismerkedek sok más technológiával is, pubsubhubbub, opensocial, social search, undroid...

Az első verzió, amit a szép új desktopomon csináltam. Az új gép egy 64 bites dual core AMD Athlon II x2, 2 GB 1600 mhz memóriával. Ezt a nevet kapta: dummywarhead. Döbbenetesen gyorsabb rajta a todomap, mint az előző gépen. Mondjuk mert több mint négyszer annyi a számítási teljesítménye... Még 3D-gyorsítós videókártyát is pakoltam bele, pedig amúgy nem szoktam játszani. Egy este alatt meg is untam az összes linux-szal jövö 3D játékot. Ideje újra kpróbálni Pali processzorgyilkosát.

Hóhérakasztó

Todomap integrációs körök, bevetésen a wireshark.

Tegnap este összekalapáltam egy java API-t arra, hogy a magyarország.hu hivatalkeresőjéből kiturkálja egy település polgármesteri hivatalának elérhetőségeit. Szóval kicsit a saját főztömet kellett megennem, bár nem én csináltam a keresőt. Viszont ráment az egész estém, furcsa dolgokon kellett átverekednem magam. A hivatalkeresőt egyáltalán nem úgy tervezték, hogy emberi felhasználón kívül bárki is hozzányúljon.

• Ha elötte nem jön létre a session és emiatt nincsen cookie-d, akkor nem működik a kereső. Innentől már sima URLConnection osztállyal sem sikerült elboldogulni, be kellett rángatni egy commons-httpclient-et.
• Az irányítószámot körülbelül le is lehetne szedni az egészről, teljesen figyelmen kívül hagyja. Például ha azt mondod, hogy Sopron polgármesteri hivatalát keresed, és arra a Sopronra gondolsz, amelynek irányítószáma 9400, akkor még rákérdez hogy nem Sopronkövesdre gondoltál-e, aminek már 9483 az irányítószáma.
• És az ilyen találgatásoknál úgy tűnik a szerver oldalon hagyja hogy mit kerestem, mert azt nem kell újra elpostolni.
• Néha a szerver nem elérhető. Remélem nem csináltam valami rosszat, végülis csak http requesteket küldök.
• Néhány városnál igazán mókás adatok is lejönnek, mindenféle freemailes, t-emailes, monornetes, email címek. Minden hivatal onnan szerzi az "informatikai megoldásait", ahonnan éppen tudja. Kiváncsi vagyok mennyire lesz ez hatékony módszer az integrációra, biztosan van közte néhány döglött cím is.

kis- és nagybetűs tuskó

Azért nem tudta a JIRA összekötni a issue-kat az SVN változásokkal, mert

1. windows-on fut és
   
2. valaki az SVN szerveren ravasz módon csinált egy TRUNK könyvtárat a trunk könyvtár mellé :-)

Tisztára mint a repülésirányításban, legalább 2 marhaság kell hozzá, hogy gebasz legyen.

todomap 0.5.9 - tákombákom

Todomap 0.5.9 még mindig javítgatásokkal a felületen:

• Frekventáltan (másodpercenként néhányszor) előforduló javascript hiba (124) Az egész a jquery tooltip pluginből ömlött. Lecseréltem q-tip-re. Köszi Móninak a tippért! Most így néz ki a tooltip:
• Lokalizáció takarítgatás: a login ablakon a kis csekkboksz és a például néhány metainformáció nem volt lemagyarítva, a google ezért így vette fel. Most még így néz ki:
• Félig medig be lett kötve a szavazás a felületre. Hát ezen még kell alakítani, de a szerveren végülis kikötnek a szavazatok.
  

todomap 0.5.7 és 0.5.8

Ja még elötte: kütyük témakörben ha megszánnátok szavazataitokkal itt a blogon oldalt látható az a kis szavazódoboz! Köszi!

Vasárnap kitettem a szerverre a 0.5.7 verziót:

• Spamfilter integráción dolgoztam. Ez szerintem egész jó lett. Bár mocsok egyszerű, akár újrafelhasználható más projectekben. Még dolgozok rajta. (13)
• Á, igen, login hibák most már megjelennek. (68) Hát nem mondanám hogy ember-baráti üzenetet küld, meg még csak szépet sem.
• Kicsi szépítés a koordináta visszafejtő dobozoknak.
• A könyvjelzők be lettek kötve a backendre. Szóval most már nem csak kattintgatsz, tényleg történik is valami :-)
  

A 0.5.7-es verzió jól kitolt azokkal, akiknek a google nem oldja fel az IP címét, csináltam bele egy javascript hibát, ami otthon soha nem jött ki. Így hát jött tegnap este a 0.5.8-as hibajavító kiadás:

• apróbb SEO, keywords meta lokalizáció. (129)
• Letéptem pár dolgot a felületről ami nem működött és még csak ki sem találtam hogy mit csináljon.
• pár lépés a 'remember me' funkció felé, nem lett kész mert ez a jelenleg használt spring security verzióban törött. Az a jó, hogy ilyen sok minőségi komponenst pakoltam a szoftverbe.... (59)
• visszatérés a térkép megadott pontjára bejelentkezés után (128) Persze ez csak opcionálisan. A bejelentkező ablakon a kis csekkbokszot be kell kattintani. És persze elfelejtettem lefordítani magyarra.

Új front: integráció

A UI hekkelésekkel még elleszek egy darabig. Sajnos ehhez még csak most gyűjtöm a tapasztalatokat. Most egy új dolgot is elkezdek, amiből sokkal kevesebb látható eredmény lesz: integráció külső rendszerekkel. Itt van a halál-listám. Tulajdonképpen itt kezd majd különbözni egy panaszgyüjteménytől.

todomap todo-list

A múlt hét elégrázósra sikeredett sajnos, 2 szerverleállás (az egyik 31 órán át) és 1 hálózatkiesés, munkahelyi túlórák és még egy otthoni gép-crash is nehezítette a munkát. A végére nem is lett belőle verzió és frissítés, nem is voltam itthon vasárnap.

No, most azóta rendberántottam az itthoni gépemet. Félelmetes, reiserfs volt a home partícióm! Legaláb 5 éve így lehetett, Hans Reiser legalábbis már 4 éve nem szívott szabad levegőt és még úgy 11 évig valószinűleg nem is fog. Én meg ilyen lusta vagyok, ennyi ideig rá se néztem, merevlemez csere alkalmával is talán csak dd...

Todomap: Egy kis tucat fejlesztés van készülőben:

• Elkezdtem foglalkozni a külső rendszerek integrációjával. Hát ebből még nem sok látszik.
• Spam-filter beépítéssel foglalkoztam, ingyenes akismet, írtam hozzá egy új API-t. Majd lesz később egyéb is integrálva, ezzel túlélem egy darabig.
• Normálisan fog működni végre a könyvjelző funkció és a szavazás.
• És dolgozok a tooltip plugin lehelyettesítésén, ami a nagy rakás javascript hibát csinálja.

Ennyi, nem sok.

JUM XIII

Öregszik a JUM, már a 13. alkalmat tartottuk tegnap este.

Tvik: Scala

Érdekes összefoglaló volt a scala lehetőségeiről, nekem valahogy az volt az érzésem hogy minden említett dolga érdemelne egy külön előadást. A scala-ban egyszerűen túl sokminden van. Magánvélemény, de én kicsit zavarosnak tartom a kulcsszavait, egészen onnantól hogy object, ami egy olyan class, aminek nem lesz példánya, mert csak static metódusok vannak benne. Pedig az object az az osztály egy példánya lenne úgy általánosan OOP-ben, nem? Mindegy, még az olvasásra szánt könyvek sorában várakozik a scala kupac, remélem én is hamarosan többet fogok érteni belőle.

Verhás Péter: Velocitoro maven plugin

Ötlet maven pluginra. Maven plugint hébe-hóba hegesztek én is, (pl a kis jetty-gzip tákolmányom), tényleg majdnem olyan egyszerű, mint ant taskokat írni :-) A velocitoro statikus weboldalak generálására szolgál és így nagyon kevés (kb 0) tapasztalatom van ilyen projectekben, így csak az első impressziómat tudom megosztani: az nem igazán tetszett hogy a java és a groovy kód egybe van a html kódokkal és a velocity templatekkel. Az olyan kis rumli hangulatú dolog.

Auth Gábor: JBoss ESB

Legfőbbképpen ez érdekelt, szó volt a JBoss csodálatos új MQ-járól, ami 5x* lenyomja az ActiveMQ-t, a hiper-optimalizált ESB-jükről, amiben van minden, BPEL és mindenféle. Nem tudom mennyire értem jól a dolgot, üssetek ha marhaságokat hordok össze, de tipikusan arra használja az ember az ESB-t, hogy független rendszereket kössön össze velük. Akkor engem nem annyira a cucc sebessége érdekelne.

Én az ilyen vendor-binding dolgokból szeretek egy kicsit kimaradni. Jó stratégiának tűnik, ha meg akarod úszni a portolást miután az Oracle megvette a JBoss-t :)

*: bizonyos esetekben :-) másokban lehet még lassabb is, gondolom...

Long live the VHOST!

Tegnap még annyira volt időm hogy találjak egy javascript hibát a kódban ebédidő körül. Csak pár ritka IP-ről észlelhető hiba (mint a munkahelyemé), a többi kliensről nem lenne semmi baj. Viszont 16:20-kor a szerver eltünt a netről és azóta se kép se ping. A teljesn szolgáltató (vpsplant.com) eltünt, valami súlyos problémájuk lehet. A hup fórumon se tud senki semmit. (Azért néha meglep hogy mennyit tudnak írni arról is hogy nem tudnak semmit :-) )

Szóval per pillanat ez a helyzet. A VPSPlant.com-ot azért kedvel[t]em, mert tulajdonképpen egy ebédem (kell nekem bankban ebédelni, na mind1) árából kijött a havi szerverbérlet. Szétnéztem, hogy mi a kínálat ha esetleg a vpsplant búcsút int. Nem túl tetszetős a kínálat, azért elég drága mind ahhoz képest hogy mégiscsak közös lóról van szó.

• Az Amazon EC2-n 11.000 körül havonta, ráadásul ámerikában hostolva, Írországban drágább ha jól értettem.
• Ebben az árkategóriában már dedikált szervert is bérelhetek 15.000 körül és akkor annak rendesen van memóriája, 2 proci mag, bőven merevlemez is és itthon van. Egy ilyenen például elmenne pár kedvenc kütyüm is, pl sonar
• 5-6000 körül láttam colocation ajánlatot, ha összevakargatok az itthoni hardware kupacokból egy gépet. Inkáb nem, hardware témában mindig nagyon le vagyok pusztulva. Legalább 4 éves a legújabb gépem is :-D
• A google app engine ennél lényegesen olcsóbb, talán a VPSplant-nál is olcsóbb lenne, hiszen a todomap nem valami CPU-intenzív alkalmazás a szerver oldalon. Viszont egy nagy rakás kódot ét kell hozzá írnom, az adatokat átmigrálni, és akkor megint csak ámerikában vagyunk, amit nem akarok. Plusz kicsit kemény megkötései vannak a környezetnek.
• Valakinek valami ötlete?

todomap 0.5.6 - über

A QA hiánya ide vezet: csodaszépen kipublikáltam egy javascript hibás todomap-et. Szóval most totál hulla szegény. Ilyenek ezek az alfás szoftverek, meg sajnos én is így összecsaptam a cuccot este.

Ismét eltellt egy vasárnap, itt van hát a friss todomap a hét fejlesztéseivel.

Felület:

• Anon felhasználótól kérünk bejelentkezést mielött zászlót tűzhetne ki (101)
• Búcsú az Atlanti óceántól: ha se a google jsapi, se a todomap saját geoip szolgáltatása nem tudja megmondani hogy hol vagy, akkor a lokalizáció. Azaz a hu.todomap.org magyarországra irányít az Atlanti óceán helyett, ami a régi megoldás volt.
• Lokalizált térkép (119)
• Csoport infowindow kinézet javítás
• Mindegyik fül becsukható a részletes leírásban. És már a google térkép se esik szét, ha minden igaz.
• Néhány egyéb javítás a lokalizáció körül

Technikai:

• Frissítettem Spring 3.0-ra és Spring Security 3.0.1-re (amit tegnap adtak ki). Nem azért mert az jobb, de az OpenID AX egyáltalán nem működik a 2.x szérián. Hát ezzel megyeget...
• Az infowindow-ban lecseréltem a kinézetet CSS alapúra az img tag helyett. Most már valamennyire látszik hogy ez egy interaktív játék lesz, de még nincsen teljesen behuzalozva. Csak a design kedvéért teszem ki, érdekel hogy mennyire tetszik.

A hétre még tervezek egy frissítést a következő vasárnapi elött, ha kész leszek pár további javítással és a szavazás/bookmark behuzalozásával.

todomap 0.5.5 - kozmetika

Szokásos vasárnapi verzió még mindig a 0.5 szériából:

• nagyító ikon a csoportok ablakában (103) ha rákattintassz, közelebb visz annyira, hogy a csoport szétessen darabjaira, meg persze középre is veszi.
• 404 és 500-as oldal azoknak, akik megilyednek egy stack trace-től. (105, 106)
• A gubanc részletes leírásánál nem a térképet mutatja elsőnek, hanem a leírást (113) nyilván haszontalan a megint térképet nézni ha pont onnan jöttél
• Postai cím visszafejtés kezdőcím és probléma hely meghatározásánál (109, 110) Ez kicsit talán még kiforratlan és félreérthető, rá is húztam egy tooltipet (remélem valaki észreveszi egyszer). A címet a címet nem küldi el a szervernek, csak annyira jó, hogy a kliens oldalon a google geocoderrel kiszámoljuk vele a koordinátákat. Például ide még kellene egy autocomplete is, többek közt...
  

Köszi mindenkinek a visszajelzéseket, nagyon sok építő kritikát kaptam! Még egy ideig el leszek látva munkával, de meglesznek!

A virtuális szerver IO sebessége alulmúl mindent. Csak ennek köszönhető, hogy nem töröltem le mindent véletlenül amikor az új verziót installáltam. Hihetetlen, de sikerült ctrl-c-t nyomni még mielött bármit is letörölt volna. Persze van napi backup is. Legalább 20 perc volt, amíg a servlet container újraindult :-(

Maven 404-ek

A todomap.org maven repoját úgy tűnik nem csak én használom, hanem páran mások is, nem tudom kik, az IP címet leszámítva, úgy látszik nálam találták meg amit kerestek. Nem baj, azért tettem oda hogy megtalálják... Viszont ez kiválló alkalmat ad arra, hogy megpróbáljam kielégíteni kiváncsiságomat: vajon mennyi 404-et generál a maven a repository szervereknek?

Az összes request a maven-től:

grep Java *.request.log | wc -l

3796

És ebből a 404:

grep 404.*Java *.request.log | wc -l

3618

Ez legtöbbször azért van, mert egyes artifactokhoz nem talál a maven pom file-t, ezért minden egyes alkalommal megpróbálja beszerezni hozzá, hogy feloldhassa a dependency-ket (hacsak nem -o opcióval hajtjuk éppen, de például continuous integration szerveren tipikusan nem).

Azt is megnéztem hogy szemre mi lehet a leggyakoribb oka a 404-nek: oracle jdbc driver :-) Érdekes listát kaphatnánk a nem maven-barát projectekből, ha nagyobb ismert repo szerverek logjaiba belenéznénk. Talán összeállíthatnánk egy fontossági listát arról hogy mihez lenne érdemes pom-ot hímezni akár kézzel is.

Egyébként nem tudom jól emlékeszem-e, valamikor még a maven 1.x alpha idején volt az ibiblio.org-nak egy félelmetesen hosszú 404 üzenete, amiben többszáz nyelv szlengjében elmondták azt, hogy "nem találom". Magyarul is persze. Hát nem csoda hogy eltünt :-)

todomap 0.5.4 - nemzetközösülés

Ma délután becimkéztem a 0.5.4-es verziót, és most már a szerveren is fent van. Ez történt a 0.5.3 óta:

• #24 - i18n. Már csak egy DNS módosítás kell és tesztelhető lesz a magyar TodoMap. update: kész is. úgy tűnik az interware-nél korán kezdődik a műszak
  Tegeződni fog, remélem ez senkinek nem lesz ellenszenves.
  Valamint sikerült egy hibát bele is tennem: #104 Nagyon egyszerű kis gubanc, de ilyenből nagyon sokat lehet csinálni.
• #92 - IE ocsmányságok. Ebbe csak belerúgtam, már nem annyira vészes, de még mindig nem jó.
• #102 - Delete. Szintén félkész állapotban ment ki :-( A szerver tudja, a kliensre is behuzaloztam de úgy megborította a kinézetet, hogy inkáb kikommenteztem.

És hát ez a 0.5.x iteráció igen rendesen kicsúszott a decemberből, így kénytelen vagyok egy pár hátramaradt tennivalót deprioritizálni és befejezni a 0.5-ből megmaradt rutinfeladatokat. Tapasztalatok ebből a körből:

• A szoftver-lokalizáció agyhalál
• A karácsony mégsem jó hegesztésre, meg a szilveszter sem

TodoMap

Hali és boldog új évet!

Szóval tartoztam az előző évtizedből egy magyarázattal hogy mi az ötlet a todomap.org kisérlet mögött. A todomap.org egy olyan kis project, amiben térképen bejelölheted azokat a dolgokat, amik bántják a szemed. Legányolt vasútállomás, koszos utca, betört utcai lámpák, úthibák, elhagyott és lepusztult épületek, közlekedési vagy parkolási gondok, illegális hulladéklerakók, falfirkák, mocskos aluljárók, közbiztonság, zaj, szmog, kutyabajok és más higéniai problémák... hosszú lehetne a felsorolás és persze mindegyikre fel tudnék sorolni példákat néhány kilóméteres körzeten belül. Gondolom ezzel nem vagyok egyedül.

Viszont az egészet nem egy panasz-oldalnak szánom, éppen eleget (vagy túl sokat is) panaszkodunk már így is.
Elösször is, ezeknek hibáknak többnyire van hivatalos felelőse, akit értesíthetünk a dologról, és remélhetőleg örömmel fogadja. Bármilyen rendszer-integráció működhet, akár az old-school FTP-s filetransfer, e-mail, web service (az ennyire korszerű megoldásokon meglepődnék, de persze örülnék neki).

Másodszor pedig akit érdekel a dolog, az indíthat akár saját projectet is. Pl találsz egy rozsdás korlátot a környékeden és beregisztrálsz rá egy projectet, valaki felajánlhat hozzá festéket és higítót, más talán a rozsdamarót, harmadik ember talán a segítségét fogja felajánlani. Idealizált eset nyilván, de az még nem jelenti azt hogy ez nem működhet.

Ha te egy közmű felelőse vagy, a todomap.org szeretne téged összekötni azokkal akik az általad üzemltetett infrastruktúrát használják. Nem csak azt fogod tudni hogy hol vannak a problémák, de azt is hogy a felhasználóknak ez mennyire fáj számszerűleg.

Ha te vagy az állam (illetőleg egy párt), képet kaphatsz arról, hogy a polgárok mit tartanának fontosnak a környezetükben, jó esetben egészen pontos képet. A kommunikáció költségét lecsökkentjük, így sok olcsó input jön be, ami ráadásul már rangsorolva is van.

Ha te egy sima állampolgár vagy, mint én, akkor a todomap.org-on meg tudod osztani a többi állampolgárral a környéketek problémáit, tudod őket rangsorolni, RSS feedeken, e-mail-en stb-n keresztül értesítést kaphatsz arról hogy mi történik ezekkel a problémákkal, mi történik a környékeden egyáltalán. Ha kész vagy arra, hogy tegyél valamit a tágabb értelemben vett lakóhelyedért, akkor szintén számíthatsz némi informatikai támogatásra hozzá.

Ez a terv. Hogy állok ezzel... nem rosszul, de még nagyon sok van hátra. Sokat küzdök a UI dolgokkal, kevés érzékem van a 'usablity'-hoz és az esztétikához, viszont tucatnyi visszajelzést kaptam több tesztelőtől (akiknek +1x köszi!) Internet explorer-ben például csak a múlt héten volt lehetőségem megnézni és elképedni rajta mennyire szét van esve (köszi azoknak is, akik nem használnak internet explorer-t!) Az infrastruktúra egy részét kunyiztam, a másik része olcsó bér-virtual-host.

És szóval ez megy majd idén, a szokásos ganajlapátolás mellett :-) Meglátjuk mire lesz időm és erőm.