Feia massa temps que no jugava amb DBUS i les he passat una mica negres aquesta tarda intentant recordar com funcionava tot plegat. La qüestió de base és molt senzilla, com que el codi parla per si mateix. Simplement adjuntaré els dos codis.
Receptor de senyals DBUS, rep la senyal amb format ‘string’ i la mostra:
#!/usr/bin/env python#--encoding:UTF-8--"""entra en un loop esperant senyals emeses a:dbus_interface=cat.oriolrius.provaobject_path="/cat/oriolrius/prova/senyal"ambnomde senyal:'estat'quanesreplasenyallamostrem"""import gobjectimportdbusimportdbus.mainloop.glibdefmostra(m):printmdbus.mainloop.glib.DBusGMainLoop(set_as_default=True)bus = dbus.SessionBus()bus.add_signal_receiver(mostra,path="/cat/oriolrius/prova/senyal",dbus_interface="cat.oriolrius.prova",signal_name = "estat" )loop = gobject.MainLoop()loop.run()
Emisor de senyals DBUS, envia una senyal de tipus ‘string’ amb el contingut ‘hola’:
#!/usr/bin/env python#--encoding:UTF-8--"""Emet una senyal a dbus, al bus 'session' amb destí:dbus_interface=cat.oriolrius.provaobject_path="/cat/oriolrius/prova/senyal"ambnomde senyal:'estat'"""import gobjectimportdbusfromdbus.serviceimportsignal,Objectimportdbus.mainloop.glibclassEmetSenyal(Object):def__init__(self,conn,object_path='/'):Object.__init__(self,conn,object_path) @signal('cat.oriolrius.prova')defestat(self,m):globalloopprint("senyal emesa: %s" % m)gobject.timeout_add(2000,loop.quit)dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)loop = gobject.MainLoop()bus = dbus.SessionBus()o = EmetSenyal(bus,object_path='/cat/oriolrius/prova/senyal')o.estat('hola')loop.run()
Usant el ‘dbus-monitor’ es pot veure la traça del missatge:
Un article ‘fast-n-dirty’ sobre potser la millor llibreria que he trobat per treballar amb templates i python: Cheetah. Es tracta de poder generar fitxers de texte de forma senzilla: fitxers de configuració, pàgines web, emails, etc. a partir de plantilles. Realment útil en molts entorns.
Les funcionalitats (copy-paste de la web):
is supported by every major Python web framework.
is fully documented and is supported by an active user community.
can output/generate any text-based format.
compiles templates into optimized, yet readable, Python code.
blends the power and flexibility of Python with a simple template language that non-programmers can understand.
gives template authors full access to any Python data structure, module, function, object, or method in their templates. Meanwhile, it provides a way for administrators to selectively restrict access to Python when needed.
makes code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates. One template can subclass another and selectively reimplement sections of it. Cheetah templates can be subclasses of any Python class and vice-versa.
provides a simple, yet powerful, caching mechanism that can dramatically improve the performance of a dynamic website.
encourages clean separation of content, graphic design, and program code. This leads to highly modular, flexible, and reusable site architectures, shorter development time, and HTML and program code that is easier to understand and maintain. It is particularly well suited for team efforts.
can be used to generate static html via its command-line tool.
a qui va orientat (copy-paste de la web):
for programmers to create reusable components and functions that are accessible and understandable to designers.
for designers to mark out placeholders for content and dynamic components in their templates.
for designers to soft-code aspects of their design that are either repeated in several places or are subject to change.
for designers to reuse and extend existing templates and thus minimize duplication of effort and code.
and, of course, for content writers to use the templates that designers have created.
Cal dir que no sóc massa ordenat al presentar noves tecnologies ja que primer de tot vaig fer un bechmark sobre Gearman abans de fer-ne una introducció, doncs bé com que en aquest article vull parlar sobre unes possibles extensions sobre les que vull treballar amb Gearman primer de tot faré una petit introducció al projecte.
Introducció
Gearman és el que comunment anomenem un servidor de tasques, o sigui, que quan el nostre codi ha de demanar una tasca, funcionalitat, treball, o quelcom similar és molt interessant de cara a:
l’escalavilitat: podem tenir tants servidors i/o processos consumint tasques com ens interessi.
paral·lelisme: les tasques es poden consumir paral·lelament.
balanceix de càrrega: podem fer map/reduce sobre les tasques i enviar-les als servidors que ens interessis per distribuir la càrrega.
independència entre lleguatges: el codi que demana la tasca i el que consumeix la tasca poden ser totalment diferents, les llibreries que té Gearman són: PHP, Pearl, Ruby, C, Python, etc.
interficie HTTP: a més disposa d’una interficie client HTTP que ens permetra injectar tasques desde llenguatges no suportats des de les llibreries de Gearman.
usar un servidor d’aquest tipus, ja que a més de permetrens demanar tasques síncrones, també podem demanar-li tasques asíncrones. O sigui, que no només no sabem qui ens esta fent la feina limitant-nos a rebre’n el resultat sinó que també podem demanar que aquesta feina es faci quan es pugui.
Per si tot això no fos poc encara hi ha més avantatges:
Open Source
Programat en C
Petit i molt ràpid
Suporta diversos backends: RAM, SQLite, Memcached, Tokyo Cabinet, etc.
Després d’aquesta introducció, ara ja puc parlar de les coses que voldria que fes Gearman però que no fa. Primer de tot he de parlar de les avantatges que tindria si pogués tenir un backend contra Redis. El que persegueixo al connectar Redis amb Gearman és aconseguir:
persistència de tasques malgrat es reiniciï Gearman
persistència de tasques en disc malgrat es reinciï Redis, gràcies a:
l’escriptura asíncrona a disc
bgrewriteaof: evita que per l’escriptura asíncrona d’informació es perdin dades al reinciar bruscament Redis
publicar a un canal PubSub de Redis els canvis que es fan sobre una tasca que s’ha enviat a ‘background’
Integració amb Redis
Es tracata de fer el mateix que s’ha per integrar backend de tokyo cabinet: queue_libtokyocabinet.c el problema d’usar tokyo cabinet contra disc és la pèrdua brutal de rendiment respecte a usar-lo contra RAM, ja que les escriptures es fan de forma síncrona.
A nivell de codi les semblances més grans són amb: queue_libmemcached.c, malgrat el problema que té aquesta implementació és que cada cop que reiniciem memcached no tenim persistència de la informació que s’havia guardat en memcached, és com si les claus que s’han intrudit en l’anterior sessió s’haguessin esborrat. A més memcached no suporta persistència en les seves dades tampoc.
Així doncs, el que cal fer és agafar el millor d’amdues integracions i fer el mòdul amb Redis.
Subscripció a les actualitzacions d’una tasca via Redis
Quan s’envia una tasca en segon pla a Gearman aquest ens retorna un ‘Handler’ per poder preguntar sobre l’estat de la tasca, el problema és que si volem saber com evoluciona la tasca o que ens informi quan ha acabat no hi ha manera de saber-ho si no és fent ‘pooling’. Per altre banda, el ‘worker’ va actualitzant la tasca cada quan creu convenien perquè Gearman pugui saber quin és l’estat de la mateixa.
La meva idea és que al usar el backend de Redis, al mateix moment que s’actualitzi l’estat de la tasca també es publiqui (publish) a un canal PubSub de Redis de forma que el codi que ha enviat la tasca pugui subscriures (subscribe) a aquest canal i en temps real i amb un cost de recursos baixíssim es pugui seguir l’estat de la tasca. Això ens evitaria la necessitat de que Gearman hagués de poder cridar un mètode de callback per informar-nos de l’estat de la mateixa, ja que hi ha alguns llenguatges en que fer això no és tan senzill.
En el gràfic que enganxo a continuació podem veure un esquema que he fet sobre això:
1) el nostre codi envia una tasca en ‘background’ (segon pla) a Gearman i aquest li torna un ‘Handler’ per identificar la tasca.
2) es guarda la tasca a Redis (set)
3) el nostre codi es subscriu al canal PubSub de la tasca
4) un worker demana la tasca
5) es publica l’estat de la tasca
6) es va actualitzant l’estat de la tasca
7) es van repetint els punts (5) i (6) fins acabar la tasca
Feedback
Com sempre s’accepten tota mena de crítiques i idees sobre la meva ‘paranoia’.
No es tracta d’unes proves de rendiment serioses i estríctes, però almenys en el meu cas m’han servit per tenir una idea del rendiment d’aquestes aplicacions i poder dissenyar diferents arquitectures amb una mica més de coneixement de causa.
Degut a un requeriment que teniem a la feina he montat un entorn d’integració continua. En escència el que es busca és el següent:
Llençar de forma automàtica tests sobre els commits que es fan al codi (buildbot)
Tenir un repositori dels resultats dels tests fàcil de consultar (web) (buildbot)
Suportar tests sobre rendiment (profiling) automàtics (guppy-pe + resource)
Poder comprovar quina és l’evolució d’aquests tests de rendiment amb una eina visual (codespeed)
Per tal d’aconseguir aquests objectius s’ha usat:
buildbot: que permet automatitzar l’entorn de compilació i testeix dels commits que es van fent al repositori. (esta programat en python). Per entendre millor buildbot, ús recomano llegir l’apartat: system architecure del seu manual.
codespeed: és una eina feta amb python+django+mysql a través d’una interficie HTTP+JSON pot injectar informació a la BBDD i a través de la GUI ens mostra:
overview: a través d’una taula mostra les tendències dels resultats dels benchmark associats a un executable.
timeline: mostra en una gràfica l’evolució dels resultats arxivats sobre un benchmark concret fets sobre un host.
guppy-pe: ens permet extreure dades referents als recursos de sistema que esta consumint una part del codi: classe, funció, variable, etc.
resource: és un módul de python que permet saber (resource.getrusage(PID)) quins recursos esta consumint un PID en un moment donat.
Com que la documentació que he fet per la feina l’he hagut de filtrar per no revelar informació interna, la documentació que publico esta en format OpenOffice i PDF perquè sigui senzill per tothom llegir-la i modificar-la si vol.
A vegades cal fer algún invent extrany amb el python, com per exemple, el haver de tenir dues versions instal·lades. Sovint la nostre distribució ja portarà una versió del mateix i a més moltes eines de les distribucions acostumen a anar lligades a aquesta versió que millor no malmetre.
Cookbook d’ordres per instal·lar un python 2.6.5 a més del 2.4.3 que ja portava el host:
Porto mesos somiant amb fer la prova de concepte que explico en aquest article, intentaré descriure en que consisteix però ja aviso que la cosa és un pèl complicadilla.
Funcionalitats requerides:
long polling: l’objectiu és rebre els canvis d’una base de dades de couchdb en temps real sense haver d’anar preguntant si hi ha canvis, sinó que aquest s’envien cada vegada que es donen de forma automàtica.
A través de jQuery el que vull és actualitzar una pàgina web de forma asíncrona, de forma que els nous resultats que vagin entrant a la BBDD es vagin mostrant en temps real a la pantalla.
JSONP, és una tècnica que ens permet rebre la sortida JSON de CouchDB i després cridar una funció de callback de JavaScript. El problema és que la funció jQuery.getJSON() original de jQuery té algunes mancances que gràcies a el plugin jQuery-JSONP podem solucionar, aquestes són: (copy/paste de la web del plugin)
error recovery in case of network failure or ill-formed JSON responses,
precise control over callback naming and how it is transmitted in the URL,
multiple requests with the same callback name running concurrently,
two caching mechanisms (browser-based and page based),
the possibility to manually abort the request just like any other AJAX request,
a timeout mechanism.
CouchDB és una base de dades NoSQL basada en documents que és capaç d’emetre una senyal (trigger) cada vegada que el contingut d’una base de dades canvia. Per més informació sobre el tema es pot consultar a: CouchDB: The Definitive Guide al capítol Change Notifications.
Cross-domain: quan es llença una petició XmlHttpRequest (la base del AJAX) amb JavaScript tenim la limitació de només poder-ho fer sobre el domini que serveix la pàgina web, cap altre port ni subdomini. Obviament tampoc un altre host. Per saltar-se aquesta restricción és quan cal recorrer a JSONP.
La prova de concepte ha estat crear una base de dades anomenada: notifcations on es guarden documents que són notificacions a mostrar a la pàgina web.
El codi és força simple de seguir, primer de tot es carreguen les llibreries: jQuery 1.4.2 i jquery-jsonp 1.1.4, ambdues necessaries per cridar el métode $.jsonp que és el que realment farà la feina.
A continuació es declara la funció longpoll que té com a paràmetre el númeral que indica quin ha estat el últim canvi a la base de dades. Aquest s’utiliza per construir la petició que es fa a CouchDB:
incloent els documents que han canviat (include_docs=true)
tracta la petició com a long polling (feed=longpoll)
mostra els canvis des de la versió X (since=X)
quan enviis els canvis fes una crida a la funció de callback definida aquí (callback=?)
‘?’ és substituit per jquery-jsonp per la funció anomenada ‘C’, aquest nom es pot canviar usant paràmetres en la declaració de $.jsonp() que ve a continuació
Els missatges de l’estil ‘console.log()‘ són per tenir un seguiment del que va passant a la consola de javascript del navegador.
$.jsonp() té força paràmetres possibles definits a la API, però en aquesta prova de concepte només uso ‘url’, ‘success’ i ‘error’. El primer esta clar que és, els altres dos són les funcions a cridar quan l’acció va bé o malament respectivament. Dins de la funció posem el codi referent a les accions que volem fer, per exemple, actualitzar la pàgina actual. Com que això només és una prova de concepte el que faig és mostrar missatges per consola i llestos. La part més important és fixar-se que quan la cosa ha anat bé es fa una crida a ella mateix de forma que la cosa no acabi mai. De fet quan hi ha un error es podria també fer una crida a si mateix perquè no pares de provar de llençar la petició un i altre cop, però el que he fet per provar eś que es notifiqui a la consola de javascript i prou.
Fora de la funció longpoll el que es fa és una petició JSONP per saber quina és l’últim número de seqüència de la base de dades, paràmetre necessari per entrar per primera vegada a la funció recursiva de longpoll.
Conclusions
Pot semblar tot una mica enravassat però diria que he simplificat el problema moltíssim, ja que fins ara havia estat teoritzant moltíssim sobre el tema. Fins que ahir i abans d’ahir vaig haver de posar-me a provar-ho a la pràctica per saber exactament com es podia implementar. Sota el meu punt de vista ha quedat tot força net i entenedor.
Pels que sou programadors de webs habitualment haureu tingut necessitats semblants així doncs espero que ús pugui ser tan útil com a mi, de fet, fa unes setmanes que estic treballant amb Tiny Core Linux montant un Quiet PC sobre una DOM de 512MB per usar-la de sistema de monitorització de les meves xarxes i les d’alguns clients, espero que d’aquí uns mesos pugui donar-vos més informació del projecte.
Com sembla que és una tònica en la meva vida tot corre molt, tot va molt ràpid i sempre hem passen mil i una coses. Qualsevol diria que normalment treballo des de casa, potser és gràcies a internet que hem permet mourem molt i aprofitar al màxim les sortides. Així doncs, per posar-me al dia he decidit re-editar un post que vaig fer l’any 2007: Fotografies dels últims dos dies. En aquest cas potser parlem de més de dues setmanes però la idea és la mateixa: buidar la targeta del mòbil i anotar coses curioses o no tan curioses al blog.
Des del 24 de gener continuo sense el meu portàtil, o sigui, que ja porto més d’un mes de patiments i esperes. De fet, gràcies a uns companys de LanA2 vaig poder-lo disfrutar garibé una setmana només netejant-lo ben net, però finalment va tornar a morir amb el mateix problema que el primer dia:
Malgrat alguna gent ha tingut la sort de que Dell li ha reparat el problema gratuitament, a d’altres com ara jo no hem tingut tanta sort. Així doncs, per eBay he demanat una placa base nova i encara estic a l’espera de rebre-la. Així podré recuperar el Dell m1330 que tan bon rendiment m’ha donat aquests quasi 3 anys.
Per altre banda, he demanat un Dell Studio 13 que fa més d’1mes que espero que Dell es digni a entregar-me, de fet, avui havia de rebre’l però segons l’estat de la comanda això no serà fins la setmana que ve, cosa que ja hem costa de creure quan han incomplert més de 3 vegades la data d’entrega.
A nivell tècnic podriem dir que és l’evolució del m1330. Amb 8GB de RAM, 500GB d’HD i algunes millores en el lector de targetes flash a més d’una gràfica més potent, etc. Però el que realment m’ha fet comprar-ne un de nou no és tan el hardware sinó una garantia de 3 anys del dia després perquè no torni a estar com ara.
Canviant de tema, fa unes setmanes vaig ser al Mobile World Congress (MWC’10) de Barcelona, on vaig aprofitar per retrobar-me amb molts amics, no només durant la fira sinó durant tot el dia. Fins hi tot vaig retrobar-me amb el Fernando que després d’uns anys a Dublin a decidit establir-se a Barcelona. Pel que fa a la fira si no hi heu pogut anar, més enllà de mirar-vos mil fotografies i videos dels mòbils i d’altres cosetes que hi van presentar ús recomano llegir: 20 key trends at Mobile World Congress 2010 (1-10, 11-20).
Aquest any l’entrada va ser gentilesa de Google i més concretament de l’Ernest, que no només ens va aconseguir aquest passe als amiguetes sinó també una entrada a la conferència de desenvolupadors d’Android que es feia a la fira. La sorpresa que ens tenien preparats l’Ernest i la gent de Google és el regal d’un Nexus One al final de la xerrada.
Sobre el telèfon comentar que és un Android i com a tal tampoc es diferència tan del HTC Hero que ja tenia, això si quan sortim del sistema operatiu per mirar-nos el telèfon és impressionant el ràpid que arriba a funcionar la CPU d’1GHz i els més de 500MB de RAM. Tot el que feia amb la Hero ara mateix vola amb el Nexus One i quan dic vola vull dir que vola, estic impressionat. Per cert, el meu més gran descobriment dels últims dies a nivell d’aplicacions és una aplicació que es diu WebSharing i que permet compartir tot el mèdia que tinc al meu telèfon via Wi-Fi a través d’una interficie web senzillíssima d’usar i molt potent.
Aquesta setmana passada també ha estat molt especial perquè movilpoint ha venut la seva primera unitat de la nova gama de productes. Després de molts mesos de feina s’ha reorientat totalment la companyia i de forma oficiosa ja puc informar que els nous productes de l’empresa seran totalment hardware, o sigui, que ja no farem software. Són productes totalment ecològics, molt econòmics i fets a mida de cada client a través d’una configuració via web. La gama de producte esta totalment orientada a fires i events, espero poder-vos presentar la nova web ben aviat.
Mentretant podeu veure com estem treballant amb els nous punts d’informació:
i també donar un cop d’ull a la primera unitat instalada a casa d’un client:
Finalment aquest cap de setmana he estat a la DrupalCamp 2010 que es feia al Citilab de Cornellà; després de fer campana al phpWorkShop d’aquest any he passat a coneixer una mica més a fons a la gent i la tecnologia de Drupal. En general he sortit amb molt bon gust de boca de tot plegat, unes xerrades amb un bon nivell tècnic, una organització molt ben portada i una col·lecció de geeks més gran i fidel del que m’imaginava, això si, molt de Mac suelto 😉
Parlant de temes tècnics potser el que més m’ha agradat és SCRUM, que com cap metodologia de projectes és perfecte però si que aporta certs elements d’XP (eXtreme Programming) que sempre he trobat molt interessants. Potser la decepció més gran Open Atrium, no sé perquè m’esperava alguna cosa molt més potent. Per cert, alguna gent com en @quimet i en @linobertrand m’han preguntat què montava jo encomptes d’Open Atrium i això ho vaig respondre a un podcast que vaig fer el maig del 2008: Podcast 1×07: gestió de projectes. Per altre banda, des de llavors també he treballat amb Redmine i el recomano moltíssim, ja que esta molt ben integrat i malgrat esta fet amb RubyOnRails del que no en sé res de res, he de reconeixer que és una solució molt ben pensada i ben feta.
Abans d’acabar algunes fotos de la DrupalCamp 2010:
Avui he descobert microfeed, es tracta d’una implementació d’arquitectura client-servidor que permet accedir a diferents fonts d’informació d’internet publicades via feeds. Potser el que més gràcia m’ha fet és que si volem usar aquesta llibreria per programar, per exemple, una GUI que permeti gestionar aquestes dades l’accés es fa a través de DBUS. És a dir, per un costat microfeed recull les dades de les seves fonts originals (twitter, facebook, identi.ca, etc) i la GUI es comunica amb la llibreria via DBUS. De fet, el que realment m’ha fet gràcia és que això és el que fa Telepathy però encomptes de fer-ho contra feeds ho fa contra jabber/XMPP, MSN, IRC, SIP, etc.
Una forma molt visual d’entendre que fa microfeed és amb aquest esquema:
En principi la única GUI que he trobat que usa aquest backend és Mauku que és una aplicació pensada per Maemo.
Amb el primer cop d’ull a la llibreria no he arribat a trobar com ho fa per rebre els feeds dels llocs com twitter i facebook, imagino que ho farà via polling. Seria interessant saber si també ho pot fer per PubSub. Ja que segons l’esquema només tinc la sensació que el PubSub s’usa via DBUS. Si algún dia em poso a treballar amb la llibreria espero aclararir-ho.
Implementació del XEP-0060, o sigui, d’un servei de publish-subscribe (PubSub) esta escrit amb Python i Twisted. Bàsicament el que permet és que sobre un servidor XMPP estàndard hi podem connectar un servei basat en PubSub, o sigui, que nosaltres publiquem una serie d’informació que un seguit de clients consulten perquè hi estan subscrits. És un mètode basat en events (no-polling) molt adient per disfondre certs tipus d’informació.
A vegades programem shell scripts que necessiten enviar el seu resultat a la xarxa XMPP, per exemple, imagineu que volem comunicar la caiguda d’un servei a través de GTalk, doncs aquest toolkit ens simplifica moltíssim aquesta tasca. Esta programat en ruby i a part de poder-se usar des de la CLI també podem integrar-ho com a llibreria dins d’un codi en ruby.
