Jun 16

Somiant amb una extenció pel Gearman

Reading time: 5 – 8 minutes

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.

gearman stack

La gent que va començar a implementar Gearman, van ser els de Danga Interactive famosos per LiveJournal i SixApart.

Les meves idees

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

esquema idees de Gearman amb Redis

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

Jul 26

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.

Jun 11

gSOAP toolkit SOAP per C/C++

Reading time: 4 – 6 minutes

gSOAP, després de perdre-li la pista durant molt de temps aquesta llibreria de C i C++ crec que és la millor de codi obert i GPL que he trobat. Així doncs, ús la vull recomenar. El nom ve de “SOAP generator” i el va fer un professor, la versió 1.0 va sortir l’any 1999, per tant, podriem dir que l’eina esta més que provada si tenim en compte que va per la versió 2.7.1 que va sortir al gener del 2008.

Per entendre una mica que ofereix aquest toolkit esta molt bé fixar-se en aquest parell de gràfics que donen una visió de l’eina quan l’usem com a servidor SOAP:

gSOAP schema for server mode

i com a client SOAP:

gSOAP schema for client mode

Si haguessim de fer una llista de funcionalitats més detallada i tècnica em quedaria amb la que ofereix la pàgina de l’aplicació:

  • All-in-one package. Independence from third-party tools and libraries ensures successful builds and reliable runtime execution.
  • Open source with several license options.
  • gSOAP supports both pure ANSI C application development and mixed C/C++ application development.
  • gSOAP is the only toolkit that supports XML-to-C/C++ mapping for native C and C++ data types, which means that you can serialize your application data directly instead of having to use wrappers or SOAP/XML-specific data types. Any C or C++ data type can be serialized when it can be specified in a C/C++ header file (except unions). The toolkit automatically serializes pointer-based data structure graphs, including cyclic graphs and pointers to derived class instances to support polymorphism.
  • The toolkit follows the WS-I Basic Profile 1.0a compliance recommendations. It warns about potential interoperability issues before building a new Web service application, so you don’t have to go through another development cycle to make your services compliant. In addition, a report is available to check compliance.
  • Complete support for industry-standard Web services protocols SOAP 1.1/1.2 (RPC and doc/lit), WSDL 1.1, and UDDI v2. Supports XML schema with primitive XSD types, simpleTypes, complexTypes, extension, restriction, elements, attributes, groups, attributeGroups, and arrays (including polymorphic data types and SOAP 1.1 encoding of multi-dimensional sparse arrays). Extensive interoperability testing with other SOAP toolkits resulted in a toolkit release that has proven to be stable, robust, and reliable.
  • Supports SOAP-over-UDP, MIME (SwA), DIME (streaming), MTOM (streaming), HTTP1.0/1.1, IPv4, IPv6, RSS, XML-RPC, WS-Addressing, WS-Enumeration, and many other WS-* protocols.
  • Supports WS-Security: authentication, tokens, digital signatures (XML encryption will be added in the near future).
  • gSOAP is the only toolkit that implements streaming techniques for DIME and MTOM binary attachment transfers. It also supports SOAP with Attachements (SwA) Multipart/related MIME attachments.
  • Fast and efficient because gSOAP uses streaming XML parsing techniques. Typical round-trip SOAP service invocation latencies are below 1ms. Shown to be the fastest SOAP1.1/1.2 compliant C/C++ implementation available (wrt. most common uses we tested).
  • Very portable: Windows, Linux, Unix, Mac OS X, Solaris, HP-UX, AIX, FreeBSD, TRU64, Irix, QNX, VxWorks, MS-DOS. Also portable to handheld devices such as WinCE (Pocket PC), Palm OS, Symbian, and embedded Linux. Clients and server applications can be created that are under 100K with a total memory footprint under 150K.
  • The gSOAP WSDL parser automates server and client application development. gSOAP also generates WSDL documens to publish your services.
  • gSOAP Web Services and clients are just as easy to program as C# and JavaRMI, see How To section below.
  • Serialization of native C and C++ data types allows you also to store and retrieve application data from XML repositories.
  • Includes stand-alone HTTP/1.1 and HTTPS secure Web Server.
  • Offers Apache_mod, IIS, WinInet, CGI, and FastCGI interfaces.
  • Supports HTTP/1.1 POST/GET SOAP/XML messaging with compression, chunking, keep-alive, logging, and SSL encryption.
  • The gSOAP compiler can be conveniently integrated in an IDE. For example, MSVC++ 6.0 project examples with gSOAP integrated in MSVC++ are included in the gSOAP distribution for Windows.
  • Security: supports HTTPS and WS-Security. In addition, the source codes have been carefully written to avoid security holes such as buffer overruns. Also, gSOAP is open source which means that the gSOAP implementation can be verified.
  • gSOAP’s memory management uses garbage collection so (deserialized) data can be cleaned up without a hassle.
  • Company backup for support, licensing, and consulting.
  • Extensive documentation.
May 24

Buscar fitxers amb el contingut duplicat en linux…

Reading time: 1 – 2 minutes

Sovint costa trobar eines o petits scripts que fassin coses aparenment tan estupides com la comentada. De fet per windows he trobat alguns programes que tenen bona pinta tot i que no els he provat encara. Però per linux m’ha costat una mica més fins que he trobat el fdupes (local). Esta programat en C i realment és molt senzill d’usar i força potent.

També he trobat un petit script en bash que fa una busqueda força rudimentaria però útil en alguns casos:

OUTF=rem-duplicates.sh;
echo "#! /bin/sh" > $OUTF;
find "$@" -type f -print0 |
  xargs -0 -n1 md5sum |
    sort --key=1,32 | uniq -w 32 -d --all-repeated=separate |
    sed -r 's/^[0-9a-f]*( )*//;s/([^a-zA-Z0-9./_-])/\\\1/g;s/(.+)/#rm \1/' >> $OUTF;
chmod a+x $OUTF; ls -l $OUTF

La pàgina on he trobat aquest script és Unix shell script for removing duplicate files.