Gondoltam egyet és megosztottam a subhub nevű pubsubhubbub kliensemet a google code-on. Ez a cucc két JMS sorral elintéz mindent. Egy JMS sorban küldöd fel, hogy mire íratkozzon fel, a másikon pedig kapod az feed updateket. Kicsit kezdetleges, de biztosan használható, mert én használom :-)
https://code.google.com/p/subhub/
2012. október 28., vasárnap
2012. október 17., szerda
Kotlin tesztkör
Néhány hónapja a Jetbrains orosz csapata bejelentette hogy új JVM nyelvet fejlesztenek Kotlin néven. Próbálgatom, gondoltam pár dolgot mesélek, hátha érdekes. Nem lesz teljes leírás, csak kedvcsináló. Ha megjött a kedved hozzá, látogass el a kotlin weboldalára! Türelmetleneknek a végén összefoglaló.
Meséltem neketek a beteges final-ozásomról. Nos a magamfajta elvetemülteknek alighanem üdítő feature a kotlin nyelvben az, hogy a változó deklarációjánál meg kell mondani, hogy változhat-e vagy sem. Ami változhat, az var (variable), ami nem, az val (value).
Ez semmi új, a scala is hasonló koncepcióval jött.
A változók deklarációjánál még tréfi az is, hogy nem kell kétszer elmondanod a típust. Kitalálja. Példa:
val kakukk = "kakukk" //nyilván string
val map = HashMap<String, String>()
Azt gondolom észrevetted, hogy new sincs. Nincsen. Mondjuk a melóhelyi projectemen, hogy a metódusok fele nagybetűvel kezdődik többnyire nem érteném, hogy ez most új objektum vagy csak hívás... desebaj, az úgyse nem lesz kotlinban.
Természetesen property-k definiálása is kapott egy szebb és kompaktabb szintaxist. Elösször is, minden amit var-ként definiál az ember, az egyből property, getterrel, setterrel, tokkal vonóval.
A null értékektől való para mindig is itt volt, mióta java platform létezik, meg még elötte is, csak szegény emberek elötte egy segmentaiton fault-ot kaptak, nem pedig NPE-t. Azért ha a kettő közül kell választani, akkor én még mindig inkáb a NPE-t választanám, az nem feltétlenül halálos.
Míg a java nyelv esetében erőtlen próbálkozásokat látunk annotációk bevezetésére, az új JRE nyelvek mind valamilyen mehanizmussal jönnek a null értékek kezelésére. A kotlin megkülönbözteti tipusonként, hogy lehet-e null. Például egy funkció, ami esetleg null-t ad vissza, azt így deklarálod:
fun talánNull() : String?
Na ez nagyon kedves, de a sima java-ban nincs ilyen, ezért minden java API minden visszaadott értéke a kotlin szempontjából esetleg null lehet. Na most például a slf4j LoggerFactory.getLogger(akármi.class) soha nem ad vissza null értéket, de a kotlin ezt nem érti, viszont néhány kényelmes operátort ad az esetleges null-támadás kivédésére. Az egyik a !! operátor. Ez a "Hidd el nekem hogy nem null, dögöljek meg itt azonnal ha null!!" operátor :) A log4j esetében például így nézne ki:
LoggerFactory.getLogger(akármi.class)!!
A másik lehetőség, az úgynevezett Elvis operátor. Elvis-szel azokat a helyzeteket tudod röviden megfogalmazni, amikor null értéket valami mással helyettesítenél. Pl ha getFoo() null-t ad vissza, akkor helyettesítsük le inkáb foo-ra:
val foo : String = getFoo() ?: "foo";
Ez a (x == null) ? null : x.getFoo() típusú műveletekre használatos. Így néz ki a fenti példa esetében fél szemű Elvis-szel.
x?.getFoo()
Ez null lesz, ha x null, és a getFoo() értéke, ha x nem null. Egész kompakt.
Ez a dolog nekem már scala-ban is nehezen esett le, de nincsen statikus változó. Első felmerülő kérdés egyből az, hogy akkor hogy a túróba fogok loggert deklarálni. Valahogy így
class object {
private val logger : Logger = LoggerFactory.getLogger(akármi.class)!!
}
Innetől ugyanúgy használhatod, mintha egy sima statikus logger lenne.
Minden új JVM nyelv lehetőséget ad closure-ök használatára (különben az érdeklődés hiányával kell szembenéznie), a kotlin sem kivétel. Nézzünk egy gyors példát:
fun kickntimes(int cnt, fn : () - > Unit) {
for(i in 0 .. cnt) {
fn();
}
}
...
kickntimes(100, {print("bla")});
Ez sem új, a groovy is és a scala is mindenféle extrákkal cicomázza fel a java osztályait. Így lesz a java.io.File osztálynak olyan metódusa, aminek például átpasszolsz egy closure-t és minden sorára meghívja. Valahogy így:
val myFile = File("bla");
myFile.forEachLine({ print(it); });
Mivel Jetbrains, nyilván idea plugin van hozzá. Azért annyira sokat azért ne várj tőle, épp úgy fejlesztés alatt áll, mint a nyelv maga. Szinez, pár helyen kisegíti a szintaxist, kódformáz. Refaktorálni többnyire nem tud, csak az alapokat (osztály átnevezés).
Szóval egészen sok új dolga van a kotlinnak, érdekes koncepciók vannak benne és van. (Ellenben a scala IDE mindig elavult eclipse-re epül, amellett hogy nem is tud sokat) kotlint használni kicsit olyan érzés, mintha délután négykor érkeznél a házibuliba: nagyon korai. Majd meglátjuk mi sül ki belőle.
var vagy val
Meséltem neketek a beteges final-ozásomról. Nos a magamfajta elvetemülteknek alighanem üdítő feature a kotlin nyelvben az, hogy a változó deklarációjánál meg kell mondani, hogy változhat-e vagy sem. Ami változhat, az var (variable), ami nem, az val (value).
Ez semmi új, a scala is hasonló koncepcióval jött.
A változók deklarációjánál még tréfi az is, hogy nem kell kétszer elmondanod a típust. Kitalálja. Példa:
val kakukk = "kakukk" //nyilván string
val map = HashMap<String, String>()
Azt gondolom észrevetted, hogy new sincs. Nincsen. Mondjuk a melóhelyi projectemen, hogy a metódusok fele nagybetűvel kezdődik többnyire nem érteném, hogy ez most új objektum vagy csak hívás... desebaj, az úgyse nem lesz kotlinban.
Mr Bean
Természetesen property-k definiálása is kapott egy szebb és kompaktabb szintaxist. Elösször is, minden amit var-ként definiál az ember, az egyből property, getterrel, setterrel, tokkal vonóval.
var name : String? = null;
Ennyi, ha nem akarod felüldefiniálni a getter tartalmát. Nagyon ajánlanám, hogy ne akard, vicces dolgokat lehet vele elkövetni. Pl ha a getterből a property-re hivatkozol, akkor simán a kód meghívja önmagát. Ezt gondolom majd kijavítják :)
Null-safety
A null értékektől való para mindig is itt volt, mióta java platform létezik, meg még elötte is, csak szegény emberek elötte egy segmentaiton fault-ot kaptak, nem pedig NPE-t. Azért ha a kettő közül kell választani, akkor én még mindig inkáb a NPE-t választanám, az nem feltétlenül halálos.
Míg a java nyelv esetében erőtlen próbálkozásokat látunk annotációk bevezetésére, az új JRE nyelvek mind valamilyen mehanizmussal jönnek a null értékek kezelésére. A kotlin megkülönbözteti tipusonként, hogy lehet-e null. Például egy funkció, ami esetleg null-t ad vissza, azt így deklarálod:
fun talánNull() : String?
Na ez nagyon kedves, de a sima java-ban nincs ilyen, ezért minden java API minden visszaadott értéke a kotlin szempontjából esetleg null lehet. Na most például a slf4j LoggerFactory.getLogger(akármi.class) soha nem ad vissza null értéket, de a kotlin ezt nem érti, viszont néhány kényelmes operátort ad az esetleges null-támadás kivédésére. Az egyik a !! operátor. Ez a "Hidd el nekem hogy nem null, dögöljek meg itt azonnal ha null!!" operátor :) A log4j esetében például így nézne ki:
LoggerFactory.getLogger(akármi.class)!!
A másik lehetőség, az úgynevezett Elvis operátor. Elvis-szel azokat a helyzeteket tudod röviden megfogalmazni, amikor null értéket valami mással helyettesítenél. Pl ha getFoo() null-t ad vissza, akkor helyettesítsük le inkáb foo-ra:
val foo : String = getFoo() ?: "foo";
Ez a (x == null) ? null : x.getFoo() típusú műveletekre használatos. Így néz ki a fenti példa esetében fél szemű Elvis-szel.
x?.getFoo()
Ez null lesz, ha x null, és a getFoo() értéke, ha x nem null. Egész kompakt.
Nincs static
Ez a dolog nekem már scala-ban is nehezen esett le, de nincsen statikus változó. Első felmerülő kérdés egyből az, hogy akkor hogy a túróba fogok loggert deklarálni. Valahogy így
class object {
private val logger : Logger = LoggerFactory.getLogger(akármi.class)!!
}
Innetől ugyanúgy használhatod, mintha egy sima statikus logger lenne.
Closure
Minden új JVM nyelv lehetőséget ad closure-ök használatára (különben az érdeklődés hiányával kell szembenéznie), a kotlin sem kivétel. Nézzünk egy gyors példát:
fun kickntimes(int cnt, fn : () - > Unit) {
for(i in 0 .. cnt) {
fn();
}
}
...
kickntimes(100, {print("bla")});
Extension functions
Ez sem új, a groovy is és a scala is mindenféle extrákkal cicomázza fel a java osztályait. Így lesz a java.io.File osztálynak olyan metódusa, aminek például átpasszolsz egy closure-t és minden sorára meghívja. Valahogy így:
val myFile = File("bla");
myFile.forEachLine({ print(it); });
IDE
Mivel Jetbrains, nyilván idea plugin van hozzá. Azért annyira sokat azért ne várj tőle, épp úgy fejlesztés alatt áll, mint a nyelv maga. Szinez, pár helyen kisegíti a szintaxist, kódformáz. Refaktorálni többnyire nem tud, csak az alapokat (osztály átnevezés).
Összevisszafoglaló
Szóval egészen sok új dolga van a kotlinnak, érdekes koncepciók vannak benne és van. (Ellenben a scala IDE mindig elavult eclipse-re epül, amellett hogy nem is tud sokat) kotlint használni kicsit olyan érzés, mintha délután négykor érkeznél a házibuliba: nagyon korai. Majd meglátjuk mi sül ki belőle.
2012. október 3., szerda
script kalandok
Ha a saját python tudásomat értékelnem kellene 1-10-ig akkor szégyenkezés nélkül 1-est adnék magamnak. A CV-ből is kihagyom, ugyanis nem karrier-cél. Ennek ellenére melóban mostanában az időm túlnyomó részét python gubancolás köti le sajnos, bugfixek, apróbb featurek, takarítgatás. Sokan csinálnák nálam jobban, talán akárki lelkesebben.
Első mese: egy python szál egy félórás tökéletes működés után (valami aszinkron taszkot vezérelt) egyszerűen csak meghalt. Vagy egy napon keresztül néztem azt a pár sor kódot és nem fogtam fel, hogy mi a baja. Aztán leesett: egy ponton a loggert hívta meg a script logging metódus nélkül. Valahogy így:
self._log('szopás')
Erre a python (helyesen) azt mondta ezen a ponton a végrehajtásban, hogy az pedig nem metódus, hanem ojjektum, és dobott egy hibát amit senki sehol nem kapott el. A szál elszakadt, a taszk meg beakadt és azt hiszem van valami timeout valahol 12 óra után, de nekem már ehhez is alig volt türelmem.
Egy szép példa arról, hogy logolás nélkül még elvben jó volt a rendszer, de logolással már nem.
Második mese: valamikor már írtam a pythonos srácok tab vs space, illetőleg 2 space vs 3 space vs 4 space vs N space vitájáról. Persze már akkor is találtam olyat, hogy valahol 13 space volt egy parancs elött. Erre a sonar hívta fel a figyelmemet, amúgy én se számolom. Szóval a 13 hogy jöhetett ki? Azt 2 db 4-spaces, egy 2-spaces és egy 3 spaces pythonos írta együtt? Mindegy, mert valahogy a python egészen idáig tolerálta a dolgot, legalábbis azt hiszem. Ma történt az, hogy megintcsak egy pythonban írt szálban keletkező hibát kellett kutatnom. Az __init__ metódus egy pár feltétel után meghívta a start() metódust, párszáz sorral lejjebb ott volt a start metódus ami elsőre nézve valami értelmes dolgot csinált. (van abban is kis gebasz amúgy, még vita trágya) Okénak tűnt, és mégsem volt az, a start ugyanis soha nem kapta meg a vezérlést. Mintha valami tréfás manó elvarázsolta volna.
Egy csomó lapozgatás után esett csak le: el volt szúrva a spacelés, így a start nem a szál osztály egy metódusa volt, hanem csak egy random funkció ott a levegőben, akit a fene se hív meg. Amúgy a szál meg frankón elindult, de nem csinált semmit se.
Tessék, space-nácik :-)
Az odáig oké, hogy én elcseszem, nyilván mert béna vagyok pythonban, de ezeket az elcseszéseket a project maintainerei csinálták, akik nyilván jobbak nálam, és még ők is ilyen alap dolgokat szúrnak el. Amúgy cefetjó, hogy dynamikus, modern, light, ésatöbbi, leszarom, csak menjen.
Első mese: egy python szál egy félórás tökéletes működés után (valami aszinkron taszkot vezérelt) egyszerűen csak meghalt. Vagy egy napon keresztül néztem azt a pár sor kódot és nem fogtam fel, hogy mi a baja. Aztán leesett: egy ponton a loggert hívta meg a script logging metódus nélkül. Valahogy így:
self._log('szopás')
Erre a python (helyesen) azt mondta ezen a ponton a végrehajtásban, hogy az pedig nem metódus, hanem ojjektum, és dobott egy hibát amit senki sehol nem kapott el. A szál elszakadt, a taszk meg beakadt és azt hiszem van valami timeout valahol 12 óra után, de nekem már ehhez is alig volt türelmem.
Egy szép példa arról, hogy logolás nélkül még elvben jó volt a rendszer, de logolással már nem.
Második mese: valamikor már írtam a pythonos srácok tab vs space, illetőleg 2 space vs 3 space vs 4 space vs N space vitájáról. Persze már akkor is találtam olyat, hogy valahol 13 space volt egy parancs elött. Erre a sonar hívta fel a figyelmemet, amúgy én se számolom. Szóval a 13 hogy jöhetett ki? Azt 2 db 4-spaces, egy 2-spaces és egy 3 spaces pythonos írta együtt? Mindegy, mert valahogy a python egészen idáig tolerálta a dolgot, legalábbis azt hiszem. Ma történt az, hogy megintcsak egy pythonban írt szálban keletkező hibát kellett kutatnom. Az __init__ metódus egy pár feltétel után meghívta a start() metódust, párszáz sorral lejjebb ott volt a start metódus ami elsőre nézve valami értelmes dolgot csinált. (van abban is kis gebasz amúgy, még vita trágya) Okénak tűnt, és mégsem volt az, a start ugyanis soha nem kapta meg a vezérlést. Mintha valami tréfás manó elvarázsolta volna.
Egy csomó lapozgatás után esett csak le: el volt szúrva a spacelés, így a start nem a szál osztály egy metódusa volt, hanem csak egy random funkció ott a levegőben, akit a fene se hív meg. Amúgy a szál meg frankón elindult, de nem csinált semmit se.
Tessék, space-nácik :-)
Az odáig oké, hogy én elcseszem, nyilván mert béna vagyok pythonban, de ezeket az elcseszéseket a project maintainerei csinálták, akik nyilván jobbak nálam, és még ők is ilyen alap dolgokat szúrnak el. Amúgy cefetjó, hogy dynamikus, modern, light, ésatöbbi, leszarom, csak menjen.
2012. szeptember 30., vasárnap
pubsubhubbub - a fagyi visszanyal
Ebben a hosszabb írásban a (nem új) pubsubhubbub protokolról írok egy összefoglalót, valamint a végén egy saját (még nem publikált) szoftverem alapötletét is felvázolom. Remélem valamennyire hasznosnak találod majd.
Eleinte volt a sima RSS és Atom formátum. Végre valami gépileg értelmezhetőt kapott a programod és nem html-ből vagy valami hasonló dzsuvából kellett kibogarászni a tartalmat. Egész kis műfaj épült az RSS streamek rendszeres ellenőrzésére és megjelenítésére. Többet nem kellett a felhasználónak hetente végiglátogatnia a kedvenc blogjait, ott volt a kedvenc RSS olvasójában minden, mindig. Mikor volt az utoljára, hogy elkezdted begépelni a firefoxnak, hogy "iwillworkforfood.blogspot.com"? Soha? Sebaj, nincs harag :-)
Olyan mainstream szoftverek támogatták ezt, mint a Microsoft Outlook.
Az RSS és Atom egyetlen apró hátulütője persze az, hogy időnként rá kell nézni, és ilyenkor le kell tölteni az egészet akkor is ha semmi új nincsen benne már egy éve. A másik apró gebasz az, hogy a friss tartalom csak egy újabb poll után kerül a felhasználóhoz. A harmadik pedig az, hogy amikor többtízezren olvasnak egy fontosabb "stream"-et, akkor az jelentős extra terhelést és forgalmat jelent a weboldalnak. Ez olyan, mintha a munkahelyeden nem csak a főnököd kérdezné, hogy "mikor leszel már kész az atomreaktorvezérlő szoftverrel", hanem mindenki akinek eszébe jut. Persze a számítógépek kicsit jobban kezelik a megszakításokat, mint az emberek.
Ezek persze nem túlélhetetlen esetek, párszáz olvasónál még mindig inkáb hagynánk had pollozzon mindenki, mint hogy törődjünk ezzel az apró problémával, extrakiadást nem jelentene, és valjuk be teljesen jó az is, ha a jövő héten amikor éppen akad időd (egy fordítás alkalmából például) elolvasod ezt a bejegyzést.
Azonban a kiszolgálónknak, a blogger.com-nak pármillió ilyen blogot kell kiszolgálnia. Így nekik már komoly terhelést jelent az, hogy örökké kérdezgetik az RSS csatornákat, és nem csak akkor, amikor a felhasználónak eszébe jut, hanem amikor az RSS olvasójának eszébe jut. Olyan oldalak, mint a google news, és társai kifejezetten szeretnék a híreket a lehető leghamarabb megkapni, azaz lehetőleg poll nélkül.
Alighanem sóhajtoztak a szolgáltatások mögött álló programozók, hogy milyen szép is lenne, ha nem kellene pollozni -mert az az összes fenti gebasszal rendelkezik- hanem egyszerűen csak elküldené neked valaki a friss tartalmat. Két megoldás született az álomból:
No, ennyit a történetről, jöhetnek a...
Nézzük hát, a specifikáció maga nem valami bolonyult. A pubsubhubbub 3 szereplős játék:
Elösször is, az RSS-t vagy Atom-ot publikáló weboldalnak tudtára kell adnia valahogy a klienseivel, hogy őt nem csak poll-ozni lehet, hanem ő támogat ennél okosabb megoldást is. Ez úgy történik, hogy egy atom linket kell betenni a kimenetbe, ezt megnézheted például itt akár ennek a blognak az atom feedjében is:
A publisher ezen kívül, amikor új tartalmat tesz a feed-be, szól is a hub-nak: nesze fiam, szólj mindenkinek! Ennyit kell tudnia a publishernek.
Nézzük, a subscribernek most már tudhatja a feed-ből, hogy nem kell örökké a publisher-hez ellátogatnia, hanem a publisher újságárús srácai fogják megkeresni. Neki ehhez annyit kell tennie, hogy megadja neki a címét. A kézbesítés, akárcsak a poll és a publish, http protokolon keresztül történik.
A felíratkozásra azért tettek egy kis hurkot, ugyanis ha a szerveredet felíratnám néhánymillió hiperaktív RSS csatornára, a google app engine böszme nagy szerverfarmja verné halálra a géped, illetőleg termelne neked szép nagy számlát a forgalommal. Ez pedig kimeríti a "más farkával történő csalánverés" tényállását, így mindkét fél érdekelt abban, hogy egy harmadik ilyet ne csináljon. Ebből a célból a hub visszakérdez a megadott címre, hogy tényleg innen jött-e a kérés. Miután a kérés megerősítést kap, a felíratkozás kész.
A publish nagyon nagyon egyszerű: http POST requestet kapsz a megadott címre, aminek request body-ja a friss tartalom.
Mennyire gyors? Nem nehéz kipróbálni, egy blogger.com blog kell hozzá és egy tetszőleges publikus webcím. dyndns, portforwarding, ingyenhosting, akármi játszhat. Általában mire sikerül ablakot váltanom, már ott van benne a tartalom, amit a blogger.com-ra került. Nem nevezném realtime-nak, de a pollhoz képest cefetgyors.
A fejlesztők álma az volt, hogy ez az egész elosztott lesz, azaz soksok hub lesz és mint a postahivatalok között áramlik majd a sok sok update. Hááát... ez nem lett egészen így. Természetesen csinálhatsz saját hub-ot, és a wordpress blogjai valóban tartalmaznak egy beépített hubot, ez nekem úgy tűnik a ritka kivételek közé tartozik inkáb, mint a meghatázozó szabály lenne. A pubsubhubbub-ot támogató feed-ed legnagyobb része a google hub-jára mutat. Azaz bár van lehetőség arra, hogy ez máshogy legyen, mégiscsak egy nagy hal viszi az egészet. Ha valamiért elakad egy pár órára a google rendszere (ilyen pedig minden cloud rendszerrel történt eddig), akkor még úgy se fog muzsikálni a rendszer, mint pollozással. Ezt azért szerintem érdemes belekalkulálni.
Majdnem elérkezett a boldogság, mert nem kell fölöslegesen böszme nagy sávszélességet vásárolni, időnként végignyalni a fél internetet, satöbbi. Amikor jön valami anyag, akkor megkapod, ezzel végülis egyszerűbb lehet a rss-feldolgozás menete.
Viszont arra gondoltam, mennyire természetesebb lenne, ha valamilyen csatornán keresztül érkeznének az RSS updatek, nekem talán egy JMS csatorna tűnik a legegyszerűbbnek. A feldolgozásról eldönthetem, hogy egymás után vagy párhuzamosan. A feldolgozást nem terheli agyon egy hirtelen forgalomhullám reggel, amikor mindenki tweet-el és updatel ésatöbbiésatöbbi. Ezzel el is tudom különíteni az feldolgozástól a pubsubhubbub-specifikus kódot, és a feldolgozás csak szin tiszta RSS/Atom xml-eket kap. Ezt az egy komponenst dobtam fel egy kívülről elérhető szerverre, a feldolgozás egy JMS queue-n keresztül tartja vele a kapcsolatot. A feldogozást akár tehetjük saját meglévő farmunkra is, ott olcsóbb a tárhely és a CPU idő is. Söt a felhőben szerintem elcseszett drága általában véve.
Ezt majd egyszer papírsárkány design pattern néven fogom szabadalmaztatni és abból leszek csilliárdos.
Hát ennyi tényleg. Boldog Szent Vencel napot :-)
Rövid feed-történelem
Eleinte volt a sima RSS és Atom formátum. Végre valami gépileg értelmezhetőt kapott a programod és nem html-ből vagy valami hasonló dzsuvából kellett kibogarászni a tartalmat. Egész kis műfaj épült az RSS streamek rendszeres ellenőrzésére és megjelenítésére. Többet nem kellett a felhasználónak hetente végiglátogatnia a kedvenc blogjait, ott volt a kedvenc RSS olvasójában minden, mindig. Mikor volt az utoljára, hogy elkezdted begépelni a firefoxnak, hogy "iwillworkforfood.blogspot.com"? Soha? Sebaj, nincs harag :-)
Olyan mainstream szoftverek támogatták ezt, mint a Microsoft Outlook.
Az RSS és Atom egyetlen apró hátulütője persze az, hogy időnként rá kell nézni, és ilyenkor le kell tölteni az egészet akkor is ha semmi új nincsen benne már egy éve. A másik apró gebasz az, hogy a friss tartalom csak egy újabb poll után kerül a felhasználóhoz. A harmadik pedig az, hogy amikor többtízezren olvasnak egy fontosabb "stream"-et, akkor az jelentős extra terhelést és forgalmat jelent a weboldalnak. Ez olyan, mintha a munkahelyeden nem csak a főnököd kérdezné, hogy "mikor leszel már kész az atomreaktorvezérlő szoftverrel", hanem mindenki akinek eszébe jut. Persze a számítógépek kicsit jobban kezelik a megszakításokat, mint az emberek.
Ezek persze nem túlélhetetlen esetek, párszáz olvasónál még mindig inkáb hagynánk had pollozzon mindenki, mint hogy törődjünk ezzel az apró problémával, extrakiadást nem jelentene, és valjuk be teljesen jó az is, ha a jövő héten amikor éppen akad időd (egy fordítás alkalmából például) elolvasod ezt a bejegyzést.
Azonban a kiszolgálónknak, a blogger.com-nak pármillió ilyen blogot kell kiszolgálnia. Így nekik már komoly terhelést jelent az, hogy örökké kérdezgetik az RSS csatornákat, és nem csak akkor, amikor a felhasználónak eszébe jut, hanem amikor az RSS olvasójának eszébe jut. Olyan oldalak, mint a google news, és társai kifejezetten szeretnék a híreket a lehető leghamarabb megkapni, azaz lehetőleg poll nélkül.
Alighanem sóhajtoztak a szolgáltatások mögött álló programozók, hogy milyen szép is lenne, ha nem kellene pollozni -mert az az összes fenti gebasszal rendelkezik- hanem egyszerűen csak elküldené neked valaki a friss tartalmat. Két megoldás született az álomból:
- a cloud - ilyen támogatását én még nem láttam
- a google pubsubhubbub specifikációja - ez annál inkáb széles támogatottságot élvez
- a blogger.com nyilván az elsők között, tekintve hogy google kézben van
- hamar megjelent a támogatás a wordpress-ben és a nagy wordpress.com is bekapcsolta úgy 7.5 millió náluk hostolt blogra
- a nagy nemzetköziek mellett had említsem meg, hogy a magyar blog.hu is támogatja
- A "long tail" blogok mellett nagy halak feedjeiben is megjelent: CNN, BBC, és pár egyéb nagyobb
No, ennyit a történetről, jöhetnek a...
Technikai részletek
Nézzük hát, a specifikáció maga nem valami bolonyult. A pubsubhubbub 3 szereplős játék:
- a publisher - aki az RSS vagy Atom feedet kiszolgálja
- subscriber - aki szeretné megkapni a friss tartalmat
- hub - aki a kettő között áll. Ő leginkáb olyan mint az újságosfiú.
Elösször is, az RSS-t vagy Atom-ot publikáló weboldalnak tudtára kell adnia valahogy a klienseivel, hogy őt nem csak poll-ozni lehet, hanem ő támogat ennél okosabb megoldást is. Ez úgy történik, hogy egy atom linket kell betenni a kimenetbe, ezt megnézheted például itt akár ennek a blognak az atom feedjében is:
<link href="http://pubsubhubbub.appspot.com/" rel="hub">
Innen tudhatja a kliens, hogy melyik hub-nál kell szólnia, hogy őt érdekelné.
A publisher ezen kívül, amikor új tartalmat tesz a feed-be, szól is a hub-nak: nesze fiam, szólj mindenkinek! Ennyit kell tudnia a publishernek.
Nézzük, a subscribernek most már tudhatja a feed-ből, hogy nem kell örökké a publisher-hez ellátogatnia, hanem a publisher újságárús srácai fogják megkeresni. Neki ehhez annyit kell tennie, hogy megadja neki a címét. A kézbesítés, akárcsak a poll és a publish, http protokolon keresztül történik.
A felíratkozásra azért tettek egy kis hurkot, ugyanis ha a szerveredet felíratnám néhánymillió hiperaktív RSS csatornára, a google app engine böszme nagy szerverfarmja verné halálra a géped, illetőleg termelne neked szép nagy számlát a forgalommal. Ez pedig kimeríti a "más farkával történő csalánverés" tényállását, így mindkét fél érdekelt abban, hogy egy harmadik ilyet ne csináljon. Ebből a célból a hub visszakérdez a megadott címre, hogy tényleg innen jött-e a kérés. Miután a kérés megerősítést kap, a felíratkozás kész.
A publish nagyon nagyon egyszerű: http POST requestet kapsz a megadott címre, aminek request body-ja a friss tartalom.
Mennyire gyors? Nem nehéz kipróbálni, egy blogger.com blog kell hozzá és egy tetszőleges publikus webcím. dyndns, portforwarding, ingyenhosting, akármi játszhat. Általában mire sikerül ablakot váltanom, már ott van benne a tartalom, amit a blogger.com-ra került. Nem nevezném realtime-nak, de a pollhoz képest cefetgyors.
A fejlesztők álma az volt, hogy ez az egész elosztott lesz, azaz soksok hub lesz és mint a postahivatalok között áramlik majd a sok sok update. Hááát... ez nem lett egészen így. Természetesen csinálhatsz saját hub-ot, és a wordpress blogjai valóban tartalmaznak egy beépített hubot, ez nekem úgy tűnik a ritka kivételek közé tartozik inkáb, mint a meghatázozó szabály lenne. A pubsubhubbub-ot támogató feed-ed legnagyobb része a google hub-jára mutat. Azaz bár van lehetőség arra, hogy ez máshogy legyen, mégiscsak egy nagy hal viszi az egészet. Ha valamiért elakad egy pár órára a google rendszere (ilyen pedig minden cloud rendszerrel történt eddig), akkor még úgy se fog muzsikálni a rendszer, mint pollozással. Ezt azért szerintem érdemes belekalkulálni.
Egy kicsi extra: subhub
Majdnem elérkezett a boldogság, mert nem kell fölöslegesen böszme nagy sávszélességet vásárolni, időnként végignyalni a fél internetet, satöbbi. Amikor jön valami anyag, akkor megkapod, ezzel végülis egyszerűbb lehet a rss-feldolgozás menete.
Viszont arra gondoltam, mennyire természetesebb lenne, ha valamilyen csatornán keresztül érkeznének az RSS updatek, nekem talán egy JMS csatorna tűnik a legegyszerűbbnek. A feldolgozásról eldönthetem, hogy egymás után vagy párhuzamosan. A feldolgozást nem terheli agyon egy hirtelen forgalomhullám reggel, amikor mindenki tweet-el és updatel ésatöbbiésatöbbi. Ezzel el is tudom különíteni az feldolgozástól a pubsubhubbub-specifikus kódot, és a feldolgozás csak szin tiszta RSS/Atom xml-eket kap. Ezt az egy komponenst dobtam fel egy kívülről elérhető szerverre, a feldolgozás egy JMS queue-n keresztül tartja vele a kapcsolatot. A feldogozást akár tehetjük saját meglévő farmunkra is, ott olcsóbb a tárhely és a CPU idő is. Söt a felhőben szerintem elcseszett drága általában véve.
Ezt majd egyszer papírsárkány design pattern néven fogom szabadalmaztatni és abból leszek csilliárdos.
Hát ennyi tényleg. Boldog Szent Vencel napot :-)
2012. augusztus 30., csütörtök
gondolom
Nézzük csak, a következő lehetőségek állnak rendelkezésre a munkahelyed elhagyására:
A nap pozítív gondolata a Piros Satyesz bt támogatásával.
Egyébként mostanában nagyon kevés szabadidőmben mongodb-ről olvasgattam, tovább kínoztam a drools planner-t mindenféle irányokban, meg wikipédiát szerkesztgetek. Egy csomó ötletem van, de nagyon nehéz időt keríteni rá.
- Melózolamíg meg nem halsz - nem hangzik nagyon biztatóan.
- Nyugdíjba mész - elvi lehetőség, gyakorlatban inkább az 1. lesz, de ezt hivatalosan még senki sem merte bevallani.
- Kirúgnak - előfordul, ezer lehetséges okból, és csak az egyik lehetséges ok vagy te.
- Felmondassz - ez a legjobb: már többre értékeled az idődet, mint azt a pénzt, amit adnak cserébe. Vagy csak mégtöbbet akarsz kapni érte...
A nap pozítív gondolata a Piros Satyesz bt támogatásával.
Egyébként mostanában nagyon kevés szabadidőmben mongodb-ről olvasgattam, tovább kínoztam a drools planner-t mindenféle irányokban, meg wikipédiát szerkesztgetek. Egy csomó ötletem van, de nagyon nehéz időt keríteni rá.
2012. augusztus 28., kedd
csapatelmélet röviden
Úgy tartja a mondás, hogy a pokolba vezető út jószándékkal van kikövezve. Ehhez hasonlóan már évek óta van egy olyan elképzelésem, hogy sok project kudarcáért felelős az, hogy nagyon-nagyon-cefetjó embereket vettek fel rá, akik képtelenek voltak együttműködni és alkudni.
A "jó" legveszélyesebb ellensége a "tökéletes".
Nem a legjobb kell, hanem elég jó.
NagyÁltalánosKeletiZenKonfuciuszButhistaBölcsesség csapatunk eheti jelentését olvashattátok.
A "jó" legveszélyesebb ellensége a "tökéletes".
Nem a legjobb kell, hanem elég jó.
NagyÁltalánosKeletiZenKonfuciuszButhistaBölcsesség csapatunk eheti jelentését olvashattátok.
2012. augusztus 1., szerda
Drools, Planner
Mostanában eltöltöttem egy kis időt egy prototipus projecten ami a drools planner integrációját késziti elő az oVirt-be. Ez még nem azt jelenti, hogy valaha benne is lesz, csak azt, hogy megpróbálom feltakarítani a környéket és beintegrálni. Gondoltam pár tapasztalatot megosztanék vele kapcsolatban.
Ha még nem találkoztál a drools projecttel, ez egy szabály-motor. Leírsz szabályokat, bedobálod a tényeket és bizonyos következtetésekre jut a drools, a következtetésekből pedig további következtetésekre. Egyrészt nagyon egyszerű és szerintem elegáns módja a szabályok leírásának, másrészt bizonyos bonyolult feladatokat egészen egyszerűen oldhatsz meg vele. Pl N királynő, labirintus, satöbbi iskolafeladatok. Na ezeken az iskolafeladatokon túl egész hasznos dolgokra is lehet használni a hétköznapi életben, most például az oVirt-ben (ami egy private cloud rendszer lenne, csak ahhoz még kicsit béna) virtuális gépek szerverekre való kiosztására próbálom használni.
(felemelő dolog szabadidőben is a melón pörögni, biztosan hősi gödörbe fognak elkapálni, ha beledöglök)
Eclipse marketplacen ha szétnézel, a JBoss IDE állítja magáról, hogy van benne Drools support. Ez sima mezeihazugság marketing, nincsen benne :-) A drools csomagok közűl kellett letölteni egy lefordított verziót és felinstallálni. Pár varázslót és egy editort kapsz, az editorban van syntax highlighting és egy kevés code completion. A vim-élménynél azért lényegesen jobb, de el tudnék képzelni barátságosabbat.
Aztán pl én néha nem szégyellek egy loggert bedobni a drools szabályaimnak, csak hogy meggyőzödjek róla, hogy tényleg kiértékelődnek. Érdemes csak debug szinten hajtani, mert komoly mennyiségű logot le tud termelni.
Aztán unit-tesztek: igen, mindenképpen unit-tesztelj! A szabályok csak futásidőben fordulnak le (első futás), szóval az hogy nem kiabált a build, az még a világon semmit sem jelent. És nagyon ajánlott ellenőrizni az eredményeket, mert könnyen előfordul, hogy elírtál egy feltételt a szabálynál és mégsem értékelődött ki.
A szabályok kiértékelési sorrendjáról pedig ennyit lehet tudni: javaslatot tehetsz rá (salience paraméter) de amúgy a drools nem enged beleugatni senkit se.
A pontozásnál több féle pontozást használhatsz, nekem a soft and hard tetszett legjobban.
Körülbelül ezer módon rúghatod tökön magad a drools plannerrel, kb 20 különbözőképpen nekem is sikerült, ebből párat nektek. Ha esetleg meg akarnátok próbálni :-)
Kiválló kiindulópont Geoffrey de Smet drools példagyüjteménye, ami a drools csomagok között letölthető. Szerintem a példagyüjtemény nélkül az elején feladatam volna. A dokumentáció az helyenként alulról közelíti a kettes érdemjegy határait. Pl az XML konfiguráció pontos leírását sehol se találtam, végül a forráskódból jöttem rá, hogy mit rontottam el.
Az egyik fájó különbség a példák és a rögvalóság között, hogy egyes példák egészen sokáig tart, amíg lefutnak. Sokkal tovább tart, mint a felhasználók türelme. A szerencse viszont az, hogy a legjobb megoldás a felhasználók túlnyomó részét teljesen hidegen hagyja, egyszerűen csak egy elég jó megoldást akarnak és persze tegnapra. Ezt sikerült olyan paraméterekkel elérni, mint
Aztán nézzük mivel szívtam még meg... Igen, a probléma tények (facts)-hoz például első nekifutásra nem a megfelelő listát adtam vissza. Pár kört lefutottam, mire rájöttem, hogy ennek következtében a pontozási szabályok egyszerűen nem kerülnek kiértékelésre.
Aztán a ConstraintType.POSITIVE-ra nem jöttem még rá, hogy hogyan kell használni, a példák között nincs egy se. Pár dolgot viszont eleinte pozitív állítások formájában próbáltam megfogalmazni. Na erről leszoktam, és csupa negatív pontozás van jelenleg. Nekem furcsa, hogy csak büntetéseket osztok a szabályaimmal, de megszokom. Majd a politikai pályafutásom alatt biztosan sok hasznát veszem ezeknek a tapasztalataimnak.
Egyébként, ha kicsit belejön az ember, úgy tűnik egészen komplex feladatok optimalizására is egészen könnyen lehet megoldást gyártani vele. A futási ideje igazán nem vészes, amennyiben jól paraméterezted a termináló feltételeket :-)
Ha még nem találkoztál a drools projecttel, ez egy szabály-motor. Leírsz szabályokat, bedobálod a tényeket és bizonyos következtetésekre jut a drools, a következtetésekből pedig további következtetésekre. Egyrészt nagyon egyszerű és szerintem elegáns módja a szabályok leírásának, másrészt bizonyos bonyolult feladatokat egészen egyszerűen oldhatsz meg vele. Pl N királynő, labirintus, satöbbi iskolafeladatok. Na ezeken az iskolafeladatokon túl egész hasznos dolgokra is lehet használni a hétköznapi életben, most például az oVirt-ben (ami egy private cloud rendszer lenne, csak ahhoz még kicsit béna) virtuális gépek szerverekre való kiosztására próbálom használni.
(felemelő dolog szabadidőben is a melón pörögni, biztosan hősi gödörbe fognak elkapálni, ha beledöglök)
IDE
Szóval a szabályokat egy speciális nyelven írod le, erre van több opciód is. Ez végül sima plain java bytecode-dá fog lefordulni. Szóval ez forráskód, ha tetszik, ha nem. A forráskód, amit írnod kell java-jellegű. Éppenséggel én nem szeretnék ilyeneket írni vim-ben, szóval az IDE támogatásnak utánna kellett járnom.Eclipse marketplacen ha szétnézel, a JBoss IDE állítja magáról, hogy van benne Drools support. Ez sima mezei
Pár tapasztalat
Első alapszabály a drools-hoz általában: bármilyen szabályt írsz is, ne legyen benne hálózati/adatbázis interakció! A drools kegyetlenül elkapja és nagyon lassú lesz vagy agyonterheli az adatbázisod. Valószinűleg mindkettő. Csinálj szépen in-memory modelt. Elösször tölt, aztán kiértékel. Sajnos ez nem mindig egyszerű.Aztán pl én néha nem szégyellek egy loggert bedobni a drools szabályaimnak, csak hogy meggyőzödjek róla, hogy tényleg kiértékelődnek. Érdemes csak debug szinten hajtani, mert komoly mennyiségű logot le tud termelni.
Aztán unit-tesztek: igen, mindenképpen unit-tesztelj! A szabályok csak futásidőben fordulnak le (első futás), szóval az hogy nem kiabált a build, az még a világon semmit sem jelent. És nagyon ajánlott ellenőrizni az eredményeket, mert könnyen előfordul, hogy elírtál egy feltételt a szabálynál és mégsem értékelődött ki.
A szabályok kiértékelési sorrendjáról pedig ennyit lehet tudni: javaslatot tehetsz rá (salience paraméter) de amúgy a drools nem enged beleugatni senkit se.
Planner
No nézzük mi ez a planner. A planner optimalizációs feladatokra segít adni valamilyen megoldást, a drools expertre építve. Ez konkrétan úgy történik, hogy pontozási szabályokat írhatsz le drools szabályokkal, írsz hozzá pár sor XML konfigurációt (ne aggódj, java config is van ha még nagyobbat akarsz szívni) és ráengeded a megoldó algoritmust. Visszakapsz egy megoldást jó esetben, és a hozzá tartozó elért pontszámot.A pontozásnál több féle pontozást használhatsz, nekem a soft and hard tetszett legjobban.
Körülbelül ezer módon rúghatod tökön magad a drools plannerrel, kb 20 különbözőképpen nekem is sikerült, ebből párat nektek. Ha esetleg meg akarnátok próbálni :-)
Kiválló kiindulópont Geoffrey de Smet drools példagyüjteménye, ami a drools csomagok között letölthető. Szerintem a példagyüjtemény nélkül az elején feladatam volna. A dokumentáció az helyenként alulról közelíti a kettes érdemjegy határait. Pl az XML konfiguráció pontos leírását sehol se találtam, végül a forráskódból jöttem rá, hogy mit rontottam el.
Az egyik fájó különbség a példák és a rögvalóság között, hogy egyes példák egészen sokáig tart, amíg lefutnak. Sokkal tovább tart, mint a felhasználók türelme. A szerencse viszont az, hogy a legjobb megoldás a felhasználók túlnyomó részét teljesen hidegen hagyja, egyszerűen csak egy elég jó megoldást akarnak és persze tegnapra. Ezt sikerült olyan paraméterekkel elérni, mint
- maximumUnimprovedStepCount, azaz ha egy ideig nem talál jobb megoldást, akkor itt hagyjuk abba.
- scoreAttained, azaz egy bizonyos minimális szintnél tovább már nem kell tovább menni.
Aztán nézzük mivel szívtam még meg... Igen, a probléma tények (facts)-hoz például első nekifutásra nem a megfelelő listát adtam vissza. Pár kört lefutottam, mire rájöttem, hogy ennek következtében a pontozási szabályok egyszerűen nem kerülnek kiértékelésre.
Aztán a ConstraintType.POSITIVE-ra nem jöttem még rá, hogy hogyan kell használni, a példák között nincs egy se. Pár dolgot viszont eleinte pozitív állítások formájában próbáltam megfogalmazni. Na erről leszoktam, és csupa negatív pontozás van jelenleg. Nekem furcsa, hogy csak büntetéseket osztok a szabályaimmal, de megszokom. Majd a politikai pályafutásom alatt biztosan sok hasznát veszem ezeknek a tapasztalataimnak.
Egyébként, ha kicsit belejön az ember, úgy tűnik egészen komplex feladatok optimalizására is egészen könnyen lehet megoldást gyártani vele. A futási ideje igazán nem vészes, amennyiben jól paraméterezted a termináló feltételeket :-)
Feliratkozás:
Bejegyzések (Atom)