Featured

Bots Conversational UI Slack Software Development Accoutability

Bots Rising - Part 6

Posted by

Jonathan Fries on September 26th, 2016.

Our internal bot has been running for a while and getting some use.

We've gotten it so that it runs for 7 - 10 days without issue, but after that length of time it seems to quietly lose the connection and we previously weren't checking for that. I'm not sure if that is a feature of Slack itself or the library we're using. In any case, 7 - 10 days seems pretty good and we should probably add some code to recover if something happens.

To get to 7 - 10 days with a Slack bot, the key was to use the Ping/Pong functionality you can see here. It's part way down the page, just look for 'pong'.

We're currently pinging every 10 minutes. This is a lot less than I've seen recommended, but I believe those recommendations were based on building chat clients with the RTM API, not long-running bots with lots of downtime. I don't want to get in trouble with Slack for sending a million ping messages for no reason.

Instead of upping the number of pings we send (which may have helped) we've added some functionality to check as part of our ping/pong functionality to check for the health of the connection. This seems to be the more responsible way to run the health check and reconnect if the connection is offline.

We've tested our reconnect, which works well. Now we just need to wait 7-10 days to see the production failure occur and see if it recovers.

Featured

Software Development Technology Software Accoutability I hate the phrase 'spaghetti code'.

Coding and Accountability

Posted by

Jonathan Fries on September 15th, 2016.

If you are a developer what code are you accountable for?

Is it only your own? Is it your own plus that of a system that you've worked on for some period of time? Is it your team's? Is it every project ever worked on at your company?

I ask this because I've seen a lot of different answers and I will share with you my own approach to this and why that has been my approach.

When I approach a code base I did not create, my first question is to ask, "What can I learn from this code?". This question can and should consume you for some time. You won't know the answer right away, if you think you do, you probably aren't listening closely enough.

Once you know what you should be learning and have begun to learn you can ask how you can make it better. There are always ways to make improvements and to meld your learning with what you already know.

At no point during this process do I use the phrase 'spaghetti code', precisely because it places the source of misunderstandings outside the self onto an inanimate object: 'the code'.

Code is, at one level, a tool to communicate to a machine what you want it to do. It can't be 'spaghetti' if the machine understands it and does what the humans in the room wanted it to do.

On another level, code is a tool to communicate between one developer and another the intent to make a program and what that program was supposed to do. You may choose to blame the previous developer (who completed their assignment), but I don't see how that helps any business situation you happen to be in.

My approach was to be accountable for all code that I touched.

For code written, from scratch by me, I am accountable for all of it, no matter how long ago I wrote it.

As a boss or manager, I don't necessarily expect every person to have that level of accountability, but I expect them to be on a journey that moves in that direction.

And I hate, hate, hate the term 'spaghetti code' (if that wasn't already clear) because it is such a victim phrase. Are you the victim of code? I certainly never wanted to be. I wanted to win and make the code do what it was supposed to do.

Think of the great developers you know. Do they use that phrase? I've never heard one do it.

The 7 Habits of Highly Effective People is very instructive on this point in general. Stephen Covey was not a developer but the lessons are apt to all of us, at all times.

Become proactive. You'll be glad you did.

Featured

Software Development Software TypeScript

Add to the List

Posted by

Jonathan Fries on September 2nd, 2016.

Add to the list a couple of other things that I feel the need to learn for my side project:

Angular 2
TypeScript

But I am having the darndest time with TypeScript. Not so much the syntax or language or ecosystem. Especially for ecosystem, WebStorm has been enormously helpful.

No, with TypeScript I am struggling with debugging and wrestling through problems in the browser. So far my journey could best be described as 7 steps forward and 8 steps back.

By which I mean, there was an initial phase where I thought I knew what I was doing - this was validated by "successes" where I got actual code that I wrote transpiled and working in the browser.

But as I ventured further in - mainly to get the Angular http module working. I have been deconstructing my working code more and more to strip it down to the bare bones and try to understand why a couple of things have gone wrong.

The end result is that I will understand the whole thing better, I suppose. But it is still very frustrating, and I am not yet at the end of my "journey backwards", so to speak.

Also, I'm removing one:

~~Sqllite~~

Simply not worth the time for what I'm doing. And I already understand a lot about databases, if I ever really want to pick that up.

I may someday. I may not.

Featured

Bots Software Development Conversational UI Slack

Bots Rising - Part 5

Posted by

Jonathan Fries on August 27th, 2016.

What do you do with an interrupted conversation?

A user can't really tell what state a conversation is in from looking at the text on the screen.

Does a user understand that this conversation had a specific state and it needs to be revived in that exact place? That isn't really how a conversation works with a human being.

You leave off. You might meet at the coffee pot. Their might be three separate emails.

What you return to doesn't have to be addressed as though it were some procedural checklist. The bot needs to be smart enough to remind the user, to help them pick up where they left off, or just move on if that is what needs to happen.

Featured

Bots Slack Conversational UI Software Development

Bots Rising - Part 4

Posted by

Jonathan Fries on August 18th, 2016.

Here is a link to part 3.

One of the great things about Slack is that it serves as a direct IM tool, a more general discussion tool, and allows for private groups and channels.

When you're building a bot for this type of tool you need to think about where you want your bot listening and how you want it to behave when you are messaging directly vs. in a public channel.

For our first bot we decided that the main focus would be on the direct messaging and we would keep the bot chatter out of the channels (public discussions) and groups (private discussions). But in the event that it appeared that contextually someone should use the bot, we would make a suggestion asking if they wanted to direct message the bot.

We can then invite the bot to channels where we think this would be appropriate, and not invite the bot where we think it would be annoying.

Slack is quite powerful and well thought out in this regard and this type of cross-linking between messages, channels, and users is easy to do.

If you are just getting started with this, it is very helpful to read the Message Formatting Spec for Slack.

Featured

JavaScript Software Development

When is a Hammer not a Hammer?

Posted by

Jonathan Fries on July 10th, 2016.

I am learning a new stack, for a side project:

Node.js
NPM (ooh scary)
Express.js
Webstorm
Handlebars
Sqllite

I will probably use some Angular on the front end, when I get there, but I am not there yet. I technically "know" Angular, since I learned that last summer.

It is very time consuming to learn all these things. But I chose it because I run this site with Ghost and this is what they use, or at least, something close to that. I have no idea if they use Webstorm, I just picked that.

Why did that (the blog) make me want to learn all this tech? Well, I think it was partly that editing a few Handlebars templates to make my theme work in Ghost made me overconfident, and partly that since I plan to host it similarly to this blog I wanted to use something similar.

I forget sometimes how much work it is to learn new technologies. It's hard, especially when you are learning several at once. You always spend a lot more time learning and Googling than you plan to, even when you've used analogous tools before.

And CSS slows me down too. That's another technology that technically I "know", but of course those quotes are there for a reason.

All this got me thinking about proliferation of tools and productivity and so forth. It would be nice to have a hammer we all could learn to use. But of course, sooner or later, you have some type of central planning committee and none of us want that. Over time the marketplace will answer some of these questions and some it won't.

But we do need to ask ourselves, at this point: Is JavaScript becoming a hammer? Has it already happened?

Jonathan's Blog