Get started with RabbitMQ, a message broker, that enables multiple processes to communicate reliably through an intermediary
- Fork this starter repo into your GitHub.
- Clone your repo down to your machine.
- In VS Code with Python extension, click on emit_message_v1.py to get VS Code in Python mode.
- View / Command Palette - then Python: Select Interpreter
- Select your conda environment. See the references below for more.
- Use the terminal to install pika into your active environment.
conda install -c conda-forge pika
- Read the RabbitMQ Tutorial - Hello, World!
- Read the code and comments in this repo.
- Run about.py.
- Read about.txt.
- Verfiy you have exactly one active, one None env.
- Read v1_emit_message.py (and the tutorial)
- Run the file.
You'll need to fix an error in the program to get it to run.
+ Looks like the error was due to an extra letter in 'localhost'
Once it runs and finishes, we can reuse the terminal.
- Read v1_listen_for_messages.py (and the tutorial)
- Run the file.
You'll need to fix an error in the program to get it to run. Once it runs successfully, will it terminate on its own? How do you know?
+ The process just waits to receive messages, so it will not terminate unless we force it to.
As long as the process is running, we cannot use this terminal for other commands.
- Open a new terminal window.
- Use this new window to emit more messages
- In v1_emit_message.py, modify the message.
- Execute the script.
- Watch what happens in the listening window.
- Do this several times to emit at least 3 different messages.
- Did you notice you had to change the message in two places?
- You update the actual message sent.
- You also update what is displayed to the user.
- Fix this by introducting a variable to hold the message.
- Use your variable when sending.
- Use the variable again when displaying to the user.
+ Used a variable called 'messagetext'
To send a new message, you'll only make one change. Updating and improving code is called 'refactoring'. Use your skills to keep coding enjoyable.
Now look at the second version of each file. These include more graceful error handling, and a consistent, reusable approach to building code.
Each of the version 2 programs include an error as well.
- Find the error and fix it.
+ localhostttt was used instead of localhost
- Compare the structure of the version 2 files.
+ Version 2 files both use the 'if name == "main"' idiom.
+ They also both define reusable functions with arguments.
+ The receiver, which is more prone to errors, has a couple exception handlers.
- Modify the docstrings on all your files.
- Include your name and the date.
- Imports always go at the top, just after the file docstring.
- Imports should be one per line - why?
+ When errors arise, it tells you what line it is in. If all the imports
+ on the same line, it will be harder to know which one caused the error.
- Then, define your functions.
- Functions are reuable logic blocks.
- Everything the function needs comes in through the arguments.
- A function may - or may not - return a value.
- When we open a connection, we should close the connection.
- Which of the 4 files will always close() the connection?
+ v1_emit_message is the only one that will always close() connection.
+ The receivers both go indefinitely, while v2_emit_message only opens and
+ closes connection when the send_message function is called.
- Search GitHub for if name == "main":
- How many hits did you get?
+ 26Million code results and 1900 discussions
- Learn and understand this common Python idiom.
+ If I wanted to import this into another python script, I could call its
+ functions without executing the lines of code under that if statement.
+ Essentially, it allows the script to be executed both on its own and as a module