Ja en porta 9!!! si si el blog, avui compleix 9 anys…
Doncs si, com cada 31 de Juliol avui és l’aniversasri del blog. Aquest any l’aventura ja arriba al seu novè aniversari. Així doncs, l’any que ve ja farà una dècada que escric en aquest mitjà. Suposo que alguna festeta o similar hauré d’organitzar ni que sigui per quedar amb els mussols i celebrar-ho una mica.
Fent balanç del que han estat els artícles d’aquest any podem dir que la producció fins al moment ha estat de només 191 articles i que podriem dir que el podcast esta més que adormit. Així doncs, no és una producció gaire excessiva com la d’altres anys però jo potser m’atreviria a dir que el canvi d’estratègia amb els posts s’ha notat. És a dir, no només escric menys posts sinó que diria que la qualitat tècnica dels mateixos és superior; almenys el que intento en cada un d’ells és aportar quelcom de la meva collita i no fer referències en les que no es feia cap aportació més enllà de la redifusió de la troballa.
A més avui puc explicar com a efemeride que ha coincidit l’aniversari del blog com el dia dels ‘sysadmins’:
En part s’ha de dir que no sóc pas un ‘sysadmin’ en el sentit literal del terma, però si que un dels meus perfils professionals es dedica a portar a terme tasques d’administrador de sistemes per alguns clients o ISPs. Sempre en l’entorn dels sistemes Linux, com no podia ser d’altre forma.
Fins aquí doncs, poc més que agrair els que de forma més o menys continuada m’aneu llegint i m’aneu animant a seguir en aquesta resenya tècnica amb pinsellades personals del que vaig tocant en la meva vida professional i personal. Gràcies a tots!
cookbook: python logging
Sovint faig molts scripts de sistema usant python com a llenguatge de programació, doncs bé, sobretot quan aquests scripts s’han de llençar usant el ‘crontab’ va molt bé tenir un bon ‘log’ per saber com van les coses. Així doncs, la setmana passada vaig decidir posar-me a fons amb el tema ‘logging’ de python i ara la forma de fer ‘logs’ que uso per defecte en els meus scripts és:
Snippet de codi python que poso als scripts:
import logging,logging.config
# logging
logging.config.fileConfig('script_logging.ini')
#logger = logging.getLogger('errorpantalla')
logger = logging.getLogger('errorfitxer')
logger.setLevel(logging.INFO)Després d’importar la llibreria de ‘logging’ es recuperar el fitxer de configuració on estan definits els paràmetres de ‘logging’. Un cop carregat, descomento una o les dues línies que hi ha a continuació en funció de si vull logs per pantalla o només contra un fitxer. La última línia només indica fins a quin nivell de depuració he de fer mostrar logs.
El fitxer de configuració:
[loggers]
keys=root,errorpantalla,errorfitxer[handlers]
keys=fitxer,pantalla
[formatters]
keys=form01
[logger_root]
level=DEBUG propagate=1 channel= parent= qualname=(root) handlers=
[logger_errorpantalla]
level=DEBUG propagate=1 channel=errorpantalla parent=(root) qualname=errorpantalla handlers=pantalla
[logger_errorfitxer]
level=DEBUG propagate=1 channel=errorfitxer parent=(root) qualname=errorfitxer handlers=fitxer
[handler_fitxer]
class=handlers.RotatingFileHandler level=DEBUG formatter=form01 filename=paht_to_log_file/log_file mode=a maxsize=0 backcount=1 args=(‘paht_to_log_file/log_file’, ‘a’, 0, 1)
[handler_pantalla]
class=StreamHandler level=DEBUG formatter=form01 stream=sys.stderr args=(sys.stderr,)
[formatter_form01]
format=%(asctime)s %(levelname)s %(message)s datefmt=
A més vaig trobar un petit script, que carrega una GUI per generar les configuracions dels fitxers de configuració dels ‘logs’, realment útil i simple d’usar:
Aquesta GUI l’he trobada al paquet: logging-0.4.9.6.tar.gz concretament al directori ‘tests’. Si no voleu buscar tant també podeu descarregar-lo directament: logconf.py.
Apunts sobre Clutter
Acabo d’obrir una secció al wiki on aniré posant els meus apunts personals sobre Clutter, així doncs, si a algú l’interessa el tema pot seguir-los des d’allà.
Conceptes de Clutter
Des de fa uns mesos m’he posat a fons amb Clutter, es tracta d’una API més una ABI programada en C per crear interficies d’usuari. Malgrat tractar-se en escència d’una API per crear espais 3D amb objectes 2D, té la capacitat de poder moure els objectes en la coordenada Z. Així doncs, és pot aprofitar la potència d’OpenGL de forma transparent i senzilla i sense haver-se de preocupar de com representar objectes 2D en espais 3D, cosa gens senzilla per un neofit en el món dels gràfics com jo.
Clutter usa el seu propi reactor d’events, però en certs casos pot usar Gobject, Glib i Gtk també. És fàcilment integrable amb DBUS i amb GStreamer. En escència m’ofereix tot el que em cal per un projecte que porto entre mans. Pels que encara no ho tingueu clar, l’interficie gràfica que usa Moblin esta programada amb Clutter com a llibreria gràfica. De fet, és aquest projecte el que li ha donat molta força a Clutter que disposa de 29 programadors a temps complet, dels quals 14 no són d’intel (intel és qui promociona amb més força ‘moblin’).
Bé doncs, aquest impuls que ha patit moblin l’han portat a la versió 0.9.8 que és realment potent i ja gairebé igual que la versió 1.0 que hauria de sortir en breu. Tot i que fins ara Clutter s’ha caracteritzat pel retard en la sortida de les noves versions esperem que aquest cop no sigui així.
Abans d’entrar a definir quins són els elements que té aquesta llibreria, comentar que també disposa de binding de python cosa que pels ‘no-programadors’, com jo, és tota una alegria. També s’ha de dir que a dia d’avui, no hi ha bindings oficials per la branca 0.9 de Clutter que és l’experimental, o futura 1.0. Així doncs, jo només he provat el Clutter fins a la seva versió 0.8, malgrat la segueixo amb lupa la versió 0.9.x; a l’espera de poder començar a fer coses amb ella quan tingui els bindings de python.
Anem al motiu central de l’article, repassar els conceptes que usa Clutter fins a la verió 0.8:
- Stages: una aplicació de Clutter conté almenys un ‘stage’, aquests contenen actors que són: imatges, rectangles, textos, etc. Un ‘stage’ es comporta de forma semblant a un ‘canvas’ (tapís).
- Stage Widget: Podem contenir un ‘stage’ dintre d’un objecte finestre de GTK+. En aquests casos es pot usar GTK com a reactor d’events.
- Actors: són formes 2D mostrades en un espai 3D. Aquestes formes poden ser; per exemple, formes geomètriques, imatges, textos, etc. Si el que cal és tenir actors tridimencionals en aquest espai el que caldrà és instanciar directament l’API d’OpenGL. Per mostrar un actor en un ‘stage’ cal fer-ho a través d’un ‘container’.
- Transformations: es refereix a les transformacions que li podem fer a un ‘actor’ al mostrar-lo:
- Scaling: aumentar o disminuir la seva mida aparent, no la real.
- Rotation: es pot rotar sobre els seus eixos X, Y i Z.
- Clipping: fixar l’objecte sobre el ‘canvas’ això ens permet per exemple, crear una zona d’scrolling al seu intererior.
- Movement: desplaçar les coordenades de posició de l’objecte.
- Containers: en si mateix és un tipus especial d’actor, compost per altres actors fills que es posicionen en l’espai respecte la posició del seu contenedor. De fet, si ens hi fixem el propi ‘stage’ és un ‘actor’ de tipus ‘container’. Escencialment hi ha dos tipus de ‘containers’: ClutterContainer i ClutterGroup.
- Events: la classe ‘actor’ emet una serie de senyals que podem capturar per enllaçar amb funcions, les senyals són:
- button-press-event: emès quan l’usuari prem el botó del ratolí sobre l’actor.
- button-release-event: emès quan l’usuari deixa anar el botó del ratolí sobre l’actor.
- motion-event: quan el ratolí es mou per sobre l’objecte.
- enter-event: emès a l’entrar sobre la superficie de l’actor.
- leave-event: emès al sortir de la superficie de l’actor.
- Timelines: es poden usar per canviar la posició o aparença d’un actor al llarg del temps. Les línies de temps es poden usar soles o amb combinació dels ‘effects’ i els ‘behaviours’. Per cada ‘frame’ que s’ha de dibuixar en el temps s’emet una senyal anomenada ‘new-frame‘, obviament la podem connectar a alguna funció. Al crear una línia de temps hem d’espificar dos paràmetres: la quantitat total de ‘frames’ que tindrà i els ‘frames per segon’ a la que es reproduirà.
- Score: podem agrupar diverses ‘timelines’ en un ‘score’, això ens permet posar en marxa o parar diverses ‘timelines’ a la vegada.
- Effects: són una serie de funcions que podem aplicar sobre els actors usant una ‘timeline’ amb l’objectiu de canviar les propietats al llarg del temps, usant un simple càlcul numèric. Sovint aquesta és la forma més simple de crear una animació. És important recordar que els efectes només poden afectar a un actor en una ‘timeline’ i no podem canviar els efectes al llarg del temps, per fer això cal fer-ho amb un ‘behaviour’.
- Behaviours: tenen la capacitat de canviar una propietat específica d’un actor al llarg del temps aplicant un simple càlcul numèric. A diferència dels ‘effects’ amb els ‘behaviours’ podem controlar més d’un actor a la vegada i canviar els paràmetres dels càlculs que es fan al llarg de la ‘timeline’. Un exemple ben senzill d’aplicació d’això seria que podem fer que la funció que es crides al llarg del temps detecti que s’ha acabat l’efecte aplicat i el faci tornar a començar automàticament, simplement canviant el paràmetre de l’efecte que s’esta aplicant. Els ‘behaviours’ que té Clutter per defecte són:
- ClutterBehaviourBspline: mou l’actor a través una línia ‘bezier‘.
- ClutterBehaviourDepth: mou un actor a l’eix Z.
- ClutterBehaviourEllipse: mou un actor al llarg d’una el·lipse.
- ClutterBehaviourOpacity: canvia l’opacitat d’un actor.
- ClutterBehaviourPath: mou un actor al llarg d’un camí definit per una serie de punts.
- ClutterBehaviourRotate: rotar un actor.
- ClutterBehaviourScale: canvia la mida aparent d’un actor.
Per fer aquesta referència m’he basat amb la informació de la guia ‘Programming with Clutter‘ escrita per Murray Cumming.
Video sobre digital signage fet per Intel
Glosari de Telepathy
Abans que res una petita introducció a: Què és Telepathy?
Es tracta d’un framework que unifica diferents sistemes de comunicació en temps real. Usa DBUS com a interficie de comunicació entre aplicacions.
Avantatges de Telepathy:
- Temps real: suporta sistemes IM (un-a-un i grups), video trucades i trucades de veu.
- Unificat: permet que diferentes aplicacions i de forma simultànea s’aprofitin de les capacitats del sistema i que treballin de forma col·laborativa.
- Framework: disecciona el sistema de comunicacions en petites parts i les fa tan simples com pot perquè al usar-les contjuntament el procés de comuncació sigui el més senzill possible.
El glosari de termes, en poques paraules el que cal tenir en ment i recordar quan parlem de Telepathy.
- MUC (multi user chat): o també anomenat chat room, o canal de xat.
- Mission Control: responsable de la gestió de comptes de missatgeria: creació de connexions i manteniment dels estats de presència dels contactes.
- Glabbe: és un connection manager de Jabber.
- Tapioca: és un framework per VoIP i aplicacions IM. Suporta SIP/XMPP.
- Farsight: idem que el Tapioca, però orientat a videoconferències.
- Stream Engine: exporta les funcions de Farsight a DBUS. i viceversa.
- Tubes: és el mecanisme que usa Telepathy per suportar transferència de dades entre aplicacions remotes, o sigui: remote IPC. La idea que hi ha darrera és “si dues persones connectades a un servei de IM poden parlar, perquè dues aplicacions connectades a un IM no poder intercanviar informació”.
- Stream Tubes: és un mètode de transport usat per Telepathy molt similar al SOCK_STREAM sockets: enviament de paquets ordenat i confiable.
- IB (in-band): quan els ‘Tubes’ usen el servidor de missatgeria per intercanviar dades. Aquest sistema pot ser molt lent per transportar depèn quin tipus d’informacions, per exemple, sessions VNC.
- OOB (out of band): els ‘Tubes’ de dades usen diferents camins fora de la xarxa XMPP, per exemple, connexions directes entre peers via UDP o TCP.
- Empathy: es tracta d’un client d’IM programat usant les llibreries de Telepathy.
- XEP-0095 Stream Initiation: aquesta especificació defineix una extenció d’XMPP que iniciar fluxes de dades entre dos entitats connectades a la xarxa XMPP. El protocol soporta la possibilitat d’incloure metadades sobre el fluxe de dades a intercanviar.
- XEP-0065 SOCKS5 bytestreams abstract: es defineix una extenció d’XMPP per establir connexions OOB entre dos peers, la connexió entre els peers pot ser directe o via un proxy SOCKS5, en principi la idea és usar TCP per aquests tipus d’enllaços malgrat també podria funcionar per UDP.
- XEP-0163 PEP (Personal Eventing Protocol): defineix la semàntica d’un protocol que usant les funcions publish-subscribe d’XMPP dinfon els canvis d’estat i presencia. D’aquesta forma podem fer funcionar l’estat d’una compte com si es tractés d’un servei pubsub; simplificant la possibilitat de sindicar-nos a dades i notificacions associades amb aquella compte. Un exemple, per fer-ho més entendor: podem tenir un servei d’agenda que ens avisa que hem de fer certes coses si és que estem disponibles però si en canvi este ausents no té sentit que ens avisi.
- XEP-0080 User Location: és una extenció per permet enviar informació sobre la posició geogràfica de l’usuari.