-
Notifications
You must be signed in to change notification settings - Fork 43
Add Ruby Getting Started guide #2669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good! Spotted a couple of things running through it though.
Should we add a mention early on (perhaps in the prerequisites?) regarding usage of EventMachine?
80b250a
to
161cb67
Compare
5890c0a
to
c13038b
Compare
bundle install | ||
``` | ||
|
||
The realtime interface of the Ruby SDK must be run within an "EventMachine":https://github.com/eventmachine/eventmachine reactor which provides an asynchronous evented framework for the library. All functionality within this guide runs within an EventMachine.run block. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The realtime interface of the Ruby SDK must be run within an "EventMachine":https://github.com/eventmachine/eventmachine reactor which provides an asynchronous evented framework for the library. All functionality within this guide runs within an EventMachine.run block. | |
The realtime interface of the Ruby SDK must be run within an "EventMachine":https://github.com/eventmachine/eventmachine reactor which provides an asynchronous evented framework for the library. All functionality within this guide runs within an @EventMachine.run@ block. |
(don't know if there's a way to make it do syntax highlighting?)
end | ||
|
||
|
||
realtime_client.connection.once(:connected) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not very clear to me what's going on here — why do we have two different :connected
handlers?
To publish a message in your code, you can add the following line to your @get_started@ method after subscribing to the channel: | ||
|
||
```[ruby] | ||
channel.publish 'example', 'A message sent from my first client!' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it's clear to the user why there are two arguments here, especially given that the CLI publish
call above only took one argument?
channel.presence.enter("I'm here!") | ||
``` | ||
|
||
* In the "dev console":https://ably.com/accounts/any/apps/any/console of your first app, attach to @my-first-channel@. Enter a @client_id@, such as @my-dev-console@, and then join the presence set of the channel. You'll see that @my-first-client@ is already present in the channel. In your terminal you'll see that an event was received when the dev console client joined the channel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I've missed something, but is there a reason that we use both the dev console and the CLI as the "other" Ably client within the same guide? Wouldn't one tool suffice?
|
||
You can retrieve previously sent messages using the history feature. Ably stores all messages for 2 minutes by default in the event a client experiences network connectivity issues. This can be extended for longer if required. | ||
|
||
If more than 2 minutes has passed since you published a regular message (excluding the presence events), then you can publish some more before trying out history. You can use the Pub/Sub SDK, Ably CLI or the dev console to do this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If more than 2 minutes has passed since you published a regular message (excluding the presence events), then you can publish some more before trying out history. You can use the Pub/Sub SDK, Ably CLI or the dev console to do this. | |
If more than 2 minutes has passed since you published a regular message (excluding the presence events), then publish some more before trying out history. You can use the Pub/Sub SDK, Ably CLI or the dev console to do this. |
"you can" makes it sound optional, which it's not — they won't see anything in history!
|
||
```[ruby] | ||
# Close the connection after 10 seconds | ||
Thread.new do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it would be better to use EventMachine.add_timer 10 do …
instead of mixing concurrency idioms?
Description
Checklist