Farewell to the devLink Technical Conference

   After spending the past nine years working with several amazing people to build the devLink Technical Conference, I have made the decision to retire the event.  Over the years, we have seen the event grow from approximately 287 attendees in 2006 to regular attendance of 800+ individuals from across the United States and beyond.  I have had the opportunity to share experiences that I will never forget and participate in life changes (good/bad) of everyone on the team as well as some attendees.  In the end, it really boils down to focus and what’s next for everyone on the team as we move forward in our lives.  Personally, I will take this opportunity to refocus and invest my efforts more fully toward my faith, my family as well as make some determinations on the next steps for my career.
    This may disappoint a few people, but my hope is with devLink coming to an end, it allows for other events to be highlighted and hopefully spurs others to take that step toward impacting the community in their own way.  Some events that immediately come to mind are CodeStock, KC/DC, Code PaLousa, CoderFaire, Heartland Developers Conference and CodeMash, but there are many more.  If you don’t have one in your area, by all means go for it! Reach out to others in the community to build something, you just have to ask.
    Several questions have come up about letting someone else take over the conference and move it forward.  While we were proactive to incorporate others into the team for just this scenario, running an event of this size is a big commitment, not everyone has the ability to make that kind of sacrifice.  Other options were explored, but it became apparent that it is better for the event to come to end than to try and make it work another way.  If people remember devLink as something great that ended too soon, that is better than remembering when devLink was great.
    My hope is that the conference made an impact on the community and those who had a chance to attend.  I would like to recognize a few of the people who gave of themselves to help make this happen.  Whether in the beginning or year after year these people made significant contributions to the success of the devLink Technical Conference: Leanna Baker, John Baker, Jason Clark, Randy Walker, Tommy Norman, Amy Walters, Rebel Bailey, Keith Elder, Alan Stevens and most of all my wife and children who gave not only of themselves but also allowed me the freedom to pursue my passion.  While it is hard to give up something you have poured yourself into for so long, it is the right time.  I loved being part of it and will miss not only the event, but all the familiar faces.  Thanks for supporting the conference over the years!

RabbitMQ Configuration via Rake Task

I recently wrapped a Ruby on Rails project in which we were leveraging RabbitMQ as the message broker.   We wanted a quick and easy solution to manage the configuration of the exchanges and queues for deployment.  Since the developers on the team had the occasional need to leverage RabbitMQ locally it made sense to combine those solutions into a rake task.The task leverages the RabbitMQ command line interface (CLI) which gives you the ability to accomplish most anything.  The problem is that most of the team were not well versed in RabbitMQ and didn’t need to be, so to make it simple I first created a ‘rake rabbit:setup‘ task that would pull down the CLI script and place it in the proper path for execution of the remaining tasks.  This only needed to be executed once and they were good to go.
To start, I wanted to make the configurations quite simple and familiar to the team so the rabbitmq.yml file was born.  The rabbitmq.yml file allows for configuration of exchanges, queues and bindings between them.  As you will see in the example gist below, you specify the user and password for RabbitMQ.  Exchanges can define all available types, identify an alternate exchange and whether the exchange is internal or not.  Queues allow for simple definition of just the name to including the expiration time and dead letter settings.  Bindings tell an exchange and queue about one another and their relationship.  You can also add a host configuration entry and modify the base command in the rake task if you are interested in configuring a remote RabbitMQ server.
To configure the system with the CLI is pretty straightforward, you can simply export the rabbit configuration to a JSON file using the ‘rabbitmqadmin export rabbit.config‘ command, make your changes and import the configuration file using ‘rabbitmqadmin import rabbit.config‘.  The problem is that if you change an existing exchange or queue those changes are ignored.  To work around that problem, I added that ability to delete exchanges and queues so that a fresh configuration would allow for all configurations to be the latest and greatest. You are probably thinking, what about existing messages, if you delete a queue with messages in it you are going to lose data, what kind of solution is that?  Well, relax if you call the delete queues or delete all, which deletes queues and exchanges, it will only remove those queues that are empty and warn you that some queues have messages.  So you can then act on those queues with messages and repeat the delete action to ensure all is well.  If you are not worried about existing messages and data loss you can easily delete the queues containing messages by running ‘rake rabbit:delete:queues_by_force‘.
In the long run, I am confident that the task can be improved upon, but it is a great starting point to incorporating a configuration based management of RabbitMQ.