After working at Heuristic Solutions for 2 years, I've decided to take my career in a new direction.

I started at Heuristic Solutions with big plans and big expectations (both from myself and from others). Things did not pan out as well as I hoped, due to a combination of factors, both professional and personal. But, I made the transition from consultant to the LearningBuilder product team, and that's where I've spent most of my time while employed there. It's been an immense and enriching challenge working on a very complex piece of software; perhaps the most complex (in a good way) piece of software I've ever had the honor to work on. Sure, it's not perfect, no code base is, but it has consistently provided a canvas to apply and grow my skills as a developer.

Everyone I've worked with, and especially the Central Ohio-based members of the product team, I highly recommend to anyone seeking out a team that works hard, thinks hard, and cares about what they're building and how they're building it.

So, you might be asking, if it's so great, why are you leaving? Well, I think that will be clear in the next blog post. In the meantime, it just remains for me to thank:

• Seth - for being a great technical leader, and for originally recruiting me to join Heuristics
• Calvin - for pairing with me over the last 2 years, and coding circles around me while doing it (bada bing bada boom)
• Brian - for helping to beat me into shape as a QA lead and playing those bongos congas so well (I hope you get that island in the sun)
• Michael - for hanging out with me and becoming an excellent coder, and automater of everything
• Scott - for always answering the call, pushing the technology limits, and just being there in the consulting trenches at the beginning
• Sara - for being a passionate UX and UI whiz, and for talking Star Wars (I've stlil not met her in person but would like to!)
• Glen - for allowing me to open up on a personal level, and providing much-needed guidance
• Christopher and Ali - for being generous, kind, and fair
• Steve, Tom, Robert, and the rest - for helping me whenever I needed it, and for your hard work accomodating customers and building relationships

A special thanks goes out to:

• Gate 35X
• No Winning
• Kuli Loach
• A closet-sized office

Thanks for reading, and stay tuned for what's next.

RabbitMQ is a "message broker". Your program gives it messages. Other programs can come along and retrieve those messages and then do something with them. It sits in the middle, so it's often referred to as "middleware".

Why would you want a middleman? Haven't a lifetime of mattress commercials shown that cutting out the middleman is always better?

Not always. Let's build an online store that takes orders and has to tell a warehouse to process the order. Consider these three designs:

1. Your website does the work itself.
2. Your website passes a message to another program directly.
3. Your website passes a message to a broker. Another program picks up messages from the broker.

These are the questions I asked, and below are the conclusions I've come to. If I'm missing anything, please add to the discussion in the comments.

#1 Your website does the work itself

A customer places an order. Since your website is doing all the work itself, it has to: email the customer, charge a credit card, and tell the warehouse to ship the item. What if the warehouse doesn't have the item? Now you have to check another warehouse. While your website is doing this, it has fewer resources available to process other customer's browsing and ordering. So it could become a performance problem as well as a complexity problem. Instead...

#2 Your website passes a message to another program directly.

Let's just tell a warehouse program to do the work, and the website will go about its business. The warehouse program can figure out which warehouse, and send the appropriate information. If it has a web service, we can just push the information. But what if something goes wrong? What if the service is down, or busy, or overloaded? Now we need to build in a retrying mechanism into our website, and we're still managing complexity and putting strain on the website. But what if...

#3 Your website passes a message to a broker. Another program picks up messages from the broker.

Our website just records all the information that the warehouse needs to a message. That message goes on the broker and waits. Once the website dumps the message, it's done, and can go about serving other customers. The warehouse program can ask the broker for messages. It gets a message, does the processing. If it goes well, then the broker can forget the message. If something goes wrong, it's up to the warehouse program to figure out what to do. It could keep retrying, send an email, call a web service, or whatever else you need. If the warehouse program gets overloaded, you can spin up another warehouse program that talks to the same broker. If the warehouse programs crash, the messages will wait on the broker.

It might seem that the middleman's job is very simple, it's very important to ensure that complex operations can be broken down and processed smoothly.

I have been accepted as a speaker for CodeMash 2016. I will be presenting "Convention Over Configuration: Queueing is Easy". This session will demonstrate how EasyNetQ (on top of RabbitMQ) makes it easier to deal with queues by using convention over configuration.

I have started preparing material for this session. One of the ways I'm doing this is by creating a series of short videos. The videos will be more in-depth than the ultimate session, but it gives me a chance to practice, prepare, and organize my thoughts. I usually prepare session material this way; I just don't record it on video.

To date, I've created and release two videos. Check out the playlist on YouTube for RabbitMQ/EasyNetQ.

The new year of 2015 will soon be upon us. I am thinking about creating a new developer's group for the Central Ohio area.

Why?

• I live in a part of Central Ohio (Grove City) where there aren't any nearby user groups (that I know of). Most user groups are in Dublin, Easton, or Polaris area, with the occasional group near OSU Campus or Downtown. I'd like to have one closer to those of us in the south/southwest/west area.
• Most user groups focus on a specific technology or technology stack: .NET, Java, cloud, Windows, JavaScript. I'd like to have a group where no topic is off the table: whether it be broad enough to apply to every developer, or narrow enough to introduce us to something outside our comfort zone. For instance, a meeting on 'git' could apply to everyone, but I'd also like to see meetings introducing languages, tools, and/or frameworks.

So what now?

I have a venue, and the above idea.

What I want now is:

• Feedback. Is this a good idea? Why or why not? What's missing?
• People. Will you come to this?
• Schedule. I'm thinking monthly. A weekday, after work hours. Probably 5:30pm or 6pm. Which day would be best? I don't want to be on the same night as one of the other excellent user groups in Central Ohio.
• Speakers and/or topics. We could do fish bowls, labs, traditional speaker sessions, lightning talks, etc.
• Name. Something that conveys the general location & broad selection of topics.

Please feel free to leave comments below, or contact me if you would like to provide more candid feedback.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• SQL Profiler Query Cleaner, a quick and dirty tool born of frustration has its first official pull request! So, I guess at least one person is using the darn thing besides me. It is one of the greatest things to get a useful pull request out of the blue, and thank you to Ruffin.
• Why don't more developers join ACM?
• Pixeling sensitive information may not always be effective.
• A recreation of Microsoft's website from 1994.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.