stealth 1.1.2 → 2.0.0.beta1

data/docs/06-models.md

@@ -1,39 +0,0 @@
----
-title: Models
----
-
-Models in Stealth are powered by [ActiveRecord](http://guides.rubyonrails.org/active_record_basics.html). Your bot may not need to persist data, but if it does, ActiveRecord comes built in. We've tried to keep things identical to Ruby on Rails.
-
-## ActiveRecord Models
-
-An ActiveRecord model in Stealth inherits all of the functionality from [ActiveRecord](http://guides.rubyonrails.org/active_record_basics.html). An empty model looks like this in Stealth:
-
-```ruby
-class Quote < BotRecord
-
-end
-```
-
-With the exception of inheriting from `BotRecord` instead of `ApplicationRecord`, everything else matches what is in the [ActiveRecord](http://guides.rubyonrails.org/active_record_basics.html) documentation.
-
-## Configuration
-
-Configuring a database is done via `config/database.yml`. A sample `database.yml` file is included when you generate your bot. It is configured to use SQLite3. For more options please refer to the [Ruby on Rails documentation](http://guides.rubyonrails.org/configuring.html#configuring-a-database).
-
-## Migrations
-
-In order to use your models, you'll need to generate migrations to create your database schema:
-
-```
-stealth g migration create_users
-```
-
-This will create a migration named `CreateUsers`. To migrate your database:
-
-```
-stealth db:migrate
-```
-
-For more information about migrations, seed data, creating databases, or dropping databases please refer to the [Ruby on Rails documentation](http://guides.rubyonrails.org/active_record_migrations.html).
-
-Just remember to prefix your commands with `stealth` rather than `rails`.

data/docs/07-replies.md

@@ -1,114 +0,0 @@
----
-title: Replies
----
-
-Stealth replies can send one or more replies to a user. The supported reply types will depend on the specific messaging service you're using. Each service integration will detail it's supported reply types in it's respective docs.
-
-However, here is a generic reply using text, delays, and suggestions.
-
-```yml
-- reply_type: text
-  text: "Hello. Welcome to our Bot."
-- reply_type: delay
-  duration: 2
-- reply_type: text
-  text: "We're here to help you learn more about something or another."
-- reply_type: delay
-  duration: 2
-- reply_type: text
-  text: 'By using the "Yes" and "No" buttons below, are you interested in do you want to continue?'
-  suggestions:
-    - text: "Yes"
-    - text: "No"
-```
-
-## Reply Variants
-
-By default, Stealth will look for your replies in the folder corresponding to your controller name. So, for example, if you have a `MessagesController`, Stealth will look for replies in `bot/replies/messages`.
-
-If you have an action named `say_hello`, it will look for a reply file named `bot/replies/messages/say_hello.yml.erb` first, and then if that is not found, it will look for `bot/replies/messages/say_hello.yml`. If neither of these files are found, Stealth will raise a `Stealth::Errors::ReplyNotFound`.
-
-In addition to these two naming conventions, Stealth 1.1+ supports Reply Variants. By adding the name of the service to your reply filename, Stealth will reply to users from that service using the designated reply file. That's a mouthful. Let's try an example.
-
-For example, if the bot is replying to a message via an action called `hello`:
-
-Facebook users would receive the reply in `hello.yml+facebook.erb`.
-Twilio SMS users would receive the reply in `hello.yml+twilio.erb`.
-Every other service would receive the reply in `hello.yml.erb`.
-
-This allows you to take advantage of things like Facebook Messenger Cards while still maintaining compatibility for users using SMS.
-
-## Format
-
-Stealth reply templates are written in YAML. Stealth doesn't use advanced YAML features, but we do recommend you familiarize yourself with the syntax. In the above reply example, you should be able to see there are 5 replies included in the reply file.
-
-**Caveat:** YAML interprets "yes", "no", "true", "false", "y", "n", etc (without quotes) as boolean values. So make sure you wrap them in quotes as we did above.
-
-## ERB
-
-Reply templates currently support ERB:
-
-```erb
-- reply_type: text
-  text: "Hello, <%= current_user.first_name %>. Welcome to our Bot."
-- reply_type: delay
-  duration: 2
-- reply_type: text
-  text: "We're here to help you learn more about something or another."
-- reply_type: delay
-  duration: 2
-<% if current_user.valid? %>
-  - reply_type: text
-    text: 'By using the "Yes" and "No" buttons below, are you interested in do you want to continue?'
-    suggestions:
-      - text: "Yes"
-      - text: "No"
-<% end %>
-```
-
-With ERB in your reply templates, you can access controller instance variables and helper methods in your replies.
-
-## Delays
-
-Delays are a common pattern of chatbot design. After a block of text, it's recommended to pause for a bit to give the user a chance to read the message. The duration of the delay depends on the length of the message sent.
-
-Stealth will pause for the duration specified. For service integrations that support it (like Facebook), Stealth will send a typing indicator while it is paused.
-
-### Dynamic Delays
-
-Rather than specifying an explicit delay duration, you can optionally choose to specify a dynamic duration:
-
-```yaml
-- reply_type: delay
-  duration: dynamic
-```
-
-The dynamic delay uses a heuristic to dynamically determine the length of the delay. The previous message sent to the user is examined and depending on it's type and text length (in the case of text replies), an optimal duration is computed.
-
-If you find that the dynamic delays are too fast for your taste, you can slow them down by setting the multiplier value to something between 0 and 1:
-
-```ruby
-Stealth.config.dynamic_delay_muliplier = 0.5
-```
-
-If you find them to be too slow, you can speed them up by setting the multipler to a value greater than 1:
-
-```ruby
-Stealth.config.dynamic_delay_muliplier = 2.5
-```
-
-You can set this option by setting the above value in an intializer file, i.e., `config/dynamic_delay_config.rb`.
-
-## Naming Conventions
-
-Replies are named after a flow's state (which is also the controller's action). So for a given controller:
-
-```ruby
-class QuotesController < BotController
-  def say_price
-
-  end
-end
-```
-
-You would need to place your reply template in `replies/quotes/say_price.yml`. If your template contains ERB, you must add the `.erb` suffix to the template filename: `replies/quotes/say_price.yml.erb`.

data/docs/08-catchalls.md

@@ -1,49 +0,0 @@
----
-title: CatchAll
----
-
-Stealth CatchAlls are designed to handle a very common scenario within chatbots. What happens when the user says something the bot doesn't understand? The majority of bots will simply respond back with a generic "I don't understand" and hope the user to figures out the next step. While this experience might be ok for some bots, we built a more robust way of handling these experiences right into Stealth. The better your CatchAlls, the better your bot.
-
-## Triggering
-
-A CatchAll flow is automatically triggered when a controller action fails to do **at least one** of the following:
-
-1. Update a session (via `step_to`, `update_session_to`, or any other of the step methods)
-2. Send a reply via `send_replies`
-
-In addition to the above two conditions, if your controller action raises an Exception, the CatchAll flow will automatically be triggered.
-
-## Multi-Level
-
-Stealth keeps track of how many times a CatchAll is triggered for a given session. This allows you to build experiences in which the user is provided different responses for subsequent failures. Once a session progresses past a failing state, the CatchAll counter resets.
-
-## Retrying
-
-By default, a Stealth bot comes with the first level CatchAll already defined. Here is the `CatchAllsController` action and associated reply:
-
-```ruby
-def level1
-  send_replies
-
-  if previous_session_specifies_fails_to?
-    step_to flow: previous_session.flow_string, state: previous_state.to_s
-  else
-    step_to session: previous_session - 2.states
-  end
-end
-```
-
-```yml
-- reply_type: text
-  text: Oops. It looks like something went wrong. Let's try that again
-```
-
-In the controller action, we check if the `previous_session` (the one that failed) specified a `fails_to` state. If so, we send the user there. Otherwise, we send the user back 2 states.
-
-Sending a user back two states is a pretty good generic action. Going back 1 state takes us back to the action that failed. Since the actions most likely to fail are `get` actions, or actions that deal with user responses, going back 2 states usually takes us back to the original "question".
-
-## Adding More Levels
-
-If you would like to expand the experience, simply add a `level2` controller action and associated reply (and update the `FlowMap`). You can go as far as you want. CatchAlls have no limit, just make sure you increment using the standardized method names of `level1`, `level2`, `level3`, `level4`, etc.
-
-If a user has encountered the maximum number of CatchAll levels as you have defined, the user's session will remain at the last CatchAll state.

data/docs/09-messaging-integrations.md

@@ -1,80 +0,0 @@
----
-title: Messaging Integrations
----
-
-Stealth is designed for your bot to support one or more messaging integrations. For example, this could be just SMS or both SMS and Facebook Messenger. Messaging integrations can be attached to your Stealth bot by adding the messaging integration gem to your `Gemfile`.
-
-## `Gemfile`
-
-```
-source 'https://rubygems.org'
-
-ruby '2.5.1'
-
-gem 'stealth', '~> 0.10.0'
-
-# Uncomment to enable the Stealth Facebook Driver
-# gem 'stealth-facebook'
-
-# Uncomment to enable the Stealth Twilio SMS Driver
-# gem 'stealth-twilio'
-```
-
-
-## `services.yml`
-
-```yml
-default: &default
-  # ==========================================
-  # ===== Example Facebook Service Setup =====
-  # ==========================================
-  # facebook:
-  #   verify_token: XXXFACEBOOK_VERIFY_TOKENXXX
-  #   page_access_token: XXXFACEBOOK_ACCESS_TOKENXXX
-  #   setup:
-  #     greeting: # Greetings are broken up by locale
-  #       - locale: default
-  #         text: "Welcome to the Stealth bot 🤖"
-  #     persistent_menu:
-  #       - type: payload
-  #         text: Main Menu
-  #         payload: main_menu
-  #       - type: url
-  #         text: Visit our website
-  #         url: https://example.com
-  #       - type: call
-  #         text: Call us
-  #         payload: "+4155330000"
-  #
-  # ===========================================
-  # ======== Example SMS Service Setup ========
-  # ===========================================
-  # twilio:
-  #   account_sid: XXXTWILIO_ACCOUNT_SIDXXX
-  #   auth_token: XXXTWILIO_AUTH_TOKENXXX
-  #   from_phone: +14155330000
-
-production:
-  <<: *default
-development:
-  <<: *default
-test:
-  <<: *default
-
-```
-
-## `stealth setup`
-
-Most messaging integrations require an initial setup. For example, Facebook requires you to send a payload to define the default greeting and persistent menu. You can accomplish this by running the `stealth setup` followed by the integration. For example:
-
-`stealth setup facebook`
-
-Make sure to reference the respective messaging integration documentation for more specifics.
-
-## Officially Supported
-
-* [Facebook Messenger](https://github.com/hellostealth/stealth-facebook)
-* [SMS (Twillio)](https://github.com/hellostealth/stealth-twilio)
-* [Smooch (many platforms, including a web widget)](https://github.com/hellostealth/stealth-smooch)
-
-While we plan to add more integrations in the future, please feel free to add your own and let us know so we can keep this list updated. 😎

data/docs/10-nlp-integrations.md

@@ -1,13 +0,0 @@
----
-title: NLP Integrations
----
-
-Stealth can be extended with NLP/NLU integrations. While these are not needed for the majority of interactions within chatbot, you may find they are helpful for certain types of interactions.
-
-## Officially Supported
-
-Stealth currently supports:
-
-* [AWS Comprehend](https://github.com/hellostealth/stealth-aws-comprehend)
-
-While we plan to add more integrations in the future, please feel free to add your own and let us know so we can keep this list updated. 😎

data/docs/11-analytics.md

@@ -1,13 +0,0 @@
----
-title: Analytics Integrations
----
-
-Stealth can be extended with metric/analytic integrations.
-
-## Officially Supported
-
-Stealth currently supports:
-
-* [Mixpanel](https://github.com/hellostealth/stealth-mixpanel)
-
-While we plan to add more integrations in the future, please feel free to add your own and let us know so we can keep this list updated. 😎

data/docs/12-commands.md

@@ -1,62 +0,0 @@
----
-title: Commands
----
-
-Stealth provides the `stealth` command-line program. It is used to generate new bots, generate flows, start a console, run integration setup tasks, run the server, and more.
-
-To view details for a command at any time use `stealth help`.
-
-```
-Usage:
-
-  stealth [<flags>] <command> [<args> ...]
-
-Flags:
-
-  -h, --help           Output usage information.
-  -C, --chdir="."      Change working directory.
-  -v, --verbose        Enable verbose log output.
-      --format="text"  Output formatter.
-      --version        Show application version.
-
-Commands:  
-stealth console             # Starts a stealth console
-stealth db:create           # Creates the database from DATABASE_URL or config/database.yml for the current STEALTH_ENV
-stealth db:create:all       # Creates all databases from DATABASE_URL or config/database.yml
-stealth db:drop             # Drops the database from DATABASE_URL or config/database.yml for the current STEALTH_ENV
-stealth db:drop:all         # Drops all databases from DATABASE_URL or config/database.yml
-stealth db:environment:set  # Set the environment value for the database
-stealth db:migrate          # Migrate the database
-stealth db:rollback         # Rolls the schema back to the previous version
-stealth db:schema:dump      # Creates a db/schema.rb file that is portable against any DB supported by Active Record
-stealth db:schema:load      # Loads a schema.rb file into the database
-stealth db:seed             # Seeds the database with data from db/seeds.rb
-stealth db:setup            # Creates the database, loads the schema, and initializes with the seed data (use db:reset to also drop the database first)
-stealth db:structure:dump   # Dumps the database structure to db/structure.sql. Specify another file with SCHEMA=db/my_structure.sql
-stealth db:structure:load   # Recreates the databases from the structure.sql file
-stealth db:version          # Retrieves the current schema version number
-stealth generate            # Generates scaffold Stealth files
-stealth help [COMMAND]      # Describe available commands or one specific command
-stealth new                 # Creates a new Stealth bot
-stealth server              # Starts a stealth server
-stealth sessions:clear      # Clears all sessions in development
-stealth setup               # Runs setup tasks for a specified service
-stealth version             # Prints stealth version
-
-Examples:
-
-  Start a new Stealth project.
-  $ stealth new [BOT NAME]
-
-  Generate a new flow inside your Stealth project.
-  $ stealth generate flow [FLOW NAME]
-
-  Run setup tasks for a specific driver.
-  $ stealth setup [INTEGRATION NAME]
-
-  Start a Stealth console.
-  $ stealth c
-
-  Start the Stealth server.
-  $ stealth s
-```

data/docs/13-deployment.md

@@ -1,50 +0,0 @@
----
-title: Deployment
----
-
-Stealth is a rack based application. That means it can be hosted on most platforms as well as taking advantage of existing tools such as Docker.
-
-## Deploying on Heroku
-
-Stealth supports [Heroku](http://herokuapp.com) out of the box. In fact, running a `stealth s` command locally boots `foreman` using a `Procfile.dev` file similar to what Heroku does. Here is a quick guide to get you started.
-
-If you haven't, make sure to track your bot in Git
-
-  ```
-  $ git init
-  Initialized empty Git repository in .git/
-  $ git add .
-  $ git commit -m "My first commit"
-  Created initial commit 5df2d09: My first commit
-   42 files changed, 470 insertions(+)
-    create mode 100644 Gemfile
-    create mode 100644 Gemfile.lock
-    create mode 100644 Procfile
-  ...
-  ```
-
-After you have your bot tracked with Git, you're ready to deploy to Heroku. Next, we'll add our bot to Heroku using:
-
-```
-$ heroku apps:create <BOT NAME>
-```
-
-You will want a production `Procfile` separate from your development `Procfile.dev`. We recommend adding:
-
-```
-web: bundle exec puma -C config/puma.rb
-sidekiq: bundle exec sidekiq -C config/sidekiq.yml -q webhooks -q default -r ./config/boot.rb
-release: bundle exec rake db:migrate
-```
-
-Then deploy your bot to Heroku.
-
-```
-$ git push heroku master
-```
-
-Once deployed:
-
-1. Make sure to enable both the `Heroku Postgres` (if you use a database) and `Heroku Redis` addons
-2. Make sure the `web` and `sidekiq` dynos are spun up
-3. Make sure you run any `stealth setup` commands to configure your messaging service