Getting started with chat bots using Talkify

Chat bots have always seemed so complex. They process natural language from text so it must be hard right? After all, how can you make sense of loose words into computer instructions and then back? It must be hard.

Well, it is hard. Kinda. A lot has already been solved around natural language processing so the amount you have to do to get started has reduced by significant amount. Tools are already there, you just have to use them.

I used those tools and still found it to be difficult. I wanted to make the process of building chat bots as easy as getting started with web development. So, I built Talkify.

Takify is an Open Source framework for building chat bots. It is written in node.js and here’s how you can build your very own chat bot in a couple of minutes.

We’ll be building a chat bot that I like to call “sidekick”. This is a simple bot that tells you knock knock and chuck norris jokes.Continue reading →

Why are my ExpectJS spies blocking calls?

While I love writing tests in JavaScript, it is sometimes incredibly painful to debug through the asynchronous test code. Today, a weirdness with ExpectJS happened. I had the following test code:

Simple right? Nope. Some how my callback was not being called which was preventing the test from finishing which in turn caused a test failure. I spent good amount of time debugging step by step and finally found the issue.

My fake contextStore was not being called. Hmm. How can this happen? I’ve defined functions that do respond asynchronously and have set spies on them as well. If anything, my spies should tell me that the function has been called!

Nothing could be further away from the truth! Well, you see, spies work differently in Java than in JavaScript. While using Mockito with Java, I’ve found that Spies never block the calls on the object that they are spying on unless explicitly told to. However, this behaviour different in JavaScript. ExpectJS blocks the calls to spies unless told otherwise!

At the end, solution was simple. I changed lines 11 and 12 to:

Boom! And it worked!

AWS cloud formation describe* permission error

So you know sometimes, its difficult to work with AWS cloud formation scripts. On surface, errors are seemingly random and unrelated to the script. This is what happened today. I wrote an awesome parameterised cloud formation script. I was quite proud of it, mainly because most of my parameters were typed. This mean that the parameters like, ec2_security_groups had a type of List<AWS::EC2::SecurityGroup::Id>. This not only makes it easier to work with that cloud formation script from the AWS console, but also makes it very easy to work with from a CI/CD pipeline as if those parameters are invalid, the script will fail instantly, instead of waiting for resources to deploy.

However, while doing this, I completely missed the fact that in order for cloud formation to validate your input parameters, it needs to look them up first. What IAM policy permission does a resource lookup need? describe!

For once, my IAM role had tightly restricted permissions and because of this I had to go on to expand them slightly to allow for describe permissions.

I kept getting this error about the role not having the describe permission and I kept wondering why it needed that. Well now you know too!

Introduction to Docker

Deploying applications is a complex task. You have to create some VMs, be it on DigitalOcean or AWS, download and install necessary prerequesites and then deploy your application. It would be easy if it were to end there, however, it doesn’t.

Following this you have application maintenance which includes deploying updated versions of your application in addition to other things like bug fixes. And this is where the real complexity starts. Your updated version might need another dependent application to be installed which in turn might need a version of some random tool to be upgraded. You did what was necessary but then you find out that the deployment of the updated application failed because you forgot to do that one null check in some corner of your application. So frantically you download the previous version of your application and try to restore it only to find that it doesn’t work anymore since you upgraded that random tool to support your newer application.

While all this is happening either your entire application is unavailable because your application is single instance or if it is indeed multi-instance split by a loadbalancer, all the other instances are being stressed out because one of the node is down.

And now you are thinking. Well, there has to be a better way.

Well my friend, there is.

Continue reading →

Deploying single instance WordPress site on CoreOS

Lets start off by deploying a single MySQL DB instance. For this, we’re going to use the default mysql image from docker hub. In order to deploy anything to CoreOS, you need to first create a service file. Here’s one for the MySQL that we’re going to deploy.

Save that file as wpdb.service. Lets examine that file. As you can see, the file is split into three distinct sections. Unit, Service and X-Fleet. The Unit section tells CoreOS, or more specifically fleet, what this service is about and what it is for. Since this one is quite simple, we only have a Description here.Continue reading →

%d bloggers like this: