Tickybot — Chingus little helper

Fred Hawk
Chingu
Published in
6 min readNov 26, 2017

--

Another Voyage and another project in the works. This project was very different from anything I’ve been apart of before in many ways. A few new technologies, a different workflow and a new challenge.

I’ve done a couple of Voyages now but my teammates had never done one before. My team had done a bit of front end things before but never worked with a slack bot before so I suggested it could be a good challenge for us to branch out and see how development works outside of the client side. Said and done.

We had a few suggestions on what to make but settled on a Ticketbot which means handling help requests with the use of a slackbot.

This idea came from one of our members after noticing that handling of problems in the voyage was administrated through an excel sheet. We all agreed that it wasn’t optimal. So we started thinking of how to improve upon it with regards to using a slack bot.

Vampiires Autobot which we used during the Voyage was an excellent example of a bot. It gave as great inspiration of what could be done with interactive messages as user interface.

Workflow

We were all familiar with git and GitHub tho not experts at it. It has this feature now called Projects which is similar to Trello which I’ve used before for project management. Since we were already using GitHub for git hosting and issue tracking it seemed like the logical choice to use Projects for task management.

We have a Kanban flow board. If you are unfamiliar with it you can learn more about in the video below.

Learn about Kanban flow

What we do is for anything we want done, a feature, a bugfix, a topic of discussion like architecture or something to refactor we create an issue in our GitHub repository. Then we take that and assign labels to it based on the preexisting ones, we also assign it to the project.

Add issue to project

When you add it to the project it then shows up under the projects.

Unassigned issue

It will then show up in your project so you can assign it to your backlog first and then work on it from there according to the Kanban flow.

This together with Francesco Agnoletto’s brilliant git guides has served us very well for the project. If you follow his guides you can’t go wrong.

The technologies

We are obviously using slack since we are making a slackbot. We also use NodeJs with ExpressJS as backend and a Firebase as datastore.
For the front end we use slack and for the distribution front end we use ReactJS.

All of us were familiar with NodeJS, ExpressJS and ReactJS. A couple had used Firebase before including me to a lesser extent. I wanted to try it for this project mostly to learn more about Firebase and get a deeper understanding of it. We are using Jest as a testing framework as we are dipping our feet into the whole process of learning testing.
We deploy the whole thing to Heroku which hosts it for us.

Bumps in the road

Along the way there were a couple of choices we had made that caused us some trouble. First one was Firebase. It turns out it can not handle compound queries on its own. A compound query is for example when you ask the database for all tickets which are older than 5 days and have the status solved. It could only query for one parameter per request.

To solve this we had a few options. One is a npm package called Querybase. Could not get that to play well with our setup. Likely my fault for misunderstanding something.

Another solution is to use Firebase next generation of the real time database which is called Firestore, it has compound queries. But it is still in early beta and we decided to not chance on an unproven technology.

The solution we chose since our queries aren’t very deep or complex was to write compound parameters to the database for the queries to use. This means a string of both parameters with a separator like an underscore. Like age_status: “10_open”. Tho we use timestamp instead of 10.

We didn’t need many of these, just a few and it has worked very well for us in the end.

Another problem was when someone created tickets rapidly, like when multiple people would create tickets at around the same time they would all get the same ticket number.

This is now handled by queuing in the server.

We also had issues on our first deployment which caused us to reset about 30 commits of our master branch. Was a headache but lessons learned, won’t do that again.

These are just a couple of the roadblocks we have had.

How it works

There is a help command displaying all the accessible commands

Help

You can open tickets by using /ticket open I have problem with X.

Open ticket

You can show the tickets that you have open or have solved.

Show open and solved tickets

Admins can solve tickets that users can then either unsolve (reopen) or close if the problem is solved.

Solved by admin
Unsolved (reopened) by a user
User closes a solved ticket

Happy non ending

Right now the project is ready for some beta testing which we hope to do in a coming Voyage. Our hope is that this could make it easier for the admins of the Voyages to help the users. Right now administration is done inside slack but an idea we have is to also make a site to administrate everything from too that syncs with the database and slack but that is an idea at the moment.

I for one have learned a lot from this project, it has been one of the first projects I have been able to understand other peoples code. I attribute that to my teammates being awesome at writing understandable code. I will continue to use GitHub Projects cause it has been a great tool for this kind of work.

There have been ups and downs for us like in any project. But nothing beats the great feelings we had when the bot worked for the first time. Or when we saw Zsoltis design for the front end the first time. It was a jaw dropping moment for me. It is incredibly well done and I did not expect the attention to detail that he put into it. He had not mentioned him being a designer but I would very much consider him one.

I feel like we have accomplished what we set out to do in the project. There are more to do — there always is. But for now I am very happy with what we have done.

I would like to thank my team ThinkTwice13 and Zsolti. It has been a pleasure working with you. Anyone who gets to have these guys on their team will be lucky. I would also like to thank Chance Taken and the Chingu community. This whole Chingu project is incredibly fun!

I hope to see you all in another Voyage!

Get Tickybot

Check out the code on GitHub

--

--