Today is the last day of development on the bot. The goal is to add a few commands, progress on the Mixpanel integration, get errors reporting properly, and hopefully have the bot able to request friendship with players. Tomorrow is launch day one way or another 🎱

Using the already available datasource riot.ranked_stats I was able to quickly add the best and worst commands. They essentially just sort and format the existing data set.

Adding the lane flag to the counter command was also really nice. Players some time want to play champions in lanes other than their most popular lane. For instance, Swain is traditionally a mid laner but can be played top. Now, determine how to counter that swain player with counter swain --lane top. Thanks to @amos90 for that request.

One of the more important commands in my opinion is intel. (Note from the future - it wasn't that important. Only ranked players really cared.) It allows a player to look up information about the players in the game they are currently in. Using it they can determine if their laning opponent is familiar with his or her champion as well as look for particularly strong players on either side. It used op.gg as a data source but given more time I could have gotten the data directly from Riot's api.

There was a particularly nasty bug in the system leading to errors just disappearing. The application would fail... silently! The error was in a section of the code that resolved a promise using a callback. It simply wasn't rejecting the promise if the callback itself threw an error. Passing that error through resolved the issue.

In an effort to collect as much data as possible during the launch, I've enhanced the Mixpanel event logs. (Note from the future: I really wish I had been more thorough and uniform here.)

My last goal today was to allow the bot to send a friend request to another player. This would enable the refer <summoner_name> command. Getting the bot to friend the other player was a straight forward process conceptually. Part one was to convert the summoner name into the xmpp user id and just involved making an api request. Part two, to send the XMPP subscribe stanza, was not as easy. Creating the XMPP request body was done with ltx and sent with the using the XMPP client available on the xmpp-adapter which was accessible to me via the robot object. It was fairly straight forward to determine how to send the request using the robot by reading the source code of Hubot. It is really well written, in a language I am familiar with, and a code base I've read through before. The tricky part was determining what the presence object should look like. While I'm not an XMPP expert, I did read a book, XMPP: The Definitive Guide a while back and I knew the basics of how an XMPP request looked. After trying a half dozen variations on what I thought should have been a proper request, I decided to just intercept an incoming friend request and log it out to see what I was doing wrong. Figuring out how to do that involved reading the hubot-xmpp code. Actually doing it required wrapping the existing presence handler so that the functionality would all still work but I'd get my nifty little console log. Doing so revealed the need for a name key holding the summoner name of the initiator. After adding this key, the friend request was finally sending properly. Of course, sending the request (and subsequently having it accepted), isn't the last step for LoLHubot. Once the bot's new friend accepts the request, LoLHubot needs to inform that friend that the bot is in fact online. This is done by sending a presence to the friend. I did this simply by responding subscribe stanzas.

Finally, once the refer command was possible, I added it to LoLHubot as refer <summoner_name.