profile
viewpoint
Matthew O'Riordan mattheworiordan Ably Real-time London https://www.ably.io CEO & technical co-founder of @ably, a realtime data delivery platform

mattheworiordan/capybara-screenshot 962

Automatically save screen shots when a Capybara scenario fails

bigjason/jpbuilder 26

A small template extension to add JSONP support to Jbuilder.

mattheworiordan/fluent-plugin-color-stripper 9

Fluentd plugin to strip ANSI color codes from input logs

mattheworiordan/Full-stack-testing 9

This repository was used in the journey I took to find the best solution for building Rails sites with full stack integration i.e. unit and integration testing with both back end and front end code. Frameworks that I used include Ruby, Rails 3, RSpec 2.5, Cucumber, Capybara

mattheworiordan/beeswithmachineguns 8

A utility for arming (creating) many bees (EC2 instances) to attack (load test) targets (web socket applications) using the load testing client daemon at https://bitbucket.org/mattheworiordan/websocket-test

mattheworiordan/Appcelerator-Titanium-Redux 6

Reduces the amount of code you need to write when using Appcelerator Titanium. Adds support for JSS, localization, global includes, default properties, and more.

mattheworiordan/google-drive-dropbox-onedrive-performance-measured 5

Measuring the latency of cloud drive solutions - because it matters when you're collaborating

mattheworiordan/capybara-screenshot-test-rails-3.1 3

Capybara-screenshot gem test app for Rails 3.1

mattheworiordan/alfred-remember-the-milk-plugin 2

Remember the Milk plugin for Alfred

mattheworiordan/geokit-gem 2

Official Geokit Gem. Geokit gem provides geocoding and distance/heading calculations. Pair with the geokit-rails plugin for full-fledged location-based app functionality.

push eventmattheworiordan/dotfiles-1

Matthew O'Riordan

commit sha cb17afa407acefd5548ea37bac8b4e2375e84a1a

Simplify the theme now that iTerm2 has a status bar with git status etc.

view details

Matthew O'Riordan

commit sha 37ef71071e367aaad6b378789731407618b27569

General tidy up and cleaning up of version managers

view details

Matthew O'Riordan

commit sha 1ffe307128429732834590808c85e436dfd7c03e

Updated gemrc config

view details

Matthew O'Riordan

commit sha e67a7d235704408273005bb51ad9c28dabb583d1

Realtime env vars to run services locallu

view details

Matthew O'Riordan

commit sha ee01b4ce304b0076d1c56e01c3bea92488683081

Use asdf as a universal version manager for all langs

view details

Matthew O'Riordan

commit sha 7e03f13a37323f8dc69cdb572dee4caee8ae4264

Ubuntu 20 TMUX shell fixes

view details

push time in 3 days

issue openedably/docs

Consistent about Ably section for all public Ably repos

We have lots of public repos, from client SDKs (https://github.com/ably/ably-js) to docs (https://github.com/ably/docs) to load testing (https://github.com/ably/ably-boomer) to demos (https://github.com/ably/whiteboard).

We should review generic about Ably messaging that exists in all public repos that gives users context, explains what Ably does, etc.

created time in 6 days

push eventably/ably-roku

Matthew O'Riordan

commit sha 44d5d2208141d294bf6398275e1618964b6ec8a3

Fix typos

view details

push time in 6 days

push eventably/ably-roku

Matthew O'Riordan

commit sha a65f1ef30d91b803ce35b9fb202c7771baa37dba

Clearly indicate this is a PoC

view details

push time in 6 days

issue openedably/docs

Message ordering from history article / documentation

See a recent discussion with a customer on message history ordering. Looking at our docs, and support solution articles, it appears we do not have documentation that sufficiently describes the behaviour of history in respect to ordering. We should create a support article for now, and later consider adding documentation for this.


Question:

Is there any guarantee that messages received from the history API will be in order? It appears that one of our clients is getting messages from the history that are out of order according to their timestamps.

Our response:

It depends what you mean by 'in order'. There is the order that the messages will have been received by a realtime client. But that will vary depending on what region the client is in. We preserve ordering for a given publisher on a given channel, but for example if two publishers in regions A and B publish messages 'a' and 'b' (respectively) approximately simultaneously, it's quite like that a subscriber in region A will see 'a' before 'b', and one in region B will see 'b' before 'a'. The ordering that history results are returned in is the ordering defined by the message timestamp which is assigned by the channel in the region that the message was published in. This means that history results - unlike realtime messages - are in the same order no matter where in the world you query them from. But that order (which we call the canonical global order) may not be the same order as any client in any region actually received them in real time if they were subscribed to the channel.

there are exceptions to that. One is recent messages (retrieved from live ephemeral storage rather than persisted); they will be in regional ordering, and then will mesh back into canonical global ordering from persisted storage (with a mechanism that prevents duplication & missing messages) when you paginate further back

another exception is untilAttach, which is a point in a regional message stream, so results returned from an untilAttach query do not satisfy this

That would explain it then, because we’re using untilAttach

And this appears to be an issue when the client region is really far away from the publishing region, as well.

so when using untilAttach the messages will be in the regional order of the region the client is in, because they have to mesh forwards into the live message stream at that point. You may well ask why we can't send them in CGO order and filter, and the answer is we plan to do that eventually, but that's pending on completely moving away from serially-incrementing channelSerials to a channelTimeserial to mark the point of attachment

created time in 14 days

issue openedably/ably-ruby

JTW test failing when using JWT with auth_url and credentials are wrong disconnected includes and invalid signature message

See https://travis-ci.org/github/ably/ably-ruby/jobs/724120006#L6345-L6544

created time in 17 days

issue openedably/open-specs

Spec needs updating to 1.2

We are version 1.2, yet this spec is version 1.1.

In addition, when imported into Stoplight, https://ably.stoplight.io/docs/rest-api/swagger.yml, there are currently 48 warnings:

screenshot_2020-09-06_11-19-57_am

created time in 18 days

pull request commentably/ably-go

Always include serial values in encoded protocol messages

Nice spot, perhaps would have been nice to have a test to prevent a regression in future though, given how hard this was to find.

lmars

comment created time in 18 days

PullRequestReviewEvent

issue commentably/docs

publish method on the Realtime (and REST) client object

See https://app.intercom.com/a/apps/ua39m1ld/inbox/inbox/all/conversations/38483300001169, this customer is still relying on a callback to manage memory leaks with the channel object. See below.

screenshot_2020-09-01_07-27-52_am

mattheworiordan

comment created time in 23 days

PullRequestReviewEvent

pull request commentably/docs

Revert "[WEB-381] Add GA tracking to docs.ably.io"

I do not understand why you are proposing to create a separate PR to add docs.ably.io tracking instead of just switching out GTM-TZ37KKW now with a new GA code? That would require less work (fewer reviews, one small change) and give you visibility into the dosc site usage at the same time.

MarkWoulfeAbly

comment created time in a month

issue commentably/ably-ruby

Feature request: support for batch requests

Hey @rgraff

We have no plans at present to add convenience methods just yet as we introduced the request method specifically to give us flexibility to add new API methods without having to roll out new SDKs each time.

Here is a Ruby equivalent if that helps:

ably = Ably::Rest.new(key: 'OBFUSCATED_KEY')
content = { "channels": [ "test1", "test2" ], "messages": { "data": "myData" } }
response = ably.request('post', '/messages', nil, content, nil)
response.success? #=> true
response #=> <Ably::Models::HttpPaginatedResponse:70093508156320
  # @base_url="/",
  # @last?=true,
  # @has_next?=false,
  # @items=
  #    {"channel"=>"test1", "messageId"=>"M2H1MbMxfB:0"},
  #    {"channel"=>"test2", "messageId"=>"1idybVV_5e:0"}
  #>

content = { "channels": [ "test1", "test2" ], "messages": { "data": "myData", "extras": { "push": "not-allowed" } } }
response = ably.request('post', '/messages', nil, content, nil)
response.success? #=> false
response.error_code #=> 40020
response.error_message #=> "Batched response includes errors (status: 400, code: 40020) (code: 40020, http status: 400) -> see https://help.ably.io/error/40020 for help"

Out of interest, can you tell me a bit about what you're using batch publishing for? We may very well consider adding this to the spec down the line, so knowing why people need this helps.

rgraff

comment created time in a month

issue commentably/ably-ruby

Feature request: support for batch requests

Hey @rgraff

We have no plans at present to add convenience methods just yet as we introduced the request method specifically to give us flexibility to add new API methods without having to roll out new SDKs each time.

Here is a Ruby equivalent if that helps:

ably = Ably::Rest.new(key: 'dFMjJg.lt-i5g:1a_LuqzpDfkpiAM2', environment: 'dev')
content = { "channels": [ "test1", "test2" ], "messages": { "data": "myData" } }
response = ably.request('post', '/messages', nil, content, nil)
response.success? #=> true
response #=> <Ably::Models::HttpPaginatedResponse:70093508156320
  # @base_url="/",
  # @last?=true,
  # @has_next?=false,
  # @items=
  #    {"channel"=>"test1", "messageId"=>"M2H1MbMxfB:0"},
  #    {"channel"=>"test2", "messageId"=>"1idybVV_5e:0"}
  #>

content = { "channels": [ "test1", "test2" ], "messages": { "data": "myData", "extras": { "push": "not-allowed" } } }
response = ably.request('post', '/messages', nil, content, nil)
response.success? #=> false
response.error_code #=> 40020
response.error_message #=> "Batched response includes errors (status: 400, code: 40020) (code: 40020, http status: 400) -> see https://help.ably.io/error/40020 for help"

Out of interest, can you tell me a bit about what you're using batch publishing for? We may very well consider adding this to the spec down the line, so knowing why people need this helps.

rgraff

comment created time in a month

issue openedably/ably-js

We should not mutate arguments passed to functions

See https://github.com/ably/ably-js/blob/52f560f7d587f103a29e3d411b42045926a69ab7/common/lib/client/realtimechannel.js#L715

It appears that we're mutating the params object by deleting the untilAttach attribute. We should arguably never do this and have side effects from arguments passed in.

created time in a month

issue openedably/docs

Alternative protocols QoS guarantees

Non-Ably protocols have varying degrees of reduced QoS attributes in comparison to Ably. We do broadly communicate this to our users, but we should be far more explicit about what this means exactly.

For example, which protocols support ordering, idempotency, client-side fault-tolerance (fallback hosts) etc.

created time in a month

issue commentably/docs

Support article for "private" channels / revisit docs

do we currently offer the ability to create 'private channels'?

No, we don't offer "private" channels as such because every channel is both public and private, and access to channels is controlled via Ably's authentication, see https://www.ably.io/documentation/core-features/authentication#capabilities-explained.

Also, see the conversation with the customer at https://app.intercom.com/a/apps/ua39m1ld/inbox/inbox/search?assigneeIdentifier=all&q=Hey%20there%2C%20was%20wondering%20about%20having%20%22private%22%20channels

mattheworiordan

comment created time in a month

Pull request review commentably/ably-flutter

Realtime message subscription

 import 'enums.dart'; import 'rest/channels.dart';  class Message {-  Message.fromEncoded(Map jsonObject, ChannelOptions channelOptions);-  Message.fromEncodedArray(List<Map> jsonArray, ChannelOptions channelOptions);++  /// A unique ID for this message+  String id;++  /// The timestamp for this message+  DateTime timestamp;++  /// The id of the publisher of this message   String clientId;++  /// The connection id of the publisher of this message   String connectionId;-  dynamic data;++  /// Any transformation applied to the data for this message   String encoding;-  dynamic extras;-  String id;++  /// The message payload+  dynamic data;

Personally I think we should go with what's easiest to implement now and avoid introducing new "special" types that deviate significantly from other SDKs.

tiholic

comment created time in a month

push eventably/docs

Matthew O'Riordan

commit sha 2f2890d905c5dacb599ebbcb50a64af68129a639

Streaming HTTP docs typo

view details

push time in 2 months

issue openedably/docs

GA tracking for docs.ably.io should not reuse the existing www.ably.io GA property

See https://github.com/ably/docs/pull/905

This change introduced GA tracking (well technically it added all GTM tracking), but this site is not part of www.ably.io, and as such, is messing up the reported URLs.

docs.ably.io should have its own GA property to avoid this.

screenshot_2020-08-03_10-56-06_am

created time in 2 months

pull request commentably/docs

Updated reactor events to address issues #864, #865 and #919

In future, can I ask that you please include a description of what a PR does in the description field? See https://ably.atlassian.net/wiki/spaces/ENG/pages/312377505/Git-PR-best-practice

MarkWoulfeAbly

comment created time in 2 months

pull request commentably/docs

Add redirect support

I am not too comfortable with this PR for a few reasons:

  • The PR does not explain why this is being done, only what it does. Every PR needs a description with the why.

  • It won't work AFAICT, this is served up as a static site. See the buildpacks used (documented in README)

$ heroku buildpacks
=== ably-docs Buildpack URLs
1. https://github.com/heroku/heroku-buildpack-ruby
2. https://github.com/ably-forks/heroku-buildpack-nanoc
3. https://github.com/heroku/heroku-buildpack-static
  • How will we rationalise redirects in the website vs the docs repo? Which will take precedence?

  • This model will break if we move to any other static site builder like Gatsby as that too generates static content.

dpflucas

comment created time in 2 months

issue openedably/docs

Support article for "private" channels / revisit docs

Question from customer:

Hey there, was wondering about having "private" channels. I need to have a secure way to publish to different clients while one can't read or subscribe to the other's data. What I thought while reading your docs was generating random hard-to-guess channel names per client and also encrypting them with per-client ciphers. Is this the way to go with Ably? Thanks.

I asked if he was referring to private channels because that is Pusher terminology:

TBH, I'm new to realtime mesaging services so I don't have any established terminology yet.

So this indicates we need to better address this need in our docs, or at least improve our solution articles that are suggested automatically.

Here is his journey through the docs:

screenshot_2020-08-01_07-53-51_pm

created time in 2 months

issue commentably/docs

Reserve extras attribute for customers to use

headers is now permitted, and all other fields are now rejected by realtime. As such, rolling out documentation now to reflect this ASAP is important. cc @MarkWoulfeAbly

mattheworiordan

comment created time in 2 months

issue openedgrafana/grafana

Regression in v7.1 - variables not selectable on iOS mobile device (Chrome & Safari)

What happened:

The first variable drop down on all dashboards using an iOS mobile device with Chrome or Safari (in landscape or portrait) is not selectable as it slides under the dashboard title.

What you expected to happen:

The variable to appear beneath the dashboard title like it does in the desktop, even when sized to a mobile viewport size.

How to reproduce it (as minimally and precisely as possible):

Visit any dashboard page that uses variables on an iOS device (13.5.1), with Chrome or Safari.

Safari view:

![F6CAD1A2-48E4-4576-92EE-7ABA336BAAC8_1_105_c](https://user-images.githubusercontent.com/43789/88596119- 4a47a780-d05c-11ea-9eb2-c218cbd70872.jpeg)

Chrome view:

76CF8330-F323-4D3C-B133-9BB810DE5C02_1_105_c

The same page with Chrome on Mac OS X with the viewport sized to a standard mobile view where the first variable environment appears beneath the title "Realtime Data Center"

screenshot_2020-07-27_10-51-42_pm

Anything else we need to know?:

Environment:

  • Grafana version: Grafana v7.1.0 (8101355285)
  • Data source type & version: InfluxDB 1.7.10
  • OS Grafana is installed on: Ubuntu 14 docker image
  • User OS & Browser: iOS 13.5.1 , iPhone X, with Chrome or Safari
  • Grafana plugins:

Alert list Azure Monitor Bar gauge CloudWatch Dashboard list Elasticsearch Gauge Getting Started Google Cloud Monitoring Grafana Image Renderer Graph Graphite Heatmap Home links InfluxDB Jaeger Logs Loki Microsoft SQL Server MySQL News OpenTSDB Plugin list PostgreSQL Prometheus Singlestat Stat Table Table (old) TestData DB Text Zipkin

created time in 2 months

issue commentably/ably-flutter

Getting error after add this plugin to project

Hi @alexeynobody. Thanks for reporting this issue. We are looking into this and will aim to get a response back to you as quickly as possible (in the next few days at most).

alexeynobody

comment created time in 2 months

Pull request review commentably/docs

Update README instructions

 with that major/minor version.  Client library developers are not expected to monitor the docs repo for spec fixes that occur after the release tag. If a given spec fix needs-to be made to client libraries at that time, on merging the pr to-`master` you should open a github issue in each individual client lib+to be made to client libraries at that time, on merging the PR to+`master` you should open a GitHub issue in each individual client lib repo to request that. If this is not done, it is not mandatory for the fix to be incorporated until the next spec release. -When updating a client lib to a spec version, client lib devs should+When updating a client lib to a spec version, client lib developers should work from a diff from the tag of the previous release, so as to incorporate all changes since that tag. +## Deploying to website (www.ably.io/documentation)++The website consumes this repo through a ruby gem. The gem points at the `master` branch and saves the revision as a version. To release to `/documentation`, follow these steps:

Minor point - ruby is referred to as Ruby elsewhere on this page

MarkWoulfeAbly

comment created time in 2 months

Pull request review commentably/docs

Update README instructions

 # Ably Documentation Overview -[Ably](https://www.ably.io) is a hugely scalable, superfast and secure hosted realtime messaging service for web-enabled devices.+[Ably](https://www.ably.io) is a scalable, fast, and secure hosted realtime messaging service for web-enabled devices. -This Git repository contains most of the [Ably API documentation](https://www.ably.io/documentation) that resides at <https://www.ably.io/documentation> in [Textile](redcloth.org/textile) format.  [Nanoc](http://nanoc.stoneship.org/) is used to build the static site from the `master` branch.+The static site generated from this repository is hosted at <http://docs.ably.io> and deployed automatically when the `master` branch is updated. -The Ably documentation was intentionally created as a public repository using a simple text based markup language so that:+We frequently publish updates from this repository so is typically more up to date than the official Ably documentation which can be found at <https://www.ably.io/documentation>. -* It can be maintained by Ably staff and developers.-* 3rd parties can fork the repository, and submit pull requests to improve the documentation.  We welcome the community's suggestions and input.-* This documentation is later merged upstream to the [Ably primary website documentation](https://www.ably.io/documentation) with each website release.+This Git repository uses the [Textile](https://redcloth.org/textile) format with [Nanoc](http://nanoc.stoneship.org/) used to build the static site from the `master` branch. -## Viewing the documentation+## Running locally -The static site generated from this documentation repository is hosted at <http://docs.ably.io> and deployed automatically when the `master` branch is updated.  We frequently publish updates from this repository so is typically more up to date than the [official Ably API documentation](https://www.ably.io/documentation).+1. Clone a local version of the repo, or a local version of your forked repo.+2. Checkout the master branch.+3. Create and checkout your feature or fix branch. -The official complete Ably documentation that incoporates all the documentation in this repository can be found at <https://www.ably.io/documentation>+At this point you can either run the repo using Docker or directly with Ruby. -## Deploying to website (www.ably.io/documentation)+### Running with Docker -The website consumes this repo through a ruby gem. The gem points at the `master` branch and saves the revision as a version. To release to `/documentation`, follow these steps:+Using Docker, run the following command: -1. Check if the changes that are already on `master` in this repository are ok to be released-1. Merge your PR-1. Clone the [website repo](https://github.com/ably/website)-1. Run `bundle update ably-docs` in the website repo-1. Check in `Gemfile.lock` that the SHA saved by the above command is the SHA of the commit you expected (in most cases this should be the merge/top commit of your PR)-1. Open PR & ask the website team to review-1. Follow the deployment process for website (if in doubt, ask the website team for help)+* `docker-compose up` -## Publishing to JSBin+This starts up a web server at <http://localhost:4000>, builds the static site and allows you to view changes live. -This configuration is not required for basic documentation creation and modification, so most-editors can simply skip to-[Forking and running locally](#forking-and-running-locally).+_This has been tested with Docker version 2.3.0.3. See [Docker installation instructions](https://docs.docker.com/get-docker/)._ -If you will be creating or modifying code within this repository that is to be uploaded automatically-to [JSBin](https://jsbin.ably.io/), for our "Try it now code editor",-then you will need to create yourself a JSBin config file:+_Note: On Windows you will need to re-run the `docker-compose up` command to see changes, unless you are using [WSL](https://docs.microsoft.com/en-us/windows/wsl/install-win10)._ -    cp config/jsbin_config.example.yaml config/jsbin_config.yaml+### Running with Ruby -And then you will need to populate the `api_key` property in that file with a JSBin API key.+Using Ruby directly (2.7.0) you must first run the following command: -The creation of code content for JSBin is further documented in our-[document formatting guide](content/client-lib-development-guide/documentation-formatting-guide.textile)-which gets published-[here](https://docs.ably.io/client-lib-development-guide/documentation-formatting-guide/#code-blocks).-The code that is published to JSBin can be found in-[content/code/](content/code/).--## Forking and running locally--* Fork the repository at https://github.com/ably/docs-* Clone a local version of your forked repo `git clone https://github.com/[you]/docs` and `cd` into it-* Checkout the master branch: `git checkout master`-* Create your feature or fix branch and check it out: `git checkout -b [your-branch]`-* `bundle install` to install the necessary gems, including `nanoc`--At this point you can either run the repo directly on your machine or via Docker.+* `bundle install`  -### Running directly with Ruby+This installs the necessary gems, including `nanoc`. You can then run the web server by running the following command: -If you have Ruby and are comfortable working in a Ruby environment as follows:+* `bundle exec nanoc live -p 4000`  -* `bundle exec nanoc live -p 4000` to start up a web server at <http://localhost:4000>, build the static site and view changes live (well near-live as Nanoc is slow, so monitor the output as you make changes)+This starts up a web server at <http://localhost:4000>, builds the static site and allows you to view changes live.  _For those who use [ASDF](https://github.com/asdf-vm/asdf) or compatible tooling to manage their Ruby runtime versions, we have included a [`.tool-versions`](.tool-versions) file._ -### Running with Docker and Docker compose--If you would prefer to use Docker, then you can run the web server as follows:+## Pull requests -* `docker-compose up`+1. Assuming you have followed the steps above, prior to making a PR, make your changes locally.+2. Commit your changes, push your branch and send us a pull request.+3. All pull requests will automatically launch a static review site that will be linked to at the bottom of the PR. -_This has been tested with Docker version 2.3.0.3. See [Docker installation instructions](https://docs.docker.com/get-docker/)._--## Running on Heroku+## Publishing to JSBin -This repo will automatically run on Heroku, but relies on the following buildpacks (see https://github.com/ably-forks/heroku-buildpack-nanoc):+If you will be creating or modifying code within this repository that is to be uploaded automatically

I think this is a bit ambiguous. There is code all over the place in our repository. JSBin only applies to code in the code folder. I also think we should link to the JSBin repo with information on how that works as there are docs in there too.

MarkWoulfeAbly

comment created time in 2 months

Pull request review commentably/docs

Update README instructions

 # Ably Documentation Overview -[Ably](https://www.ably.io) is a hugely scalable, superfast and secure hosted realtime messaging service for web-enabled devices.+[Ably](https://www.ably.io) is a scalable, fast, and secure hosted realtime messaging service for web-enabled devices. -This Git repository contains most of the [Ably API documentation](https://www.ably.io/documentation) that resides at <https://www.ably.io/documentation> in [Textile](redcloth.org/textile) format.  [Nanoc](http://nanoc.stoneship.org/) is used to build the static site from the `master` branch.+The static site generated from this repository is hosted at <http://docs.ably.io> and deployed automatically when the `master` branch is updated. -The Ably documentation was intentionally created as a public repository using a simple text based markup language so that:+We frequently publish updates from this repository so is typically more up to date than the official Ably documentation which can be found at <https://www.ably.io/documentation>. -* It can be maintained by Ably staff and developers.-* 3rd parties can fork the repository, and submit pull requests to improve the documentation.  We welcome the community's suggestions and input.-* This documentation is later merged upstream to the [Ably primary website documentation](https://www.ably.io/documentation) with each website release.+This Git repository uses the [Textile](https://redcloth.org/textile) format with [Nanoc](http://nanoc.stoneship.org/) used to build the static site from the `master` branch.

I think it's important we include a reference to the documentation on how to write content in content/client-lib-development-guide/documentation-formatting-guide.textile as anyone who wants to contribute, would need to read that to get going.

MarkWoulfeAbly

comment created time in 2 months

Pull request review commentably/docs

Update README instructions

 # Ably Documentation Overview -[Ably](https://www.ably.io) is a hugely scalable, superfast and secure hosted realtime messaging service for web-enabled devices.+[Ably](https://www.ably.io) is a scalable, fast, and secure hosted realtime messaging service for web-enabled devices. -This Git repository contains most of the [Ably API documentation](https://www.ably.io/documentation) that resides at <https://www.ably.io/documentation> in [Textile](redcloth.org/textile) format.  [Nanoc](http://nanoc.stoneship.org/) is used to build the static site from the `master` branch.+The static site generated from this repository is hosted at <http://docs.ably.io> and deployed automatically when the `master` branch is updated. -The Ably documentation was intentionally created as a public repository using a simple text based markup language so that:+We frequently publish updates from this repository so is typically more up to date than the official Ably documentation which can be found at <https://www.ably.io/documentation>. -* It can be maintained by Ably staff and developers.-* 3rd parties can fork the repository, and submit pull requests to improve the documentation.  We welcome the community's suggestions and input.-* This documentation is later merged upstream to the [Ably primary website documentation](https://www.ably.io/documentation) with each website release.+This Git repository uses the [Textile](https://redcloth.org/textile) format with [Nanoc](http://nanoc.stoneship.org/) used to build the static site from the `master` branch. -## Viewing the documentation+## Running locally -The static site generated from this documentation repository is hosted at <http://docs.ably.io> and deployed automatically when the `master` branch is updated.  We frequently publish updates from this repository so is typically more up to date than the [official Ably API documentation](https://www.ably.io/documentation).+1. Clone a local version of the repo, or a local version of your forked repo.+2. Checkout the master branch.+3. Create and checkout your feature or fix branch. -The official complete Ably documentation that incoporates all the documentation in this repository can be found at <https://www.ably.io/documentation>+At this point you can either run the repo using Docker or directly with Ruby. -## Deploying to website (www.ably.io/documentation)+### Running with Docker -The website consumes this repo through a ruby gem. The gem points at the `master` branch and saves the revision as a version. To release to `/documentation`, follow these steps:+Using Docker, run the following command: -1. Check if the changes that are already on `master` in this repository are ok to be released-1. Merge your PR-1. Clone the [website repo](https://github.com/ably/website)-1. Run `bundle update ably-docs` in the website repo-1. Check in `Gemfile.lock` that the SHA saved by the above command is the SHA of the commit you expected (in most cases this should be the merge/top commit of your PR)-1. Open PR & ask the website team to review-1. Follow the deployment process for website (if in doubt, ask the website team for help)+* `docker-compose up` -## Publishing to JSBin+This starts up a web server at <http://localhost:4000>, builds the static site and allows you to view changes live. -This configuration is not required for basic documentation creation and modification, so most-editors can simply skip to-[Forking and running locally](#forking-and-running-locally).+_This has been tested with Docker version 2.3.0.3. See [Docker installation instructions](https://docs.docker.com/get-docker/)._ -If you will be creating or modifying code within this repository that is to be uploaded automatically-to [JSBin](https://jsbin.ably.io/), for our "Try it now code editor",-then you will need to create yourself a JSBin config file:+_Note: On Windows you will need to re-run the `docker-compose up` command to see changes, unless you are using [WSL](https://docs.microsoft.com/en-us/windows/wsl/install-win10)._ -    cp config/jsbin_config.example.yaml config/jsbin_config.yaml+### Running with Ruby -And then you will need to populate the `api_key` property in that file with a JSBin API key.+Using Ruby directly (2.7.0) you must first run the following command:

I would avoid specifying the Ruby version here, and instead link to the .ruby_version file stating that version should be used

MarkWoulfeAbly

comment created time in 2 months

Pull request review commentably/ably-flutter

Synchronous API for creating instances and Hot-reload fix

 clientOptions.logLevel = ably.LogLevel.verbose; //optional ##### Rest API  ```dart-ably.Rest rest = await ablyPlugin.createRest(options: clientOptions);+ably.Rest rest = ably.Ably.Rest(options: clientOptions);

Thanks for the feedback and thoughts, it's all getting exciting 👍

tiholic

comment created time in 3 months

Pull request review commentably/ably-flutter

Synchronous API for creating instances and Hot-reload fix

 clientOptions.logLevel = ably.LogLevel.verbose; //optional ##### Rest API  ```dart-ably.Rest rest = await ablyPlugin.createRest(options: clientOptions);+ably.Rest rest = ably.Ably.Rest(options: clientOptions);

@Quintin, out of interest, why did you propose introducing RestClient instead of:

var rest = Ably.Rest(options: clientOptions);

See comparable https://github.com/ably/ably-js#typescript, https://github.com/ably/ably-js#introduction and https://github.com/ably/ably-java#using-the-realtime-api

P.S. I am not sure why we opt for ably as the lib vs Ably. Is that a Dart thing?

tiholic

comment created time in 3 months

pull request commentably/docs

Consolidate functions and webhooks documentation between versions

@MarkWoulfeAbly please can you refer to https://ably.atlassian.net/wiki/spaces/ENG/pages/312377505/Git-PR-best-practice as this PR has no comment or description. Everyone needs this to have context of what they're reviewing.

Can you please explain what you're trying to achieve with this PR? I am not clear from the single commit.

MarkWoulfeAbly

comment created time in 3 months

issue openedably/docs

SDK IDL should use a portable format

If we use a portable definition language for our SDK interfaces and types, we benefit from potentially being able to autogenerate code in languages we support.

Currently our IDL uses a bespoke format which was intentional to avoid coupling to any language idiomatic features, however this approach too has its shortcomings. See @SimonWoolf thoughts on this at https://github.com/ably/docs/issues/791#issuecomment-572542506.


Extracts from a Slack convo

Matt

See https://app.quicktype.io?share=BOtw8DjRdmLMIT9cLCy0. Whilst talking to the folks at AsyncAPI they said they are looking at using Quicktype to auto-generate types that they can use in their generated SDKs. I tried our TypeScript definition and created https://app.quicktype.io?share=BOtw8DjRdmLMIT9cLCy0

It got me thinking though:

  • Could we use this (manually) to take the client lib spec in a format like TypeScript and generate types across all our SDKs?
  • Given the serialisation problems we’ve just had with Dart / Flutter, could we use it there too to help avoid typos etc?

Simon

That does look neat. The generator is giving not-great output for the pseudo-enums in the ably-js typings (which I think might have been originally written by someone before typescript had enums, and we've stuck with that style since) -- we'd write cleaned-up typings, maybe in a subset of typescript that gives decent results with quicktype. I suspect it wouldn't ever be quite good enough to autogenerate and use unmodified, just as a starting point. especially since some libs do depart from the standard typings in deliberate/limited ways, eg for callbacks vs promises vs sync functions per what's idiomatic in the language. Anyway, main point is :+1: to using consistent machine-readable typescript for our IDL, rather than the almost-rust-ish pseudocode we have now. (Which is actually something I've proposed previously - https://github.com/ably/docs/issues/791#issuecomment-572542506 )

created time in 3 months

more