Author: Oriol Rius

Aire de Barcelona: banys àrabs

Reading time: 3 – 5 minutes

Per l’aniversari d’Estefania i el meu ens van regalar unes sessions als banys àrabas de Barcelona; coneguts com “Aire de Barcelona“. Doncs bé, aquest dimecres a les 22h varem anar a comprovar què tal era l’experiència. Després de fer-nos una passejada tranquila i a bona temperatura des d’Arc de Triomf fins al Parc de la Ciutadella (~10min) varem trobar de forma ràpida i senzilla el lloc.

aire de Barcelona

Cal dir que la decoració de tot el local, des de la porta d’entrada passant per la recepció, els vestuaris i les piscines esta tot cuidadíssim, així doncs m’encanta el gust del decorador que va fer l’ambietació del lloc. A més els treballadors són molt amables i et tracten amb una pau que també relaxa moltíssim.

Pel que fa a les piscines, aquestes estan repartides segons canvis de presió o de temperatura. Així doncs, podem trobar des del típic hidromassatge d’aigua i d’aire passant per una piscina d’aigua salada. Pel que fa a les de temperatura, n’hi ha una a uns 36º, una a uns 45º i dues més a 16 i 18º respectivament. Realment és una passada experimentar les sensacions que et transmet el cos quan rep aquests canvis de temperatura tan bruscos. Obviament, res que envejar a les saunes finlandeses amb una bona dutxa freda després o llençar-se directament sobre la neu.

Parlant de sauna, obviament les instal·lacions també disposen d’una moderníssima sauna a 60º. Un altre detall de qualitat que realment varem apreciar és que hi havia una zona de descans prou amplia i còmode, malgrat no haver-hi cap coixí, on es podia prendre aigua fresca o te amb menta ben calent. Realment un plaer.

Pel que fa als massatges, n’hi ha de dos tipus els tradicionals aplicats sobre l’espatlla i en una camilla o els més exòtics que es fan sobre una pedra calenta i que bàsicament es centren en cap, cames i braços (tot i que cal triar 2 de les 3 opcions). En aquest punt és on no em va acabar d’agradar el circuit, ja que la qualitat del massatge craneofacial+peus que em varen fer va ser molt i molt light, la senyora que me’l va fer semblava que tingués por de cansar-se i tota l’aplicació era tan relaxada que no acabava de tenir aquells corrents que et fa el cervell quan et fan un bon massatge.

A més quan estavem a la piscina d’hidromassatge ens varem fixar que hi havia dos massatgistes que mentre feien massatges estaven xerrant i rient constantment a la zona de camilles. Tot això, és clar, no ajuda a relaxar gens ni mica quan et fan un massatge. A més cal sumar-li el fet que pel meu gust hi havia massa gent compartint les instal·lacions (crec que unes 30 persones), jo diria que més de 15 ja és exagerat ja que l’entorn perd el clima íntim que preten donar la llum tènue i la música relaxant de fons.

Posats a destacar coses negatives només afegiria que l’oli que et posen pel cos al fer-te massatges, malgrat fer una olor boníssima i tenir una textura molt agradable, al entrar en contacte amb l’aigua de les piscines i després d’anar passant gent per l’aigua creava una acumulació de gasos que va acabar deixant-me els ulls ben vermells i adolorits.

Després de tot això sembla que no em vagi agradar la visita als banys, la cosa no és pas així i li recomano a tothom que hi vagi. Això si, cal saber que no vas a rebre un molt bon massatge. Simplement a disfrutar de l’ambient íntim amb la parella i de les sensacions que t’ofereix l’aigua i l’entorn en si mateix.

pkg-config: controlant les llibreries que tenim instal·lades

Reading time: 9 – 14 minutes

pkg-config és una eina que ens ajuda quan hem de compilar aplicacions i llibreries. Permet descobrir les opcions que s’han d’afegir al compilador.

Alguns exemples ràpids de coses que podem fer:

# descobrir llista de llibreries que tenim instal·lades:
pkg-config --list-all
# cflags per una lliberia concreta
pkg-config nom_llibreria --cflags
# llibreries a incloure al compilador per una llibreria concreta
pkg-config nom_llibreria --libs

Ja en porta 9!!! si si el blog, avui compleix 9 anys…

Reading time: 2 – 3 minutes

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.

9e aniversari del blog

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’:

31 de juliol el dia dels sysadminsEn 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

Reading time: 11 – 18 minutes

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:

logging configurator for python

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

Reading time: < 1 minute 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

Reading time: 6 – 9 minutes

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.

Glosari de Telepathy

Reading time: 3 – 4 minutes

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.

Canvi font del editor d’articles del WordPress

Reading time: < 1 minute Després d'una estona fent canvis, per fi ho he aconseguit. Així doncs, per no perdre-ho: Cal modificar el fitxer: YOUR_WP_PATH/wp-includes/js/tinymce/themes/advanced/skins/wp_theme/content.css a la secció body.mceContentBody


XMPP amb BOSH: usant HTTP com a protocol de transport

Reading time: 4 – 7 minutes

La potència de treballar amb BOSH (Bidirectional-streams Over Synchronous HTTP) rau en que malgrat aparentment l’única forma que hi ha d’implementar XMPP sobre HTTP seria mitjançant tècniques de polling, o sigui, que periódicament el client anés connectant-se al servidor per preguntar si hi ha alguna nova informació per ell.

Doncs BOSH aconsegueix millorar aquest algoritme i el que intenta descriure és quelcom així:

  1. El client fa una connexió ‘HTTP request’ al servidor
  2. El servidor no envia cap resposta, així doncs, la connexió no es tanca.
  3. Quan el servidor té una informació (asíncrona) a enviar al client, llavors busca alguna connexió oberta del client i que estigui esperant resposta, o sigui, qu estigui al punt 2. Llavors el que fa és enviar l’informació a través d’aquesta connexió com una ‘request response’. La connexió es tanca.
  4. Un cop el client rep l’informació inmediatament després de tancar-se l’enllaç, aquest torna a obrir una connexió contra el servidor, o sigui, tornem al punt 1.

Obviament quan el client té alguna cosa a enviar això es fa en el punt 1.

A l’hora de la veritat els servidors de Jabber/XMPP el que tenen per oferir accés via BOSH és un especie de proxy que rep les connexions HTTP i les processa tal com he explica més amunt, per l’altre costat captura els events que rep de cada un dels clients XMPP que esta instanciant i va connectant els fluxes de dades que rep a través d’XMPP als sockets HTTP que té esperant informació.

Servidors BOSH incrustats en servidors XMPP

Obviament això ens porta a pensar, que podem usar un servidor BOSH per un servidor XMPP que no el suporti a mode de proxy. Això es podria programar de forma força senzilla amb twisted, per altre banda, hi ha servidors XMPP que ja suporten de serie el servidor BOSH, alguns exemples són: ejabberd, Tigase, Openfire i Jabber XCP.

Avantatges de tenir el servidor BOSH dins del servidor XMPP:

  • Sovint esta més ben testejat que el codi que podem fer-nos o que ha desenvolupat un tercer per fer aquesta tasca.
  • A priori hauria de ser més eficient, ja que la part de recepció d’events/senyals es fa a través de l’API nativa i no pas d’un client XMPP. Cosa que permet estalviar recursos i ser més eficient en la seva tasca.
  • És més fàcil de configurar, sovint només cal descomentar la línia corresponent del fitxer de configuració i llestos.

Com que no tot podien ser avantatges aquí van els inconvenients:

  • Un servidor BOSH que esta incrustat en un servidor XMPP obviament només pot atendre les peticions que van cap aquell servidor, per tant, si volem que això sigui escalable haurem de montar un balencejador de càrrega sobre el port HTTP per anar desviant connexions entre diferents sevidor BOSH.
  • El suport del servidor BOSH esta lligat al suport que la comunitat doni al servidor XMPP amb el que va lligat, això no sempre és suficient.

Quan no hem de suportar més d’un servidor XMPP, i a més aquest ja suporti BOSH no hi ha hauran mai problemes. La cosa es complicarà quan haguem d’escalar aquesta infraestructura.

Servidors BOSH dedicats, per tant independents del servidor XMPP

Per exemple: Punjab, Araneo, JabberHTTPBind i rhb. Pel que fa les avantatges i desavantatges d’aquest tipus de servidors BOSH, obviament són les mateixes que les anteriors però invertides.

Un servidor BOSH dedicat, per tant, podrà connectar-se a una xarxa XMPP a través d’un servidor XMPP federat sense problemes. Sovint el preu de sobrecarrega que això suposa esta més que justificat. Cal pensar que per cada client s’hauran de tenir sovint dues connexions TCP/HTTP més una connexió TCP/XMPP; per tant, tres sockets oberts per cada client connectat al servidor BOSH. Amb això suposo que queda clara la similitut amb un servidor proxy, no?
Com ja he apuntat abans escalar els servidors BOSH a través de ‘load-balancers’ és molt senzill, per exemple ús recomano nginex. Penseu que amb aquest ‘load-balancer’ podem tenir fins a10.000 connexions HTTP i només consumir 2’5Mb de memòria RAM. Per tant, aquesta també és una molt bona raó per usar-los externs els servidors BOSH. De fet, això no només ho penso jo sinó que aquí també ho pensen: BOSH cloud.
De fet, hi ha gent tan agoserada que gosa dir que XMPP és millor si els clients usen BOSH per accedir-hi, de fet, si llegeixes el raonament no sembla tan dolent: XMPP is better with BOSH.

Nota final

Per si algú encara no ho tenia clar, això és el que usen les llibreries d’XMPP implementades en JavaScript, o sigui, els client de xat (Jabber/XMPP) que via Web. Per exemple, el client que podem usar des de la pàgina web de gmail.

Obviament les aplicacions Jabber/XMPP són infinites i no només com a clients de xat. Per tant, podeu aprofitar aquestes llibreries JS que implementen BOSH per mostrar de forma interactiva a les vostres interficies web qualsevol tipus de contingut que obtingueu a través de la xarxa XMPP.

Scroll to Top