リアルタイム共同編集のアルゴリズム (Operational Transformation; OT) を理解する試み

Google Docsのように文書を複数人でリアルタイムに共同編集できるアプリケーションがあります。あのような機能は、多かれ少なかれ、Operational Transformation (OT; 操作変換) という考え方を使って実現されているようです。興味があったので、このOTについて調べてみました。

(追記: これからは OT でなく CRDT だという話 → I was wrong. CRDTs are the future)

なおGoogle Docsではいわゆる「リッチテキスト」を共同編集できますが、ここでは話を簡単にするために「プレーンテキスト」を共同編集することを想定します。

リアルタイム共同編集の流れ

共同編集システムの登場人物は次の通りです：

• サーバ x 1（各クライアントから届く編集操作をもとに、最新の文書を保持します）
• クライアント x N（文書を編集する側です）

そして、リアルタイム共同編集では以下のような処理が繰り返されます：

1. 各クライアントは、手元で文書が編集されたら、その編集操作の内容をサーバに送信します。
2. サーバは、各クライアントから送られてくる編集操作を、到着した順にサーバ上の文書に適用します（※ここでOTを使います。後述）。
3. 次にサーバは、他の全てのクライアントに編集操作の内容を送信します。
4. 各クライアントは、サーバから送られてきた（他のクライアントによる）編集操作を、手元の文書に反映します（※ここでもOTを使います。後述）。

ちなみにプレーンテキストにおいては、「編集操作」というのは文字列の単なる挿入と削除のことです。例えば「39文字目に文字列 “hello” を追加」とか「74文字目から8文字を削除」といったものです。

サーバは、各クライアントから届く編集操作を、到着順にサーバ上の文書に反映させていきます。これによってサーバ上の文書は次々と更新されていき、文書のリビジョン番号 (rev) は 0 → 1 → 2 → 3 → 4 → … と直線的に進んでいきます。サーバは、あるクライアントから届いた編集の内容を、他のクライアント全員にも送信することで、皆が同じ文書の状態を共有します。

…というのが基本ですが、現実はそう簡単ではありません。

メカニカルキーボード (Niz micro82) を買って Magic Trackpad 2 と併置した

MacBook Proを横によけて外付けディスプレイをメインで使おうと思って、Niz micro82というキーボードを買った。メカニカルキーボードを使うのは10年以上ぶり。

公式サイトで注文してちょうど1週間で届いた。Bluetooth付きモデルで、送料込みで$189だった。

1万円超のフライパン (Scanpan) に買い替えた

700円で買ったフライパンを捨ててデンマーク製の “Scanpan Pro IQ Saute Pan（ソテーパン）” というやつを買った。ソテーパンは日本でいう炒め用フライパンと同じような形状をしている。

日本でまともに買うと32,000円以上するので、保証が効かないことを覚悟したうえでオーストラリアから輸入した。本体12,000円＋送料4,000円の計16,000円で買えた。

Facebook PageとInstagramへの反応をAPIでリアルタイムにウォッチする

（追記：その後、App作成時に “Facebook Business Integrations” という種別を選択できるようになったらしく、身内でしか使わないアプリに関しては以下のような審査は不要かもしれません。どんどん状況が変っていくのでついていけません…）

チームで管理するFacebookページやInstagramアカウントへの反応（例えばコメント）をリアルタイムに把握したいというニーズは多いと思う。これはFacebookが提供するWebhooksを使えば実現できる。ただしWebhooksの利用自体は比較的簡単だが、その利用審査が面倒くさい。

Facebookの多くのAPIは、自分が管理するオブジェクトに対する操作であれば「開発モード」（つまり審査なし）でも使える。しかしここで扱う Webhooks (for Facebook Pages / Messenger / Instagram) に関しては、「ライブモード（本番モード）」でなければ動作しない。つまり、たとえ自分が管理しているページでの利用であっても、必要なパーミッションを申請して審査を受ける必要がある。

届いたFAXを自動でGoogle Driveに保存してOCRで本文を抽出してSlackで通知する

(@前職)

リモートワークの絡みで、タイトルの通りのことをやってみようと思いついて、やってみたらけっこう簡単にできたので、その概要を書いておく。

処理の要点は、メールの自動受信処理、Google Cloud VisionによるOCR、Google Drive (G Suite) へのアップロードなど。

最終的な結果は以下のような感じでSlackに通知される。

処理の流れ

FAX複合機
 ↓
SendGrid Inbound Parse Webhook
 ↓
Google Cloud Functions
    → Google Cloud Vision
    → Google Drive (G Suite)
 ↓
Slack

メールの「受信」ができるAPIの比較 (2020年5月)

Amazon SES vs. SendGrid vs. Mailgun vs. Mailjet vs. Mailchimp

Google Cloud Functionsを試す with Python 3.7

Cloud Functionsは、端的にいえばAWS LambdaのGoogle Cloud版だ。要するに、比較的小規模なコードをデプロイしておいて、何らかのトリガに応じてそれを実行させて、実行された時間分だけ課金される、という仕組みで、俗に「サーバレス」と呼ばれているものの礎の1つでもある。

AWS Lambdaと比べて

Cloud Functionsの特徴としては：

CloudflareによるロードバランシングとZero-Downtime Failover

格安VPSなどでWebサーバのクラスタを組む場合に、Cloudflareのロードバランシング機能が便利に使えることがある。Cloudflare自体がそもそもリバースプロクシなので、そのリバースプロクシから複数のOriginへとリクエストを振り分ければ負荷分散やフェイルオーバーが行えるという仕組みだ。

格安VPSとこれを組み合わせるメリットとしては例えば：

Nature Remo E liteでスマートメーターから使用電力を読む

自分が住んでいるアパートには既にスマートメータが設置されているので、スマートメータと通信できる機器さえ用意すればば現在の使用電力を読み取ることができる。今回、Nature Remo E liteという比較的安めの機器が発売されたので買ってみた。

Nature Remo E lite

Nature Remo Eは、「Nature Remo」というIoT赤外線リモコンを主力商品として出している会社が作ったHEMSコントローラだ。

上位版の Nature Remo E（約3万円）は2019年末に出ていたが、今回、そこから太陽光発電や蓄電池システムとの通信機能を省いたNature Remo E liteという廉価版（1.4万円）が発売された。liteのほうはスマートメーターとの通信のみに限定されている。