typo

majek · majek · commit 65aa89812d0c · 2010-10-07T14:39:35.000+01:00
diff --git a/python/tutorial-one.mdx b/python/tutorial-one.mdx
@@ -98,7 +98,7 @@ RabbitMQ uses a weird jargon, but it's simple once you'll get it. For example:
    }
    {% enddot %}
 
- * _Consuming_ has a simmilar meaning to receiving. _Consumer_ is a program
+ * _Consuming_ has a similar meaning to receiving. _Consumer_ is a program
    that mostly waits to receive messages. On our drawings it's shown with "C":
 
     {% dot -Gsize="10,0.3" -Grankdir=LR %}
@@ -257,7 +257,7 @@ run the command as many times you like, and only one will be created.
 You may ask why to declare the queue again - we have already declared it
 in our previous code. We could have avoided that if we were sure
 that the queue already exists. For example if `send.py` program was
-runned before. But we're not yet sure which
+run before. But we're not yet sure which
 program to run as first. In such case it's a good practice to repeat
 declaring the queue in both programs.
 
diff --git a/python/tutorial-three.mdx b/python/tutorial-three.mdx
@@ -32,9 +32,9 @@ messages and second will receive and print them.
 In our logging system every running copy of the receiver program
 will be able to get the same messages. That way we'll be able to run one
 receiver and direct the logs to disk, in the same time we'll be able to run
-another reciver and see the same logs on the screen.
+another receiver and see the same logs on the screen.
 
-Essentially, emited log messages are going to be broadcasted to all
+Essentially, emitted log messages are going to be broadcasted to all
 the receivers.
 
 
@@ -119,9 +119,9 @@ queues it knows. And that's exactly what we need for our logger.
 > because we were using a default `""` _empty string_ (nameless) exchange.
 > Remember how publishing worked:
 >
->     chnnel.basic_publish(exchange='',
->                          routing_key='test',
->                          body=message)
+>     channel.basic_publish(exchange='',
+>                           routing_key='test',
+>                           body=message)
 >
 > The _empty string_ exchange is special: message is
 > routed to the queue with name specified by `routing_key`.
diff --git a/python/tutorial-two.mdx b/python/tutorial-two.mdx
@@ -144,7 +144,7 @@ it.
 If consumer dies without sending ack, Rabbit will understand that a
 message wasn't processed fully and will redispatch it to another
 consumer. That way you can be sure that no message is lost, even if
-the workers occasionaly die.
+the workers occasionally die.
 
 There aren't any message timeouts, Rabbit will redispatch the
 message only when the worker connection dies. It's fine if processing
@@ -339,7 +339,7 @@ And our worker:
 
 
 Using message acknowledgments and `prefetch_count` you may set up
-quite a decent work queue. The durabiltiy options let the tasks
+quite a decent work queue. The durability options let the tasks
 to survive even if Rabbit is restarted.
 
 Now we can move on to [part 3]({{ python_three_url }}) and learn how to
