Encara dintre d’aquest núvol que m’envolta des de fa setmanes i que no em deixa tocar de peus a terra avui és un altre dia molt especial en la meva vida, avui compleixo 35 anys. No és cap número màgic com els 18 o els 30. Però avui realment sento que tot el que m’envolta és màgic; la família, els amics i el més màgic de tot és la connexió que sento amb el meu interior. Tinc la sensació d’estar en pau en mi mateix i això ús asseguro que és el millor regal que he experimentat mai. La veritat és que ara mateix no puc demanar res a la vida, així doncs només puc seguir donant i compartint tot allò de que disposo. Aprendre que la felicitat és un estat que s’ha de saber disfrutar durant el caminar cap a l’objectiu que manté l’il·lusió i que sostenta la passió amb la que s’afronten les accions diaries. Tot plegat fa que continui afrontant els dies amb un fantàstic somriure als llavis.

Avui es compleixen 9 anys del meu accident que em podria haver costat la vida, sempre m’agrada escriure un article recordant el moment i mostrant una foto de com va quedar el cotxe.

Aquest any el fet és més emotiu que mai ja que després del punt d’inflexió que va suposar per mi aquest segona oportunitat me n’adono que he canviat molt les meves preferencies vitals i això em fa sentir molt bé. De fet, amb l’última re-organització del blog es pot veure que a més del meu interés per la tecnologia es diferencia clarament un apartat dedicat al creixement personal i un altre per tractar temes personals, com aquest mateix article.

Però no només el blog és un gran exemple del meu canvi interior, el passat 29 d’abril vaig contraure matrimoni amb l’Estefania una persona que m’ha ajudat a tenir un punt de vista molt diferent a la vida; on els aspectes més competitius de la nostre societat han obert un espai a altres parts més emocionals que m’ajuden a mantenir l’equilibri en el meu dia a dia. Quan després de tots aquests anys de treball personal arribes en un punt d’equilibri entre la part mental, emocional, espiritual i física tot plegat té un efecte revitalitzant que t’ajuda a afrontar el dia a dia amb un somriure als llavis.

L’última prova me l’ha posat la vida aquest darrer dia 1, dia en el que un dels meus servidors personals m’ha donat un ensurt que paliar els efectes em costarà encara moltes setmanes de feina i esforç, tan energètic com econòmic. Però el difícil, o l’interessant, és saber afrontar aquesta situació professional sense que m’afecti el moment tan dolç que estic vivint en la meva vida personal. Dit d’altre forma, el interessant és aconseguir que aquest contra-temps tècnic no tingui efectes sobre el viatge de noces que comença aquest proper dijous. Això és el que em fa estar més content de la meva evolució d’aquests 9 anys.

No penseu pas que estic dient que he arribat al final del meu camí, al contrari, he descobert que l’èxit no el trobaré al final del camí sinó disfrutant del dia a dia pel fet de poder viure el camí que he escollit. Per no allargar-me massa acabaré l’article amb una cita:

La vida és un joc, no et prenguis res seriosament.

Hoy he disfrutado de este video de TED; es la primera vez que referencio este servicio pero seguro que no será la última.

Quiero recomendaros este video porqué hace una reflexión sobre cómo nos hace percibir nuestro interior y exterior los dos emisferios del cerebro. Creo que son 20min de iluminación que no puedo dejar de recomendaros.

Deseo que os guste y os llene tanto como lo ha hecho conmigo.

In the next few lines I’ll describe with more detail the properties and features of AMQP elements. It won’t be an exhaustive description but in my opinion more than enough to start playing with AMQP queues.

Channels

When producers and consumers connect to the broker using a TCP socket, after authenticating the connection they establish a channel where AMQP commands are sent. The channel is a virtual path inside a TCP connection. This is very useful because there can be multiple channels inside the TCP connection where each channel is identified using an unique ID.

An interesting parameter of a channel is confirmation mode. If this is set to “true”, the producer will receive an acknowledgment message with an UID when a message is delivered to an exchange and is put into a queue. This type of messages is asynchronous and permits a producer to send the next message when it is still waiting for the ACK message. Of course if the message cannot be stored and it is lost the producer receives a NACK (not acknowledged) message.

Producers

Maybe this is the most simple part of the system. Producers only need to negotiate the authentication across a TCP connection, create a channel and then publish all messages with their corresponding routing key. Of course, producers can create exchanges, queues and then bind them. But usually this is not a good idea. It is much more secure do this from consumers. Because when producers try to send a message to a broker and don’t have the required exchange then the message will be lost. Usually consumers are connected all the time and subscribed to queues. Producers only connect to brokers when they need to send messages.

Consumers

When a consumer connects to a queue, it usually uses a command called basic.consume to subscribe the channel to a queue.Then, every time the subscribed queue has a new message, it is sent to the consumer after the last message is consumed, or rejected.

If the consumer only wants to receive one message without a subscription, it can use the command basic.get.This works like a poll method. In fact, the consumer only gets a message each time it sends the command.

You can get the best throughput using the basic.consume command because it’s more efficient than poll every time the consumer wants another message.

When more than one consumer is connected to a queue, messages are distributed in a round-robin. After the message is delivered to a consumer it sends an acknowledgement message and then the queue sends another message to the next consumer. If the consumer sends a reject message the same message is sent to the next consumer.

There are two types of acknowledgements:

• basic.ack: this is the message that the consumer sends to the queue to acknowledge the receipt of a message
• auto_ack: this is a parameter we can set when the consumer subscribes to a queue. The setting assumes an ACK message from consumer and then queue sends next message without waiting for the ACK message.

The message basic.reject is sent when the consumer wants to reject a received message. This message discards the message and it is lost. If we want to requeue the message we can set the parameterrequeue=true when sent a reject message.

When the queue is created there can be a parameter called dead letter set to true, then consumer rejects a message with the parameter requeue=false the message is queued to a new queue called  dead letter. This is very useful because after all we can go tho that queue an inspect the message rejection reason.

Queues

Both consumers and producers can create a queue using queue.declare command. The most natural way is create queues from consumers and then bind it to an exchange. The consumers needs a free channel to create a queue, if a channel is subscribed to a queue, the channel is busy and cannot create new queues. When a queue is created usually we use a name to identify the queue, if the name is not specified it’s randomly generated. This is useful when create temporary and anonymous queues for RPC-over-AMQP.

Parameters we can set when create a new queue:

• exclusive – this setting makes a queue private and is only accessible from your application. Only one consumer can connect to a queue.
• auto-delete – when last consumer unsubscribes from queue the queue is removed.
• passive - when create a queue that exists the server returns successfully or returns fail if parameters don’t match. If passive parameter is set and we create a queue that exists always returns success but if the queue doesn’t exist it is not created.
• durable – the queue can persist when the services reboots.

Exchange and binding

In the first post of the serie we talked about different exchange types as you can remember these types are: direct, fanout and topic. And the most important parameter to set when producer sends a message is the routing key this is used to route the message to a queue.

Once we have declared an exchange this can be related with a queue using a binding command: queue_bind. The relation between them is made using the routing key or a pattern based in routing key. When exchange has type fanout the routing key or patterns are not needed.

Some pattern examples can be: log.*, message.* and #.

The most important exchange parameters are:

• type: direct, fanout and topic.
• durable: makes an exchange persistent to reboots.

Broker and virtual hosts

A broker is a container where exhanges, bindings and queues are created. Usually we can define more than one virtual brokers in the same server. Virtual brokers are also called virtual hosts. The users, permissions and something else related to a Broker cannot be used from another one. This is very useful because we can create multiple brokers in the same physical server like multi-domain web server and when some of this virtual hosts is too big it can be migrated to another physical server and it can be clustered if it is required.

Messages

An AMQP message is a binary without a fixed size and format. Each application can set it’s own messages. The AMQP broker only will add small headers to be routed among different queues as fast as possible.

Messages are not persistent inside a broker unless the producer sets the parameter persistent=true. In the other way the messages needs to be stored in durable exchanges and durable queues to persist in the broker when it is restarted. Of course when the messages are persistent these must be wrote to disk and the throughput will fall down. Then maybe sometimes create persistent messages is not a good idea.

Este mes de enero leí el libro “El mejor año de tu vida” de Mónica Fusté. Un libro que ya estube recomendando a través de twitter. Después de leer el libro y a modo de notas personales hice un mapa mental que hoy me he decidido a traducir al castellano y a compartir con todos vosotros.

Añadir que este mapa mental no sustituye para nada la lectura del libro. Pero si que después de leerlo a mi me ha sido muy útil tenerlo a mano para recordar conceptos fundamentales del viaje interior que estoy haciendo.

He dedicat gairebé tot el dia a acabar el nou format del blog. És possible que hi acabi afegint algo. Però ara per ara la idea que porto al cap la dono per tancada. És a dir, que la re-estructuració en la forma d’accedir i visualitzar els continguts queda totalment separada en les tres seccions que ja he estat comentat.

Ara només entrar al blog com podeu veure en el menú principal es pot escollir de forma senzilla el poder veure tots els contiguts, només els de tecnologia, creixement personal o els personals. Així quan algú entri amb una idea concreta desitjo que li sigui més senzill trobar el que busca.

Finalment a la part superior podeu trobar els menús que hi havia abans a la barra principal.

Apa doncs, a disfrutar-ho.

What is AMQP? (Advanced Message Queuing Protocol)

When two applications need to communicate with each other there a lot of solutions like IPC, if these applications are remote we can use RPC. If an application needs to communicate with more than one other application we can use ESB. And there are many more solutions. But when more than two applications need to communicate with each other and the system(s) need(s) to be scalable the problem is a bit more complicated. In fact, when we need to make 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 this kind of solutions was Gearman; that is a very simple queue system where workers connects 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 its features like publish/subscribe. Anyway you can always develop your own queue system. Maybe there a lot of solutions like that but when you are interested in developing as standard way and want a long-term solution with scalability and high availability then you need to think about using 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 were some message-oriented middlewares, for example, JMS. But AMQP is the standard protocol to keep when you choose a queue-based solution.

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

The architecture

The basic architecture is simple, there are client applications called producers that create messages and deliver them to a AMQP server also called broker. Inside the broker the messages are routed and filtered until they get to queues where other applications called consumers are connected and process the messages.

When we have understood this maybe it’s time to further explore the broker where AMQP’s magic happens. The broker has three parts:

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

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

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

This is the internal schema of a broker:

Really useful command of ssh package to add public key of your user account to a remote SSH server and then access there with passwordless authentication method.

In the past I wrote a simple cookbook to explain this process but now this is as simple as possible. Don't forget ssh-copy-id is the most easy way to add your ssh public key in remote servers.

After reading the book ‘RabbitMQ in action‘ I’m working in a post serie that will has these posts:

1. What is AMQP? and the architecure
2. Deep inside AMQP
3. RabbitMQ CLI quick reference
4. Hello World using ‘kombu’ library and python
5. Parallel programming
6. Events example
7. RPC
8. Clustering fundamentals
9. Managing RabbitMQ from administration web interface
10. 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 so allways is useful to know if someone has been working in this issues.

Configure spamassassin is never easy to do. But when you look for information in Google usually you will be mad . The most common help method in linux is use 'man command' but it doesn't work or information is not enough usually.

After a lucky search I found this command to get an extended information about how to configure spamassassin.conf file.

perldoc Mail::SpamAssassin::Conf