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:
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.
So what now?
I have a venue, and the above idea.
What I want now is:
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.
If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.
Welcome to the latest installment of the Brief Bio series, where I'm writing up very informal biographies about major figures in the history of computers. Please take a look at the Brief Bio archive, and feel free to leave corrections and omissions in the comments.
A special note about this week's Brief Bio. It is a guest post from my good friend Pete Shearer. Pete runs a tech blog called Pete on Software, and also has a podcast, The Pete on Software Podcast. I have made some minor edits to his post, but otherwise it's completely his own work, and all the credit goes to him.
Pete's official bio: Pete has spent his career as a technologist working on projects large and small for organizations of all sizes. He has a passion for technology and more specifically, for finding the right technology solutions to fit the needs of his clients. Currently, he is trying to do as much in the mobile and cloud space as possible because it's the future and because it's fun!
If YOU would like to do a Brief Bio guest post (or any other guest post), I'm always open to it, and I even have a list of names to suggest for you. It's a great way to learn a little history.
John William Mauchly was born on August 30, 1907 in Cincinnati, Ohio (O-H!). His father, Sebastian, was a high school science teacher. When John was 8 years old, his father received an appointment in Washington, D.C. to become chief physicist at the Carnegie Institute.
Due to the salary that his father's position afforded him, John was able to get a very good education. He put that education to good use and had quite the aptitude in electrical wiring and construction. While he was still in school, he earned money by replacing mechanical doorbells with electrical versions for people. And when his neighbors had household wiring issues, who did they call? That's right, our Johnny boy.
John breezed through high school and ultimately enrolled in Johns Hopkins University in 1925 to study in their Electrical Engineering program. Like all great minds, he was soon bored and at the end of his Sophomore year, he felt like engineering was too boring. Fortunately, Hopkins had the ability for great students to enroll in a Ph.D. program before their undergraduate degree was completed (what?!?) and in 1927, Mauchly became a graduate-level physics student.
Unfortunately, Mauchly's father died on Christmas Eve, 1928. He was able to remain at the university on scholarship, however, and he was awarded his doctorate in 1932. He eventually began teaching physics at Ursinus College near Philadelphia, PA. Ursinus College was a small institution and couldn't afford the kind of laboratory that Mauchly wanted to be able to do his research. During his research, he came across an abundance of worldwide meteorological data. The data was easily obtained, but analyzing it was another problem altogether (later, the UNIVAC would be applied to weather forecasts). Mauchly began to think about better ways to perform the calculations for the analysis, both from his own perspective and research as well as for his students. This naturally led him into calculating machines, beginning with a used Marchant calculator.
In 1936, Mauchly took a job as a temporary assistant physicist and computer at the Carnegie Institute's Department of Terrestrial Magnetism, working for his father's old supervisor. Faithful computer science history buffs will catch the "computer" in his job title and realize that "computer" in this sense just means a person who does long tedious calculations. During this time, he attempted to get an article published, but it was rejected for not analyzing a large enough set of data. This set him off on ways to easily perform greater volumes of computation. His first thought was to outsource, and he attempted to use students as human computers. At the same time, he also sought an automated solution using tabulating machines.
Mauchly's interest in tabulating machines led him to the University of Pennsylvania's Moore School of Electrical Engineering in 1941. The Moore School was working with the U.S. Army to train engineers to work weapons and communication systems for the military due to World War II. Mauchly joined up and studied electrical engineering at the school. During his time there, he met John Presper Eckert, who would become his historically famous collaborator.
The Moore School had a device called the differential analyzer. It was an analog computer that solved differential equations by integration. The U.S. Army had the school use the device to compute artillery shell trajectories. Both Mauchly and Eckert were very involved in the project and it was this project that eventually led them to create ENIAC (Electronic Numerical Integrator and Computer), the first electronic general-purpose computer. ENIAC was Turing-complete, digital, and programmable to solve a wide array of problems.
In 1947, the duo left the Moore school and founded the Eckert and Mauchly Computer Corporation (EMCC), the first computer company. At EMCC, their first product was called BINAC (BINary Automated Computer). At EMCC, Mauchly was responsible for the programming and applications for the production hardware. After meeting with many individuals who were interested in using computers to crush (note from Matthew: I think Pete meant "crunch", but I love the idea of "crushing" numbers, so I left this in) numbers for them, he sought out to make the software that they'd need to do their jobs. Because of this, EMCC began to hire coders.
Mauchly's experience with ENIAC led him to create "Short Code" (more on Short Code available in a paper called "The UNIVAC Short Code"), which was the first programming language actually used on a computer. Konrad Zuse's Plankalkül language was envisioned first, but remained unimplemented for 50 more years. Mauchly put his money where his mouth was about the importance of applications, too. His software mindset led to him hiring Grace Hopper to develop a compiler for the UNIVAC computer.
Unfortunately, like many tech-types who go into business for themselves, they weren't very good with money and ran into financial issues. They eventually sold the company and its patents to Remington Rand in 1950. At Rand, they created UNIVAC (UNIVersal Automatic Computer), most famous for predicting the 1952 presidential election as a landslide for Eisenhower, when human polls all favored Adlai Stevenson. The outcome was so shocking that CBS went on the air downplaying the computer's effectiveness and prediction. Look about 45 seconds into this video for Walter Kronkite introducing the UNIVAC:
After Rand, Mauchly formed his own successful consulting companies, Mauchly Associates and Dynatrend. He retired to Pennsylvania and died on January 8, 1980.
Mauchly's legacy is certain. He was a founding member and president of the Association for Computing Machinery (ACM) and also helped found the Society for Industrial and Applied Mathematics (SIAM), serving as its fourth president. He was a was a life member of the Franklin Institute, a Fellow of the IRE, and a Fellow of the American Statistical Association. He received several honorary degrees as well as the Scott Medal, the Goode Medal, the Howard N. Potts medal, the Pennsylvania Award, the Emanual R. Piore Aware, and many others.
Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.