Midgaard Bot post corrections

diff --git a/posts/20171227-midgaard_bot.html b/posts/20171227-midgaard_bot.html
index 116dcb06098bd38a3b1ee23eb7d79c9db1b68bf3..65aa2d60026f334289b366e913148529f160aba4 100644 (file)
--- a/posts/20171227-midgaard_bot.html
+++ b/posts/20171227-midgaard_bot.html
@@ -2,7 +2,7 @@ title: Midgaard Bot, conneting to a MUD with Telegram
 date: 2017-12-27 11:51
 ---
 <div>
-  <p>A colleague of mine, Vlad Nicu, is developing a Telegram bot to offer information about cryptocurrencies (price, etc). After talking with him, I had the idea of writing a bot to connect to a MUD (Multi User Dungeon) using Telegram. When I was young, I spent a long time playing with this type of online games and I thought it'd be fun to develop something similar.</p>
+  <p>A colleague of mine, Vlad Nicu, is developing a Telegram bot to offer information about cryptocurrencies (price, etc). After talking with him, I had the idea of writing a bot to connect to a MUD (Multi User Dungeon) using Telegram. When I was young, I spent a lot of time playing with this type of online games and I thought it'd be fun to develop something similar.</p>
 
   <p>I decided to use Golang to practice a little with this language and its goroutines. I think it has a lot of things that could be improved, but, undoubtedly, concurrency is its strongest feature. From my point of view, sometimes people abuse of channels and goroutines. I have seen a lot of examples of problems that could be resolved only with function calls, without all the goroutines system.</p>
 
@@ -16,7 +16,7 @@ date: 2017-12-27 11:51
 
   <p>When the message is complete, we send it to a specific goroutine that receives messages from open sessions and forwards them to Telegram.</p>
 
-  <p>During the development, a funny thing happened to me, and that makes me think about how goroutines really work. The goroutine in charge of an open session wrote a message to a channel and, after that, it got suspended. The problem was taht I didn't develop the code to read that channel yet, and Go channels block the execution.</p>
+  <p>During the development, a funny thing happened to me, and that makes me think about how goroutines really work. The goroutine in charge of an open session wrote a message to a channel and, after that, it got suspended. The problem was that I didn't develop the code to read that channel yet, and Go channels block the execution.</p>
 
   <p>I thought Go channels run in a similar way than messages work in Erlang. In Erlang, a process send messages asynchronously, and the execution continues independently. But in Golang is different, channels aren't pipes, are meeting points for goroutines. If you put a message in a channel, you are blocked until another goroutine reads that channel and releases the goroutine that has written that message.</p>