aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRafael Mendonça França <rafaelmfranca@gmail.com>2015-07-08 22:31:40 -0300
committerRafael Mendonça França <rafaelmfranca@gmail.com>2015-07-08 22:31:40 -0300
commita187e793d592300910e671fe9270b48d22ca3cb3 (patch)
tree03a08c626ba53d31f69c27dcc4a5269687e3033b
parentac6f118d5ccecc16fa8e40496fea8d2bf84bba76 (diff)
parent108328facbf0842c15fe9e8098c396d9b9d201ed (diff)
downloadrails-a187e793d592300910e671fe9270b48d22ca3cb3.tar.gz
rails-a187e793d592300910e671fe9270b48d22ca3cb3.tar.bz2
rails-a187e793d592300910e671fe9270b48d22ca3cb3.zip
Merge pull request #5 from lsylvester/update-readme-for-getting-started
Update README
-rw-r--r--README.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/README.md b/README.md
index 806f2a8273..fd1e2f8dc5 100644
--- a/README.md
+++ b/README.md
@@ -15,7 +15,7 @@ websockets open to your application if they use multiple browser tabs or devices
The client of a websocket connection is called the consumer.
Each consumer can in turn subscribe to multiple cable channels. Each channel encapsulates
-a logical unit of work, similar to what a controller does in a regular MVC setup. So
+a logical unit of work, similar to what a controller does in a regular MVC setup. So
you may have a `ChatChannel` and a `AppearancesChannel`. The consumer can be subscribed to either
or to both. At the very least, a consumer should be subscribed to one channel.
@@ -26,7 +26,7 @@ could subscribe to multiple chat rooms at the same time. (And remember that a ph
have multiple consumers, one per tab/device open to your connection).
Each channel can then again be streaming zero or more broadcastings. A broadcasting is a
-pubsub link where anything transmitted by the broadcaster is sent directly to the channel
+pubsub link where anything transmitted by the broadcaster is sent directly to the channel
subscribers who are streaming that named broadcasting.
As you can see, this is a fairly deep architectural stack. There's a lot of new terminology
@@ -148,7 +148,7 @@ We then link `App.appearance#appear` to `AppearanceChannel#appear(data)`. This i
channel instance will automatically expose the public methods declared on the class (minus the callbacks), so that these
can be reached as remote procedure calls via `App.appearance#perform`.
-Finally, we expose `App.appearance` to the machinations of the application itself by hooking the `#appear` call into the
+Finally, we expose `App.appearance` to the machinations of the application itself by hooking the `#appear` call into the
Turbolinks `page:change` callback and allowing the user to click a data-behavior link that triggers the `#away` call.
@@ -234,7 +234,7 @@ application. The recommended basic setup is as follows:
```ruby
# cable/config.ru
-require ::File.expand_path('../config/environment', __FILE__)
+require ::File.expand_path('../../config/environment', __FILE__)
Rails.application.eager_load!
require 'action_cable/process/logging'
@@ -245,7 +245,7 @@ run ActionCable.server
Then you start the server using a binstub in bin/cable ala:
```
#!/bin/bash
-bundle exec puma cable/config.ru -p 28080
+bundle exec puma -p 28080 cable/config.ru
```
That'll start a cable server on port 28080. Remember to point your client-side setup against that using something like:
@@ -268,7 +268,7 @@ The Ruby side of things is built on top of [faye-websocket](https://github.com/f
## Deployment
Action Cable is powered by a combination of EventMachine and threads. The
-framework plumbing needed for connection handling is handled in the
+framework plumbing needed for connection handling is handled in the
EventMachine loop, but the actual channel, user-specified, work is handled
in a normal Ruby thread. This means you can use all your regular Rails models
with no problem, as long as you haven't committed any thread-safety sins.