stealth 1.1.2 → 2.0.0.beta1

data/docs/00-introduction.md

@@ -1,37 +0,0 @@
----
-title: Introduction
----
-Stealth includes everything you need to build amazing chatbots with tools you know and love.
-
-## Assumptions
-
-These docs are designed for intermediate Ruby developers who want to get started with the Stealth framework.
-
-If you do not yet have experience with Ruby, we would recommend checking out these guides first:
-
-- [Official Ruby website](https://www.ruby-lang.org/en/documentation/)
-- [List of Free Programming Books](https://github.com/EbookFoundation/free-programming-books/blob/master/free-programming-books.md#ruby)
-
-## What is Stealth?
-
-Stealth is an open source Ruby framework for conversational voice and text chatbots.
-
-Stealth is inspired by the Model-View-Controller (MVC) pattern. However, instead of calling them *Views* Stealth refers to them as *Replies* to better match the chatbot domain.
-
-- The [Model](#models) layer represents your data model (such as Account, User, Quote, etc.) and encapsulates the business logic that is specific to your bot. By default, Stealth uses [ActiveRecord](#models.active_record).
-
-- The [Controller](#controllers) layer is responsible for handling incoming requests from messaging platforms and providing and transmitting the response (reply).
-
-- The [Reply](#replies) layer is composed of "templates" that are responsible for constructing the respective response.
-
-In addition to being inspired by Model-View-Controller (MVC) pattern, Stealth as a few other awesome things built in for you.
-
-- **Plug and play services.** Every service integration in Stealth is a Ruby gem. One bot can support [multiple chat services](#messaging_integrations) (i.e. Facebook Messenger, SMS, Alexa, and more) and multiple NLP/NLU services.
-
-- **Advanced tooling.** From web servers to continuous integration testing, Stealth is built to take advantage of all the great work done by the web development community.
-
-- **Hosting you know.** Stealth is a Rack application. That means your bots can be [deployed](#deployment) using familiar services like Docker and Heroku.
-
-- **Ready for production.** Stealth already powers bots for large, well-known brands including: Humana, TradeStation, Haven Life, and BarkBox.
-
-- **Open source.** Stealth is MIT licensed to ensure you own your bot. More importantly, we welcome contributors to help make Stealth even better.

data/docs/01-getting-started.md

@@ -1,21 +0,0 @@
----
-title: Getting Started
----
-
-## Ruby
-
-Stealth has been tested on Ruby (MRI) `2.4.x` and `2.5.x`. While we don't require any C-based Ruby gems, we haven't yet certified Stealth on other VMs (such as JRuby).
-
-## Installation
-
-You can install Stealth via RubyGems:
-
-  ```
-  gem install stealth
-  ```
-
-Next, you can create a new Stealth bot:
-
-  ```
-  stealth new <bot_name>
-  ```

data/docs/02-local-development.md

@@ -1,40 +0,0 @@
----
-title: Local Development
----
-
-## Prerequisites
-
-Stealth bundles [Sidekiq](https://github.com/mperham/sidekiq) in order to process background jobs. Therefore, it is required to run Redis in order to boot up a Stealth server.
-
-## Starting the Server
-
-Once you have made your current working directory your Stealth bot, you can install gems:
-
-```
-bundle install
-```
-
-To boot your bot:
-
-```
-stealth server
-```
-
-You can also use `stealth s`. This will use the [foreman](https://github.com/ddollar/foreman) gem to start the web server and Sidekiq processes together. Redis will have to be running for the server to start.
-
-That's it! You are now running Stealth.
-
-## Introspectable Tunnels to localhost
-
-When developing locally, messaging services require access to your server in order to transmit user messages. We recommend downloading and using [ngrok](https://ngrok.com/download) to create a local tunnel to your development machine.
-
-1. Download [ngrok](https://ngrok.com/download)
-2. Start your Stealth server as detailed above.
-3. Open up an ngrok tunnel to your Stealth server and port (default 5000) like this: `ngrok http 5000`. ngrok will output a unique ngrok local tunnel URL to your machine.
-
-When you provide your local ngrok URL to a messaging service, you will have to add `/incoming/<service>`. For example:
-
- * `https://abc1234.ngrok.io/incoming/facebook`
- * `https://abc1234.ngrok.io/incoming/twilio`
-
-More details on service specific settings can be found on the GitHub page for each service gem.

data/docs/03-basics.md

@@ -1,171 +0,0 @@
----
-title: The Basics
----
-
-## Directory Structure
-
-When you open up your Stealth bot you will see the following file structure:
-
-```
-├── Gemfile
-├── Procfile.dev
-├── README.md
-├── Rakefile
-├── bot
-│   ├── controllers
-│   │   ├── bot_controller.rb
-│   │   ├── catch_alls_controller.rb
-│   │   ├── concerns
-│   │   ├── goodbyes_controller.rb
-│   │   └── hellos_controller.rb
-│   ├── helpers
-│   │   └── bot_helper.rb
-│   ├── models
-│   │   ├── bot_record.rb
-│   │   └── concerns
-│   └── replies
-│       ├── catch_alls
-│       │   └── level1.yml
-│       ├── goodbyes
-│       │   └── say_goodbye.yml
-│       └── hellos
-│           └── say_hello.yml
-├── config
-│   ├── boot.rb
-│   ├── database.yml
-│   ├── environment.rb
-│   ├── flow_map.rb
-│   ├── initializers
-│   ├── puma.rb
-│   ├── services.yml
-│   └── sidekiq.yml
-├── config.ru
-└── db
-    └── seeds.rb
-```
-
-## Flows
-
-A `Flow` is a general term to describe a complete interaction between a user and the bot. Flows are comprised of `states`, like a finite state machine.
-
-For example, if a user was using your bot to receive an insurance quote, the flow might be named `quote`. Note: Stealth requires that flows be named in the singular form, like Rails.
-
-A flow consists of the following components:
-
-1. A controller file, named in the plural form. For example, a `quote` flow would have a corresponding `QuotesController`.
-2. Replies. Each flow will have a directory in the `replies` directory in plural form. Again using the `quote` flow example, the directory would named `quotes`.
-3. An entry in `config/flow_map.rb`. The `FlowMap` file is where each flow and it's respective states are defined for your bot.
-
-Flows can be generated using a generator:
-
-```
-  stealth generate flow <NAME>
-```
-
-## FlowMap
-
-The `FlowMap` file is where each flow and it's respective states are defined for your bot. Here is an example `flow_map.rb`:
-
-```ruby
-class FlowMap
-
-  include Stealth::Flow
-
-  flow :hello do
-    state :say_hello
-    state :ask_name
-    state :get_name, fails_to: :ask_name
-    state :say_wow, redirects_to: :say_hello
-    state :say_bye, redirects_to: 'goodbye->say_goodbye'
-  end
-
-  flow :goodbye do
-    state :say_goodbye
-  end
-
-  flow :catch_all do
-    state :level1
-    state :level2
-  end
-
-end
-```
-
-Here we have defined three flows: `hello`, `goodbye`, and `catch_all`. These are the default flows that are generated for you when you create a new bot. We have made a few changes above to highlight some functionality.
-
-Each flow consists of an arbitrary number of states. These states should each have a corresponding controller action by the same name. States also support two additional options: `fails_to` and `redirects_to` which we explain below.
-
-## Default Flows
-
-When you generate a new Stealth bot, it comes packaged with three default flows. While you will likely add many flows of your own, we recommend keeping these three flows as they encourage good bot building practices.
-
-## Hello & Goodbye
-
-These two flows make up the entrance and exit of your bot. We include blank examples on how to greet (say hello) and sendoff (say goodbye) your users. You can customize these flows to work with the design of your bot.
-
-## CatchAll
-
-Stealth also comes packaged with a `catch_all` flow. Stealth CatchAlls are designed to handle scenarios in which the user says something the bot is not expecting or the bot encounters an error.
-
-Error handling is one of the most important parts of building great bots. We recommend that bot designers and developers spend sufficient time building the CatchAll states.
-
-See the Catch All (#catchalls) section for more information on how Stealth handles `catch_all` flows.
-
-## fails_to
-
-The `fails_to` option allows you to specify a state that a user should be redirected to in case of an error. The `CatchAllsController` will still be responsible for determining how to handle the error, but by specifying a `fails_to` state here, the `CatchAllsController` is able to redirect accordingly.
-
-A freshly generated bot will contain sample `CatchAll` code for redirecting a user to a `fails_to` state.
-
-The `fails_to` option takes a state name (string or symbol) or a session key. See [Redis Backed Sessions](#sessions.redis_backed_sessions) (or in the FlowMap example above) for more info about session keys. By specifying a session key, you can fail to a completely different flow from the one where the error occurred.
-
-## redirects_to
-
-The `redirects_to` option allows you specify a state that a user should be redirected to. This is useful if you have deprecated a state where existing users may still have open sessions pointing to the state. When a user returns to your bot, they will be redirected to the flow and state specified by this option.
-
-Like `fails_to` above, the `redirects_to` option takes a state name (string or symbol) or a session key. See [Redis Backed Sessions](#sessions.redis_backed_sessions) (or in the FlowMap example above) for more info about session keys. By specifying a session key, you can fail to a completely different flow from the one where the error occurred.
-
-## Say, Ask, Get
-
-Stealth recommends you use the `say`, `ask`, and `get` prefix for your flow state names. It's not required, but it is a convention we have found helpful to keep state names under control. It also helps other developers on your team follow along more easily.
-
-### SAY
-
-*SAY* Stealth actions are for _saying_ something to the user.
-
-For example:
-
-```ruby
-  def say_hello
-    send_replies
-  end
-```
-
-### ASK
-
-*ASK* Stealth actions are for _asking_ something from the user.
-
-For example:
-
-```ruby
-  def ask_weather
-    send_replies
-    update_session_to state: 'get_weather_reponse'
-  end
-```
-
-### GET
-
-*GET* Stealth actions are for _getting_ and parsing a response from the user.
-
-For example:
-
-```ruby
-  def get_weather_reponse
-    if current_message.message == 'Sunny'
-      step_to state: "say_wear_sunglasses"
-    elsif current_message.message == 'Raining'
-      step_to state: "say_dont_forget_umbrella"
-    end
-  end
-```

data/docs/04-sessions.md

@@ -1,29 +0,0 @@
----
-title: Sessions
----
-
-A user of your bot can be in any single flow and state at any given moment. They can never be in more than one flow or state. For this reason, Stealth sessions are modeled using [finite state machines](https://en.m.wikipedia.org/wiki/Finite-state_machine).
-
-## Finite State Machines
-
-Technically, each flow is its own state machine with its own states. Stealth, however, does not restrict the movement between states as rigidly. So while we find the state machine model helpful to learn sessions, don't spend too much time on Wikipedia!
-
-## Redis Backed Sessions
-
-User sessions are stored in Redis. Each session is a lightweight key-value pair. The key is the user's ID from the service -- so for Facebook it may be a long integer value: `100023838288224423`. The value is the flow and state for the user separated by a "stabby" operator (`->`).
-
-So if for example a user with ID `100023838288224423` is currently at the `hello` flow and `ask_name` state, the value for the key would be: `hello->ask_name`.
-
-You likely won't be interacting with sessions directly since Stealth manages it automatically for you. We just present it here for clarity into how sessions work.
-
-## Session Expiration
-
-By default, Stealth will not expire your user sessions. If you want your sessions to expire, you can set the `session_ttl` option:
-
-```ruby
-Stealth.config.session_ttl = 2_592_000 # seconds (30 * 24 * 60 * 60)
-```
-
-The above configuration setting will result in stale keys expiring in 30 days. Sessions that have been accessed reset the TTL (time to live). If you set a value of zero (the default), session expiration will be disabled.
-
-If a user returns to your bot after their session has expired, they will start again in the `Hello` flow or whatever you have defined to be your first flow.

data/docs/05-controllers.md

@@ -1,179 +0,0 @@
----
-title: Controllers
----
-
-Controllers are responsible for handling incoming requests and getting a response back to the user (replies).
-
-## Naming Conventions
-
-The controller's methods, also referred to as actions, must be named after the flow's states. So for example, given the flow:
-
-```ruby
-flow :onboard do
-  state :say_welcome
-  state :ask_for_phone
-  state :get_phone, fails_to: :ask_for_phone
-end
-```
-
-The corresponding controller would be:
-
-```ruby
-class OnboardsController < BotController
-  def say_welcome
-
-  end
-
-  def ask_for_phone
-
-  end
-
-  def get_phone
-
-  end
-end
-```
-
-## `bot_controller.rb`
-
-Every Stealth project comes with a default `bot_controller.rb`:
-
-```ruby
-class BotController < Stealth::Controller
-
-  before_action :current_user
-
-  def route
-    if current_session.present?
-      step_to session: current_session
-    else
-      step_to flow: 'hello', state: 'say_hello'
-    end
-  end
-
-end
-```
-
-All of your controllers will inherit from `BotController`:
-
-```ruby
-class QuotesController < BotController
-
-end
-```
-
-## Route Method
-
-You can implement any method in `BotController`. Typically you will implement methods like `current_user` and methods for handling message payloads. The one method that `BotController` **must** implement is the `route` method.
-
-The `route` method is called for every incoming message. In its default implementation, the `route` method checks whether the user already has a session, and if so routes them to that controller and action. If the user does not yet have a session, it will route them to the `hello` flow and `say_hello` action.
-
-## Stepping and Updating Sessions
-
-Stealth provides a few built-in methods to help you route a user through your bot.
-
-## `step_to`
-
-The `step_to` method is used to update the session and immediately move the user to the specified flow and/or state. `step_to` can accept a *flow*, a *state*, or both. `step_to` is often used after a `say` action where the next action typically doesn't require user input.
-
-Some examples of the different parameters:
-
-`step_to flow: 'hello'` - Sets the session's flow to `hello` and the state will be set to the *first* state in that flow (as defined by the `flow_map.rb` file). The corresponding controller action in the `HellosController` would also be called.
-
-`step_to state: 'say_hello'` - Sets the session's state to `say_hello` and keeps the flow the same. The `say_hello` controller action would also be called.
-
-`step_to flow: 'hello', state: 'say_hello'` - Sets the session's flow to `hello` and the state to `say_hello`. The `say_hello` controller action of the `HellosController` controller would also be called.
-
-## `update_session_to`
-
-Similar to `step_to`, `update_session_to` is used to update the user's session to a flow and/or state. It accepts the same parameters. However, `update_session_to` does not immediately call the respective controller action. `update_session_to` is typically used after an `ask` action where the next action is waiting for user input. So by asking a user for input, then updating the session, it ensures the response the user sends back can be handled by the `get` action.
-
-Some examples of the different parameters:
-
-`update_session_to flow: 'quote'` - Sets the session's flow to `quote` and the state will be set to the *first* state in that flow (as defined by the `flow_map.rb` file).
-
-`update_session_to state: 'ask_zip_code'` - Sets the session's state to `ask_zip_code` and keeps the flow the same.
-
-`step_to flow: 'quote', state: 'ask_zip_code'` - Sets the session's flow to `quote` and the state to `ask_zip_code`.
-
-## `send_replies`
-
-`send_replies` will instruct the `Reply` to construct the reply and transmit them. Not all of your controller actions will send replies. Typically in `get` action, you'll get a user's response, perform some action, and then send a user to a new state without replying.
-
-The `send_replies` method does not take any parameters:
-
-```ruby
-class ContactsController < BotController
-  def say_contact_us
-    send_replies
-  end
-end
-```
-
-This would render the reply contained in `replies/contacts/say_contact_us.yml`. See [Reply Variants](#variants) for additional naming options.
-
-## `step_to_in`
-
-The `step_to_in` method is similar to `step_to`. The only difference is that instead of calling the respective controller action immediately, it calls it after a specified duration. It can also take a flow, state, or both.
-
-For example:
-
-```ruby
-step_to_in 8.hours, flow: 'hello', state: 'say_hello'
-```
-
-This will set the user's session to the `hello` flow and `say_hello` state in 8 hours after being called. It will then immediately call that responsible controller action.
-
-## `step_to_at`
-
-The `step_to_at` method is similar to `step_to`. The only difference is that instead of calling the respective controller action immediately, it calls it at a specific date and time. It can also take a flow, state, or both.
-
-For example:
-
-```ruby
-step_to_at DateTime.strptime("01/23/23 20:23", "%m/%d/%y %H:%M"), flow: 'hello', state: 'say_hello'
-```
-
-This will set the user's session to the `hello` flow and `say_hello` state on `Jan 23, 2023 @ 20:23`. It will then immediately call that responsible controller action.
-
-## Available Data
-
-Within each controller action, you have access to a few objects containing information about the session and the message the being processed.
-
-### current_session
-
-The user's session is available to you at anytime using `current_session`. This is a `Stealth::Session` object. It has a few notable methods:
-
-`flow_string`: Returns the name of the flow.
-`state_string`: Returns the name of the state.
-`current_session + 2.states`: Returns a new session object 2 states after the current state. If we've passed the last state, the last state is returned.
-`current_session - 2.states`: Returns a new session object 2 states before the current state. If we've passed the first state, the first state is returned.
-
-### current_message
-
-The current message being processed is available to you at anytime using `current_message`. This is a `Stealth::ServiceMessage` object. It has a few notable methods:
-
-`sender_id`: The ID of the user sending the message. This will vary based on the service integration.
-`timestamp`: Ruby `DateTime` object of when the message was transmitted.
-`service`: String indicating the service from where the message originated (i.e., 'facebook').
-`messsage`: String of the message contents.
-`payload`: This will vary by service integration.
-`location`: This will vary by service integration.
-`attachments`: This will vary by service integration.
-`referral`: This will vary by service integration.
-
-### current_service
-
-This will be a string indicating the service from where the message originated (i.e., 'facebook' or 'twilio')
-
-### has_location?
-
-Returns `true` or `false` depending on whether or not the `current_message` contains location data.
-
-### has_attachments?
-
-Returns `true` or `false` depending on whether or not the `current_message` contains attachments.
-
-### current_session_id (previously current_user_id)
-
-A convenience method for accessing the session's ID.