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'm in the midst of reading Ubik by Phillip K. Dick.
Here is an interesting theme from the book: people pay for a great many things as a service, instead of owning the use of those things outright. Many of the instances in the book are a bit silly for us in 2016 - a coin operated door to an apartment, for instance. But we have the benefit of an additional 45 years of history and science that PKD did not have in 1969, when Ubik was published.
Today there are a lot of things that we pay for in an ongoing way (albeit not with coins) - phones, books, music, computing power, automobiles, genealogy information, etc.
Phillip K. Dick was able to imagine a version of our electronic, service-based, cloud technology world well before any of it existed.
That he got some of the implementation details wrong is hardly surprising, given when he was writing.
A lot of old science fiction gets those sort of details wrong. It can be hard to look past those limitations sometimes - it's easy to focus on coin-operated doors or old special-effects technologies. But if you do, really good sci-fi gets a lot of things right. Heck, sometimes even bad sci-fi gets a few things right.
It's a healthy exercise in ignoring details when the details aren't the thing that matters - what mattered then (as now) was imagination and storytelling. PKD got those things very right a lot of the time.
Also, if you are ever in Ft. Morgan, CO, USA, you can visit Phillip K. Dick's grave. It is located in Riverside Cemetery. The people there are happy to help show you where his grave is located. He is buried with his twin sister who died when she was an infant.
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.
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.
Jonathan Fries on .