Category: Development, Models and Methodologies

Celery logs through syslog

2013/09/06 1 comentari

Reading time: 2 – 2 minutes

Celery logs are colorized by default, the first big idea is disable color logs. It’s as easy as setting ‘CELERYD_LOG_COLOR’ to ‘False’ in ‘celery.conf’. The code could be something like this:

celery.conf.update('CELERYD_LOG_COLOR' = False)

Secondly we need a function where we set up a new handler and other settings to celery logging system. For example, the code could be:

from __future__ import absolute_import
from logging import BASIC_FORMAT, Formatter
from logging.handlers import SysLogHandler
from celery.log import redirect_stdouts_to_logger

def setup_log(**args):
    # redirect stdout and stderr to logger
    redirect_stdouts_to_logger(args['logger'])
    # logs to local syslog
    hl = SysLogHandler('/dev/log')
    # setting log level
    hl.setLevel(args['loglevel'])
    # setting log format
    formatter = Formatter(BASIC_FORMAT)
    hl.setFormatter(formatter)
    # add new handler to logger
    args['logger'].addHandler(hl)

Pay attention to ‘redirect_stdouts_to_logger’ it’s used to send all outputs like print’s or something else to syslog.

Thirdly we want to use those settings in our celery tasks, then we have to connect ‘setup_log’ code to some celery signals. Those signals are launched when ‘task_logger’ and ‘logger’ are configured. To connect signals:

from celery.signals import after_setup_task_logger, after_setup_logger

after_setup_logger.connect(setup_log)
after_setup_task_logger.connect(setup_log)

Fourthly we have to get the ‘logger’, we can have more than one if we are interested in records with task context or without it. For example:

logger = get_logger('just_a_name_for_internal_use')
logger_with_task_context = get_task_logger('name_of_the_task_to_be_recorded_in_logs')

Finally we only have to use those loggers with common methods DEBUG, INFO, WARN, ERROR and CRITICAL:

@celery.task
def the_task():
    logger.info('this is a message without task context')
    logger_with_task_context.debug('this record will have the prefix "name_of_the_task_to_be_recorded_in_logs" in syslog')

A pair of themes for ExtJS

2013/05/28 No hi ha comentaris

Reading time: 1 – 2 minutes

I’m a ExtJS JavaScript framework believer, but there other interesting and famous JavaScript frameworks like Bootstrap and jQuery. IMHO ExtJS is more focused on web applications than public web. In this post I want to share two ExtJS themes that helps to improve UI look and feel.

The first one is a bootstrap look and feel for ExtJS:

if you want to test it take a look to demo site. The theme is opensource and you can find the source in github.

The second and last one is Clifton theme.

IMHO is a nice theme although it’s not really free. It costs around 320€, but in some professional projects it could be a really low price if you consider the effort to get a professional look and feel . You can try it in demo page.

Some recommendations about RESTful API design

2012/10/11 No hi ha comentaris

Reading time: 4 – 6 minutes

I want to recommend to you to watch the YouTube video called RESTful API design of Brian Mulloy. In this post I make an small abstract of the most important ideas of the video, of course from my point of view:

Use concrete plural nouns when you are defining resources.
Resource URL has to be focused in access collection of elements and specific element. Example:
- /clients – get all clients
- /clients/23 – get the client with ID 23
Map HTTP methods to maintein elements (CRUD):
- POST – CREATE
- GET – READ
- PUT – UPDATE
- DELETE – DELETE
Workaround, if your REST client doesn’t support HTTP methods, use a parameter called ‘method’ could be a good idea. For example, when you have to use a method HTTP PUT it could be changed by method HTTP GET and the parameter ‘method=put’ in the URL.
Sweep complexity behind the ‘?’. Use URL parameters to filter or put some optional information to your request.
How to manage errors:
- Use HTTP response codes to refer error codes. You can find a list of HTTP response codes in Wikipedia.
- JSON response example can be like this:
```
{ 'message':'problem description', 'more_info':'http://api.domain.tld/errors/12345' }
```
- Workaround, if REST client doesn’t know how to capture HTTP error codes and raise up an error losing the control of the client, you can use HTTP response code 200 and put ‘response_code’ field in JSON response object. It’s a good idea use this feature as optional across URL parameter ‘supress_response_code=true’.
Versioning the API. Use a literal ‘v’ followed by an integer number before the resource reference in the URL. It could be the most simple and powerful solution in this case. Example: /v1/clients/
The selection of what information will be returned in the response can be defined in the URL parameters, like in this example: /clients/23?fields=name,address,city
Pagination of the response. Use the parameters ‘limit’ and ‘offset’, keep simple. Example: ?limit=10&offset=0
Format of the answer, in this case I’m not completely agree with Brian. I prefer to use HTTP header ‘Accept’ than his proposal. Anyway both ideas are:
- Use HTTP header ‘Accept’ with proper format request in the answer, for example, ‘Accept: application/json’ when you want a JSON response.
- or, use extension ‘.json’ in URL request to get the response in JSON format.
Use Javascript format for date and time information, when you are formatting JSON objects.
Sometimes APIs need to share actions. Then we can’t define an action with a noun, in this case use verb. Is common to need actions like: convert, translate, calculate, etc.
Searching, there are two cases:
- Search inside a resource, in this case use parameters to apply filters.
- Search across multiple resource, here is useful to create the resource ‘search’.
Count elements inside a resource, simply add ‘/count’ after the resource. Example: /clients/count
As far as you can use a single base URL for all API resources, something like this: ‘http://api.domain.tld’.
Authentication, simply use OAuth 2.0
To keep your API KISS usually it’s a good idea develop SDK in several languages, where you can put more high level features than in API.
Inside an application each resource has its own API but it’s not a good idea publish it to the world, maybe use a virtual API in a layer above it’s more secure and powerful.

What is AMQP? and the architecture

2012/03/15 1 comentari

Reading time: 3 – 4 minutes

What is AMQP? (Advanced Message Queuing Protocol)

When two applications need to communicate there are a lot of solutions like IPC, if these applications are remote we can use RPC. When two or more applications communicate with each other we can use ESB. And there are many more solutions. But when more than two applications communicate and the systems need to be scalable the problem is a bit more complicated. In fact, when we need to send a call to a remote process or distribute object processing among different servers we start to think about queues.

Typical examples are rendering farms, massive mail sending, publish/subscriptions solutions like news systems. At that time we start to consider a queue-based solution. In my case the first approach to these types of solutions was Gearman; that is a very simple queue system where workers connect to a central service where producers have to call the methods published by workers; the messages are queued and delivered to workers in a simple queue.

Another interesting solution can be use Redis like a queue service using their features like publish/subscribe. Anyway always you can develop your own queue system. Maybe there a lot of solutions like that but when you are interested in develop in standard way and want a long-run solution with scalability and high availability then you need to think in use AMQP-based solutions.

The most simple definition of AMQP is: “message-oriented middleware”. Behind this simple definition there are a lot of features available. Before AMQP there was some message-oriented middlewares, for example, JMS. But AMQP is the standard protocol to keep when you choice a queue-based solution.

AMQP have features like queuing, routing, reliability and security. And most of the implementations of AMQP have a really scalable architectures and high availability solutions.

The architecture

The basic architecture is simple, there are a client applications called producers that create messages and deliver it to a AMQP server also called broker. Inside the broker the messages are routed and filtered until arrive to queues where another applications called consumers are connected and get the messages to be processed.

When we have understood this maybe is the time to deep inside the broker where there are AMQP magic. The broker has three parts:

Exchange: where the producer applications delivers the messages, messages have a routing key and exchange uses it to route messages.
Queues: where messages are stored and then consumers get the messages from queues.
Bindings: makes relations between exchanges and queues.

When exchange have a message uses their routing key and three different exchange methods to choose where the message goes:

Direct Exchange: routing key matches the queue name.
Fanout Exchange: the message is cloned and sent to all queues connected to this exchange.
Topic Exchange: using wildcards the message can be routed to some of connected queues.

This is the internal schema of a broker:

AMQP and RabbitMQ [TOC]

2012/03/09 7 comentaris

Reading time: 1 – 2 minutes

After reading the book ‘RabbitMQ in action‘ I’m working on series of posts that will include the following subjects:

What is AMQP? and the architecure
Deep inside AMQP
RabbitMQ CLI quick reference
Hello World using ‘kombu’ library and python
Parallel programming
Events example
RPC
Clustering fundamentals
Managing RabbitMQ from administration web interface
Managing RabbitMQ from REST API

Please let me know if you are interested in this series of posts. Because in my opinion this is very interesting and it always comes in handy to know if someone has been working on those subjects.

12h amb Arduino

2011/11/09 6 comentaris

Reading time: 6 – 9 minutes

En un calaix tenia guardat un Arduino Duemilenove i una colla de sensors, finalment aquest passat dissabte no vaig poder evitar-ho i vaig haver-m’hi de posar. La temptació va ser massa forta. Així doncs, en aquest post el que vull és explicar-vos com he passat les meves primeres 12h sobre aquesta plataforma d’Open Hardware. Tan de temps treballant amb el concepte Open Source i per primera vegada començo a parlar d’Open Hardware això és una sensació que no té preu.

Arduino Duemilanove

Bé doncs, primer de tot comentar que el llenguatge de programació és molt simple. Tan és així que vaig invertir unes 2h en revisar tots els llibres que tinc d’Arduino en busca de més funcions o usos del mateix que compliquessin una mica la cosa pensant que no podia ser tot tan senzill. Diria que he passat massa temps amb llenguatges d’alt nivell i al tornar al món proper al hardware tot canvia tant que no me’n sabia fer el càrrec. Així doncs, amb ben poques hores ús asseguro que tindreu per la mà totes o quasi totes les instruccions del llenguatge. El que podria semblar més difíci, tot i que sota el meu punt de vista crec que no ho és gens, és fer-se a la idea de que després d’iniciar el sistema tota la lògica estarà tancada en un bucle infinit que esta esperant que els sensors captin algún tipus d’entrada per disparar la lògica. Potser el més interessant és el fet de poder introduir el concepte d’interrupcions per hardware que et permeten secuestrar el fil d’execució en qualsevol moment del codi per llençar una rutina.

Després de fer les típiques proves amb LEDs i pulsadors, vaig posar-me a investigar les entrades i sortides analògiques amb sensors de temperatura, humitat, proximitat, lluminositat i d’altres similars. Coneixer i dominar tot això és qüestió de ben poca estona però crec que val la pena passar-hi per sentir-se còmode amb les eines de programació i el propi hardware. Us recomano intentar retenir tots els pins que té la placa alhora d’entendre el codi és molt més senzill.

arduino

Arribats a aquest punt vaig descobrir que usar la consola serie per mostrar-hi informació de depuració és una de les formes més senzilles de controlar si els programes estan fent el que ens interessa. Així doncs, en aquest punt usava el port serie per volcar-hi tot tipus de comentaris explicatius per tal de seguir el fil del codi a mode de consola de treball. Per tant, us recomano tenir a mà un ‘minicom’ obert constanment per pode recol·lectar tot el feedbak que ens interessi.

On la cosa em va enganxar de veritat és quan vaig començar a posar-me amb els temes d’infra-rojos; concretament a l’hora de decodificar trames enviades per comandaments a distància i d’altres artilugis similars. És realment interessant fer implementacions manuals d’aquest tema usant els rellotges interns que té el dispositiu. T’ajuda a entendre al 100% com funcionen les codificacions dels comandaments a distància per infra-rojos. Després descobreixes que la cosa es pot simplificar moltíssim usant llibreries que t’ho gestionen tot i que t’ofereixen una serie d’interficies de més alt nivell que permeten desenvolupar aplicacions molt senzilles sense haver de preocupar-se dels detalls de les internalitats que comentava abans. Llavors és quan realment pots arribar a fer coses interessants tan a l’hora de rebre com d’enviar informació per infra-rojos.

El pas obvi que venia després d’això era començar a jugar amb protocols de comunicacinos inal·lambrics que per algo tinc vocació telemàtica, no? la veritat és que gràcies a una llibreria d’alt nivell anomenada ‘VirtualWire‘ que parla sobre com usar transmisors i receptors de 433MHz modulats amb ASK per enviar i rebre trames a través de l’aire vaig entendre al 100% com funcionava el sistema de control remot de persianes i calefacció que tinc a casa. De fet, em vaig quedar amb les ganes de seguir jugant amb aquest tema per manca de components electrònics que no tenia a mà. Seguint amb aquesta línia tot i que no vaig fer-ne proves vaig estar veient que és força simple treballar amb busos de dades SPI i I2C. Cosa que obre un món de possibilitats a l’hora de fer interconnexions amb certs aparells.

He de dir que si sou persones que us costa entendre l’electrònica analògica, com a mi, no ús heu de preocupar es poden fer miracles amb Arduino sense tenir ni idea de perquè s’acostuma a posar una resistència davant d’un LED. Això si, arriba un moment que la pròpia motivació per tot el que estas fent et porta a rellegir-te ni que sigui en diagonal els capítols dedicats a l’electrònica que tenen molts dels llibres d’Arduino. Almenys en el meu cas amb uns 30-40min en vaig tenir prou per tornar-me a posar al cap tots els conceptes que havia estudiat en el seu dia i poder seguir endevant amb els meus experiemnts amb més coneixement de causa.

Tot i que pel que vaig fer a continuació no era necessari haver fet el repàs sobre electrònica no vaig poder evitar consultar com es feia per treballar amb els mòduls Ethernet, ZigBee i Wifi que té Arduino. Com que no tenia tot aquest hardware aquesta part només la vaig fer a nivell teòric però la veritat és que ja em va ser molt útil. Em va permetre entendre com es podia treballar amb tot plegat. Això si, ara el ‘gusanillo’ el tinc en la tecnologia ZigBee (IEEE 802.15.4) que mai he tocat de primera mà, així doncs, potser per reis em regalo algún mòdul d’aquesta tecnologia per trastejar-hi una mica, a veure què tal és tot això del ‘mesh-networking’ amb aquest protocol que tants adeptes ha guanyat en el món de l’embedded.

He de dir que de les 12h prop de 4h les vaig passar fullejant i llegint amb deteniment llibres i més llibres que tinc del tema, això em va servir per veure diferents formes de fer les coses i l’abast dels projectes que fa la gent amb l’Arduino cosa que és realment interessant per familiaritzar-se amb la tecnologia. Potser vaig repassar prop de 50 projectes amb aquestes hores i me’n vaig mirar amb lupa uns 10 cosa que em va anar molt bé per coneixer a fons molts temes que per manca de hardware i components electrònics no podia reproduir a casa.

Per cert, si algú s’esperava que aquest article fos un manual de com iniciar-se amb Arduino em sap molt greu però diria que fer això no té cap sentit ja que per internet n’hi ha moltíssims de manuals que expliquen com fer-s’ho per començar. A més, també hi ha moltíssims llibres disponibles a les llibreries i biblioteques a partir dels quals podeu tenir tutorials més que bons i detallats de com començar amb aquest tema. Així doncs, m’ha semblat que era més útil explicar-vos l’experiència de les meves primeres 12h amb aquesta tecnologia.

Autenticació PAM/OTP via PHP

2010/09/16 No hi ha comentaris

Reading time: 2 – 3 minutes

Una bona forma de continuar aprofindint amb el tema OTP i també amb PAM, després de l’article: Shellinabox i OTP, és explicar-vos com m’ho he fet per afegir suport OTP al PHP, de forma que quan programem amb PHP es pugui delegar l’autenticació al sistema PAM del linux. Obviament això té certes restriccions perquè PHP corre amb els permisos de l’usuari de l’Apache, o bé, de l’usuari del FSGI, etc. L’important de fer notar és que no és habitual llençar codi PHP amb permisos de ‘root’. Així doncs, depèn de quina acció li fem fer al PAM aquest no la podrà dur a terme, per exemple, no podrà accedir al fitxer /etc/shadow per validar el password de sistema. De fet, com que el que jo vull és treballar amb OTP això no és rellevant.

El primer que s’ha de fer és instal·lar el paquet php5-auth-apm i reiniciar l’Apache:

apt-get install php5-auth-pam
/etc/init.d/apache2 restart

Ara anem al directori /etc/pam-script.d i fem:

cd /etc/pam-script.d
rm pam_script_acct
# creem fitxer pam_script_acct
echo '#!/bin/sh' > pam_script_acct
echo 'exit 0' >> pam_script_acct
chmod 755 pam_script_acct

Ara toca crear el fitxer /etc/pam.d/php, amb el següent contingut:

auth    sufficient      pam_script.so onerr=fail dir=/etc/pam-script.d/
account  required       pam_script.so onerr=fail dir=/etc/pam-script.d/

Amb això ja en tenim prou per anar a jugar amb el php, el primer és amb un phpinfo(); validar que apareix algo així:

i després podem fer un codi tan senzill com aquest:

<?php
    $result=pam_auth('user','password-otp',&$error);
    var_dump($result);
    var_dump($error);
?>

La comanda clau com podeu veure és pam_auth, passeu com a paràmetre el nom de l’usuari, el password que ús ha donat la vostre aplicació generadora de passwords OTP i la variable que voleu que reculli els errors la passeu per referencia. En cas d’error de l’autenticació aquesta comanda contindrà la descripció de l’error. Aquesta mateixa funció retorna un codi boleà amb el resultat de l’autenticació.

wiki: Notes sobre entorns de programació

2010/08/30 No hi ha comentaris

Reading time: < 1 minute En un .txt tenia unes notes que havia pres sobre entorns de programació, escencialment la conferència de la que són les notes parlava sobre PHP i diferents formens de fer el desplegament dels projectes. Aquesta informació l'he passat a una pàgina del wiki amb la idea d'anar-la actualitzant per altres llenguatges especialment amb la idea de afegir-hi notes de python. Així doncs l'enllaç del wiki és a: Notes about programming environments and deployment. Tal com podeu deduir amb el títol les notes són amb anglès, sento no recordar la conferència per afegir-hi la presentació.

A continuació enganxo el contingut de la wiki de forma dinàmica, així quan actualitzi la wiki s’actualitzarà l’article:

Què és un WebHook?

2010/08/21 No hi ha comentaris

Reading time: < 1 minute WebHook logo
Un WebHook és una HTTP callback, o sigui, un HTTP POST que es dona quan algo passa (un event); o sigui, que podem definir WebHook com a sistema de notificació d’events per HTTP POST.

El valor més important dels WebHooks és la possibilitat de poder rebre events quan aquest passen no a través dels ineficaços mecanismes de polling.

Si voleu més informació sobre aquest tema: WebHooks site.

Jornades #decharlas sobre #symfony

2010/07/08 No hi ha comentaris

Reading time: 4 – 6 minutes

symfony logo

Com deia a l’anterior article, el dilluns i dimarts vaig ser per la zona de Castelló per assistir amb el Benja a les jornades de Symfony organitzades per la Universitat de Jaume I de Castelló. Doncs bé, comentar que les jornades em van sorprendre molt positivament, realment hi havia gent amb força o fins hi tot molt nivell en la materia i això sempre és d’agraïr en aquest tipus d’events.

El programa de les xerrades era molt interessant i tret d’algunes xerrades puntuals totes eren del màxim interés per mi. Com molts esteu cansats de sentir jo no sóc programador, però en aquesta vida he picat força codi i concretament amb Symfony vaig començar-ho a fer en la versió 0.6.4, o sigui, molt abans que fos estable. Però de la mà de l’Oriol M. varem fer un projecte amb uns quants megues de codi font per fer recàrregues de mòbil a una cadena de botigues de fotografia, un dels codis dels que estic més orgullós.

Tornant a les jornades, volia destacar el meu ranking particular de ponents, es tracta d’un petit TOP 3 que des de la meva més extrema modèstia preten classificar en base a uns criteris totalment subjectius les persones que van saber transmetre els valors més importants que jo busco en una xerrada:

Javier Eguíluz (Symfony 2) – a destacar la gran capacitat d’enfocar la conferència cap als items més importants a resaltar, sense oblidar els detalls rellevants en cada moment, tot això sense perdre un fil conductor clar en tota la xarrada. També s’ha de dir que el tema li donava molt de joc per fer embadalir a l’audiència; però va saber com treure-li el suc i tenir-nos a tots ben enganxats malgrat estar molt cansats després de dos dies de conferències sense parar, aquesta va ser l’última conferència.
José Antonio Pío (Vistas y sfForm) – cal deixar-ho clar, una màquina té tota la pinta de ser un programador com la copa d’un pi i els típics defectes i virtuts de ser un professor (ho és?). Malgrat sembla que és molt bo i sap explicar-se la densitat del seu contingut i complexitat del mateix, feien complex seguir-lo tota l’estona ja que exigia molt a la concentració. Cosa gens senzilla en una marató de conferències com el que ens ocupa.
Jordi Llonch (Plugins) – aquest representant de les nostres terres diria que també ha fet una molt bona feina explicant-nos la potència dels plug-ins de Symfony, potser a nivell personal no m’ha aportat tan com les altres dues xerrades però la qualitat de les transparències, l’oratòria i la bona organització dels continguts diria que l’han convertit en una referència de com fer les coses, sota el meu punt de vista, és clar.

Comentar que la resta de ponències també han estat molt bé, obviament algunes amb més qualitat que d’altres i amb temes que per mi tenien un major interés que altres. Però en conjunt dono una nota altíssima al contingut de les xerrades. Pel que fa a la organització i les instal·lacions un 9, més que res per donar-los marge a millorar. Impresionant el complexe universitari, res a envejar a d’altres que he vist.

Abans de tancar aquest article tan poc ortodoxe per descriure les jornades comentar en forma de punts algunes notes mentals que me n’he emportat:

Hauria de posar-me amb Doctrine, però al coneixer Propel mai trobo el moment.
Mirar-me a fons referències sobre integració continua amb PHP i eines de gestió de projectes
Dona gust adonar-se que moltes pràctiques que has adoptat unilateralment també es comparteixen en la comunitat: temes d’sfForm, vistes, pugins, web escalables, cloud computing, etc.
Pel que fa al tema de la web escalable, m’agradaria agafar els ‘slides’ del ponent Asier Marqués i fer el meu propi screencast del tema, comparteixo quasi tot el que va dir a la conferència però em quedo amb les ganes d’aportar-hi el meu granet de sorra.
Mirar-me el tema d’ESI que ja l’havia oblidat.
MongoDB, com dic cada dia… una passada! i si a sobre es soporta a Doctrine això ja no té preu. Interessant el tema de Mondongo.
i l’estrella de tot plegat!!!! Symofny2… estic impacient!!!!

UPDATE: presentacions de les jornades.