This month I had the chance to travel to Dublin to speak about RabbitMQ at an event organized by the .Net, Ruby & Python communities from Ireland. The experience was really great both from a touristic point of view and from the conferences itself. I also had the chance to attend to Jakub Stastny aka @botanicus talk about AMQP libraries for the Ruby world. In my case I presented about messaging patterns that can be implemented with RabbitMQ. As an extra bonus the RabbitMQ guys delivered free t-shirts that we raffled between the attendants. Big thanks to the organizers for the invitation to Ireland. Sadly I can't get Guinness everyday here in ZĂŒrich :).One common use case of RabbitMQ is to use it as a background task processing system: you enqueue jobs there that are meant to be picked up by long running workers, perhaps written in PHP. Now with time comes the realization that RabbitMQ can do more than being a simple queue server, you start to realize the power of using a Messaging System to send events across your machines, for example notifying the system health status to your remotely connected browser console. Suddenly you start to get more and more process talking to each other via RabbitMQ. In the same sense you learn OOP Design Patters to properly organize your objects in your applications you need to learn Messaging Patterns to better take advantage of a system like RabbitMQ. In the talk I gave in Dublin I've explained some of those patters to the audience.For example you might want to send one notification to the system telling that your web server is down. You want to have a receiver of those messages that sends an email to the sysadmins so they are alerted of the problem. Later management asks you to also send a SMS to the sysadmins just in case their aren't in front of the computer when the failure happens. Finally since it's a bad experience for users to try to access an irresponsive web site you write a final message receiver that fires up a tiny server that delivers a static HTML page to tell clients that your system is down and that you are working on fixing the problem. Now, how do we implement this with messaging and RabbitMQ? We can use the publish subscribe pattern which in RabbitMQ parlance translates to publishing messages to a fanout exchange and then binding several queues on the other end. Each queue will have workers for specific tasks: one to send emails, the other to send SMS and the last one to switch to a static website. If in the future you need to do other things with the message then you can add more queues with their respective workers. On the notification publisher side you don't need to modify a single line of code.There are many more patterns like the previous one that can help us easily find a solution to problems that might arise with this kind of distributed programming. If you want to learn more about them I always recommend the book Enterprise Integration Patterns: eaipatterns.com. The patterns I discuss in my slides can be seen here: slideshare.net/old_sound/messaging-patterns.Coming back to the topic of conferences this week I traveled to Basel to speak at the Webilea event. The event was very well organized, full of food and beers which is Goodâą. This time since the attendants were a mix of business people, entrepreneurs and developers I try to give a lightweight talk to explain why you may need RabbitMQ and what kind of advantages it might bring to your company. After the talks some people went for beers and we the nerds stayed for a short live coding session on RabbitMQ. I've demoed live how to create basic consumers and publishers. How RabbitMQ persisted messages, transient queues and more. Thanks to the Webilea guys for such great event.And finally thanks to Liip for allowing me to participate in all these conferences.